Esplorare le opzioni di disponibilità elevata e ripristino di emergenza
Prima di ideare una soluzione per le macchine virtuali, è necessario conoscere le opzioni di disponibilità per le distribuzioni basate su IaaS.
IaaS e PaaS a confronto
In termini di disponibilità, la scelta tra IaaS (Infrastructure as a Service, infrastruttura distribuita come servizio) e PaaS (Platform as a Service, piattaforma distribuita come servizio) fa la differenza. Con IaaS, è disponibile una macchina virtuale, ovvero è presente un sistema operativo con un'installazione di SQL Server. L'amministratore o il gruppo responsabile di SQL Server ha a disposizione un'ampia gamma di soluzioni di disponibilità elevata e ripristino di emergenza (HADR) e un notevole controllo sulla modalità di configurazione della soluzione prescelta.
Con le distribuzioni basate su PaaS, ad esempio il database SQL di Azure, le soluzioni HADR sono incorporate nella funzionalità e spesso devono essere semplicemente abilitate. Le opzioni che è possibile configurare sono minime.
A causa di queste differenze, la scelta tra IaaS e PaaS può influire sulla progettazione finale della soluzione HADR.
Funzionalità HADR di SQL Server per le macchine virtuali di Azure
Quando si usa una distribuzione IaaS, è possibile usare le funzionalità offerte da SQL Server per aumentare la disponibilità. In alcuni casi, queste possono essere combinate con funzionalità di livello Azure per aumentare ulteriormente la disponibilità.
Nella tabella seguente sono illustrate le funzionalità disponibili in SQL Server.
| Nome funzionalità | Protegge |
|---|---|
| Istanza del cluster di failover Always On | Istanza |
| Gruppo di disponibilità Always On | Database |
| Log shipping | Database |
Un'istanza di SQL Server è costituita dall'intera installazione di SQL Server (file binari, tutti gli oggetti all'interno dell'istanza, inclusi elementi quali account di accesso, processi di SQL Server Agent e database). Fornire protezione a livello di istanza significa considerare l'intera istanza ai fini della disponibilità.
Un database in SQL Server contiene i dati usati dagli utenti finali e dalle applicazioni. Vi sono database di sistema su cui si basa SQL Server e database creati da utenti finali e applicazioni. Un'istanza di SQL Server dispone sempre di specifici database di sistema. Fornire protezione a livello di database significa che tutti i dati presenti nel database o quelli acquisiti nel log delle transazioni per il database di un utente o di un'applicazione vengono considerati come parte della funzionalità di disponibilità. Qualsiasi elemento presente all'esterno del database, o non acquisito come parte del log delle transazioni, ad esempio i processi di SQL Server Agent e i server collegati, deve essere gestito manualmente per assicurare che il server di destinazione possa funzionare come primario nel caso di un evento di failover pianificato o non pianificato.
Sia le istanze del cluster di failover sia i gruppi di disponibilità richiedono un meccanismo di cluster sottostante. Per le distribuzioni di SQL Server in esecuzione in Windows Server, questo meccanismo è costituito da Cluster di failover di Windows Server (WSFC, Windows Server Failover Cluster), mentre per quelle di Linux viene usato Pacemaker.
Istanze del cluster di failover AlwaysOn
Un'istanza del cluster di failover viene configurata al momento dell'installazione di SQL Server. Non è possibile convertire un'istanza del cluster di failover in un'istanza autonoma di SQL Server. A un'istanza del cluster di failover viene assegnato un nome univoco, oltre che un indirizzo IP diverso dai server, o nodi, sottostanti che partecipano al cluster. Anche il nome e l'indirizzo IP devono essere diversi dal meccanismo del cluster sottostante. Le applicazioni e gli utenti finali useranno il nome univoco dell'istanza del cluster di failover per l'accesso. Questa astrazione consente alle applicazioni di non dover conoscere la posizione in cui viene eseguita l'istanza. Una differenza importante tra le istanze del cluster di failover basate su Azure e quelle locali è che per Azure è necessario un servizio di bilanciamento del carico interno. Questo servizio viene usato per assicurare che le applicazioni e gli utenti finali possano connettersi al nome univoco dell'istanza del cluster di failover.
Quando si esegue il failover di un'istanza del cluster di failover in un altro nodo di un cluster, avviato manualmente o in seguito a un problema, l'intera istanza viene riavviata in un altro nodo. Ciò significa che il processo di failover consiste in un arresto e in un avvio completi di SQL Server. Le applicazioni o gli utenti finali connessi all'istanza del cluster di failover verranno disconnessi durante il failover e solo le applicazioni che possono gestire questa interruzione ed essere ripristinate verranno riconnesse automaticamente.
All'avvio sull'altro nodo, l'istanza viene sottoposta al processo di ripristino. L'istanza del cluster di failover sarà coerente con il punto di guasto e quindi, tecnicamente, non si verificherà alcuna perdita di dati, ma tutte le transazioni di cui è necessario eseguire il rollback faranno parte del ripristino. Come notato in precedenza, poiché si tratta di una protezione a livello di istanza, è già presente tutto ciò che è necessario (account di accesso, processi di SQL Server Agent e così via) in modo che le attività possano riprendere normalmente quando i database sono pronti.
Le istanze del cluster di failover richiedono una singola copia di un database, ma questo è anche il singolo punto di guasto. Per assicurarsi che un altro nodo possa accedere al database, le istanze del cluster di failover richiedono un sistema di archiviazione condivisa. Per le architetture basate su Windows Server, questo è possibile tramite una condivisione file Premium di Azure, iSCSI, un disco condiviso di Azure, Spazi di archiviazione diretta (S2D) o una soluzione di terze parti supportata, come SIOS DataKeeper. Le istanze del cluster di failover con l'edizione Standard di SQL Server possono avere al massimo due nodi. Per il loro funzionamento è inoltre necessario l'uso di Active Directory Domain Services e DNS (Domain Name Services), che devono quindi essere implementati in un punto qualsiasi di Azure.
Con Windows Server 2016 o versioni successive, le istanze del cluster di failover possono usare Replica archiviazione per creare una soluzione di ripristino di emergenza nativa senza dover usare un'altra funzionalità, come il log shipping o i gruppi di disponibilità.
Gruppi di disponibilità AlwaysOn
I gruppi di disponibilità sono stati introdotti nell'edizione Enterprise di SQL Server 2012 e, a partire da SQL Server 2016, sono disponibili anche nell'edizione Standard. Nell'edizione Standard un gruppo di disponibilità può contenere un solo database, mentre nell'edizione Enterprise un gruppo di disponibilità può avere più database. I gruppi di disponibilità presentano alcune analogie con le istanze del cluster di failover, ma nella maggior parte dei casi sono diversi.
La differenza principale tra un'istanza del cluster di failover e un gruppo di disponibilità è data dal fatto che i gruppi di disponibilità forniscono protezione a livello di database. La replica primaria è l'istanza che partecipa a un gruppo di disponibilità contenente i database di lettura/scrittura. Una replica secondaria è la replica a cui quella primaria invia transazioni attraverso il trasporto del flusso di log per mantenerla sincronizzata. Lo spostamento dei dati di una replica primaria può essere sincrono o asincrono. I database in una replica secondaria si trovano in stato di caricamento, ovvero possono ricevere transazioni, ma non possono essere una copia completamente scrivibile finché la replica non diventa primaria. Un gruppo di disponibilità nell'edizione Standard può avere al massimo due repliche (una primaria, una secondaria), mentre nell'edizione Enterprise sono supportate fino a nove repliche (una primaria e otto secondarie). Una replica secondaria viene inizializzata da un backup del database o, a partire da SQL Server 2016, è possibile usare una funzionalità denominata "seeding automatico". Il seeding automatico usa il trasporto del flusso di log per trasmettere il backup alla replica secondaria per ogni database del gruppo di disponibilità usando gli endpoint configurati.
Un gruppo di disponibilità fornisce astrazione con il listener, che funziona come il nome univoco assegnato a un'istanza del cluster di failover e ha un nome e un indirizzo IP diversi da qualsiasi altro elemento (WSFC, nodo e così via). Il listener richiede anche un servizio di bilanciamento del carico interno e passa attraverso un processo di arresto e avvio. Le applicazioni e gli utenti finali possono usare il listener per connettersi, ma a differenza di un'istanza del cluster di failover, l'uso del listener non è obbligatorio. Sono possibili anche connessioni dirette all'istanza. Con l'edizione Enterprise, le repliche secondarie possono anche essere configurate per l'accesso in sola lettura, se necessario, e possono essere usate per altre funzionalità, ad esempio le verifiche di coerenza del database e i backup.
I gruppi di disponibilità possono avere tempi di failover più rapidi rispetto a un'istanza del cluster di failover, e questo è uno dei motivi per cui sono oggetto di particolare interesse. Se da un lato i gruppi disponibilità non richiedono l'archiviazione condivisa, dall'altro ogni replica dispone di una copia dei dati, con il conseguente aumento del numero totale di copie del database e dei costi di archiviazione complessivi. Le risorse di archiviazione sono locali per ogni replica. Se, ad esempio, il footprint di dati dei database nella replica primaria è 1 TB, anche ogni replica avrà lo stesso footprint. Se sono presenti cinque repliche, saranno necessari 5 TB di spazio.
È opportuno tenere presente che qualsiasi oggetto presente al di fuori del database, o non acquisito nel log delle transazioni del database, deve essere creato manualmente e preso in considerazione per qualsiasi altra istanza di SQL Server, nel caso in cui tale istanza diventi la nuova replica primaria. Tra gli oggetti da considerare sono inclusi i processi di SQL Server Agent, gli account di accesso a livello di istanza e i server collegati. Se con i gruppi di disponibilità è possibile usare l'autenticazione di Windows o database indipendenti, l'accesso risulterà più semplice.
Molte organizzazioni possono trovarsi ad affrontare problemi durante l'implementazione di architetture a disponibilità elevata e possono aver bisogno solo della disponibilità elevata fornita dalla piattaforma Azure, oppure di una soluzione PaaS come Istanza gestita di SQL di Azure. Prima di esaminare le soluzioni offerte dalla piattaforma Azure, è necessario conoscere un'altra funzionalità di SQL Server: il log shipping.
Log shipping
Il log shipping è una funzionalità usata fin dai primi tempi di SQL Server ed è basata sui processi di backup, copia e ripristino. Si tratta di uno dei metodi più semplici per ottenere disponibilità elevata e ripristino di emergenza per SQL Server. Il log shipping viene usato principalmente per il ripristino di emergenza, ma può anche essere usato per migliorare la disponibilità locale.
Come i gruppi di disponibilità, il log shipping fornisce protezione a livello di database, e questo significa che è comunque necessario tenere conto dei processi di SQL Server Agent, dei server collegati, degli account di accesso a livello di istanza e così via. Il log shipping non fornisce alcuna astrazione in modo nativo e quindi il passaggio a un altro server che partecipa al log shipping deve essere in grado di tollerare una modifica del nome. Se questo non è possibile, si possono configurare metodi come un alias DNS a livello di rete per tentare di attenuare i problemi di modifica del nome.
Il meccanismo del log shipping è semplice: si esegue prima un backup completo del database di origine nel server primario e quindi si ripristina il database in stato di caricamento (STANDBY o NORECOVERY) in un'altra istanza definita server secondario o warm standby. La nuova copia del database prende il nome di database secondario. Un processo automatico integrato in SQL Server eseguirà automaticamente il backup del log delle transazioni del database primario, copierà il backup nel server di standby e infine ripristinerà il backup in standby.
Le funzionalità HADR di SQL Server non sono le uniche opzioni che consentono di migliorare la disponibilità di una distribuzione IaaS. È opportuno considerare anche alcune funzionalità disponibili in Azure.