Configurare un cluster Ubuntu e una risorsa del gruppo di disponibilità

Si applica a: SQL Server (tutte le versioni supportate) - Linux

Questo articolo descrive come creare un cluster a tre nodi in Ubuntu 20.04 e aggiungere un gruppo di disponibilità creato in precedenza come risorsa nel cluster. Per la disponibilità elevata, un gruppo di disponibilità in Linux richiede tre nodi. Vedere Disponibilità elevata e protezione dei dati per le configurazioni del gruppo di disponibilità.

l'integrazione di SQL Server con Pacemaker in Linux non è associata a WSFC in Windows. Dall'interno di SQL Server, non esiste alcuna conoscenza della presenza del cluster, tutte le orchestrazioni provengono dall'esterno e il servizio viene controllato come istanza autonoma dalla gestione cluster. Inoltre, il nome della rete virtuale è specifico per WSFC e non esiste alcun equivalente dello stesso in Pacemaker. Le DMV Always On che eseguono query sulle informazioni del cluster restituiscono righe vuote.

È comunque possibile creare un listener per la riconnessione trasparente dopo il failover, ma è necessario registrare manualmente il nome del listener nel server DNS con l'INDIRIZZO IP usato per creare la risorsa IP virtuale (come illustrato nelle sezioni seguenti).

Le sezioni seguenti illustrano i passaggi per configurare una soluzione cluster di failover.

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:

  1. Configurare SQL Server nei nodi del cluster.

  2. Creare il gruppo di disponibilità.

  3. Configurare un modulo per la gestione di risorse cluster, ad esempio Pacemaker. Le istruzioni sono riportate in questo documento.

    La modalità di configurazione di un modulo per la gestione di risorse cluster dipende dalla specifica distribuzione Linux.

    Gli ambienti di produzione richiedono un agente di fencing, ad esempio STONITH per la disponibilità elevata. Le dimostrazioni in questa documentazione non usano agenti di fencing. 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. In questo momento, la fencing 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).

    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.

  4. Aggiungere il gruppo di disponibilità come risorsa nel cluster.

Installare e configurare Pacemaker in ogni nodo del cluster

  1. Aprire 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 semplicemente il firewall:

    sudo ufw disable
    
  2. Installare i pacchetti Pacemaker. In tutti i nodi eseguire i comandi seguenti:

    sudo apt-get install pacemaker pcs fence-agents resource-agents
    
  3. 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
    

Abilitare e avviare il servizio pcsd e Pacemaker

Il comando seguente abilita e avvia il pcsd servizio e Pacemaker. Eseguirlo in tutti i nodi. In questo modo, i nodi potranno essere aggiunti nuovamente al cluster dopo il riavvio.

sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker

Il enable pacemaker comando può completare l'errore seguente:

pacemaker Default-Start contains no runlevels, aborting.

L'errore è innocuo e la configurazione del cluster può continuare.

Creare il cluster

  1. Rimuovere eventuali configurazioni cluster esistenti da tutti i nodi.

    L'esecuzione sudo apt-get install pcs di installa pacemaker, corosync e pc contemporaneamente e avvia l'esecuzione di tutti i 3 servizi. L'avvio di corosync genera un file modello /etc/cluster/corosync.conf . Per avere esito positivo, questo file non dovrebbe esistere, quindi la soluzione alternativa consiste nell'arrestare pacemaker o corosync ed eliminare /etc/cluster/corosync.conf, quindi i passaggi successivi vengono completati correttamente. Il comando pcs cluster destroy esegue la stessa cosa e è possibile usarlo come passaggio di configurazione iniziale del cluster una sola volta.

    Il comando seguente rimuove tutti i file di configurazione del cluster esistenti e arresta tutti i servizi del cluster, eliminando definitivamente il cluster. Eseguirlo come primo passaggio in un ambiente di pre-produzione. Si noti che pcs cluster destroy disabilita il servizio Pacemaker e deve essere riabilitato. Eseguire il comando seguente in tutti i nodi.

    Avviso

    Il comando elimina definitivamente tutte le risorse cluster esistenti.

    sudo pcs cluster destroy 
    sudo systemctl enable pacemaker
    
  2. Creare il cluster.

    L'avvio del cluster (pcs cluster start) potrebbe non riuscire con l'errore seguente, perché il file di log configurato in /etc/corosync/corosync.conf, che viene creato quando viene eseguito il comando di installazione del cluster, non è corretto. Per risolvere questo problema, modificare il file di log in /var/log/corosync/corosync.log. In alternativa, è possibile creare il /var/log/cluster/corosync.log file autonomamente.

    Job for corosync.service failed because the control process exited with error code. 
    See "systemctl status corosync.service" and "journalctl -xe" for details.
    

    Il comando seguente crea un cluster a tre nodi. Prima di eseguire lo script, sostituire i valori compresi tra < ... >. Eseguire il comando seguente nel nodo primario.

    sudo pcs host auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
    sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
    sudo pcs cluster start --all
    sudo pcs cluster enable --all
    

    Nell'implementazione corrente dell'agente di risorse SQL Server, il nome del nodo deve corrispondere alla ServerName proprietà dell'istanza. Ad esempio, se il nome del nodo è node1, assicurarsi SERVERPROPERTY('ServerName') di restituire node1 nell'istanza di SQL Server. Se si verifica una mancata corrispondenza, le repliche verranno inserite in uno stato di risoluzione dopo la creazione della risorsa Pacemaker.

    Uno scenario in cui questa regola è importante quando si usano nomi di dominio completi (FQDN). Ad esempio, se si usa node1.yourdomain.com come nome del nodo durante l'installazione del cluster, assicurarsi SERVERPROPERTY('ServerName') di restituire node1.yourdomain.come non solo node1. Le possibili soluzioni alternative per questo problema sono:

    • Rinominare il nome host nel nome di dominio completo e usare le sp_dropserver stored procedure e sp_addserver per assicurarsi che i metadati in SQL Server corrispondano alla modifica.
    • Usare l'opzione addr nel pcs cluster auth comando per corrispondere al nome del SERVERPROPERTY('ServerName') nodo al valore e usare un INDIRIZZO IP statico come indirizzo del nodo.

    Se in precedenza è stato configurato un cluster negli stessi nodi, è necessario usare l'opzione --force quando si esegue pcs cluster setup. Ciò equivale all'esecuzione pcs cluster destroydi e il servizio Pacemaker deve essere riabilitare usando sudo systemctl enable pacemaker.

Configurare l'isolamento (STONITH)

I fornitori di cluster Pacemaker richiedono l'abilitazione di STONITH e un dispositivo di isolamento impostato per una configurazione di cluster supportata. (STONITH sta per "sparare l'altro nodo nella testa". Quando gestione risorse cluster non è in grado di determinare lo stato di un nodo o di una risorsa in un nodo, la fencing viene usata per portare di nuovo il cluster a uno stato noto.

La fencing a livello di risorsa garantisce che non si verifichi alcun danneggiamento dei dati se si verifica un'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.

La fencing a livello di nodo garantisce che un nodo non esegua alcuna risorsa. Questa operazione viene eseguita reimpostando il nodo e l'implementazione di Pacemaker di esso è denominata STONITH. Pacemaker supporta un'ampia gamma di dispositivi di fencing, ad esempio una scheda di alimentazione non interruptibile o schede di interfaccia di gestione per i server.

Per altre informazioni, vedere Cluster Pacemaker da Zero e Fencing 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 pcs property set stonith-enabled=false

In questo esempio, la disabilitazione di STONITH è solo a scopo di test. Se si prevede di usare Pacemaker in un ambiente di produzione, è consigliabile pianificare un'implementazione di STONITH 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 cluster-recheck-interval proprietà indica l'intervallo di polling in corrispondenza del quale il cluster controlla le modifiche apportate 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 cluster-recheck-interval su un valore più piccolo non è consigliata.

Per aggiornare il valore della proprietà su 2 minutes, eseguire il comando seguente:

sudo pcs property set cluster-recheck-interval=2min

Se si dispone già di una risorsa del gruppo di disponibilità gestita da un cluster Pacemaker, si noti che tutte le distribuzioni che usano il pacchetto Pacemaker 1.1.18-11.el7 o versioni successive, introdurre una modifica del comportamento per l'impostazione del start-failure-is-fatal cluster quando il relativo valore è false. Questa modifica influisce sul flusso di lavoro del failover. Se una replica primaria esegue un'interruzione, il cluster deve eseguire il failover 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 consigliata precedentemente da impostare start-failure-is-fatal non è più valida e l'impostazione deve essere ripristinata al relativo valore predefinito di true

La risorsa del gruppo di disponibilità deve inoltre essere aggiornata in modo da includere la proprietà failover-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 del gruppo di disponibilità esistente su 60s, eseguire il comando seguente (sostituendo ag1 con il nome della risorsa):

pcs resource update ag1 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

  1. In tutte le istanze di SQL Server creare un account di accesso 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.

  2. In tutte le istanze di SQL Server salvare 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 primario/replica per il ocf:mssql:ag gruppo di disponibilità con il nome ag1.

sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=30s 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. Prima di eseguire lo script, sostituire i valori compresi tra < ... >con un indirizzo IP valido.

sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<10.128.16.240>

Non esiste alcun nome del 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, la risorsa non può essere eseguita in 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 di INFINITY significa che è 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 pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY

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:

  1. Problemi pcs resource move utente al gruppo di disponibilità primario da node1 a node2.

  2. La risorsa IP virtuale si arresta in node1.

  3. La risorsa IP virtuale inizia su node2.

    A questo punto, l'indirizzo IP punta node2 temporaneamente a mentre node2 è ancora un secondario di pre-failover.

  4. Il gruppo di disponibilità primario in node1 viene demoto in secondario.

  5. Il gruppo di disponibilità secondario viene node2 promosso a primario.

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 pcs constraint order promote ag_cluster-clone then start virtualip

Dopo aver configurato il cluster e aggiunto il gruppo di disponibilità come risorsa del cluster, non è possibile usare Transact-SQL per eseguire il failover delle risorse del gruppo di disponibilità. SQL Server risorse del cluster in Linux non sono associate strettamente al sistema operativo in quanto si trovano in un cluster di failover di Windows Server (WSFC). 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 è consigliabile usare pcs.

Passaggi successivi