Lorsqu’un nœud d’un cluster de basculement (Failover Cluster) redémarre inopinément ou qu’une ressource refuse de basculer, le réflexe habituel consiste à consulter l’Observateur d’événements. Malheureusement, les événements d’erreur génériques (comme l’ID 1069) signalent souvent la panne sans en détailler la cause racine. C’est ici que l’analyse du journal interne du cluster devient indispensable.
Comprendre le fonctionnement des logs de cluster
Contrairement aux anciennes versions sous Windows Server 2003 où le fichier Cluster.log était continuellement écrit en texte clair dans le répertoire système, Windows Server 2008 a introduit le traçage ETW (Event Tracing for Windows). Les données opérationnelles transitent par un tampon circulaire en mémoire vive afin d’optimiser les performances d’E/S disque.
Par conséquent, vous ne trouverez aucun fichier texte prêt à être lu directement sur le disque. Il est nécessaire de forcer la génération et l’exportation du journal vers un format texte exploitable.
Méthode 1 : L’utilitaire cluster.exe sous Windows Server 2008
Si vous intervenez sur un environnement Windows Server 2008 standard, l’outil historique en ligne de commande cluster.exe reste le moyen le plus direct. Vous pouvez l’exécuter localement sur l’un des nœuds ou bien accéder à Windows 2008 en ligne de commande à distance pour piloter l’opération.
Pour générer et regrouper les journaux de l’ensemble des nœuds dans un dossier spécifique, utilisez la syntaxe suivante :
cluster.exe /cluster:NomDuCluster log /gen /copy: »C:\Temp\ClusterLogs »
Détail des paramètres :
- /cluster:NomDuCluster : Spécifie le nom d’accès au cluster (optionnel si exécuté localement).
- /gen : Déclenche la conversion du tampon binaire ETW en fichier texte lisible.
- /copy: »chemin » : Copie les journaux générés de tous les nœuds actifs dans le répertoire cible indiqué.
Méthode 2 : L’approche moderne avec PowerShell (Get-ClusterLog)
Dès Windows Server 2008 R2 et sur toutes les versions modernes (2012, 2016, 2019, 2022), le module PowerShell FailoverClusters remplace avantageusement l’ancien binaire. C’est une commande indispensable qui rejoint les lignes de commandes indémodables Windows en administration système.
La commande de base s’exécute dans une console PowerShell élevée :
Get-ClusterLog -Destination « C:\Temp »
Le principal inconvénient d’un export brut réside dans sa taille colossale. Pour isoler un incident survenu récemment sans saturer le stockage, deux paramètres sont capitaux :
Get-ClusterLog -Destination « C:\Temp » -TimeSpan 30 -UseLocalTime
- -TimeSpan 30 : Limite l’extraction aux 30 dernières minutes précédant l’exécution, évitant de manipuler des fichiers de plusieurs centaines de mégaoctets.
- -UseLocalTime : Par défaut, le journal de cluster consigne les horodatages au format UTC (GMT). Ce paramètre convertit les heures selon le fuseau horaire local du serveur, facilitant la corrélation avec vos autres journaux d’événements.
Pensez à surveiller l’espace disponible lors d’exports massifs sur plusieurs nœuds ; il peut être utile de vérifier ou d’afficher la taille du répertoire en ligne de commande avant et après l’opération.
Clés pour lire et interpréter le cluster.log
Une fois le fichier généré, ouvrez-le avec un éditeur de texte performant capable d’encaisser de gros volumes (comme Notepad++). Voici les éléments à rechercher en priorité :
- Les niveaux de sévérité : Concentrez vos recherches sur les balises [ERR] et [WARN].
- Le composant RHS (Resource Hosting Subsystem) : Les mentions RHS et les appels de contrôle LooksAlive ou IsAlive indiquent souvent qu’une ressource applicative (disque, SQL Server, rôle de fichier) a cessé de répondre aux pings du cluster.
- Les pertes de Quorum et de Heartbeat : Des erreurs réseau inter-nœuds mentionnant l’interface de communication privée ou des échecs d’arbitrage sur le disque témoin (Witness disk).
