Ciao a tutti e bentornati.
In questo video parleremo dei tipi di distribuzione di più risorse.
Ora, in una panoramica di alto livello, tenete presente che quando decidete di utilizzare le distribuzioni
multibase nelle idee, sono disponibili due sottotipi.
Il primo è l'implementazione di più istanze CA.
Il secondo è l'implementazione di cluster multi AC.
Tra questi, la distribuzione di più istanze di CA è l'approccio più vecchio.
L'implementazione di cluster multi CA è l'approccio più recente e, in genere, per gli ambienti di produzione, l'implementazione
di cluster multi CA si rivela piuttosto utile.
Andiamo quindi avanti e cerchiamo di capire entrambe le cose.
Il primo approccio è l'implementazione di più istanze AC.
Si tratta anche di una multi CA con uno standby.
Quindi, se guardate questo diagramma, avete l'istanza del database primario e uno standby disponibile.
E tra entrambi è in corso una replica.
Ora, una cosa da notare è che questa istanza di standby, anche se è in corso una replica come
utente, non sarà in grado di eseguire alcuna operazione sull'istanza di standby, compresa
l'operazione Reid.
A volte ci si chiede se l'istanza di standby sia in funzione.
Perché non usarlo per le operazioni di raid?
Questo si rivela utile perché viene già aggiunto come parte dei costi.
Tuttavia, in questo tipo di approccio, questa replica standby, non c'è alcun accesso a meno che e fino a quando
il DB primario non si guasta, questa replica standby diventa il nuovo database primario.
L'approccio numero due, come stiamo discutendo, è la distribuzione di cluster multi AC.
In questo tipo di architettura, c'è un'istanza di database writer e un'istanza di database read e tutte sono
disponibili in tre zone di disponibilità separate nella stessa regione.
Ad esempio, qui si vede che ci sono tre zone di disponibilità, giusto?
L'istanza del DB è disponibile qui, ci sono due istanze del database.
Quindi si può usare anche come istanza di standby, come abbiamo discusso nell'approccio.
L'unico vantaggio è che non solo può fungere da istanza di standby, ma può anche eseguire
operazioni di lettura.
Quindi il carico automatico viene distribuito, giusto?
L'operazione può andare all'istanza DB giusta e leggere L'operazione può andare all'istanza DB del lettore qui.
Quando si parla di tipi di distribuzione negli ID, ci sono tre tipi di distribuzione principali.
Una è la singola zona di disponibilità.
Si dispone di una zona a disponibilità multipla con uno standby.
Quindi questo è l'approccio numero uno, e avete la zona di disponibilità multipla con due standby leggibili,
che non è altro che l'implementazione di cluster multi AC.
Quando si parla di capacità di lettura aggiuntiva per la singola zona di disponibilità, non c'è alcuna capacità
di lettura aggiuntiva.
Esiste una sola istanza del database primario, che può essere utilizzata per le operazioni di lettura
e scrittura.
Quando si parla di multi AC con uno standby, non c'è capacità di lettura aggiuntiva, poiché non è
possibile eseguire alcuna operazione di lettura sull'istanza di standby.
Tuttavia, per le distribuzioni in cluster, è necessario che l'istanza del DB sia leggibile.
Questo si rivela quindi vantaggioso quando si parla di rilevamento automatico del failover per una singola CA.
Anche in questo caso, non c'è e per la multi CA, ci sarà sempre un rilevamento dei guasti.
Quando si parla di durata del failover, è qui che l'implementazione del cluster si rivela ancora una volta
utile.
Quando si parla di più CA con uno standby, il nuovo primario è disponibile per servire il
carico di lavoro in soli 60 secondi.
Tuttavia, per le distribuzioni in cluster è molto più veloce, in genere sotto i 35 secondi.
Prima di concludere, analizziamo rapidamente entrambi gli aspetti.
Ora dalla console IDS.
Ho due istanze di database disponibili.
Uno è basato sulla distribuzione dell'istanza qui.
Questa è la distribuzione dell'istanza.
Il secondo si basa sulla distribuzione del cluster.
Ora, come stiamo discutendo nella distribuzione dell'istanza, tutte le repliche in standby sono presenti,
ma non è possibile accedervi.
Questo è un aspetto che va sottolineato.
Se lo apro, c'è solo un endpoint e questo endpoint va all'istanza del database primario.
Ora, quando discutiamo delle distribuzioni in cluster, sappiamo che abbiamo un'istanza DB destra
e due istanze DB lettore.
Quindi, se espando questo, si vede che per il cluster multi AC c'è un'istanza a destra e due
istanze di lettura.
E una cosa da notare è che tutti questi sono in zone di disponibilità separate, quindi lo scrittore
è in una, il lettore è in una, il secondo lettore è in una D Questa è una cosa da notare insieme a questo, se apro
rapidamente questo vedrete che di solito il.
Due punti finali.
Il primo punto finale è per la destra, ad esempio.
Quindi, per l'applicazione che eseguirà l'operazione corretta, sarà necessario fornire questo endpoint
specifico.
E c'è anche un altro endpoint per l'istanza del lettore.
È qui che il traffico sarà indirizzato all'insieme di istanze del lettore DB, nel caso in cui si voglia connettersi direttamente
a un'istanza specifica del lettore DB, è possibile farlo.
Ad esempio, se apro l'istanza del DB del lettore, anche qui c'è il suo set di endpoint.
Va bene.
Spero che con questa panoramica di alto livello abbiate compreso le basi dell'implementazione
di istanze multi CA e del cluster multi CA.
Prima di concludere, volevo anche mostrarvi alcune cose.
Quindi, ogni volta che si crea un database con un approccio basato su più AC.
Vediamo quindi di analizzarlo rapidamente.
Permettetemi di selezionare il test.
E nel giro di un anno ci si accorge di avere un cluster multi AC db e l'istanza multi AC db, come stiamo discutendo,
il cluster multi AC db presenta grandi vantaggi ma anche grandi costi.
Quindi è molto più costoso rispetto all'istanza DB.
Questo è un aspetto che va sottolineato.
Oltre a ciò, esistono anche alcune restrizioni relative al tipo di istanza e allo storage che può essere utilizzato.
Ad esempio, se si seleziona un'istanza multi AC DB, scendiamo un po' più in basso.
Sotto la classe di istanza, c'è lo standard, c'è la memoria ottimizzata e c'è anche l'istanza
più stabile come P tre micro e così via.
Se seleziono rapidamente il deployment del cluster qui, scendiamo un po' più in basso.
Non avete la versione stabile disponibile.
Avete solo la memoria standard e quella ottimizzata e lo stesso vale per lo spazio di archiviazione.
Selezioniamo quindi l'istanza del DB multi AC.
Andiamo al magazzino.
Ora, nel tipo di archiviazione, è possibile selezionare anche l'archiviazione più economica, come l'SSD per uso generico,
oltre a quella più costosa come il provisioning.
Si tratta quindi di qualcosa che può essere utilizzato e anche nello spazio di archiviazione allocato, ad esempio 20 GB.
Tuttavia, quando si seleziona l'opzione cluster, passiamo allo storage.
Si vede che nel magazzino non c'è lo scopo generale, che è molto più economico.
L'unica opzione è la fornitura di IOPS, SD e il valore minimo è di 100 giga.
Va bene.
Quindi, nel caso in cui si utilizzi questo approccio, sarà molto più costoso nel caso in cui si stia
provando anche dal punto di vista pratico, dal momento che non si dispone del DT tre micro e di
altre istanze, si dovrà andare con m, fi, D e altri e questo costerà parecchio.
Si tratta quindi di un aspetto da tenere presente.
Ottimo.
Con questo si conclude il video di oggi.