Cet article décrit comment créer un cluster à trois nœuds sur Linux en utilisant Pacemaker et comment ajouter un groupe de disponibilité précédemment créé en tant que ressource dans le cluster. Pour une haute disponibilité, un groupe de disponibilité sur Linux nécessite trois nœuds, consultez Haute disponibilité et protection des données pour les configurations de groupes de disponibilité.
SQL Server n’est pas aussi étroitement intégré à Pacemaker sur Linux qu’au clustering de basculement Windows Server (WSFC). Une instance de SQL Server n’a pas connaissance du cluster et toute l’orchestration se fait de l’extérieur vers l’intérieur. Pacemaker fournit une orchestration des ressources de cluster. En outre, le nom du réseau virtuel est spécifique au clustering de basculement Windows Server : il n’y a pas d’équivalent dans Pacemaker. Les vues de gestion dynamique (DMV) du groupe de disponibilité qui interrogent les informations de cluster renvoient des lignes vides sur les clusters de Pacemaker. Pour créer un écouteur pour une reconnexion transparente après le basculement, enregistrez manuellement le nom de l’écouteur dans DNS avec l’adresse IP utilisée pour créer la ressource d’adresse IP virtuelle.
Les sections suivantes décrivent les étapes à suivre pour configurer un cluster Pacemaker et ajouter un groupe de disponibilité en tant que ressource dans le cluster pour la haute disponibilité, pour chacune des distributions Linux prises en charge.
La couche de clustering est basée sur le module complémentaire haute disponibilité Red Hat Enterprise Linux (RHEL) basé sur Pacemaker.
Notes
L’accès à la documentation complète de Red Hat requiert un abonnement valide.
Pour plus d’informations sur la configuration du cluster, les options des agents de ressources et la gestion, consultez la documentation de référence de RHEL.
Feuille de route
Les étapes de création d’un groupe de disponibilité sur des serveurs Linux pour la haute disponibilité diffèrent de celles d’un cluster de basculement Windows Server. La liste suivante décrit les différentes étapes de haut niveau :
Configurez SQL Server sur les nœuds du cluster.
Créez le groupe de disponibilité.
Configurez un gestionnaire de ressources de cluster, comme Pacemaker. Ces instructions se trouvent dans cet article.
La façon de configurer un gestionnaire de ressources de cluster dépend de la distribution Linux spécifique.
Important
Les environnements de production nécessitent un agent de clôturage pour la haute disponibilité. Les démonstrations de cette documentation n’utilisent pas les agents de clôturage. Elles sont destinées uniquement à des fins de test et de validation.
Un cluster Linux utilise l’isolation pour ramener le cluster à un état connu. La façon de configurer l’isolation dépend de la distribution et de l’environnement. À ce stade, l’isolation n’est pas disponible dans certains environnements cloud. Pour plus d’informations, consultez Stratégies de support pour les clusters à haute disponibilité RHEL - Plateformes de virtualisation.
Ajoutez le groupe de disponibilité en tant que ressource dans le cluster.
Pour configurer la haute disponibilité pour RHEL, activez l’abonnement à haute disponibilité, puis configurez Pacemaker.
Activer l’abonnement haute disponibilité pour RHEL
Chaque nœud du cluster doit avoir un abonnement approprié pour RHEL et le module complémentaire haute disponibilité. Consultez les exigences sur Comment installer des packages de cluster haute disponibilité dans Red Hat Enterprise Linux. Procédez comme suit pour configurer l’abonnement et les référentiels :
Enregistrez le système.
sudo subscription-manager register
Fournissez vos nom d’utilisateur et mot de passe.
Répertoriez les pools disponibles pour l’inscription.
sudo subscription-manager list --available
Dans la liste des pools disponibles, notez l’ID de pool pour l’abonnement à haute disponibilité.
Mettez à jour le script suivant. Remplacez <pool id>
par l’ID de pool pour la haute disponibilité de l’étape précédente. Exécutez le script pour joindre l’abonnement.
sudo subscription-manager attach --pool=<pool id>
Activez le référentiel.
RHEL 7
sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
RHEL 8
sudo subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
Pour plus d’informations, consultez Pacemaker - Open source, cluster haute disponibilité.
Après avoir configuré l’abonnement, procédez comme suit pour configurer Pacemaker :
Après avoir inscrit l’abonnement, procédez comme suit pour configurer Pacemaker :
Sur tous les nœuds du cluster, ouvrez les ports de pare-feu de Pacemaker. Pour ouvrir ces ports avec firewalld
, exécutez la commande suivante :
sudo firewall-cmd --permanent --add-service=high-availability
sudo firewall-cmd --reload
Si le pare-feu n’a pas de configuration de haute disponibilité intégrée, ouvrez les ports suivants pour Pacemaker.
- TCP : Ports 2224, 3121, 21064
- UDP : Port 5405
Installez les packages Pacemaker sur tous les nœuds.
sudo yum install pacemaker pcs fence-agents-all resource-agents
Définissez le mot de passe pour l’utilisateur par défaut qui est créé pendant l’installation des packages Pacemaker et Corosync. Utilisez le même mot de passe sur tous les nœuds.
sudo passwd hacluster
Pour autoriser les nœuds à rejoindre le cluster après le redémarrage, activez et démarrez le service pcsd
et Pacemaker. Exécutez la commande suivante sur tous les nœuds.
sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker
Créez le cluster. Pour ce faire, exécutez la commande suivante :
RHEL 7
sudo pcs cluster auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup --name <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
RHEL 8
Pour RHEL 8, vous devez authentifier séparément les nodes. Entrez manuellement le nom d’utilisateur et le mot de passe pour hacluster lorsque vous y êtes invité.
sudo pcs host auth <node1> <node2> <node3>
sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
Notes
Si vous avez précédemment configuré un cluster sur les mêmes nœuds, vous devez utiliser l’option --force
pendant l’exécution de pcs cluster setup
. Cette option revient à exécuter pcs cluster destroy
. Pour réactiver Pacemaker, exécutez sudo systemctl enable pacemaker
.
Installez l’agent de ressources SQL Server pour SQL Server. Exécutez les commandes suivantes sur tous les nœuds.
sudo yum install mssql-server-ha
Une fois Pacemaker configuré, utilisez pcs
pour interagir avec le cluster. Exécutez toutes les commandes sur un nœud à partir du cluster.
Considérations dans le cas où il y a plusieurs interfaces réseau
Lors de la configuration de la haute disponibilité avec des serveurs ayant plusieurs cartes réseau, suivez ces suggestions :
Vérifiez que le fichier hosts
est configuré de sorte que les adresses IP du serveur pour les multiples cartes réseau sont résolues en nom d’hôte du serveur Linux sur chaque nœud.
Lors de la configuration du cluster en utilisant Pacemaker, l’utilisation du nom d’hôte des serveurs doit configurer Corosync pour définir la configuration de toutes les cartes réseau. Nous voulons une communication Pacemaker/Corosync sur une seule carte réseau. Une fois le cluster Pacemaker configuré, modifiez la configuration dans le fichier corosync.conf
et mettez à jour l’adresse IP de la carte réseau dédiée que vous voulez utiliser pour la communication Pacemaker/Corosync.
Le corosync.conf
donné dans le fichier <hostname>
doit être identique à la sortie donnée lors d’une recherche inversée (ping -a <ip_address>
) et doit être le nom court configuré sur l’hôte. Vérifiez que le fichier hosts
représente également l’adresse IP appropriée pour la résolution de noms.
Les modifications apportées à l’exemple de fichier corosync.conf
sont mises en surbrillance ci-dessous :
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Les fournisseurs de cluster Pacemaker nécessitent l’isolation d’un nœud défaillant, à l’aide d’un appareil d’isolation configuré pour une configuration de cluster prise en charge. Lorsque le gestionnaire des ressources de cluster ne peut pas déterminer l’état d’un nœud ou d’une ressource sur un nœud, l’isolation est utilisée pour ramener le cluster à un état connu.
Un appareil d’isolation fournit un agent d’isolation. Configuration de Pacemaker sur Red Hat Entreprise Linux dans Azure fournit un exemple de création d’un appareil d’isolation pour ce cluster dans Azure. Modifiez les instructions pour votre environnement.
L’isolation au niveau des ressources garantit qu’il n’y a pas d’altération des données lors d’une interruption pendant la configuration d’une ressource. Par exemple, vous pouvez utiliser l’isolation au niveau des ressources pour marquer le disque d’un nœud comme obsolète lorsque la liaison de communication tombe en panne.
Le clôturage au niveau du nœud garantit qu’un nœud n’exécute aucune ressource. Pour ce faire, réinitialisez le nœud. Pacemaker prend en charge un grand nombre d’appareils d’isolation. Les exemples incluent une alimentation sans coupure ou des cartes d’interface de gestion pour les serveurs.
Pour plus d’informations sur l’isolation d’un noeud défaillant, consultez les articles suivants :
Notes
Étant donné que la configuration d’isolation au niveau du nœud dépend fortement de votre environnement, désactivez-la pour ce didacticiel (il peut être configurer ultérieurement). Le script suivant désactive l’isolation au niveau du nœud :
sudo pcs property set stonith-enabled=false
La désactivation de l’isolation est uniquement à des fins de test. Si vous envisagez d’utiliser Pacemaker dans un environnement de production, vous devez planifier une implémentation de l’isolation en fonction de votre environnement et la garder activée.
Définir l’intervalle de revérification du cluster de la propriété du cluster
cluster-recheck-interval
indique l’intervalle d’interrogation selon lequel le cluster vérifie les modifications dans les paramètres de ressource, les contraintes ou d’autres options de cluster. Si un réplica tombe en panne, le cluster tente de redémarrer le réplica à un intervalle qui est lié par la valeur failure-timeout
et la valeur cluster-recheck-interval
. Par exemple, si failure-timeout
a la valeur de 60 secondes et cluster-recheck-interval
est défini sur 120 secondes, le redémarrage est tenté à un intervalle supérieur à 60 secondes, mais inférieur à 120 secondes. Nous vous recommandons de définir le délai d’expiration des défaillances sur 60 secondes et cluster-recheck-interval
sur une valeur supérieure à 60 secondes. Définir cluster-recheck-interval
sur une valeur plus petite n’est pas recommandé.
Pour mettre à jour la valeur de la propriété sur une exécution de 2 minutes
:
sudo pcs property set cluster-recheck-interval=2min
Si vous disposez déjà d’une ressource de groupe de disponibilité gérée par un cluster Pacemaker, notez que le package Pacemaker 1.1.18-11.el7 a introduit un changement de comportement pour le paramètre de cluster start-failure-is-fatal
quand sa valeur est false
. Cette modification affecte le workflow de basculement. Si un réplica principal subit une interruption, le cluster est censé basculer vers l’un des réplicas secondaires disponibles. Au lieu de cela, les utilisateurs remarquent que le cluster continue d’essayer de démarrer le réplica principal qui a échoué. Si ce principal ne passe jamais en ligne (en raison d’une interruption permanente), le cluster ne bascule jamais vers un autre réplica secondaire disponible. En raison de cette modification, une configuration précédemment recommandée pour définir start-failure-is-fatal
n’est plus valide et le paramètre doit être rétabli à la valeur par défaut true
.
En outre, la ressource du groupe de disponibilité doit être mise à jour pour inclure la propriété failure-timeout
.
Pour mettre à jour la valeur de la propriété sur une exécution de true
:
sudo pcs property set start-failure-is-fatal=true
Pour mettre à jour la propriété failure-timeout
de la ressource ag_cluster
sur 60s
, exécutez :
pcs resource update ag_cluster meta failure-timeout=60s
Pour plus d’informations sur les propriétés de cluster de Pacemaker, consultez Propriétés des clusters de Pacemaker.
Créer une connexion SQL Server pour Pacemaker
Sur toutes les instances SQL Server, créez un compte de connexion Server pour Pacemaker.
Le code Transact-SQL ci-dessous a pour effet de créer un compte de connexion :
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Au moment de la création du groupe de disponibilité, l’utilisateur Pacemaker requiert des autorisations ALTER
, CONTROL
et VIEW DEFINITION
sur le groupe de disponibilité, une fois qu’il a été créé mais avant l’ajout de nœuds à celui-ci.
Sur toutes les instances SQL Server, enregistrez les informations d’identification pour le compte de connexion SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Créer une ressource de groupe de disponibilité
Pour créer la ressource de groupe de disponibilité, utilisez la commande pcs resource create
et définissez les propriétés de la ressource. La commande suivante crée une ressource de type maître/subordonné ocf:mssql:ag
pour le groupe de disponibilité nommé ag1
.
RHEL 7
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s master notify=true
RHEL 8
Avec la disponibilité de RHEL 8, la syntaxe de création a changé. Si vous utilisez RHEL 8, la terminologie master
a été remplacée par promotable
. Utilisez la commande de création suivante à la place de la commande ci-dessus :
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s promotable notify=true
Notes
Quand vous créez la ressource et régulièrement par la suite, l’agent de ressource Pacemaker définit automatiquement la valeur de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
sur le groupe de disponibilité selon la configuration de celui-ci. Par exemple, si le groupe de disponibilité a trois réplicas synchrones, l’agent affecte à REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
la valeur 1
. Pour obtenir plus d’informations et d’options de configuration, consultez Haute disponibilité et protection des données pour les configurations des groupes de disponibilité.
Créer une ressource d’adresse IP virtuelle
Pour créer la ressource d’adresse IP virtuelle, exécutez la commande suivante sur un nœud. Utilisez une adresse IP statique disponible à partir du réseau. Remplacez l’adresse IP entre <10.128.16.240>
par une adresse IP valide.
sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<10.128.16.240>
Il n’y a aucun nom de serveur virtuel équivalent dans Pacemaker. Pour utiliser une chaîne de connexion qui pointe vers un nom de serveur de chaîne au lieu d’une adresse IP, enregistrez l’adresse de ressource IP et le nom de serveur virtuel souhaité dans DNS. Pour les configurations de récupération d’urgence, enregistrez le nom de serveur virtuel et l’adresse IP souhaités auprès des serveurs DNS sur le site principal et le site de récupération d’urgence.
Ajouter une contrainte de colocalisation
Presque toutes les décisions d’un cluster Pacemaker, comme le choix de l’emplacement dans lequel une ressource doit s’exécuter, s’effectuent en comparant les scores. Les scores sont calculés par ressource. Le gestionnaire de ressources de cluster choisit le nœud avec le score le plus élevé pour une ressource particulière. Si un nœud a un score négatif pour une ressource, la ressource ne peut pas être exécutée sur ce nœud.
Sur un cluster Pacemaker, vous pouvez manipuler les décisions du cluster avec les contraintes. Les contraintes ont un score. Si une contrainte a un score inférieur à INFINITY
, Pacemaker la considère comme une suggestion. Un score de INFINITY
est obligatoire.
Pour vous assurer que le réplica principal et les ressources d’adresse IP virtuelle sont exécutés sur le même hôte, définissez une contrainte de colocalisation avec un score INFINITY. Pour ajouter une contrainte de colocalisation, exécutez la commande suivante sur un nœud.
RHEL 7
Lorsque vous créez la ressource ag_cluster
dans RHEL 7, la ressource est créée en tant que ag_cluster-master
. Utilisez la commande suivante pour RHEL 7 :
sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master
RHEL 8
Lorsque vous créez la ressource ag_cluster
dans RHEL 8, la ressource est créée en tant que ag_cluster-clone
. Utilisez la commande suivante pour RHEL 8 :
sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY with-rsc-role=Master
Ajouter une contrainte de classement
La contrainte de colocalisation a une contrainte de classement implicite. Elle déplace la ressource IP virtuelle avant de déplacer la ressource de groupe de disponibilité. La séquence des événements par défaut est la suivante :
L’utilisateur émet pcs resource move
sur le groupe de disponibilité principal, de nœud1 à nœud2.
La ressource d’adresse IP virtuelle s’arrête sur le nœud 1.
La ressource d’adresse IP virtuelle démarre sur le nœud 2.
Notes
À ce stade, l’adresse IP pointe temporairement vers le nœud 2, tandis que le nœud 2 est toujours un secondaire de pré-basculement.
Le groupe de disponibilité principal sur nœud 1 est rétrogradé en secondaire.
Le groupe de disponibilité secondaire sur nœud 2 est promu en principal.
Pour empêcher l’adresse IP de pointer temporairement vers le nœud avec le secondaire antérieur au basculement, ajoutez une contrainte de classement.
Pour ajouter une contrainte de classement, exécutez la commande suivante sur un nœud :
RHEL 7
sudo pcs constraint order promote ag_cluster-master then start virtualip
RHEL 8
sudo pcs constraint order promote ag_cluster-clone then start virtualip
Important
Après avoir configuré le cluster et ajouté le groupe de disponibilité en tant que ressource de cluster, vous ne pouvez pas utiliser Transact-SQL pour basculer les ressources du groupe de disponibilité. Les ressources de cluster SQL Server sur Linux ne sont pas couplées aussi étroitement au système d’exploitation, car elles se trouvent sur un cluster de basculement Windows Server (WSFC). SQL Server service n’est pas informé de la présence du cluster. Toutes les orchestrations sont effectuées via les outils d’administration de cluster. Dans RHEL ou Ubuntu utilisez pcs
et dans SLES, utilisez les outils crm
.
Basculez manuellement le groupe de disponibilité avec pcs
. N’initialisez pas le basculement avec Transact-SQL. Pour obtenir des instructions, consultez Basculement.
Contenu connexe
La couche de clustering est basée sur l’Extension haute disponibilité (HAE) de SUSE placée au-dessus de Pacemaker.
Pour plus d’informations sur la configuration du cluster, les options de l’agent de ressources, la gestion, les meilleures pratiques et les suggestions, consultez Extension haute disponibilité SUSE Linux Enterprise.
Feuille de route
La procédure de création d’un groupe de disponibilité pour la haute disponibilité varie entre les serveurs Linux et un cluster de basculement Windows Server. La liste suivante décrit les différentes étapes de haut niveau :
Configurez SQL Server sur les nœuds du cluster.
Créez le groupe de disponibilité.
Configurez un gestionnaire de ressources de cluster, comme Pacemaker. Ces instructions se trouvent dans cet article.
La façon de configurer un gestionnaire de ressources de cluster dépend de la distribution Linux spécifique.
Important
Les environnements de production nécessitent un agent d’isolation pour la haute disponibilité. Les exemples de cet article n’utilisent pas les agents d’isolation. Ils sont destinés uniquement à des fins de test et de validation.
Un cluster Linux utilise l’isolation pour ramener le cluster à un état connu. La façon de configurer l’isolation dépend de la distribution et de l’environnement. À ce stade, l’isolation n’est pas disponible dans certains environnements cloud. Pour plus d’informations, consultez l’Extension de haute disponibilité de SUSE Linux Enteprise.
Ajouter le groupe de disponibilité en tant que ressource dans le cluster
Prérequis
Pour effectuer le scénario de bout en bout suivant, vous avez besoin de trois machines pour déployer le cluster à trois nœuds. Les étapes suivantes décrivent la configuration de ces serveurs.
La première étape consiste à configurer le système d'exploitation sur les nœuds de cluster. Pour ce guide, utilisez SLES 12 SP3 avec un abonnement valide pour le module complémentaire de haute disponibilité.
Installez et configurez le service SQL Server sur tous les nœuds. Pour obtenir des instructions détaillées, consultez Guide à l’installation de SQL Server sur Linux.
Désignez un nœud en tant que principal et d’autres nœuds en tant que secondaires. Utilisez ces termes dans ce guide.
Assurez-vous que les nœuds qui vont faire partie du cluster peuvent communiquer entre eux.
L’exemple suivant présente /etc/hosts
avec des ajouts pour trois nœuds nommés SLES1, SLES2 et SLES3.
127.0.0.1 localhost
10.128.16.33 SLES1
10.128.16.77 SLES2
10.128.16.22 SLES3
Tous les nœuds de cluster doivent pouvoir accéder aux uns et aux autres via SSH. Certains outils, comme hb_report
ou crm_report
(pour la résolution des problèmes) et l’Explorateur d’historique de Hawk, exigent un accès SSH sans mot de passe entre les nœuds, sinon ils ne peuvent collecter que les données du nœud actif. Si vous utilisez un port SSH non standard, utilisez l’option -X (consultez la page man
). Par exemple, si votre port SSH est le 3479, appelez un crm_report
avec :
sudo crm_report -X "-p 3479" [...]
Pour plus d’informations, consultez la section Guide d’administration SLES - Divers.
Créer une connexion SQL Server pour Pacemaker
Sur toutes les instances SQL Server, créez un compte de connexion Server pour Pacemaker.
Le code Transact-SQL ci-dessous a pour effet de créer un compte de connexion :
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Au moment de la création du groupe de disponibilité, l’utilisateur Pacemaker requiert des autorisations ALTER
, CONTROL
et VIEW DEFINITION
sur le groupe de disponibilité, une fois qu’il a été créé mais avant l’ajout de nœuds à celui-ci.
Sur toutes les instances SQL Server, enregistrez les informations d’identification pour le compte de connexion SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Sur les serveurs Linux, configurez le groupe de disponibilité, puis configurez les ressources de cluster. Pour configurer le groupe de disponibilité, consultez Configurer le groupe de disponibilité Always On pour haute disponibilité sur Linux
Installer l’extension de haute disponibilité
Pour référence, consultez Installation de SUSE Linux Enterprise Server et de l’extension de haute disponibilité.
Installez le package d’agents de ressources SQL Server sur les deux nœuds.
sudo zypper install mssql-server-ha
Configurer le premier nœud
Référez-vous aux instructions d'installation SLES.
Connectez-vous en tant que root
à la machine physique ou virtuelle que vous voulez utiliser en tant que nœud de cluster.
Démarrez le script de démarrage en exécutant :
sudo ha-cluster-init
Si NTP n’a pas été configuré pour démarrer au moment du démarrage, un message s’affiche.
Si vous décidez néanmoins de continuer, le script génère automatiquement des clés pour l’accès SSH et pour l’outil de synchronisation Csync2, et démarre les services nécessaires pour les deux.
Pour configurer la couche de communication du cluster (Corosync) :
Entrez une adresse réseau à laquelle effectuer la liaison. Par défaut, le script propose l’adresse réseau d’eth0. Vous pouvez également entrer une autre adresse réseau, par exemple l’adresse de bond0.
Entrez une adresse de multidiffusion. Le script propose une adresse aléatoire que vous pouvez utiliser par défaut.
Entrez un port de multidiffusion. Le script propose 5405 comme valeur par défaut.
Pour configurer SBD ()
, entrez un chemin d’accès permanent à la partition de votre appareil de bloc que vous souhaitez utiliser pour SBD. Le chemin d’accès doit être cohérent sur tous les nœuds du cluster.
Enfin, le script démarre le service Pacemaker pour mettre le cluster à un nœud en ligne et activer l’interface de gestion Web Hawk2. L’URL à utiliser pour Hawk2 s’affiche à l’écran.
Pour obtenir des détails sur le processus d’installation, cochez /var/log/sleha-bootstrap.log
. Vous disposez maintenant d’un cluster à un nœud en cours d’exécution. Vérifiez l’état du cluster à l’aide de l’état crm :
sudo crm status
Vous pouvez également consulter la configuration du cluster avec crm configure show xml
ou crm configure show
.
La procédure de démarrage crée un utilisateur Linux nommé hacluster avec le mot de passe linux. Remplacez le mot de passe par défaut par un mot de passe sécurisé dès que possible :
sudo passwd hacluster
Ajouter des nœuds à un cluster existant
Si vous avez un cluster en cours d’exécution avec un ou plusieurs nœuds, ajoutez des nœuds de cluster supplémentaires avec le script de démarrage de la jonction de clusters à haute disponibilité. Le script a uniquement besoin d’accéder à un nœud de cluster existant et effectue automatiquement le programme d’installation de base sur la machine actuelle. Utiliser les étapes suivantes :
Si vous avez configuré les nœuds de cluster existants à l’aide du module de cluster YaST
, assurez-vous que les conditions préalables suivantes sont remplies avant d’exécuter ha-cluster-join
:
- L’utilisateur racine sur les nœuds existants a des clés SSH en place pour la connexion sans mot de passe.
Csync2
est configuré sur les nœuds existants. Pour plus d’informations, consultez Configuration de Csync2 avec YaST.
Connectez-vous en tant que root
à la machine physique ou virtuelle censée rejoindre le cluster.
Démarrez le script de démarrage en exécutant :
sudo ha-cluster-join
Si NTP n’a pas été configuré pour démarrer au moment du démarrage, un message s’affiche.
Si vous décidez de continuer, vous êtes invités à entrer l’adresse IP d’un nœud existant. Entrez l’adresse IP.
Si vous n’avez pas encore configuré un accès SSH sans mot de passe entre les deux machines, vous êtes également invités à entrer le mot de passe de root du nœud existant.
Une fois connecté au nœud spécifié, le script copie la configuration Corosync, configure SSH et Csync2
, puis met la machine actuelle en ligne en tant que nouveau nœud de cluster. En outre, il démarre le service nécessaire à Hawk. Si vous avez configuré le stockage partagé avec OCFS2
, il crée également automatiquement le répertoire de montage pour le système de fichiers OCFS2
.
Répétez les étapes précédentes pour toutes les machines que vous souhaitez ajouter au cluster.
Pour plus d’informations sur le processus, vérifiez /var/log/ha-cluster-bootstrap.log
.
Vérifiez l’état du cluster à l’aide de sudo crm status
. Si vous avez réussi à ajouter le deuxième nœud, voici ce que vous obtenez en sortie :
sudo crm status
Vous voyez une sortie similaire à l’exemple suivant.
3 nodes configured
1 resource configured
Online: [ SLES1 SLES2 SLES3]
Full list of resources:
admin_addr (ocf::heartbeat:IPaddr2): Started node1
Remarque
admin_addr
est la ressource de cluster IP virtuelle qui est configurée pendant l’installation initiale du cluster à un nœud.
Après avoir ajouté tous les nœuds, vérifiez si vous devez ajuster la stratégie de non-quorum dans les options de cluster global. Cela est particulièrement important pour les clusters à deux nœuds.
Définir l’intervalle de revérification du cluster de la propriété du cluster
cluster-recheck-interval
indique l’intervalle d’interrogation selon lequel le cluster vérifie les modifications dans les paramètres de ressource, les contraintes ou d’autres options de cluster. Si un réplica tombe en panne, le cluster tente de redémarrer le réplica à un intervalle qui est lié par la valeur failure-timeout
et la valeur cluster-recheck-interval
. Par exemple, si failure-timeout
a la valeur de 60 secondes et cluster-recheck-interval
est défini sur 120 secondes, le redémarrage est tenté à un intervalle supérieur à 60 secondes, mais inférieur à 120 secondes. Nous vous recommandons de définir le délai d’expiration des défaillances sur 60 secondes et cluster-recheck-interval
sur une valeur supérieure à 60 secondes. Définir cluster-recheck-interval
sur une valeur plus petite n’est pas recommandé.
Pour mettre à jour la valeur de la propriété sur une exécution de 2 minutes
:
crm configure property cluster-recheck-interval=2min
Si vous disposez déjà d’une ressource de groupe de disponibilité gérée par un cluster Pacemaker, notez que le package Pacemaker 1.1.18-11.el7 a introduit un changement de comportement pour le paramètre de cluster start-failure-is-fatal
quand sa valeur est false
. Cette modification affecte le workflow de basculement. Si un réplica principal subit une interruption, le cluster est censé basculer vers l’un des réplicas secondaires disponibles. Au lieu de cela, les utilisateurs remarquent que le cluster continue d’essayer de démarrer le réplica principal qui a échoué. Si ce principal ne passe jamais en ligne (en raison d’une interruption permanente), le cluster ne bascule jamais vers un autre réplica secondaire disponible. En raison de cette modification, une configuration précédemment recommandée pour définir start-failure-is-fatal
n’est plus valide et le paramètre doit être rétabli à la valeur par défaut true
.
En outre, la ressource du groupe de disponibilité doit être mise à jour pour inclure la propriété failure-timeout
.
Pour mettre à jour la valeur de la propriété sur une exécution de true
:
crm configure property start-failure-is-fatal=true
Mettez à jour la propriété de ressource de votre groupe de disponibilité existant failure-timeout
pour une exécution de 60s
(remplacez ag1
par le nom de votre ressource de groupe de disponibilité) :
crm configure edit ag1
Dans l’éditeur de texte, ajoutez meta failure-timeout=60s
après les éléments param
et avant les éléments op
.
Pour plus d’informations sur les propriétés de cluster Pacemaker, consultez Configuration des ressources de cluster.
Considérations dans le cas où il y a plusieurs interfaces réseau
Lors de la configuration de la haute disponibilité avec des serveurs ayant plusieurs cartes réseau, suivez ces suggestions :
Vérifiez que le fichier hosts
est configuré de sorte que les adresses IP du serveur pour les multiples cartes réseau sont résolues en nom d’hôte du serveur Linux sur chaque nœud.
Lors de la configuration du cluster en utilisant Pacemaker, l’utilisation du nom d’hôte des serveurs doit configurer Corosync pour définir la configuration de toutes les cartes réseau. Nous voulons une communication Pacemaker/Corosync sur une seule carte réseau. Une fois le cluster Pacemaker configuré, modifiez la configuration dans le fichier corosync.conf
et mettez à jour l’adresse IP de la carte réseau dédiée que vous voulez utiliser pour la communication Pacemaker/Corosync.
Le corosync.conf
donné dans le fichier <hostname>
doit être identique à la sortie donnée lors d’une recherche inversée (ping -a <ip_address>
) et doit être le nom court configuré sur l’hôte. Vérifiez que le fichier hosts
représente également l’adresse IP appropriée pour la résolution de noms.
Les modifications apportées à l’exemple de fichier corosync.conf
sont mises en surbrillance ci-dessous :
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Les fournisseurs de cluster Pacemaker nécessitent l’isolation d’un nœud défaillant, à l’aide d’un appareil d’isolation configuré pour une configuration de cluster prise en charge. Lorsque le gestionnaire des ressources de cluster ne peut pas déterminer l’état d’un nœud ou d’une ressource sur un nœud, l’isolation est utilisée pour ramener le cluster à un état connu.
L’isolation au niveau des ressources garantit principalement qu’il n’y a pas d’altération des données pendant une interruption en configurant une ressource. Vous pouvez utiliser l’isolation au niveau des ressources, par exemple, avec DRBD (périphérique de bloc répliqué distribué) pour marquer le disque d’un nœud comme obsolète lorsque la liaison de communication tombe en panne.
Le clôturage au niveau du nœud garantit qu’un nœud n’exécute aucune ressource. Pour ce faire, réinitialisez le nœud et l’implémentation de Pacemaker est appelée STONITH. Pacemaker prend en charge un grand nombre de périphériques d’isolation, tels qu’une alimentation sans coupure ou des cartes d’interface de gestion pour des serveurs.
Pour plus d'informations, consultez les pages suivantes :
Au moment de l’initialisation du cluster, l’isolation est désactivée si aucune configuration n’est détectée. Vous pouvez l’activer ultérieurement en exécutant la commande suivante :
sudo crm configure property stonith-enabled=true
Important
La désactivation de l’isolation est uniquement à des fins de test. Si vous envisagez d’utiliser Pacemaker dans un environnement de production, vous devez planifier une implémentation de l’isolation en fonction de votre environnement et la garder activée. SUSE ne fournit pas d’agents d’isolation pour les environnements cloud (y compris Azure) ou Hyper-V. En fait, le fournisseur de cluster n’offre pas de prise en charge pour l’exécution de clusters de production dans ces environnements. Nous travaillons sur une solution pour cet intervalle qui sera disponible dans les mises en production ultérieures.
Reportez-vous au Guide d'administration SLES.
Activer Pacemaker
Activez Pacemaker afin qu’il démarre automatiquement.
Exécutez la commande suivante sur chaque nœud du cluster.
systemctl enable pacemaker
Créer une ressource de groupe de disponibilité
La commande suivante crée et configure la ressource de groupe de disponibilité pour trois réplicas du groupe de disponibilité [AG1]. Les opérations et les délais d’expiration de l’analyse doivent être spécifiés explicitement dans SLES en fonction du fait que les délais d’expiration dépendent fortement de la charge de travail et doivent être ajustés avec soin pour chaque déploiement.
Exécutez la commande sur l’un des nœuds du cluster :
Exécutez crm configure
pour ouvrir l’invite crm :
sudo crm configure
Dans l’invite crm, exécutez la commande suivante pour configurer les propriétés de la ressource.
primitive ag_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag_cluster ag_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true" \
commit
Notes
Quand vous créez la ressource et régulièrement par la suite, l’agent de ressource Pacemaker définit automatiquement la valeur de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
sur le groupe de disponibilité selon la configuration de celui-ci. Par exemple, si le groupe de disponibilité a trois réplicas synchrones, l’agent affecte à REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
la valeur 1
. Pour obtenir plus d’informations et d’options de configuration, consultez Haute disponibilité et protection des données pour les configurations des groupes de disponibilité.
Créer une ressource d’adresse IP virtuelle
Si vous n’avez pas créé la ressource d’adresse IP virtuelle au moment de l’exécution de ha-cluster-init
, vous pouvez créer cette ressource maintenant. La commande suivante crée une ressource d’adresse IP virtuelle. Remplacez <**0.0.0.0**>
par une adresse disponible de votre réseau et <**24**>
par le nombre de bits dans le masque de sous-réseau CIDR. Exécutez sur un nœud.
crm configure \
primitive admin_addr \
ocf:heartbeat:IPaddr2 \
params ip=<**0.0.0.0**> \
cidr_netmask=<**24**>
Ajouter une contrainte de colocalisation
Presque toutes les décisions d’un cluster Pacemaker, comme le choix de l’emplacement dans lequel une ressource doit s’exécuter, s’effectuent en comparant les scores. Les scores sont calculés par ressource et le gestionnaire de ressources de cluster choisit le nœud avec le score le plus élevé pour une ressource particulière. (Si un nœud a un score négatif pour une ressource, la ressource ne peut pas être exécutée sur ce nœud.) Nous pouvons manipuler les décisions du cluster avec les contraintes. Les contraintes ont un score. Si une contrainte a un score inférieur à INFINITY, il ne s’agit que d’une suggestion. Un score INFINITY signifie qu’il s’agit d’une obligation. Nous voulons nous assurer que le principal du groupe de disponibilité et la ressource d’adresse IP virtuelle sont exécutés sur le même hôte. Nous définissons donc une contrainte de colocalisation avec un score INFINITY.
Pour définir une contrainte de colocalisation pour que l’adresse IP virtuelle s’exécute sur le même nœud que le nœud principal, exécutez la commande suivante sur un nœud :
crm configure
colocation vip_on_master inf: \
admin_addr ms-ag_cluster:Master
commit
Ajouter une contrainte de classement
La contrainte de colocalisation a une contrainte de classement implicite. Elle déplace la ressource IP virtuelle avant de déplacer la ressource de groupe de disponibilité. La séquence des événements par défaut est la suivante :
- L’utilisateur émet
resource migrate
sur le groupe de disponibilité principal, de nœud1 à nœud2.
- La ressource d’adresse IP virtuelle s’arrête sur le nœud 1.
- La ressource d’adresse IP virtuelle démarre sur le nœud 2. À ce stade, l’adresse IP pointe temporairement vers le nœud 2, tandis que le nœud 2 est toujours un secondaire de pré-basculement.
- Le master du groupe de disponibilité sur le nœud 1 est rétrogradé.
- Le groupe de disponibilité sur le nœud 2 est promu master.
Pour empêcher l’adresse IP de pointer temporairement vers le nœud avec le secondaire antérieur au basculement, ajoutez une contrainte de classement.
Pour ajouter une contrainte de classement, exécutez la commande suivante sur un nœud :
sudo crm configure \
order ag_first inf: ms-ag_cluster:promote admin_addr:start
Important
Après avoir configuré le cluster et ajouté le groupe de disponibilité en tant que ressource de cluster, vous ne pouvez pas utiliser Transact-SQL pour basculer les ressources du groupe de disponibilité. Les ressources de cluster SQL Server sur Linux ne sont pas couplées aussi étroitement au système d’exploitation, car elles se trouvent sur un cluster de basculement Windows Server (WSFC). SQL Server service n’est pas informé de la présence du cluster. Toutes les orchestrations sont effectuées via les outils d’administration de cluster. Dans SLES utilisez crm
.
Basculez manuellement le groupe de disponibilité avec crm
. N’initialisez pas le basculement avec Transact-SQL. Pour plus d'informations, consultez Basculement.
Pour plus d’informations, consultez l’article suivant :
Contenu connexe
Feuille de route
Les étapes de création d’un groupe de disponibilité sur des serveurs Linux pour la haute disponibilité diffèrent de celles d’un cluster de basculement Windows Server. La liste suivante décrit les différentes étapes de haut niveau :
Conseils d’installation pour SQL Server sur Linux.
Configurer le groupe de disponibilité Always On SQL Server sur Linux.
Configurez un gestionnaire de ressources de cluster, comme Pacemaker. Ces instructions se trouvent dans cet article.
La façon de configurer un gestionnaire de ressources de cluster dépend de la distribution Linux spécifique.
Important
Les environnements de production nécessitent un agent d’isolation pour la haute disponibilité. Les exemples de cet article n’utilisent pas les agents d’isolation. Ils sont destinés uniquement à des fins de test et de validation.
Un cluster Linux utilise l’isolation pour ramener le cluster à un état connu. La façon de configurer l’isolation dépend de la distribution et de l’environnement. À ce stade, l’isolation n’est pas disponible dans certains environnements cloud.
L’isolation est généralement implémentée au niveau du système d’exploitation et dépend de l’environnement. Pour plus d’informations sur l’isolation, consultez la documentation du fournisseur du système d’exploitation.
Ajoutez le groupe de disponibilité en tant que ressource dans le cluster.
Sur tous les nœuds, ouvrez les ports du pare-feu. Ouvrez le port pour le service de haute disponibilité de Pacemaker, l’instance et le point de terminaison du groupe de disponibilité. Le port TCP par défaut pour le serveur exécutant SQL Server est 1433
.
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 21064/tcp
sudo ufw allow 5405/udp
sudo ufw allow 1433/tcp # Replace with TDS endpoint
sudo ufw allow 5022/tcp # Replace with DATA_MIRRORING endpoint
sudo ufw reload
Vous pouvez également désactiver le pare-feu, mais cela n’est pas recommandé dans un environnement de production :
sudo ufw disable
Installez les packages Pacemaker. Exécutez les commandes suivantes sur tous les nœuds pour Ubuntu 20.04. Pour plus d’informations sur l’installation sur les versions précédentes, consultez Ubuntu HA - MS SQL Server sur Azure.
sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents fence-agents corosync python3-azure
Définissez le mot de passe pour l’utilisateur par défaut qui est créé pendant l’installation des packages Pacemaker et Corosync. Utilisez le même mot de passe sur tous les nœuds.
sudo passwd hacluster
Créer le cluster
Avant de créer un cluster, vous devez créer une clé d’authentification sur le serveur principal et la copier sur les autres serveurs faisant partie du groupe de disponibilité.
Utilisez le script suivant pour créer une clé d’authentification sur le serveur principal :
sudo corosync-keygen
Vous pouvez utiliser scp
pour copier la clé générée sur d’autres serveurs :
sudo scp /etc/corosync/authkey dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/authkey dbadmin@server-03:/etc/corosync
Pour créer le cluster, modifiez le fichier /etc/corosync/corosync.conf
sur le serveur principal :
sudo vim /etc/corosync/corosync.conf
Le fichier corosync.conf
doit ressembler à l’exemple suivant :
totem {
version: 2
cluster_name: agclustername
transport: udpu
crypto_cipher: none
crypto_hash: none
}
logging {
fileline: off
to_stderr: yes
to_logfile: yes
logfile: /var/log/corosync/corosync.log
to_syslog: yes
debug: off
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
}
nodelist {
node {
name: server-01
nodeid: 1
ring0_addr: 10.0.0.4
}
node {
name: server-02
nodeid: 2
ring0_addr: 10.0.0.5
}
node {
name: server-03
nodeid: 3
ring0_addr: 10.0.0.6
}
}
Remplacez le fichier corosync.conf
sur d’autres nœuds :
sudo scp /etc/corosync/corosync.conf dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/corosync.conf dbadmin@server-03:/etc/corosync
Redémarrez les services pacemaker
et corosync
:
sudo systemctl restart pacemaker corosync
Confirmez l’état du cluster et vérifiez la configuration :
sudo crm status
Considérations dans le cas où il y a plusieurs interfaces réseau
Lors de la configuration de la haute disponibilité avec des serveurs ayant plusieurs cartes réseau, suivez ces suggestions :
Vérifiez que le fichier hosts
est configuré de sorte que les adresses IP du serveur pour les multiples cartes réseau sont résolues en nom d’hôte du serveur Linux sur chaque nœud.
Lors de la configuration du cluster en utilisant Pacemaker, l’utilisation du nom d’hôte des serveurs doit configurer Corosync pour définir la configuration de toutes les cartes réseau. Nous voulons une communication Pacemaker/Corosync sur une seule carte réseau. Une fois le cluster Pacemaker configuré, modifiez la configuration dans le fichier corosync.conf
et mettez à jour l’adresse IP de la carte réseau dédiée que vous voulez utiliser pour la communication Pacemaker/Corosync.
Le corosync.conf
donné dans le fichier <hostname>
doit être identique à la sortie donnée lors d’une recherche inversée (ping -a <ip_address>
) et doit être le nom court configuré sur l’hôte. Vérifiez que le fichier hosts
représente également l’adresse IP appropriée pour la résolution de noms.
Les modifications apportées à l’exemple de fichier corosync.conf
sont mises en surbrillance ci-dessous :
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Les fournisseurs de cluster Pacemaker nécessitent l’isolation d’un nœud défaillant, à l’aide d’un appareil d’isolation configuré pour une configuration de cluster prise en charge. Lorsque le gestionnaire des ressources de cluster ne peut pas déterminer l’état d’un nœud ou d’une ressource sur un nœud, l’isolation est utilisée pour ramener le cluster à un état connu.
Le clôturage au niveau des ressources garantit qu’aucune altération des données ne se produit en cas de panne. Vous pouvez utiliser l’isolation au niveau des ressources, par exemple, avec DRBD (périphérique de bloc répliqué distribué) pour marquer le disque d’un nœud comme obsolète lorsque la liaison de communication tombe en panne.
Le clôturage au niveau du nœud garantit qu’un nœud n’exécute aucune ressource. Pour ce faire, réinitialisez le nœud et l’implémentation de Pacemaker est appelée STONITH. Pacemaker prend en charge un grand nombre de périphériques de clôturage, tels qu’une alimentation sans coupure ou des cartes d’interface de gestion pour des serveurs.
Pour plus d’informations, consultez Clusters Pacemaker à partir de zéro et Clôturage et Stonith.
Étant donné que la configuration d’isolation au niveau du nœud dépend fortement de votre environnement, nous la désactivons pour ce didacticiel (vous pouvez la configurer ultérieurement). Exécutez le script suivant sur le réplica principal :
sudo crm configure property stonith-enabled=false
Dans cet exemple, la désactivation de l’isolation est uniquement à des fins de test. Si vous envisagez d’utiliser Pacemaker dans un environnement de production, vous devez planifier une implémentation de l’isolation en fonction de votre environnement et la garder activée. Contactez le fournisseur du système d’exploitation pour obtenir des informations sur les agents d’isolation pour toute distribution spécifique.
Définir l’intervalle de revérification du cluster de la propriété du cluster
La propriété cluster-recheck-interval
indique l’intervalle d’interrogation selon lequel le cluster vérifie les modifications dans les paramètres de ressource, les contraintes ou d’autres options de cluster. Si un réplica tombe en panne, le cluster tente de redémarrer le réplica à un intervalle qui est lié par la valeur failure-timeout
et la valeur cluster-recheck-interval
. Par exemple, si failure-timeout
a la valeur de 60 secondes et cluster-recheck-interval
est défini sur 120 secondes, le redémarrage est tenté à un intervalle supérieur à 60 secondes, mais inférieur à 120 secondes. Vous devez définir failure-timeout
sur 60 secondes et cluster-recheck-interval
sur une valeur supérieure à 60 secondes. La définition de cluster-recheck-interval
sur une valeur plus petite n’est pas recommandée.
Pour mettre à jour la valeur de la propriété sur une exécution de 2 minutes
:
sudo crm configure property cluster-recheck-interval=2min
Si vous disposez déjà d’une ressource de groupe de disponibilité gérée par un cluster Pacemaker, notez que le package Pacemaker 1.1.18-11.el7 a introduit un changement de comportement pour le paramètre de cluster start-failure-is-fatal
quand sa valeur est false
. Cette modification affecte le workflow de basculement. Si un réplica principal subit une interruption, le cluster est censé basculer vers l’un des réplicas secondaires disponibles. Au lieu de cela, les utilisateurs remarquent que le cluster continue d’essayer de démarrer le réplica principal qui a échoué. Si ce principal ne passe jamais en ligne (en raison d’une interruption permanente), le cluster ne bascule jamais vers un autre réplica secondaire disponible. En raison de cette modification, une configuration précédemment recommandée pour définir start-failure-is-fatal
n’est plus valide et le paramètre doit être rétabli à la valeur par défaut true
.
En outre, la ressource du groupe de disponibilité doit être mise à jour pour inclure la propriété failure-timeout
.
Pour mettre à jour la valeur de la propriété sur une exécution de true
:
sudo crm configure property start-failure-is-fatal=true
Mettez à jour la propriété de ressource de votre groupe de disponibilité existant failure-timeout
pour une exécution de 60s
(remplacez ag1
par le nom de votre ressource de groupe de disponibilité) :
sudo crm configure meta failure-timeout=60s
Installer l’agent de ressource SQL Server pour l’intégration avec Pacemaker
Exécutez les commandes suivantes sur tous les nœuds.
sudo apt-get install mssql-server-ha
Créer une connexion SQL Server pour Pacemaker
Sur toutes les instances SQL Server, créez un compte de connexion Server pour Pacemaker.
Le code Transact-SQL ci-dessous a pour effet de créer un compte de connexion :
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Au moment de la création du groupe de disponibilité, l’utilisateur Pacemaker requiert des autorisations ALTER
, CONTROL
et VIEW DEFINITION
sur le groupe de disponibilité, une fois qu’il a été créé mais avant l’ajout de nœuds à celui-ci.
Sur toutes les instances SQL Server, enregistrez les informations d’identification pour le compte de connexion SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Créer une ressource de groupe de disponibilité
Pour créer la ressource de groupe de disponibilité, utilisez la commande sudo crm configure
pour définir les propriétés de la ressource. L’exemple suivant permet de créer une ressource de type principal/réplica ocf:mssql:ag
pour le groupe de disponibilité nommé ag1
.
~$ sudo crm
configure
primitive ag1_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 ag1_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
commit
Notes
Quand vous créez la ressource et régulièrement par la suite, l’agent de ressource Pacemaker définit automatiquement la valeur de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
sur le groupe de disponibilité selon la configuration de celui-ci. Par exemple, si le groupe de disponibilité a trois réplicas synchrones, l’agent affecte à REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
la valeur 1
. Pour obtenir plus d’informations et d’options de configuration, consultez Haute disponibilité et protection des données pour les configurations des groupes de disponibilité.
Créer une ressource d’adresse IP virtuelle
Pour créer la ressource d’adresse IP virtuelle, exécutez la commande suivante sur un nœud. Utilisez une adresse IP statique disponible à partir du réseau. Avant d’exécuter le script, remplacez les valeurs entre < ... >
par une adresse IP virtuelle.
sudo crm configure primitive virtualip \
ocf:heartbeat:IPaddr2 \
params ip=10.128.16.240
Il n’y a aucun nom de serveur virtuel équivalent dans Pacemaker. Pour utiliser une chaîne de connexion qui pointe vers un nom de serveur de chaîne et ne pas utiliser l’adresse IP, enregistrez l’adresse de ressource IP et le nom de serveur virtuel souhaité dans DNS. Pour les configurations de récupération d’urgence, enregistrez le nom de serveur virtuel et l’adresse IP souhaités auprès des serveurs DNS sur le site principal et le site de récupération d’urgence.
Ajouter une contrainte de colocalisation
Presque toutes les décisions d’un cluster Pacemaker, comme le choix de l’emplacement dans lequel une ressource doit s’exécuter, s’effectuent en comparant les scores. Les scores sont calculés par ressource et le gestionnaire de ressources de cluster choisit le nœud avec le score le plus élevé pour une ressource particulière. (Si un nœud a un score négatif pour une ressource, la ressource ne peut pas être exécutée sur ce nœud.)
Utilisez des contraintes pour configurer les décisions du cluster. Les contraintes ont un score. Si une contrainte a un score inférieur à INFINITY, il ne s’agit que d’une suggestion. Un score INFINITY signifie qu’il s’agit d’une obligation.
Pour vous assurer que le réplica principal et la ressource d’adresse IP virtuelle sont exécutés sur le même hôte, définissez une contrainte de colocalisation avec un score INFINITY. Pour ajouter une contrainte de colocalisation, exécutez la commande suivante sur un nœud.
sudo crm configure colocation ag-with-listener INFINITY: virtualip-group ms-ag1:Master
Ajouter une contrainte de classement
La contrainte de colocalisation a une contrainte de classement implicite. Elle déplace la ressource IP virtuelle avant de déplacer la ressource de groupe de disponibilité. La séquence des événements par défaut est la suivante :
L’utilisateur émet pcs resource move
sur le groupe de disponibilité principal, de node1
à node2
.
La ressource d’adresse IP virtuelle s’arrête sur le node1
.
La ressource d’adresse IP virtuelle démarre sur le node2
.
À ce stade, l’adresse IP pointe temporairement vers le node2
, tandis que le node2
est toujours un secondaire de pré-basculement.
Le groupe de disponibilité principal sur node1
est rétrogradé en secondaire.
Le groupe de disponibilité secondaire sur node2
est promu en principal.
Pour empêcher l’adresse IP de pointer temporairement vers le nœud avec le secondaire antérieur au basculement, ajoutez une contrainte de classement.
Pour ajouter une contrainte de classement, exécutez la commande suivante sur un nœud :
sudo crm configure order ag-before-listener Mandatory: ms-ag1:promote virtualip-group:start
Après avoir configuré le cluster et ajouté le groupe de disponibilité en tant que ressource de cluster, vous ne pouvez pas utiliser Transact-SQL pour basculer les ressources du groupe de disponibilité. Les ressources de cluster SQL Server sur Linux ne sont pas couplées aussi étroitement au système d’exploitation, car elles se trouvent sur un cluster de basculement Windows Server (WSFC). Le service SQL Server n’est pas informé de la présence du cluster. Toutes les orchestrations sont effectuées via les outils d’administration de cluster.
Contenu connexe