HyperV.fr

Cluster iSCSI

Vous devez créer un cluster iSCSI sous Windows Server 2008 ou 2008 R2 ?

Ou vous voulez migrer un cluster MSCS Windows Server 2003 vers la nouvelle fonctionnalité Failover Clustering introduite depuis 2008 Server ?

Si tel est le cas, il faut savoir que Microsoft a remanié les fonctions de cluster depuis 2008 Server. En effet, désormais, ces nouvelles plateformes serveurs utilisent, et requièrent, la version 3 du standard SCSI, ce qui impact bien évidemment le protocole iSCSI également.

Ce changement de version apporte plus de fiabilité lors du basculement d’un cluster, mais ajoute dorénavant quelques restrictions supplémentaires. Cela se passe notamment pour les fonctions de réservation/libération d’un disque partagé entre plusieurs noeuds d’un cluster.

Avec des clusters Windows Server 2003, les commandes SCSI-2 utilisées sont les suivantes : Reserve / Release / Reset.

• SCSI Reserve est utilisé par le noeud qui détient le disque partagé : Toutes les 3 secondes, le noeud actif signale sa présence pour conserver le disque dont il est le propriétaire actuel.
• SCSI Reset est une commande SCSI utilisée par un autre noeud qui souhaite devenir le propriétaire d’un disque partagé : Toutes les 10 secondes, cette commande est envoyée.

Si le noeud actif, propriétaire du disque, est toujours actif, la prise du disque par le noeud passif échouera. A l’inverse, si le noeud actif subit une défaillance, la commande SCSI Reset du noeud passif réussira, car le noeud actif n’envoi plus de SCSI Reserve.

Le problème de cette technique, c’est que la commande SCSI Reset peut-être mal interprétée. Au lieu d’être interprétée comme un disque reset, celle-ci, dans certains cas, peut être vu comme un Bus Reset. Sachant qu’un Bus SCSI peut être partagé entre plusieurs disques, cela peut être problématique et libérer d’autres disques accidentellement.

Ca, c’était sous Windows Server 2003 et SCSI-2.

Passons maintenant à Windows Server 2008 et donc SCSI-3.

Une nouvelle fonction entre en jeu : Les « Réservations persistantes » (Persistent Reservations).

Désormais, c’est le SAN qui va gérer l’appartenance d’un disque à une machine du cluster. Une table d’enregistrements/réservations apparait pour chaque LUN mises à disposition.

Cette table contient deux colonnes :

• Enregistrements : Contient une référence à chaque noeud pouvant posséder la LUN.
• Réservation : Contient la référence au noeud possédant la LUN.

Dans la pratique, comment cela se passe ?

Le noeud actif, qui possède la LUN, va vérifier toutes les 3 secondes que sa référence est dans la table des réservations et qu’aucune autre référence ne s’y trouve. Il vérifie également qu’il n’y a pas d’autres entrées que la sienne dans la table des enregistrements. Si tel est le cas, le noeud actif supprimera ces autres références. Donc, toutes les 3 secondes, le noeud actif vérifie qu’il est le seul en enregistrement et réservation.

Toutes les 6 secondes, le noeud (passif) qui veut posséder la LUN tente une demande d’enregistrement et de réservation.

• Dans le cas où le noeud actif est toujours actif, la demande de réservation du noeud passif échouera. La demande d’enregistrement sera, elle, prise en compte et inscrite.
• Si le noeud actif n’est plus actif, il n’a pas pu supprimer dans la table des enregistrements la référence de l’autre noeud voulant s’approprier le disque. Dans ce cas, alors, au terme des 6 secondes d’attente, la réservation du disque par le noeud demandeur réussira, car il possède sa référence dans la table des enregistrements. Le noeud qui vient de récupérer le disque supprimera, à son tour, les références qui se trouvent dans la table des enregistrements et qui ne le concernent pas.

Voilà pour les explications. Bien que SCSI-3 soit plus fiable que SCSI-2 pour la réservation de disque, cela n’empêche pas qu’il puisse y avoir des problèmes lors de la réservation de disque. Toutefois, cela reste moins fréquent et plus rare qu’avec la version SCSI-2.

Cette fonction de « Persistent Reservations » est devenu un pré-requis à l’implémentation d’un cluster Windows Server 2008 sur SAN iSCSI. Cette fonction n’est disponible qu’avec SCSI-3, mais ce n’est pas parce qu’un SAN est compatible SCSI-3 qu’il supporte obligatoirement cette fonction. Il est donc impératif que vous le vérifiez avant de vous lancer dans la réalisation d’un cluster (i)SCSI avec Windows Server 2008 (ou R2).