Aucun message portant le libellé VOTING DISK. Afficher tous les messages
Aucun message portant le libellé VOTING DISK. Afficher tous les messages

mardi 18 septembre 2012

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.

jeudi 14 janvier 2010

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)