Schema di distribuzione a doppia regione multizona

I server virtuali IBM Cloud Windows Server 2019 Standard configurati come nodi Windows Server Failover Cluster (WSFC) e SQL Server Enterprise edition con gruppi di disponibilità SQL Server Always On configurati su ciascun nodo costituiscono la base del modello di distribuzione duale Multi-Zone Region (MZR). Questa architettura, insieme a MS ADDNS, fornisce un'implementazione di SQL Server per il disaster recovery.

Il modello di distribuzione MZR doppio illustrato sfrutta il modello della doppia zona di disponibilità (AZ) e lo estende in modo da avere una copia dei database in una regione remota; pertanto, questo modello è adatto ai database di produzione che richiedono il disaster recovery e sfrutta le seguenti tecnologie di base:

Una IBM Cloud VPC con sottoreti in due MZR.
I gruppi di sicurezza vengono utilizzati per controllare i flussi di traffico tra i componenti.
Uno o più host bastion utilizzati per l'accesso amministrativo ai server.
Floating IP (FIP) collegato agli host del bastione per consentire l'accesso a Internet.
Tre server virtuali Windows Server 2019 Standard, uno in ogni AZ nell'MZR primario e un terzo nell'MZR di ripristino, che sono controller di dominio Active Directory nello stesso dominio forestale.
Tre server virtuali Windows Server 2019 Standard, uno in ogni AZ dell'MZR primario e un terzo nell'MZR di ripristino, che diventeranno nodi Windows Server Failover Cluster (WSFC).
I gruppi di disponibilità Always On consentono di mantenere un insieme discreto di database altamente disponibili su uno o più nodi del cluster e operano a livello di database. I gruppi di disponibilità sono costituiti da una replica primaria e da un massimo di otto repliche secondarie e utilizzano la replica dei dati sincrona o asincrona. In questo schieramento:
- la replica sincrona viene utilizzata tra i due AZ dell'MZR primario.
- tra gli MZR viene utilizzata la replica asincrona.
Distributed Network Names è una risorsa di nomi nei gruppi di disponibilità WSFC e Always On, utilizzata per la risoluzione dei nomi delle risorse del cluster.

In questa distribuzione non è necessario un testimone di condivisione file, poiché il numero di nodi è dispari e verrà utilizzata la modalità quorum a maggioranza di Node

Cluster Failover di Windows Server

La distribuzione di gruppi di disponibilità Always On per HA su Windows richiede un Windows Server Failover Cluster (WSFC). Ogni replica di un gruppo di disponibilità deve risiedere su un nodo diverso del WSFC. Per semplificare la configurazione della sicurezza dei database di disponibilità, si consiglia di eseguire le istanze del server SQL (gli account di servizio) sotto un account di servizio di dominio.

Windows Server Failover Cluster (WSFC) è una funzione di Windows Server e ogni server che funge da nodo del cluster deve avere questa funzione abilitata. Il WSFC si basa sul quorum per evitare la sindrome del "cervello diviso", e ci sono diverse modalità di quorum:

Maggioranza dei Node- I nodi attivi del cluster determinano il quorum. Affinché il cluster mantenga uno stato di salute, almeno la metà dei voti possibili deve essere positiva.
Maggioranza di Node e file share - Un file share remoto funge da testimone di voto per i nodi attivi coinvolti nella votazione del quorum. Come nel caso della maggioranza dei Node, almeno la metà dei voti possibili deve essere affermativa affinché il cluster mantenga uno stato sano.
Maggioranza di Node e dischi - Un disco condiviso funge da testimone di voto, insieme ai nodi attivi coinvolti in una votazione di quorum.
Solo disco - Un disco condiviso funge da testimone e il quorum è determinato da quali nodi possono accedere al disco. Non è richiesto un numero minimo di voti possibili.

Le raccomandazioni di Microsoft per SQL server sono le seguenti:

Utilizzare la modalità quorum a maggioranza di Node quando c'è un numero dispari di nodi votanti.
Utilizzare la modalità quorum Node and File Share Majority quando si dispone di un numero pari di nodi votanti.

Gruppi di disponibilità sempre attivi

Un gruppo di disponibilità supporta un set di database primari e fino a otto set di database secondari. I database secondari non sono backup, quindi è essenziale eseguire regolarmente il backup dei database e dei relativi registri delle transazioni. I gruppi di disponibilità Always On richiedono una delle tre seguenti opzioni di tipo di cluster: WSFC, EXTERNAL, NONE.

WSFC - Utilizza Windows Server Failover Cluster (WSFC) per gestire il failover del cluster. Questo è un prerequisito per i gruppi ad alta disponibilità sui server Windows.
Esterno - Utilizza un gestore di cluster esterno. Ad esempio, SQL Server su Linux supporta Pacemaker. I gruppi di disponibilità su cluster Linux richiedono almeno due repliche sincrone per garantire l'HA, ma almeno tre repliche per il ripristino automatico, quindi si consiglia di impostare un gruppo di disponibilità su almeno tre nodi.
Nessuno - Conosciuti come gruppi di disponibilità senza cluster o inizialmente indicati come gruppi di disponibilità su scala di lettura. Tuttavia, questa opzione fornisce solo un sottoinsieme delle funzioni dei gruppi di disponibilità e non include il failover automatico. Le caratteristiche includono il failover manuale pianificato e forzato e le modalità di replica sincrona e asincrona, i nodi secondari leggibili e i backup delle repliche secondarie. I gruppi di disponibilità senza un cluster WSFC possono comunque fornire nodi secondari leggibili, routing di sola lettura e bilanciamento del carico. Il failover può essere automatizzato con strumenti esterni. Una nuova funzionalità di SQL Server 2019 aiuta a mitigare questo problema con il reindirizzamento automatico del traffico, che prevede il reindirizzamento del traffico di lettura/scrittura al nodo primario e non richiede un listener.

Per descrivere i concetti di gruppo di disponibilità si utilizza la seguente terminologia:

Gruppo di disponibilità: supporta un ambiente replicato per un insieme discreto di database utente.
Gruppo di disponibilità HA: un gruppo di database che fanno fail over insieme.
Gruppo di disponibilità su scala di lettura: un gruppo di database che viene copiato su altre istanze di SQL Server per il carico di lavoro in sola lettura.
Replica primaria - rende i database primari disponibili per le connessioni in lettura-scrittura dei client e invia i record dei registri delle transazioni di ciascun database primario a tutti i database secondari.
Replica secondaria - fino a otto repliche secondarie, ciascuna delle quali ospita una serie di database secondari e serve come potenziale target di failover per il gruppo di disponibilità HA.

Modalità di sincronizzazione

Le repliche secondarie del gruppo di disponibilità possono essere configurate con una delle seguenti modalità di sincronizzazione:

Sincrono - Il log viene temprato (le transazioni vengono impegnate nel log delle transazioni) su ogni replica secondaria prima che la transazione venga impegnata sulla replica primaria. Questo garantisce l'assenza di perdita di dati, con un potenziale impatto sulle prestazioni di un carico di lavoro altamente transazionale se la latenza di rete è elevata. È possibile avere due repliche sincrone per AG. Questa modalità è più adatta alle istanze dello stesso AZ o MZR.
Asincrono - La transazione è considerata impegnata non appena viene registrata nel registro delle transazioni sulla replica primaria. Se si verifica un problema prima che i registri siano consolidati su tutte le repliche secondarie, è possibile che si verifichi una perdita di dati e il punto di ripristino sarebbe l'ultima transazione impegnata che ha avuto successo su tutte le repliche secondarie. Questa modalità è più adatta per le istanze in diversi MZR o tra un AZ e un on-premise.

Modalità di failover

Quando un gruppo di disponibilità subisce un guasto, una replica secondaria diventa la nuova primaria e la replica primaria, se disponibile, diventa una replica secondaria.

Failover automatico - I failover automatici forniscono HA e si basano su oggetti listener e WSFC correttamente configurati per il loro successo. Solo una replica in modalità di disponibilità sincrona-commit può essere la destinazione di un failover automatico. È possibile configurare le condizioni che richiedono un failover automatico su una scala da 1 a 5, dove 1 indica che solo un'interruzione totale del servizio SQL Server sulla replica primaria avvierebbe un failover e 5 indica uno qualsiasi degli errori di SQL Server da critici a meno gravi. L'impostazione predefinita è 3, che richiede un fallimento automatico in caso di interruzione o di mancata risposta della replica primaria, ma anche per alcune condizioni critiche del server. Queste condizioni di "politica di failover flessibile" sono descritte in dettaglio in Configurazione di una politica di failover automatico flessibile per un gruppo di disponibilità Always On.
Failover pianificato - Un failover pianificato può avvenire solo se non c'è possibilità di perdita di dati. In particolare, ciò significa che il failover avviene senza utilizzare il parametro FORCE per riconoscere gli avvisi nel codice o nelle finestre di dialogo di SSMS. È possibile avere un failover pianificato su una replica secondaria solo in modalità di disponibilità synchronouscommit. È possibile spostare una replica in modalità di disponibilità asincrona-commit a sincrona, attendere lo stato SYNCHRONIZED e quindi eseguire un failover pianificato senza perdita di dati. I failover pianificati devono sempre essere avviati tramite SSMS, T-SQL o PowerShell.
Failover forzato - Un failover forzato avviato manualmente deve essere avviato solo in risposta a condizioni avverse del cluster, come la perdita del nodo primario. Iniziate da procedure guidate SSMS, comandi T-SQL o PowerShell e solo da Windows Server Failover Cluster Manager come ultima risorsa.
Forzare il failover se il quorum del WSFC è inattivo - Non è possibile forzare un failover per i gruppi di disponibilità basati su un WSFC se il WSFC non ha il quorum. Dovrete prima forzare il quorum nel Configuration Manager "truccando" il voto e modificando i pesi dei nodi. Questo passaggio va considerato solo in caso di emergenza, ad esempio quando un disastro ha interrotto la maggior parte dei nodi del cluster. Questo può essere realizzato con uno script PowerShell, per forzare un nodo online ad assumere il ruolo primario senza una maggioranza di voti.

I Failover non sono causati da problemi del database, come ad esempio un database sospetto a causa della perdita di un file di dati o del danneggiamento di un log delle transazioni.

Altri tipi di gruppi di disponibilità

I seguenti gruppi di disponibilità non sono utilizzati in questo modello di distribuzione, ma possono essere interessanti per i risolutori che desiderano adattare o estendere questo modello di distribuzione:

Gruppi di disponibilità di base - Una versione limitata dei gruppi di disponibilità e sono supportati solo su SQL Server Standard edition. La singola replica secondaria non può essere letta o sottoposta a backup e ogni gruppo di disponibilità di base può supportare solo due repliche, ma è possibile configurare più gruppi di disponibilità di base per server. I gruppi di disponibilità di base consentono molte delle stesse caratteristiche dei gruppi di disponibilità, tra cui la replica sincrona o asincrona, i failover manuali o automatici.
Gruppi di disponibilità distribuiti - Consente a un gruppo di disponibilità di trattare un altro gruppo di disponibilità come replica secondaria. Le repliche secondarie di sola lettura possono essere disperse a livello globale, scaricando i carichi di lavoro su repliche secondarie di sola lettura regionali. I due gruppi di disponibilità, ciascuno con il proprio ascoltatore, non devono necessariamente trovarsi nella stessa rete o nello stesso WSFC. Ciò consente di realizzare HA e DR geograficamente remoti in implementazioni multi-sito. Con i gruppi di disponibilità distribuiti, non è necessario che un WSFC si estenda su più regioni. Non c'è failover automatico tra il gruppo di disponibilità primario e il gruppo di disponibilità secondario. Il gruppo di disponibilità non primario può servire solo query di sola lettura, ma ha una replica primaria. La replica primaria del gruppo di disponibilità secondario è incaricata di replicare le transazioni alle altre repliche secondarie del gruppo di disponibilità secondario. Questa architettura è utile per gli aggiornamenti del sistema operativo e della versione di SQL Server, in quanto è possibile avere versioni diverse di Windows Server in ciascun gruppo di disponibilità. Sebbene ogni gruppo di disponibilità in uno scenario distribuito abbia il proprio ascoltatore, il gruppo di disponibilità distribuito nel suo complesso non lo ha. Le applicazioni, magari con l'aiuto di alias DNS, si collegheranno a ciascun gruppo di disponibilità direttamente dopo un failover per sfruttare le repliche secondarie leggibili.

Nomi di rete distribuiti

Questa implementazione utilizza Distributed Network Names (DNN), che è una risorsa di nomi nei gruppi di disponibilità WSFC e Always On, utilizzata per la risoluzione dei nomi delle risorse del cluster. Si differenzia da una risorsa nome di rete standard perché non richiede un indirizzo IP separato dagli indirizzi IP dei nodi e non richiede l'uso del Gratuitous Address Resolution Protocol (GARP) sulla rete quando si verifica un failover. In Windows Server 2019, il nome del WSFC, che è anche il Cluster Name Object (CNO) in Active Directory Domain Services, e l'ascoltatore del database possono entrambi essere creati con DNN.