Partager via

Configurer un cluster de disque partagé SLES pour SQL Server

S’applique à :SQL Server sur Linux

Ce guide fournit des instructions pour créer un cluster de disques partagés à 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.

Notes

À compter de SQL Server 2025 (17.x), SUSE Linux Enterprise Server (SLES) n’est pas pris en charge.

Pour plus d'informations sur la configuration du cluster, les options de l'agent de ressources, la gestion, les meilleures pratiques et les recommandations, consultez SUSE Linux Enterprise High Availability Extension 12 SP5.

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 suivantes décrivent la configuration de ces serveurs.

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 l'add-on HA.

Installer et configurer SQL Server sur chaque nœud du cluster

  1. Installez et configurez des SQL Server sur les deux nœuds. Pour obtenir des instructions détaillées, consultez Guide à l’installation de SQL Server sur Linux.

  2. Désignez un nœud comme principal et l’autre comme secondaire, à des fins de configuration. Utilisez ces termes pour le présent guide.

  3. 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-server

    Notes

    Au moment de l’installation, une clé principale de serveur (SMK) est générée pour l’instance SQL Server et placée à /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. Vous devez copier la clé de chiffrement du nœud principal vers chaque nœud secondaire afin que chaque compte local mssql puisse y accéder pour déchiffrer le SMK.

  4. 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-server

    Connectez-vous à la base de données SQL Server master avec le sa compte et exécutez le script suivant :

    USE [master];
GO

CREATE LOGIN [<loginName>] with PASSWORD = N'<password>';
GRANT VIEW SERVER STATE TO <loginName>;

    Attention

    Votre mot de passe doit suivre la politique de mot de passe par défaut de SQL Server. Par défaut, le mot de passe doit avoir au moins huit caractères appartenant à trois des quatre groupes suivants : lettres majuscules, lettres minuscules, chiffres de base 10 et symboles. Les mots de passe peuvent comporter jusqu'à 128 caractères. Utilisez des mots de passe aussi longs et complexes que possible.

  5. Sur le nœud principal, arrêtez et désactivez SQL Server.

  6. Suivez les instructions de la documentation SUSE pour configurer et mettre à jour le fichier hôtes pour chaque nœud de cluster. Le fichier hosts doit inclure l’adresse IP et le nom de chaque nœud du cluster.

    Pour vérifier l’adresse IP du nœud actuel, exécutez :

    sudo ip addr show

    Dé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/hosts avec des ajouts pour deux nœuds nommés SLES1 et SLES2.

    127.0.0.1      localhost
10.128.18.128  SLES1
10.128.16.77   SLES2

    Tous les nœuds de cluster doivent disposer d’un accès SSH sans mot de passe les uns aux autres. Dans le cas contraire, les outils tels que hb_report, crm_reportet l’Explorateur d’historique de Hawk ne peuvent collecter des données qu’à partir du nœud local. Si vous utilisez un port SSH non standard, utilisez l’option -X (voir Autres exigences et recommandations). Par exemple, si votre port SSH est 3479, appelez 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

Vous pouvez utiliser différentes solutions pour fournir un stockage partagé. Cette procédure pas à pas illustre la configuration du stockage partagé avec NFS. Suivez les bonnes pratiques et utilisez Kerberos pour sécuriser NFS :

Si vous ne suivez pas ces instructions, toute personne qui peut accéder à votre réseau et usurper l’adresse IP d’un nœud SQL peut accéder à vos fichiers de données. Comme toujours, effectuez une modélisation des menaces sur 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 des fichiers de base de données SQL Server pour pointer 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 dans le partage :

  1. Sur le nœud principal uniquement, enregistrez les fichiers de base de données dans un emplacement temporaire. Le script suivant crée un 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/*
exit

    Configurez le client NFS sur tous les nœuds de cluster :

    Notes

    Pour obtenir les meilleures pratiques et recommandations SUSE concernant le stockage NFS hautement disponible, consultez Stockage NFS hautement disponible avec DRBD et Pacemaker.

  2. Sur chaque nœud, vérifiez que SQL Server démarre correctement avec le nouveau chemin d’accès au fichier. À ce stade, un seul nœud doit exécuter SQL Server à la fois. Ils ne peuvent pas tous les deux s’exécuter en même temps, car ils essaient tous deux d’accéder simultanément aux fichiers de données.

    Pour empêcher SQL Server de démarrer sur les deux nœuds, utilisez une ressource de cluster de système de fichiers pour vous assurer que le partage est monté par un seul nœud à la fois.

    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

  1. 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 '<password>' >> /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 600 /var/opt/mssql/secrets/passwd

    Attention

    Votre mot de passe doit suivre la politique de mot de passe par défaut de SQL Server. Par défaut, le mot de passe doit avoir au moins huit caractères appartenant à trois des quatre groupes suivants : lettres majuscules, lettres minuscules, chiffres de base 10 et symboles. Les mots de passe peuvent comporter jusqu'à 128 caractères. Utilisez des mots de passe aussi longs et complexes que possible.

  2. Tous les nœuds de cluster doivent accéder les uns aux autres via SSH. Les outils tels hb_report ou crm_report (pour la résolution des problèmes) et l’Explorateur d’historique de Hawk nécessitent un accès SSH sans mot de passe entre les nœuds. Sinon, ils peuvent uniquement collecter des données à partir du nœud actuel. Si vous utilisez un port SSH non standard, utilisez l’option -X (voir la page man). Par exemple, si votre port SSH est 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.

  3. 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)

  4. 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-ha

  5. Configurez 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 status

    Il indique qu’un nœud, SLES1, est configuré.

  6. Ajoutez des nœuds à un cluster existant. Ensuite, joignez 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 ajoutez un deuxième nœud, la sortie ressemble à l’exemple suivant :

    2 nodes configured
1 resource configured
Online: [ SLES1 SLES2 ]
Full list of resources:
admin_addr     (ocf::heartbeat:IPaddr2):       Started SLES1

    Notes

    admin_addr est la ressource de cluster IP virtuelle que vous configurez lors de la configuration initiale d’un cluster à nœud.

  7. 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. Personnalisez les deux paramètres suivants :

  • 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, cette valeur représente le temps que vous attendez que SQL Server prenne pour mettre la master base de données en ligne.

Mettez à jour les valeurs dans le script suivant pour votre environnement. Exécutez le script 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 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 montre les résultats lorsque Pacemaker démarre correctement en tant que ressource en 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 de cluster en cas de défaillance matérielle ou logicielle, vous pouvez également les déplacer manuellement à l’aide de l’interface graphique graphique Pacemaker ou de la ligne de commande.

Utilisez la migrate commande pour cette tâche. Par exemple, pour migrer la ressource SQL vers un nœud de cluster nommé SLES2, exécutez :

crm resource
migrate mssqlha SLES2

Contenu connexe

  • Last updated on