I dischi permanenti regionali e Hyperdisk Balanced High Availability sono opzioni di archiviazione che ti consentono di implementare servizi ad alta disponibilità (HA) in Compute Engine. Disco permanente regionale e Hyperdisk con disponibilità elevata bilanciata in modo sincrono replicare i dati tra due zone nella stessa regione e garantire l'alta disponibilità per il disco per un massimo di un errore a livello di zona.
Creazione di servizi ad alta disponibilità con dischi replicati
Questa sezione spiega come creare servizi HA con dischi permanenti regionali o Hyperdisk bilanciati con disponibilità elevata.
Note sul layout
Prima di iniziare a progettare un servizio HA, 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 disco Persistent Disk di regione 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.
Quando progetti per l'alta disponibilità, tieni presente quanto segue:
- L'effetto sull'applicazione dell'uso Disponibilità elevata Hyperdisk Bilanciata, un disco permanente regionale o altre soluzioni
- Prestazioni di scrittura del disco
- L'obiettivo del tempo di recupero del servizio: la velocità con cui il servizio deve riprendersi da un'interruzione zonale e i requisiti dell'SLA
- Il costo per creare un'architettura di servizi resiliente e affidabile
In termini di costi, utilizza le seguenti opzioni per la replica delle applicazioni sincrona e asincrona:
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 gestione della replica delle applicazioni
Utilizza una singola VM con dischi replicati in modo sincrono. Per raggiungere la disponibilità con un regionale Persistent Disk o disco a disponibilità elevata con bilanciato 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 permanenti a livello di regione e i dischi ad alta disponibilità bilanciati con Hyperdisk hanno il doppio a livello di zona, perché vengono replicati zone.
Tuttavia, l'utilizzo di dischi con replica sincrona potrebbe ridurre il costo di manutenzione perché i dati vengono scritti automaticamente in due repliche senza che sia necessario mantenere la replica dell'applicazione.
Non avviare la VM secondaria finché non è necessario 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 tabella seguente mette in evidenza i compromessi in termini di costi, prestazioni e resilienza per le diverse architetture di servizio.
| Architettura del servizio ad alta disponibilità |
Snapshot dei dischi a livello di zona |
Sincrona a livello di applicazione |
Asincrona a livello di applicazione |
Dischi replicati sincrono |
|---|---|---|---|---|
| Protegge da errori di applicazioni, VM e 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 e, eventualmente, altri componenti software devono essere coeerenti in caso di arresto anomalo o utilizzare una sorta di quiescenza.
2 La replica di alcune applicazioni consente di attenuare alcuni problemi di corruzione delle applicazioni. Ad esempio, MySQL principale il danneggiamento dell'applicazione non fa sì che le istanze VM di replica diventino corrotti. Per informazioni dettagliate, consulta la documentazione dell'applicazione.
3 Per perdita di dati si intende la perdita non recuperabile di dati committati nell'archiviazione permanente. Tutti i dati non sottoposti a commit andranno 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 illustra i concetti di alto livello per la creazione di soluzioni HA per servizi di database stateful (MySQL, Postgres e così via) che utilizzano Compute Engine con dischi permanenti regionali e dischi Hyperdisk bilanciati ad alta disponibilità (anteprima).
Se si verificano interruzioni generali in Google Cloud, ad esempio se un'intera regione diventa non disponibile, la tua applicazione potrebbe non essere disponibile. In base a le tue esigenze, considera tecniche di replica tra regioni o Replica asincrona del disco permanente (replica PD asincrona) per una disponibilità ancora maggiore.
Le configurazioni HA del database hanno in genere almeno due istanze VM. È preferibile che queste istanze VM facciano parte di uno o più gruppi di istanze gestite:
- Un'istanza VM principale nella zona principale
- Un'istanza VM di standby in una zona secondaria
Un'istanza VM principale ha almeno due dischi: un disco di avvio e un 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 di riserva richiede un disco di avvio separato per poter recuperare da interruzioni correlate alla configurazione, ad esempio a seguito di un upgrade del sistema operativo. Inoltre, non puoi forzare il collegamento di un disco di avvio a un altro durante un failover.
Le istanze VM principali e di riserva sono configurate per utilizzare un bilanciatore del carico con il traffico indirizzato alla VM principale in base agli indicatori dei controlli 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 Disco permanente regionale e dischi ad alta disponibilità Hyperdisk Balanced (anteprima).
| Sfide | Replica sincrona o semi-sincrona dell'applicazione |
Replica sincrona dei dischi |
|---|---|---|
| Mantenimento della replica stabile tra la replica principale e quella di failover. | Potrebbero verificarsi diversi problemi e potrebbero causare un'istanza VM
per uscire dalla modalità ad alta disponibilità:
|
Gli errori di archiviazione sono gestiti Disco permanente regionale e dischi ad alta disponibilità Hyperdisk Balanced. Questo avviene in modo trasparente per l'applicazione, tranne per una possibile fluttuazione del rendimento del disco. Devono essere presenti controlli di integrità definiti dall'utente per rilevare eventuali problemi relativi all'applicazione o alla VM e attivare 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. | A livello di regione Persistent Disk e i dischi bilanciati con Hyperdisk ad alta disponibilità forniscono di replica, perciò il tempo di failover è limitato dalla somma dei seguenti fattori e la latenza minima:
|
| Cervello diviso | Per evitare il problema del cervello diviso, entrambi gli approcci richiedono delle disposizioni per garantire che sia presente un solo canale principale 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 la sequenza di lettura e scrittura.
Per impostazione predefinita, una VM Compute Engine con Regional Persistent Disk o Hyperdisk Balanced High Availability (Preview) funziona in modalità di replica completa, in cui 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. Questo approccio offre risultati ottimali se configurato 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. Il piano di controllo deve trovarsi in una zona diversa dall'istanza VM dell'integrità della quale sta monitorando.
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 di più sulla replica asincrona dei dischi permanenti.
- Scopri come creare applicazioni web scalabili e resilienti su Google Cloud.
- Consulta la guida alla pianificazione del ripristino di emergenza.