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

Il n’y a pas eu de newsletter au mois de Mai pour cause de grosse charge et aussi peu d’informations interessantes à collecter.

En compensation, voici un bulletin traitant de la façon dont l’arbitrage des disques est assuré entre les noeuds d’un cluster. D’où le titre barbare…

Qu’est-ce que l’arbitrage des disques et à quoi cela sert-il ?

Tout d’abord, une notion très simple à laquelle on ne pense jamais.

Jusqu’à Windows Server 2003, il faut savoir qu’il n’existait aucun mécanisme au sein du système d’exploitation permettant d’indiquer quel serveur est le propriétaire d’un disque partagé. Lorsque l’on présente un disque à plusieurs serveurs Windows Server 2003, chacun d’entre eux va tenter de s’approprier le disque et y écrire des informations. Par conséquent, cela peut induire des corruptions sur ce volume.

En effet, lorsqu’un disque est présenté à un serveur, le périphérique va être détecté par le driver disk.sys puis par la pile de stockage jusqu’au Volume Manager afin d’être visible par le Disk Manager afin de le rendre utilisable pour les administrateurs. Aucun driver ni composant n’a pas la capacité de voir que le disque est déjà utilisé par un autre serveur…

Lorsque ces mêmes serveurs sont inclus dans un cluster, le principe est le même tant que ce disque n’est pas inclus dans le cluster en tant que ressource du cluster (Physical Disk).

Depuis Windows Server 2008, un nouveau mécanisme a été introduit pour passer tous les disques présentés et considérés comme non connus en mode protégé (autrement appelé le “mode SAN”). Il faut une opération manuelle pour que le disque soit utilisable, et cela sur le serveur depuis lequel on effectue cette opération. Ceci implique que le disque peut être présenté à plusieurs serveurs Windows Server 2008 sans dommage.

L’arbitrage des disques intervient au sein d’un cluster et permet d’assurer la cohérence de l’appartenance des disques entre les noeuds.

En clair, un mécanisme (décrit plus bas) permet de notifier aux noeuds du cluster si un disque est déjà utilisé par un autre noeud ou s’il peut être disponible car il est très important de se rappeler qu’une ressource cluster ne peut être détenue que par un seul noeud à un instant T.

Un peu d’histoire

Avec Windows Server 2003, l’arbitrage des disques repose sur une mécanique très simple qui consiste à envoyer des commandes SCSI visant à réserver ou libérer le disque. Ce mécanisme est appelé Challenge/Defense Protocol.

Ce mécanisme entre en oeuvre lorsqu’un noeud du cluster tente de s’approprier un disque partagé actuellement attribué à un autre noeud qui semble défaillant.

Les commandes SCSI utilisée sont les suivantes :

• Reserve : lit et écrit sur le secteur 12 du disque partagé
• Release : libère le disque partagé (dans le cas d’une mise offline de la ressource)
• Reset : vise à casser la réservation en écrivant sur le secteur 12 du disque partagé

La commande Reset est particulière car elle peut être interprétée comme un reset de la LUN ou un reset du bus SCSI complet.

Dans le cadre du protocol de Challenge/Defense on parle de Successful Defense et de Successful Challenge ou en bon Français : Défense réussie et Challenge réussi.

Le principe d’une défense réussie est le suivant :

1. Le noeud qui détient le disque envoie une commande SCSI Reserve toutes les 3 secondes
2. Le noeud qui veut s’approprier le disque envoie une commande SCSI Reset toutes les 10 secondes
1. 3 secondes pour que le propriétaire renouvele sa réservation et 2 secondes pour que le bus se réinitialise
2. x2 pour donner au propriétaire deux chances de renouveler son bail
3. Le noeud qui détient le disque continue d’envoyer ses commandes SCSI Reserve prouvant sa bonne santé
4. La tentative d’appropriation par le challenger échoue donc

Le principe d’un challenge réussi est le suivant :

1. Le noeud qui détient le disque envoie une commande SCSI Reserve toutes les 3 secondes
2. Le noeud qui veut s’approprier le disque envoie une commande SCSI Reset toutes les 10 secondes
3. Le noeud qui détient le disque n’envoie plus de commandes SCSI Reserve impliquant une défaillance
4. La tentative d’appropriation par le challenger est donc réussie

La fiche technique suivante explique de manière plus détaillée ce mécanisme :

KB309186 - How the Cluster service reserves a disk and brings a disk online

Comme indiqué plus haut, la commande SCSI utilisé par le challenger peut se traduire dans certains cas par un bus reset. Ce qui pose problème si d’autres disques sont sur ce bus et présentés à d’autres serveurs.

En effet, ce qui peut se produire est que tous les disques soient désolidarisés de leurs propriétaires (que ce soient des serveurs Windows ou non) et causer des interruptions de service plus ou moins impactantes.

Cela survient bien sûr si la configuration du SAN est ainsi faite, en théorie les bus ne sont pas partagés.

Le mécanisme tel qu’il est connu avec Windows Server 2003 a donc été totallement modifié afin d’améliorer le fonctionnement de l’arbitrage au sein des clusters Windows.

Les Persistent Reservations

Windows Server 2008 introduit l’utilisation forcée des Persistent Reservations définies par le standard SCSI-3 SPC-3.

On ne parle plus de Challenge/Defense Protocol mais de Registration Defense Algorithm !

Le principe est le suivant :

Une table de réservation est maintenue par le SAN pour chaque LUN présentée. Cette table n’est pas exposée aux serveurs mais est mis en oeuvre sous la forme d’un “élément” virtuel au sein du SAN associé à chaque LUN. Je parle d’”élément” ne connaissant pas la terminologie des différents fabricants.

Cette table contient les informations d’enregistrement et de réservation de chaque HBAs a qui est présentée la LUN.

Chaque noeud ayant accès à la LUN disposera d’une entrée dans la table des enregistrements sous la forme d’une clé de 8 octects qui est générée sur chaque noeud. Le noeud disposant de la LUN verra sa clé dans la table des réservations comme schématisé ci-dessous :

Le mécanisme d’arbitrage reprend alors ce que nous avons déjà vu plus haut.

Le principe d’une défense réussie est le suivant :

1. Le noeud qui détient le disque a sa clé dans la table des réservations et vérifie toutes les 3 secondes que son entrée est toujours présente et qu’aucune nouvelle entrée n’est présente
2. Le noeud qui veut s’approprier le disque envoie une demande d’enregistrement et une demande de réservation toutes les 6 secondes
1. La demande d’enregistrement va s’effectuer
2. La demande de réservation va échouer car il y a déjà une clé dans la table des réservations
3. Dans son cycle de 3 secondes, le noeud qui détient le disque vérifie que sa clé est toujours présente dans la table des réservations
1. Ce noeud s’aperçoit qu’il existe une nouvelle entrée dans la table des enregistrements
2. Il supprime les informations qui ne le concerne pas dans la table des enregistrements
4. Le noeud qui veut s’approprier le disque termine son attente de 6 secondes et tente de s’approprier le disque en inscrivant sa clé dans la table des réservations
1. Cette tentative échoue car ce noeud ne dispose plus d’entrée dans la table des enregistrements

Le principe d’un challenge réussi est le suivant :

1. Le noeud qui détient le disque a sa clé dans la table des réservations et vérifie toutes les 3 secondes que son entrée est toujours présente et qu’aucune nouvelle entrée n’est présente
2. Le noeud qui veut s’approprier le disque envoie une demande d’enregistrement et une demande de réservation toutes les 6 secondes
1. La demande d’enregistrement va s’effectuer
2. La demande de réservation va échouer car il y a déjç une clé dans la table des réservations
3. Du fait d’une défaillance, le noeud qui détient le disque ne vérifie pas que sa clé est toujours présente dans la table des réservations
1. Ce noeud ne s’aperçoit donc pas qu’il existe une nouvelle entrée dans la table des enregistrements
2. Et il ne supprime pas les informations qui ne le concerne pas dans la table des enregistrements
4. Le noeud qui veut s’approprier le disque termine son attente de 6 secondes et tente de s’approprier le disque en inscrivant sa clé dans la table des réservations
1. Cette tentative réussie car ce noeud dispose de son entrée dans la table des enregistrements
2. Ce noeud supprime les informations qui ne le concerne pas dans la table des enregistrements

Peut-on dire que nous n’aurons plus de problèmes d’arbitrage de disques ?

Malheureusement il y a quelques cas où l’on peut avoir des comportements non souhaités… Même si c’est une amélioration énorme, les noeuds envoient des commandes standard SCSI 3 qui sont interprétées par le SAN, il s’avère que dans certaines situations, les persistent reservations posent problème.

C’est extrêmement rare mais dans la situation ou la connectivité entre le SAN et les noeuds d’un cluster est interrompue abruptement (crash des serveurs, ou pire…), au redémarrage de ces serveurs il apparaît que les persistent reservations ne sont pas “purgées” et les noeuds ne parviennent pas à prendre possession des disques et donc le service cluster ne parvient pas à démarrer.

Comme je l’ai dit c’est rare mais cela arrive… et c’est largement mieux que le Challenge/Defense Protocol !

Ressources

KB947710 - Parallel SCSI support in Windows Server 2008 Failover Clusters has been removed

Understanding Cluster Validation Tests: Storage (TechNet en Anglais)

Guillaume

Windows Core – Support Escalation Engineer