Configurer un cluster de disque partagé SLES pour SQL Server
S’applique à : 
SQL Server - Linux
Ce guide fournit des instructions pour créer un cluster à deux nœuds pour SQL Server sur SUSE Linux Enterprise Server (SLES). 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 12 SP2.
Prérequis
Pour effectuer le scénario de bout en bout suivant, vous avez besoin de deux machines pour déployer le cluster à deux nœuds et d’un autre serveur pour configurer le partage NFS. Les étapes ci-dessous décrivent comment ces serveurs seront configurés.
Installer et configurer le système d’exploitation sur chaque nœud du cluster
La première étape consiste à configurer le système d'exploitation sur les nœuds de cluster. Pour ce guide, utilisez SLES avec un abonnement valide pour le module complémentaire de haute disponibilité.
Installer et configurer SQL Server sur chaque nœud du cluster
Installez et configurez SQL Server sur les deux nœuds. Pour obtenir des instructions détaillées, consultez Installer SQL Server sur Linux.
Désignez un nœud comme principal et l’autre comme secondaire, à des fins de configuration. Utilisez ces termes pour le présent guide.
Sur le nœud secondaire, arrêtez et désactivez SQL Server. L’exemple suivant arrête et désactive SQL Server :
sudo systemctl stop mssql-server sudo systemctl disable mssql-serverNotes
Au moment de la configuration, une clé principale de serveur est générée pour l’instance et placée à l’adresse
/var/opt/mssql/secrets/machine-key. Sur Linux, SQL Server s’exécute toujours en tant que compte local appelé mssql. Étant donné qu’il s’agit d’un compte local, son identité n’est pas partagée entre les nœuds. Par conséquent, vous devez copier la clé de chiffrement du nœud principal sur chaque nœud secondaire afin que chaque compte mssql local puisse y accéder pour déchiffrer la clé principale du serveur.Sur le nœud principal, créez un compte de connexion SQL Server pour Pacemaker et octroyez l’autorisation de connexion pour exécuter
sp_server_diagnostics. Pacemaker utilise ce compte pour vérifier le nœud en cours d’exécution SQL Server.sudo systemctl start mssql-serverConnectez-vous à la base de données
masterSQL Server avec le compte « sa » et exécutez la commande suivante :USE [master] GO CREATE LOGIN [<loginName>] with PASSWORD= N'<loginPassword>' GRANT VIEW SERVER STATE TO <loginName>Sur le nœud principal, arrêtez et désactivez SQL Server.
Suivez les instructions de la documentation SUSE pour configurer et mettre à jour le fichier hôtes pour chaque nœud de cluster. Le fichier « hôtes » doit inclure l’adresse IP et le nom de chaque nœud de cluster.
Pour vérifier l’adresse IP du nœud actuel, exécutez :
sudo ip addr showDéfinissez le nom de l’ordinateur sur chaque nœud. Donnez à chaque nœud un nom unique de 15 caractères ou moins. Définissez le nom de l’ordinateur en l'ajoutant à
/etc/hostnameà l’aide de YAST ou manuellement.L’exemple suivant présente
/etc/hostsavec des ajouts pour deux nœuds nommésSLES1etSLES2.127.0.0.1 localhost 10.128.18.128 SLES1 10.128.16.77 SLES2Tous 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 le dépannage) 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 :
crm_report -X "-p 3479" [...]Pour plus d’informations, consultez le Guide d’administration.
Dans la section suivante, vous allez configurer le stockage partagé et déplacer vos fichiers de base de données vers ce stockage.
Configurer le stockage partagé et déplacer des fichiers de base de données
Il existe diverses solutions pour fournir un stockage partagé. Cette procédure pas à pas illustre la configuration du stockage partagé avec NFS. Nous vous recommandons de suivre les meilleures pratiques et d’utiliser Kerberos pour sécuriser NFS :
Si vous ne suivez pas ce guide, toute personne pouvant accéder à votre réseau et usurper l’adresse IP d’un nœud SQL pourra accéder à vos fichiers de données. Comme toujours, assurez-vous de modéliser les risques de votre système avant de l'utiliser en production.
Une autre option de stockage consiste à utiliser le partage de fichiers SMB :
Configurer un serveur NFS
Pour configurer un serveur NFS, consultez les étapes suivantes dans la documentation SUSE : Configuration du serveur NFS.
Configurer tous les nœuds de cluster pour la connexion au stockage partagé NFS
Avant de configurer le client NFS pour monter le chemin d’accès aux fichiers de base de données SQL Server pour qu’il pointe vers l’emplacement de stockage partagé, veillez à enregistrer les fichiers de base de données dans un emplacement temporaire afin de pouvoir les copier ultérieurement sur le partage :
Sur le nœud principal uniquement, enregistrez les fichiers de base de données dans un emplacement temporaire. Le script suivant crée un nouveau répertoire temporaire, copie les fichiers de base de données dans le nouveau répertoire et supprime les anciens fichiers de base de données. Comme SQL Server s’exécute en tant qu’utilisateur local mssql, vous devez vous assurer qu’après le transfert des données vers le partage monté, l’utilisateur local dispose d’un accès en lecture-écriture au partage.
su mssql mkdir /var/opt/mssql/tmp cp /var/opt/mssql/data/* /var/opt/mssql/tmp rm /var/opt/mssql/data/* exitConfigurez le client NFS sur tous les nœuds de cluster :
Remarque
Nous vous recommandons de suivre les meilleures pratiques et les recommandations de SUSE concernant le stockage NFS à haute disponibilité : Stockage NFS hautement disponible avec DRBD et Pacemaker.
Vérifiez que SQL Server démarre correctement avec le nouveau chemin d’accès au fichier. Procédez de la sorte sur chaque nœud. À ce stade, un seul nœud doit exécuter SQL Server à la fois. Ils ne peuvent pas être exécutés en même temps, car ils essaient d’accéder simultanément aux fichiers de données (pour éviter de démarrer accidentellement SQL Server sur les deux nœuds, utilisez une ressource de cluster de système de fichiers pour vous assurer que le partage n’est pas monté deux fois par les différents nœuds). Les commandes suivantes démarrent SQL Server, vérifient l’état, puis, arrêtent SQL Server.
sudo systemctl start mssql-server sudo systemctl status mssql-server sudo systemctl stop mssql-server
À ce stade, les deux instances de SQL Server sont configurées pour s’exécuter avec les fichiers de base de données sur le stockage partagé. L’étape suivante consiste à configurer SQL Server pour Pacemaker.
Installer et configurer Pacemaker sur chaque nœud de cluster
Sur les deux nœuds du cluster, créez un fichier pour stocker le nom d’utilisateur et le mot de passe SQL Server du compte de connexion Pacemaker. La commande suivante a pour effet de créer et remplir ce fichier :
sudo touch /var/opt/mssql/secrets/passwd sudo echo '<loginName>' >> /var/opt/mssql/secrets/passwd sudo echo '<loginPassword>' >> /var/opt/mssql/secrets/passwd sudo chown root:root /var/opt/mssql/secrets/passwd sudo chmod 600 /var/opt/mssql/secrets/passwdTous 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 le dépannage) 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 le manuel). Par exemple, si votre port SSH est le 3479, appelez un hb_report avec :
crm_report -X "-p 3479" [...]Pour plus d’informations, consultez la configuration système requise et les recommandations dans la documentation de SUSE.
Installez l’extension High Availability. Pour installer cette extension, suivez les étapes décrites dans l’article SUSE suivante :
Installation and Setup Quick Start (Guide rapide d’installation et de configuration)
Installez l’agent de ressources FCI pour SQL Server. Exécutez les commandes suivantes sur les deux nœuds :
sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/12/mssql-server-2017.repo sudo zypper --gpg-auto-import-keys refresh sudo zypper install mssql-server-haConfigurez automatiquement le premier nœud. L’étape suivante consiste à configurer un cluster à un nœud en cours d’exécution en configurant le premier nœud, SLES1. Suivez les instructions de l’article SUSE, Configuration du premier nœud.
À la fin de la procédure, vérifiez l’état du cluster à l’aide de
crm status:crm statusLe résultat doit indiquer qu’un seul nœud est configuré : SLES1.
Ajoutez des nœuds à un cluster existant. Joignez ensuite le nœud SLES2 au cluster. Suivez les instructions de l’article SUSE, Ajout du deuxième nœud.
À la fin de la procédure, vérifiez l’état du cluster à l’aide de crm status. Si vous avez réussi à ajouter le deuxième nœud, voici ce que vous obtenez en sortie :
2 nodes configured 1 resource configured Online: [ SLES1 SLES2 ] Full list of resources: admin_addr (ocf::heartbeat:IPaddr2): Started SLES1Remarque
admin_addr est la ressource de cluster IP virtuelle qui est configurée pendant l’installation initiale du cluster à un nœud.
Procédures de suppression. Si vous devez supprimer un nœud du cluster, utilisez le script d’amorçage ha-cluster-remove. Pour plus d’informations, consultez Overview of the Bootstrap Scripts (Vue d’ensemble des scripts d’amorçage).
Configurer les ressources de cluster pour SQL Server
Les étapes suivantes expliquent comment configurer la ressource de cluster pour SQL Server. Vous devez personnaliser deux paramètres.
- Nom de la ressource SQL Server : nom de la ressource SQL Server clusterisée.
- Valeur du délai d’attente : la valeur du délai d’attente avant expiration correspond à la durée d’attente du cluster pendant la mise en ligne d’une ressource. Pour SQL Server, il s’agit de la durée prévue pour que SQL Server mette la base de données
masteren ligne.
Mettez à jour les valeurs du script suivant pour votre environnement. Exécutez sur un nœud pour configurer et démarrer le service en cluster.
sudo crm configure
primitive <sqlServerResourceName> ocf:mssql:fci op start timeout=<timeout_in_seconds>
colocation <constraintName> inf: <virtualIPResourceName> <sqlServerResourceName>
show
commit
exit
Par exemple, le script suivant crée une ressource SQL Server de cluster nommée mssqlha.
sudo crm configure
primitive mssqlha ocf:mssql:fci op start timeout=60s
colocation admin_addr_mssqlha inf: admin_addr mssqlha
show
commit
exit
Une fois la configuration validée, SQL Server démarre sur le même nœud que la ressource d’adresse IP virtuelle.
Pour plus d’informations, consultez Configuration et gestion des Ressources de cluster (ligne de commande).
Vérifiez que SQL Server a démarré
Pour vérifier que SQL Server a démarré, exécutez la commande état crm :
crm status
L’exemple suivant affiche les résultats quand Pacemaker a démarré avec succès en tant que ressource de cluster.
2 nodes configured
2 resources configured
Online: [ SLES1 SLES2 ]
Full list of resources:
admin_addr (ocf::heartbeat:IPaddr2): Started SLES1
mssqlha (ocf::mssql:fci): Started SLES1
Gérer des ressources de cluster
Pour gérer vos ressources de cluster, consultez l’article SUSE suivante : Gestion des ressources de cluster
Basculement manuel
Bien que les ressources soient configurées pour basculer (ou migrer) automatiquement vers d’autres nœuds du cluster, en cas de défaillance matérielle ou logicielle, vous pouvez également déplacer manuellement une ressource vers un autre nœud dans le cluster à l’aide de l’interface graphique utilisateur Pacemaker ou de la ligne de commande.
Utilisez la commande Migrer pour cette tâche. Par exemple, pour migrer la ressource SQL vers des noms d’un nœud de cluster, SLES2 exécute :
crm resource
migrate mssqlha SLES2
Contenu connexe
Commentaires
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir: https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour