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
- 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 ?
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:Les 2 sections ci-dessous détaillent comment changer
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 avecgpnptool 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.
asm_diskstring et les devices réseaux dans cette configurationChangement de asm_diskstring
Il y a plusieurs scénarios au cours desquels vous serez intéressés à changer le paramètreasm_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
- ...
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 commandeasmcmd dssetne 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
- 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
# ./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 :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...
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.
1 commentaire:
Comme d'habitude, super article. Je vais le garder dans un coin de ma tête.
Merci d'avoir décrypter un peu le mécanisme de démarrage de clusterware.
Enregistrer un commentaire