Mettre en place un groupe de disponibilité AlwaysOn sur deux nœuds.

Ce que l'on construit

Un groupe de disponibilité (Always On Availability Group) réplique une ou plusieurs bases d'un serveur principal vers un serveur secondaire. Avec deux nœuds en validation synchrone, une transaction n'est confirmée qu'une fois écrite dans le journal des deux serveurs : le basculement automatique se fait sans perte de données.

Les applications se connectent à un nom unique, le listener, qui pointe toujours vers le serveur principal. Les deux nœuds sont fédérés par un cluster de basculement Windows (WSFC), qui arbitre le rôle de chacun.

Prérequis à vérifier avant de commencer

• Deux serveurs Windows de même version, joints au même domaine Active Directory, avec une adresse IP fixe chacun, et une résolution DNS fonctionnelle entre eux.
• SQL Server installé à l'identique sur les deux : même version, même niveau de mise à jour, même édition, même collation, mêmes dossiers pour les données si possible.
• Édition : l'édition Enterprise offre les groupes de disponibilité complets. L'édition Standard (à partir de SQL Server 2016 SP1) propose les groupes Basic : deux réplicas, une seule base par groupe, pas de lecture sur le secondaire.
• Comptes de service de domaine pour le moteur SQL Server, ou comptes gérés de service, avec les mêmes droits sur les deux nœuds.
• Pare-feu : le port des points de terminaison (5022 par convention) et le port SQL Server (1433) ouverts entre les deux nœuds, ainsi que les ports du cluster Windows.
• Base à répliquer en modèle de récupération complet (FULL), avec au moins une sauvegarde complète.
• Un témoin de quorum : indispensable avec deux nœuds, voir plus bas.

Étape 1 : le cluster de basculement Windows

Sur les deux nœuds, installez la fonctionnalité de clustering, puis validez la configuration avant de créer le cluster.

# Sur SQL01 et SQL02
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

# Validation de la configuration (à lancer depuis un nœud)
Test-Cluster -Node SQL01, SQL02 -Include "Inventory", "Network", "System Configuration"

# Création du cluster, sans stockage partagé (propre aux groupes de disponibilité)
New-Cluster -Name CLUSQL -Node SQL01, SQL02 -StaticAddress 10.0.0.50 -NoStorage

L'avertissement de validation sur le stockage est normal : un groupe de disponibilité n'utilise pas de disque partagé, chaque nœud possède ses propres copies de la base.

Étape 2 : le témoin de quorum

Avec deux nœuds seulement, la perte de l'un d'eux laisse l'autre sans majorité : le cluster s'arrête pour éviter un « cerveau scindé ». Un troisième vote, le témoin, règle le problème. Trois options :

• Partage de fichiers sur un troisième serveur, indépendant des deux nœuds.
• Témoin cloud (Azure Storage), pratique quand aucun troisième serveur n'est disponible (Windows Server 2016 et suivants).
• Disque témoin, réservé aux clusters qui ont un stockage partagé : non utilisé ici.

# Témoin de partage de fichiers
Set-ClusterQuorum -FileShareWitness \\FS01\TemoinCLUSQL

# Ou témoin cloud
Set-ClusterQuorum -CloudWitness -AccountName "moncomptestockage" -AccessKey "<clé>"

Étape 3 : activer Always On dans SQL Server

La fonctionnalité s'active sur chaque instance, puis le service redémarre.

# Module SqlServer requis ; à lancer pour chaque nœud (le service redémarre)
Enable-SqlAlwaysOn -ServerInstance SQL01 -Force
Enable-SqlAlwaysOn -ServerInstance SQL02 -Force

Alternative graphique : Gestionnaire de configuration SQL Server, propriétés du service, onglet « Haute disponibilité Always On ». Vérification :

SELECT SERVERPROPERTY('IsHadrEnabled') AS always_on_active;   -- 1 = activé

Étape 4 : les points de terminaison

Les deux serveurs communiquent via un point de terminaison dédié (type « database mirroring »). À créer sur chaque nœud :

CREATE ENDPOINT [Hadr_endpoint]
    STATE = STARTED
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (ROLE = ALL,
                            AUTHENTICATION = WINDOWS NEGOTIATE,
                            ENCRYPTION = REQUIRED ALGORITHM AES);

-- Autoriser le compte de service de l'autre nœud (ou le même compte s'il est partagé)
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DOMAINE\svc_sql];

Étape 5 : préparer la base et créer le groupe

La base doit être en modèle de récupération complet et avoir fait l'objet d'une sauvegarde complète :

ALTER DATABASE [MaBase] SET RECOVERY FULL;
BACKUP DATABASE [MaBase] TO DISK = N'\\FS01\Sauvegardes\MaBase_init.bak' WITH COMPRESSION, CHECKSUM;

Puis, sur le futur nœud principal (SQL01), on crée le groupe avec ses deux réplicas. L'initialisation automatique (seeding) transfère la base sans restauration manuelle (SQL Server 2016 et suivants).

CREATE AVAILABILITY GROUP [AG_MaBase]
WITH (DB_FAILOVER = ON)                       -- bascule si une base devient inaccessible (2016+)
FOR DATABASE [MaBase]
REPLICA ON
  N'SQL01' WITH (ENDPOINT_URL      = N'TCP://SQL01.domaine.local:5022',
                 AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
                 FAILOVER_MODE     = AUTOMATIC,
                 SEEDING_MODE      = AUTOMATIC,
                 SECONDARY_ROLE (ALLOW_CONNECTIONS = NO)),
  N'SQL02' WITH (ENDPOINT_URL      = N'TCP://SQL02.domaine.local:5022',
                 AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
                 FAILOVER_MODE     = AUTOMATIC,
                 SEEDING_MODE      = AUTOMATIC,
                 SECONDARY_ROLE (ALLOW_CONNECTIONS = NO));

Ensuite, sur le nœud secondaire (SQL02) : rejoindre le groupe et autoriser la création de la base reçue.

ALTER AVAILABILITY GROUP [AG_MaBase] JOIN;
ALTER AVAILABILITY GROUP [AG_MaBase] GRANT CREATE ANY DATABASE;

• Sur l'édition Standard, ajoutez l'option BASIC dans la clause WITH du groupe.
• Pour une distance importante entre les deux sites, passez le réplica distant en ASYNCHRONOUS_COMMIT avec FAILOVER_MODE = MANUAL : on accepte alors une perte de données possible en échange d'un impact moindre sur la latence.

Étape 6 : le listener

Le listener donne un nom et une adresse stables aux applications. Il s'ajoute depuis le nœud principal :

ALTER AVAILABILITY GROUP [AG_MaBase]
ADD LISTENER N'LSN_MaBase' (WITH IP ((N'10.0.0.51', N'255.255.255.0')), PORT = 1433);

• Le compte de l'objet cluster doit avoir le droit de créer des objets ordinateur dans Active Directory, sinon la création échoue.
• Les applications doivent se connecter au nom du listener. Sur un cluster réparti sur plusieurs sous-réseaux, ajoutez MultiSubnetFailover=True à la chaîne de connexion pour accélérer la reconnexion.

Étape 7 : vérifier l'état du groupe

-- Santé des réplicas
SELECT ar.replica_server_name, rs.role_desc, rs.connected_state_desc, rs.synchronization_health_desc
FROM sys.dm_hadr_availability_replica_states AS rs
JOIN sys.availability_replicas AS ar ON ar.replica_id = rs.replica_id;

-- Synchronisation par base : files d'attente d'envoi et de rejeu
SELECT ar.replica_server_name, DB_NAME(drs.database_id) AS base,
       drs.synchronization_state_desc, drs.synchronization_health_desc,
       drs.log_send_queue_size AS file_envoi_ko, drs.redo_queue_size AS file_rejeu_ko
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON ar.replica_id = drs.replica_id;

On attend l'état SYNCHRONIZED et la santé HEALTHY sur les deux nœuds. Des files d'attente qui grossissent signalent un secondaire trop lent ou une liaison saturée.

Étape 8 : tester le basculement

Ne mettez jamais un groupe en production sans avoir testé le basculement, aller et retour. Depuis le secondaire :

-- Basculement planifié, sans perte de données (réplicas synchronisés)
ALTER AVAILABILITY GROUP [AG_MaBase] FAILOVER;

• Vérifiez ensuite que l'application se reconnecte via le listener, que les travaux planifiés s'exécutent et que les connexions sont présentes sur le nouveau principal.
• Testez aussi l'arrêt brutal du service ou de la machine principale, pour valider le basculement automatique.
• La commande FORCE_FAILOVER_ALLOW_DATA_LOSS est une procédure d'urgence en cas de perte du principal : elle peut faire perdre des données.

Ce qui n'est pas répliqué

Le groupe ne réplique que les bases choisies. Tout ce qui vit hors de ces bases doit être maintenu à l'identique sur les deux nœuds :

• Les connexions (logins) et leurs mots de passe. Créez-les avec le même identifiant de sécurité (SID), sinon les utilisateurs de la base deviennent orphelins après un basculement.
• Les travaux de l'Agent SQL Server : prévoyez dans chaque travail un test du rôle (par exemple sys.fn_hadr_is_primary_replica) pour qu'il ne s'exécute que sur le principal.
• Les serveurs liés, les certificats, les paramètres d'instance, les bases système (master, msdb), les alertes et les opérateurs.
• Les sauvegardes : choisissez le comportement dans le groupe (préférence de sauvegarde) et vérifiez que les travaux de sauvegarde en tiennent compte.

Les pièges qui reviennent

• Pas de témoin de quorum : l'arrêt d'un seul nœud arrête alors tout le cluster.
• Journal qui grossit : tant qu'un réplica n'a pas reçu un journal, celui-ci ne peut pas être purgé. Un secondaire injoignable pendant des heures peut remplir le disque du principal. Surveillez l'espace et l'état de synchronisation.
• Pare-feu et DNS : la plupart des échecs de jonction du secondaire viennent d'un port fermé ou d'un nom non résolu.
• Mises à jour : appliquez d'abord le correctif au secondaire, basculez, puis mettez à jour l'ancien principal. Ne mettez jamais à jour les deux en même temps.
• Applications mal connectées : une chaîne de connexion pointant sur le nom du serveur plutôt que sur le listener ne suit pas le basculement.
• Fausse sécurité : un groupe de disponibilité n'est pas une sauvegarde. Une suppression accidentelle ou une corruption logique est répliquée aussitôt. Conservez des sauvegardes testées.