Partage via

Configurer le groupe de disponibilité Always On SQL Server sur Linux

  • Article

S’applique à : SQL Server - Linux

Cet article décrit comment créer un groupe de disponibilité (AG) Always On SQL Server pour la haute disponibilité sur Linux. Il existe deux types de configuration pour les groupes de disponibilité. Une configuration de haute disponibilité utilise un gestionnaire de clusters pour fournir la continuité des activités. Cette configuration peut également inclure des réplicas en échelle lecture. Ce document explique comment créer le groupe de disponibilité pour la haute disponibilité.

Vous pouvez également créer un groupe de disponibilité sans gestionnaire de clusters pour une échelle lecture. Le groupe de disponibilité pour l’échelle lecture fournit uniquement des réplicas en lecture seule pour le scale-out des performances. Il ne fournit pas de haute disponibilité. Pour créer un groupe de disponibilité en échelle lecture, consultez Configurer un groupe de disponibilité SQL Server pour l’échelle lecture sur Linux.

Les configurations qui garantissent une haute disponibilité et la protection des données requièrent deux ou trois réplicas de validation synchrone. Avec trois réplicas synchrones, le groupe de disponibilité peut effectuer une récupération automatique même si un serveur n’est pas disponible. Pour plus d’informations, consultez Haute disponibilité et protection des données pour les configurations des groupes de disponibilité.

Tous les serveurs doivent être physiques ou virtuels et les serveurs virtuels doivent se trouver sur la même plateforme de virtualisation. Cette exigence est due au fait que les agents d’isolation sont spécifiques à la plateforme. Consultez Stratégies pour les clusters invités.

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 :

  1. Conseils d’installation pour SQL Server sur Linux.

    Important

    Les trois serveurs du groupe de disponibilité doivent se trouver sur la même plateforme, physique ou virtuelle, car la haute disponibilité Linux utilise des agents d’isolation pour isoler les ressources sur les serveurs. Les agents d’isolation sont spécifiques à chaque plateforme.

  2. Créez le groupe de disponibilité. Cette étape est traitée dans cet article en cours.

  3. Configurez un gestionnaire de ressources de cluster, comme Pacemaker.

    La façon de configurer un gestionnaire de ressources de cluster dépend de la distribution Linux spécifique. Pour obtenir des instructions spécifiques à la distribution, consultez les liens suivants :

    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 Pacemaker 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.

    Pour SLES, consultez Extension de haute disponibilité SUSE Linux Enterprise.

  4. Ajoutez le groupe de disponibilité en tant que ressource dans le cluster.

    La façon d’ajouter le groupe de disponibilité en tant que ressource dans le cluster dépend de la distribution Linux. Pour obtenir des instructions spécifiques à la distribution, consultez les liens suivants :

Considérations dans le cas où il y a plusieurs interfaces réseau

Pour plus d’informations sur la configuration d’un groupe de disponibilité pour des serveurs avec plusieurs cartes réseau, consultez les sections pertinentes pour :

Prérequis

Avant de créer le groupe de disponibilité, vous devez :

  • Définir votre environnement de sorte que tous les serveurs qui hébergeront des réplicas de disponibilité puissent communiquer.
  • Installez SQL Server.

Sur Linux, vous devez créer un groupe de disponibilité avant de l’ajouter en tant que ressource de cluster à manager par le cluster. Ce document fournit un exemple qui crée le groupe de disponibilité.

  1. Mettre à jour le nom de l’ordinateur pour chaque hôte.

    Chaque nom d’instance SQL Server doit être :

    • 15 caractères ou moins.
    • être unique dans le réseau.

    Pour définir le nom de l’ordinateur, modifiez /etc/hostname. Le script suivant vous permet de modifier /etc/hostname avec vi :

    sudo vi /etc/hostname

  2. Configurer le fichier hôtes.

    Notes

    Si les noms d’hôte sont inscrits avec leur adresse IP dans le serveur DNS, il n’est pas nécessaire d’effectuer les étapes ci-dessous. Vérifiez que tous les nœuds destinés à faire partie de la configuration du groupe de disponibilité peuvent communiquer entre eux. (Un test Ping vers le nom d’hôte doit répondre avec l’adresse IP correspondante.) Vérifiez aussi que le fichier /etc/hosts ne contient pas d’enregistrement qui mappe l’adresse IP 127.0.0.1 de localhost au nom d’hôte du nœud.

    Le fichier hosts sur chaque serveur contient les adresses IP et les noms de tous les serveurs qui seront inclus dans le groupe de disponibilité.

    La commande suivante retourne l’adresse IP du serveur actif :

    sudo ip addr show

    Mettez à jour /etc/hosts. Le script suivant vous permet de modifier /etc/hosts avec vi :

    sudo vi /etc/hosts

    L’exemple suivant montre /etc/hosts sur node1 avec des ajouts pour node1, node2 et node3. Dans cet exemple, node1 fait référence au serveur qui héberge le réplica principal, et node2 et node3 aux serveurs qui hébergent les réplicas secondaires.

    127.0.0.1    localhost localhost4 localhost4.localdomain4
::1          localhost localhost6 localhost6.localdomain6
10.128.18.12 node1
10.128.16.77 node2
10.128.15.33 node3

Installer SQL Server

Installez SQL Server. Les liens suivants pointent vers les instructions d’installation de SQL Server pour différentes distributions :

Activer les groupes de disponibilité Always On

Activez les groupes de disponibilité Always On pour chaque nœud qui héberge une instance SQL Server, puis redémarrez mssql-server. Exécutez le script suivant :

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server

Activer une session d’événements AlwaysOn_health

Vous pouvez éventuellement activer les événements étendus (XE) pour mieux diagnostiquer les causes racines lorsque vous résolvez les problèmes d’un groupe de disponibilité. Exécutez la commande suivante sur chaque instance de SQL Server :

ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE = ON);
GO

Pour plus d’informations sur cette session XE, consultez Configurer les événements étendus pour des groupes de disponibilité.

Créer un certificat

Le service SQL Server sur Linux utilise des certificats pour authentifier les communications entre les points de terminaison de mise en miroir.

Le script Transact-SQL suivant crée une clé principale et un certificat. Il sauvegarde ensuite le certificat et sécurise le fichier avec une clé privée. Mettez à jour le script avec des mots de passe forts. Se connecter à l'instance principale. Pour créer le certificat, exécutez le script suivant Transact-SQL suivant :

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Master_Key_Password>';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
    TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
        FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
        ENCRYPTION BY PASSWORD = '<Private_Key_Password>'
    );

À ce stade, votre réplica SQL Server principal a un certificat à l’emplacement /var/opt/mssql/data/dbm_certificate.cer et une clé privée à l’emplacement var/opt/mssql/data/dbm_certificate.pvk. Copiez ces deux fichiers au même emplacement sur tous les serveurs qui hébergeront les réplicas de disponibilité. Utilisez l’utilisateur mssql ou accordez à l’utilisateur mssql l’autorisation d’accéder à ces fichiers.

Par exemple, sur le serveur source, la commande suivante copie les fichiers sur la machine cible. Remplacez les valeurs <node2> par les noms des instances qui hébergeront les réplicas.

cd /var/opt/mssql/data
scp dbm_certificate.* root@<node2>:/var/opt/mssql/data/

Sur chaque serveur cible, accordez à l’utilisateur mssql l’autorisation d’accéder au certificat.

cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*

Créer le certificat sur les serveurs secondaires

Le script Transact-SQL suivant crée une clé principale et un certificat à partir de la sauvegarde que vous avez créée sur le réplica SQL Server principal. Mettez à jour le script avec des mots de passe forts. Le mot de passe de déchiffrement est le même mot de passe que celui que vous avez utilisé pour créer le fichier .pvk à une étape précédente. Popur créer le certificat, exécutez le script suivant sur tous les serveurs secondaires :

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Master_Key_Password>';
CREATE CERTIFICATE dbm_certificate
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
        FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
        DECRYPTION BY PASSWORD = '<Private_Key_Password>'
    );

Créer les points de terminaison de mise en miroir de bases de données sur tous les réplicas

Les points de terminaison de mise en miroir de bases de données utilisent le protocole TCP (Transmission Control Protocol) pour l’envoi et la réception de messages entre les instances de serveur participant à des sessions de mise en miroir de bases de donnée ou hébergeant des réplicas de disponibilité. Le point de terminaison de mise en miroir de bases de données écoute sur un numéro de port TCP unique.

Le script Transact-SQL suivant crée un point de terminaison d’écoute nommé Hadr_endpoint pour le groupe de disponibilité. Il démarre le point de terminaison et donne l’autorisation de connexion au certificat que vous avez créé. Avant d’exécuter le script, remplacez les valeurs entre < ... >. Si vous le souhaitez, vous pouvez inclure une adresse IP LISTENER_IP = (0.0.0.0). L’adresse IP de l’écouteur doit être une adresse IPv4. Vous pouvez également utiliser 0.0.0.0.

Mettez à jour le script Transact-SQL suivant pour votre environnement sur toutes les instances de SQL Server :

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
    );

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

Notes

Si vous utilisez l’édition SQL Server Express sur un nœud pour héberger un réplica de configuration uniquement, la seule valeur valide pour ROLE est WITNESS. Exécutez le script suivant sur l’édition SQL Server Express :

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (
        ROLE = WITNESS,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
    );

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

Le port TCP sur le pare-feu doit être ouvert pour le port de l’écouteur.

Important

Pour SQL Server 2017 (14.x), la seule méthode d’authentification prise en charge pour le point de terminaison de mise en miroir de bases de données est CERTIFICATE. L’option WINDOWS n’est pas disponible.

Pour plus d’informations, consultez Point de terminaison de mise en miroir de bases de données (SQL Server).

Créer le groupe de disponibilité

Les exemples de cette section expliquent comment créer le groupe de disponibilité à l’aide de Transact-SQL. Vous pouvez également utiliser l’Assistant Groupe de disponibilité SQL Server Management Studio. Lorsque vous créez un groupe de disponibilité à l’aide de l’Assistant, une erreur est renvoyée lorsque vous joignez les réplicas au groupe de disponibilité. Pour résoudre ce problème, accordez ALTER, CONTROL et VIEW DEFINITIONS à Pacemaker sur le groupe de disponibilité à tous les réplicas. Une fois les autorisations octroyées sur le réplica principal, joignez les nœuds au groupe de disponibilité à l’aide de l’Assistant, mais pour que la haute disponibilité fonctionne correctement, octroyez l’autorisation à tous les réplicas.

Pour une configuration de haute disponibilité qui garantit le basculement automatique, le groupe de disponibilité requiert au moins trois réplicas. L’une des configurations suivantes peut prendre en charge la haute disponibilité :

Pour plus d’informations, consultez Haute disponibilité et protection des données pour les configurations des groupes de disponibilité.

Notes

Les groupes de disponibilité peuvent inclure des réplicas synchrones ou asynchrones supplémentaires.

Créez le groupe de disponibilité pour la haute disponibilité sur Linux. Utilisez CREATE AVAILABILITY GROUP avec CLUSTER_TYPE = EXTERNAL.

  • Groupe de disponibilité : CLUSTER_TYPE = EXTERNAL.

    Spécifie qu’une entité de cluster externe gère le groupe de disponibilité. Pacemaker est un exemple d’entité de cluster externe. Lorsque le type de cluster du groupe de disponibilité est externe,

  • Définissez les réplicas principaux et secondaires : FAILOVER_MODE = EXTERNAL.

    Spécifie que le réplica interagit avec un gestionnaire de clusters externe, comme Pacemaker.

Les scripts Transact-SQL suivants créent un groupe de disponibilité pour la haute disponibilité nommé ag1. Le script configure les réplicas de groupe de disponibilité avec SEEDING_MODE = AUTOMATIC. Ce paramètre permet à SQL Server de créer automatiquement la base de données sur chaque serveur secondaire. Mettez à jour le script suivant en fonction de votre environnement. Remplacez les valeurs <node1>, <node2> et <node3> par les noms des instances SQL Server qui hébergent les réplicas. Remplacez la valeur <5022> par le port défini pour le point de terminaison de mise en miroir des données. Pour créer le groupe de disponibilité, exécutez Transact-SQL suivant sur l’instance hébergeant le réplica principal.

Important

Dans l’implémentation actuelle de l’agent de ressource SQL Server, le nom du nœud doit correspondre à la propriété ServerName de votre instance. Par exemple, si le nom de votre nœud est node1, vérifiez que SERVERPROPERTY (« ServerName ») renvoie node1 dans votre instance SQL Server. En cas de non-concordance, vos réplicas passent à un état de résolution après la création de la ressource Pacemaker.

Cette règle est particulièrement importante lorsque vous utilisez des noms de domaine complets. Par exemple, si vous utilisez node1.yourdomain.com comme nom de nœud lors de l’installation du cluster, vérifiez que SERVERPROPERTY (« ServerName ») retourne node1.yourdomain.com, et pas seulement node1. Vous pouvez éviter ce problème de l’une des manières suivantes :

  • Renommez votre nom d’hôte en nom de domaine complet et utilisez les procédures de stockage sp_dropserver et sp_addserver pour vous assurer que les métadonnées de SQL Server correspondent à la modification.
  • Utilisez l’option addr dans la commande pcs cluster auth pour faire correspondre le nom du nœud à la valeur SERVERPROPERTY (« ServerName ») et utilisez une adresse IP statique comme adresse de nœud.

Exécutez seulement un des scripts suivants :

Créer un groupe de disponibilité avec trois réplicas synchrones

Créer AG avec trois réplicas synchrones :

CREATE AVAILABILITY GROUP [ag1]
      WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
      FOR REPLICA ON
         N'<node1>'
               WITH (
            ENDPOINT_URL = N'tcp://<node1>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
         N'<node2>'
         WITH (
            ENDPOINT_URL = N'tcp://<node2>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
         N'<node3>'
         WITH(
            ENDPOINT_URL = N'tcp://<node3>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Important

Après avoir exécuté le script précédent pour créer un groupe de disponibilité avec trois réplicas synchrones, n’exécutez pas le script suivant :

Créer un groupe de disponibilité avec deux réplicas synchrones et un réplica de configuration

Créer un groupe de disponibilité avec deux réplicas synchrones et un réplica de configuration :

Important

Cette architecture permet à n’importe quelle édition de SQL Server d’héberger le troisième réplica. Par exemple, le troisième réplica peut être hébergé sur SQL Server Express Edition. Sur Express Edition, le seul type de point de terminaison valide est WITNESS.

CREATE AVAILABILITY GROUP [ag1]
   WITH (CLUSTER_TYPE = EXTERNAL)
   FOR REPLICA ON
      N'<node1>' WITH (
         ENDPOINT_URL = N'tcp://<node1>:<5022>',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = EXTERNAL,
         SEEDING_MODE = AUTOMATIC
         ),
      N'<node2>' WITH (
         ENDPOINT_URL = N'tcp://<node2>:<5022>',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = EXTERNAL,
         SEEDING_MODE = AUTOMATIC
         ),
      N'<node3>' WITH (
         ENDPOINT_URL = N'tcp://<node3>:<5022>',
         AVAILABILITY_MODE = CONFIGURATION_ONLY
         );
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Créer un groupe de disponibilité avec deux réplicas synchrones

Créer un groupe de disponibilité avec deux réplicas synchrones

Incluez deux réplicas avec le mode de disponibilité synchrone. Par exemple, le script suivant crée un groupe de disponibilité appelé ag1. node1 et node2 hébergent des réplicas en mode synchrone, avec l’amorçage automatique et le basculement automatique.

Important

Exécutez uniquement le script suivant pour créer un groupe de disponibilité avec deux réplicas synchrones. N’exécutez pas le script suivant si vous avez exécuté le script précédent.

CREATE AVAILABILITY GROUP [ag1]
   WITH (CLUSTER_TYPE = EXTERNAL)
   FOR REPLICA ON
   N'node1' WITH (
      ENDPOINT_URL = N'tcp://node1:5022',
      AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
      FAILOVER_MODE = EXTERNAL,
      SEEDING_MODE = AUTOMATIC
   ),
   N'node2' WITH (
      ENDPOINT_URL = N'tcp://node2:5022',
      AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
      FAILOVER_MODE = EXTERNAL,
      SEEDING_MODE = AUTOMATIC
   );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Vous pouvez également configurer un groupe de disponibilité avec CLUSTER_TYPE=EXTERNAL à l’aide de SQL Server Management Studio ou de PowerShell.

Joindre les réplicas secondaires au groupe de disponibilité

L’utilisateur Pacemaker a besoin des autorisations ALTER, CONTROL et VIEW DEFINITION sur le groupe de disponibilité pour tous les réplicas. Pour octroyer des autorisations, exécutez le script Transact-SQL suivant une fois le groupe de disponibilité créé sur le réplica principal et chaque réplica secondaire immédiatement après qu’ils aient été ajoutés au groupe de disponibilité. Avant d’exécuter le script, remplacez <pacemakerLogin> par le nom du compte d’utilisateur Pacemaker. Si vous n’avez pas de compte de connexion pour Pacemaker, Créez un compte de connexion SQL Server pour Pacemaker.

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO <pacemakerLogin>
GRANT VIEW SERVER STATE TO <pacemakerLogin>

Le script Transact-SQL suivant joint une instance à un groupe de disponibilité nommé ag1. Mettez à jour le script en fonction de votre environnement. Sur chaque instance qui héberge un réplica secondaire, exécutez le script Transact-SQL suivant pour joindre le groupe de disponibilité.

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Ajouter une base de données au groupe de disponibilité

Vérifiez que la base de données ajoutée au groupe de disponibilité est dans le mode de récupération complète et qu’elle dispose d’un journal de sauvegarde valide. Si votre base de données est une base de données de test ou une base de données nouvellement créée, faites une sauvegarde de la base de données. Sur le serveur SQL Server principal, exécutez le script Transact-SQL (T-SQL) suivant pour créer et sauvegarder une base de données appelée db1 :

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
SET RECOVERY FULL;
GO

BACKUP DATABASE [db1]
TO DISK = N'/var/opt/mssql/data/db1.bak';

Sur le réplica SQL Server principal, exécutez le script T-SQL suivant pour ajouter une base de données appelée db1 à un groupe de disponibilité appelé ag1 :

ALTER AVAILABILITY GROUP [ag1]
ADD DATABASE [db1];

Vérifier que la base de données est créée sur les serveurs secondaires

Sur chaque réplica SQL Server secondaire, exécutez la requête suivante pour déterminer si la base de données db1 a été créée et si elle est synchronisée :

SELECT * FROM sys.databases
WHERE name = 'db1';
GO

SELECT DB_NAME(database_id) AS 'database',
    synchronization_state_desc
FROM sys.dm_hadr_database_replica_states;
GO

Important

Après avoir créé le groupe de disponibilité, vous devez configurer l’intégration avec une technologie de cluster comme Pacemaker pour la haute disponibilité. Pour une configuration à l’échelle lecture à l’aide de groupes de disponibilité, à partir de SQL Server 2017 (14.x), la configuration d’un cluster n’est pas nécessaire.

Si vous avez suivi les étapes de ce document, vous disposez d’un groupe de disponibilité qui n’est pas encore en cluster. L’étape suivante consiste à ajouter le cluster. Cette configuration est valide pour les scénarios d’échelle lecture/équilibrage de charge, mais elle n’est pas complète pour la haute disponibilité. Pour une haute disponibilité, vous devez ajouter le groupe de disponibilité en tant que ressource de cluster. Consultez le contenu associé pour obtenir des instructions.

Notes

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. Dans SLES utilisez crm.

Important

Si le groupe de disponibilité est une ressource de cluster, il existe un problème connu dans la mise en production actuelle, où le basculement forcé avec perte de données vers un réplica asynchrone ne fonctionne pas. Ce problème sera résolu dans la prochaine mise en production. Le basculement manuel ou automatique vers un réplica synchrone a réussi.

Contenu connexe