Ciao, Adrian, e bentornato.
Nel video di oggi parleremo di come ottenere l'alta disponibilità con il failover del
cloud front Origin.
Ora, una delle cose da notare è che se il cloud di Origin è inattivo, l'impatto complessivo è sull'ambiente
di produzione.
Quindi, in questo esempio, ho un'istanza semplice e facile da usare come origine per il fronte cloud.
Quindi, se questa istanza di EC due va in tilt, tutti gli utenti ne risentiranno.
Ora, questa origine può essere un bucket S3, un carico di applicazioni, bilanciatori e così via. Per ovviare a questo problema, il cloud front ha una
caratteristica specifica che ci permette di ottenere un'alta disponibilità, considerando
che ci sono più origini.
Quindi, in questo insieme rivisto di architetture, si nota che ci sono due origini.
Uno è l'istanza EC due nella regione uno e il secondo è un'istanza PC due di backup nella regione due, nel
caso in cui il cloud friend non sia in grado di connettersi all'istanza EC due primaria nella regione, un cloud
front può fare automaticamente il failover e inviare tutte le richieste a questo PC due di backup nella regione due.
Questo è il cosiddetto failover complessivo dell'origine.
Ora, prima di procedere oltre e capire le cose in modo più dettagliato, facciamo una rapida dimostrazione per capire il flusso
di lavoro complessivo.
Per la demo di oggi, ho una distribuzione cloud.
Apriamo rapidamente la discussione.
Ora qui dentro, apriamo le origini.
Sono disponibili due origini.
In realtà, entrambi sono facili.
Ad esempio, se si esamina il nome del dominio di origine, si ha un'istanza CE numero uno e un'istanza
facile numero due.
Quindi la prima istanza è nella regione della Virginia settentrionale e la seconda è nella regione di Singapore.
Quindi il primo amico di Cloud invierà sempre una richiesta alle primarie EC due in North Virginia.
Se il primario EC due fallisce, invia una richiesta alla seconda ricevuta.
Quindi andiamo avanti e proviamo rapidamente.
Per prima cosa, apriamo l'URL.
Quindi questo è associato a una AC primaria due.
Quindi, se lo aggiungo qui, si ottiene l'impostazione predefinita.
Benvenuti alla pagina del motore ICS.
Apriamo l'URL associato a un PC di backup due.
Aggiungiamolo.
Questa volta il titolo è cambiato da Welcome to Engine X a Welcome to Backup Server.
Da qui si può facilmente identificare quale sia il server.
Ora, dal fronte delle nuvole, torniamo indietro.
Apriamo il nome del dominio nel browser.
Quando inserisco il nome del dominio come previsto, viene visualizzata la pagina Welcome to engine ICS.
Quindi ora facciamo una cosa.
Procediamo con l'arresto di questa istanza della CE due.
Fermiamo quindi questa istanza della CE due.
Quindi, se le cose funzionano bene, la richiesta ripetuta al cloud front dovrebbe andare a questo specifico server
di backup.
Aspettiamo quindi che l'istanza si fermi.
Quindi attualmente è in stato di arresto.
Va bene così.
Quindi, se copiamo l'URL dell'EC due che abbiamo appena interrotto, inviamo una richiesta a quell'URL.
Anche in questo caso, si tratta di una cache.
Questo è il motivo per cui sta arrivando.
Eseguiamo un controllo per.
E questa volta, vedete, non viene servita alcuna richiesta.
È inoltre possibile verificare dal ClA che se si effettua una chiamata su questo URL specifico, non si ottiene alcuna risposta,
principalmente perché l'istanza e il server web non sono più in esecuzione.
Quindi, dopo un attimo, il messaggio indica che la connessione si è interrotta.
Quindi questa volta inviamo una richiesta di distribuzione al cloud per vedere qual è la risposta che
riceviamo.
E questa volta vedete che nel ClA stiamo ricevendo il benvenuto al server di back up.
Va bene.
Spero che con questa panoramica di alto livello abbiate capito le basi del failover di Origin.
Ora, prima di concludere, ci sono alcune indicazioni importanti da tenere presenti.
Il primo punto è che se una richiesta ha un riscontro nella cache, il cloud friend restituirà subito l'oggetto
richiesto.
È semplice da capire.
Il secondo punto è che se si verifica una cache miss, il cloud front instrada la richiesta all'origine primaria
nel gruppo di origine.
Ora avete un'origine primaria e un'origine secondaria o di backup.
La prima priorità è sempre l'origine primaria.
Ora, dall'origine primaria, se il cloud front non è in grado di connettersi o l'origine primaria sta inviando un tipo
di risposta come Phi X, X o altri, allora Cloud Friend può andare avanti e inviare una richiesta all'origine
secondaria, che fa parte del gruppo di origine.
Quindi tutte le origini configurate come primarie o secondarie possono essere configurate come parte del gruppo
di origini.
Ad esempio, qui abbiamo due origini configurate insieme a questa.
Abbiamo anche un gruppo di origine che viene creato.
Ora, se guardate a questo gruppo di origini, avete un'origine denominata origine primaria e un'origine
denominata origine di backup.
In questo modo è possibile controllare quale dei due sia primario o di backup.
Inoltre, è possibile configurare i criteri di failover.
Quindi, se è stato restituito un errore 500 internal server dall'origine primaria o un bad
gateway dall'origine primaria, ecc. oppure l'origine primaria non risponde al cloud friend,
allora il cloud front invia una richiesta all'origine secondaria.
Ora ho allegato anche un diagramma direttamente dalla documentazione, che spiega la stessa cosa, e diventa
più facile da rivedere.
Quindi la richiesta va al fronte cloud.
Se c'è un riscontro nella cache, il cloud front restituirà la risposta.
È una cosa che abbiamo visto.
Tuttavia, se si verifica una mancanza di cache, si invia una richiesta all'origine.
Questa è quindi l'origine primaria.
Ora, se l'origine risponde con un errore, la richiesta andrà all'origine B e dall'origine
B i dati saranno restituiti al visualizzatore.
Questo è il gruppo di origine in cui sono presenti l'origine primaria e quella secondaria.
Questa è una panoramica di alto livello che conclude il video di oggi.