C:\>Windows Internals - L'équipe Française de Support Windows_ : Clustering

Partager ses sous-répertoires dans un cluster Windows Server 2008 ou Windows Server 2008 R2

GaetanB — Fri, 27 Nov 2009 12:31:01 GMT

Tous les aficionados du cluster auront remarqué la disparition de la fonctionnalité pourtant très appréciée de partage automatique des sous-répertoires d’un partage clusterisé.

En dehors de la création manuelle de ces partages, point de salut.

Voilà une petite commande pour partager tous les sous-répertoires du répertoire courant.

FOR /F %i IN ('dir /b /a:d') DO net share %i=%CD%\%i

Si les partages doivent être cachés, la commande devient :

FOR /F %i IN ('dir /b /a:d') DO net share %i$=%CD%\%i

Explication :

dir /b /a:d renvoie la liste des répertoires contenus dans le répertoire courant

/b pour une liste simple et /a:d seulement les fichiers qui sont des répertoires (directory)

La boucle FOR va donc exécuter le code qui suit le DO pour chacune des entrées renvoyée par le dir

la commande net share permet le partage, on lui indique le nom du partage et le chemin d’accès complet au partage

%i ou %i$ sera le nom du partage (respectivement visible et caché), ce nom est le nom du répertoire lui même

%CD%\%i est la concaténation du chemin d’accès complet (répertoire actuel) et du nom du sous-répertoire à partager

Les 2 lignes de commandes citées devront être exécutées directement depuis l’invite de commande

Pour celles et ceux qui veulent inclure ces lignes dans un fichier .cmd ou .bat, voici la syntaxe à utiliser :

FOR /F %%i IN ('dir /b /a:d') DO net share %%i=%CD%\%%i

Si les partages doivent être cachés, la commande devient :

FOR /F %%i IN ('dir /b /a:d') DO net share %%i$=%CD%\%%i

le %i qui est la variable locale à notre commande doit avoir un double % pour être correctement interprétée

Le %CD% est une variable système et n’a donc pas besoin d’être doublé au niveau du %

iSCSI reconnecting suite à un reboot

Lionel.T — Fri, 23 Oct 2009 08:25:08 GMT

J’ai rencontré un problème assez pénalisant en utilisant mes VMs Cluster sous Hyper-V :

Lors de chaque redémarrage de mes guest Windows 2008 pour faire des clusters virtuels, les connexions iSCSI restaient en état reconnecting. Je devais alors reconfigurer tous les initiators afin qu’ils puissent être de nouveau fonctionnel avec mon iSCSI Target.

J’ai utilisé une solution de contournement avec la clef de registre EnablePMTUDiscovery = 1 dans HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Maintenant, mes VMs se reconnectent correctement suite à leur reboot.

Note : Cette solution de contournement peut affecter les performances TCP et n’est valable que dans le cadre de testing…

Lien Technet

http://technet.microsoft.com/en-us/library/cc957539.aspx

La liste suivante décrit les paramètres que vous pouvez utiliser avec cette valeur du registre :

1 : Lorsque vous définissez EnablePMTUDiscovery sur 1, TCP tente de découvrir la taille de l'unité MTU (Maximum Transmission Unit ) ou la taille de paquet la plus élevée sur le chemin d'accès à un hôte distant. TCP peut éliminer la fragmentation sur les routeurs sur le chemin d'accès qui connecte des réseaux à différentes unités MTU, en découvrant l'unité MTU du chemin et en limitant les segments TCP à cette taille. Inversement, la fragmentation affecte le débit TCP.

0 : Nous vous recommandons de définir EnablePMTUDiscovery sur 0. Ainsi, une unité MTU de 576 octets est utilisée pour toutes les connexions qui ne sont pas des hôtes sur le sous-réseau local. Si vous ne définissez pas cette valeur sur 0, un attaquant peut forcer la valeur de l'unité MTU à une très petite valeur et ainsi surmener la pile.

Lionel

Windows Core Support Escalation Engineer

Cluster Checkpoint registry (Windows 2003)

Lionel.T — Tue, 06 Oct 2009 17:53:00 GMT

Objectif:

Nativement, le service Cluster maintient sa configuration en copiant sur tous les nœuds du Cluster la Hive Cluster. Cette Hive (une ruche en anglais) se situe dans HKLM\Cluster et contient tous les paramètres des ressources du Cluster. C'est-à-dire que les ressources utilisées dans le Cluster stockent leurs paramètres et propriétés dans cette Hive (@IP, nom du Network Name, chemin d’un File share , etc). On retrouve également une copie de cette Hive sur le disque du Quorum (Q:\MSCS) sous la forme d’un fichier CHKxxx.tmp.

Mais si une application clusterisée n’utilise pas la section HKLM\Cluster pour y stocker ses données, comment les autres nœuds peuvent recevoir ce contenu ?

Le registry Checkpointing dans un cluster a pour objectif de propager le contenu d’un bout de base de registre qui ne serait pas localisée dans HKLM\Cluster mais dans HKLM\Software, là où les applications enregistrent généralement leurs données.

Des fichiers 0000000x.CPT présents sur le disque du quorum représentent le contenu de base de registre qui sont à sauvegarder et donc a propager lorsque ces ressources basculent d’un nœud à un autre. Ils sont organisés comme suit :

ü 0000000x.CPT représente un checkpoint registry pour une ressource.

ü Il sont stockés sur le disque du Quorum comme ceci : Q:\MSCS\<GUID>\

Q : étant le disque du Quorum et MSCS le répertoire par défaut

<GUID> est le GUID de la ressource nécessitant un checkpoint registry et que nous retrouvons dans HKLM\Cluster\GUID.

Ce principe est utilisé par SQL ou des applications génériques par exemple.

Ressources en ligne:

How a Server Cluster Works: http://technet2.microsoft.com/WindowsServer/en/library/4aa0be73-ef61-4f9c-a071-b390278b47731033.mspx?mfr=true

Checkpointing http://msdn2.microsoft.com/en-us/library/aa367195.aspx

ClusterRecovery tool: http://www.microsoft.com/downloads/details.aspx?familyid=2BE7EBF0-A408-4232-9353-64AAFD65306D&displaylang=en

Knowledge Base:

Restore registry check points stop working after you restore a server cluster

http://support.microsoft.com/default.aspx?scid=kb;EN-US;307469

174070 Registry replication in Microsoft Cluster Server

http://support.microsoft.com/default.aspx?scid=kb;EN-US;174070

Règles relatives au checkpoint Registry

Lors de tout changement sur la clé de registre ‘Checkpointée’ et lorsque la ressource est en ligne, le service cluster stocke une copie de ce registre sur la ressource quorum.
Un changement fait sur une clé de registre ‘Checkpointée’ pendant que la ressource se trouve ‘Offline’ sera ré-écrasé par la précédente valeur stockée lorsque l’application passera ‘Online’
Si les ressources basculent sur un autre nœud, le service cluster restaure les valeurs de registre depuis les fichiers stockées sur le quorum vers le nouveau nœud avant de mettre en ligne la ressource concernée par le Checkpoint.
Si une ressource est supprimée, le Checkpoint est aussi supprimé mais pas les informations contenu dans le registre local.
Les Checkpoints sont inclus dans les backup créés par la function BackupClusterDatabase
Plusieurs instances de ressources sur différents nœuds doivent être manipulées avec attention. Par exemple, une ressource A[0] stocke une valeur data[0] dans un Checkpoint A sur le nœud 0. Une ressource A[1] stocke une valeur data[1] dans un Checkpoint A sur le nœud 1. Si la ressource A[1] basculent sur le nœud 0, le service Cluster remplacera data[0] par data[1] pour le checkpoint A. Si la ressource A[0] dépend de data[0], elle sera aussi en échec. Une solution à ce problème consiste à donner des noms différents de clef ‘Checkpointé’ sur les différents nœuds.

Lister les Checkpoints actuels du Cluster:

cluster . /checkpoints

Ajouter un Checkpoint au Cluster

cluster . resource "< Nom de la ressource >" /addcheckpoints:"\Software\...”

Supprimer un Checkpoint au Cluster

cluster . resource "< Nom de la ressource >" /removecheck :"\Software\...”

Mise en situation :

Imaginons que nous avons créé une application Client/Serveur ‘Onyone’ dont les données de registre sont stockées sous HKLM\Software\Onyone et HKLM\Software\Onyone2. Nous souhaitons la mettre dans un cluster sous forme d’application générique afin d’offrir aux utilisateurs une haute disponibilité.
Pour assurer la copie des clefs précédentes, nous allons ajouter à l’aide de la commande CLUSTER.EXE, deux checkpoints sur la ressource Network Name ‘Network Name DATA’ de cette application.

C:\>cluster resource "Network Name DATA" /addcheckpoints:"SOFTWARE\Microsoft\onyone"
Adding registry checkpoint 'SOFTWARE\Microsoft\onyone' for resource 'Network Name DATA'...

C:\>cluster resource "Network Name DATA" /addcheckpoints:"SOFTWARE\Microsoft\onyone2"
Adding registry checkpoint 'SOFTWARE\Microsoft\onyone2' for resource 'Network Name DATA'...

Regardons maintenant la prise en compte de ces commandes :

C:\>Cluster . resource /checkpoints
No resource name specified.

Listing registry checkpoints for all resources...

Resource             Registry Checkpoint
-------------------- --------------------------------------------------------
Quorum Disk          None

Cluster IP Address   None

Cluster Name         None

Disk P:              None

IP File Share        None

Network Name DATA    'SOFTWARE\Microsoft\onyone'

Network Name DATA    'SOFTWARE\Microsoft\onyone2'

File Share           None

Sur le disque du quorum, nous retrouvons dans le répertoire \MSCS (par défaut), un nouveau répertoire qui a été créé et ayant le GUID de la ressource concernée et contenant deux fichiers CPT :

Ce GUID est peut être retrouvé dans la clef HKLM\Cluster.

Lionel

Windows Core Support Escalation Engineer

Liens vers HCL/WSC et matrice de compatibilité Cluster

Lionel.T — Thu, 01 Oct 2009 23:38:00 GMT

La HCL , WSC ou matrice de compatibilité Cluster, ça vous dit quelque chose?

Mais si, ce sont ces fameuses listes qui répertorie l'ensemble des élements composant une solution Cluster 2000/2003. L'ennui est qu'il est difficile de trouver sa configuraiton et les matériels et logiciels évoluant, elle n'est pas forcement à jour. C'est pour cela que je vous ai regroupé différents pointeurs vers les OEM les plus connus pour limiter les spectres de vos recherches. Si vous avez un doute sur la compatibilité de votre matériel avec le MSCS, il est facile de demander à votre OEM le lien vers vers votre solution en place.

EMC Support Matrices : http://www.emc.com/interoperability/
HP Cluster Configuration Support Matrices http://h18022.www1.hp.com/solutions/enterprise/highavailability/answercenter/configuration-all.html
HP Support Matrices : http://h20272.www2.hp.com/
Dell Support Matrices : http://www.dell.com/content/topics/global.aspx/sitelets/solutions/cluster_grid/clustering_ha?c=us&cs=555&l=en&s=biz&~tab=4
Brocade Compatibility Matrix : http://www.brocadekorea.com/download/resource/CompatibilityMatrix_4_03.pdf
Cisco Disk Storage Interoperability Matrix http://www.cisco.com/en/US/docs/switches/datacenter/mds9000/interoperability/matrix/Matrix1.html
IBM Support Matrices : http://www-03.ibm.com/systems/storage/product/interop.html
HCL/WSC Microsoft : http://www.windowsservercatalog.com/results.aspx?bCatID=1291&cpID=0&avc=10&OR=1

Et pour Failover Cluster 2008 et 2008 R2? et bien, c'est beaucoup plus simple : il suffit que vos composants (hosts, HBA, SAN et softtware) aient reçus le logo Certified for Windows Server 2008 ou Certified for Windows Server 2008 R2 et que les tests de Validate passent avec succès. That's All!

The Microsoft Support Policy for Windows Server 2008 Failover Clusters : http://support.microsoft.com/kb/943984

Lionel

Windows Core Support Escalation Engineer

Routage statique et Windows Server 2008 Failover Clustering

GuillaumeD — Wed, 09 Sep 2009 14:16:00 GMT

C’est la première fois que je rencontre ce cas de figure et c’est presque un coup de chance qui m’a permis d’identifier la solution à ce problème.

Le contexte est le suivant : sur un cluster Windows Server 2008 deux noeuds, lorsque l’on passe la ressource IP Address offline ou que l’on forçe un failover du groupe contenant cette ressource il n’est plus possible de contacter le noeud qui détenait cette ressource à travers le réseau. Encore moins d’ouvrir une session en Remote Desktop.

Comportement qui laisse sceptique au début et qui relève de la magie lorsqu’on nous le montre…

En une images, la configuration simple pour reproduire ce comportement :

Trois réseaux (le problème apparaît avec deux voir un seul réseau) :

Réseau publique : communication intra-cluster et connectivité clients
Réseau pour le heartbeat : communication intra-cluster seule autorisée
Réseau iSCSI : aucune communication cluster autorisée

Une ressource IP Address disposant de l’adresse IP 192.168.40.33

Les addresses IP des noeuds étant :

LAB-WS08-SQL0 : 192.168.40.103
LAB-WS08-SQL1 : 192.168.40.104

Après les quelques vérifications d’usage autour de la configuration des adaptateurs réseau de chaque noeud, nous avons vérifié la présence de paramétrages de routage spécifique, propre aux serveurs. Et il s’est avéré qu’une route statique avait été rajoutée sur chacun des noeuds.

Et c’est là que l’on pointe un sujet méconnu : l’adaptateur virtuel nommé Microsoft Failover Cluster Virtual Adapter.

La question est donc qu’est-ce que cet adaptateur et à quoi sert-il ?

En peu de mots, le code du cluster sous Windows Server 2008 a été en grande partie réécrite et la couche réseau en a bénéficié. Ce qui se traduit par l’apparition de cet adapateur qui a pour tâche de construire et de maintenir une structure de routage sur chacun des noeuds afin d’améliorer la connectivité réseau en cas de défaillance de l’un des adaptateur réseau.

C’est cette nouveauté qui permet de placer des noeuds d’un même cluster sur des sous-réseaux différents séparés par des routeurs, ce qui n’était pas possible avec Windows 2000 Server et Windows Server 2003.

Mais revenons à notre problème.

Sur ces deux serveurs, une route statique a été configurée, comme on peut le voir sur les captures d’écran ci-dessous :


LAB-WS08-SQL0	LAB-WS08-SQL1

On voit ici que cette route s’applique à tous les adaptateurs.

En rouge la route statique.

En bleu, l’adresse IP du noeud.

En vert l’adresse IP de la ressource IP Address du cluster.

Notez ce qui est entouré de jaune.

Lorsque l’on bascule la ressource IP Address ou que l’on passe offline cette ressource, la route statique du noeud disparait de la table de routage (du moins elle ne fait plus partie des routes actives) :

Ce qui rend impossible la connectivité vers et depuis le réseau 192.168.42.0 (le sous-réseau qui fait l’objet du routage statique).

Comment résoudre ce problème et utiliser tout de même un routage statique ? C’est simple, mettre en oeuvre le routage statique de manière recommandée, à savoir suivre la procédure suivante :

Supprimer la route statique :

ROUTE DELETE 192.168.42.0
Identifier l’adaptateur réseau qui doit bénéficier de ce routage statique :

NETSH INT IPV4 SHOW INT
Appliquer la route statique à cet adaptateur uniquement en exécutant la commande suivante :

ROUTE –P ADD 192.168.42.0 MASK 255.255.255.0 0.0.0.0 IF 15

où 15 correspond à l’adaptateur et 0.0.0.0 représente la route par défaut (en l’occurence la passerelle pour communiquer avec le réseau 192.168.42.0 sera l’adresse IP de l’adaptateur réseau du noeud)

On obtient ceci :


Table de routage avec la ressource IP Address online	Table de routage avec la ressource IP Address offline

On voit ici que la route statique reste active même lorsque la ressource IP Address est offline.

Meilleures pratiques

Ne jamais modifier le paramétrage de l’adaptateur virtuel Microsoft Failover Cluster Virtual Adapter
Ne jamais désactiver l’adaptateur virtuel Microsoft Failover Cluster Virtual Adapter
Créer des routes statiques avec la méthode décrite ci-dessus

Ressources

Rendons à César ce qui appartient à César, le bulletin qui m’a permis de résoudre cet incident : Active Route gets removed on Windows Server 2008 offline Cluster IP Address – Blog Microsoft Enterprise Networking Team

What is a Microsoft Failover Cluster Virtual Adapter anyway? – Blog de l’équipe Core aux US

Multi-Site Failover Cluster Communications Connectivity – Blog de l’équipe Core aux US

Guillaume

Windows Core Support Escalation Engineer

Supportabilité du cluster Windows Server 2008

GuillaumeD — Thu, 02 Jul 2009 23:57:00 GMT

Parmi les nouveautés (ce ne sont plus vraiment des nouveautés à l’heure actuelle) apportées avec Windows Server 2008, l’outil de diagnostic Validate en est une qui laisse parfois dubitatif.

En effet, il est expliqué que les clusters n’ayant pas satisfait les deux critères suivants ne sont pas supportés :

Passage “réussi” de Validate sur chacun des noeuds (ou futurs noeuds) du cluster
Chaque composant (logiciel ou matériel) de chaque noeud (ou futur noeud) du cluster doit avoir été qualifié et disposer du logo “Certified for Windows Server 2008”

Mais alors, pourquoi un composant ne disposant pas du logo “Certified for Windows Server 2008” compromettrait la supportabilité de mon cluster alors que le passage de Validate n’indique aucune erreur ?

La réponse tient en deux points :

Garantie fonctionnelle : la qualification des composants apporte l’assurance que leur développement respecte le mode de fonctionnement du cluster Windows Server 2008
Garantie opérationnelle : le passage de Validate permet de s’assurer que le cluster respecte les meilleures pratiques et dispose d’une configuration adéquate pour assurer un fonctionnement optimal

La mise en place d’un cluster étant toujours déterminé par un besoin de haute disponibilité, la mise en place de ces nouveaux critères de supportabilité apportent une assurance plus importante sur ces plateformes critiques.

De plus, un cluster est énormément dépendant des composants tiers qui sont mis en oeuvre pour le faire fonctionner : SAN, cartes réseau, drivers de carte HBA, etc… Comme Microsoft n’est pas maître pour le développement de ces parties, nous nous devions d’offrir cette garantie supplémentaire.

Concrètement, qu’apporte cette nouvelle stratégie de support ?

Auparavant, par le biais de la HCL (Hardware Compatibility List), les constructeurs proposaient des “solutions” cluster, autrement dit des packages en bon français. L’ensemble était validé par chaque constructeur suivant les préconnisations de Microsoft.

Désormais, le niveau de validation n’est plus au niveau du cluster mais du composant. Il est donc possible de choisir des composants disparates pour construire son cluster. Tant que ces éléments disposent du logo “Certfied for Windows Server 2008”…

En allant plus loin, il est possible d’installer un cluster Windows Server 2008 avec des serveurs de marques différentes même s’il est toujours recommandé de garder une configuration homogène.

Pour trouver des composants certifiés : Windows Server Catalog (en Anglais)

Une fois remplis le critère de la qualification des éléments qui formeront un cluster, Validate apporte un avantage important par rapport à Windows Server 2003 consistant à s’assurer du fonctionnement du cluster et de tous les composants impliqués dans son fonctionnement avant son installation.

Pour avoir un point de comparaison, jusqu’à Windows Server 2003 lorsque l’on planifait la mise en place d’un cluster MSCS, la seule façon de savoir si un cluster fonctionnerait correctement était de créer ce cluster (avec tous les problèmes potentiels à résoudre pendant l’installation) puis de le tester en forçant des bascules de groupes et de ressources.

Depuis Windows Server 2008, en utilisant Validate, il est possible de vérifier avant la création du cluster si la plateforme matérielle et logicielle sélectionnée fonctionnera de manière optimale.

Principalement, cet outil permet d’identifier les problèmes de configuration réseau (adressage, connectivité, …) et stockage (zoning, pré-requis SCSI, …) de manière proactive et d’y remédier avant l’installation du cluster.

Si le rapport de validation ne présente que des feux vert alors le cluster fonctionnera de manière optimale.

Autrement, il faudra traiter les erreurs remontées. A ce sujet, chaque erreur identifiée est accompagnée de commentaires permettant d’en identitifer la cause.

Validate est un assistant de diagostic visant donc deux objectifs principaux :

Valider le fonctionnement de la “feature” Failover Clustering
Assurer le respect des critères “opérationnels” de la supportabilité du cluster

Validate, meilleures pratiques

Pour garantir la supportabilité d’un cluster dans le temps, il est recommandé (sinon requis) d’exécuter Validate à chaque fois qu’un changement est apporté au cluster (ajout d’un noeud, changement d’une carte HBA, …).

Les scénarios pour lesquels il est recommandé d’exécuter Validate sont identifiés ici : Understanding the validation tests required for your scenario (TechNet, en Anglais)

Au delà de la supportabilité, Validate peut également être utilisé pour diagnostiquer d’éventuels dysfonctionnement.

Grâce au rapport généré par cet outil, il peut être possible de mettre le doigt sur un problème de configuration qui permettra de corriger ce problème.

Ressources

Failover Cluster Step-by-Step Guide: Validating Hardware for a Failover Cluster (TechNet, en Anglais)

KB943984 - The Microsoft Support Policy for Windows Server 2008 Failover Clusters (en Anglais)

Windows Server Catalog (en Anglais)

Failover Cluster Configuration Program (en Anglais)

Guillaume

Windows Core Support Escalation Engineer

Le cluster logging sous Windows Server 2008

GuillaumeD — Thu, 11 Jun 2009 00:24:00 GMT

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 :

Session	Fichier .ETL	Démarrage du noeud	Arrêt du noeud	Atteinte de la taille maximale	Perte
#1	clusterLog.etl.001	10/06	13/06	Non	Aucune
#2	clusterLog.etl.002	13/06	17/06	15/06	Evènements du 14/06
#3	clusterLog.etl.003	17/06	22/06	19/06	Evènements du 18/06

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

Disk Arbitration et Persistent Reservations

GuillaumeD — Mon, 01 Jun 2009 22:39:27 GMT

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 :

Le noeud qui détient le disque envoie une commande SCSI Reserve toutes les 3 secondes
Le noeud qui veut s’approprier le disque envoie une commande SCSI Reset toutes les 10 secondes

3 secondes pour que le propriétaire renouvele sa réservation et 2 secondes pour que le bus se réinitialise
x2 pour donner au propriétaire deux chances de renouveler son bail

Le noeud qui détient le disque continue d’envoyer ses commandes SCSI Reserve prouvant sa bonne santé
La tentative d’appropriation par le challenger échoue donc

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

Le noeud qui détient le disque envoie une commande SCSI Reserve toutes les 3 secondes
Le noeud qui veut s’approprier le disque envoie une commande SCSI Reset toutes les 10 secondes
Le noeud qui détient le disque n’envoie plus de commandes SCSI Reserve impliquant une défaillance
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 :

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
Le noeud qui veut s’approprier le disque envoie une demande d’enregistrement et une demande de réservation toutes les 6 secondes

La demande d’enregistrement va s’effectuer
La demande de réservation va échouer car il y a déjà une clé dans la table des réservations

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

Ce noeud s’aperçoit qu’il existe une nouvelle entrée dans la table des enregistrements
Il supprime les informations qui ne le concerne pas dans la table des enregistrements

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

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 :

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
Le noeud qui veut s’approprier le disque envoie une demande d’enregistrement et une demande de réservation toutes les 6 secondes

La demande d’enregistrement va s’effectuer
La demande de réservation va échouer car il y a déjç une clé dans la table des réservations

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

Ce noeud ne s’aperçoit donc pas qu’il existe une nouvelle entrée dans la table des enregistrements
Et il ne supprime pas les informations qui ne le concerne pas dans la table des enregistrements

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

Cette tentative réussie car ce noeud dispose de son entrée dans la table des enregistrements
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

Le quorum et le cluster

GuillaumeD — Mon, 30 Mar 2009 15:31:00 GMT

Le rôle du quorum au sein d’un cluster est souvent mal compris et peut mener à la mise en place d’une configuration éronée, surtout avec Windows Server 2008 où un nouveau modèle est disponible.

Tout d’abord, la définition du quorum dans son sens commun (Définition d’un quorum) :

“ En droit, le quorum est le nombre minimum de membres d'un corps délibératif nécessaire à la validité d'une décision. C'est souvent la moitié des membres, mais beaucoup d'entités ont un prérequis plus bas ou plus haut.

Lorsque le quorum n'est pas atteint, le corps délibératif ne peut pas tenir de vote et ne peut pas changer le statu quo. Ainsi, les votants en faveur du statu quo peuvent bloquer une décision en ne se présentant pas au vote. Le vote sera alors automatiquement rejeté et le statu quo conservé.

Dans un corps législatif, le quorum est habituellement la majorité des membres de l'entité y compris les postes vacants. Bien des corps ne prennent pas en compte le quorum à moins qu'une question ait été soumise à l'ordre du jour (par exemple un amendement). “

Il faut donc retenir les notions de “votants” et de “majorité” pour bien comprendre le rôle du quorum au sein du cluster.

Qu’est-ce que le quorum et a quoi sert-il ?

Il est fréquent de voir appeler “quorum” le disque utilisé pour stocker la configuration du cluster. C’est en partie vrai.

Dans un cluster configuré avec un disque quorum, ce disque joue le rôle d’arbitre.

Dans un cluster sans dique quorum, le quorum au sein d’un cluster représente l’ensemble des votants permettant d’assurer la continuité de fonctionnement du service cluster et la cohérence ce celui-ci. Je développe plus tard cet aspect de continuité de fonctionnement.

Une nuance cependant, avec Windows Server 2008, un modèle de quorum inclut le disque quorum comme votant.

En ce qui concerne son utilité, le quorum a trois rôles très simples :

Fournir un moyen d’arbitrer l’appartenance au cluster

Lors du démarrage d’un noeud, celui-ci utilise une copie de la configuration du cluster présent en local pour identifier les autres membres du cluster. Un mécanisme de sponsoring permet alors au noeud en cours de démarrage de se joindre ou non au cluster. Si ce serveur est sponsorisé par un noeud déjà démarré et si le cluster est fonctionnel, alors il récupère une copie récente de la configuration du cluster (on appelle cette action un JOIN).
Aider à maintenir la cohérence du cluster

C’est le rôle le plus important du quorum. Dans un scenario de split-brain, le quorum est utilisé pour garantir que les ressources partagées ne soient montées que sur un seul noeud. Le quorum est utilisé comme un tie-breaker dans ce scénario. Voir plus bas ce qu’est un split-brain.
Fournir un moyen de stocker la configuration du cluster

Au sein d’un cluster, chaque noeud doit disposer d’une vue consistante de la configuration du cluster. Cela est rendu possible par la mise à disposition par le quorum de la configuration du cluster stockée dans le quorum log.

Qu’est-ce que le quorum log ?

Le quorum log est une base de données contenant la configuration du cluster :

Les serveurs faisant parti du cluster
Les ressources installées et partagées
L’état des ressources partagées

Le quorum log est stocké par défaut dans \MSCS\quolog.log.

Qu’est-ce qu’un split-brain ?

Mot à mot, l’expression “split-brain” peut se traduire par “cerveau-scindé”. Hum… pas encore tout à fait clair…

Imaginons que le cluster soit un corps humain et que les membres du cluster (les noeuds) soient les lobes du cerveau.

Imaginons que ces lobes ne communiquent plus. On peut s’attendre à ce que le corps ne réagisse plus vraiment correctement, les ordres venant distinctement des deux lobes qui ne se synchronisent plus, et menant donc à quelque catastrophe…

Dans le cas d’un cluster, un split-brain intervient lorsque les liens réseau entre deux ou plusieurs noeuds subissent une défaillance. Le cluster est alors scindé en une ou plusieurs partitions qui ne peuvent plus communiquer entre elles.

Dans ce cas de figure, la partition détenant le quorum (le noeud 1 dans cet exemple) est seule autorisée à continuer à fonctionner. La seconde partition (le noeud 2) devra s’arrêter.

Le but de ce fonctionnement ? Eviter que plusieurs noeuds ne pouvant plus se “concerter” effectuent des opérations sur les ressources partagées menant à une inconsistence du service en cluster.

Exemple : un cluster Exchange est hébergé dans un cluster 2 noeuds. Le noeud 1 détient le quorum, le noeud 2 détient les ressources Exchange (les bases de données).

Si le noeud 2 vient à perdre la communication avec le noeud 1 alors le noeud 2 va tenter de prendre l’ownership sur le quorum. S’il n’y parvient pas, le service cluster sur le noeud 2 va s’arrêter de lui-même car il va se considérer en mauvaise santé et donc incapable d’assurer son rôle.
Le noeud 1 tentera alors de récupérer les ressources détenues par le noeud 2 et les remettres en service.
Si le noeud 2 parvient à prendre l’ownership du quorum, alors c’est que le noeud 1 subit une défaillance. C’est alors le noeud 1 qui, s’il n’est pas déjà arrêté ou hors d’état de fonctionner, qui va arrêter le service cluster.
Enfin, si ni le noeud 1 ni le noeud 2 ne parviennent à prendre l’ownership du quorum, alors le cluster est arrêté sur les deux noeuds.

Ces opérations visent à laisser la ressource en cluster sur un seul noeud. On ne peut avoir deux instances du même service fonctionner sur un réseau.

Vous me direz : mais pourquoi un noeud s’arrête t’il de lui-même si c’est le réseau qui a un problème ? Et bien, le noeud n’en sait rien. Il agit de manière proactive en constatant qu’il ne détient pas le quorum.

Et après tout, un problème réseau peut être causé par une défaillance de la carte réseau, d’un changement de configuration IP, sous Windows Server 2003 le service RPC ne répond plus, …

Bien sûr la réalité est un peu plus compliquée, il y a d’autres mécanismes que je n’ai pas détaillé ici qui entrent en jeu et qui complexifient la donne. Mais le principe est là.

Par exemple le cas où le cluster met en oeuvre plus de 2 noeuds. Dans ce cas, la notion de majorité est encore plus forte. La partition détenant le plus de votants est maintenue.

Les modèles de quorum

Disk Only

Dans ce modèle, seul le disque partagé dit “quorum” dispose d’un vote. Je lui attribue plutôt un rôle d’arbitrage.

Le cluster continue de fonctionner si au moins un noeud accède au disque quorum.

Cette configuration n’est généralement pas recommandée sous Windows Server 2008 et si ce modèle est toujours disponible, c’est… pour les nostalgiques !

Disk and Node Majority

Ce modèle a été intorduit avec Windows Server 2008. Le cluster dispose de trois votants : les deux noeuds et le disque quorum.

Le cluster continue de fonctionner si au moins deux votants sont fonctionnels.

Node Majority

Ce modèle de quorum entre en jeu lorsque le cluster est composé d’au moins trois noeuds et sans stockage partagé.

Pour que le cluster continue de fonctionner, il est nécessaire d’avoir une majorité de votants fonctionnels.

Node and File Share Majority

Le dernier modèle de quorum est implémenté lorsque qu’il n’y a pas de stockage partagé.

Il s’appuie sur les votants (les noeuds du cluster) et un témoin (un partage sur un serveur qui n’est pas un noeud).

Le cluster continue de fonctionner si la majorité des votants ET le témoin sont fonctionnels.

Le cas particulier du quorum sans disque partagé

Dans les configurations Node Majority et Node and File Share Majority, la configuration du quorum est stockée sur chaque noeud du cluster sur le disque système.

La consistence du réplica (le quorum log) sur tous les noeuds est assurée par le témoin (le File Share Witness) ou pas le cluster lui-même qui détermine qu’une modification est considérée comme permanente dès lors que cette configuration est présente sur la moitié des noeuds.

Comment choisir le modèle de quorum adéquat

Deux éléments sont à prendre en compte pour choisir le modèle de quorum :

La présence ou non de stockage partagé : SAN ou iSCSI / cluster local ou géographique
Le nombre de noeuds défaillants tolérés avant arrêt total du cluster

1ère étape : choix en fonction du stockage et de la répartition des noeuds

Disk Only

Disk and Node Majority

Node Majority

Node and File Share Majority

Avec stockage partagé
X

X

Sans stockage partagé

X

X

Cluster local
X

X

X

X

Cluster géographique

X

X

2nde étape : choix en fonction de la tolérance aux défaillances (sans stockage partagé ni File Share Witness)

Nombre de noeuds (N)

Nombre de votants (V)

Tolérance aux défaillances : (V-1)/2

2

2

0

3

3

1

4

4

1

5

5

2

6

6

2

7

7

3

8

8

3

3ème étape : choix en fonction de la tolérance aux défaillances (avec stockage partagé ou File Share Witness)

Nombre de noeuds (N)

Nombre de votants (V)

Tolérance aux défaillances : (V-1)/2

2

3

1

3

4

1

4

5

2

5

6

2

6

7

3

7

8

3

8

9

4

Le piège a éviter

Prenons le cas d’un cluster Exchange sept noeuds configuré suivant le modèle Disk and Node Majority.

Sur ce cluster, quatre instances d’Exchange sont actives et trois noeuds sont passifs.

Si vous avez bien suivi, et si j’ai été clair, combien de votants peuvent subir une défaillance sans que cela n’impacte :

Les quatre instances actives ?
Le cluster dans son ensemble ?

La réponse à la première question est : les quatre instances Exchange restent fonctionnelles tant qu’un maximum de trois votants subissent une défaillance

La réponse à la seconde est : le cluster dans son ensemble reste fonctionnel tant qu’un maximum de trois votants subissent une défaillance

Jusque là tout va bien… mais en allant un peu plus loin, on peut dire que cette configuration amène un risque.

Pourquoi ? Il suffit qu’un votant supplémentaire subisse une défaillance pour que le cluster dans son ensemble ne fournisse plus le service qu’on attend de lui.

Et en l’occurence le risque vient du disque quorum. Si ce disque vient aussi à subir une défaillance alors la majorité n’est pas atteinte au sein du cluster. Le service cluster sera donc arrêté sur les noeuds fonctionnels afin d’éviter une inconsistance sinon de plus graves dommages au niveau du cluster et surtout de l'application en cluster.

Que faut-il tirer de cet exemple ?

Une recommandation très simple : toujours avoir un nombre impair de votants.

Conclusion

En définitive, la configuration du quorum dépend d’un certain nombre de facteurs dont le plus important est celui visant à déterminer le nombre de défaillances tolérées.

Dans la pratique, sur des clusters mettant en oeuvre plus de deux noeuds, une stratégie de secours doit être définie pour palier à la loi de Murphy. Cette stratégie s’inclut dans un plan de DRP (Disaster Recovery Plan) et la plupart du temps, implique la présence d’un cluster de secours ou tout au moins de procédures visant à remettre en service l’application en cluster le plus rapidement possible.

Ressources

Quelques ressources en anglais (les traductions restent parfois aléatoires) :

Failover Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster

Understanding Quorum Configurations in a Failover Cluster

Details of How Quorum Works in a Failover Cluster

Additional Information About Quorum Modes

Quorum resource

Troubleshooting Quorum Resource Problems

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

Guillaume

Windows Core Support Escalation Engineer

Nombre de noeuds (N)	Nombre de votants (V)	Tolérance aux défaillances : (V-1)/2
2	2	0
3	3	1
4	4	1
5	5	2
6	6	2
7	7	3
8	8	3