Voting Disk corrompu et... aucune sauvegarde!

Suite à un "downgrade" du clusterware 11gR2 à la version 10gR2 (10.2.0.4), nous n'avons pas réussi à redémarrer le CRS correctement. Après quelques investigations dans les différents fichiers de trace (.log), j'ai alors remarqué le message suivant dans le fichier "cssd.log"

ERROR:   clssnmvReadFatal: voting device corrupt (0x00000000/0x00000000/0//dev/vd1_sys_1g)

Pour remédier à ce problème, nous avons du recréer le "voting disk" car nous n'avions aucune sauvegarde à notre disposition ni de mirroring... chose à ne pas faire.

Voici les étapes effectuées. Ceci a été effectué sur une plate-forme AIX dont les produits Oracle étaient de la version 10gR2 (10.2.0.4)

• Arrêt complet du clusterware

Dans notre cas, la commande "crsctl stop crs" ne fonctionnait pas alors nous avons désactivé le démarrage automatique (init.crs disable) puis redémarrer chacun des noeuds.

• Ajout d'un nouveau raw device

L'administrateur de système nous a alloué un nouveau disque d'une capacité d'un gigaoctet.

• Afficher le voting disk actuel

#crsctl query css votedisk

Cette commande nous a retourné le nom complet du voting disk (ex. /dev/vd1_sys_1g)

• Ajouter un voting disk en précisant l'emplacement exact

# crsctl add css votedisk [/chemin/nom] -force

Ex. # crsctl add css votedisk /dev/vd1_sys_2g -force

• Détruire le voting disk corrompu en spécifiant le chemin complet

# crsctl delete css votedisk [/chemin/nom] -force

Ex. # crsctl delete css votedisk /dev/vd1_sys_1g -force

• Redémarrer le cluster

# crsctl start crs

• Vérifier le nouveau voting disk

# crsctl query css votedisk

Suite à toutes ces étapes, nous nous sommes empressé de recommander la mise en place d'une sauvegarde du voting disk dans la procédure de sauvegarde existante et, de créer au minimum un second voting disk.

Statut inconnu (UNKNOWN) de l'instance ASM sous RAC

Voici une situation vécue avec une instance ASM 10g (10.2.0.4) dans un environnement Oracle Real Application Cluster (RAC) 10gR2 sur la plateforme IBM AIX 64 bits.

Le statut de l'instance ASM est devenu "UNKNOWN" et celles des bases de données hébergées sur le même noeud sont OFFLINE. Que se passe-t-il ?

Afin de comprendre, je me suis dirigé vers les fichiers de trace sous l'ORACLE_HOME d'Oracle ASM situé à l'emplacement suivant puis vérifier le contenu du fichier "ora.noeud01.ASM1.asm.log" :

$ cd /opt/oracle/product/asm10g/log/noeud01/racg
$ vi ora.noeud01.ASM1.asm.log (writing error)

Le fichier de trace contenait l'erreur suivante :

RACG][1] [905406][1][ora.noeud01.ASM1.asm]: CLSR-0006: Error encountered when writing file /opt/oracle/product/crs10g/racg/tmp/ora.noeud01.ASM1.asm.ora

Je me suis alors déplacé vers le répertoire "/opt/oracle/product/crs10g/racg/tmp" pour vérifier les fichiers présents et leurs permissions.

$ cd /opt/oracle/product/crs10g/racg/tmp
$ ls -al

Voyant que tout semblait correct et que rien n'attirait mon attention, j'ai prit la décision de déplacer tous les fichiers de ce répertoire vers un autre répertoire dans le but de laisser Oracle les recréer au besoin :

# mkdir -p /tmp/backup
# mv * /tmp/backup

Suite au déplacement, j'ai redémarré le CRS puis revérifier graduellement le statut de chacune des composantes :

# crsctl stop crs
# crsctl start crs
# crsctl check crs
# crs_stat.sh

Toutes les composantes ont redémarrées correctement. Maintenant, je dois investiguer pour comprendre ce qu'il s'est réellement passé.

Modifier l'information réseau contenu dans l'OCR

Si vous obtenez les messages :

PRVG-1513 : Failed to retrieve current selection of public and private network classifications for node
PRVG-11050 : No matching interfaces "" for subnet "" on nodes "racnode1"

Il est fort possible que l'information contenu dans l'OCR ne soit pas correcte. Pour remédier à cela, vous devrez procéder comme suit pour vérifier les interfaces définis dans l'OCR puis de la redéfinir selon votre cas.

voici un exemple :

• Afficher les interfaces présents sur le noeud

$ oifcfg iflist -p -n
en3  10.2.2.0  UNKNOWN  255.255.255.0
en0  10.25.9.0  PRIVATE  255.255.255.0

• Afficher les interfaces définis par la commande "setif"

$ oifcfg getif
en0  10.25.9.0  global  public
en3  10.2.1.0  global  cluster_interconnect

En comparant les adresses IP des interfaces, on remarque qu'un d'elle est incorrecte (10.2.1.0). On doit supprimé cette entrée pour la réinsérer avec la bonne adresse IP (10.2.2.0) :

$ oifcfg delif -global en3

$ oifcfg setif -global en3/10.2.2.0:cluster_interconnect

L'interface de configuration "OIFCFG" permet de définir et de gérer les interfaces réseau. Il permet d'allouer et libérer les interfaces réseaux,d'utiliser des interfaces réseau spécifiques et obtenir des informations de configuration des composant.De plus, vous pouvez utiliser "OIFCFG" sur une instance unique et des environnements impliquant Oracle Clusterware.

Configuration des interfaces de l'interconnect

Lors de la vérification de la configuration d'un cluster existant de la version 10gR2 (runcluvfy.sh) en prévision de le mettre à niveau à la version 11gR2 (11.2.0.3), nous avions reçu le message suivant :

WARNING:
Could not find a suitable set of interfaces for the private interconnect
Checking subnet mask consistency...
Subnet mask consistency check passed for subnet "10.2.190.0".
PRVG-11055 : Interfaces configured with subnet number "192.168.2.0" have multiple subnets masks
PRVG-11056 : subnet masks "255.255.255.0" are configured with subnet number "192.168.2.0" on nodes "qaora05t"
PRVG-11056 : subnet masks "255.255.255.224" are configured with subnet number "192.168.2.0" on nodes "qaora06t"
Subnet mask consistency check failed.

Result: Node connectivity check failed

Nous avons dû modifier le "netmask" au niveau du serveur "srvbd02" pour qu'il soit identique sur les 2  noeuds (serveurs) du cluster, voici les étapes réalisées :

$oifcfg iflist -p -n
en2  10.2.190.0  PRIVATE  255.255.255.0
en4  192.168.2.0  PRIVATE  255.255.255.0

#ifconfig en4
en4: flags=1e080863,c0
        inet 192.168.2.14 netmask 0xfffffe00 broadcast 192.168.2.31
         tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0

Le "netmask" qui est égale à "0xffffffe0" doit être modifié pour être "0xffffff00" :

#chdev -l en4 -a netaddr=192.168.2.14 -a netmask=0xffffff00

#ifconfig en4
en4: flags=1e080863,c0
        inet 192.168.2.14 netmask 0xffffff00 broadcast 192.168.2.255
         tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0

Suite à ce changement, le « cluster verify » à passer sans erreur.


Ce cluster était sur une plateforme IBM AIX 5.3 64bits.

Un merci tout spécial à mon collègue Nabil Ben Tekaya. Grâce à ses yeux de lynx, il a remarqué la différence au niveau des masques réseau.

INS-40406 avec Oracle Universal Installer

Lors d'une tentative de migration d'Oracle Clusterware de 10g à la version 11gR2, nous avons rencontré l'erreur INS-40406. Le programme d'installation ne voyait pas la présence d'un cluster.

Suite à plusieurs recherches, nous avons remarqué qu'il manquait le paramètre : CRS="true" dans le fichier "inventory.xml" vis-à-vis la balise correspondant à l'ORACLE_HOME du cluster.

Après avoir ajouter le paramètre, le programme d'installation a reconnu le cluster.

Exemple : CRS="true"

Oracle Clusterware 11gR2

Oracle Clusterware est la composante majeure d’Oracle Grid Infrastructure et constitue la base d’Oracle Real Application Cluster (RAC). Oracle Clusterware permet de former un groupe de serveurs et de les faire fonctionner comme un seul système. Il permet de gérer l’ensemble des ressources, des processus et des applications du cluster tout en gérant et assurant la stabilité des nœuds.

Oracle Clusterware est composé principalement de deux éléments : le « voting disk » et l'OCR (Oracle Cluster Registry). Le « voting disk » est tout simplement un fichier qui contient et gère les informations de tous les nœuds liés au cluster et, l'OCR est un fichier qui gère le cluster et configuration RAC.

Depuis la version 11g Release 2, les fichiers de l’OCR et des voting disks peuvent maintenant être stockés dans ASM. D’ailleurs, cette façon de faire est conseillée par Oracle.
Dans les versions antérieures, la sauvegarde des « voting disks » en utilisant la commande « dd » était une tâche nécessaire suite à l’installation. Avec Oracle Clusterware 11gR2, la sauvegarde et la restauration d'un « voting disk » en utilisant la commande « dd » n'est plus supportée ni requise car ils sont sauvegardés automatiquement dans l’Oracle Cluster Registry (OCR) dès qu’un changement de configuration se produit. De plus, les données d’un « voting disks » sont automatiquement restaurées et appliquées sur un disque nouvellement ajouté.

Nouveautés intéressantes avec Clusterware 11gR2

Server Pool

• Division logique du cluster en pools de serveurs.
• Regroupement de serveurs ayant une charge similaire
• Gérer avec les outils crsctl (applications) et srvctl (Oracle)
• Définit par 3 principaux attributs (min, max, importance) ou une liste prédéfinie des nœuds
• Utilisation de règles (policies) pour contrôler l’utilisation du pool

Single Client Access Name (SCAN)

• Utilisé par les clients pour établir une connexion à n’importe quelle base de données du cluster
• Aucun changement nécessaire à la configuration de connexion d’un client advenant un changement au cluster
• Balancement de la charge parmi les instances desservit par un service
• Transparence lors d’un déplacement d’instance (failover)
• Permet aux clients d’utiliser une connexion de type « EZConnect » ou JDBC simple

Grid Plug and Play (GPnP)

• Simplifie l’ajout, le remplacement, et la suppression d’un noeud du cluster
• Permettre au cluster de gérer ses propres adresses IP virtuelles (Grid Naming Service)

Oracle Grid Infrastructure 11gR2

À partir d’Oracle 11g Release 2, Oracle Clusterware combiné à Oracle Automatic Storage Management (ASM) est devenu Oracle Grid Infrastructure.

Oracle Grid Infrastructure peut être déployé autant pour un environnement à multiples instances que simple instance (stand alone).

Pour les bases de données à simple instance, Oracle Grid Infrastructure permet de mettre en place une infrastructure légère de haute disponibilité. Cette option inclut deux composantes : Oracle Restart et Oracle ASM.

Pour les bases de données à multiple instance (RAC), Oracle Grid Infrastructure permet de mettre en place une réelle infrastructure de haute disponibilité regroupant plusieurs serveurs. Cette option inclut deux composantes : Oracle Clusterware et Oracle ASM.