Besoin de faire passer des clusters SQL Server Always On de abc.com à xyz.com avec un minimum de coupure ? Voici un guide opérationnel, concret et éprouvé pour réussir la migration sans stress ni surprises.
Sommaire
Comment migrer un cluster SQL Server multi‑nœud (Always On) d’un domaine A vers un domaine B ?
Vue d’ensemble de la question
Vous exploitez un ou plusieurs Windows Server Failover Clustering (WSFC) hébergeant des groupes de disponibilité SQL Server Always On. Chaque nœud se trouve dans le domaine abc.com et doit basculer vers xyz.com avec une administration minimale et un temps d’arrêt extrêmement réduit.
Deux stratégies s’offrent à vous :
- Migration in‑place (Windows Server 2019/2022/2025) : changer le domaine du cluster sans le recréer.
- Nouveau cluster dans le domaine cible + Distributed Availability Group (dAG) : approche « zéro ou quasi‑zéro coupure ».
Réponse & solution
Migration in‑place (Windows Server 2019/2022/2025)
Depuis Windows Server 2019, un WSFC peut changer de domaine sans recréation. L’approche ci‑dessous réduit la coupure à l’essentiel : deux redémarrages par nœud et la remise en ligne des ressources.
| Étape | Action | Remarques clés |
|---|---|---|
| Préparation | Sauvegardes complètes (système & SQL), inventaire des ressources, suspension des bascules AG. | Documentez les versions/patches, les points de montage, les SPN, le quorum et les témoins. |
| 1 | Mettre hors ligne les ressources Cluster Name (CNO/VCO). | Évite les conflits d’objets AD lors du changement de domaine. |
| 2 | Supprimer les objets AD du cluster (CNO/VCO) dans abc.com. | Option recommandée pour repartir proprement dans xyz.com. |
| 3 | Arrêter le service cluster et passer en démarrage manuel sur chaque nœud. | Assure un arrêt contrôlé pour la sortie du domaine. |
| 4 | Sortir du domaine abc.com → passer en Workgroup → joindre xyz.com → redémarrer. | Fenêtre d’indisponibilité ultra‑courte (double reboot). |
| 5 | Relancer ClusSvc et remettre en démarrage automatique ; remettre en ligne les noms. | Le cluster revient opérationnel dans le nouveau domaine. |
| 6 | Recréer les objets AD du cluster dans xyz.com. | Crée CNO/VCO et rattache les identités au nouveau domaine. |
| 7 | Vérifier CNO/VCO, témoins, SPN ; réactiver les bascules AG. | Corriger au besoin le file‑share witness avant la (re)création des objets. |
Commandes utiles (exemples)
# Mettre hors ligne les ressources de nom de cluster
Stop-ClusterResource -Name "Cluster Name" -Force
# Supprimer les comptes AD existants du cluster (CNO/VCO) dans l'ancien domaine
Remove-ClusterNameAccount -Cluster -DeleteComputerObjects
# Arrêt contrôlé du service cluster sur chaque nœud
Stop-Service ClusSvc
Set-Service ClusSvc -StartupType Manual
# ... changement de domaine via l'interface ou :
# Add-Computer -DomainName xyz.com -Credential xyz\admin -Restart
# Après jonction domaine
Set-Service ClusSvc -StartupType Automatic
Start-Service ClusSvc
# Récréation des comptes de nom de cluster dans le nouveau domaine
New-ClusterNameAccount -Name -Domain xyz.com -UpgradeVCOs Temps d’arrêt : limité aux redémarrages et à la remise en ligne des ressources (les bases restent attachées ; aucune recopie de données n’est nécessaire).
Pré‑requis et garde‑fous pour l’in‑place
- Confiance entre domaines au moins temporaire (bidirectionnelle) pour préserver Kerberos, accès au quorum et endpoints AG pendant la bascule.
- Witness : si vous utilisez un File Share Witness dans abc.com, prévoyez de le désactiver ou de le recréer côté xyz.com avant de réenregistrer les noms.
- SPN : supprimez/rafraîchissez les SPN
MSSQLSvc/...pour les comptes de service dans le nouveau domaine ; vérifiez les doublons (setspn -X). - Comptes de service : privilégiez les gMSA (Managed Service Accounts) pour simplifier la gestion des SPN et rotations de mot de passe.
- Firewall : autorisez 1433 (ou port dédié du moteur), 5022 (Always On endpoints) et le trafic cluster (RPC, SMB, ICMP).
Approche « nouveau cluster » — zéro ou quasi‑zéro coupure
Créez un nouveau WSFC dans xyz.com (même version de Windows/SQL/patching) et migrez la charge via un Distributed Availability Group (dAG). L’idée : répliquer en parallèle jusqu’à la bascule, puis échanger les noms/alias côté application.
- Préparer le nouveau cluster : même build SQL, storage, quorum, règles de firewall, comptes de service. Créez un AG « cible » vide avec les mêmes bases (restaurations en NORECOVERY ou STANDBY).
- Mettre en place le dAG : lier l’AG source (abc) et l’AG cible (xyz). Réplication asynchrone pendant le rattrapage initial.
- Abstraire la connexion : introduire un alias DNS/CNAME (ex. crm.alias) qui pointe vers le listener. Réduisez le TTL à ≤ 30 s.
- Bascule finale : passer en synchrone, faire le failover dAG, recréer ou réutiliser le listener (même nom si possible), puis supprimer l’ancien AG/cluster.
Exemple T‑SQL (dAG simplifié)
-- Sur le cluster source (abc)
CREATE AVAILABILITY GROUP [AG_SRC]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
FOR DATABASE [MaBase]; -- déjà en production
-- Sur le cluster cible (xyz), AG cible prêt
CREATE AVAILABILITY GROUP [AG_DST]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
FOR DATABASE [MaBase]; -- bases restaurées en NORECOVERY
-- Créer le dAG sur la source
CREATE AVAILABILITY GROUP [dAG_MIG]
WITH (DISTRIBUTED)
AVAILABILITY GROUP ON
([AG_SRC] WITH (LISTENER_URL = 'tcp://lsn-src.abc.com:5022')),
([AG_DST] WITH (LISTENER_URL = 'tcp://lsn-dst.xyz.com:5022'));
-- Suivre l'état
SELECT * FROM sys.dm_hadr_availability_group_states;
-- Avant la bascule finale, passer les bases en synchrone
ALTER AVAILABILITY GROUP [AG_SRC]
MODIFY REPLICA ON N'' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
ALTER AVAILABILITY GROUP [AG_DST]
MODIFY REPLICA ON N'' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
-- Bascule contrôlée
-- (selon le design retenu, failover du dAG puis re-création/pivot du listener) Cas sans dAG : si vous ne pouvez pas déployer un dAG, utilisez le changement de contexte HADR pour déplacer un AG vers un autre cluster :
ALTER SERVER CONFIGURATION
SET HADR CLUSTER CONTEXT = 'clus01.xyz.com';
Rejoignez ensuite les réplicas au nouvel AG, resynchronisez et recréez le listener.
Endpoints et sécurité inter‑domaines
- Kerberos : si une confiance bidirectionnelle existe, les endpoints SQL (port 5022 par défaut) fonctionnent classiquement.
- Certificats : sans confiance, optez pour des endpoints chiffrés par certificat et ouvrez uniquement les ports nécessaires.
- Compression et chiffrement : validez l’impact réseau (latence/jitter) et ajustez le commit mode (synchrone/asynchrone) durant le rattrapage initial.
Bonnes pratiques complémentaires
- Confiance entre domaines : simplifie SPN, Kerberos et l’accès aux partages (backups, file‑share witness).
- SPN et témoins : recréez les SPN
MSSQLSvcpour les services SQL/Listener dans xyz.com ; adaptez/quittez/rejoignez le file‑share witness au bon moment. - Alias DNS : utilisez un CNAME pour éviter de changer les chaînes de connexion. TTL ≤ 30 s pour un basculement quasi instantané.
- Tests répétés :
Test-Cluster, bascules AG, restaurations, latence réseau. Un environnement pré‑prod identique est un accélérateur majeur. - Protection des données : sauvegardes régulières + log shipping ou snapshots ; la migration de domaine ne remplace jamais la stratégie de sauvegarde.
- Windows Server 2025 : les clusters indépendants du domaine réduisent la dépendance à AD pour les futures migrations ; à envisager pour de nouveaux déploiements.
Plan de mise en œuvre recommandé
Calendrier indicatif
| Période | Actions | Livrables |
|---|---|---|
| T‑30 à T‑10 jours | Audit (inventaire WSFC, AG, jobs, logins, linked servers, SSRS/SSIS), tests de restauration, plan d’adressage/DNS, ouverture de flux. | Runbook détaillé, matrice de rôles, plan de tests, fiche de retour arrière. |
| T‑7 à T‑2 jours | Précréer comptes de service gMSA, SPN, witness dans xyz.com ; valider la confiance de domaine ; préparer scripts. | Scripts PowerShell/T‑SQL versionnés, fenêtres de maintenance validées. |
| T‑1 jour | Réduire le TTL DNS, passer les AG en automatic seeding disabled si utile, backups finaux, capture des états. | Points de restauration, état de référence (baseline). |
| Jour J | Exécuter la migration (in‑place ou dAG). Suivi temps réel (latence, synchronisation, erreurs). | Procès‑verbal d’exécution, horodatage des actions. |
| T+1 à T+7 jours | Nettoyage des objets AD résiduels, désactivation de l’ancienne infra, revue post‑mortem. | Rapport de fin de chantier, recommandations durables. |
Checklist d’avant‑bascule
- Version/édition SQL et patching identiques entre source et cible.
- Quorum et témoin planifiés (file‑share/Cloud/Node majority) dans xyz.com.
- Flux ouverts : 1433, 5022, SMB/RPC/ICMP pour cluster et backups.
- Comptes de service (gMSA) disponibles dans xyz.com.
- SPN prêts,
setspn -Xne remonte aucun doublon. - Alias DNS créé (TTL ≤ 30 s), procédure de bascule documentée.
- Backups complets et différentiels valides, plus tail‑log si nécessaire.
Checklist de validation post‑bascule
- AG :
sys.dm_hadr_*OK, synchronization_state = SYNCHRONIZED, failover_mode conforme. - Listener accessible, DNS propagé, applications reconnectées via l’alias.
- SPN présents dans xyz.com, Kerberos en place (éviter NTLM).
- SQL Agent jobs, plans de maintenance, opérateurs, Database Mail, linked servers testés.
- Logins migrés avec leurs SID (pas de orphan users), clés de chiffrement (TDE) et certificats réimportés.
- Surveillance : latence, temps de failover, errorlog, Cluster.log, compteurs PerfMon.
Scripts prêts à l’emploi
Inventaire et santé AG
-- Réplicas et état de synchronisation
SELECT ag.name AS AG_Name,
ar.replica_server_name,
ars.synchronization_state_desc,
ars.synchronization_health_desc,
ars.is_primary_replica,
drs.database_state_desc,
drs.synchronization_state_desc AS DB_Sync_State,
drs.log_send_queue_size, drs.redo_queue_size, drs.redo_rate
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id = ars.replica_id
JOIN sys.dm_hadr_database_replica_states drs ON ars.replica_id = drs.replica_id
ORDER BY ag.name, ar.replica_server_name;
-- Suivi du rattrapage avant bascule dAG
SELECT DB_NAME(database_id) AS [DB],
log_send_queue_size, redo_queue_size, last_redone_lsn, last_hardened_lsn
FROM sys.dm_hadr_database_replica_states
ORDER BY [DB]; Passage en synchrone avant la bascule
ALTER AVAILABILITY GROUP [AG_SRC]
MODIFY REPLICA ON N'<ReplicaPrimaire>'
WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
ALTER AVAILABILITY GROUP [AG_DST]
MODIFY REPLICA ON N'<ReplicaPrimaire>'
WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
Logins avec SID identique (éviter les utilisateurs orphelins)
-- Exemple : script de création avec SID et mot de passe hashé
-- (générer depuis la source ; exécuter sur la cible)
CREATE LOGIN [app_svc] WITH PASSWORD = 0x..., HASHED, SID = 0x..., CHECK_POLICY = ON, CHECK_EXPIRATION = OFF;
PowerShell cluster : diagnostic rapide
# État du cluster
Get-Cluster | Format-List *
# Ressources et propriétaire actuel
Get-ClusterResource | Select-Object Name, State, OwnerGroup | Sort-Object OwnerGroup
# Log du cluster (2 dernières heures, heure locale)
Get-ClusterLog -UseLocalTime -TimeSpan 02:00 | Out-File C:\Temp\ClusterLog.txt SPN essentiels (exemples)
# Vérifier les doublons
setspn -X
# Déclarer SPN pour le service SQL et le listener (port par défaut)
setspn -S MSSQLSvc/listener.xyz.com:1433 xyz\svc-sql
setspn -S MSSQLSvc/sqlnode1.xyz.com:1433 xyz\svc-sql Pièges fréquents et parades
| Problème | Symptôme | Résolution |
|---|---|---|
| CNO n’a pas le droit de créer les VCO | Échec de mise en ligne des noms de rôle/ressources | Déléguer « Créer/Supprimer objets ordinateur » sur l’OU cible avant l’étape de (re)création. |
| SPN dupliqués | Connexions en NTLM, lenteurs, erreurs Kerberos | setspn -X, supprimer les doublons, recréer proprement dans xyz.com. |
| Témoin file‑share dans l’ancien domaine | Perte de quorum pendant la bascule | Désactiver/recréer le witness côté xyz.com avant la remise en ligne des noms. |
| Pas de confiance inter‑domaines | Endpoints Always On ne s’authentifient pas | Utiliser des certificats pour les endpoints ou établir une confiance temporaire. |
| Listener non recâblé côté appli | Erreurs de connexion après bascule | Introduire un alias DNS dès le départ et basculer l’alias, pas les chaînes de connexion. |
Procédure détaillée — in‑place pas à pas
- Geler les bascules AG (maintenance) et prévenir les parties prenantes.
- Backups : master, msdb, model, TDE keys, bases applicatives (full + diff + tail‑log si coupure).
- Mettre hors ligne les noms de cluster (CNO/VCO) et documenter les IP associées.
- Supprimer les comptes AD du cluster dans abc.com pour éviter tout « ghost object ».
- Arrêter ClusSvc et mettre en Manual sur tous les nœuds.
- Sortir du domaine, passer en Workgroup, joindre xyz.com, redémarrer.
- Relancer ClusSvc (Automatic), remettre en ligne les ressources.
- Recréer CNO/VCO dans xyz.com et revalider le quorum/témoin.
- SPN : recréer pour les services SQL et le listener ; vérifier l’authentification Kerberos.
- Réactiver les bascules AG et contrôler la santé du cluster.
- Validation applicative : tests fonctionnels, montée en charge légère, journaux applicatifs.
Procédure détaillée — nouveau cluster + dAG
- Déployer le cluster cible (même version, mêmes correctifs, mêmes collation/trace flags si utilisés).
- Restaurer les bases en NORECOVERY sur l’AG cible.
- Configurer les endpoints (Kerberos ou certificats) et ouvrir le trafic réseau minimal.
- Créer le dAG et initier la réplication asynchrone.
- Rattraper jusqu’à des files log send/redo ≈ 0 ; passer en synchrone pour le dernier tronçon.
- Basculer : failover dAG, recréer (ou re‑pointer) le listener, basculer l’alias DNS.
- Nettoyer : retirer l’ancien AG/cluster, supprimer les objets AD résiduels, archiver les scripts.
Plan de retour arrière (si nécessaire)
- Conserver l’alias DNS pointant l’ancien listener jusqu’à validation applicative complète.
- Si in‑place : re‑joindre abc.com en inversant la procédure (CNO/VCO recréés dans l’ancien domaine).
- Si dAG : conserver la réplication jusqu’à validation, puis failover inverse si besoin.
- Restaurer depuis les backups horodatés en cas d’incohérence fonctionnelle.
FAQ express
Quel temps de coupure attendre ?
In‑place : généralement quelques dizaines de minutes (double reboot + remise en ligne). Nouveau cluster + dAG : coupure technique proche de zéro (temps de failover + propagation DNS).
Faut‑il changer les chaînes de connexion ?
Non si vous utilisez un alias DNS : vous basculez l’alias du listener source vers le listener cible.
Que devient le quorum ?
Prévoyez le témoin dans xyz.com avant la remise en ligne ; ajustez la stratégie (Node Majority, Node+FileShare, Cloud Witness).
Et les jobs SQL Agent ?
Exportez/importez ou synchronisez via un repository ; testez les comptes proxy, opérateurs et Database Mail.
Comment gérer les logins et SIDs ?
Générez des scripts de logins avec SID identique pour éviter les utilisateurs orphelins ; validez les permissions d’objets.
Synthèse
- Windows Server 2019+ : migration in‑place rapide (suppression/recréation des comptes de nom de cluster, changement de domaine, remise en ligne).
- Tous environnements : nouveau cluster + distributed AG pour bascule quasi instantanée, orchestrée via un alias DNS.
- Clés du succès : sauvegardes, tests, alias DNS à TTL court, SPN/witness corrects, scripts reproductibles, monitoring en direct, plan de rollback.
- Préparer l’avenir : envisager les clusters indépendants du domaine pour simplifier les prochaines migrations.
Annexe — Ports & vérifications rapides
| Composant | Port par défaut | Remarques |
|---|---|---|
| Moteur SQL | 1433 | Peut être dédié/personnalisé ; mettez à jour SPN en conséquence. |
| Always On Endpoint | 5022 | Fixez un port et documentez‑le pour firewall et dAG. |
| WSFC (RPC/SMB) | 135, 445, dynamiques | Consultez votre politique pour les plages RPC dynamiques. |
| ICMP | — | Utile pour la détection de nœud (selon vos règles de sécurité). |
Commandes de vérification
# Test DNS
Resolve-DnsName listener.xyz.com
Resolve-DnsName crm.alias
# Test port
tnc listener.xyz.com -Port 1433
tnc lsn-dst.xyz.com -Port 5022 Modèle de runbook condensé
1) Geler bascules AG, notifier, backups validés
2) Mettre hors ligne "Cluster Name", documenter IP
3) Remove-ClusterNameAccount -DeleteComputerObjects
4) Stop-Service ClusSvc / Set-Service -StartupType Manual
5) Quitter abc.com → Workgroup → rejoindre xyz.com → reboot
6) Set-Service ClusSvc -StartupType Automatic ; Start-Service ClusSvc
7) New-ClusterNameAccount -Domain xyz.com -UpgradeVCOs
8) Reconfigurer witness, SPN, alias DNS
9) Relancer bascules AG et tests applicatifs
10) Nettoyage AD, archivage logs & scripts
Avec ces stratégies et ce runbook, vous pouvez déplacer vos clusters SQL Server Always On du domaine abc.com vers xyz.com en quelques minutes de coupure… ou sans interruption perceptible.