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