Disco permanente a livello di regione è un'opzione di archiviazione che consente di implementare servizi ad alta disponibilità in Compute Engine. Il disco permanente regionale replica in modo sincrono i dati tra due zone nella stessa regione e garantisce l'alta disponibilità per i dati del disco per un massimo di un errore a livello di zona.
Questo documento spiega come utilizzare Persistent Disk a livello di regione per creare servizi ad alta disponibilità.
Creazione di servizi ad alta disponibilità con Persistent Disk a livello di regione
Questa sezione spiega come creare servizi ad alta disponibilità con Persistent Disk a livello di regione.
Note sul layout
Prima di iniziare a progettare un servizio ad alta disponibilità, occorre comprendere le caratteristiche dell'applicazione, del file system e del sistema operativo. Queste caratteristiche costituiscono la base della progettazione 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 compatibili con gli arresti anomali, l'utilizzo di dischi permanenti a livello di regione o persino di snapshot di dischi permanenti a livello di zona potrebbe non essere un'opzione. La tolleranza agli arresti anomali è definita come la capacità di eseguire il ripristino in seguito a una terminazione brusca senza perdere o danneggiare i dati di cui era già stato eseguito il commit su un disco permanente prima dell'arresto anomalo.
Quando progetti per l'alta disponibilità, tieni presente quanto segue:
- L'effetto dell'utilizzo di dischi permanenti a livello di regione o di altre soluzioni sulle prestazioni di scrittura di applicazioni e dischi.
- Il Service Recovery Time Objective. Scopri la velocità con cui il tuo servizio deve recuperare da un'interruzione 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, le seguenti opzioni sono per la replica di applicazioni sincrone e asincrone:
Utilizza due istanze del database e della VM. In questo caso, il costo totale è determinato dalle seguenti voci:
- Costi delle istanze VM
- Costi dei dischi permanenti
- Costi di mantenimento della replica delle applicazioni
Utilizza una singola VM con dischi permanenti a livello di regione. Per ottenere l'alta disponibilità con un disco permanente a livello di regione, utilizza la stessa istanza VM e gli stessi componenti del disco permanente, ma includi anche un disco permanente a livello di regione. I dischi permanenti a livello di regione costano il doppio del costo per byte rispetto ai dischi permanenti a livello di zona perché sono replicati in due zone.
Tuttavia, l'utilizzo di dischi permanenti a livello di regione potrebbe ridurre i costi di manutenzione perché i dati vengono replicati automaticamente in due repliche senza il requisito di mantenere la replica dell'applicazione.
Non avviare la seconda VM finché non è richiesto il failover. Puoi ridurre ulteriormente i costi dell'host avviando la VM di backup solo on demand durante il failover anziché mantenerla in modalità standby a caldo.
Confronta costi, prestazioni e resilienza
La seguente tabella evidenzia i compromessi in termini di costi, prestazioni e resilienza per le diverse architetture di servizio.
| Architettura del servizio ad alta disponibilità |
Snapshot di disco permanente a livello di zona |
sincrona a livello di applicazione |
Asincrona a livello di applicazione |
Soluzione ad alta disponibilità utilizzando un disco permanente a livello di regione |
|---|---|---|---|---|
| Protezione da errori di applicazioni, VM e zone1 | ||||
| Mitigazione del danneggiamento delle applicazioni (ad esempio: intolleranza agli arresti anomali dell'applicazione) | 2 | 2 | ||
| Costo | $ |
$$
|
$$
|
1,5 $ x 1,5 $
|
| Prestazioni delle applicazioni |
|
|
|
|
| Adatto per applicazioni con requisiti RPO ridotti (tolleranza molto bassa per la perdita di dati) |
|
|
|
|
| Tempo di ripristino dello spazio di archiviazione in caso di emergenza4 |
|
|
|
|
1 L'utilizzo di dischi permanenti o snapshot a livello di regione non è sufficiente per proteggere e mitigare da errori e danneggiamenti. L'applicazione, il file system ed eventualmente altri componenti software devono essere coerenti o utilizzare una sorta di quiescing.
2 La replica di alcune applicazioni riduce alcune danneggiamenti delle applicazioni. Ad esempio, il danneggiamento dell'applicazione principale di MySQL non determina il danneggiamento anche delle relative istanze VM di replica. Per informazioni dettagliate, consulta la documentazione della tua applicazione.
3 Per perdita di dati si intende la perdita non recuperabile dei dati impegnati nell'archiviazione permanente. I dati di cui non è stato eseguito il commit andranno comunque persi.
4 Le prestazioni del failover non includono il controllo del file system, il recupero e il caricamento dell'applicazione dopo il failover.
crea servizi di database ad alta disponibilità utilizzando dischi permanenti a livello di regione
Questa sezione tratta concetti ad alto livello per la creazione di soluzioni ad alta disponibilità per servizi di database stateful (MySQL, Postgres e così via) utilizzando dischi permanenti a livello di regione e Compute Engine.
Se si verificano interruzioni di servizio ampie in Google Cloud, ad esempio se un'intera regione diventa non disponibile, la tua applicazione potrebbe non essere più disponibile. A seconda delle tue esigenze, prendi in considerazione le tecniche di replica tra regioni per una disponibilità ancora maggiore.
Le configurazioni ad alta disponibilità del database hanno in genere 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 primaria ha almeno due dischi permanenti: un disco di avvio e un disco permanente a livello di regione. Il disco permanente a livello di regione contiene i dati del database e tutti gli altri dati modificabili che devono essere conservati in un'altra zona in caso di interruzione.
Un'istanza VM in standby richiede un disco di avvio separato per il ripristino in seguito a interruzioni legate alla configurazione, che potrebbero derivare, ad esempio, da un upgrade del sistema operativo. Non puoi forzare il collegamento di un disco di avvio a un'altra VM durante un failover.
Le istanze VM principali e in standby sono configurate per utilizzare un bilanciatore del carico con il traffico indirizzato alla VM principale in base agli indicatori del controllo di integrità. Questa configurazione è anche nota come hot standby. Lo scenario di ripristino di emergenza per i dati descrive altre configurazioni di failover, che potrebbero essere più appropriate per il tuo scenario.
Challenge con replica dei database
La seguente tabella elenca alcune sfide comuni relative alla configurazione e alla gestione della replica sincrona o semi-sincrona delle applicazioni (come MySQL) e delle differenze rispetto alla replica a blocchi con dischi permanenti a livello di regione.
| sfide | Replica sincrona o semisincrona dell'applicazione |
Blocca la replica con dischi permanenti a livello di regione |
|---|---|---|
| Mantenimento della replica stabile tra la replica principale e quella di failover. | Potrebbero verificarsi una serie di problemi che potrebbero causare l'uscita dalla modalità ad alta disponibilità di un'istanza VM:
|
Gli errori di archiviazione sono gestiti dai dischi permanenti a livello di regione. Ciò avviene in modo trasparente per l'applicazione, tranne per una possibile fluttuazione delle prestazioni del disco. Devono essere previsti controlli di integrità definiti dall'utente per rilevare eventuali problemi dell'applicazione o della 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. L'attesa della riproduzione di tutte le transazioni (passaggio 2 precedente) potrebbe richiedere arbitrariamente un tempo prolungato, a seconda dello schema e del carico sul database. | I dischi permanenti a livello di regione forniscono la replica sincrona, perciò il tempo di failover è vincolato dalla somma delle seguenti latenze:
|
| Cervello divisa | Per evitare lo split-brain, entrambi gli approcci richiedono provisioning per garantire che ne sia presente un solo elemento principale alla volta. | |
Controlli di integrità
I controlli di integrità utilizzati dal bilanciatore del carico vengono implementati dall'agente per il controllo di integrità. L'agente per il controllo di integrità ha due scopi:
- L'agente per il controllo di integrità si trova all'interno delle VM primarie e secondarie per monitorare le istanze VM e comunicare con il bilanciatore del carico per indirizzare il traffico. Questa opzione funziona al meglio se configurata con gruppi di istanze.
- L'agente per il controllo di integrità si sincronizza con il piano di controllo a livello di regione 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 di cui sta monitorando l'integrità.
Lo stesso agente per il controllo di integrità deve essere a tolleranza di errore. Ad esempio, nota che, nell'immagine che segue, il piano di controllo è separato dall'istanza VM principale, che si trova nella zona us-central1-a, mentre la VM in standby si trova nella zona us-central1-f.
Passaggi successivi
- Scopri come creare e gestire Persistent Disk a livello di regione.
- Scopri come creare applicazioni web scalabili e resilienti su Google Cloud.
- Consulta la guida alla pianificazione del ripristino di emergenza.