Résoudre les problèmes liés aux échecs des instances de cluster de basculement SQL Server avec des gMSA

S’applique à : SQL Server sur Windows

Résumé

Cet article vous aide à résoudre les problèmes liés à l’installation d’une instance de cluster de basculement SQL Server (FCI), à l’ajout de nœud, au démarrage et aux échecs de basculement lorsque le service SQL Server s’exécute sous un compte de service géré de groupe (gMSA). Il couvre la récupération de mot de passe managée sur chaque nœud propriétaire possible, les droits spécifiques au nœud et les paramètres de démarrage, l’état d’installation incomplet et les échecs de ressources de cluster.

Avant de commencer, passez en revue les prérequis et exécutez la liste de contrôle de validation rapide dans Résoudre les problèmes d’installation, de démarrage et d’authentification de SQL Server avec des gMSA.

Symptoms

L’installation de FCI échoue lors de la validation du compte.
Une opération d’ajout de nœud signale des informations incohérentes sur le compte de service.
SQL Server commence à partir de la ligne de commande, mais pas via le cluster.
Le basculement échoue, car les paramètres de démarrage propres au nœud ou les configurations correspondantes sont absents.

Cause

Les échecs FCI peuvent impliquer la récupération de mot de passe, les métadonnées d’installation incomplètes, les paramètres de démarrage spécifiques au nœud, les droits qui diffèrent selon le nœud, l’accès au stockage ou les vérifications d’intégrité du service de cluster. La cause spécifique à gMSA est qu’un ou plusieurs nœuds propriétaires possibles ne sont pas autorisés à récupérer le mot de passe managé, de sorte que l’instance fonctionne sur certains nœuds et échoue sur d’autres.

Diagnostiquer les défaillances d’une instance de cluster de basculement

Exécutez la liste de contrôle de validation rapide sur chaque nœud propriétaire possible et comparez les résultats.

Exécutez les commandes suivantes sur chaque nœud propriétaire possible.
```
Test-ADServiceAccount -Identity 'SQLgMSA'
sc.exe qmanagedaccount MSSQLSERVER
Get-ClusterResource | Format-Table Name, ResourceType, State, OwnerGroup -AutoSize
```
Comparez l’identité de service, l’état du compte managé, les droits effectifs et les paramètres de démarrage entre les nœuds.

Résultat attendu :Test-ADServiceAccount renvoie True sur chaque nœud propriétaire potentiel, et la configuration du service ainsi que les paramètres de démarrage sont cohérents pour la même FCI.
Consultez l’historique de l’installation pour les opérations d’ajout de nœud annulées ou incomplètes.
Collectez le journal des erreurs SQL Server et le journal du cluster pour la même transition de ressource.

Générez un journal de cluster en exécutant la commande suivante.
```
Get-ClusterLog -UseLocalTime -Destination C:\Temp
```

Résoudre les défaillances d’une instance de cluster de basculement

Utilisez la solution qui correspond à la preuve des étapes de diagnostic.

Autoriser chaque nœud propriétaire possible à récupérer le mot de passe managé

Autorisez chaque nœud propriétaire possible à récupérer le mot de passe géré, puis retestez le basculement vers chaque nœud. Si le gMSA autorise des comptes d’ordinateur spécifiques, Set-ADServiceAccount remplace la liste complète des principaux autorisés. Examinez d’abord la valeur existante et incluez chaque principal qui doit rester autorisé.

# Review the gMSA configuration
Get-ADServiceAccount -Identity "SQLgMSA" `
    -Properties PrincipalsAllowedToRetrieveManagedPassword |
    Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

# If individual computer accounts are used, authorize each possible owner node
Set-ADServiceAccount -Identity "SQLgMSA" `
    -PrincipalsAllowedToRetrieveManagedPassword "NODE1$","NODE2$","NODE3$"

# Verify the gMSA from each possible owner node
Invoke-Command -ComputerName NODE1,NODE2,NODE3 {
    Test-ADServiceAccount -Identity "SQLgMSA"
}

Si un groupe de sécurité autorise le gMSA, ajoutez les nœuds propriétaires possibles à ce groupe au lieu de remplacer les principaux gMSA existants.

Add-ADGroupMember -Identity "SQL-FCI-gMSA-Nodes" `
    -Members "NODE1$","NODE2$","NODE3$"

Si vous souhaitez en savoir plus, consultez les articles suivants :

Corriger les droits spécifiques au nœud, les paramètres de démarrage ou l’état d’installation incomplet

Corrigez les droits confirmés spécifiques au nœud, les paramètres de démarrage ou l’état d’installation incomplet. Exécutez les commandes suivantes sur chaque nœud et comparez les résultats. Remplacez <InstanceID> par l’ID d’instance, par MSSQL16.MSSQLSERVERexemple .

# Verify the SQL Server service account on each node
Get-CimInstance Win32_Service -Filter "Name='MSSQLSERVER'" |
    Select-Object Name, StartName, State, StartMode

# Compare SQL Server startup parameters on each node
reg query "HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\<InstanceID>\MSSQLServer\Parameters"

# Check the SQL Server Windows service configuration
sc.exe qc MSSQLSERVER

Utilisez Gestionnaire de configuration SQL Server pour corriger les différences de paramètre de démarrage au lieu de modifier le Registre manuellement. Si vous souhaitez en savoir plus, consultez les articles suivants :

Si l’échec de la ressource de cluster n’est pas lié au compte de service, utilisez les commandes suivantes pour passer en revue les rôles en cluster, les ressources de cluster et le journal du cluster.

# List clustered roles and their current owner/state
Get-ClusterGroup

# List cluster resources and their current state
Get-ClusterResource |
    Format-Table Name, ResourceType, State, OwnerGroup -AutoSize

# Identify SQL Server-related cluster resources
Get-ClusterResource |
    Where-Object { $_.ResourceType -like "*SQL*" } |
    Format-Table Name, ResourceType, State, OwnerGroup -AutoSize

# Generate cluster logs
New-Item -ItemType Directory -Path "C:\ClusterLogs" -Force
Get-ClusterLog -UseLocalTime -Destination "C:\ClusterLogs"

Le module FailoverClusters PowerShell fournit les cmdlets Get-ClusterResource, Get-ClusterLog et Get-ClusterGroup. Pour plus d’informations sur ces applets de commande, consultez les articles suivants :

Pour les échecs spécifiques à SQL Server, consultez les articles suivants :

Recréer les clés de Registre spécifiques aux ressources manquantes

Pour recréer des clés de Registre spécifiques à une ressource manquantes, suivez les étapes décrites dans La procédure de recréation manuelle des clés de Registre spécifiques aux ressources. Avant d’apporter les modifications documentées au Registre, identifiez les ressources de cluster SQL Server et sauvegardez le Registre du cluster.

# Identify the SQL Server cluster resources
Get-ClusterResource |
    Where-Object { $_.ResourceType -like "*SQL*" } |
    Format-Table Name, ResourceType, State, OwnerGroup

# Back up the cluster registry before making documented registry changes
New-Item -ItemType Directory -Path "C:\Temp" -Force
reg export "HKLM\Cluster" "C:\Temp\ClusterRegistryBackup.reg" /y

Avertissement

Ne copiez pas les valeurs de Registre entre des instances non liées. Vérifiez l’ID d’instance, les chemins de stockage partagé, le rôle cluster et le nœud avant d’apporter une modification.

Collecter des données de diagnostic

Si l’échec persiste une fois ces étapes terminées, collectez les données de diagnostic à partir de chaque nœud propriétaire possible, y compris le journal du cluster pour la même transition de ressource. Pour obtenir les données de preuve spécifiques à gMSA et les journaux d’activité de SQL Server standard à collecter, consultez Collecte des données de diagnostic dans la vue d’ensemble de la résolution des problèmes gMSA. Utilisez ces données pour poursuivre l’enquête ou ouvrir un cas de support.

Commentaires

Cette page a-t-elle été utile ?

Dernière mise à jour : 2026-10-01