SQL Server Always ON Availability Group è una soluzione pensata per ottenere disponibilità elevata e ripristino di emergenza per i database di SQL Server. Possiamo configurare questa funzionalità tra le installazioni di SQL Server basate su Windows, le installazioni di SQL Server basate su Linux e persino tra le installazioni di SQL Server basate su Linux e Windows insieme.
I gruppi di disponibilità sono strettamente integrati con le tecnologie cluster sotto forma di failover automatico e protezione dei dati replicando i dati nelle rispettive repliche secondarie. Tuttavia, non è sempre obbligatorio disporre di un gestore risorse cluster per configurare i gruppi di disponibilità.
Per configurare i gruppi di disponibilità di SQL Server, abbiamo bisogno di WSFC – Cluster di failover di Windows Server tecnologia per Windows installazioni basate su SQL Server e PACEMAKER per Linux installazioni basate su SQL Server.
PACEMAKER è un gestore di risorse cluster open source che possiamo utilizzare per gestire le risorse e garantire la disponibilità del sistema, in caso di guasto sui sistemi Linux.
WSFC è un prodotto Microsoft sviluppato per supportare i requisiti dei cluster basati su Windows.
Quando guardi i gruppi di disponibilità configurati in SQL Server per entrambi i tipi di sistema operativo, sembra simile in SQL Server Management Studio.
Tuttavia, questo articolo spiega i gruppi di disponibilità tra SQL Server basato su Ubuntu Linux installazioni utilizzando il PACEMAKER tecnologia cluster quindi prenderò in considerazione solo questa configurazione.
Configurazione del tipo di cluster
Come ho affermato in precedenza, abbiamo tre varianti per la configurazione dei gruppi di disponibilità per SQL Server, a seconda del sistema operativo:
- tra installazioni di SQL Server basate su Windows;
- tra installazioni di SQL Server basate su Linux;
- tra il tipo misto di installazioni di SQL Server basate su Windows e Linux.
Microsoft ha introdotto il Tipo_cluster impostazione di configurazione per identificare e configurare una tecnologia cluster appropriata per i gruppi di disponibilità. È un elemento di configurazione che definisce il tipo di tecnologia cluster che utilizziamo per i gruppi di disponibilità, indipendentemente dal sistema operativo su cui si basa l'istanza di SQL Server.
È possibile recuperare e convalidare la configurazione esistente del tipo Cluster utilizzando SQL Server Dynamic Management View (DMV) sys.availability_groups . Sono presenti due colonne denominate cluster_type e cluster_type_desc . Possiamo leggere queste colonne per definire la configurazione del tipo di cluster della configurazione del gruppo di disponibilità.
Questa impostazione di configurazione ha 3 valori per soddisfare i requisiti della tecnologia del cluster per ciascuna variante:
WSFC .È necessario utilizzare l'opzione WSFC (cluster di failover del server Windows) se si dispone di installazioni di SQL Server basate su Windows. Non è supportato per installazioni di SQL Server basate su Linux.
ESTERNO . Se si configurano i gruppi di disponibilità tra installazioni di SQL Server basate su Linux, è necessario utilizzare il gestore cluster PACEMAKER e scegliere ESTERNO cluster digita . Anche la modalità di failover deve essere ESTERNA (in WSFC sarà Automatica).
NESSUNO . Se non desideri utilizzare alcuna tecnologia di clustering per i tuoi gruppi di disponibilità, seleziona NESSUNO . Questa opzione è applicabile se si desidera configurare i gruppi di disponibilità tra le istanze di SQL Server basate su Linux e Windows. Anche se hai configurato il clustering per il tuo sistema, una volta impostato il valore del tipo di cluster su NONE, i gruppi di disponibilità non utilizzeranno la tecnologia del cluster. La modalità di failover per il tipo di cluster NONE è sempre Manuale .
Una nuova impostazione:obbligatorie secondarie sincronizzate per impegnarsi
A partire da SQL Server 2017, Microsoft ha introdotto una nuova impostazione denominata required_synchronized_secondaries_to_commit . Abilita l'opzione di failover automatico se hai configurato il tipo di cluster come ESTERNO per la configurazione del cluster PACEMAKER.
Il valore di questa impostazione è impostato per impostazione predefinita quando si configura l'agente risorse di SQL Server mssql-server-ha e crea la configurazione del cluster.
Inoltre, puoi modificare manualmente il valore per i tuoi requisiti eseguendo il comando seguente:
--Run below commands to change value for setting required_synchronized_secondaries_to_commit
--AGResourceName is the name of the resource configured for the Availability group
sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<Value>
Nota:possiamo modificare l'impostazione sopra solo tramite Pacemaker su Linux. È impossibile modificarlo utilizzando l'istruzione T-SQL per le distribuzioni basate su Linux. Tuttavia, per le distribuzioni basate su Windows, possiamo modificare questa impostazione tramite un'istruzione T-SQL.
Di seguito sono riportati i possibili valori per required_synchronized_secondaries_to_commit
0 – Significa che le repliche secondarie non devono essere sincronizzate con la rispettiva replica primaria. Pertanto, non supporta il failover automatico. È necessario avviare il failover manualmente se la replica primaria non funziona. Importante:c'è una possibilità di perdita di dati quando scegli questo valore per la configurazione.
1 – Significa che almeno una replica secondaria deve essere nello stato sincronizzato per ottenere il failover automatico.
2 – Significa che entrambe le repliche secondarie devono essere sincronizzate con la replica primaria. Il failover automatico è supportato.
Repliche per partecipare a un gruppo di disponibilità
Il numero di repliche che possono partecipare a un gruppo di disponibilità dipende dall'edizione di SQL Server installata.
- Lo standard di SQL Server l'edizione supporta solo replica a due nodi per un gruppo di disponibilità insieme alla replica aggiuntiva di sola configurazione.
- L'impresa di SQL Server l'edizione supporta fino a nove repliche:una replica primaria e otto secondarie.
Poiché SQL Server Standard Edition supporta solo due repliche (una replica primaria e una replica secondaria), Microsoft ha introdotto un nuovo concetto chiamato replica di sola configurazione in SQL Server 2017 CU1 per ottenere il failover automatico per SQL Server in esecuzione su sistemi Linux.
Ci sono due possibili opzioni di progettazione:
- Tre repliche sincrone. Questa configurazione può essere distribuita solo con SQL Server Enterprise Edition. Ci saranno 3 copie dei tuoi database di disponibilità. Questa architettura consente tutte e 3 le funzionalità su scala di lettura, alta disponibilità e protezione dei dati.
- Due repliche sincrone e una replica di sola configurazione. È possibile configurare questa progettazione anche con l'aiuto dell'edizione SQL Server Standard, eseguendo due repliche sincrone nell'edizione SQL Server Standard e la replica 3 nell'edizione SQL Server Express che funge da replica di sola configurazione. È un design conveniente che supporta l'alta disponibilità con failover automatico e protezione del database.
Replica a due nodi
Le configurazioni di replica a due nodi per i gruppi di disponibilità è un'opzione di distribuzione molto popolare per garantire l'elevata disponibilità dei database di SQL Server. Otteniamo il failover automatico con l'aiuto della tecnologia Windows Server Failover Cluster e un testimone di condivisione file nelle distribuzioni di SQL Server basate su Windows.
La condivisione file viene generalmente utilizzata su un nodo aggiuntivo in WSFC per fornire la configurazione del quorum per le configurazioni di replica a due nodi. WSFC sincronizza tutti i metadati di configurazione su entrambe le repliche e sul terzo nodo o testimone di condivisione file per un failover uniforme. Tutto l'arbitrato di failover per il gruppo di disponibilità di SQL Server basato su Windows avviene a livello WSFC.
Se vogliamo ottenere il failover automatico per le distribuzioni del gruppo di disponibilità di SQL Server basate su Linux, la configurazione sopra non funzionerà. È perché WSFC può essere utilizzato solo per installazioni di SQL Server basate su Windows.
Per affrontare questa limitazione e abilitare il failover automatico per le distribuzioni a due repliche basate su Linux, Microsoft ha introdotto un nuovo concetto.
Replica di sola configurazione
Una replica di sola configurazione è un'opzione in cui installiamo un'istanza aggiuntiva di SQL Server sul terzo nodo. Quel nodo funzionerà come server di controllo per la configurazione della replica a due nodi per supportare il failover automatico. Possiamo creare una replica di sola configurazione per gruppo di disponibilità .
Per le istanze di SQL Server basate su Linux in cui utilizziamo il tipo di cluster come ESTERNO per PACEMAKER, l'arbitrato di failover non funziona a livello di cluster come WSFC. Tutto l'arbitrato di failover avviene a livello di SQL Server perché tutti i metadati di configurazione del gruppo di disponibilità sono archiviati nei database master di ogni replica.
Microsoft ha introdotto il concetto di replica di sola configurazione per gestire il quorum per i gruppi di disponibilità di SQL Server basati su Linux. Questo concetto non ospita alcun database utente per partecipare a un gruppo di disponibilità. Memorizza tutte le informazioni di configurazione del gruppo di disponibilità nel database master per garantire che tutto l'arbitrato di failover avvenga senza intoppi.
È possibile utilizzare qualsiasi edizione di SQL Server per la replica di sola configurazione. Anche l'edizione SQL Server Express si adatta a risparmiare sul costo della licenza per la terza replica. Tenere presente che la replica di sola configurazione non ospiterà alcun database all'interno del gruppo di disponibilità. Pertanto, avrai solo due copie di database in un gruppo di disponibilità.
Per impostazione predefinita, required_synchronized_secondaries_to_commit è impostato su 0 quando utilizziamo la replica di sola configurazione. Possiamo modificare manualmente questo valore su 1 se necessario.
Dai un'occhiata al diagramma di progettazione della replica sincrona a due nodi e di una replica di sola configurazione per ottenere il failover automatico e la protezione dei dati.
Possiamo vedere che ci sono 3 VM denominate AOAGVM1, AOAGVM2 e AOAGVM3. Sono tutti eseguiti dal sistema Ubuntu Linux e SQL Server è configurato su tutti e tre i sistemi Linux. I database di disponibilità sono ospitati su AOAGVM1 e AOAGVM2.
AOAGVM1 agisce come una replica primaria, mentre AOAGVM2 è una replica secondaria. AOAGVM3 funge da replica di sola configurazione, ovvero l'edizione SQL Server Express. Nessun database utente è ospitato su questa terza replica.
Il cluster Pacemaker è stato configurato tra tutti e tre i nodi per supportare la tecnologia cluster per la configurazione del gruppo di disponibilità basato su Linux.
Per configurare o implementare il design di cui sopra, dobbiamo eseguire i seguenti passaggi:
- Installa SQL Server su tre sistemi Ubuntu (l'edizione SQL Server Express è adatta per la replica di sola configurazione).
- Configura i gruppi di disponibilità tra tre nodi.
- Configura il cluster PACEMAKER tra tre nodi.
- Aggiungi o integra il gruppo di disponibilità come risorsa nel gruppo di cluster.
Dai un'occhiata all'articolo correlato per completare il passaggio 1 (installazione di istanze di SQL Server su tre nodi).
Resta sintonizzato per il mio prossimo articolo in cui spiegherò il processo passo dopo passo per implementare il design sopra. Il nostro obiettivo sarà ottenere il failover automatico e la protezione dei dati utilizzando la replica sincrona a 2 nodi e una replica di sola configurazione.
Saremo lieti di ascoltare i vostri pensieri e consigli pratici su questo argomento. Sentiti libero di condividerli nella sezione Commenti.
