Tutoriel : Configurer un groupe de disponibilité Always On à trois nœuds avec HPE Serviceguard pour Linux

S’applique à :SQL Server sur Linux

Ce tutoriel explique comment configurer des groupes de disponibilité SQL Server avec HPE Serviceguard pour Linux, exécuté sur des machines virtuelles locales ou des machines virtuelles Azure.

Pour obtenir une vue d’ensemble des clusters HPE Serviceguard, consultez Clusters HPE Serviceguard.

Ce didacticiel contient les tâches suivantes :

Prerequisites

• Dans Azure, créez trois machines virtuelles Linux. Pour créer des machines virtuelles Linux, consultez le guide Démarrage rapide : Créer une machine virtuelle Linux dans le portail Azure. Quand vous déployez les machines virtuelles, veillez à utiliser les distributions Linux prises en charge par HPE ServiceGuard. Vous pouvez également déployer les machines virtuelles localement dans un environnement local si vous le souhaitez.

  Pour obtenir un exemple de distribution prise en charge, consultez HPE Serviceguard pour Linux. Contactez HPE pour obtenir des informations sur la prise en charge des environnements de cloud public.

  Les instructions de ce tutoriel ont été validées pour HPE Serviceguard pour Linux. Une version d’essai peut être téléchargée à partir du site HPE.

• Les fichiers de base de données SQL Server sur le montage de volume logique (LVM) pour les trois machines virtuelles. Consultez le Guide de démarrage rapide de Serviceguard pour Linux (HPE)

• Vérifiez que le runtime Java OpenJDK est installé sur les machines virtuelles. Le SDK Java IBM n’est pas pris en charge.

Installer SQL Server

Sur les trois machines virtuelles, installez SQL Server et les outils nécessaires en effectuant l’une des étapes ci-dessous selon la distribution Linux choisie pour ce tutoriel.

Red Hat Enterprise Linux (RHEL)

• Installer SQL Server sur Red Hat
• Outils

SLES (SUSE Linux Enterprise Server)

• Installer SQL Server sur SLES
• Outils

Au terme de cette étape, le service SQL Server et les outils sont normalement installés sur les trois machines virtuelles qui seront membres du groupe de disponibilité.

Installer HPE Serviceguard sur les machines virtuelles

Durant cette étape, vous installez HPE Serviceguard pour Linux sur les trois machines virtuelles. Le tableau suivant décrit le rôle de chaque serveur dans le cluster.

Pour installer Serviceguard, utilisez la méthode cminstaller. Vous trouverez des instructions spécifiques via les liens ci-dessous :

• Installez Serviceguard pour Linux sur deux nœuds. Reportez-vous à la section Install_serviceguard_using_cminstaller.
• Installez le serveur de quorum Serviceguard sur le troisième nœud. Reportez-vous à la section Install_QS_from_the_ISO.

Après avoir installé le cluster HPE Serviceguard, vous pouvez activer le portail de gestion du cluster sur le port TCP 5522 sur le nœud du réplica principal. Les étapes suivantes ajoutent une règle au pare-feu pour autoriser 5522. La commande suivante concerne un Red Hat Enterprise Linux (RHEL). Vous devez exécuter des commandes similaires pour d’autres distributions :

sudo firewall-cmd --zone=public --add-port=5522/tcp --permanent
sudo firewall-cmd --reload

Créer le cluster HPE Serviceguard

Suivez ces instructions pour créer et configurer le cluster HPE Serviceguard. Durant cette étape, vous configurez également le serveur de quorum.

1. Configurez le serveur de quorum Serviceguard sur le troisième nœud. Reportez-vous à la section Configure_QS.
2. Créez et configurez le cluster Serviceguard sur les deux autres nœuds. Reportez-vous à la section Configure_and_create_Cluster.

Créer le groupe de disponibilité et y ajouter un exemple de base de données

Durant cette étape, vous créez un groupe de disponibilité avec deux (ou plus) réplicas synchrones et un réplica de configuration uniquement, ce qui assure la protection des données et peut contribuer à offrir une haute disponibilité. Le diagramme suivant illustre cette architecture :

1. Réplication synchrone des données utilisateur vers le réplica secondaire. Il comprend également des métadonnées de configuration des groupes de disponibilité.

2. Réplication synchrone des métadonnées de configuration des groupes de disponibilité. Il n’inclut pas les données utilisateur.

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

Pour créer le groupe de disponibilité, effectuez les étapes suivantes :

1. Activer les groupes de disponibilité et exécuter restart mssql-server sur toutes les machines virtuelles, y compris le réplica de configuration uniquement.
2. Activer une session d’événements AlwaysOn_health (facultatif)
3. Créer un certificat sur la machine virtuelle principale
4. Créer le certificat sur les serveurs secondaires
5. Créer les points de terminaison de mise en miroir de bases de données sur les réplicas
6. Créer un groupe de disponibilité
7. Joindre les réplicas secondaires
8. Ajouter une base de données au groupe de disponibilité

Activer les groupes de disponibilité et exécuter restart mssql-server

Activez les groupes de disponibilité sur tous les nœuds qui hébergent une instance SQL Server. Ensuite, redémarrez mssql-server. Exécutez le script suivant sur les trois réplicas :

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

Activer une session d’événements AlwaysOn_health (facultatif)

Activez facultativement les événements étendus des groupes de disponibilité Always On pour faciliter le diagnostic de la cause racine quand vous résolvez les problèmes rencontrés avec 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

Créer un certificat sur la machine virtuelle principale

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. Connectez-vous à l’instance principale de SQL Server et exécutez le script 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, le 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 le nom de l’hôte qui exécute l’instance SQL Server secondaire. Copiez aussi le certificat sur le réplica de configuration uniquement et exécutez également les commandes ci-dessous sur ce nœud.

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

À présent, sur les machines virtuelles secondaires qui exécutent l’instance secondaire et le réplica de configuration uniquement de SQL Server, exécutez les commandes suivantes pour que l’utilisateur mssql puisse détenir le certificat copié :

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 que celui que vous avez utilisé pour créer le fichier .pvk au cours d’une étape précédente. Pour créer le certificat, exécutez le script suivant sur tous les serveurs secondaires à l’exception du réplica de configuration uniquement :

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>'
);

Dans l’exemple précédent, remplacez <private-key-password> par le mot de passe que vous avez utilisé au moment de la création du certificat sur le réplica principal.

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

Sur le réplica principal et les réplicas secondaires, exécutez les commandes ci-dessous pour créer les points de terminaison de mise en miroir de bases de données :

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;

Sur le réplica de configuration uniquement, créez le point de terminaison de mise en miroir de bases de données à l’aide de la commande suivante. Notez que le rôle est défini ici sur la valeur WITNESS, comme cela est requis pour le réplica de configuration uniquement.

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;

Créer un groupe de disponibilité

Sur l’instance du réplica principal, exécutez les commandes suivantes. Ces commandes créent un groupe de disponibilité nommé ag1, qui a un cluster_type EXTERNAL et qui accorde l’autorisation de création de base de données au groupe de disponibilité.

Avant d’exécuter les scripts suivants, remplacez les espaces réservés <node1>, <node2> et <node3> (réplica de configuration uniquement) par le nom des trois machines virtuelles que vous avez créées aux étapes précédentes.

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;

Joindre les réplicas secondaires

Exécutez les commandes suivantes sur tous les réplicas secondaires. Ces commandes joignent les réplicas secondaires au groupe de disponibilité ag1 contenant le réplica principal et accordent l’autorisation de création de base de données au groupe de disponibilité ag1.

ALTER AVAILABILITY GROUP [ag1]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO
ALTER AVAILABILITY GROUP [ag1]
GRANT CREATE ANY DATABASE;
GO

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

Connectez-vous au réplica principal et exécutez les commandes T-SQL suivantes pour :

1. Créer un exemple de base de données nommé db1, qui sera ajouté au groupe de disponibilité.

   CREATE DATABASE [db1];
   GO
   

2. Définir le mode de récupération complet (full) pour la base de données. Toutes les bases de données dans un groupe de disponibilité doivent être configurées sur le mode de récupération complet.

   ALTER DATABASE [db1]
       SET RECOVERY FULL;
   GO
   

3. Sauvegardez la base de données. Une base de données doit avoir fait l’objet d’une sauvegarde complète au moins avant d’être ajoutée à un groupe de disponibilité.

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

4. Définissez le mode de récupération complet (full) pour la base de données.

   ALTER DATABASE [db1]
       SET RECOVERY FULL;
   GO
   

5. Sauvegarde de la base de données sur disque

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

6. Ajoutez la base de données db1 au groupe de disponibilité.

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

Quand vous avez terminé les étapes précédentes, vous voyez que le groupe de disponibilité ag1 a été créé et que les trois machines virtuelles ont été ajoutées en tant que réplicas (un réplica principal, un réplica secondaire et un réplica de configuration uniquement). ag1 contient une seule base de données.

Déployer la charge de travail du groupe de disponibilité SQL Server (gestionnaire de cluster HPE)

Dans HPE Serviceguard, déployez la charge de travail SQL Server sur le groupe de disponibilité par le biais de l’interface utilisateur du gestionnaire de cluster Serviceguard.

Déployez la charge de travail du groupe de disponibilité, et activez la haute disponibilité (HA) et la reprise après sinistre (DR) via le cluster Serviceguard à l’aide de l’interface graphique de Serviceguard Manager. Reportez-vous à la section Protection de Microsoft SQL Server sur Linux pour les groupes de disponibilité Always On.

Créer l’équilibrage de charge dans le portail Azure

Pour les déploiements dans le cloud Azure, HPE Serviceguard pour Linux nécessite un équilibreur de charge qui permette les connexions clientes avec le réplica principal, afin de remplacer les adresses IP traditionnelles.

1. Dans le portail Azure, ouvrez le groupe de ressources contenant les machines virtuelles ou nœuds de cluster Serviceguard.

2. Dans le groupe de ressources, sélectionnez Ajouter.

3. Faites une recherche sur « équilibreur de charge » puis, dans les résultats de la recherche, sélectionnez l’équilibreur de charge qui est publié par Microsoft.

4. Dans le volet Équilibreur de charge, sélectionnez Créer.

5. Configurez l’équilibreur de charge comme ceci :

   Setting	Valeur
   Name	Nom de l’équilibreur de charge. Par exemple : SQLAvailabilityGroupLB.
   Type	Interne
   SKU	De base ou Standard
   Réseau virtuel	Réseau virtuel utilisé pour les réplicas de machine virtuelle
   Sous-réseau	Sous-réseau dans lequel les instances SQL Server sont hébergées
   Affectation d’adresses IP	statique
   Adresse IP privée	Créer une adresse IP privée dans le sous-réseau
   Abonnement	Choisir l’abonnement concerné
   Groupe de ressources	Choisir le groupe de ressources concerné
   Emplacement	Sélectionner le même emplacement que les nœuds SQL

Configurer le pool principal

Le pool de back-ends est constitué des adresses des deux instances sur lesquelles le cluster Serviceguard est configuré.

1. Dans votre groupe de ressources, cliquez sur l’équilibreur de charge que vous avez créé.
2. Accédez à Paramètres > Pools de back-ends, puis sélectionnez Ajouter pour créer un pool d’adresses de back-ends.
3. Dans Ajouter un pool de back-ends, sous Nom, tapez un nom pour le pool de back-ends.
4. Sous Associé à, sélectionnez Machine virtuelle.
5. Sélectionnez chaque machine virtuelle dans l’environnement et associez l’adresse IP appropriée à chaque sélection.
6. Sélectionnez Ajouter.

Créer une sonde

La sonde définit la façon dont Azure vérifie lequel des nœuds du cluster Serviceguard est le réplica principal. Azure sonde le service avec l’adresse IP sur un port que vous définissez lors de la création de la sonde.

1. Dans le volet Paramètres de l’équilibreur de charge, sélectionnez Sondes d’intégrité.

2. Dans le volet Sondes d’intégrité, sélectionnez Ajouter.

3. Utilisez les valeurs suivantes pour configurer la sonde :

   Setting	Valeur
   Name	Nom de la sonde. Par exemple : SQLAGPrimaryReplicaProbe.
   Protocol	TCP
   Port	Vous pouvez utiliser n’importe quel port disponible. Par exemple, 59999.
   Intervalle	5
   Seuil de l'état non sain	2

4. Sélectionnez OK.

5. Connectez-vous à toutes vos machines virtuelles, puis ouvrez le port de la sonde à l’aide des commandes suivantes :

   sudo firewall-cmd --zone=public --add-port=59999/tcp --permanent
   sudo firewall-cmd --reload
   

Azure crée la sonde, puis il l’utilise pour tester le nœud Serviceguard sur lequel l’instance du réplica principal du groupe de disponibilité est en cours d’exécution. N’oubliez pas le port configuré (59999), qui est requis pour déployer le groupe de disponibilité dans le cluster Serviceguard.

Configurer les règles d’équilibrage de charge

Les règles d’équilibrage de la charge configurent la façon dont l’équilibreur de charge route le trafic vers le nœud Serviceguard, qui est le réplica principal dans le cluster. Pour cet équilibreur de charge, activez le retour direct du serveur, car un seul des nœuds du cluster Serviceguard à la fois peut être un réplica principal.

1. Dans le volet Paramètres de l’équilibreur de charge, sélectionnez Règles d’équilibrage de charge.

2. Dans le volet Règles d’équilibrage de charge, sélectionnez Ajouter.

3. Configurez la règle d’équilibrage de charge en utilisant les paramètres suivants :

   Setting	Valeur
   Name	Nom représentant la règle d’équilibrage de charge. Par exemple : SQLAGPrimaryReplicaListener.
   Protocol	TCP
   Port	1433
   Port principal	1433. Cette valeur est ignorée, car cette règle utilise une adresse IP flottante.
   Sonde	Utilisez le nom de la sonde que vous avez créée pour cet équilibrage de charge.
   Persistance de session	Aucun
   Délai d’inactivité (minutes)	4
   IP flottante	activé

4. Sélectionnez OK.

5. Azure configure la règle d’équilibrage de charge. À présent, l’équilibreur de charge est configuré pour router le trafic vers le nœud Serviceguard qui est l’instance du réplica principal dans le cluster.

Notez l’adresse IP du front-end de l’équilibreur de charge, « LbReadWriteIP », car vous en aurez besoin pour déployer le groupe de disponibilité dans le cluster Serviceguard.

À ce stade, le groupe de ressources a un équilibreur de charge qui se connecte à tous les nœuds Serviceguard. L’équilibreur de charge contient également une adresse IP permettant aux clients de se connecter à l’instance du réplica principal dans le cluster. Ainsi, n’importe quelle machine qui est un réplica principal pourra répondre aux demandes du groupe de disponibilité.

Effectuer un basculement automatique et joindre à nouveau le nœud au cluster

Pour effectuer le test de basculement automatique, vous pouvez arrêter le réplica principal (mettez-le hors tension), ce qui permet de répliquer l’indisponibilité soudaine du nœud principal. Le comportement attendu est le suivant :

1. Le gestionnaire de cluster promeut l’un des réplicas secondaires du groupe de disponibilité en réplica principal.

2. Le réplica principal à l’arrêt rejoint automatiquement le cluster après son redémarrage. Le gestionnaire de cluster le promeut en réplica secondaire.

Pour HPE Serviceguard, reportez-vous à la section Tester la configuration pour la disponibilité du basculement

Contenu associé

• Groupes de disponibilité pour SQL Server sur Linux