Gruppi di disponibilità AlwaysOn di SQL Server è la tecnologia più recente di Microsoft per soddisfare le esigenze di disponibilità elevata e ripristino di emergenza delle organizzazioni che utilizzano SQL Server. Un grande vantaggio di AlwaysOn è la capacità di gestire sia HA che DR in un'unica implementazione. I principali vantaggi di AlwaysOn che abbiamo riscontrato sono i seguenti:
Possiamo raggruppare i database correlati come parte di un unico gruppo di disponibilità e farli eseguire il failover insieme in caso di tale necessità. Ciò è particolarmente utile per le applicazioni che dipendono da più di un database come Microsoft Office SharePoint, Microsoft Lync o Sage.
Se confrontato con le istanze del cluster di failover di SQL Server, troviamo che l'archiviazione come singolo punto di errore è stata eliminata poiché a ogni istanza che costituisce una replica è assegnato il proprio spazio di archiviazione.
Con AlwaysOn, è possibile configurare HA e DR contemporaneamente. Ciò si ottiene creando cluster di failover di Windows multisito come base della configurazione AlwaysOn. L'esecuzione di un cambio di ruolo quando si utilizza AlwaysOn è molto più semplice rispetto a quando si utilizza la spedizione del registro delle transazioni.
La dipendenza WSFC
Quando si utilizza SQL Server AlwaysOn AG per la disponibilità elevata e il ripristino di emergenza, è innanzitutto necessario configurare un cluster di failover di Windows. Gli AG AlwaysOn dipendono da WFCS per gestire l'AG AlwaysOn come un ruolo composto da risorse del cluster come il nome del gruppo di disponibilità, il nome della condivisione file, il nome del listener e un indirizzo IP.
Fig. 1 AlwaysOn AG come risorsa cluster
Quorum
Quorum è il numero minimo di voti richiesti per ottenere la maggioranza in un cluster di failover. Il quorum determina il numero di errori di nodo che il cluster può sostenere. Attraverso la rete privata sulla porta 3343, tutti i nodi del cluster comunicano lo stato di salute e le informazioni sul monitoraggio delle risorse. In caso di fallimento, i voti mostrano quali nodi hanno lo stato “Up” e su quali risorse di nodo devono essere portate online.
Da Windows Server 2012, il numero massimo di nodi cluster supportati è sedici. Tuttavia, nella maggior parte degli ambienti che conosco, i cluster a due nodi sono comuni. Un cluster a due nodi pone un piccolo problema in termini di raggiungimento del quorum poiché ogni nodo ha un voto e se c'è un problema con la comunicazione tra i due, ognuno può presumere che l'altro non sia sano. Questo è chiamato uno scenario del cervello diviso. Gli scenari del cervello diviso sono il motivo per configurare un tie-break come un disco o una condivisione di file.
Se hai un numero dispari di nodi, non è necessario configurare uno spareggio. La configurazione del quorum dinamico e la testimonianza dinamica sono state introdotte rispettivamente in Windows Server 2012 e Windows Server 2012 R2. Con l'aiuto di queste tecnologie, Windows ridistribuisce automaticamente i voti in un cluster in modo che il numero di nodi in un cluster non sia importante per stabilire un Quorum. Il voto di un nodo del cluster viene rimosso impostando la proprietà del cluster "NodeWeight" su 0. Queste funzionalità sono abilitate per impostazione predefinita.
Fig. 2 Ottenere tutte le proprietà del cluster utilizzando PowerShell
Fig. 3 voti assegnati in un cluster a due nodi
Utilizzo di PowerShell
Il comando Get-Cluster di PowerShell può essere utilizzato per verificare la configurazione del quorum su un cluster di Windows. La Fig. 4 mostra come controllare tutte le proprietà del cluster relative al Quorum su un cluster e la Fig. 5 illustra le proprietà del File Share Witness. Esistono molti altri comandi di PowerShell per controllare e gestire i cluster di Windows.
Get-Cluster | Format-List –Property *Quorum*
Fig. 4 Comando di PowerShell per verificare le proprietà relative al quorum
Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter
Fig. 5 Comando di PowerShell per controllare i dettagli delle proprietà del testimone di condivisione file
Modalità quorum
Il cluster di failover di Windows Server consente di configurare fino a quattro modalità. Le modalità quorum sono essenzialmente opzioni che scegli per determinare in che modo il cluster gestirà gli errori dei nodi.
1. Maggioranza del nodo
Questa modalità Quorum può sostenere errori fino a (n/2)-1 nodi. È consigliato per i cluster con un numero dispari di nodi. Ad esempio, in un cluster a cinque nodi, ci vorrebbe un errore di due nodi per causare un errore del cluster.
2. Maggioranza di nodi e dischi
Può sostenere errori fino alla metà del numero di nodi del cluster finché il disco di controllo (chiamato anche disco quorum) rimane online.
3. Maggioranza di condivisione di nodi e file
Questa modalità Quorum può sostenere errori fino alla metà del numero di nodi del cluster finché la condivisione file rimane accessibile. A partire da Windows Server 2012 R2, Microsoft consiglia di configurare sempre un controllo (disco o condivisione file) durante la creazione di un cluster.
4. Nessuna maggioranza
Questa è una modalità Solo disco. Questa modalità può sostenere gli errori di tutti i nodi tranne uno finché il disco è online. Questa modalità non è consigliata poiché il disco diventa un singolo punto di errore.
Suggerimenti sulla configurazione della maggioranza dei nodi e delle condivisioni file
I gruppi di disponibilità AlwaysOn supportano solo due di queste modalità quorum:Maggioranza nodo e Maggioranza condivisione file e nodo. Quando si crea un cluster del gruppo di disponibilità AlwaysOn di SQL Server, ci sono alcuni punti che il DBA dovrebbe tenere a mente:
1. Utilizzo di server fisici
Quando si configura un cluster a due nodi per AlwaysOn, i nodi devono risiedere in rack fisici diversi. Il server che ospita la tua condivisione file deve risiedere in un terzo rack.
2. Utilizzo di server virtuali
Quando si configura un cluster a due nodi per AlwaysOn, le macchine virtuali devono risiedere su host separati. La macchina virtuale che ospita la tua condivisione file deve risiedere su un terzo host.
3. Clustering multisito
Quando si configura un cluster multinodo per AlwaysOn tra i data center, in uno scenario ideale il file server che ospita la condivisione file deve risiedere in un terzo data center.
4. Autorizzazioni di condivisione file
L'oggetto Cluster Name deve disporre delle autorizzazioni sulla condivisione file utilizzata come Quorum Witness. Senza questo, in genere si verificano errori nel tentativo di configurare il Quorum Witness.
Fig. 6 Autorizzazioni per la condivisione di file
5. Configurazione in linea
Le modalità quorum possono essere configurate mentre il cluster è online. Quindi, nel caso in cui il server di condivisione file si guasta o debba essere riconfigurato, assicurati di riconfigurarlo rapidamente per garantire che non si verifichino errori imprevisti, specialmente su un cluster a due nodi.
Un caso d'uso reale
Il diagramma in Fig. 7 mostra un vero Cluster AG AlwaysOn multisito. È un cluster a quattro nodi con due nodi su un sito e altri due su un sito di ripristino di emergenza remoto. Il file server che ospita la condivisione file utilizzata come tie-breaker è ospitato in un terzo data center. Nel caso in esame, il File Server risiede nella stessa città del Data Center primario, ma se te lo puoi permettere, sarebbe l'ideale avere il File Server in un'altra città. La comunicazione tra le tre parti deve essere di buona qualità per evitare falsi positivi.
Ad esempio, nella nostra implementazione iniziale di questo cluster, abbiamo utilizzato la "replica sincrona con failover automatico" nei siti Live e DR. In più di un'occasione abbiamo riscontrato un problema tecnico nella comunicazione che ha attivato un failover automatico al sito di ripristino di emergenza e ha esposto un difetto nella nostra configurazione. Ciò ha causato la risoluzione del nome del listener negli indirizzi IP associati nel sito DR e i client non potevano più connettersi perché la comunicazione con questo nuovo indirizzo IP non era consentita sui firewall di rete. Abbiamo semplicemente fallito sul sito primario per mitigare il problema e modificato la configurazione in "Replica asincrona con failover manuale" per i nodi che risiedono tra i data center. Abbiamo in programma di trattare l'aspetto della risoluzione dei nomi nel nostro prossimo articolo "AlwaysOn".
Fig. 7 Un caso d'uso reale
Conclusione
La funzionalità Gruppi di disponibilità AlwaysOn è stata introdotta in SQL Server 2012 ed è la tecnologia più recente di Microsoft per soddisfare le esigenze di disponibilità elevata e ripristino di emergenza. La configurazione dei gruppi di disponibilità AlwaysOn dipende in larga misura dal servizio cluster di failover di Windows. I cluster di failover, a loro volta, dipendono molto dalla corretta configurazione del quorum. Quando si compila AlwaysOn su cluster multisito, la latenza tra i nodi nei diversi siti e la condivisione file utilizzata come arbitro è davvero importante. Assicurati che la configurazione del tuo quorum sia sempre in perfetta forma per evitare comportamenti imprevisti con i gruppi di disponibilità.
Riferimenti
Panoramica dei gruppi di disponibilità AlwaysOn
Gruppo di failover di Windows con SQL Server
Documentazione PowerShell
Comprensione del quorum del cluster di failover di Windows Server
