SQL Server non è strettamente integrato con Pacemaker in Linux come lo è con il clustering di failover di Windows Server (WSFC). Un'istanza di SQL Server non è in grado di conoscere il cluster e tutte le orchestrazioni provengono dall'esterno. Pacemaker fornisce un'orchestrazione di risorse cluster. Inoltre, il nome della rete virtuale è specifico del clustering di failover di Windows Server. Non esiste un equivalente in Pacemaker. Le DMV del gruppo di disponibilità che eseguono query sulle informazioni del cluster restituiscono righe vuote nei cluster Pacemaker. Per creare un listener per la riconnessione trasparente dopo il failover, registrare manualmente il nome del listener in DNS con l'indirizzo IP usato per creare la risorsa IP virtuale.
Le sezioni seguenti illustrano i passaggi per configurare un cluster Pacemaker e aggiungere un gruppo di disponibilità come risorsa nel cluster per la disponibilità elevata, per ogni distribuzione di Linux supportata.
Il livello di clustering si basa sul componente aggiuntivo a disponibilità elevata di Red Hat Enterprise Linux (RHEL), basato a sua volta su Pacemaker.
Nota
Per accedere alla documentazione di Red Hat, è necessaria una sottoscrizione.
Per altre informazioni sulla configurazione del cluster, sulle opzioni degli agenti delle risorse e sulla gestione, vedere la documentazione di riferimento di RHEL.
Roadmap
I passaggi da seguire per creare un gruppo di disponibilità sui server Linux per la disponibilità elevata sono diversi da quelli relativi a un cluster di failover di Windows Server. Nell'elenco seguente sono descritti i passaggi principali:
Configurare SQL Server nei nodi del cluster.
Creare il gruppo di disponibilità.
Configurare un modulo per la gestione di risorse cluster, ad esempio Pacemaker. Le istruzioni sono riportate in questo articolo.
La modalità di configurazione di un modulo per la gestione di risorse cluster dipende dalla specifica distribuzione Linux.
Importante
Per la disponibilità elevata, negli ambienti di produzione è necessario un agente di isolamento. Nelle dimostrazioni di questa documentazione non vengono usati agenti di isolamento. Le dimostrazioni sono riportate solo a scopo di test e convalida.
Un cluster Linux usa l'isolamento per ripristinare uno stato noto del cluster. La modalità di configurazione dell'isolamento dipende dalla distribuzione e dall'ambiente. Attualmente l'isolamento non è disponibile in alcuni ambienti cloud. Per altre informazioni, vedere Support Policies for RHEL High Availability Clusters - Virtualization Platforms (Criteri di supporto per il cluster RHEL a disponibilità elevata - Piattaforme di virtualizzazione).
Aggiungere il gruppo di disponibilità come risorsa nel cluster.
Per configurare la disponibilità elevata per RHEL, abilitare la sottoscrizione a disponibilità elevata e quindi configurare Pacemaker.
Abilitare la sottoscrizione a disponibilità elevata per RHEL
Ogni nodo del cluster deve avere una sottoscrizione appropriata per RHEL e il componente aggiuntivo a disponibilità elevata. Esaminare i requisiti riportati in How to install High Availability cluster packages in Red Hat Enterprise Linux (Come installare i pacchetti di cluster a disponibilità elevata in Red Hat Enterprise Linux). Seguire questa procedura per configurare la sottoscrizione e i repository:
Registrare il sistema.
sudo subscription-manager register
Specificare il nome utente e la password.
Elencare i pool disponibili per la registrazione.
sudo subscription-manager list --available
Dall'elenco dei pool disponibili, prendere nota dell'ID del pool per la sottoscrizione a disponibilità elevata.
Aggiornare lo script seguente. Sostituire <pool id>
con l'ID del pool per la disponibilità elevata nel passaggio precedente. Eseguire lo script per associare la sottoscrizione.
sudo subscription-manager attach --pool=<pool id>
Abilitare il repository.
RHEL 7
sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
RHEL 8
sudo subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
Per altre informazioni, vedere Pacemaker - The Open Source, High Availability Cluster (Pacemaker - Il cluster open source a disponibilità elevata).
Dopo aver configurato la sottoscrizione, completare la procedura seguente per configurare Pacemaker:
Dopo aver registrato la sottoscrizione, completare la procedura seguente per configurare Pacemaker:
In tutti i nodi del cluster aprire le porte del firewall di Pacemaker. Per aprire queste porte con firewalld
, eseguire il comando seguente:
sudo firewall-cmd --permanent --add-service=high-availability
sudo firewall-cmd --reload
Se il firewall non ha una configurazione a disponibilità elevata predefinita, aprire le porte seguenti per Pacemaker.
- TCP: porte 2224, 3121, 21064
- UDP: porta 5405
Installare i pacchetti Pacemaker in tutti i nodi.
sudo yum install pacemaker pcs fence-agents-all resource-agents
Impostare la password per l'utente predefinito creato durante l'installazione dei pacchetti Pacemaker e Corosync. Usare la stessa password in tutti i nodi.
sudo passwd hacluster
Per riaggiungere i nodi al cluster dopo il riavvio, abilitare e avviare il servizio pcsd
e Pacemaker. Eseguire il comando seguente in tutti i nodi.
sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker
Creare il cluster. Per creare il cluster, eseguire il comando seguente:
RHEL 7
sudo pcs cluster auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup --name <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
RHEL 8
Per RHEL 8, sarà necessario autenticare i nodi separatamente. Immettere manualmente il nome utente e la password per hacluster, quando richiesto.
sudo pcs host auth <node1> <node2> <node3>
sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
Nota
Se in precedenza è stato configurato un cluster negli stessi nodi, è necessario usare l'opzione --force
quando si esegue pcs cluster setup
. Questa opzione equivale a eseguire pcs cluster destroy
. Per abilitare nuovamente pacemaker, eseguire sudo systemctl enable pacemaker
.
Installare l'agente delle risorse SQL Server per SQL Server. Eseguire i comandi seguenti in tutti i nodi.
sudo yum install mssql-server-ha
Dopo aver configurato Pacemaker, usare pcs
per interagire con il cluster. Eseguire tutti i comandi in unico nodo del cluster.
Considerazioni per più schede di interfaccia di rete
Quando si configura la disponibilità elevata con server con più schede di interfaccia di rete, seguire questi suggerimenti:
Assicurati che il file hosts
sia configurato in modo che gli indirizzi IP del server per più schede di interfaccia di rete vengano risolti nel nome host del server Linux in ogni nodo.
Quando si configura il cluster usando Pacemaker, l'uso del nome host dei server deve configurare Corosync per impostare la configurazione per tutte le schede di interfaccia di rete. La comunicazione Pacemaker/Corosync deve avvenire su una singola scheda di interfaccia di rete. Dopo aver configurato il cluster Pacemaker, modifica la configurazione nel file corosync.conf
e aggiorna l'indirizzo IP per la scheda di interfaccia di rete dedicata da usare per la comunicazione Pacemaker/Corosync.
Il valore <hostname>
specificato nel file corosync.conf
deve essere uguale all'output specificato durante l'operazione di ricerca inversa (ping -a <ip_address>
) e deve essere il nome breve configurato nell'host. Assicurati che il file hosts
rappresenti anche l'indirizzo IP appropriato per la risoluzione dei nomi.
Di seguito sono evidenziate le modifiche apportate all'esempio del file corosync.conf
:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
I fornitori di cluster Pacemaker richiedono l’isolamento di un nodo non riuscito, usando un dispositivo di isolamento impostato per una configurazione di cluster supportata. Quando il modulo per la gestione di risorse cluster non riesce a determinare lo stato di un nodo o di una risorsa in un nodo, è possibile ripristinare uno stato noto del cluster tramite l'isolamento.
Un dispositivo di isolamento fornisce un agente di isolamento. La configurazione di Pacemaker in Red Hat Enterprise Linux in Azure offre un esempio di come creare un dispositivo di isolamento per questo cluster in Azure. Modificare le istruzioni per l'ambiente.
L'isolamento a livello di risorsa garantisce che i dati non subiscano danni in caso di interruzione tramite la configurazione di una risorsa. È ad esempio possibile usare l'isolamento a livello di risorsa per contrassegnare come obsoleto il disco su un nodo quando il collegamento di comunicazione diventa inattivo.
L'isolamento a livello di nodo consente di assicurarsi che un nodo non esegua alcuna risorsa. Questa operazione viene eseguita tramite il reset del nodo. Pacemaker supporta un'ampia gamma di dispositivi di isolamento, ad esempio un alimentatore di continuità o schede di interfaccia di gestione per i server.
Per informazioni sull'isolamento di un nodo non riuscito, vedi gli articoli seguenti:
Nota
Poiché la configurazione dell'isolamento a livello di nodo dipende principalmente dall'ambiente in uso, disabilitarlo per questa esercitazione. Potrà essere configurato in un secondo momento. Lo script seguente disabilita l'isolamento a livello di nodo:
sudo pcs property set stonith-enabled=false
La disabilitazione dell’isolamento viene eseguita solo a scopo di test. Se si prevede di usare Pacemaker in un ambiente di produzione, è consigliabile pianificare un'implementazione dell’isolamento in base all'ambiente e mantenerla abilitata.
Impostare la proprietà del cluster cluster-recheck-interval
cluster-recheck-interval
indica l'intervallo di polling in base al quale il cluster verifica se sono state apportate modifiche ai parametri delle risorse, ai vincoli o ad altre opzioni del cluster. Se una replica diventa inattiva, il cluster prova a riavviare la replica in base a un intervallo associato ai valori di failure-timeout
e cluster-recheck-interval
. Se, ad esempio, failure-timeout
è impostato su 60 secondi e cluster-recheck-interval
su 120, viene eseguito un tentativo di riavvio in base a un intervallo superiore a 60 secondi ma inferiore a 120. È consigliabile impostare failure-timeout su 60 secondi e cluster-recheck-interval
su un valore superiore a 60 secondi. L'impostazione di cluster-recheck-interval
su un valore inferiore non è consigliata.
Per aggiornare il valore della proprietà su 2 minutes
, eseguire il comando seguente:
sudo pcs property set cluster-recheck-interval=2min
Se è già presente una risorsa del gruppo di disponibilità gestita da un cluster Pacemaker, il pacchetto Pacemaker 1.1.18-11.el7 ha introdotto una modifica del comportamento per l'impostazione del cluster start-failure-is-fatal
quando il relativo valore è false
. Questa modifica influisce sul flusso di lavoro del failover. Se si verifica un'interruzione in una replica primaria, è previsto il failover del cluster in una delle repliche secondarie disponibili. Al contrario, gli utenti noteranno che il cluster continuerà a provare ad avviare la replica primaria che ha subito l'interruzione. Se la replica primaria non torna mai online, a causa di un'interruzione permanente, il cluster non esegue mai il failover in un'altra replica secondaria disponibile. A causa di questa modifica, una configurazione precedentemente consigliata per impostare start-failure-is-fatal
non è più valida e l'impostazione deve essere ripristinata sul valore true
predefinito.
La risorsa del gruppo di disponibilità deve inoltre essere aggiornata in modo da includere la proprietà failure-timeout
.
Per aggiornare il valore della proprietà su true
, eseguire il comando seguente:
sudo pcs property set start-failure-is-fatal=true
Per aggiornare la proprietà failure-timeout
della risorsa ag_cluster
impostandola su 60s
, esegui il comando seguente:
pcs resource update ag_cluster meta failure-timeout=60s
Per informazioni sulle proprietà del cluster Pacemaker, vedere Pacemaker Cluster Properties (Proprietà del cluster Pacemaker).
Creare un account di accesso di SQL Server per Pacemaker
In tutte le istanze di SQL Server crea un account di accesso al server per Pacemaker.
Il codice Transact-SQL seguente crea un account di accesso:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Al momento della creazione del gruppo di disponibilità, l'utente Pacemaker richiederà le autorizzazioni ALTER
, CONTROL
, e VIEW DEFINITION
per il gruppo di disponibilità, dopo che è stato creato, ma prima che vi vengano aggiunti nodi.
In tutte le istanze di SQL Server salva le credenziali per l'account di accesso di SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Creare una risorsa del gruppo di disponibilità
Per creare la risorsa del gruppo di disponibilità, usare il comando pcs resource create
e impostare le proprietà della risorsa. Il comando seguente crea una risorsa di tipo master/subordinato ocf:mssql:ag
per il gruppo di disponibilità con il nome ag1
.
RHEL 7
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s master notify=true
RHEL 8
Con la disponibilità di RHEL 8, la sintassi CREATE è cambiata. Se si usa RHEL 8, il termine master
è stato modificato in promotable
. Usare il comando di creazione seguente invece del comando precedente:
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s promotable notify=true
Nota
Quando si crea la risorsa, e periodicamente dopo la creazione, l'agente delle risorse Pacemaker imposta automaticamente il valore di REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
nel gruppo di disponibilità in base alla configurazione del gruppo di disponibilità. Se ad esempio il gruppo di disponibilità contiene tre repliche sincrone, l'agente imposterà REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
su 1
. Per informazioni dettagliate e altre opzioni di configurazione, vedere High availability and data protection for availability group configurations (Disponibilità elevata e protezione dati per le configurazioni del gruppo di disponibilità).
Creare una risorsa IP virtuale
Per creare la risorsa indirizzo IP virtuale, eseguire il comando seguente in un nodo. Usare un indirizzo IP statico disponibile nella rete. Sostituire l'indirizzo IP <10.128.16.240>
con un indirizzo IP valido.
sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<10.128.16.240>
Non esiste un nome di server virtuale equivalente in Pacemaker. Per usare una stringa di connessione che punta a un nome di server in formato stringa anziché a un indirizzo IP, registrare l'indirizzo della risorsa IP virtuale e il nome di server virtuale desiderato in DNS. Per le configurazioni di ripristino di emergenza, registrare il nome e l'indirizzo IP del server virtuale desiderato nei server DNS sia del sito primario sia del sito di ripristino di emergenza.
Aggiungere un vincolo di condivisione percorso
Quasi tutte le decisioni di un cluster Pacemaker, come la scelta della posizione in cui deve essere eseguita una risorsa, vengono eseguite tramite il confronto di punteggi. I punteggi vengono calcolati per singola risorsa. Il modulo per la gestione di risorse cluster sceglie il nodo con il punteggio più alto per una determinata risorsa. Se un nodo ha un punteggio negativo per una risorsa, questa non può essere eseguita su tale nodo.
In un cluster Pacemaker, è possibile modificare le decisioni del cluster applicando vincoli. I vincoli hanno un punteggio. Se un vincolo ha un punteggio inferiore a INFINITY
, Pacemaker lo interpreta come suggerimento. Un vincolo con punteggio INFINITY
è obbligatorio.
Per assicurarsi che la replica primaria e la risorsa IP virtuale vengano eseguite nello stesso host, definire un vincolo di condivisione percorso con punteggio INFINITY. Per aggiungere un vincolo di condivisione percorso, eseguire il comando seguente in un nodo.
RHEL 7
Quando si crea la risorsa ag_cluster
in RHEL 7, viene creata come ag_cluster-master
. Usare il comando seguente per RHEL 7:
sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master
RHEL 8
Quando si crea la risorsa ag_cluster
in RHEL 8, viene creata come ag_cluster-clone
. Usare il comando seguente per RHEL 8:
sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY with-rsc-role=Master
Aggiungere un vincolo di ordinamento
Il vincolo di condivisione percorso ha un vincolo di ordinamento implicito. Sposta la risorsa IP virtuale prima di spostare la risorsa del gruppo di disponibilità. Di seguito è indicata la sequenza di eventi predefinita:
L'utente invia pcs resource move
alla replica primaria del gruppo di disponibilità dal nodo 1 al nodo 2.
La risorsa IP virtuale viene arrestata sul nodo 1.
La risorsa IP virtuale viene avviata sul nodo 2.
Nota
A questo punto, l'indirizzo IP punta temporaneamente al nodo 2, mentre il nodo 2 è ancora una replica secondaria preliminare al failover.
La replica primaria del gruppo di disponibilità nel nodo 1 viene abbassata di livello e diventa secondaria.
La replica secondaria del gruppo di disponibilità nel nodo 2 viene alzata di livello e diventa primaria.
Per evitare che l'indirizzo IP punti temporaneamente al nodo con la replica secondaria preliminare al failover, aggiungere un vincolo di ordinamento.
Per aggiungere un vincolo di ordinamento, eseguire il comando seguente in un nodo:
RHEL 7
sudo pcs constraint order promote ag_cluster-master then start virtualip
RHEL 8
sudo pcs constraint order promote ag_cluster-clone then start virtualip
Importante
Dopo aver configurato il cluster e aggiunto il gruppo di disponibilità come risorsa cluster, non è possibile usare Transact-SQL per eseguire il failover delle risorse del gruppo di disponibilità. Le risorse cluster di SQL Server in Linux non sono strettamente associate al sistema operativo come in un cluster WSFC (Windows Server Failover Cluster). Il servizio SQL Server non è a conoscenza della presenza del cluster. Tutta l'orchestrazione viene eseguita tramite gli strumenti per la gestione di cluster. In RHEL o Ubuntu usare pcs
e in SLES usare crm
.
Per eseguire manualmente il failover per il gruppo di disponibilità, usare pcs
. Non avviare il failover con Transact-SQL. Per istruzioni, vedere Failover.
Contenuto correlato
Il livello di clustering si basa su SUSE High Availability Extension (HAE), a sua volta basato su Pacemaker.
Per altre informazioni su configurazione dei cluster, opzioni degli agenti delle risorse, gestione, procedure consigliate e suggerimenti, vedi SUSE Linux Enterprise High Availability Extension.
Roadmap
La procedura per la creazione di un gruppo di disponibilità per la disponibilità elevata è diversa tra i server Linux e un cluster di failover di Windows Server. Nell'elenco seguente sono descritti i passaggi principali:
Configurare SQL Server nei nodi del cluster.
Creare il gruppo di disponibilità.
Configurare un modulo per la gestione di risorse cluster, ad esempio Pacemaker. Le istruzioni sono riportate in questo articolo.
La modalità di configurazione di un modulo per la gestione di risorse cluster dipende dalla specifica distribuzione Linux.
Importante
Per la disponibilità elevata, negli ambienti di produzione è necessario un agente di isolamento. Gli esempi in questo articolo non usano agenti di isolamento. Sono illustrati solo a scopo di test e convalida.
Un cluster Linux usa l'isolamento per ripristinare uno stato noto del cluster. La modalità di configurazione dell'isolamento dipende dalla distribuzione e dall'ambiente. Attualmente l'isolamento non è disponibile in alcuni ambienti cloud. Per altre informazioni, vedi SUSE Linux Enterprise High Availability Extension.
Aggiungere il gruppo di disponibilità come risorsa nel cluster
Prerequisiti
Per completare lo scenario end-to-end seguente, sono necessari tre computer per distribuire il cluster a tre nodi. I passaggi seguenti illustrano come configurare questi server.
Il primo passaggio consiste nel configurare il sistema operativo nei nodi del cluster. Per questa procedura dettagliata, usare SLES 12 SP3 con un abbonamento valido per il componente aggiuntivo a disponibilità elevata.
Installare e configurare il servizio SQL Server in tutti i nodi. Per istruzioni dettagliate, vedi Linee guida per l'installazione di SQL Server in Linux.
Designare un nodo come primario e gli altri nodi come secondari. Usare questi termini per tutte le istruzioni riportate in questo documento.
Assicurarsi che i nodi da includere nel cluster possano comunicare tra loro.
L'esempio seguente mostra /etc/hosts
con gli indirizzi aggiuntivi per i tre nodi denominati SLES1, SLES2 e SLES3.
127.0.0.1 localhost
10.128.16.33 SLES1
10.128.16.77 SLES2
10.128.16.22 SLES3
Tutti i nodi del cluster devono poter accedere l'uno all'altro tramite SSH. Strumenti come hb_report
o crm_report
(per la risoluzione dei problemi) e History Explorer di Hawk richiedono l'accesso a SSH senza password da un nodo all'altro, altrimenti possono raccogliere dati solo dal nodo corrente. Se si usa una porta SSH non standard, usare l'opzione -X (vedere la pagina relativa a man
). Se, ad esempio, la porta SSH è 3479, richiamare un oggetto crm_report
con:
sudo crm_report -X "-p 3479" [...]
Per altre informazioni, vedere SLES Administration Guide - Miscellaneous (Guida all'amministrazione di SLES - Varie).
Creare un account di accesso di SQL Server per Pacemaker
In tutte le istanze di SQL Server crea un account di accesso al server per Pacemaker.
Il codice Transact-SQL seguente crea un account di accesso:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Al momento della creazione del gruppo di disponibilità, l'utente Pacemaker richiederà le autorizzazioni ALTER
, CONTROL
, e VIEW DEFINITION
per il gruppo di disponibilità, dopo che è stato creato, ma prima che vi vengano aggiunti nodi.
In tutte le istanze di SQL Server salva le credenziali per l'account di accesso di SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Nei server Linux configurare il gruppo di disponibilità e quindi le risorse cluster. Per configurare il gruppo di disponibilità, vedi Configurare un gruppo di disponibilità Always On di SQL Server per la disponibilità elevata in Linux
Installare l'estensione per la disponibilità elevata
Per informazioni di riferimento, vedi Installing SUSE Linux Enterprise Server and High Availability Extension (Installazione di SUSE Linux Enterprise Server e dell'estensione per la disponibilità elevata).
Installare il pacchetto dell'agente delle risorse SQL Server in entrambi i nodi.
sudo zypper install mssql-server-ha
Configurare il primo nodo
Vedi le istruzioni per l'installazione di SLES.
Accedi come root
alla macchina virtuale o fisica che vuoi usare come nodo del cluster.
Avviare lo script di bootstrap con il comando seguente:
sudo ha-cluster-init
Se NTP non è stato configurato in modo da essere eseguito in fase di avvio, viene visualizzato un messaggio.
Se decidi di continuare comunque, lo script genera automaticamente le chiavi per l'accesso SSH e per lo strumento di sincronizzazione Csync2 e avvia i servizi necessari per entrambi.
Per configurare il livello di comunicazione del cluster (Corosync):
Immettere un indirizzo di rete con cui stabilire l'associazione. Per impostazione predefinita, lo script propone l'indirizzo di rete eth0. In alternativa, immettere un indirizzo di rete diverso, ad esempio bond0.
Immettere un indirizzo multicast. Lo script propone un indirizzo casuale che è possibile usare come predefinito.
Immettere una porta multicast. Lo script propone 5405 come numero di porta predefinito.
Per configurare SBD ()
, immettere un percorso permanente per la partizione del dispositivo a blocchi che si vuole usare per SBD. Il percorso deve essere coerente in tutti i nodi del cluster.
Lo script avvierà infine il servizio Pacemaker per portare online il cluster a un nodo e abilitare l'interfaccia di gestione Web Hawk2. L'URL da usare per Hawk2 viene visualizzato sullo schermo.
Per informazioni dettagliate sul processo di installazione, vedere /var/log/sleha-bootstrap.log
. A questo punto è disponibile un cluster a un nodo in esecuzione. Verificare lo stato del cluster con crm status:
sudo crm status
È anche possibile vedere la configurazione del cluster con crm configure show xml
o crm configure show
.
La routine di bootstrap crea un utente Linux denominato hacluster con password linux. Sostituire la password predefinita con una password sicura, non appena possibile:
sudo passwd hacluster
Aggiungere nodi al cluster esistente
Se è in esecuzione un cluster con uno o più nodi, aggiungere altri nodi del cluster con lo script di bootstrap ha-cluster-join. Lo script deve semplicemente disporre dell'accesso a un nodo del cluster esistente e completerà automaticamente la configurazione di base nel computer corrente. Eseguire la procedura descritta di seguito:
Se i nodi del cluster esistenti sono stati configurati con il modulo per cluster YaST
, prima di eseguire ha-cluster-join
assicurarsi che i prerequisiti seguenti siano soddisfatti:
- L'utente ROOT nei nodi esistenti dispone di chiavi SSH per l'accesso senza password.
Csync2
è configurato nei nodi esistenti. Per altre informazioni, vedi Configurazione di Csync2 con YaST.
Accedi come root
alla macchina virtuale o fisica che dovrebbe essere aggiunta al cluster.
Avviare lo script di bootstrap con il comando seguente:
sudo ha-cluster-join
Se NTP non è stato configurato in modo da essere eseguito in fase di avvio, viene visualizzato un messaggio.
Se si decide di continuare comunque, verrà chiesto di specificare l'indirizzo IP di un nodo esistente. Immettere l'indirizzo IP.
Se non è già stato configurato un accesso SSH senza password tra entrambi i computer, verrà chiesto di specificare anche la password radice del nodo esistente.
Dopo aver eseguito l'accesso al nodo specificato, lo script copia la configurazione di Corosync, configura SSH e Csync2
, quindi porta online il computer corrente come nuovo nodo del cluster. Oltre a questo, avvia il servizio necessario per Hawk. Se lo spazio di archiviazione condiviso è stato configurato con OCFS2
, viene creata automaticamente anche la directory del punto di montaggio per il file system OCFS2
.
Ripetere i passaggi precedenti per tutti i computer da aggiungere al cluster.
Per informazioni dettagliate sulla procedura, vedere /var/log/ha-cluster-bootstrap.log
.
Verificare lo stato del cluster con sudo crm status
. Se il secondo nodo è stato aggiunto correttamente, l'output sarà simile al seguente:
sudo crm status
L'output sarà simile all'esempio seguente.
3 nodes configured
1 resource configured
Online: [ SLES1 SLES2 SLES3]
Full list of resources:
admin_addr (ocf::heartbeat:IPaddr2): Started node1
Nota
admin_addr
è la risorsa cluster IP virtuale definita durante la configurazione iniziale del cluster a un nodo.
Dopo aver aggiunto tutti i nodi, controllare se è necessario modificare no-quorum-policy nelle opzioni globali del cluster. Questa operazione è particolarmente importante per i cluster a due nodi.
Impostare la proprietà del cluster cluster-recheck-interval
cluster-recheck-interval
indica l'intervallo di polling in base al quale il cluster verifica se sono state apportate modifiche ai parametri delle risorse, ai vincoli o ad altre opzioni del cluster. Se una replica diventa inattiva, il cluster prova a riavviare la replica in base a un intervallo associato ai valori di failure-timeout
e cluster-recheck-interval
. Se, ad esempio, failure-timeout
è impostato su 60 secondi e cluster-recheck-interval
su 120, viene eseguito un tentativo di riavvio in base a un intervallo superiore a 60 secondi ma inferiore a 120. È consigliabile impostare failure-timeout su 60 secondi e cluster-recheck-interval
su un valore superiore a 60 secondi. L'impostazione di cluster-recheck-interval
su un valore inferiore non è consigliata.
Per aggiornare il valore della proprietà su 2 minutes
, eseguire il comando seguente:
crm configure property cluster-recheck-interval=2min
Se è già presente una risorsa del gruppo di disponibilità gestita da un cluster Pacemaker, il pacchetto Pacemaker 1.1.18-11.el7 ha introdotto una modifica del comportamento per l'impostazione del cluster start-failure-is-fatal
quando il relativo valore è false
. Questa modifica influisce sul flusso di lavoro del failover. Se si verifica un'interruzione in una replica primaria, è previsto il failover del cluster in una delle repliche secondarie disponibili. Al contrario, gli utenti noteranno che il cluster continuerà a provare ad avviare la replica primaria che ha subito l'interruzione. Se la replica primaria non torna mai online, a causa di un'interruzione permanente, il cluster non esegue mai il failover in un'altra replica secondaria disponibile. A causa di questa modifica, una configurazione precedentemente consigliata per impostare start-failure-is-fatal
non è più valida e l'impostazione deve essere ripristinata sul valore true
predefinito.
La risorsa del gruppo di disponibilità deve inoltre essere aggiornata in modo da includere la proprietà failure-timeout
.
Per aggiornare il valore della proprietà su true
, eseguire il comando seguente:
crm configure property start-failure-is-fatal=true
Per aggiornare la proprietà failure-timeout
della risorsa del gruppo di disponibilità esistente su 60s
, eseguire il comando seguente (sostituendo ag1
con il nome della risorsa):
crm configure edit ag1
Nell'editor di testo, aggiungi meta failure-timeout=60s
dopo qualsiasi param
s e prima di qualsiasi op
s.
Per altre informazioni sulle proprietà del cluster Pacemaker, vedere Configurazione delle risorse cluster.
Considerazioni per più schede di interfaccia di rete
Quando si configura la disponibilità elevata con server con più schede di interfaccia di rete, seguire questi suggerimenti:
Assicurati che il file hosts
sia configurato in modo che gli indirizzi IP del server per più schede di interfaccia di rete vengano risolti nel nome host del server Linux in ogni nodo.
Quando si configura il cluster usando Pacemaker, l'uso del nome host dei server deve configurare Corosync per impostare la configurazione per tutte le schede di interfaccia di rete. La comunicazione Pacemaker/Corosync deve avvenire su una singola scheda di interfaccia di rete. Dopo aver configurato il cluster Pacemaker, modifica la configurazione nel file corosync.conf
e aggiorna l'indirizzo IP per la scheda di interfaccia di rete dedicata da usare per la comunicazione Pacemaker/Corosync.
Il valore <hostname>
specificato nel file corosync.conf
deve essere uguale all'output specificato durante l'operazione di ricerca inversa (ping -a <ip_address>
) e deve essere il nome breve configurato nell'host. Assicurati che il file hosts
rappresenti anche l'indirizzo IP appropriato per la risoluzione dei nomi.
Di seguito sono evidenziate le modifiche apportate all'esempio del file corosync.conf
:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
I fornitori di cluster Pacemaker richiedono l’isolamento di un nodo non riuscito, usando un dispositivo di isolamento impostato per una configurazione di cluster supportata. Quando il modulo per la gestione di risorse cluster non riesce a determinare lo stato di un nodo o di una risorsa in un nodo, è possibile ripristinare uno stato noto del cluster tramite l'isolamento.
L'isolamento a livello di risorsa garantisce soprattutto che i dati non subiscano danni durante un'interruzione tramite la configurazione di una risorsa. È ad esempio possibile usare l'isolamento a livello di risorsa con DRBD (Distributed Replicated Block Device) per contrassegnare come obsoleto il disco su un nodo quando il collegamento di comunicazione diventa inattivo.
L'isolamento a livello di nodo consente di assicurarsi che un nodo non esegua alcuna risorsa. A tale scopo, è necessario reimpostare il nodo e la relativa implementazione in Pacemaker è denominata STONITH. Pacemaker supporta un'ampia gamma di dispositivi di isolamento, ad esempio un alimentatore di continuità o schede di interfaccia di gestione per i server.
Per altre informazioni, vedi:
In fase di inizializzazione del cluster, se non viene rilevata alcuna configurazione, l’isolamento è disabilitato. È possibile abilitarlo in un secondo momento tramite il comando seguente:
sudo crm configure property stonith-enabled=true
Importante
La disabilitazione dell’isolamento viene eseguita solo a scopo di test. Se si prevede di usare Pacemaker in un ambiente di produzione, è consigliabile pianificare un'implementazione dell’isolamento in base all'ambiente e mantenerla abilitata. SUSE non fornisce agenti di isolamento per ambienti cloud (incluso Azure) o Hyper-V. Di conseguenza, il fornitore del cluster non offre supporto per l'esecuzione di cluster di produzione in questi ambienti. Questo problema è attualmente in fase di studio e una soluzione sarà disponibile nelle versioni future.
Vedi SLES Administration Guide (Guida all'amministrazione di SLES).
Abilitare Pacemaker
Abilitare Pacemaker per consentirne l'avvio automatico.
In ogni nodo del cluster eseguire il comando seguente.
systemctl enable pacemaker
Creare una risorsa del gruppo di disponibilità
Il comando seguente crea e configura la risorsa per tre repliche del gruppo di disponibilità [ag1]. Le operazioni di monitoraggio e i timeout devono essere definiti in modo esplicito in SLES tenendo conto del fatto che i timeout sono fortemente dipendenti dai carichi di lavoro e devono essere definiti con precisione per ogni distribuzione.
Eseguire il comando seguente in uno dei nodi del cluster:
Eseguire crm configure
per aprire il prompt di crm:
sudo crm configure
Nel prompt crm eseguire il comando seguente per configurare le proprietà della risorsa.
primitive ag_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag_cluster ag_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true" \
commit
Nota
Quando si crea la risorsa, e periodicamente dopo la creazione, l'agente delle risorse Pacemaker imposta automaticamente il valore di REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
nel gruppo di disponibilità in base alla configurazione del gruppo di disponibilità. Se ad esempio il gruppo di disponibilità contiene tre repliche sincrone, l'agente imposterà REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
su 1
. Per informazioni dettagliate e altre opzioni di configurazione, vedere High availability and data protection for availability group configurations (Disponibilità elevata e protezione dati per le configurazioni del gruppo di disponibilità).
Creare una risorsa IP virtuale
Se la risorsa IP virtuale non è stata creata al momento dell'esecuzione di ha-cluster-init
, è possibile crearla adesso. Il comando seguente crea una risorsa IP virtuale. Sostituire <**0.0.0.0**>
con un indirizzo disponibile della rete e <**24**>
con il numero di bit nella subnet mask CIDR. Eseguire il comando in un nodo.
crm configure \
primitive admin_addr \
ocf:heartbeat:IPaddr2 \
params ip=<**0.0.0.0**> \
cidr_netmask=<**24**>
Aggiungere un vincolo di condivisione percorso
Quasi tutte le decisioni di un cluster Pacemaker, come la scelta della posizione in cui deve essere eseguita una risorsa, vengono eseguite tramite il confronto di punteggi. Il calcolo dei punteggi viene eseguito per singola risorsa e il modulo per la gestione di risorse cluster sceglie il nodo con il punteggio più alto per una determinata risorsa. Se un nodo ha un punteggio negativo per una risorsa, la risorsa non può essere eseguita in tale nodo. È possibile modificare le decisioni del cluster con vincoli. I vincoli hanno un punteggio. Se un vincolo ha un punteggio inferiore a INFINITY, è solo una raccomandazione. Un punteggio INFINITY indica invece che il vincolo è obbligatorio. Per assicurarsi che la replica primaria del gruppo di disponibilità e la risorsa IP virtuale vengano eseguite nello stesso host, definire un vincolo di condivisione percorso con punteggio INFINITY.
Per impostare un vincolo di condivisione percorso per fare in modo che la risorsa IP virtuale venga eseguita nello stesso nodo del nodo primario, esegui il comando seguente in un nodo:
crm configure
colocation vip_on_master inf: \
admin_addr ms-ag_cluster:Master
commit
Aggiungere un vincolo di ordinamento
Il vincolo di condivisione percorso ha un vincolo di ordinamento implicito. Sposta la risorsa IP virtuale prima di spostare la risorsa del gruppo di disponibilità. Di seguito è indicata la sequenza di eventi predefinita:
- L'utente invia
resource migrate
alla replica primaria del gruppo di disponibilità dal nodo 1 al nodo 2.
- La risorsa IP virtuale viene arrestata sul nodo 1.
- La risorsa IP virtuale viene avviata sul nodo 2. A questo punto, l'indirizzo IP punta temporaneamente al nodo 2, mentre il nodo 2 è ancora una replica secondaria preliminare al failover.
- La replica master del gruppo di disponibilità nel nodo 1 viene abbassata di livello.
- Il gruppo di disponibilità nel nodo 2 viene alzato di livello a master.
Per evitare che l'indirizzo IP punti temporaneamente al nodo con la replica secondaria preliminare al failover, aggiungere un vincolo di ordinamento.
Per aggiungere un vincolo di ordinamento, eseguire il comando seguente in un nodo:
sudo crm configure \
order ag_first inf: ms-ag_cluster:promote admin_addr:start
Importante
Dopo aver configurato il cluster e aggiunto il gruppo di disponibilità come risorsa cluster, non è possibile usare Transact-SQL per eseguire il failover delle risorse del gruppo di disponibilità. Le risorse cluster di SQL Server in Linux non sono strettamente associate al sistema operativo come in un cluster WSFC (Windows Server Failover Cluster). Il servizio SQL Server non è a conoscenza della presenza del cluster. Tutta l'orchestrazione viene eseguita tramite gli strumenti per la gestione di cluster. In SLES usare crm
.
Per eseguire manualmente il failover per il gruppo di disponibilità, usare crm
. Non avviare il failover con Transact-SQL. Per altre informazioni, vedere Failover.
Per altre informazioni, vedi:
Contenuto correlato
Roadmap
I passaggi da seguire per creare un gruppo di disponibilità sui server Linux per la disponibilità elevata sono diversi da quelli relativi a un cluster di failover di Windows Server. Nell'elenco seguente sono descritti i passaggi principali:
Linee guida per l'installazione di SQL Server in Linux.
Configura un gruppo di disponibilità Always On di SQL Server per la disponibilità elevata in Linux.
Configurare un modulo per la gestione di risorse cluster, ad esempio Pacemaker. Le istruzioni sono riportate in questo articolo.
La modalità di configurazione di un modulo per la gestione di risorse cluster dipende dalla specifica distribuzione Linux.
Importante
Per la disponibilità elevata, negli ambienti di produzione è necessario un agente di isolamento. Gli esempi in questo articolo non usano agenti di isolamento. Sono illustrati solo a scopo di test e convalida.
Un cluster Linux usa l'isolamento per ripristinare uno stato noto del cluster. La modalità di configurazione dell'isolamento dipende dalla distribuzione e dall'ambiente. Attualmente l'isolamento non è disponibile in alcuni ambienti cloud.
L'isolamento viene in genere implementato nel sistema operativo e dipende dall'ambiente. Per istruzioni sull'isolamento nel sistema operativo, vedere la documentazione relativa al server di distribuzione.
Aggiungere il gruppo di disponibilità come risorsa nel cluster.
Apri le porte del firewall in tutti i nodi. Aprire la porta per il servizio Pacemaker per la disponibilità elevata, l'istanza di SQL Server e l'endpoint del gruppo di disponibilità. La porta TCP predefinita per il server che esegue SQL Server è la 1433
.
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 21064/tcp
sudo ufw allow 5405/udp
sudo ufw allow 1433/tcp # Replace with TDS endpoint
sudo ufw allow 5022/tcp # Replace with DATA_MIRRORING endpoint
sudo ufw reload
In alternativa, è possibile disabilitare il firewall, ma questo non è consigliato in un ambiente di produzione:
sudo ufw disable
Installare i pacchetti Pacemaker. In tutti i nodi, esegui i comandi seguenti per Ubuntu 20.04. Per altre informazioni sull'installazione nelle versioni precedenti, vedi Ubuntu HA - MS SQL Server in Azure.
sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents fence-agents corosync python3-azure
Impostare la password per l'utente predefinito creato durante l'installazione dei pacchetti Pacemaker e Corosync. Usare la stessa password in tutti i nodi.
sudo passwd hacluster
Creare il cluster
Prima di creare un cluster, è necessario creare una chiave di autenticazione nel server primario e copiarla negli altri server che partecipano al gruppo di disponibilità.
Usa lo script seguente per creare una chiave di autenticazione nel server primario:
sudo corosync-keygen
È possibile usare scp
per copiare la chiave generata in altri server:
sudo scp /etc/corosync/authkey dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/authkey dbadmin@server-03:/etc/corosync
Per creare il cluster, modifica il file /etc/corosync/corosync.conf
nel server primario:
sudo vim /etc/corosync/corosync.conf
Il file corosync.conf
dovrebbe essere simile a quello riportato nell'esempio seguente:
totem {
version: 2
cluster_name: agclustername
transport: udpu
crypto_cipher: none
crypto_hash: none
}
logging {
fileline: off
to_stderr: yes
to_logfile: yes
logfile: /var/log/corosync/corosync.log
to_syslog: yes
debug: off
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
}
nodelist {
node {
name: server-01
nodeid: 1
ring0_addr: 10.0.0.4
}
node {
name: server-02
nodeid: 2
ring0_addr: 10.0.0.5
}
node {
name: server-03
nodeid: 3
ring0_addr: 10.0.0.6
}
}
Sostituisci il file corosync.conf
in altri nodi:
sudo scp /etc/corosync/corosync.conf dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/corosync.conf dbadmin@server-03:/etc/corosync
Riavvia i servizi pacemaker
e corosync
:
sudo systemctl restart pacemaker corosync
Verifica lo stato del cluster e verifica la configurazione:
sudo crm status
Considerazioni per più schede di interfaccia di rete
Quando si configura la disponibilità elevata con server con più schede di interfaccia di rete, seguire questi suggerimenti:
Assicurati che il file hosts
sia configurato in modo che gli indirizzi IP del server per più schede di interfaccia di rete vengano risolti nel nome host del server Linux in ogni nodo.
Quando si configura il cluster usando Pacemaker, l'uso del nome host dei server deve configurare Corosync per impostare la configurazione per tutte le schede di interfaccia di rete. La comunicazione Pacemaker/Corosync deve avvenire su una singola scheda di interfaccia di rete. Dopo aver configurato il cluster Pacemaker, modifica la configurazione nel file corosync.conf
e aggiorna l'indirizzo IP per la scheda di interfaccia di rete dedicata da usare per la comunicazione Pacemaker/Corosync.
Il valore <hostname>
specificato nel file corosync.conf
deve essere uguale all'output specificato durante l'operazione di ricerca inversa (ping -a <ip_address>
) e deve essere il nome breve configurato nell'host. Assicurati che il file hosts
rappresenti anche l'indirizzo IP appropriato per la risoluzione dei nomi.
Di seguito sono evidenziate le modifiche apportate all'esempio del file corosync.conf
:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
I fornitori di cluster Pacemaker richiedono l’isolamento di un nodo non riuscito, usando un dispositivo di isolamento impostato per una configurazione di cluster supportata. Quando il modulo per la gestione di risorse cluster non riesce a determinare lo stato di un nodo o di una risorsa in un nodo, è possibile ripristinare uno stato noto del cluster tramite l'isolamento.
L'isolamento a livello di risorsa garantisce che non si verifichi alcun danneggiamento dei dati in caso di interruzione. È ad esempio possibile usare l'isolamento a livello di risorsa con DRBD (Distributed Replicated Block Device) per contrassegnare come obsoleto il disco su un nodo quando il collegamento di comunicazione diventa inattivo.
L'isolamento a livello di nodo consente di assicurarsi che un nodo non esegua alcuna risorsa. A tale scopo, è necessario reimpostare il nodo e la relativa implementazione in Pacemaker è denominata STONITH. Pacemaker supporta un'ampia gamma di dispositivi di isolamento, ad esempio un gruppo di continuità o schede di interfaccia di gestione per i server.
Per altre informazioni, vedere Pacemaker Clusters from Scratch (Cluster Pacemaker da zero) e Fencing and Stonith (Isolamento e STONITH).
Poiché l'isolamento a livello di nodo dipende principalmente dall'ambiente in uso, viene disabilitato per questa esercitazione e può essere configurato in un secondo momento. Eseguire lo script seguente nel nodo primario:
sudo crm configure property stonith-enabled=false
In questo esempio la disabilitazione dell’isolamento viene eseguita solo a scopo di test. Se si prevede di usare Pacemaker in un ambiente di produzione, è consigliabile pianificare un'implementazione dell’isolamento in base all'ambiente e mantenerla abilitata. Contattare il fornitore del sistema operativo per informazioni sugli agenti di isolamento per una distribuzione specifica.
Impostare la proprietà del cluster cluster-recheck-interval
La proprietà cluster-recheck-interval
indica l'intervallo di polling in base al quale il cluster verifica se sono state apportate modifiche ai parametri delle risorse, ai vincoli o ad altre opzioni del cluster. Se una replica diventa inattiva, il cluster prova a riavviare la replica in base a un intervallo associato ai valori di failure-timeout
e cluster-recheck-interval
. Se, ad esempio, failure-timeout
è impostato su 60 secondi e cluster-recheck-interval
su 120, viene eseguito un tentativo di riavvio in base a un intervallo superiore a 60 secondi ma inferiore a 120. È necessario impostare failure-timeout
su 60 secondi e cluster-recheck-interval
su un valore maggiore di 60 secondi. L'impostazione di cluster-recheck-interval
su un valore inferiore non è consigliata.
Per aggiornare il valore della proprietà su 2 minutes
, eseguire il comando seguente:
sudo crm configure property cluster-recheck-interval=2min
Se è già presente una risorsa del gruppo di disponibilità gestita da un cluster Pacemaker, il pacchetto Pacemaker 1.1.18-11.el7 ha introdotto una modifica del comportamento per l'impostazione del cluster start-failure-is-fatal
quando il relativo valore è false
. Questa modifica influisce sul flusso di lavoro del failover. Se si verifica un'interruzione in una replica primaria, è previsto il failover del cluster in una delle repliche secondarie disponibili. Al contrario, gli utenti noteranno che il cluster continuerà a provare ad avviare la replica primaria che ha subito l'interruzione. Se la replica primaria non torna mai online, a causa di un'interruzione permanente, il cluster non esegue mai il failover in un'altra replica secondaria disponibile. A causa di questa modifica, una configurazione precedentemente consigliata per impostare start-failure-is-fatal
non è più valida e l'impostazione deve essere ripristinata sul valore true
predefinito.
La risorsa del gruppo di disponibilità deve inoltre essere aggiornata in modo da includere la proprietà failure-timeout
.
Per aggiornare il valore della proprietà su true
, eseguire il comando seguente:
sudo crm configure property start-failure-is-fatal=true
Per aggiornare la proprietà failure-timeout
della risorsa del gruppo di disponibilità esistente su 60s
, eseguire il comando seguente (sostituendo ag1
con il nome della risorsa):
sudo crm configure meta failure-timeout=60s
Installare l'agente delle risorse SQL Server per l'integrazione con Pacemaker
Eseguire i comandi seguenti in tutti i nodi.
sudo apt-get install mssql-server-ha
Creare un account di accesso di SQL Server per Pacemaker
In tutte le istanze di SQL Server crea un account di accesso al server per Pacemaker.
Il codice Transact-SQL seguente crea un account di accesso:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Al momento della creazione del gruppo di disponibilità, l'utente Pacemaker richiederà le autorizzazioni ALTER
, CONTROL
, e VIEW DEFINITION
per il gruppo di disponibilità, dopo che è stato creato, ma prima che vi vengano aggiunti nodi.
In tutte le istanze di SQL Server salva le credenziali per l'account di accesso di SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Creare una risorsa del gruppo di disponibilità
Per creare la risorsa del gruppo di disponibilità, usa il comando sudo crm configure
per impostare le proprietà della risorsa. L’esempio seguente crea una risorsa primaria/replica ocf:mssql:ag
per il gruppo di disponibilità con il nome ag1
.
~$ sudo crm
configure
primitive ag1_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 ag1_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
commit
Nota
Quando si crea la risorsa, e periodicamente dopo la creazione, l'agente delle risorse Pacemaker imposta automaticamente il valore di REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
nel gruppo di disponibilità in base alla configurazione del gruppo di disponibilità. Se ad esempio il gruppo di disponibilità contiene tre repliche sincrone, l'agente imposterà REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
su 1
. Per informazioni dettagliate e altre opzioni di configurazione, vedere High availability and data protection for availability group configurations (Disponibilità elevata e protezione dati per le configurazioni del gruppo di disponibilità).
Creare una risorsa IP virtuale
Per creare la risorsa indirizzo IP virtuale, eseguire il comando seguente in un nodo. Usare un indirizzo IP statico disponibile nella rete. Prima di eseguire lo script, sostituire i valori compresi tra < ... >
con un indirizzo IP valido.
sudo crm configure primitive virtualip \
ocf:heartbeat:IPaddr2 \
params ip=10.128.16.240
Non esiste un nome di server virtuale equivalente in Pacemaker. Per usare una stringa di connessione che punta a un nome di server in formato stringa e non usa l'indirizzo IP, registrare l'indirizzo della risorsa IP e il nome di server virtuale desiderato in DNS. Per le configurazioni di ripristino di emergenza, registrare il nome e l'indirizzo IP del server virtuale desiderato nei server DNS sia del sito primario sia del sito di ripristino di emergenza.
Aggiungere un vincolo di condivisione percorso
Quasi tutte le decisioni di un cluster Pacemaker, come la scelta della posizione in cui deve essere eseguita una risorsa, vengono eseguite tramite il confronto di punteggi. Il calcolo dei punteggi viene eseguito per singola risorsa e il modulo per la gestione di risorse cluster sceglie il nodo con il punteggio più alto per una determinata risorsa. Se un nodo ha un punteggio negativo per una risorsa, questa non può essere eseguita su tale nodo.
Usare i vincoli per configurare le decisioni del cluster. I vincoli hanno un punteggio. Se un vincolo ha un punteggio inferiore a INFINITY, è solo una raccomandazione. Un punteggio INFINITY indica invece che il vincolo è obbligatorio.
Per assicurarsi che la replica primaria e la risorsa IP virtuale si trovino nello stesso host, definire un vincolo di condivisione percorso con punteggio INFINITY. Per aggiungere un vincolo di condivisione percorso, eseguire il comando seguente in un nodo.
sudo crm configure colocation ag-with-listener INFINITY: virtualip-group ms-ag1:Master
Aggiungere un vincolo di ordinamento
Il vincolo di condivisione percorso ha un vincolo di ordinamento implicito. Sposta la risorsa IP virtuale prima di spostare la risorsa del gruppo di disponibilità. Di seguito è indicata la sequenza di eventi predefinita:
L'utente invia pcs resource move
alla replica primaria del gruppo di disponibilità da node1
a node2
.
La risorsa IP virtuale viene arrestata su node1
.
La risorsa IP virtuale viene avviata su node2
.
A questo punto, l'indirizzo IP punta temporaneamente a node2
, mentre node2
è ancora una replica secondaria preliminare al failover.
La replica primaria del gruppo di disponibilità in node1
viene abbassata di livello e diventa secondaria.
La replica secondaria del gruppo di disponibilità in node2
viene alzata di livello e diventa primaria.
Per evitare che l'indirizzo IP punti temporaneamente al nodo con la replica secondaria preliminare al failover, aggiungere un vincolo di ordinamento.
Per aggiungere un vincolo di ordinamento, eseguire il comando seguente in un nodo:
sudo crm configure order ag-before-listener Mandatory: ms-ag1:promote virtualip-group:start
Dopo aver configurato il cluster e aggiunto il gruppo di disponibilità come risorsa cluster, non è possibile usare Transact-SQL per eseguire il failover delle risorse del gruppo di disponibilità. Le risorse cluster di SQL Server in Linux non sono strettamente associate al sistema operativo come in un cluster WSFC (Windows Server Failover Cluster). Il servizio SQL Server non è a conoscenza della presenza del cluster. Tutta l'orchestrazione viene eseguita tramite gli strumenti per la gestione di cluster.
Contenuto correlato