J’ai déjà parlé ici du nouveau modèle de quorum de Windows Server 2008 ainsi que de certaines notions d’arbitrage des disques mais le mécanisme de logging du cluster a lui aussi beaucoup changé avec Windows Server 2008.

Au delà des différents journaux d’évènements qui présentent une vue synthétique et compréhensible des évènements, on se réfère encore beaucoup au fameux cluster.log.

Pour ceux qui n’ont jamais osé en ouvrir un, ce log est au format texte pur et dur avec des évènements au millième de seconde et beaucoup de mots incompréhensible sinon par les développeurs eux-mêmes.

Rébarbatif n’est pas un mot assez fort semble-t-il !

 

 

Avec Windows Server 2008, le cluster.log dans ce format n’existe plus. C’est désormais sur le moteur ETW que se repose le service cluster pour écrire ses évènements dans des logs un peu bizarres avec une extension .ETL.

ETW veut dire Event Tracing for Windows. Je ne vais pas m’étendre sur le sujet mais ce mécanisme existe depuis Windows Server 2003 et est de plus en plus utilisé par les développeurs de Windows pour inclure dans leur partie de code des fonctions permettant d’activer l’écriture d’évènements dans un log spécifique lorsque l’on a besoin de diagnostiquer un problème spécifique.

Quelques ressources sur le sujet :

Improve Debugging And Performance Tuning With ETW (MSDN Magazine en Anglais)

Event Tracing (MSDN en Anglais)

 

 

Revenons à notre cluster.log… Que puis-je faire des fichiers .ETL générés par le service cluster ?

En l’état pas grand chose. Mais en tapant la commande suivante depuis un prompt CMD en mode privilégié, on retrouve le cluster.log au format texte et donc largement plus exploitable (je me comprends):

CLUSTER LOG /G /COPY:"C:\TEMP"

Cette ligne de commande concatène tous les fichiers .ETL de tous les noeuds du cluster et les transforme en fichier texte.

Voilà le grand changement qui se devait d’être expliqué. Mais ce n’est pas tout…

 

 

En effet… maintenant que nous pouvons jeter un oeil au cluster.log, on peut parfois se rendre compte que certaines périodes ne sont pas couvertes dans ce log.

Quand on veut diagnostiquer un problème et que l’on a pas les évènements couvrant la période où a eu lieu ce dysfonctionnement, on peut être partagé entre l’énèrvement ou le fatalisme.

Pour ma part, c’est de la frustration.

 

 

Pourquoi cela peut-il arriver ? On s’attend à ce qu’un log serve justement à collecter tous les évènements, sans trou noir. C’est son rôle...

Il faut donc savoir quelques petits détails supplémentaires.

 

 

Le principe est le suivant :

• Les évènements du service cluster sont écrits dans plusieurs fichier ETL qui sont soumis chacun au mode circular logging :
  • Ces fichiers sont présents dans le dossier %WINDIR%\System32\winevt\logs
  • Les fichiers .ETL sont nommés ClusterLog.etl.00x où x représente un incrément de 1
• A chaque démarrage d’un nœud de cluster une nouvelle session de tracing est démarrée :
  • Cette session est liée à un fichier .ETL particulier, en l’occurrence le fichier  ClusterLog.etl.00x+1
  • Le nombre maximum de fichiers de tracing est 5 donc lorsque l’on atteint le 5ème log, le prochain redémarrage entrainera la conséquence que le logging s’écrira dans le premier fichier ETL, à savoir : ClusterLog.etl.001
• Pendant une session de tracing, le logging est soumis à la taille maximum du cluster log qui s’applique au fichier ETL de la session en cours :
  • Si l’on atteint cette limite, le tracing continue d’écrire les évènements du service cluster mais écrit au début du fichier .ETL en cours par-dessus les évènements les plus anciens

Lorsque l’on génère le cluster.log au format texte, tous les fichiers .ETL sont pris en compte et concaténés pour former la trace complète

Donc, si, lors d’une session de tracing, la taille maximale du cluster log a été atteinte, le fichier au format texte aura des « trous » et manqueront des évènements

 

Exemple :

 

Avec une représentation graphique :

Cet exemple assume que la taille maximale du cluster log est définie pour garder 72 heures d’évènements.

Lorsque l’on génère le cluster.log au format texte, nous aurons dans ce fichier les évènements suivants : {10/06 -> 13/06} {15/06 -> 17/06} {19/06 -> 22/06}.

Il manquera les évènements suivants du 14/06 et du 18/06 car les évènements de ces jours auront été écrasés car les sessions de tracing correspondantes (#2 et #3) auront duré plus de 72 heures (équivalent de notre taille maximale du cluster.log).

Vous trouverez des explications plus détaillées sur le logging cluster en suivant les webcasts ci-dessous :

Failover Cluster Validation and Troubleshooting with Windows Server 2008 (Level 300) (en Anglais)

Une version mise à jour pour Windows Server 2008 R2 (en Anglais)

 

 

Ce que l’on conseille de manière générale est de configurer le cluster log pour pouvoir détenir les évènements des dernières 72 heures. Ceci permet de récupérer les cluster logs suite à l’identification d’un problème même dans le cas où ce problème intervient au début du week-end et que celui-ci n’est détecté que le lundi suivant.

En ayant conscience de cela, la taille maximale du cluster log devra être calculée en fonction des éléments suivants pour permettre de pouvoir tracer tous les évènements dans la période de 72 heures:

• Le ou les services ou applications mises en cluster : chaque service peut avoir une façon différente d’écrire des évènements
  • Verbosité des applications en cluster
  • Looks alive/is alive
• Le niveau de verbosité du cluster log en lui-même (cluster log level)
• La configuration du cluster et des ressources du cluster :
  • Configuration des ressources pour qu’elles s’exécutent dans des Resource Monitors distincts
  • Configuration des temps de polling
  • Configuration des thresholds de redémarrage des ressources et du service cluster en cas de défaillance
• Le comportement des ressources et des nœuds : défaillance des nœuds, défaillance des ressources
  • Nombre de modifications apportées à la configuration du cluster dans la période des 72 heures

 

 

Pour déterminer la taille du cluster log il s’agit donc de superviser le cluster et les logs en situation de production pour identifier la taille convenable.

 

 

Guillaume

Windows Core Support Escalation Engineer