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

1. 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.
   
2. 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’
   
3. 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.
   
4. Si une ressource est supprimée, le Checkpoint est aussi supprimé mais pas les informations contenu dans le registre local.
   
5. 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