Il y a quelque-chose que j’aime beaucoup dans l’Infrastructure Grid d’Oracle 11.2. L’OCR qui contient les informations de configuration du cluster est stockée dans ASM, lequel a besoin de ces informations de configuration pour démarrer… Vous me direz « Rien de neuf ! ». Déjà en 10.1, l’OCR est géré par CRSD, lequel a besoin du processus CSSD pour démarrer…

Si vous aimez les parallèles, commençons par un petit rappel de fonctionnement du clusterware 10.1, 10.2 et 11.1 :

• OCSSD utilise ocr.loc pour trouver le fichier d’OCR
• Il lit cet OCR, pendant sa phase de démarrage, pour localiser les fichiers de voting
• Il démarre et permet ainsi à CRSD de démarrer et de monter l’OCR en lecture/écriture

Simple, en fait ! Alors reprenons notre Infrastructure Grid 11.2 :

• OCSSD utilise ocr.loc pour trouver le fichier d’OCR
• Il trouve un nom de diskgroup, e.g. ‘+VOTING’ et…
• Comment fait-il pour trouver les disques qui correspondent à ‘+VOTING’ puisque l’information de découverte est stockée dans le paramètre asm_diskstring ?

Si vous avez un peu transpiré sur des sauvegardes/restauration de cette infrastructures, vous connaissez la réponse : l’information est mise à disposition par le service GridPnP lors du démarrage. GridPnP est une infrastructure distribuée et dynamique.

Autrement dit, vous pouvez accéder à cette information via gpnptool ou le fichier profile.xml du service, même lorsque le cluster est entièrement stoppé, comme ci-dessous :

./gpnptool get -o-
Cannot get GPnP profile. Error CLSGPNP_NO_DAEMON (GPNPD daemon is not running). 
GPnP service is not running on localhost. Found locally cached profile...
<?xml version="1.0" encoding="UTF-8"?>
<gpnp:GPnP-Profile xmlns="http://www.grid-pnp.org/2005/11/gpnp-profile" 
                   xmlns:gpnp="http://www.grid-pnp.org/2005/11/gpnp-profile" 
                   xmlns:orcl="http://www.oracle.com/gpnp/2005/11/gpnp-profile" 
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="1.0" 
                   xsi:schemaLocation="http://www.grid-pnp.org/2005/11/gpnp-profile gpnp-profile.xsd" 
                   ProfileSequence="17" ClusterUId="abcd" ClusterName="demo" PALocation="">
  <gpnp:Network-Profile>
    <gpnp:HostNetwork id="gen" HostName="*">
      <gpnp:Network id="net1" Adapter="bond0" IP="192.168.1.0" Use="public"/>
      <gpnp:Network id="net2" Adapter="bond1" IP="192.168.2.0" Use="cluster_interconnect"/>
    </gpnp:HostNetwork>
  </gpnp:Network-Profile>
  <orcl:CSS-Profile id="css" DiscoveryString="+asm" LeaseDuration="400"/>
  <orcl:ASM-Profile id="asm" DiscoveryString="ORCL:*" SPFile="+VOTING/demo/asmparameterfile/registry.253.782840057"/>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <ds:Reference URI="">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
            <InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="gpnp orcl xsi"/>
          </ds:Transform>
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <ds:DigestValue>YYYY=</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>XXX=</ds:SignatureValue>
  </ds:Signature>
</gpnp:GPnP-Profile>
Success.

Error CLSGPNP_NO_DAEMON getting profile.

La morale ici c’est que, en 11.2, quand vous faites des modifications notamment de la chaîne de découverte des disques, qui sont des informations stockées à plusieurs endroits, mais aussi du fichier spfile d’ASM et des devices réseaux, vous voudrez vous assurer que le profile du GridPnP est bien à jour.

Note:
Modifier directement le fichier de profile du GridPnP n’est pas supporté par Oracle et celui-ci est protégé par une signature basé sur le contenu du wallet. Evidemment vous pouvez vous amuser avec gpnptool unsign|sign. Cela dit, le plus simple est d’utiliser la procédure adéquate pour modifier le fichier de profile et de conserver une copie du fichier avant de faire les modifications pour éviter les déconvenues.

Les 2 sections ci-dessous détaillent comment changer asm_diskstring et les devices réseaux dans cette configuration

Changement de asm_diskstring

Il y a plusieurs scénarios au cours desquels vous serez intéressés à changer le paramètre asm_diskstring :

• Le passage d’ASMLib à un accès direct
• Le passage d’un device unique à un accès multipath via le device-mapper
• L’ajout d’une nouvelle baie
• L’ajout d’un fichier sur un stockage NFS pour un cluster étendu
• …

On peut distinguer l’ajout d’un chemin ou de la suppression d’un chemin qui n’est plus utilisé par ASM. Ces 2 opérations s’effectuent simplement à chaud. En revanche, la modification des chemins en cours d’utilisation et notamment du diskgroup qui contiennent l’OCR et voting, non seulement nécessite un arrêt redémarrage d’ASM mais surtout ne supporte pas toutes les méthodes de modification.

Cela dit, rien d’exceptionnel non plus, la commande ci-dessous non seulement modifie la configuration dans le fichier spfile d’ASM et dans le profil qui sera donné lors du prochain redémarrage de l’infrastructure Grid :

sqlplus / as sysasm
alter system 
   set asm_diskstring='/dev/mapper/friendly*' 
   scope=spfile;

Et cela fonctionne quelque soit le nombre de serveur du cluster démarré. Pour vous en persuader, vous pouvez utiliser la commande asmcmd dsget ; vous voyez ici que le profile est déjà démarré mais que ASM utilise toujours son ancien chemin comme paramètre d’instance et au prochaine redémarrage, ça ne sera plus le cas :

asmcmd dsget
parameter:ORCL:*
profile:/dev/mapper/friendly*

Note:
La commande asmcmd dsset ne permet pas, c’est là où je voulais en venir, de remplacer la chaine de découverte dans le fichier spfile sans le modifier en mémoire des instances ASM. En conséquence vous pouvez l’utiliser pour ajouter un chemin ou supprimer un chemin qui a été libéré mais pas remplacer un chemin qui existe encore comme dans le cas d’un passage d’ASMLib en mode non-ASMLib.

Modification des noms de device réseau

Plusieurs scénarios de maintenance aboutissent à la nécessité de modifier un nom de device réseau :

• le changement d’une carte sur certains systèmes pour une carte d’une autre marque, d’une autre technologie ou supportant un débit différent
• la mise en oeuvre d’une interface de bond ou d’un aggrégat de devices
• la suppression d’une interface de bond ou d’un aggrégat de devices

Dans toutes ces situations, vous devez utiliser la commande oifcfg comme dans les versions précédentes. Il existe désormais contraintes supplémentaires :

• tous les noeuds du cluster doivent être démarrés avec le service GridPNP actif
• vous ne pouvez plus avoir une configuration à laquelle vous auriez retiré un des réseaux

En revanche, vous pouvez ajouter un device qui n’existe pas encore à votre configuration. Vous pouvez également supprimer ceux qui existent pour effectuer la configuration syst
ème après la configuration du cluster. Voici ci-dessous un exemple de désactivation des interfaces de bond sous Linux ; notez que dans ce scénario les devices eth0 et eth1 qui seront utilisés au final existent mais ne sont pas capable de gérer le réseau en question du fait qu’elles sont encore esclave des interfaces bond :

# ./oifcfg getif
bond0  192.168.1.0  global  public
bond1  192.168.2.0  global  cluster_interconnect

# ./oifcfg delif -global bond1
PRIF-31: Failed to delete the specified network interface because it is the last private interface

# ./oifcfg setif -global eth1/192.168.2.0:cluster_interconnect
# ./oifcfg getif
bond0   192.168.1.0   global  public
bond1   192.168.2.0   global  cluster_interconnect
eth1   192.168.2.0   global  cluster_interconnect

# ./oifcfg delif -global bond1
# ./oifcfg setif -global eth0/192.168.1.0:public
# ./oifcfg delif -global bond0
# ./oifcfg getif
eth1   192.168.2.0   global  cluster_interconnect
eth0   192.168.1.0   global public

Note :
La configuration réseau est prise en compte, lors du démarrage des services. Il est donc important que votre configuration soit conforme à votre configuration GridPnP lors du démarrage. Dans le cas précédent, si vous oubliiez de supprimer les interfaces bond0, il faudrait que vous ayez à la fois les interfaces bond et eth lors du démarrage ! Autrement dit, si vous voulez redémarrer à chaque fois, n’hésitez pas à faire une sauvegarde du profile GridPNP et à conserver un plan de retour arrière.

Voilà, si vous vous posez des questions sur ces changements de configuration de l’infrastructure Grid, tout est possible mais pas forcément aussi simple que dans les versions précédentes ! Vous serez sans doute intéressé par toutes les notes de My Oracle Support et par l’utilisation de « rootcrs.pl » ; mais c’est déjà une autre histoire…