Esercitazione: configurare un gruppo di disponibilità Always On a tre nodi con HPE Serviceguard per Linux
Si applica a:
SQL Server - Linux
Questa esercitazione illustra come configurare i gruppi di disponibilità di SQL Server con HPE Serviceguard per Linux in esecuzione in macchine virtuali locali o basate su Azure.
Per una panoramica dei cluster HPE Serviceguard, vedere HPE Serviceguard Clusters (Cluster di HPE Serviceguard).
Nota
Microsoft offre supporto per lo spostamento dei dati, il gruppo di disponibilità e i componenti di SQL Server. Contattare HPE per assistenza relativa alla documentazione per i cluster HPE Serviceguard e la gestione del quorum.
Questa esercitazione è costituita dalle attività seguenti:
- Installare SQL Server in tutte e tre le macchine virtuali che faranno parte del gruppo di disponibilità
- Installare HPE Serviceguard nelle macchine virtuali
- Creare il cluster HPE Serviceguard
- Creare il servizio di bilanciamento del carico nel portale di Azure
- Creare il gruppo di disponibilità e aggiungere un database di esempio al gruppo di disponibilità
- Distribuire il carico di lavoro di SQL Server nel gruppo di disponibilità tramite la gestione cluster di Serviceguard
- Eseguire un failover automatico e aggiungere di nuovo il nodo al cluster
Prerequisiti
In Azure creare tre macchine virtuali (VM) basate su Linux. Per creare macchine virtuali basate su Linux in Azure, vedere Avvio rapido: Creare una macchina virtuale Linux nel portale di Azure. Per distribuire le VM, assicurarsi di usare distribuzioni Linux supportate da HPE Serviceguard. Se si preferisce, è possibile distribuire le VM anche in locale in un ambiente locale.
Per un esempio di distribuzione supportata, vedere HPE Serviceguard for Linux. Per informazioni sul supporto per gli ambienti cloud pubblici, contattare HPE.
Le istruzioni in questa esercitazione sono verificate in HPE Serviceguard per Linux. È possibile scaricare una versione di valutazione da HPE.
File di database di SQL Server in una partizione LVM (Logical Volume Mount) per tutte e tre le macchine virtuali. Vedere Quick start guide for Serviceguard Linux (HPE) (Guida introduttiva per Serviceguard Linux - HPE)
Assicurarsi che nella VM sia installato un runtime Java OpenJDK. IBM Java SDK non è supportato.
Installare SQL Server
In tutte e tre le VM, seguire uno dei passaggi seguenti in base alla distribuzione di Linux scelta per questa esercitazione, per installare SQL Server e gli strumenti.
Red Hat Enterprise Linux (RHEL)
SUSE Linux Enterprise Server (SLES)
Dopo aver completato questo passaggio, il servizio SQL Server e gli strumenti dovrebbero essere installati in tutte e tre le macchine virtuali che parteciperanno al gruppo di disponibilità.
Installare HPE Serviceguard nelle macchine virtuali
In questo passaggio, installare HPE Serviceguard per Linux in tutte e tre le macchine virtuali. Nella tabella seguente viene descritto il ruolo svolto da ogni server nel cluster.
| Number of VMs (Numero di VM) | Ruolo di HPE Serviceguard | Ruolo della replica del gruppo di disponibilità di Microsoft SQL Server |
|---|---|---|
| 1 | Nodi del cluster HPE Serviceguard | Replica primaria |
| 1 o più | Nodo del cluster HPE Serviceguard | Replica secondaria |
| 1 | Server quorum HPE Serviceguard | Replica di sola configurazione |
Nota
Fare riferimento a questo video di HPE, che descrive come installare e configurare un cluster HPE Serviceguard tramite l'interfaccia utente.
Per installare Serviceguard, usare il metodo cminstaller. Sono disponibili istruzioni specifiche nei collegamenti seguenti:
- Installare Serviceguard per Linux in due nodi. Vedere la sezione Install_serviceguard_using_cminstaller.
- Installare il server quorum Serviceguard nel terzo nodo. Vedere la sezione Install_QS_from_the_ISO.
Dopo aver completato l'installazione del cluster HPE Serviceguard, è possibile abilitare il portale di gestione del cluster sulla porta TCP 5522 nel nodo della replica primaria. I passaggi seguenti aggiungono una regola al firewall per consentire 5522. Il comando seguente è per Red Hat Enterprise Linux (RHEL). è necessario eseguire comandi simili per altre distribuzioni:
sudo firewall-cmd --zone=public --add-port=5522/tcp --permanent
sudo firewall-cmd --reload
Creare un cluster HPE Serviceguard
Segui queste istruzioni per configurare e creare il cluster HPE Serviceguard. In questo passaggio verrà anche configurato il server quorum.
- Configurare il server quorum Serviceguard nel terzo nodo. Vedere la sezione Configure_QS.
- Configurare e creare un cluster Serviceguard negli altri due nodi. Vedere la sezione Configure_and_create_Cluster.
Nota
È possibile ignorare l'installazione manuale del cluster HPE Serviceguard e del quorum aggiungendo l'estensione HPE Serviceguard for Linux (SGLX) dal Marketplace di macchine virtuali di Azure quando si crea la macchina virtuale.
Creare il gruppo di disponibilità e aggiungere un database di esempio
In questo passaggio creare un gruppo di disponibilità con due (o più) repliche sincrone e una replica di sola configurazione, che supporta la protezione dei dati e può anche offrire disponibilità elevata. Nel diagramma seguente è illustrata questa architettura:
Replica sincrona dei dati utente nella replica secondaria. Sono inclusi anche i metadati di configurazione del gruppo di disponibilità.
Replica sincrona dei metadati di configurazione del gruppo di disponibilità. Non sono inclusi i dati utente.
Per altre informazioni, vedi Due repliche sincrone e una replica di sola configurazione.
Per creare il gruppo di disponibilità, seguire questa procedura:
- Abilita i gruppi di disponibilità e riavvia mssql-server su tutte le macchine virtuali, inclusa la replica di sola configurazione.
- Abilitare una sessione eventi
AlwaysOn_health(facoltativo) - Creare un certificato nella macchina virtuale primaria
- Creare il certificato nei server secondari
- Creare gli endpoint di mirroring del database per le repliche
- Creare un gruppo di disponibilità
- Aggiungere le repliche secondarie
- Aggiungere un database al gruppo di disponibilità
Abilitare i gruppi di disponibilità e riavviare mssql-server
Abilita i gruppi di disponibilità in tutti i nodi che ospitano un'istanza di SQL Server. Riavviare quindi mssql-server. Eseguire lo script seguente in tutti e tre i nodi:
sudo /opt/mssql/bin/mssql-conf
set hadr.hadrenabled 1 sudo systemctl restart mssql-server
Abilitare una sessione eventi AlwaysOn_health (facoltativo)
Facoltativamente, abilitare gli eventi estesi dei gruppi di disponibilità Always On per diagnosticare più facilmente la causa radice durante la risoluzione dei problemi che interessano un gruppo di disponibilità. Eseguire il comando seguente in ogni istanza di SQL Server:
ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO
Creare un certificato nella macchina virtuale primaria
Lo script Transact-SQL seguente crea una chiave master e un certificato. Quindi esegue il backup del certificato e protegge il file con una chiave privata. Aggiornare lo script con password complesse. Connettersi all'istanza di SQL Server primaria ed eseguire lo script Transact-SQL seguente:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Master_Key_Password>';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY
( FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
ENCRYPTION BY PASSWORD = '<Private_Key_Password>' );
A questo punto la replica di SQL Server primaria ha un certificato in /var/opt/mssql/data/dbm_certificate.cer e una chiave privata in var/opt/mssql/data/dbm_certificate.pvk. Copiare questi due file nello stesso percorso in tutti i server che ospiteranno le repliche di disponibilità. Usa l'utente mssql o concedi l'autorizzazione all'utente mssql per questi file.
Nel server di origine, ad esempio, il comando seguente copia i file nel computer di destinazione. Sostituire i valori di node2 con il nome dell'host che esegue l'istanza di SQL Server secondaria. Copiare il certificato anche nella replica di sola configurazione ed eseguire anche i comandi seguenti in tale nodo.
cd /var/opt/mssql/data
scp dbm_certificate.* root@<node2>:/var/opt/mssql/data/
A questo punto, nelle macchine virtuali secondarie che eseguono l'istanza secondaria e la replica di sola configurazione di SQL Server esegui i comandi seguenti, in modo che l'utente mssql possa diventare proprietario del certificato copiato:
cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*
Creare il certificato nei server secondari
Lo script Transact-SQL seguente crea una chiave master e un certificato dal backup creato nella replica primaria di SQL Server. Aggiornare lo script con password complesse. La password di decrittografia è la stessa password usata per creare il file .pvk in un passaggio precedente. Per creare il certificato, eseguire lo script seguente in tutti i server secondari ad eccezione della replica di sola configurazione:
CREATE MASTER KEY ENCRYPTION BY PASSWORD =
'<Master_Key_Password>';
CREATE CERTIFICATE dbm_certificate FROM FILE =
'/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
DECRYPTION BY PASSWORD = '<Private_Key_Password>' );
Creare gli endpoint di mirroring del database per le repliche
Nella replica primaria e nella replica secondaria esegui i comandi seguenti per creare gli endpoint di mirroring del database:
CREATE ENDPOINT [hadr_endpoint] AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING
(
ROLE = WITNESS,
AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES
);
ALTER ENDPOINT [hadr_endpoint] STATE = STARTED;
Nota
5022 è la porta standard usata per l'endpoint di mirroring del database, ma è possibile sostituirla con qualsiasi porta disponibile.
Nella replica di sola configurazione crea l'endpoint di mirroring del database usando il comando seguente. Il valore del ruolo qui è impostato su WITNESS, ovvero l'impostazione necessaria per la replica di sola configurazione.
CREATE ENDPOINT [hadr_endpoint] AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (
ROLE = WITNESS,
AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES
);
ALTER ENDPOINT [hadr_endpoint] STATE = STARTED;
Creare un gruppo di disponibilità
Nell'istanza della replica primaria esegui i comandi seguenti. Questi comandi creano un gruppo di disponibilità denominato ag1, che ha EXTERNAL cluster_type e concede l'autorizzazione per la creazione di database al gruppo di disponibilità.
Prima di eseguire gli script seguenti, sostituire i segnaposto <node1>, <node2> e <node3> (replica di sola configurazione) con il nome delle macchine virtuali create nei passaggi precedenti.
CREATE AVAILABILITY GROUP [ag1]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR REPLICA ON
N'<node1>' WITH (
ENDPOINT_URL = N'tcp://<node1>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'<node2>' WITH (
ENDPOINT_URL = N'tcp://<node2>:\<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'<node3>' WITH (
ENDPOINT_URL = N'tcp://<node3>:<5022>',
AVAILABILITY_MODE = CONFIGURATION_ONLY
);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
Aggiungere le repliche secondarie
Esegui i comandi seguenti in tutte le repliche secondarie. Questi comandi aggiungono le repliche secondarie al gruppo di disponibilità ag1 con la replica primaria e forniscono le autorizzazioni per la creazione di database al gruppo di disponibilità ag1.
ALTER AVAILABILITY GROUP [ag1]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO
ALTER AVAILABILITY GROUP [ag1]
GRANT CREATE ANY DATABASE;
GO
Aggiungere un database al gruppo di disponibilità
Connettiti alla replica primaria ed esegui i comandi T-SQL seguenti per:
- Creare un database di esempio denominato
db1che verrà aggiunto al gruppo di disponibilità. - Impostare il modello di recupero con registrazione completa per il database. Per tutti i database in un gruppo di disponibilità è richiesto il modello di recupero con registrazione completa.
- Eseguire il backup del database. Prima di poter aggiungere un database a un gruppo di disponibilità, è necessario almeno un backup completo.
-- creates a database named db1
CREATE DATABASE [db1];
GO
-- set the database in full recovery model
ALTER DATABASE [db1] SET RECOVERY FULL;
GO
-- backs up the database to disk
BACKUP DATABASE [db1]
TO DISK = N'/var/opt/mssql/data/db1.bak';
GO
-- adds the database db1 to the AG
ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];
GO
Dopo aver completato i passaggi precedenti, è possibile visualizzare il gruppo di disponibilità ag1 creato e le tre macchine virtuali vengono aggiunte come replica con una replica primaria, una replica secondaria e una replica di sola configurazione. ag1 contiene un solo database.
Distribuire il carico di lavoro del gruppo di disponibilità di SQL Server (gestione cluster HPE)
In HPE Serviceguard distribuire il carico di lavoro di SQL Server in un gruppo di disponibilità tramite l'interfaccia utente di gestione cluster di Serviceguard.
Distribuire il carico di lavoro del gruppo di disponibilità e abilitare la disponibilità elevata e il ripristino di emergenza tramite il cluster Serviceguard usando l'interfaccia utente grafica di gestione di Serviceguard. Vedi la sezione Protezione di Microsoft SQL Server in Linux per i gruppi di disponibilità Always On.
Creare il servizio di bilanciamento del carico nel portale di Azure
Per le distribuzioni nel cloud di Azure, HPE Serviceguard per Linux richiede un load balancer per abilitare le connessioni client con la replica primaria, per sostituire gli indirizzi IP tradizionali.
Nel portale di Azure apri il gruppo di risorse contenente i nodi del cluster o le macchine virtuali di Serviceguard.
Nel gruppo di risorse selezionare Aggiungi.
Nei risultati della ricerca cerca il bilanciamento del carico e seleziona Load balancer, pubblicato da Microsoft.
Nel pannello Load balancer seleziona Crea.
Configura il load balancer con le impostazioni seguenti:
Impostazione valore Nome Nome del load balancer. Ad esempio: SQLAvailabilityGroupLB.Type Internal SKU Basic o Standard Rete virtuale Rete virtuale usata per le repliche di macchine virtuali Subnet Subnet in cui sono ospitate le istanze di SQL Server Assegnazione indirizzi IP Statico Indirizzo IP privato Creare un sondaggio all'interno di un progetto Abbonamento Scegliere la sottoscrizione interessata Gruppo di risorse Scegliere il gruppo di risorse interessato Location Selezionare la stessa posizione dei nodi SQL
Configurare il pool back-end
Il pool back-end sono gli indirizzi delle due istanze in cui è configurato il cluster Serviceguard.
- Nel gruppo di risorse fai clic sul load balancer creato.
- Passa a Impostazioni > Pool back-end e seleziona Aggiungi per creare un pool di indirizzi back-end.
- In Aggiungi pool back-end, in Nome digita un nome per il pool back-end.
- In Associato a selezionare Macchina virtuale.
- Seleziona ogni macchina virtuale nell'ambiente e associa l'indirizzo IP appropriato a ogni selezione.
- Selezionare Aggiungi.
Creare un probe
Il probe definisce il modo in cui Azure verifica quale nodo del cluster Serviceguard è la replica primaria. Azure esamina il servizio in base all'indirizzo IP su una porta definita quando si crea il probe.
Nel riquadro Impostazioni del load balancer, fai clic su Probe di integrità.
Nel riquadro Probe di integrità, seleziona Aggiungi.
Usare i valori seguenti per configurare il probe.
Impostazione valore Nome Nome che rappresenta il probe. Ad esempio: SQLAGPrimaryReplicaProbe.Protocollo TCP Porta È possibile usare qualsiasi porta disponibile. Ad esempio 59999. Intervallo 5 Soglia non integra 2 Seleziona OK.
Accedi a tutte le macchine virtuali e apri la porta del probe usando i comandi seguenti:
sudo firewall-cmd --zone=public --add-port=59999/tcp --permanent sudo firewall-cmd --reload
Azure crea il probe e lo usa per testare il nodo Serviceguard in cui è in esecuzione l'istanza di replica primaria del gruppo di disponibilità. Ricorda la porta configurata (59999), necessaria per implementare il gruppo di disponibilità nel cluster Serviceguard.
Impostare le regole di bilanciamento del carico
Le regole di bilanciamento del carico configurano il modo in cui il load balancer instrada il traffico al nodo Serviceguard, ovvero la replica primaria nel cluster. Per questo load balancer, abilitare Direct Server Return, perché solo uno dei nodi del cluster Serviceguard può essere una replica primaria alla volta.
Nel riquadro Impostazioni del load balancer, fai clic su Regole di bilanciamento del carico.
Seleziona Regole di bilanciamento del carico e quindi Aggiungi.
Configura la nuova regola di bilanciamento del carico con le seguenti impostazioni:
Impostazione valore Nome Nome che rappresenta le regole di bilanciamento del carico. Ad esempio: SQLAGPrimaryReplicaListener.Protocollo TCP Porta 1433 Porta back-end 1433. Questo valore verrà ignorato perché questa regola usa IP mobile. Probe Usare il nome del probe creato per questo servizio di bilanciamento del carico. Persistenza della sessione None Timeout di inattività (minuti) 4 IP mobile Attivata Seleziona OK.
Azure configura la regola di bilanciamento del carico. Il load balancer è ora configurato per instradare il traffico al nodo Serviceguard che è l'istanza di replica primaria nel cluster.
Prendi nota dell'indirizzo IP front-end del load balancer "LbReadWriteIP", necessario per implementare il gruppo di disponibilità nel cluster Serviceguard.
A questo punto il gruppo di risorse dispone di un load balancer, che si connette a tutti i nodi Serviceguard. Il load balancer contiene anche un indirizzo IP per consentire ai client di connettersi all'istanza di replica primaria nel cluster, in modo che qualsiasi computer che sia una replica primaria possa rispondere alle richieste per il gruppo di disponibilità.
Eseguire il failover automatico e aggiungere di nuovo il nodo al cluster
Per il test di failover automatico, è possibile arrestare la replica primaria (spegnimento) per replicare la mancata disponibilità improvvisa del nodo primario. Questo è il comportamento previsto:
- La gestione cluster alza di livello una delle repliche secondarie nel gruppo di disponibilità a replica primaria.
- La replica primaria in errore viene aggiunta automaticamente al cluster dopo il backup. La gestione cluster la alza di livello a replica secondaria.
Per HPE Serviceguard, vedere la sezione Testing the setup for failover readiness (Testare la configurazione per la conformità del failover)
Contenuto correlato
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per