Creazione di servizi ad alta disponibilità con dischi replicati
Questa sezione spiega come creare servizi ad alta disponibilità con Dischi ad alta disponibilità con bilanciamento con Hyperdisk.
Note sul layout
Prima di iniziare a progettare un servizio ad alta disponibilità, comprendi le caratteristiche dell'applicazione, del file system e del sistema operativo. Questi caratteristiche sono alla base della progettazione e possono escludere approcci. Ad esempio, se un'applicazione non supporta l'applicazione alcune opzioni di progettazione corrispondenti non sono applicabili.
Analogamente, se l'applicazione, il file system o il sistema operativo non sono a prova di arresti anomali, quindi Disponibilità elevata con Hyperdisk Balanced (anteprima) e perfino snapshot di dischi a livello di zona, un'opzione. La tolleranza degli arresti anomali è definita come la capacità di recuperare da un Interruzione improvvisa senza perdere o danneggiare i dati di cui è già stato eseguito il commit su un disco prima dell'arresto anomalo.
Considera quanto segue quando progetti per l'alta disponibilità:
- L'effetto sull'applicazione dell'uso Disponibilità elevata Hyperdisk Bilanciata o altre soluzioni
- Prestazioni di scrittura del disco
- L'obiettivo del tempo di recupero del servizio: la velocità dopo un'interruzione del servizio a livello di zona e i requisiti dello SLA (accordo sul livello del servizio)
- Il costo per creare un'architettura di servizio resiliente e affidabile
In termini di costo, utilizza le seguenti opzioni per le di replica asincrona delle applicazioni:
Utilizza due istanze del database e della VM. In questo caso, determinano il costo totale:
- Costi delle istanze VM
- Persistent Disk o Costi di Hyperdisk
- Costi di mantenimento della replica delle applicazioni
Utilizza una singola VM con dischi replicati in modo sincrono. Per raggiungere la disponibilità con un disco a disponibilità elevata bilanciata con Hyperdisk, usa la stessa istanza VM e i componenti del disco come l'opzione precedente, ma includono anche un oggetto il disco replicato. i dischi ad alta disponibilità bilanciati con Hyperdisk hanno il doppio a livello di zona, perché vengono replicati diverse.
Tuttavia, l'uso di dischi replicati in modo sincrono potrebbe ridurre i costi di manutenzione perché i dati vengono automaticamente scritti su senza la necessità di mantenere la replica dell'applicazione.
Non avviare la VM secondaria finché non è richiesto il failover. Puoi ridurre l'host costa ancora di più avviando la VM secondaria solo on demand durante anziché mantenerla come VM attiva in standby.
Confrontare costi, prestazioni e resilienza
La seguente tabella evidenzia i compromessi in termini di costi, prestazioni per le varie architetture di servizio.
| Architettura del servizio ad alta disponibilità |
Snapshot del disco di zona |
Sincrona a livello di applicazione |
Asincrona a livello di applicazione |
Dischi replicati sincrono |
|---|---|---|---|---|
| Protezione da errori delle applicazioni, delle VM e delle zone1 | ||||
| Mitigazione contro il danneggiamento delle applicazioni (Esempio: intolleranza agli arresti anomali dell'applicazione). | 2 | 2 | ||
| Costo | € |
$$
|
$$
|
$1,5x - $$
|
| Prestazioni delle applicazioni |
|
|
|
|
| Adatto per applicazioni con requisiti di RPO ridotti (tolleranza molto bassa per la perdita di dati) |
|
|
|
|
| Tempo di ripristino dello spazio di archiviazione da un'emergenza4 |
|
|
|
|
1 L'utilizzo di dischi o snapshot replicati non è sufficienti per proteggerti da guasti e malfunzionamenti e mitigarlo. L'applicazione, il file system ed eventuali altri componenti software devono essere sono coerenti o utilizzano una sorta di quiescing.
2 La replica di alcune applicazioni fornisce mitigazione contro il danneggiamento di alcune applicazioni. Ad esempio, MySQL principale il danneggiamento dell'applicazione non fa sì che le istanze VM di replica diventino corrotti. Per maggiori dettagli, consulta la documentazione della tua applicazione.
3 Per perdita di dati si intende una perdita di dati irreversibile nello spazio di archiviazione permanente. I dati non impegnati continuano a andare persi.
4 Le prestazioni del failover non includono il file system nonché il ripristino e il caricamento delle applicazioni dopo il failover.
Creazione di servizi di database ad alta disponibilità utilizzando dischi replicati in modo sincrono
Questa sezione tratta concetti generali per la creazione di soluzioni ad alta disponibilità per i servizi di database stateful (MySQL, Postgres e così via) utilizzando Compute Engine con dischi ad alta disponibilità bilanciati con Hyperdisk (anteprima).
In caso di ampie interruzioni in Google Cloud, ad esempio nel caso dell'intera regione se non è più disponibile, la tua applicazione potrebbe non essere più disponibile. In base a le tue esigenze, considera tecniche di replica tra regioni per una disponibilità ancora maggiore.
Le configurazioni ad alta disponibilità del database in genere hanno almeno due istanze VM. Preferibilmente queste istanze VM fanno parte di uno o più gruppi di istanze gestite:
- Un'istanza VM principale nella zona principale
- Un'istanza VM in standby in una zona secondaria
Un'istanza VM principale ha almeno due dischi: un disco di avvio il disco replicato. Il disco replicato contiene dati di database e tutti gli altri dati modificabili che devono essere conservati in un'altra zona in caso di un'interruzione del servizio.
Un'istanza VM in standby richiede un disco di avvio separato per poter eseguire il ripristino alla configurazione di un sistema operativo, upgrade, ad esempio. Inoltre, non puoi forzare il collegamento di un disco di avvio a un altro durante un failover.
Le istanze VM principali e in standby sono configurate in modo da utilizzare un bilanciatore del carico il traffico diretto alla VM principale in base agli indicatori del controllo di integrità. La scenario di ripristino di emergenza per i dati delinea altre configurazioni di failover, che potrebbero essere più appropriate il tuo scenario.
Sfide con la replica dei database
La tabella seguente elenca alcuni problemi comuni legati alla configurazione e alla gestione replica sincrona o semisincrona delle applicazioni (come MySQL) e come rispetto alla replica sincrona dei dischi dischi ad alta disponibilità Hyperdisk Balanced (anteprima).
| Sfide | Sincrona dell'applicazione o la replica semisincrona |
Replica sincrona dei dischi |
|---|---|---|
| Mantenimento della replica stabile tra la replica principale e quella di failover. | Potrebbero verificarsi alcuni problemi e potrebbero causare un'istanza VM
per uscire dalla modalità ad alta disponibilità:
|
Gli errori di archiviazione sono gestiti dischi ad alta disponibilità Hyperdisk Balanced. Ciò accade in modo trasparente verso l'applicazione, tranne per una possibile fluttuazione del le prestazioni del disco. Devono essere presenti controlli di integrità definiti dall'utente per individuare eventuali applicazioni o VM dei problemi e attivano il failover. |
| Il tempo di failover end-to-end è più lungo del previsto. | Il tempo impiegato per l'operazione di failover non ha un limite superiore. In attesa della ripetizione di tutte le transazioni (passaggio 2 sopra) potrebbe essere necessario un arbitrariamente lungo, a seconda dello schema e del carico per configurare un database. | i dischi bilanciati con Hyperdisk ad alta disponibilità forniscono di replica, perciò il tempo di failover è limitato dalla somma dei valori seguenti e la latenza minima:
|
| Cervello diviso | Da evitare cervello diviso, entrambi gli approcci richiedono delle disposizioni per garantire che ci sia solo un alla volta. | |
Sequenza di operazioni di lettura e scrittura sui dischi
Determinare le sequenze di lettura e scrittura o l'ordine in cui i dati vengono letti e scritto su disco, la maggior parte del lavoro viene svolta dal driver del disco della VM. Come utente, non devi gestire la semantica della replica, possono interagire con il file system come di consueto. Il driver sottostante gestisce sequenza per la lettura e la scrittura.
Per impostazione predefinita, una VM Disponibilità elevata con Hyperdisk Balanced (anteprima) opera in modalità di replica completa, dove le richieste di lettura o scrittura dal disco vengono inviate a entrambe le repliche.
In modalità di replica completa si verifica quanto segue:
- Durante la scrittura, una richiesta di scrittura tenta di scrivere su entrambe le repliche conferma quando entrambe le scritture hanno esito positivo.
- Durante la lettura, la VM invia una richiesta di lettura a entrambe le repliche e restituisce i risultati da quello che ha esito positivo. Se la richiesta di lettura scade, viene richiesta di lettura inviata.
Se una replica è in ritardo o non riesce a confermare che la lettura o la scrittura richieste completate, stato della replica viene aggiornato.
Controlli di integrità
I controlli di integrità utilizzati e vengono implementati dall'agente controllo di integrità. L'agente per il controllo di integrità ha due scopi:
- L'agente del controllo di integrità si trova all'interno delle VM primarie e secondarie le istanze VM e comunicare con il bilanciatore del carico per indirizzare per via del traffico. Funziona al meglio se viene configurata con gruppi di istanze.
- L'agente del controllo di integrità si sincronizza con il controllo regionale specifico dell'applicazione e prende decisioni di failover in base al comportamento del piano di controllo. La il piano di controllo deve trovarsi in una zona diversa dall'istanza VM di cui sta monitorando lo stato.
L'agente per il controllo di integrità stesso deve essere a tolleranza di errore. Ad esempio, tieni presente che,
nell'immagine che segue, il piano di controllo è separato dalla VM principale
che si trova nella zona us-central1-a, mentre la VM in standby risiede
nella zona us-central1-f.
Passaggi successivi
- Scopri come creare e gestire dischi replicati in modo sincrono.
- Scopri come creare applicazioni web scalabili e resilienti su Google Cloud.
- Consulta la guida alla pianificazione del ripristino di emergenza.