Quello che fondamentalente ho bisogno di realizzare nel campo della HADR è un sistema di database che sia, quanto più possibile, sempre disponibile (‘online and accessibile’), completo (‘no data loss) e accurato ( ‘no data corruption). Considerato l’intento di questa discussione, ignorerò le strategie di backup, partendo dall’assunto che esistono principalmente per riportare dei database allo stato precedentemente conosciuto. Ignorerò anche il tema della coerenza dei dati perché la coerenza transazionale ACID dipende largamente dal tipo di database e dal design dell’applicazione. Il concetto alternativo di coerenza (come definito dal teorema CAP di Eric Brewer) è realmente basato sulla sincronizzazione di database replicati, cosa che non riveste grande importanza per me , visto che sono principalmente interessato a proteggere un database master.
I database possono diventare indisponibili per motivi programmati (aggiornamento e manutenzione) o per ragioni non programmate, dovute al malfunzionamento di qualche componente del sistema (che possono interessare un disco rigido o un intero data center). Un’infrastruttura ad alta disponibilità deve essere studiata per fare fronte a tutti i possibili guasti del sistema, spaziando da componenti con tolleranza alle interruzioni per finire con i piani di disaster ricovery. Quanto più queste potenzialità sono incluse nella piattaforma, tanto più il mio lavoro risulterà facile e sarà meno probabile che debba fare compromessi al ribasso con gli altri requisiti di sistema.
Nel corso degli ultimi anni, ho ideato e sviluppato soluzioni di database in cloud, ibride e on-premise, con distribuzioni cloud sia ai database SQL di Azure (PaaS) che ai server SQL operanti in Azure VM (IaaS). Ho dovuto affrontare sfide non da poco quando si è trattato di architettare soluzioni di disaster recovery. La buona notizia è che, nel frattempo, ho assistito alla crescita progressiva e al miglioramento delle funzioni ad alta disponibilità in Azure. In particolare, le funzioni di geo-restore e geo-replication dei nuovi livelli di servizio del database SQL di Azure che sono state introdotte l’anno scorso.
A questo punto vi potrei fornire una lunga lista delle potenzialità dei database SQL di Azure confrontate con quelle del server SQL in Azure VM. Per quanto si tratti di informazioni appetibili, sono facilmente reperibili online. Quello che invece voglio fare, è esporre le mie personali osservazioni volte a chiarire se siano bastate le differenze nelle funzioni ad alta disponibilità a influenzare la mia scelta tra piattaforma o architettura.
So che, nel mondo reale, la scelta della piattaforma probabilmente sarà influenzata da diversi fattori, quali costi, problemi di sicurezza o funzionalità di sviluppo. Ma vorrei richiamare l’attenzione sul fatto che requisiti soddisfacenti di alta disponibilità dovrebbero essere tra i primi fattori da tenere in conto nel prendere le decisioni, non gli ultimi.
Le opzioni ad alta disponibilità per SQL Server operante in Azure VM sono fondamentalmente le stesse degli omologhi on-premise. Per quanto riguarda SQL Server on-premise, io raccomanderei sempre AlwaysOn Availability Groups, e lo stesso discorso vale per SQL Server in Azure. Ora che Azure supporta connessioni network virtuali, possiamo collocare delle repliche in diverse regioni ai fini del disaster recovery.
Dunque, i server SQL in un AlwaysOn Avaialbility Group spostati in Azure rispondono ai requisiti di alta disponibilità? Bene, si e no. La replicazione su un data center remoto in Azure garantisce il disaster recovery da un data center fuori servizio, ma richiede la modalità commit per essere asincrona e consentire la latenza di rete. Le implicazioni sono che il failover non può essere automatico e sussiste il pericolo di perdita di dati (sebbene ridotta) tra le repliche primarie e secondarie. L’altro appunto che devo fare è che il failover verso un altro data center dovrebbe essere l’ultima ratio, perché impatta su tutta l’applicazione. Dal momento che Azure VM non integra alcuna tolleranza alle interruzioni, dobbiamo ricorrere a database in replica per il rispristino a seguito di una larga gamma di guasti.
Al confronto, la geo-replication attiva, che è disponibile per i database SQL di Azure, edizione premium, sembra fornire una funzionalità simile a AlwaysOn Availability Groups. Entrambi eseguono la replicazione sincrona di transazioni in altre regioni di Azure, offrono l’opzione di repliche secondarie leggibili, e consentono il failover manuale. Vale la pena di sottolineare che geo-replication usa un buffer per archiviare le transazioni in attesa di essere replicate. La mia esperienza è che si adatta meglio a un gran numero di piccole transazioni che a un piccolo numero di grandi transazioni che possono intasare il buffer.
Il punto sul quale i database SQL di Azure offrono un vantaggio è la loro architettura tollerante alle interruzioni, basata su repliche locali in diversi domini domini di errore con rilevamento automatico dell’inconveniente e failover. Questa potenzialità integrata protegge automaticamente il database dalla maggior parte dei guasti, ad eccezione della perdita del data center. Per la tolleranza alle interruzioni con il server SQL, Microsoft raccomanda di inserire tutte le macchine virtuali per livelli di dati in un set di disponibilità, che dovrebbe contenere almeno due macchine virtuali per assicurare che almeno una sia disponibile durante interventi di manutenzione programmata o non programmata. Benché ogni set di disponibilità contenga due domini dedicati ai guasti e fino a 5 domini dedicati all’aggiornamento, nessuno di questi garantisce una disponibilità ininterrotta delle vostre macchine virtuali che ospitano SQL Server nel caso di guasto a livello locale.
Un altro punto a favore del database SQL di Azure è la semplicità dal punto di vista amministrativo. Microsoft recentemente si è impegnata per rendere più agevole l’approvvigionamento e l’amministrazione delle macchine virtuali che ospitano SQL Server in Azure con backup automatici, patch automatico e maggiori immagini di macchine virtuali (inclusa AlwaysOn). In ogni caso, nessuna di esse si avvicina al vantaggio che deriva dall’attivazione della geo-replication per i database SQL di Azure e alla sicurezza offerta dall’integrazione della tolleranza all’interruzione.
Allora, in conclusione, se non ci sono altre considerazioni, mi sentirei davvero di affermare che i database SQL di Azure per implementazioni nel cloud soddisfano i requisiti di continuità del business che mi stanno a cuore.
Come post scriptum, vorrei sottolineare che, mentre per me è stato un piacere avere la possibilità di ideare, implementare e testare soluzioni ad alta disponibilità, in nessuna di esse finora si sono registrati dei guasti, così non sono in grado di documentare il comportamento nella realtà in caso di failover in emergenza