Incohérences entre OCR et profil GPnP

Le profil GPnP (Grid Plug and Play) est l’une des nombreuses nouveautés de la couche Grid infrastructure 11gR2 (anciennement nommée clusterware en version 10g)  et qui permet entre autres de démarrer une instance ASM dont le spfile est lui aussi stocké dans l’ASM, ou un cluster dont les fichiers OCR et voting disks sont également stockés dans l’ASM.

Ce fichier profil  localisé dans $GRID_HOME/gpnp/<hostname>/profiles/peer/profile.xml contient toutes les informations permettant de démarrer l’infrastructure grid (localisation des fichiers OCR , voting disks, spfile de l’ASM, conf réseau, etc…), et doit toujours être en parfaite cohérence avec le contenu du fichier OLR (Oracle Local Registry) pour une instance ASM ou OLR/OCR (Oracle Cluster Registry) pour un RAC.
Si vous perdez cette cohérence, voilà ce qui risque de vous arriver : l’instance ASM ou le RAC ne démarre plus !!!

crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4529: Cluster Synchronization Services is online
CRS-4534: Cannot communicate with Event Manager

Cette perte de cohérence m’est déjà arrivé lors d’un upgrade de RAC, et au beau milieu d’un changement d’adresses IP sur le lien interconnect durant lequel un des nœuds a malheureusement rebooté !
Voici comment nous avons finalement réussi à redémarrer le cluster sans avoir à réinstaller le tout.
L’incohérence constatée dans notre cas concernait la configuration des cartes et adresses réseau privées, mais vous pouvez vous inspirer de la même procédure pour tout autre type d’incohérence (voir le détail des informations stockées dans le profil GPnP et modifiables par la commande  » gpnptool edit -? « ).
Créons un répertoire de travail que nous nommerons GPNPDIR, et stockons y le contenu courant du profil GPnP.

mkdir /tmp/gpnp
export GPNPDIR=/tmp/gpnp
gpnptool get -o=$GPNPDIR/profile.xml
Resulting profile written to "/tmp/gpnp/profile.xml".
Success.
cp $GPNPDIR/profile.xml $GPNPDIR/newprofile.xml  <-- pour garder une trace du profil d'origine.

Retirons toutes traces de signatures qui auraient pu être altérées lors de l’incident rencontré.

gpnptool unsign -p=$GPNPDIR/newprofile.xml -o=$GPNPDIR/newprofile.xml -ovr

Récupérons le dernier numéro de séquence associé au profil (qui servira par la suite, lors de la génération du nouveau profil) ainsi que le nom des interfaces réseau utilisées en exécutant les commandes suivantes :

gpnptool getpval -p=$GPNPDIR/newprofile.xml -prf_sq -o-
40          <-- récupérér ce numéro de séquence
gpnptool getpval -p=$GPNPDIR/newprofile.xml -net -o-
net0 net2    <-- récupérer les n° de réseau correspondant aux interfaces publiques et privées
                 du cluster

Maintenant corrigeons le fichier profil GPnP newprofile.xml pour qu’il contienne les bonnes informations (dans notre cas les bonnes adresses IP).

vi $GPNPDIR/newprofile.xml
<gpnp:Network-Profile><gpnp:HostNetwork id="gen" HostName="*"><gpnp:Network id="net0" Adapter="eth0" IP="10.103.9.0" Use="public"/><gpnp:Network id="net2" Adapter="bond0" IP="192.168.100.0" Use="cluster_interconnect"/></gpnp:HostNetwork></gpnp:Network-Profile>

Générons ensuite le fichier profil fraichement modifié en y incluant les signatures qui vont bien (notez bien l’incrémentation du numéro de séquence : 40 –> 41).

gpnptool edit -p=$GPNPDIR/newprofile.xml -o=$GPNPDIR/newprofile.xml -ovr -prf_sq=41 -net0:net_use=public -net2:net_use=cluster_interconnect
Resulting profile written to "/tmp/gpnp/newprofile.xml".
Success.
gpnptool sign -p=$GPNPDIR/newprofile.xml -w=firofile:/HOME/grid/gpnp/`hostname`/wallets/peer/ -o=$GPNPDIR/newprofile.xml -ovr
Resulting profile written to "/tmp/gpnp/newprofile.xml".
Success.

Il ne nous reste plus qu’à placer ce nouveau fichier profil dans son répertoire habituel comme ceci :

gpnptool put -p=$GPNPDIR/newprofile.xml
Success.

puis démarrer les process de l’infrastructure grid comme celà ..

crsctl start res ora.crsd -init
CRS-2672: Attempting to start 'ora.ctssd' on 'bdb01'
CRS-2676: Start of 'ora.ctssd' on 'bdb01' succeeded
CRS-2672: Attempting to start 'ora.evmd' on 'db01'
CRS-2676: Start of 'ora.evmd' on 'bdb01' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'bdb01'
CRS-2676: Start of 'ora.asm' on 'bdb01' succeeded
CRS-2672: Attempting to start 'ora.crsd' on 'bdb01'
CRS-2676: Start of 'ora.crsd' on 'bdb01' succeeded

Le cluster est bien reparti et tous les process sont maintenant actifs !

crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online