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. I dischi permanenti a livello di area geografica e Hyperdisk Balanced High Availability replicano in modo sincrono i dati tra due zone nella stessa regione e garantiscono l'alta disponibilità per i dati del disco in caso di un massimo di un errore circoscritto a una zona.
Creazione di servizi ad alta disponibilità con dischi replicati
Questa sezione spiega come creare servizi HA con dischi Persistent Disk 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. Queste caratteristiche sono la base del design e possono escludere vari approcci. Ad esempio, se un'applicazione non supporta la replica a livello di applicazione, alcune opzioni di progettazione corrispondenti non sono applicabili.
Analogamente, se l'applicazione, il file system o il sistema operativo non sono tolleranti ai crash, l'utilizzo di dischipermanenti Persistent Disk o Hyperdisk ad alta disponibilità bilanciata (anteprima) o anche di snapshot dei dischi a livello di zona potrebbe non essere un'opzione.La tolleranza agli arresti anomali è definita come la capacità di recuperare da un'interruzione brusca senza perdere o danneggiare i dati già committati su un disco prima dell'arresto anomalo.
Quando progetti per l'alta disponibilità, tieni presente quanto segue:
- L'effetto sull'applicazione dell'utilizzo di Hyperdisk bilanciato con disponibilità elevata, Persistent Disk regionali o altre soluzioni.
- Prestazioni di scrittura sul disco.
- L'obiettivo del tempo di recupero del servizio: la rapidità con cui il servizio deve riprendersi da un'interruzione zonale e i requisiti dell'SLA.
- Il costo per creare un'architettura di servizio resiliente e affidabile.
- Messico, Osaka e Montréal hanno tre zone in uno o due data center fisici. Poiché i dati archiviati in queste regioni possono andare persi nell'improbabile caso in cui i data center vengano distrutti, potresti prendere in considerazione il backup dei dati business-critical in una seconda regione per una protezione dei dati maggiore.
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, il costo totale è determinato dai seguenti elementi:
- Costi delle istanze VM
- Costi diHyperdisk o Persistent Disk
- Costi di gestione della replica delle applicazioni
Utilizza una singola VM con dischi replicati in modo sincrono. Per ottenere un'alta disponibilità con undisco Persistent Disk regionale o un disco Hyperdisk ad alta disponibilità bilanciata , utilizza gli stessi componenti dell'istanza VM e del disco dell'opzione precedente, ma includi anche un disco replicato in modo sincrono.I dischi permanenti regionali e i dischi Hyperdisk ad alta disponibilità con carico bilanciato hanno un costo per byte doppio rispetto ai dischi zonali perché vengono replicati in due 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 ulteriormente i costi dell'host avviando la VM secondaria solo su richiesta durante il failover anziché mantenerla come VM di standby attiva.
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 HA |
Snapshot dei dischi a livello di zona |
Sincrona a livello di applicazione |
Asincrono a livello di applicazione |
Dischi con replica sincrona |
|---|---|---|---|---|
| Protegge da errori di applicazioni, VM e zone1 | ||||
| Mitigazione della corruzione delle applicazioni (esempio: intolleranza agli arresti anomali dell'applicazione) | 2 | 2 | ||
| Costo | $ |
$$
|
$$
|
1,5 volte il prezzo - $$
|
| Prestazioni delle applicazioni |
|
|
|
|
| Adatta per applicazioni con requisiti RPO ridotti (tolleranza molto bassa alla perdita di dati) |
|
|
|
|
| Tempo di recupero dello spazio di archiviazione dopo un disastro4 |
|
|
|
|
1 L'utilizzo di snapshot o dischi replicati non è sufficiente per proteggere da errori e danneggiamenti e per ridurli al minimo. 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, la corruzione dell'applicazione MySQL principale non causa la corruzione anche delle istanze VM di replica. Per maggiori dettagli, 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 controllo del file system, il recupero e il caricamento delle applicazioni dopo il failover.
Creazione di servizi di database ad alta disponibilità utilizzando dischi con replica sincrona
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. A seconda delle tue esigenze, valuta le tecniche di replica tra regioni o la replica asincrona del disco permanente (DP asincrono) 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 i dati del database e qualsiasi altro dato mutabile che deve essere conservato in un'altra zona in caso di 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'altra VM 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 controllo di integrità. Lo scenario di ripristino di emergenza dei dati descrive altre configurazioni di failover, che potrebbero essere più appropriate per il tuo scenario.
Problemi con la replica del database
La tabella seguente elenca alcuni problemi comuni relativi alla configurazione e alla gestione della replica sincrona o semi-sincrona delle applicazioni (come MySQL) e il loro confronto con la replica sincrona dei dischi conRegional Persistent Disk e Hyperdisk Balanced High Availability (anteprima).
| Sfide | Replica sincrona o semi-sincrona dell'applicazione |
Replica sincrona dei dischi |
|---|---|---|
| Mantenimento di una replica stabile tra la replica principale e quella di failover. | Esistono diversi fattori che possono causare un errore e impedire a un'istanza VM di uscire dalla modalità HA:
|
Gli errori di archiviazione vengono gestiti da dischi permanenti regionali e Hyperdisk Balanced ad alta disponibilità. Ciò 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 necessario per l'operazione di failover non ha un limite superiore. L'attesa del replay di tutte le transazioni (passaggio 2 sopra) potrebbe richiedere un tempo arbitrariamente lungo, a seconda dello schema e del carico sul database. | Idischi permanenti regionali e i dischi Hyper-V con disponibilità elevata bilanciata forniscono la replica sincrona, pertanto il tempo di failover è limitato dalla somma delle seguenti latenze:
|
| Cervello diviso | Per evitare il split-brain, entrambi gli approcci richiedono delle disposizioni per garantire che sia presente un solo account principale alla volta. | |
Sequenza di operazioni di lettura e scrittura sui dischi
Per determinare le sequenze di lettura e scrittura o l'ordine in cui i dati vengono letti e scritti sul disco, la maggior parte del lavoro viene eseguita dal driver del disco nella VM. In qualità di utente, non devi occuparti della semantica della replica e puoi interagire con il file system come di consueto. Il driver sottostante gestisce la sequenza per la lettura e la 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 in entrambe le repliche e conferma quando entrambe le scritture vanno a buon fine.
- Durante la lettura, la VM invia una richiesta di lettura a entrambe le repliche e restituisce i risultati di quella che va a buon fine. Se la richiesta di lettura scade, viene inviata un'altra richiesta di lettura.
Se una replica non è aggiornata o non conferma il completamento delle richieste di lettura o scrittura, lo stato della replica viene aggiornato.
Controlli di integrità
I controlli di integrità utilizzati dal bilanciatore del carico vengono implementati dall'agente di controllo di integrità. L'agente di controllo di integrità ha due scopi:
- L'agente di controllo di integrità si trova nelle VM principali e secondarie per monitorare le istanze VM e comunicare con il bilanciatore del carico per indirizzare il traffico. Questo approccio offre risultati ottimali se configurato con gruppi di istanze.
- L'agente di controllo di integrità si sincronizza con il control plane regionale specifico dell'applicazione e prende decisioni di failover in base al comportamento del control plane. Il piano di controllo deve trovarsi in una zona diversa dall'istanza VM la cui integrità sta monitorando.
L'agente di controllo di integrità stesso deve essere tollerante ai guasti. Ad esempio, nell'immagine seguente, il piano di controllo è separato dall'istanza VM principale, che si trova nella zona us-central1-a, mentre la VM di standby si trova nella zona us-central1-f.
Passaggi successivi
- Scopri come creare e gestire i dischi con replica sincrona.
- 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.