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 :

 

Enregistrements	Réservations
Nœud 1 HBA1 Clé 1	Clé 1
Nœud 2 HBA1 Clé 2

 

 

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