Nous avons déjà couvert une partie de la théorie sur la configuration des groupes de disponibilité Always ON pour les serveurs SQL basés sur Linux. L'article actuel se concentrera sur la pratique.
Nous allons présenter le processus étape par étape de configuration des groupes de disponibilité SQL Server Always ON entre deux réplicas synchrones. Nous mettrons également en évidence l'utilisation du réplica de configuration uniquement pour effectuer un basculement automatique.
Avant de commencer, je vous recommande de vous référer à cet article précédent et de rafraîchir vos connaissances.
Le schéma de conception ci-dessous affiche le réplica synchrone à deux nœuds et un réplica de configuration uniquement qui nous aident à assurer le basculement automatique et la protection des données.
Nous avons exploré cette conception dans l'article mentionné précédemment, veuillez donc vous y référer pour plus d'informations avant de passer aux tâches pratiques.
Installer SQL Server sur les systèmes Ubuntu
Le diagramme de conception ci-dessus mentionne 3 systèmes Ubuntu - aoagvm1 , aoagvm2 , et aoagvm3 avec les instances SQL Server installées. Reportez-vous aux instructions d'installation de SQL Server sur Ubuntu - l'exemple concerne SQL Server 2019 sur le système Ubuntu 18.04. Vous pouvez continuer et installer SQL Server 2019 sur les 3 nœuds (assurez-vous d'installer la même version de build).
Pour réduire les coûts de licence, vous pouvez installer l'édition SQL Server Express pour le réplica du troisième nœud. Celui-ci fonctionnera comme un réplica de configuration uniquement sans héberger de bases de données de disponibilité.
Une fois SQL Server installé sur les 3 nœuds, nous pouvons configurer le groupe de disponibilité entre eux.
Configurer des groupes de disponibilité entre trois nœuds
Avant de continuer, validez votre environnement :
- Assurez-vous qu'il existe une communication entre les 3 nœuds.
- Vérifiez et mettez à jour le nom de l'ordinateur pour chaque hôte en exécutant la commande sudo vi /etc/hostname
- Mettez à jour le fichier hôte avec l'adresse IP et les noms de nœud pour chaque nœud. Vous pouvez utiliser la commande sudo vi /etc/hosts pour y parvenir
- Assurez-vous que toutes les instances s'exécutent au-delà de SQL Server 2017 CU1 si vous n'utilisez pas SQL Server 2019
Commençons maintenant à configurer le groupe de disponibilité SQL Server Always ON entre 3 nœuds. Nous devons activer la fonctionnalité Groupe de disponibilité sur les 3 nœuds.
Exécutez la commande ci-dessous (notez que vous devez redémarrer le service SQL Server après cette action) :
--Enable Availability Group feature
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
--Restart SQL Server service
sudo systemctl restart mssql-server
J'ai exécuté la commande ci-dessus sur le nœud principal. Il doit être répété pour les deux nœuds restants.
La sortie est ci-dessous - entrez le nom d'utilisateur et le mot de passe chaque fois que vous y êtes invité.
[email protected]:~$ sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
SQL Server needs to be restarted to apply this setting. Please run
'systemctl restart mssql-server.service'.
[email protected]:~$ systemctl restart mssql-server
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to restart 'mssql-server.service'.
Authenticating as: Ubuntu (aoagvm1)
Password:
L'étape suivante consiste à activer les événements étendus Toujours activés pour chaque instance SQL Server. Bien qu'il s'agisse d'une étape facultative, vous devez l'activer pour résoudre les problèmes qui pourraient survenir ultérieurement. Connectez-vous à l'instance SQL Server à l'aide de SQLCMD et exécutez la commande ci-dessous :
--Connect to the local SQL Server instance using sqlcmd
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
Go
ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
Go
La sortie est ci-dessous :
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
2>GO
1>
Une fois que vous avez activé cette option sur le nœud de réplica principal, faites de même pour les nœuds aoagvm2 et aoagvm3 restants.
Les instances SQL Server exécutées sur Linux utilisent des certificats pour authentifier la communication entre les points de terminaison de mise en miroir. Ainsi, l'option suivante consiste à créer le certificat sur le réplica principal aoagvm1 .
Tout d'abord, nous créons une clé principale et un certificat. Ensuite, nous sauvegardons ce certificat dans un fichier et sécurisons le fichier avec une clé privée. Exécutez le script T-SQL ci-dessous sur le nœud de réplica principal :
--Connect to the local SQL Server instance using sqlcmd
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
--Configure Certificates
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
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 = '[email protected]');
La sortie :
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
2>CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
3>GO
1>BACKUP CERTIFICATE dbm_certificate TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
2>WITH PRIVATE KEY (FILE = '/var/opt/mssql/data/dbm_certificate.pvk',ENCRYPTION BY PASSWORD = '[email protected]');
3>GO
1>
Le nœud de réplica principal a maintenant deux nouveaux fichiers. L'un est le fichier de certificat dbm_certificate.cer et le fichier de clé privée dbm_certificate.pvk à /var/opt/mssql/data/ emplacement.
Copiez les deux fichiers ci-dessus au même emplacement sur les deux nœuds restants (AOAGVM2 et AOAGVM3) qui participeront à la configuration du groupe de disponibilité. Vous pouvez utiliser la commande SCP ou tout utilitaire tiers pour copier ces deux fichiers sur le serveur cible.
Une fois les fichiers copiés sur les deux nœuds restants, nous attribuerons des autorisations au mssql utilisateur d'accéder à ces fichiers sur les 3 nœuds. Pour cela, exécutez la commande ci-dessous puis exécutez-la pour le 3ème nœud aoagvm3 aussi :
--Copy files to aoagvm2 node
cd /var/opt/mssql/data
scp dbm_certificate.* [email protected]:var/opt/mssql/data/
--Grant permission to user mssql to access both newly created files
cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*
Nous allons créer les fichiers de clé principale et de certificat à l'aide des deux fichiers copiés ci-dessus sur les deux nœuds restants aoagvm2 et aoagvm3 . Exécutez la commande ci-dessous sur ces deux nœuds pour créer la clé principale :
--Create master key and certificate on remaining two nodes
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
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 = '[email protected]');
J'ai exécuté la commande ci-dessus sur le deuxième nœud aoagvm2 pour créer la clé principale et certificat . Jetez un oeil à la sortie d'exécution. Assurez-vous d'utiliser les mêmes mots de passe que lors de la création et de la sauvegarde du certificat et de la clé principale.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
2>CREATE CERTIFICATE dbm_certificate
3>FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
4>WITH PRIVATE KEY (FILE = '/var/opt/mssql/data/dbm_certificate.pvk', DECRYPTION BY PASSWORD = '[email protected]');
5>GO
1>
Exécutez la commande ci-dessus sur AOAGVM3 nœud également.
Maintenant, nous configurons les points de terminaison de mise en miroir de bases de données - auparavant, nous avons créé des certificats pour eux. Le point de terminaison de mise en miroir nommé hadr_endpoint doit être sur les 3 nœuds selon leur type de rôle respectif.
Comme les bases de données de disponibilité sont hébergées sur seulement 2 nœuds aoagvm1 et aoagvm2, nous exécuterons l'instruction ci-dessous uniquement sur ces nœuds. Le troisième nœud agira comme un témoin ; nous allons donc simplement changer le RÔLE pour témoigner dans le script ci-dessous, puis exécutez le T-SQL sur le troisième nœud aoagvm3 . Le script est :
--Configure database mirroring endpoint Hadr_endpoint on nodes aoagvm1 and aoagvm2
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE = ALL,
AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES);
--Start the newly created endpoint
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
Voici la sortie de la commande ci-dessus sur le nœud de réplica principal. Je me suis connecté à sqlcmd et l'exécuta. Assurez-vous de faire la même chose sur le 2ème nœud de réplica aoagvm2 aussi.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>CREATE ENDPOINT [Hadr_endpoint]
2>AS TCP (LISTENER_PORT = 5022)
3>FOR DATABASE_MIRRORING (ROLE = ALL, AUTHENTICATION = CERTIFICATE dbm_certificate, ENCRYPTION = REQUIRED ALGORITHM AES);
4>Go
1>ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
2>Go
1>
Une fois que vous avez exécuté le script T-SQL ci-dessus sur les 2 premiers nœuds, nous devons le modifier pour le troisième nœud - changez le ROLE en WITNESS.
Exécutez le script ci-dessous pour créer le point de terminaison de mise en miroir de la base de données sur le nœud témoin AOAGVM3 . Si vous souhaitez y héberger des bases de données de disponibilité, exécutez également la commande ci-dessus sur le nœud 3 réplica. Mais assurez-vous d'avoir installé la bonne édition de SQL Server pour obtenir cette fonctionnalité.
Si vous avez installé l'édition SQL Server Express sur le nœud 3 pour implémenter la configuration uniquement réplique , vous pouvez uniquement configurer RÔLE en tant que témoin pour ce nœud :
--Connect to the local SQL Server instance using sqlcmd
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
----Configure database mirroring endpoint Hadr_endpoint on 3rd node aoagvm3
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE = WITNESS, AUTHENTICATION = CERTIFICATE dbm_certificate, ENCRYPTION = REQUIRED ALGORITHM AES);
--Start the newly created endpoint on aoagvm3
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
Nous devons maintenant créer le groupe de disponibilité nommé ag1 .
Connectez-vous à l'instance SQL Server à l'aide de sqlcmd et exécutez la commande ci-dessous sur le nœud de réplica principal aoagvm1 :
--Connect to the local SQL Server instance using sqlcmd hosted on primary replica node aoagvm1
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
--Create availability group ag1
CREATE AVAILABILITY GROUP [ag1]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR REPLICA ON
N'aoagvm1’ WITH (ENDPOINT_URL = N'tcp://aoagvm1:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC),
N'aoagvm2' WITH (ENDPOINT_URL = N'tcp://aoagvm2:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC),
N'aoagvm3' WITH (ENDPOINT_URL = N'tcp://aoagvm3:5022',
AVAILABILITY_MODE = CONFIGURATION_ONLY);
--Assign required permission
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
Le script ci-dessus configure les répliques du groupe de disponibilité avec les paramètres de configuration ci-dessous (nous venons de les utiliser dans le script T-SQL) :
- CLUSTER_TYPE =EXTERNE car nous configurons un groupe de disponibilité sur des installations SQL Server basées sur Linux
- SEEDING_MODE =AUTOMATIQUE oblige SQL Server à créer automatiquement une base de données sur chaque réplica secondaire. Les bases de données de disponibilité ne seront pas créées sur le réplica de configuration uniquement
- FAILOVER_MODE =EXTERNE pour les répliques primaires et secondaires. cela signifie que le réplica interagit avec un gestionnaire de ressources de cluster externe, tel que Pacemaker
- AVAILABILITY_MODE =SYNCHRONOUS_COMMIT pour les réplicas principaux et secondaires pour le basculement automatique
- AVAILABILITY_MODE =CONFIGURATION_ONLY pour le 3ème réplica qui fonctionne comme un réplica de configuration uniquement
Nous devons également créer une connexion Pacemaker sur toutes les instances SQL Server. Cet utilisateur doit se voir attribuer le ALTER , CONTRÔLE , et AFFICHER DÉFINITION autorisations sur le groupe de disponibilité sur tous les réplicas. Pour accorder des autorisations, exécutez immédiatement le script T-SQL ci-dessous sur les 3 nœuds de réplica. Tout d'abord, nous allons créer une connexion Pacemaker. Ensuite, nous attribuerons les autorisations ci-dessus à cette connexion.
--Create pacemaker login on each SQL Server instance. Run below commands on all 3 SQL Server instances
CREATE LOGIN pacemaker WITH PASSWORD = '[email protected]@12'
--Grant permission to pacemaker login on newly created availability group. Run it on all 3 SQL Server instances
GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO pacemaker
GRANT VIEW SERVER STATE TO pacemaker
Après avoir attribué les autorisations appropriées à la connexion Pacemaker sur les 3 répliques, nous exécutons les scripts T-SQL ci-dessous pour rejoindre les répliques secondaires aoagvm2 et aoagvm3 au groupe de disponibilité nouvellement créé ag1 . Exécutez les commandes ci-dessous sur les réplicas secondaires aoagvm2 et aoagvm3 .
--Execute below commands on aoagvm2 and aoagvm3 to join availability group ag1
ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
Vous trouverez ci-dessous la sortie des exécutions ci-dessus sur le nœud aoagvm2 . Assurez-vous de l'exécuter sur aoagvm3 nœud également.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
2>Go
1>ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
2>Go
1>
Ainsi, nous avons configuré le groupe de disponibilité. Maintenant, nous devons ajouter un utilisateur ou une base de données de test à ce groupe de disponibilité. Si vous avez déjà créé une base de données utilisateur sur la réplique du nœud principal, exécutez simplement une sauvegarde complète, puis laissez l'amorçage automatique la restaurer sur le nœud secondaire.
Ainsi, exécutez la commande ci-dessous :
--Run a full backup of test database or user database hosted on primary replica aoagvm1
BACKUP DATABASE [Test] TO DISK = N'/var/opt/mssql/data/Test_15June.bak';
Ajoutons cette base de données Test au groupe de disponibilité ag1 . Exécutez l'instruction T-SQL ci-dessous sur le nœud principal aoagvm1 . Vous pouvez utiliser le sqlcmd utilitaire pour exécuter des instructions T-SQL.
--Add user database or test database to the availability group ag1
ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [Test];
Vous pouvez vérifier la base de données utilisateur ou une base de données de test que vous avez ajoutée au groupe de disponibilité en examinant l'instance SQL Server secondaire, qu'elle soit créée sur des réplicas secondaires ou non. Vous pouvez soit utiliser SQL Server Management Studio, soit exécuter une simple instruction T-SQL pour récupérer les détails de cette base de données.
--Verify test database is created on a secondary replica or not. Run it on secondary replica aoagvm2.
SELECT * FROM sys.databases WHERE name = 'Test';
GO
Vous obtiendrez le test base de données créée sur le réplica secondaire.
Avec l'étape ci-dessus, le groupe de disponibilité AlwaysOn a été configuré entre les trois nœuds. Cependant, ces nœuds ne sont pas encore groupés. Notre prochaine étape consiste à installer le pacemaker cluster sur eux. Ensuite, nous ajouterons le groupe de disponibilité ag1 en tant que ressource pour ce cluster.
Configuration du cluster PACEMAKER entre trois nœuds
Nous allons donc utiliser un gestionnaire de ressources de cluster externe PACEMAKER entre les 3 nœuds pour la prise en charge du cluster. Commençons par activer les ports du pare-feu entre les 3 nœuds.
Ouvrez les ports du pare-feu à l'aide de la commande ci-dessous :
--Run the below commands on all 3 nodes to open Firewall Ports
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
sudo ufw allow 5022/tcp
sudo ufw reload
--If you don't want to open specific firewall ports then alternatively you can disable the firewall on all 3 nodes by running the below command (THIS IS ALTERNATE & OPTIONAL APPROACH)
sudo ufw disable
Voir la sortie - celle-ci provient du réplica principal AOAGVM1 . Vous devez exécuter les commandes ci-dessus sur les trois nœuds, un par un. Le résultat devrait être similaire.
[email protected]:~$ sudo ufw allow 2224/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 3121/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 21064/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 5405/udp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 1433/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 5022/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw reload
Firewall not enabled (skipping reload)
Installer Pacemaker et corosync packages sur les 3 nœuds. Exécutez la commande ci-dessous sur chaque nœud - elle configurera Pacemaker , corosync , et agent d'escrime .
--Install Pacemaker packages on all 3 nodes aoagvm1, aoagvm2 and aoagvm3 by running the below command
sudo apt-get install pacemaker pcs fence-agents resource-agents
La sortie est énorme - près de 20 pages. J'ai copié les premières et dernières lignes pour l'illustrer (vous pouvez voir tous les packages installés) :
[email protected]:~$ sudo apt-get install pacemaker pcs fence-agents resource-agents
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
cluster-glue corosync fonts-dejavu-core fonts-lato fonts-liberation ibverbs-providers javascript-common libcfg6 libcib4 libcmap4 libcorosync-common4 libcpg4
libcrmcluster4 libcrmcommon3 libcrmservice3 libdbus-glib-1-2 libesmtp6 libibverbs1 libjs-jquery liblrm2 liblrmd1 libnet-telnet-perl libnet1 libnl-3-200
libnl-route-3-200 libnspr4 libnss3 libopenhpi3 libopenipmi0 libpe-rules2 libpe-status10 libpengine10 libpils2 libplumb2 libplumbgpl2 libqb0 libquorum5 librdmacm1
libruby2.5 libsensors4 libsgutils2-2 libsnmp-base libsnmp30 libstatgrab10 libstonith1 libstonithd2 libtimedate-perl libtotem-pg5 libtransitioner2 libvotequorum8
libxml2-utils openhpid pacemaker-cli-utils pacemaker-common pacemaker-resource-agents python-pexpect python-ptyprocess python-pycurl python3-bs4 python3-html5lib
python3-lxml python3-pycurl python3-webencodings rake ruby ruby-activesupport ruby-atomic ruby-backports ruby-did-you-mean ruby-ethon ruby-ffi ruby-highline
ruby-i18n ruby-json ruby-mime-types ruby-mime-types-data ruby-minitest ruby-multi-json ruby-net-telnet ruby-oj ruby-open4 ruby-power-assert ruby-rack
ruby-rack-protection ruby-rack-test ruby-rpam-ruby19 ruby-sinatra ruby-sinatra-contrib ruby-test-unit ruby-thread-safe ruby-tilt ruby-tzinfo ruby2.5
rubygems-integration sg3-utils snmp unzip xsltproc zip
Suggested packages:
ipmitool python-requests python-suds apache2 | lighttpd | httpd lm-sensors snmp-mibs-downloader python-pexpect-doc libcurl4-gnutls-dev python-pycurl-dbg
python-pycurl-doc python3-genshi python3-lxml-dbg python-lxml-doc python3-pycurl-dbg ri ruby-dev bundler
The following NEW packages will be installed:
cluster-glue corosync fence-agents fonts-dejavu-core fonts-lato fonts-liberation ibverbs-providers javascript-common libcfg6 libcib4 libcmap4 libcorosync-common4
libcpg4 libcrmcluster4 libcrmcommon3 libcrmservice3 libdbus-glib-1-2 libesmtp6 libibverbs1 libjs-jquery liblrm2 liblrmd1 libnet-telnet-perl libnet1 libnl-3-200
libnl-route-3-200 libnspr4 libnss3 libopenhpi3 libopenipmi0 libpe-rules2 libpe-status10 libpengine10 libpils2 libplumb2 libplumbgpl2 libqb0 libquorum5 librdmacm1
libruby2.5 libsensors4 libsgutils2-2 libsnmp-base libsnmp30 libstatgrab10 libstonith1 libstonithd2 libtimedate-perl libtotem-pg5 libtransitioner2 libvotequorum8
libxml2-utils openhpid pacemaker pacemaker-cli-utils pacemaker-common pacemaker-resource-agents pcs python-pexpect python-ptyprocess python-pycurl python3-bs4
python3-html5lib python3-lxml python3-pycurl python3-webencodings rake resource-agents ruby ruby-activesupport ruby-atomic ruby-backports ruby-did-you-mean
ruby-ethon ruby-ffi ruby-highline ruby-i18n ruby-json ruby-mime-types ruby-mime-types-data ruby-minitest ruby-multi-json ruby-net-telnet ruby-oj ruby-open4
ruby-power-assert ruby-rack ruby-rack-protection ruby-rack-test ruby-rpam-ruby19 ruby-sinatra ruby-sinatra-contrib ruby-test-unit ruby-thread-safe ruby-tilt
ruby-tzinfo ruby2.5 rubygems-integration sg3-utils snmp unzip xsltproc zip
0 upgraded, 103 newly installed, 0 to remove and 2 not upgraded.
Need to get 19.6 MB of archives.
After this operation, 86.0 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 fonts-lato all 2.0-2 [2698 kB]
Get:2 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 libdbus-glib-1-2 amd64 0.110-2 [58.3 kB]
…………
--------
Une fois que le pacemaker l'installation du cluster est terminée, le hacluster user sera renseigné automatiquement lors de l'exécution de la commande ci-dessous :
[email protected]:~$ cat /etc/passwd|grep hacluster
hacluster:x:111:115::/var/lib/pacemaker:/usr/sbin/nologin
Maintenant, nous pouvons définir le mot de passe pour l'utilisateur par défaut créé lors de l'installation de Pacemaker et le Corosync paquets. Assurez-vous d'utiliser le même mot de passe sur les 3 nœuds. Utilisez la commande ci-dessous :
--Set default user password on all 3 nodes
sudo passwd hacluster
Entrez le mot de passe lorsque vous y êtes invité :
[email protected]:~$ sudo passwd hacluster
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
L'étape suivante consiste à activer et démarrer le pcsd service et Pacemaker sur les 3 nœuds. Il permet aux 3 nœuds de rejoindre le cluster après le redémarrage. Exécutez la commande ci-dessous sur les 3 nœuds pour effectuer cette étape :
--Enable and start pcsd service and pacemaker
sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker
Voir l'exécution sur le réplica principal aoagvm1 . Assurez-vous de l'exécuter également sur les deux nœuds restants.
--Enable pcsd service
[email protected]:~$ sudo systemctl enable pcsd
Synchronizing state of pcsd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pcsd
--Start pcsd service
[email protected]:~$ sudo systemctl start pcsd
--Enable Pacemaker
[email protected]:~$ sudo systemctl enable pacemaker
Synchronizing state of pacemaker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pacemaker
Nous avons configuré le pacemaker paquets. Nous créons maintenant un cluster.
Tout d'abord, assurez-vous que vous n'avez aucun cluster précédemment configuré sur ces systèmes. Vous pouvez détruire toutes les configurations de cluster existantes de tous les nœuds en exécutant les commandes ci-dessous. Notez que la suppression de toute configuration de cluster arrêtera tous les services de cluster et désactivera le pacemaker service - il doit être réactivé.
--Destroy previously configured clusters to clean the systems
sudo pcs cluster destroy
--Reenable Pacemaker
sudo systemctl enable pacemaker
Vous trouverez ci-dessous la sortie du nœud de réplica principal aoagvm1 .
--Destroy previously configured clusters to clean the systems
[email protected]:~$ sudo pcs cluster destroy
Shutting down pacemaker/corosync services...
Killing any remaining services...
Removing all cluster configuration files...
--Reenable Pacemaker
[email protected]:~$ sudo systemctl enable pacemaker
Synchronizing state of pacemaker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pacemaker
Ensuite, nous créons le cluster à 3 nœuds entre les 3 nœuds à partir du réplica principal aoagvm1 . Important :Exécutez les commandes ci-dessous à partir de votre nœud principal uniquement !
--Create cluster. Modify below command with your node names, hacluster password and clustername
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
Consultez la sortie sur le nœud de réplica principal :
[email protected]:~$ sudo pcs cluster auth aoagvm1 aoagvm2 aoagvm3 -u hacluster -p hacluster
aoagvm1: Authorized
aoagvm2: Authorized
aoagvm3: Authorized
[email protected]:~$ sudo pcs cluster setup --name aoagvmcluster aoagvm1 aoagvm2 aoagvm3
Destroying cluster on nodes: aoagvm1, aoagvm2, aoagvm3...
aoagvm1: Stopping Cluster (pacemaker)...
aoagvm2: Stopping Cluster (pacemaker)...
aoagvm3: Stopping Cluster (pacemaker)...
aoagvm1: Successfully destroyed cluster
aoagvm2: Successfully destroyed cluster
aoagvm3: Successfully destroyed cluster
Sending 'pacemaker_remote authkey' to 'aoagvm1', 'aoagvm2', 'aoagvm3'
aoagvm1: successful distribution of the file 'pacemaker_remote authkey'
aoagvm2: successful distribution of the file 'pacemaker_remote authkey'
aoagvm3: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
aoagvm1: Succeeded
aoagvm2: Succeeded
aoagvm3: Succeeded
Synchronizing pcsd certificates on nodes aoagvm1, aoagvm2, aoagvm3...
aoagvm1: Success
aoagvm2: Success
aoagvm3: Success
Restarting pcsd on the nodes to reload the certificates...
aoagvm1: Success
aoagvm2: Success
aoagvm3: Success
[email protected]:~$ sudo pcs cluster start --all
aoagvm1: Starting Cluster...
aoagvm2: Starting Cluster...
aoagvm3: Starting Cluster...
[email protected]:~$ sudo pcs cluster enable --all
aoagvm1: Cluster Enabled
aoagvm2: Cluster Enabled
aoagvm3: Cluster Enabled
Escrime est l'une des configurations essentielles lors de l'utilisation du cluster PACEMAKER en production. Vous devez configurer le fencing pour votre cluster afin de vous assurer qu'il n'y aura pas de corruption de données en cas de panne .
Il existe deux types d'implémentation de clôture :
- Au niveau des ressources – garantit qu'un nœud ne peut pas utiliser une ou plusieurs ressources.
- Au niveau du nœud – garantit qu'un nœud n'exécute aucune ressource.
Nous utilisons généralement STONITH comme configuration de clôture - la clôture au niveau du nœud pour PACEMAKER .
Quand PACEMAKER ne peut pas déterminer l'état d'un nœud ou d'une ressource sur un nœud, la clôture ramène le cluster à un état connu. Pour y parvenir, PACEMAKER nous demande d'activer STONITH , qui signifie Tirez sur l'autre nœud dans la tête .
Nous ne nous concentrerons pas sur la configuration de clôture dans cet article, car la configuration de clôture au niveau du nœud dépend fortement de l'environnement individuel. Pour notre scénario, nous allons le désactiver en exécutant la commande ci-dessous :
--Disable fencing (STONITH)
sudo pcs property set stonith-enabled=false
Cependant, si vous prévoyez d'utiliser Pacemaker dans un environnement de production, vous devez planifier la mise en œuvre de STONITH en fonction de votre environnement et la maintenir activée.
Ensuite, nous allons définir certaines propriétés essentielles du cluster :cluster-recheck-interval, start-failure-is-fatal, et échec-délai .
Selon MSDN, si failure-timeout est défini sur 60 secondes, et cluster-recheck-interval est réglé sur 120 secondes, le redémarrage est tenté à un intervalle supérieur à 60 secondes mais inférieur à 120 secondes. Microsoft recommande de définir une valeur pour cluster-recheck-interval supérieur à la valeur de failure-timeout . Un autre paramètre start-failure-is-fatal doit être défini sur true . Sinon, le cluster n'initiera pas le basculement du réplica principal vers son réplica secondaire respectif, en cas de panne permanente.
Exécutez les commandes ci-dessous pour configurer les 3 propriétés importantes du cluster :
--Set cluster property cluster-recheck-interval to 2 minutes
sudo pcs property set cluster-recheck-interval=2min
--Set start-failure-is-fatal to True
sudo pcs property set start-failure-is-fatal=true
--Set failure-timeout to 60 seconds. Ag1 is the name of the availability group. Change this name with your availability group name.
pcs resource update ag1 meta failure-timeout=60s
Intégrer le groupe de disponibilité au groupe de clusters Pacemaker
Ici, notre objectif est de décrire le processus d'intégration du groupe de disponibilité nouvellement créé ag1 au nouveau pacemaker groupe de clusters.
Tout d'abord, nous allons installer l'agent de ressources SQL Server pour l'intégration avec Pacemaker sur les 3 nœuds :
--Install SQL Server Resource Agent on all 3 nodes
sudo apt-get install mssql-server-ha
J'ai exécuté la commande ci-dessus sur les 3 nœuds. Voir la sortie ci-dessous (extraite de aoagvm1 ):
--Install SQL Server resource agent for integration with Pacemaker
[email protected]:~$ sudo apt-get install mssql-server-ha
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
mssql-server-ha
0 upgraded, 1 newly installed, 0 to remove, and 2 not upgraded.
Need to get 1486 kB of archives.
After this operation, 9151 kB of additional disk space will be used.
Get:1 https://packages.microsoft.com/ubuntu/16.04/mssql-server-preview xenial/main amd64 mssql-server-ha amd64 15.0.1600.8-1 [1486 kB]
Fetched 1486 kB in 0s (4187 kB/s)
Selecting previously unselected package mssql-server-ha.
(Reading database ... 90430 files and directories currently installed.)
Preparing to unpack .../mssql-server-ha_15.0.1600.8-1_amd64.deb ...
Unpacking mssql-server-ha (15.0.1600.8-1) ...
Setting up mssql-server-ha (15.0.1600.8-1) ...
Répétez les étapes ci-dessus sur les 2 nœuds restants.
Nous avons déjà créé le pacemaker connectez-vous sur toutes les instances SQL Server hébergées sur 3 nœuds lorsque nous avons configuré le groupe de disponibilité ag1 . Maintenant, nous attribuons le rôle sysadmin sur les 3 instances SQL Server. Vous pouvez vous connecter en utilisant sqlcmd pour exécuter cette commande T-SQL. If you have not created the Pacemaker login, you can run the below command to do it.
--Create a pacemaker login if you missed creating it in the above section.
USE master
Go
CREATE LOGIN pacemaker WITH PASSWORD = '[email protected]@12'
Go
--Assign sysadmin role to pacemaker login on all 3 nodes. Run this T-SQL on all 3 SQL Server instances.
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemaker]
We must save the above SQL Server Pacemaker login and its credentials on all 3 nodes. Run the below command there:
--Save pacemaker login credentials on all 3 nodes by executing below commands on each node
echo 'pacemaker' >> ~/pacemaker-passwd
echo '[email protected]@12' >> ~/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
We will create the Availability Group Resource as master/subordinate .
We are using the pcs resource create command to create the Availability Group resource and set its properties. The following command will create the ocf:mssql:ag resource for the Availability Group ag1 .
The Pacemaker resource agent automatically sets the value of REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT on the Availability Group based on the Availability Group’s configuration during the creation of the Availability Group resource.
Execute the below command:
--Create availability group resource ocf:mssql:ag
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=30s --master meta notify=true
Next, we create a virtual IP resource in Pacemaker . Ensure you have the unused private IP address from your network . Replace the IP value with your virtual IP address. This IP will point to the primary replica and you can use it to make databases connections with active nodes.
The command is below:
--Configure virtual IP resource
sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=10.50.0.7
We are adding the colocation constraint and ordering constraint to the Pacemaker cluster configuration . These constraints help the virtual IP resource to make decisions on resources, e.g., where they should run.
Constraints have some scores, and Pacemaker uses these scores to make decisions. Scores are calculated per resource. The cluster resource manager chooses the node with the highest score for a particular resource.
The colocation constraint has an implicit ordering constraint . We need to add an ordering constraint to prevent the IP address from temporarily pointing to the node with the pre-failover secondary . Ordering constraint ensures the cluster comes online in a particular sequential manner.
Run the below commands to add colocation constraint and ordering constraint to the cluster.
--Add colocation constraint
sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master
--Add ordering constraint
sudo pcs constraint order promote ag_cluster-master then start virtualip
Hence, Two-Node Synchronous Replicas (aoagvm1 &aoagvm2) and a Configuration-Only Replica (aoagvm3) on PACEMAKER Cluster between 3-Node Ubuntu Systems has been completed.
We can test the configuration to validate the automatic failover. Run the below command to check the status of the Pacemaker cluster. The command also initiates the Availability Group failover.
Remember, once you couple your Availability Group with the PACEMAKER cluster, you cannot use T-SQL statements to initiate the Availability Group failovers. You can also shut down the primary replica to initiate the automatic failover.
The command is the following:
--Validate the PACEMAKER cluster configuration
sudo pcs status
--Initiate availability group failover to verify AOAG configuration
sudo pcs resource move ag_cluster-master aoagvm2 –master
Conclusion
This article was meant to help you understand the configuration of the Two-Node Synchronous Replicas and a Configuration-Only Replica on PACEMAKER Cluster. We hope that you got useful information that will help you in your workflow.
Always plan all steps carefully and do proper testing in a lower life cycle before deploying to your production environment.
We’ll be glad to hear your thoughts about this topic. Feel free to leave your feedback in a comment section.
