Cluster Checkpoint registry (Windows 2003)
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: https://technet2.microsoft.com/WindowsServer/en/library/4aa0be73-ef61-4f9c-a071-b390278b47731033.mspx?mfr=true
Checkpointing https://msdn2.microsoft.com/en-us/library/aa367195.aspx
ClusterRecovery tool: https://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
https://support.microsoft.com/default.aspx?scid=kb;EN-US;307469
174070 Registry replication in Microsoft Cluster Server
https://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 NoneCluster 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