Disponibilità elevata in Azure HorizonDB (anteprima)

Per i carichi di lavoro cruciali, ridurre al minimo i tempi di inattività e prevenire la perdita di dati sono requisiti essenziali. In Azure HorizonDB, l'alta disponibilità viene ottenuta tramite una combinazione di archiviazione resiliente alla zona, repliche di calcolo distribuite e meccanismi di failover automatizzati.

Panoramica della disponibilità elevata

A differenza delle distribuzioni PostgreSQL tradizionali che si basano sulla replica di streaming tra server indipendenti, Azure HorizonDB usa un'architettura nativa del cloud che separa il calcolo e l'archiviazione. Questa architettura cambia il modo in cui funziona il failover eliminando la necessità di riavvolgere il WAL (write-ahead log) o della reinizializzazione del primario dopo il failover, riducendo così il tempo di failover.

Calcolo delle repliche

La disponibilità elevata a livello di calcolo richiede almeno 2 repliche di calcolo. Le repliche di calcolo fungono sia da destinazioni per la scalabilità in lettura che da candidati per il failover.

Un cluster HorizonDB è costituito da:

• Una replica primaria (lettura/scrittura)
• Una o più repliche a disponibilità elevata di lettura

Quando si aggiunge una replica, il sistema lo inserisce automaticamente in un'altra zona di disponibilità quando l'area supporta più zone. Questa posizione fornisce l'isolamento degli errori a livello di zona a livello di calcolo.

Storage a ridondanza zonale

A differenza della tradizionale replicazione di PostgreSQL, Azure HorizonDB non esegue lo streaming del WAL dal nodo primario alle repliche standby per garantire la durabilità dei dati. L'architettura si basa invece su un livello di archiviazione condiviso:

• Il servizio WAL con ridondanza della zona condiviso tra tutte le repliche di calcolo.
• La flotta di archiviazione dei dati con ridondanza della zona che applica in modo asincrono il WAL dal servizio WAL.
• Archiviazione BLOB di Azure con ridondanza di zona che garantisce la durabilità sottostante sia dei dati che dell'archiviazione WAL.

Processo di failover

Il failover è il processo con cui una replica in standby viene promossa a nuovo primario quando il primario corrente non è più disponibile. Azure HorizonDB supporta sia il failover automatico che quello pianificato.

Failover automatico (non pianificato)

Il failover automatico si verifica quando la replica di calcolo primaria non è più disponibile a causa di un evento imprevisto, ad esempio:

• Errore hardware nella zona di disponibilità che ospita il database primario
• Partizioni di rete che interessano la replica primaria
• Guasti a livello di sistema operativo o di processo sul primario

Quando il servizio rileva che il database primario non è disponibile, avvia la sequenza seguente:

1. Rilevamento : la piattaforma rileva l'errore in base ai segnali di integrità della replica.
2. Isolamento: isolare il primario in modo che non vengano effettuate ulteriori scritture.
3. Promozione: viene selezionata una replica in standby in una zona di disponibilità integra e viene promossa come primaria. Se sono presenti più repliche, quella più vicina all'LSN della replica primaria viene scelta come destinazione di failover.
4. Attendere la promozione - attendere finché il database sia scrivibile.
5. Aggiornamento dell'endpoint: l'endpoint di lettura/scrittura viene aggiornato in modo da puntare al primario appena alzato di livello.
6. Riconnessione client : le connessioni client al database primario precedente vengono eliminate. Le applicazioni si riconnettono tramite l'endpoint di lettura/scrittura, che ora indirizza al nuovo database primario.

Failover pianificato

Un failover pianificato è un'operazione controllata avviata dall'utente o dalla piattaforma. Un failover pianificato viene utilizzato per verificare l'alta disponibilità. Inoltre, il servizio avvia il failover pianificato durante le operazioni di manutenzione, ad esempio:

• Aggiornamenti di versione minore
• Patch di sicurezza

Durante un failover pianificato, il servizio segue una sequenza controllata:

1. Scelta della replica - Il failover pianificato avviato dall'utente può specificare la replica verso cui eseguire il failover e tale replica diventa la destinazione del failover.
2. Isolamento: isolare il primario in modo che non vengano effettuate ulteriori scritture.
3. Promozione: il servizio promuove lo standby selezionato a nuovo primario
4. Aggiornamento dell'endpoint: l'endpoint di lettura e scrittura passa al nuovo primario.

I failover pianificati vengono in genere completati più velocemente dei failover non pianificati perché non è necessario alcun rilevamento.

failover forzato

Un failover forzato può essere attivato da un utente per alzare immediatamente di livello una replica impostandola come primaria senza attendere una transizione coordinata. Un failover forzato è simile alla logica di un failover automatico, ma viene avviato da un utente.

Durabilità dei dati durante il failover

Azure HorizonDB garantisce che le transazioni di cui è stato eseguito il commit non andranno perse durante il failover. Il servizio WAL mantiene tutte le transazioni di cui è stato eseguito il commit in modo permanente tra le zone prima di riconoscerlo al client. Poiché tutte le repliche leggono dalla stessa archiviazione persistente, lo standby promosso ha accesso a ogni scrittura confermata.

Le transazioni in corso ma non ancora confermate al momento del failover vengono annullate, in modo coerente con il comportamento ACID standard di PostgreSQL.

Considerazioni sull'applicazione

Per sfruttare al meglio la disponibilità elevata in Azure HorizonDB, prendere in considerazione le procedure a livello di applicazione seguenti:

• Implementare la logica di ripetizione dei tentativi di connessione : usare il backoff esponenziale con nuovi tentativi in caso di errori di connessione temporanei. La maggior parte delle librerie client e dei framework PostgreSQL supporta la configurazione automatica dei tentativi.
• Usare gli endpoint : connettersi sempre tramite endpoint di lettura/scrittura o di sola lettura anziché direttamente a repliche specifiche. Gli endpoint vengono instradati automaticamente verso la replica corretta dopo un failover.
• Evitare transazioni di lunga durata - Le transazioni lunghe ritardano il completamento del failover pianificato e aumentano il rischio di rollback durante il failover non pianificato.
• Non archiviare lo stato negli spazi di tabella temporanei : gli oggetti temporanei non vengono mantenuti tra gli eventi di failover. Evitare di creare oggetti schema utente in spazi di tabella temporanei.

Contenuti correlati

• Panoramica della continuità aziendale in Azure HorizonDB (anteprima)
• Configurare la disponibilità elevata in Azure HorizonDB (anteprima)
• Eseguire il failover in Azure HorizonDB (Anteprima)
• Backups in Azure HorizonDB (anteprima)