Ciao a tutti.
E bentornati.
In questo video, con una panoramica di alto livello, parleremo delle implementazioni di Amazon ideas
in più zone di disponibilità, note anche come implementazioni multiple.
Ora, prima di discuterne più dettagliatamente, analizziamo una sfida tipica.
Supponiamo di avere un database in esecuzione nella zona di disponibilità, numero uno.
Ora, per qualche motivo, se questa zona di disponibilità uno va in tilt o magari l'hardware su cui girava il database
va in tilt, l'intera applicazione andrà in tilt perché il cuore dell'applicazione, dove i
dati sono principalmente memorizzati, è il database.
Se il database è inattivo, l'intero sito web può andare in tilt.
E questo è un aspetto che non si desidera per gli ambienti di produzione.
Questo è il motivo per cui è molto importante che ogni volta che si utilizzano le idee per la produzione,
si evitino le distribuzioni basate su una sola zona di disponibilità.
L'architettura migliore consiste nell'utilizzare una distribuzione a più zone di disponibilità.
Quindi, in un'architettura di distribuzione basata su più AC, si ha un database primario
qui e un database secondario che viene eseguito in una zona di disponibilità diversa della
stessa regione e c'è una replica che avviene tra entrambi i database.
Ora, per qualche motivo, ad esempio se il database primario si guasta, le idee reindirizzeranno tutte
le richieste all'istanza stand by.
Va bene.
Questo è il processo automatizzato.
Come utente o applicazione, non c'è bisogno di preoccuparsi di questo.
Ora, una delle domande che ci si pone è: in quale scenario avviene il failover automatico dall'istanza
primaria a quella di standby?
Ora, prima di esaminare il campo delle condizioni, rivediamo rapidamente che in caso di interruzione pianificata
o non pianificata dell'istanza del database, questa passa automaticamente alla replica di standby in un'altra zona di disponibilità
nelle distribuzioni multi AC.
È una cosa che abbiamo visto.
Esaminiamo ora alcune condizioni.
Il primo è che se si verifica una perdita di disponibilità nella zona di disponibilità primaria.
In secondo luogo, se si verifica una perdita di connettività di rete all'istanza primaria, se si verifica un guasto dell'unità
di calcolo sull'istanza primaria, si verifica nuovamente la condizione di failover.
In questi casi, se si verifica un guasto dello storage sull'istanza del database primario, avviene anche il failover
automatico.
E quando esaminiamo il tempo di failover, in genere varia da 60 a 1-20 secondi.
Ora, facciamo una cosa.
Vediamo di capire questo aspetto dal punto di vista dimostrativo, in modo che il nostro concetto sia chiaro.
Per la demo di oggi, ho un database creato in base alla distribuzione multi AC.
Il nome del database è Demo DB, Multi AC.
Ora, se si esamina questo database specifico, si passa alla configurazione.
Scendiamo un po' più in basso.
Si può notare che il multi AC è abilitato, quindi è indicato come sì.
Andiamo quindi a vedere come funziona esattamente.
Passiamo quindi alla connettività.
Copio il punto finale dell'istanza IDs.
E facciamo una rapida ricerca per vedere qual è l'indirizzo IP restituito.
L'indirizzo IP è uno 7231 37. 32.
A questo punto, se devo mostrarvi il diagramma, potete considerare che l'indirizzo
IP restituito è quello dell'istanza primaria.
Ora, per una prospettiva dimostrativa, faremo un failover e vedremo come l'indirizzo IP cambierà in quello dell'istanza
secondaria.
Quindi facciamo una cosa.
Procediamo con il riavvio dell'istanza del database.
Ora, ogni volta che si riavvia, è possibile scegliere di riavviare con Failover.
Procediamo quindi con la conferma.
Si tratta quindi di un modo semplice per capire come funziona l'implementazione multi CA in scenari reali.
Nel caso in cui si verifichino problemi legati alla rete e il failover avvenga automaticamente, non è necessario
preoccuparsi.
Permettetemi quindi di fare una rapida conferma.
Va bene.
Quindi la ricostruzione è in corso.
Aspettiamo un attimo.
Quindi, al momento dell'aggiornamento, il nostro stato è ora disponibile.
A questo punto, se si esegue nuovamente la ricerca NSS per trovare l'indirizzo IP associato all'istanza del
database, questa volta si noterà che l'indirizzo IP è diverso.
Prima era un 7231 3732 ora è un 7231 79. 1 47.
Quindi, dietro le quinte, RDC ha reindirizzato automaticamente la richiesta all'istanza di standby.
Ora, una cosa importante da notare è che l'URL dell'endpoint di cui stiamo parlando
qui, rimane lo stesso.
Quindi, anche se il database primario va in tilt e le richieste sono dirette a questo endpoint, le idee indirizzeranno
automaticamente la richiesta all'istanza di standby.
Questo è il motivo per cui l'alta disponibilità orale funziona in un'architettura basata su più CA.