Questo tutorial descrive come eseguire il deployment di un sistema di database Microsoft SQL Server su Linux utilizzando un gruppo di disponibilità sempre attivo (AOAG) e Pacemaker come soluzione ad alta disponibilità e ripristino di emergenza (RE). Ai fini di questo documento, un'emergenza è un evento in cui un database principale ha problemi o non è più disponibile.
Un database primario può presentare errori se la regione in cui si trova ha esito negativo o diventa inaccessibile. Anche se una regione è disponibile e funziona normalmente, un database primario potrebbe non funzionare a causa di un errore di sistema. In questi casi, il ripristino di emergenza è il processo di messa a disposizione dei client di un database secondario affinché continui a essere elaborato.
Questo tutorial è rivolto ad architetti di database, amministratori e ingegneri.
Obiettivi
- Esegui il deployment di SQL Server su Linux
- Crea un gruppo di disponibilità sempre attivo per l'alta disponibilità e il ripristino di emergenza
- Installa e configura Pacemaker per gestire il failover del cluster SQL Server
- Configura un bilanciatore del carico per instradare il traffico al gruppo di disponibilità con SQL Server
- Configura una recinzione STONITH (Scatta l'altro nodo nella testa) per garantire l'integrità dell'alta disponibilità
- Esegui un test di failover per assicurarti che il cluster SQL Server funzioni come previsto
Costi
Questo tutorial utilizza i componenti fatturabili di Google Cloud, tra cui:
Utilizza il Calcolatore prezzi per generare una stima dei costi in base all'utilizzo previsto.
Prima di iniziare
Per questo tutorial è necessario un progetto Google Cloud. Puoi crearne uno nuovo o selezionare un progetto già creato:
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
- Assicurati che l'API NetApp Cloud Volumes sia abilitata per il tuo progetto Google Cloud.
-
Nella console Google Cloud, attiva Cloud Shell.
Prepara il progetto e la rete
Per preparare il progetto Google Cloud e il VPC per il deployment dei gruppi di disponibilità Always On di SQL Server, segui questi passaggi:
Nella console Google Cloud, apri Cloud Shell facendo clic sul pulsante Attiva Cloud Shell
.
Imposta l'ID progetto predefinito:
gcloud config set project
PROJECT_ID
Sostituisci
PROJECT_ID
con l'ID del tuo progetto Google Cloud.Imposta la tua regione predefinita:
gcloud config set compute/region
REGION
Sostituisci
REGION
con l'ID della regione in cui vuoi eseguire il deployment.Imposta la tua zona predefinita:
gcloud config set compute/zone
ZONE
Sostituisci
ZONE
con l'ID della zona in cui vuoi eseguire il deployment. Deve essere una zona valida nella regione specificata nel passaggio precedente.
Crea VM Linux
Per raggiungere l'alta disponibilità e il quorum per il cluster SQL Server, esegui il deployment di tre macchine virtuali (VM) Linux per ospitare il cluster SQL Server.
Inizializza le seguenti variabili:
PD_SIZE=30 MACHINE_TYPE=n2-standard-8
Crea le VM Linux:
gcloud compute instances create node-1 \ --project=
PROJECT_ID
\ --zoneREGION
-a \ --machine-type $MACHINE_TYPE \ --subnetSUBNET_NAME
\ --create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID
/zones/ZONE
/diskTypes/pd-balanced \ --scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write gcloud compute instances create node-2 \ --project=PROJECT_ID
\ --zoneREGION
-b \ --machine-type $MACHINE_TYPE \ --subnetSUBNET_NAME
\ --create-disk=auto-delete=yes,boot=yes,device-name=node-2,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID
/zones/ZONE
/diskTypes/pd-balanced \ --scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write gcloud compute instances create node-3 \ --project=PROJECT_ID
\ --zoneREGION
-c \ --machine-type $MACHINE_TYPE \ --subnetSUBNET_NAME
\ --create-disk=auto-delete=yes,boot=yes,device-name=node-3,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID
/zones/ZONE
/diskTypes/pd-balanced \ --scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_writeSostituisci la subnet
SUBNET_NAME
con il nome della tua subnet VPC.Aggiorna il file hosts su
node-1
,node-2
enode-3
:- Connettiti a ciascuna delle tue VM tramite SSH. Per ulteriori informazioni, consulta la documentazione relativa alla connessione alle VM Linux.
Apri il file hosts per la modifica.
sudo vi /etc/hosts
Trova l'indirizzo IP interno per ogni VM Linux e aggiungi le voci dell'host alla fine del file.
NODE1_INTERNAL_IP
node-1NODE2_INTERNAL_IP
node-2NODE3_INTERNAL_IP
node-3Sostituisci
NODE1_INTERNAL_IP
,NODE2_INTERNAL_IP
eNODE3_INTERNAL_IP
con l'indirizzo IP interno di ogni VM Linux.
Controlla la comunicazione tra le tue VM. Tutte le VM che fanno parte del gruppo di disponibilità Always On devono essere in grado di comunicare con altre VM:
Torna a ogni VM Linux, esegui i comandi da ogni VM e verifica che tutte le VM possano comunicare tra loro.
ping -c 4 node-1 ping -c 4 node-2 ping -c 4 node-3
Installare e configurare SQL Server
Scarica, installa e configura il motore SQL Server sulle tre VM Linux che parteciperanno al gruppo di disponibilità Always On.
SSH a
node-1
,node-2
enode-3
ed esegui questi passaggi:Importa le chiavi del repository pubblico.
wget -qO- https://packages.microsoft.com/keys/microsoft.asc \ | sudo tee /etc/apt/trusted.gpg.d/microsoft.asc
Registra il repository SQL Server Ubuntu.
sudo add-apt-repository \ "$(wget -qO- https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2019.list)"
Aggiorna i file di indice del pacchetto e installa SQL Server.
sudo apt-get update sudo apt-get install -y mssql-server
Configura SQL Server:
Esegui lo strumento mssql-conf.
sudo /opt/mssql/bin/mssql-conf setup
Scegli la versione Sviluppatore per la versione SQL Server e accetta il contratto di licenza.
La versione Developer ha tutte le funzionalità aziendali incluse, ma puoi utilizzarla solo per ambienti non di produzione. Sono disponibili ulteriori informazioni sulle versioni SQL Server e sulle licenze Microsoft.
.Specifica una password per l'account SA.
Verifica che il servizio
mssql-server
sia in esecuzione.systemctl status mssql-server --no-pager
Se nelle VM è abilitato un firewall, apri il firewall per SQL Server:
Controlla se
Uncomplicated Firewall
è installato e abilitato eseguendo questo comando.sudo ufw status
Se lo stato è attivo, esegui i comandi seguenti per aprire le porte.
sudo ufw allow 1433 sudo ufw allow 5022 sudo ufw reload
Connetti a SQL Server
A questo punto, SQL Server è installato. Per connetterti, crea una macchina Windows nello stesso VPC e installa SQL Server Management Studio (SSMS) per connetterti all'istanza SQL Server appena creata sulle tue VM:
Crea una VM Windows:
Torna a Cloud Shell ed esegui questo comando.
gcloud compute instances create node4 \ --project=
PROJECT_ID
\ --zoneZONE
\ --subnetSUBNET_NAME
\ --machine-type=n2-standard-4 \ --create-disk=auto-delete=yes,boot=yes,device-name=node4,image=projects/windows-cloud/global/images/windows-server-2022-dc-v20240415,mode=rw,size=50,type=projects/p3rf-sqlserver/zones/ZONE
/diskTypes/pd-balanced
Connettiti alla VM Windows su
node-4
utilizzando Remote Desktop:Aggiorna il file hosts su
node-4
:- Apri il blocco note in modalità amministratore.
Fai clic su File > Apri e apri il file hosts.
c:\Windows\System32\drivers\etc\hosts
Aggiungi le voci host alla fine del file.
NODE1_INTERNAL_IP
node-1NODE2_INTERNAL_IP
node-2NODE3_INTERNAL_IP
node-3Sostituisci
NODE1_INTERNAL_IP
,NODE2_INTERNAL_IP
eNODE3_INTERNAL_IP
con il rispettivo indirizzo IP interno di ogni VM.Salva ed esci.
Verifica la connettività alle VM Linux:
- Connettiti alla VM Windows su
node-4
- Fai clic sul pulsante Start e inserisci PowerShell nella barra di ricerca.
- Fai clic per aprire l'app ISE di Windows PowerShell.
Verifica la connettività eseguendo questi comandi.
ping node-1 ping node-2 ping node-3
- Connettiti alla VM Windows su
Installa Microsoft SQL Server Management Studio (SSMS) svolgendo i seguenti passaggi:
Connettiti alla VM Windows su
node-4
utilizzando Remote Desktop.Nella sessione RDP, riduci al minimo tutte le finestre e avvia l'app ISE di Windows PowerShell.
Al prompt di PowerShell, scarica ed esegui il programma di installazione di SSMS.
Start-BitsTransfer ` -Source "https://aka.ms/ssmsfullsetup" ` -Destination "$env:Temp\ssms-setup.exe" & $env:Temp\ssms-setup.exe
Nel programma di installazione di SSMS, fai clic su Installa.
Accetta la richiesta di consentire l'applicazione di modifiche.
Al termine dell'installazione, fai clic su Riavvia per riavviare il computer remoto. Questa operazione chiude la sessione RDP.
Connettiti all'istanza SQL Server sul nodo 1:
Torna alla VM
node-4
utilizzando RDP.Apri SSMS e connettiti a
node-1
utilizzando i seguenti parametri.Server name: node-1 Authentication: SQL Server Authentication Login: sa
Per saperne di più, consulta la sezione sulla connessione a un'istanza SQL Server utilizzando la documentazione di SQL Server Management Studio.
Inserisci la password dell'account SA creato durante l'installazione.
Seleziona Certificato server attendibile.
Fai clic su Connect (Connetti).
Abilita gruppo di disponibilità sempre attivo
Su Linux, devi creare un gruppo di disponibilità prima di poterlo aggiungere come risorsa che deve essere gestita da Pacemaker:
Abilita la funzionalità del gruppo di disponibilità sempre attivo per ogni istanza SQL Server che fa parte del gruppo di disponibilità. Esegui questi comandi su
node-1
,node-2
enode-3
:sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1 sudo systemctl restart mssql-server
Connettiti all'istanza che è l'host principale nel gruppo di disponibilità utilizzando SSMS:
Apri una finestra di nuova query.
Esegui il seguente snippet di codice per creare una chiave di crittografia, un certificato e una chiave privata.
USE MASTER; CREATE MASTER KEY ENCRYPTION BY PASSWORD = '
ENCRYPTION_KEY_PASSWORD
'; CREATE CERTIFICATE my_ag_certificate WITH SUBJECT = 'my_ag_cert'; BACKUP CERTIFICATE my_ag_certificate TO FILE = '/var/opt/mssql/data/my_ag_certificate.cer' WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/my_ag_certificate.pvk', ENCRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD
' );Sostituisci
ENCRYPTION_KEY_PASSWORD
ePRIVATE_KEY_PASSWORD
con le password della chiave di crittografia e della chiave privata.
Trasferisci i file del certificato e della chiave
I file del certificato e della chiave creati nei passaggi precedenti devono essere spostati nei nodi secondari di SQL Server. Esistono diversi metodi per spostare i file del certificato e della chiave nei nodi secondari su node-2
e node-3
.
Per altre opzioni di trasferimento, vedi Trasferimento di file su VM Linux
Trasferisci i file del certificato e della chiave utilizzando Cloud Storage
Crea un ambiente Cloud Storage per trasferire i file dai nodi del cluster principale a quelli secondari.
Crea un bucket Cloud Storage:
Torna a Cloud Shell, esegui questo comando:
gcloud storage buckets create gs://
BUCKET_NAME
\ --project=PROJECT_ID
\ --location=REGION
\ --public-access-preventionSostituisci
BUCKET_NAME
con il nome del bucket da creare. SostituisciPROJECT_ID
con l'ID del tuo progetto Google Cloud eREGION
con l'ID della regione di cui vuoi eseguire il deployment del bucket.
Per ulteriori informazioni, consulta la sezione Creare bucket.
Torna a SSh il giorno
node-1
,node-2
enode-3
per inizializzare Google Cloud CLI:Esegui questo comando per inizializzare Google Cloud CLI.
gcloud init
Scegli
option [1]
per usare l'account di servizio preinstallato.Inserisci il nome del progetto.
Inserisci
n
nella domanda per configurare la regione e la zona predefinite.
Torna a
node-1
per copiare i file in Cloud Storage:Carica i due file appena creati in Cloud Storage utilizzando i seguenti comandi.
sudo gsutil cp /var/opt/mssql/data/my_ag_certificate.cer gs://
BUCKET_NAME
/ sudo gsutil cp /var/opt/mssql/data/my_ag_certificate.pvk gs://BUCKET_NAME
/Sostituisci
BUCKET_NAME
con il nome del bucket creato.
Torna a
node-2
enode-3
per copiare i file da Cloud Storage:Scarica i due file da Cloud Storage su
node-2
.sudo gsutil cp gs://
BUCKET_NAME
/my_ag_certificate.cer /var/opt/mssql/data/ sudo gsutil cp gs://BUCKET_NAME
/my_ag_certificate.pvk /var/opt/mssql/data/Sostituisci
BUCKET_NAME
con il nome del bucket creato.Cambia la proprietà dei file su
node-2
enode-3
eseguendo il comando in una shell root.chown mssql:mssql /var/opt/mssql/data/my_ag_certificate.* chmod 660 /var/opt/mssql/data/my_ag_certificate.*
Configura endpoint di mirroring del database
In questa sezione creerai l'endpoint di database utilizzando una chiave di crittografia e un certificato condivisi da ciascun nodo nel cluster SQL Server per garantire la replica sicura dei dati.
Torna alla VM Windows il giorno
node-4
per creare gli endpoint di mirroring del database:Connettiti ai database SQL Server su
node-1
,node-2
enode-3
tramite SSMS. Segui i passaggi descritti in Connetti a SQL Server utilizzandonode-1
,node-2
enode-3
come nome del server e le rispettive password impostate per l'account SA.Crea il certificato sulle VM secondarie
node-2
enode-3
dai file copiati. Utilizza le password che hai fornito quando hai creato il certificato e la chiave sul nodo primario.USE MASTER; CREATE MASTER KEY ENCRYPTION BY PASSWORD = '
ENCRYPTION_KEY_PASSWORD
'; CREATE CERTIFICATE my_ag_certificate FROM FILE = '/var/opt/mssql/data/my_ag_certificate.cer' WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/my_ag_certificate.pvk', DECRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD
' );Sostituisci
ENCRYPTION_KEY_PASSWORD
ePRIVATE_KEY_PASSWORD
con le password della chiave di crittografia e della chiave privata.Torna a SSMS per creare endpoint di mirroring del database eseguendo il comando T-SQL per
node-1
,node-2
enode-3
.CREATE ENDPOINT [my_ag_endpoint] AS TCP (LISTENER_PORT = 5022) FOR DATABASE_MIRRORING ( ROLE = ALL, AUTHENTICATION = CERTIFICATE my_ag_certificate, ENCRYPTION = REQUIRED ALGORITHM AES ); ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED;
Creare e configurare il gruppo di disponibilità Sempre attivo
Quindi, crea il gruppo di disponibilità Always On di SQL Server utilizzando SQL Server Management Studio e utilizza gli endpoint creati in precedenza per la replica.
Torna alla VM Windows e apri SSMS:
- Connettiti al motore del database SQL Server su
node-1
e apri una nuova finestra di query.
- Connettiti al motore del database SQL Server su
Crea un database ed esegui il backup del database in preparazione per la replica:
USE MASTER; CREATE DATABASE [bookshelf]; ALTER DATABASE [bookshelf] SET RECOVERY FULL; BACKUP DATABASE [bookshelf] TO DISK = N'/var/opt/mssql/data/bookshelf.bak';
Crea il gruppo di disponibilità Sempre attivo:
Esegui questo comando T-SQL in SSMS su
node-1
,node-2
enode-3
. Ciò garantirà che gli endpoint siano abilitati e che SQL Server su ciascun nodo sia pronto per la replica dei dati.IF (SELECT state FROM sys.endpoints WHERE name = N'my_ag_endpoint') <> 0 BEGIN ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED END GO IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health') BEGIN ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON); END IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health') BEGIN ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START; END GO
Esegui questo comando T-SQL su
node-1
per creare l'AOAG.USE [master] GO CREATE AVAILABILITY GROUP [aoag1] WITH ( AUTOMATED_BACKUP_PREFERENCE = SECONDARY, DB_FAILOVER = OFF, DTC_SUPPORT = NONE, CLUSTER_TYPE = EXTERNAL, REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0 ) FOR DATABASE [bookshelf] REPLICA ON N'node-1' WITH ( ENDPOINT_URL = N'TCP://node-1:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)), N'node-2' WITH (ENDPOINT_URL = N'TCP://node-2:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)), N'node-3' WITH (ENDPOINT_URL = N'TCP://node-3:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO) ); GO
Esegui il comando T-SQL seguente su
node-2
enode-3
per ogni istanza SQL Server per unirti al nuovo gruppo di disponibilità.ALTER AVAILABILITY GROUP [aoag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL); GO ALTER AVAILABILITY GROUP [aoag1] GRANT CREATE ANY DATABASE; GO
Hai creato un nuovo database denominato bookpeer e aggiunto il nuovo database a un nuovo gruppo di disponibilità denominato aoag1 in un'istanza SQL Server in esecuzione in
node-1
.Node-2
enode-3
sono stati aggiunti al gruppo di disponibilità e i dati nel database bookshield verranno replicati in modo sincrono nelle istanze SQL Server in tutti e tre i nodi.
Installare e configurare pacemaker
Pacemaker è un software open source per la gestione delle risorse ad alta disponibilità utilizzato con il motore del cluster Corosync. In questa sezione installerai e configurerai Pacemaker su ciascuna delle tue VM.
Crea un accesso a SQL Server per il gestore del cluster di pacemaker
In questa sezione creerai un nuovo account SQL Server che Pacemaker può utilizzare per accedere a ogni istanza SQL Server e gestire il gruppo di disponibilità.
Esegui questo comando T-SQL su
node-1
,node-2
enode-3
:USE [master]; CREATE LOGIN [pacemaker] with PASSWORD= N'
PACEMAKER_LOGIN_PASSWORD
'; GOSostituisci
PACEMAKER_LOGIN_PASSWORD
con una password per l'account del pacemaker.Esegui il comando T-SQL per concedere le autorizzazioni di accesso al pacemaker al gruppo di disponibilità:
GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::[aoag1] TO [pacemaker]; GRANT VIEW SERVER STATE TO [pacemaker]; GO
Torna a SSH su
node-1
,node-2
enode-3
per eseguire i comandi che consentono di salvare l'accesso e la password di Pacemaker nella cartella dei secret di SQL Server:echo 'pacemaker' >> ~/pacemaker-passwd echo '
PACEMAKER_LOGIN_PASSWORD
' >> ~/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/passwdSostituisci
PACEMAKER_LOGIN_PASSWORD
con la password dell'account del pacemaker.
Installazione di pacemaker
Quindi, installa Pacemaker e configura un account di accesso su tutte le VM Linux per la gestione delle risorse.
Porte del firewall aperte per il pacemaker:
Controlla se
Uncomplicated Firewall
è installato e abilitato eseguendo questo comando sunode-1
,node-2
enode-3
.sudo ufw status
Se ufw è abilitato, apri le porte del firewall su
node-1
,node-2
enode-3
.sudo ufw allow 2224/tcp sudo ufw allow 3121/tcp sudo ufw allow 5405/udp sudo ufw allow 21064/tcp sudo ufw allow 1433/tcp sudo ufw allow 5022/tcp sudo ufw reload
Installa pacemaker su
node-1
,node-2
enode-3
:sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents fence-agents corosync python3-azure pcs
Imposta una nuova password per l'utente
hacluster
sunode-1
,node-2
enode-3
:sudo passwd hacluster
Configura Corosync
Ora configurerai Corosync per gestire l'appartenenza ai cluster e la messaggistica in tutto il cluster.
Crea una chiave di autenticazione per Corosync su
node-1
:sudo corosync-keygen
Modifica il file di configurazione Corosync:
Torna a
node-1
e modifica il filecorosync.conf
.sudo vi /etc/corosync/corosync.conf
Aggiorna le sezioni evidenziate. Dopo la modifica, il file dovrebbe avere l'aspetto seguente.
# Please read the corosync.conf.5 manual page totem { version: 2 # Corosync itself works without a cluster name, but DLM needs one. # The cluster name is also written into the VG metadata of newly # created shared LVM volume groups, if lvmlockd uses DLM locking. cluster_name: my_agcluster # crypto_cipher and crypto_hash: Used for mutual node authentication. # If you choose to enable this, then do remember to create a shared # secret with "corosync-keygen". # enabling crypto_cipher, requires also enabling of crypto_hash. # crypto works only with knet transport transport: udpu crypto_cipher: none crypto_hash: none } logging { # Log the source file and line where messages are being # generated. When in doubt, leave off. Potentially useful for # debugging. fileline: off # Log to standard error. When in doubt, set to yes. Useful when # running in the foreground (when invoking "corosync -f") to_stderr: yes # Log to a log file. When set to "no", the "logfile" option # must not be set. to_logfile: yes logfile: /var/log/corosync/corosync.log # Log to the system log daemon. When in doubt, set to yes. to_syslog: yes # Log debug messages (very verbose). When in doubt, leave off. debug: off # Log messages with time stamps. When in doubt, set to hires (or on) #timestamp: hires logger_subsys { subsys: QUORUM debug: off } } quorum { # Enable and configure quorum subsystem (default: off) # see also corosync.conf.5 and votequorum.5 provider: corosync_votequorum } nodelist { # Change/uncomment/add node sections to match cluster configuration node { # Hostname of the node name: node-1 # Cluster membership node identifier nodeid: 1 # Address of first link ring0_addr:
NODE1_INTERNAL_IP
# When knet transport is used it's possible to define up to 8 links #ring1_addr: 192.168.1.1 } node { name: node-2 nodeid: 2 ring0_addr:NODE2_INTERNAL_IP
} node { name: node-3 nodeid: 3 ring0_addr:NODE3_INTERNAL_IP
} # ... }Sostituisci
NODE1_INTERNAL_IP
,NODE2_INTERNAL_IP
eNODE3_INTERNAL_IP
con gli indirizzi IP interni di ciascun nodo.
Trasferisci i file di configurazione utilizzando Cloud Storage
Carica la chiave di autenticazione e i file di configurazione Corosync generati da
node-1
nel tuo bucket Cloud Storage:sudo gsutil cp /etc/corosync/authkey gs://
BUCKET_NAME
/ sudo gsutil cp /etc/corosync/corosync.conf gs://BUCKET_NAME
/Sostituisci
BUCKET_NAME
con il nome del bucket creato in precedenza.Scarica i file di Authkey e configurazione in
node-2
enode-3
:sudo gsutil cp gs://
BUCKET_NAME
/authkey /etc/corosync/ sudo gsutil cp gs://BUCKET_NAME
/corosync.conf /etc/corosync/Sostituisci
BUCKET_NAME
con il nome del bucket in cui sono stati trasferiti i file di configurazione Corosync.Aggiorna le autorizzazioni dei file su
node-2
enode-3
:sudo chmod 400 /etc/corosync/authkey sudo chmod 400 /etc/corosync/corosync.conf
Riavvia e verifica la comunicazione del cluster
Riavvia i servizi Pacemaker e Corosync su
node-1
,node-2
enode-3
:sudo systemctl restart pacemaker corosync
Conferma lo stato del cluster eseguendo il comando su
node-1
:sudo crm status
Dovresti vedere tutti e tre i nodi online.
Configura il cluster
Il passaggio successivo prevede la configurazione del cluster Pacemaker creando una nuova risorsa per il gruppo di disponibilità Always On di SQL Server.
Esegui questo comando su
node-1
per impostare le proprietà del cluster:sudo crm configure property stonith-enabled=false sudo crm configure property cluster-recheck-interval=2min sudo crm configure property start-failure-is-fatal=true
Per saperne di più, consulta Opzioni del cluster.
Autorizza i nodi nel cluster eseguendo il comando su
node-1
. Usa la password impostata in precedenza per l'accounthacluster
:sudo pcs cluster auth -u hacluster
Dovresti vedere che tutti e tre i nodi sono autorizzati.
Installa l'agente di risorse SQL Server per l'integrazione con Pacemaker su
node-1
,node-2
enode-3
:sudo apt-get install mssql-server-ha
Torna a
node-1
e crea una risorsa del gruppo di disponibilità nel cluster:Esegui Cluster Resource Manager.
sudo crm
Digita
configure
per accedere al menu di configurazione.Inserisci la configurazione seguente.
primitive aoag1-cluster \ ocf:mssql:ag \ params ag_name="aoag1" \ 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 aoag1-cluster \ meta master-max="1" master-node-max="1" clone-max="3" \ clone-node-max="1" notify="true"
Digita
commit
per eseguire il commit delle modifiche.Digita
exit
per uscire da Cluster Resource Manager.Verifica la configurazione.
sudo crm status
Dovresti vedere che
node-1
è stato promosso al nodo primario.Node-2
enode-3
devono essere impostati come nodi secondari.
Configura il bilanciatore del carico e il listener del gruppo di disponibilità
In questa sezione, creerai un indirizzo IP virtuale e una risorsa per il controllo di integrità nel cluster utilizzando un bilanciatore del carico TCP passthrough interno che instrada il traffico al gruppo di disponibilità.
Torna a Cloud Shell e prenota un indirizzo IP statico da utilizzare come IP del cluster:
gcloud compute addresses create aoag1-cluster \ --region
REGION
\ --subnetSUBNET_NAME
CLUSTER_ADDRESS=$(gcloud compute addresses describe aoag1-cluster \ --region $(gcloud config get-value compute/region) \ --format=value\(address\)) && \ echo "Cluster IP address: $CLUSTER_ADDRESS"Sostituisci
REGION
eSUBNET_NAME
con la regione e la subnet in cui viene eseguito il deployment delle VM Linux.Crea gruppi di istanze non gestite per ciascuno dei nodi del cluster e assegnali al gruppo di istanze appena creato. Esegui questi comandi in Cloud Shell:
gcloud compute instance-groups unmanaged create node-1-uig \ --zone=
REGION
-a gcloud compute instance-groups unmanaged add-instances node-1-uig \ --zone=REGION
-a \ --instances=node-1 gcloud compute instance-groups unmanaged create node-2-uig \ --zone=REGION
-b gcloud compute instance-groups unmanaged add-instances node-2-uig \ --zone=REGION
-b \ --instances=node-2 gcloud compute instance-groups unmanaged create node-3-uig \ --zone=REGION
-c gcloud compute instance-groups unmanaged add-instances node-3-uig \ --zone=REGION
-c \ --instances=node-3Sostituisci
REGION
con la regione in cui viene eseguito il deployment delle VM Linux.Creare un controllo di integrità TCP. I bilanciatori del carico utilizzano i controlli di integrità per determinare quali istanze di backend rispondono correttamente al traffico.
gcloud compute health-checks create tcp aoag1-healthcheck \ --port=
HEALTH_CHECK_PORT
--proxy-header=NONE \ --check-interval=10 --timeout=10 --unhealthy-threshold=2 \ --healthy-threshold=2Scegli e sostituisci
HEALTH_CHECK_PORT
con il valore di una porta gratuita e compresa nell'intervallo privato 49152-65535 . Ad esempio, 60.000.Per saperne di più, consulta la panoramica dei controlli di integrità.
Aggiungi tag di rete ai nodi del cluster. Il tag di rete viene utilizzato dalla regola firewall per il controllo di integrità:
gcloud compute instances add-tags node-1 \ --tags
NETWORK_TAG_NAME
\ --zoneREGION
-a gcloud compute instances add-tags node-2 \ --tagsNETWORK_TAG_NAME
\ --zoneREGION
-b gcloud compute instances add-tags node-3 \ --tagsNETWORK_TAG_NAME
\ --zoneREGION
-cSostituisci
NETWORK_TAG_NAME
con un nome per il tag di rete.Crea una regola firewall per consentire ai controlli di integrità di raggiungere i nodi del cluster in base al nome del tag:
gcloud compute firewall-rules create mssql-aoag1-fw-rule \ --network
VPC_NAME
\ --action ALLOW \ --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tagsNETWORK_TAG_NAME
\ --rules tcp:HEALTH_CHECK_PORT
Per ulteriori informazioni, consulta Regole firewall per i controlli di integrità.
Crea il servizio di backend del bilanciatore del carico:
gcloud compute backend-services create aoag1-backend \ --load-balancing-scheme internal \ --health-checks aoag1-healthcheck \ --no-connection-drain-on-failover \ --drop-traffic-if-unhealthy \ --failover-ratio 1.0 \ --region
REGION
\ --global-health-checksAggiungi i tre gruppi di istanze non gestite al servizio di backend:
gcloud compute backend-services add-backend aoag1-backend \ --instance-group node-1-uig \ --instance-group-zone
REGION
-a \ --regionREGION
gcloud compute backend-services add-backend aoag1-backend \ --instance-group node-2-uig \ --instance-group-zoneREGION
-b \ --failover \ --regionREGION
gcloud compute backend-services add-backend aoag1-backend \ --instance-group node-3-uig \ --instance-group-zoneREGION
-c \ --failover \ --regionREGION
Definisci una regola di forwarding per il bilanciatore del carico. Una regola di forwarding specifica il protocollo e le porte su cui il bilanciatore del carico accetta il traffico:
gcloud compute forwarding-rules create aoag1-fwd-rule \ --load-balancing-scheme internal \ --address
CLUSTER_ADDRESS
\ --subnetSUBNET_NAME
\ --regionREGION
\ --backend-service aoag1-backend \ --ports ALLSostituisci
CLUSTER_ADDRESS
con l'indirizzo IP prenotato in precedenza.Per maggiori informazioni, vedi Regole di forwarding
Per completare la configurazione e verificare se il bilanciatore del carico di rete è configurato correttamente, installa e configura
HAProxy tcp listener
sunode-1
,node-2
enode-3
:Installa HAProxy.
sudo apt-get install haproxy
Scegli
Y
per completare l'installazione.Modifica il file
haproxy.cfg
.sudo vi /etc/haproxy/haproxy.cfg
Nella sezione delle impostazioni predefinite di
haproxy.cfg file
, imposta la modalità sutcp
.Aggiungi la seguente sezione alla fine del file
haproxy.cfg
#--------------------------------------------------------------- # Set up health check listener for SQL Server Availability Group #--------------------------------------------------------------- listen healthcheck bind *:
HEALTH_CHECK_PORT
Sostituisci
HEALTH_CHECK_PORT
con la porta per il controllo di integrità selezionata in precedenza. Ad esempio, 6000.Avvia il servizio per verificare che sia configurato correttamente:
sudo systemctl start haproxy.service sudo systemctl enable haproxy.service sudo systemctl restart haproxy.service
Vai alla pagina Bilanciamento del carico e fai clic sul bilanciatore del carico. Osserva i tre gruppi di istanze non gestite, che ora dovrebbero risultare integri.
Vai a Bilanciamento del carico
In alternativa, puoi eseguire questo comando in Cloud Shell per visualizzare lo stato del servizio di backend.
gcloud compute backend-services get-health aoag1-backend \ --region
REGION
Sostituisci
REGION
con la regione in cui viene eseguito il deployment delle VM Linux.
Una volta che tutti e tre i gruppi di istanze non gestite sono in stato integro, vai al passaggio successivo.
sudo systemctl restart haproxy.service
Crea la risorsa di controllo di integrità in Pacemaker:
Accedi a
node-1
tramite SSH e crea una risorsa di controllo di integrità per il servizio HAProxy nel cluster di pacemaker:sudo pcs resource create aoag1-healthcheck \ service:haproxy \ op monitor interval=10s timeout=20s
Controlla che la risorsa di integrità sia avviata sul nodo primario
node-1
:sudo crm status
Se la risorsa di controllo di integrità non viene avviata sul nodo primario, spostala con i comandi seguenti:
sudo pcs resource move aoag1-healthcheck node-1 sudo pcs resource clear aoag1-healthcheck
Vedrai che il controllo di integrità per il bilanciatore del carico sarà in stato integro solo per
node-1
.
Crea una risorsa di indirizzi IP virtuali nel cluster Pacemaker:
Torna a SSH su
node-1
e trova il nome dell'interfaccia di rete del tuo nodo. Ti servirà nel passaggio successivo.ip -c link
Crea la risorsa dell'indirizzo IP virtuale.
sudo pcs resource create aoag1-vip ocf:heartbeat:IPaddr2 \ ip="
CLUSTER_ADDRESS
" nic=NIC_NAME
cidr_netmask=32 \ op monitor interval=3600s timeout=60sSostituisci
NIC_NAME
con il nome dell'interfaccia di rete del passaggio precedente eCLUSTER_ADDRESS
con l'indirizzo IP riservato.Verifica che la risorsa dell'indirizzo IP virtuale sia avviata sull'host principale.
sudo crm status
Se la risorsa dell'indirizzo IP virtuale non viene avviata sul nodo principale, spostala con i comandi seguenti.
sudo pcs resource move aoag1-vip node-1
Raggruppa le risorse per il controllo di integrità e gli indirizzi IP virtuali.
sudo pcs resource group add aoag1-group \ aoag1-healthcheck aoag1-vip
Crea un vincolo che localizzi il nuovo gruppo sullo stesso nodo di quello primario.
sudo pcs constraint colocation add master aoag1-group with master ms-ag1 score=INFINITY
Crea un listener per il gruppo di disponibilità SQL Server
Le connessioni a SQL Server con gruppi di disponibilità devono utilizzare un nome listener di gruppo di disponibilità anziché il nome del server. In caso di failover, il listener reindirizzerà automaticamente le connessioni al nuovo nodo primario del cluster.
Torna a SSMS e connettiti al database
node-1
.Esegui questa query:
ALTER AVAILABILITY GROUP aoag1 ADD LISTENER 'aoag1-listener' ( WITH IP (('
CLUSTER_ADDRESS
','255.255.255.0')), PORT=1433 ); GOSostituisci
CLUSTER_ADDRESS
con l'indirizzo IP riservato.
Configura una recinzione STONITH
STONITH è una strategia di recinzione per mantenere l'integrità dei nodi in un cluster ad alta disponibilità. Il servizio STONITH funziona a livello di nodo e protegge il cluster dai nodi che non rispondono o in stato sconosciuto. Ti consigliamo il dispositivo di recinzione fence_gce
specializzato per Compute Engine su Google Cloud.
Configurazione di dispositivi di recinzione
Controlla se l'agente
fence_gce
- Fence per Compute Engine è installato sunode1
:sudo pcs stonith list | grep fence_gce
Per ulteriori informazioni, vedi:
- Agente di recinzione per Google Compute Engine.
Per visualizzare i parametri associati all'esecuzione dell'agente.
sudo pcs stonith describe fence_gce
Su
node-1
, crea le risorse di tipo di recinzionefence_gce
per ciascuno dei nodi partecipanti:sudo pcs stonith create node-1-fence fence_gce \ plug=node-1 \ zone=
REGION
-a \ project=PROJECT_ID
\ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" sudo pcs stonith create node-2-fence fence_gce \ plug=node-2 \ zone=REGION
-b \ project=PROJECT_ID
\ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" sudo pcs stonith create node-3-fence fence_gce \ plug=node-3 \ zone=REGION
-c \ project=PROJECT_ID
\ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s"Sostituisci
REGION
con la regione in cui viene eseguito il deployment delle VM Linux e sostituisciPROJECT_ID
con il tuo ID progetto.Puoi verificare lo stato degli agenti di fencing eseguendo il comando di stato:
sudo fence_gce -o status -n node-1 --zone=
REGION
-a sudo fence_gce -o status -n node-2 --zone=REGION
-b sudo fence_gce -o status -n node-3 --zone=REGION
-cCrea vincoli di posizione per i dispositivi di recinzione per assicurarti che vengano eseguiti solo sulle istanze previste:
sudo pcs constraint location node-1-fence avoids node-1 sudo pcs constraint location node-2-fence avoids node-2 sudo pcs constraint location node-3-fence avoids node-3
Attiva la recinzione nel gruppo di pacemaker e imposta il timeout della recinzione del cluster:
sudo pcs -f stonith_cfg property set stonith-enabled=true sudo pcs property set stonith-timeout="300s"
Controlla lo stato del cluster:
sudo crm status
Prova i dispositivi di recinzione
Dopo aver configurato i dispositivi di recinzione, ti consigliamo di testarli seguendo questa procedura.
Interrompi la recinzione su
node-2
:Connettiti a
node-1
ed esegui questo comando per testare il dispositivo di recinzione associato anode-2
dal tuo cluster.fence_gce -o off -n node-2 --zone=
REGION
-bControlla lo stato del cluster.
sudo crm status
Vedrai anche che
node-2
è disattivato in Compute Engine.
Riavvia la recinzione su
node-2
:Torna a
node-1
e riavvia l'istanza eseguendo il comando seguente.fence_gce -o on -n node-2 --zone=
REGION
-bControlla lo stato del cluster in Pacemaker e Compute Engine. Dopo qualche istante vedrai che
node-2
è di nuovo online.sudo crm status
Configurare Corosync per il riavvio ritardato
Per evitare problemi di tempistica e garantire un corretto ordine delle operazioni eseguite in caso di azione di recinzione, consigliamo di ritardare il riavvio del servizio Corosync di 60 secondi.
Per ulteriori informazioni, consulta l'articolo della knowledge base di Red Hat.
Crea un file drop in systemd che imposti un ritardo dell'avvio del servizio Corosync su
node-1
,node-2
enode-3
:Apri corosync.service per la modifica.
sudo systemctl edit corosync.service
Aggiungi le righe seguenti, salva il file e esci dall'editor.
[Service] ExecStartPre=/bin/sleep 60
Ricarica il gestore del servizio e controlla se la configurazione è presa in considerazione.
sudo systemctl daemon-reload systemctl status corosync.service --no-pager
Se vedi la sezione Drop-in, significa che le impostazioni nel file del menu a discesa sono state prese in considerazione correttamente.
Testa il failover
Ora puoi verificare se il failover funziona come previsto.
- Connettiti alla VM Windows su
node-4
tramite Remote Desktop: - Apri una sessione di PowerShell:
Esegui questo script:
while ($True){ $Conn = New-Object System.Data.SqlClient.SqlConnection $Conn.ConnectionString = "Server=
CLUSTER_ADDRESS
;User ID=sa;Password=SA_PASSWORD
;Initial Catalog=master" $Conn.Open() $Cmd = New-Object System.Data.SqlClient.SqlCommand $Cmd.Connection = $Conn $Cmd.CommandText = "SELECT @@SERVERNAME" $Adapter = New-Object System.Data.SqlClient.SqlDataAdapter $Cmd $Data = New-Object System.Data.DataSet $Adapter.Fill($Data) | Out-Null $Data.Tables[0] + (Get-Date -Format "MM/dd/yyyy HH:mm:ss") Start-Sleep -Seconds 2 }Sostituisci
CLUSTER_ADDRESS
con l'indirizzo IP del listener eSA_PASSWORD
con la password dell'account SA su SQL Server.Ogni 2 secondi, lo script si connette a SQL Server utilizzando il listener del gruppo di disponibilità o il listener DNN ed esegue una query sul nome del server.
Lascia in esecuzione lo script.
Torna a SSH su
node-1
ed esegui i comandi per attivare un failover anode-2
:sudo pcs resource move ms-ag1 node-2 --master sudo pcs resource move aoag1-group node-2 sudo pcs resource move aoag1-vip node-2
Torna alla sessione di PowerShell il giorno
node-4
:- Osserva l'output dello script in esecuzione e nota che il nome del server
cambia da
node-1
anode-2
come risultato del failover.
- Osserva l'output dello script in esecuzione e nota che il nome del server
cambia da
Torna a
node-1
e avvia un failover anode-1
:sudo pcs resource move ms-ag1 node-1 --master sudo pcs resource move aoag1-group node-1 sudo pcs resource move aoag1-vip node-1
Torna a Powershell su
node-4
e interrompi lo script premendoCtrl+C
.
Esegui la pulizia
Al termine del tutorial, puoi eseguire la pulizia delle risorse che hai creato in modo che smettano di utilizzare la quota e smettano di essere addebitati. Le sezioni seguenti descrivono come eliminare o disattivare queste risorse.
Elimina il progetto
Il modo più semplice per eliminare la fatturazione è eliminare il progetto che hai creato per il tutorial.
Per eliminare il progetto:
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.