Restauration des OCR et Voting

Cet article explique comment restaurer les OCR et Voting dans l’environnement Grid infrastructure. L’OCR et les voting étant sur un même diskgroup comme dans une installation par défaut. Le diskgroup ici se nomme OCRVOT et est en normal redundacy sur 3 disques donc.

 Trois scénarii de perte partielle ou totale des disques de l’OCRVOT y sont décrits. Le premier explique comment réparer la perte d’un disque, le deuxième comment réparer la perte de 2 disques et le 3 ème la perte de 3 disques.

Cet article s’applique donc pour un diskgroup OCRVOT en mode normal redundacy. Cependant si le diskgroup est en external redundacy, la perte d’un disque implique la perte total du diskgroup et correspond donc au scénario : 3 disques de perdu. En revanche, si vous êtes un gros parano et avait choisi le mode High redundacy… débrouillez-vous !Tongue Out

 

Les manipulations ont été faites sur le banc RAC 11GR2. Vous pouvez donc faire tous les opérations décrites ci-dessous à la virgule prêt, si vous avez monté votre banc grâce à cet excellent tutorial Cool.

Précision pour ceux qui n'ont pas lu le tutorial précédemment cité : racdb1 et racdb2 nos 2 serveurs RAC, grid le compte propriétaire du Grid Infrascture

 

 Prérequis

Avant de commencer à casser, il faut s’assurer d’avoir le backup de ce que l’on va casser, logique non ?

Pour lister les backups:

[grid@racdb1 ~]$ ocrconfig -showbackup
racdb1     2013/02/10 21:42:27     /oracle/11.2.0.3/grid/cdata/racdb-cluster/backup00.ocr
racdb1     2013/02/10 17:42:26     /oracle/11.2.0.3/grid/cdata/racdb-cluster/backup01.ocr
racdb1     2013/02/10 17:42:26     /oracle/11.2.0.3/grid/cdata/racdb-cluster/day.ocr
racdb1     2013/02/10 17:42:26     /oracle/11.2.0.3/grid/cdata/racdb-cluster/week.ocr

Grid lance automatiquement les backups de l’OCR tous les 4 heures, mais visiblement ce banc n’a jamais été up pendant plus de 4 heures depuis le 2 février. (Quel gaspillage de ressource disque, 100Go de disque qui dorment !!! Il faut rationnaliser tout cela, il faut trancher dans le lard !!! Laughing).

 Nous lançons donc un petit backup manuel par précaution, au cas où il y aurait eu de modification du registre du cluster depuis.

[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/ocrconfig -manualbackup
racdb1     2013/04/20 20:44:48     /oracle/11.2.0.3/grid/cdata/racdb-cluster/backup_20130420_204448.ocr

Il peut être bon aussi de backuper le spfile de l’instance ASM. En effet en cas de perte du diskgroup OCRVOT, celui-ci est perdu et il n’est pas contenu dans le backup de l’OCR. Son backup n’est pas primordial, il peut être recréer facilement, mais il peut arriver de devoir le customiser, auquel cas, à moins d’avoir une bonne mémoire, la customisation sera perdu.

Sous ASM:

SQL> create pfile='/home/grid/initASM_BACKUP.ora' from spfile;

 

Bon quand il faut y aller, faut y aller…

Perte d'un disque

Nous allons corrompre un disque de l’ocr-voting, nous choisissons d’endommager l’OCRVOT3.

Au passage une astuce pour retrouver la correspondance entre le device linux et le disque ASM associé.

[grid@racdb1 ~]$ /etc/init.d/oracleasm querydisk -d OCRVOT3
Disk "OCRVOT3" is a valid ASM disk on device [8, 65]
[grid@racdb1 ~]$ more /proc/partitions |grep 65
   8       65    1044193 sde1
252        2   35651584 dm-2

La partition /dev/sde1 du disque /dev/sde est donc notre "disque à destroyer" Embarassed

Pour cela un petit dd

[root@racdb1 ~]$ dd if=/dev/zero of=/dev/sde1 bs=1M count=100

Vérifions que asmlib ne reconnait plus le disque OCRVOT:

[grid@racdb1 ~]$ /etc/init.d/oracleasm querydisk -d OCRVOT3
Disk "OCRVOT3" defines an unmarked device

Rebootons alors les serveurs racdb1, voir aussi racdb2. Tout redémarre bien comme si il n’y avait aucun problème !

Pour trouver une trace d’un problème, il faut éditer l’alert.log du cluster ($ORACLE_HOME/log/<hostname>/alert<hostname>.log) :

2013-04-18 21:14:19.517
[cssd(3059)]CRS-1604:CSSD voting file is offline: /dev/oracleasm/disks/OCRVOT3; details at (:CSSNM00069:) in /oracle/11.2.0.3/grid/log/racdb1/cssd/ocssd.log.

Dans l’alert.log de l’instance ASM nous pouvons voir aussi :

Thu Apr 18 21:14:17 2013
NOTE: PST enabling heartbeating (grp 1)
NOTE: PST enabling heartbeating (grp 3)
NOTE: PST enabling heartbeating (grp 2)
NOTE: cache closing disk 2 of grp 4: OCRVOT_0002
Thu Apr 18 21:14:19 2013
NOTE: Attempting voting file refresh on diskgroup OCRVOT
NOTE: Voting file relocation is required in diskgroup OCRVOT
NOTE: Attempting voting file relocation on diskgroup OCRVOT

Et effectivement un disque de voting à disparu:

[grid@racdb2 ~]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
1. ONLINE   1331634fde7d4f0bbf8ecbd8f5347205 (/dev/oracleasm/disks/OCRVOT1) [OCRVOT]
2. ONLINE   69baf93c03064f34bf52858994864fdc (/dev/oracleasm/disks/OCRVOT2) [OCRVOT]
Located 2 voting disk(s).

Il n’y a plus que 2 disques voting.

Mais si on check les OCR qui sont aussi dans +OCRVOT

 [root@racdb2 ~]# /oracle/11.2.0.3/grid/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
                 Version                  :          3
                 Total space (kbytes)     :     262120
                 Used space (kbytes)      :       2972
                 Available space (kbytes) :     259148
                 ID                       :  297893987
                 Device/File Name         :    +OCRVOT
                                    Device/File integrity check succeeded
                                    Device/File not configured
                                    Device/File not configured
                                    Device/File not configured
                                    Device/File not configured
                 Cluster registry integrity check succeeded
                 Logical corruption check succeeded

Tout va bien dans le meilleur des mondes. Undecided . C’est normal, la redundancy normal du diskgroup OCRVOT joue son rôle. L’OCR est mirroré donc il va bien.

Dans l’alert.log des instances ASM nous pouvons voir, qu’un disque a été droppé automatiquement:

NOTE: cache closing disk 2 of grp 4: (not open) _DROPPED_0002_OCRVOT
SUCCESS: refreshed membership for 4/0xa47861e0 (OCRVOT)
SUCCESS: alter diskgroup OCRVOT drop disk OCRVOT_0002 force /* ASM SERVER */
NOTE: starting rebalance of group 4/0xa47861e0 (OCRVOT) at power 1
Starting background process ARB0
SUCCESS: PST-initiated drop disk in group 4(2759352800))

 

Ré-instancions le disque OCRVOT3:

[root@racdb1 ~]# /usr/sbin/oracleasm createdisk ocrvot3 /dev/sde1
Writing disk header: done
Instantiating disk: done

[root@racdb1 ~]# /usr/sbin/oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...

[root@racdb1 ~]# /usr/sbin/oracleasm listdisks
DATA1_1
DATA1_2
DATA2_1
DATA2_2
FRA1
FRA2
OCRVOT1
OCRVOT2
OCRVOT3

N’oublions sur le deuxième noeud de refaire un scan des disques, pour recharger l’OCRVOT3

[root@racdb2 ~]# /usr/sbin/oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...

 

Ensuite il faut remettre l’OCRVOT3 dans le diskgroup OCRVOT, 2 solutions :

 -          La graphique :

Sous le compte grid, lançons asmca, puis suivons les captures d’écran ci-dessous:

 

 

-          Ou bien à la ligne de commande, réservé au pur et dur, au vrai DBACool.

[grid@racdb2 trace]$ export ORACLE_SID=+ASM2
[grid@racdb2 trace]$ sqlplus / as sysasm
SQL> ALTER DISKGROUP OCRVOT ADD  DISK '/dev/oracleasm/disks/OCRVOT3';

 

Et voilà, tout est bien qui fini bien, tout est réparé. Pour l’OCR cela a été transparent, c’est comme si il n’y avait jamais eu de problème.

Pour les VOTING, le troisième voting est remonté, suite à l’ajout du disque OCRVOT3 :

 [grid@racdb2 trace]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
1. ONLINE   1331634fde7d4f0bbf8ecbd8f5347205 (/dev/oracleasm/disks/OCRVOT1) [OCRVOT]
2. ONLINE   69baf93c03064f34bf52858994864fdc (/dev/oracleasm/disks/OCRVOT2) [OCRVOT]
3. ONLINE   7d732989a15c4f73bfe76276264fbac1 (/dev/oracleasm/disks/OCRVOT3) [OCRVOT]
Located 3 voting disk(s).

La vie est belle!

 

Perte de deux disques

Comme précédemment on identifie nos disques à corrompre. Ici OCRVOT2 et OCRVOT3.

 [root@racdb2 trace]dd if=/dev/zero of=/dev/sde1 bs=10M count=100
 [root@racdb2 trace]dd if=/dev/zero of=/dev/sdd1 bs=10M count=100

Il y a donc plus que 1 voting sur 3 et plus qu’un disque sur 3 dans le diskgroup OCR.

Niveau cluster tout semble ok.

Par exemple sous asm tous les fichiers contenu dans OCRVOT sont accéssibles

[grid@racdb2 trace]$ asmcmd -p

ASMCMD [+] > cd OCRVOT
ASMCMD [+OCRVOT] > ls */*

+OCRVOT/racdb-cluster/ASMPARAMETERFILE/:
REGISTRY.253.804983509

+OCRVOT/racdb-cluster/OCRFILE/:
REGISTRY.255.804983511

La commande crsctl stat res -t, affiche bien toutes les ressources et services comme ONLINE.

L’ arrêt redémarrage de la base ARKONA…

[oracle@racdb1 ~]$ srvctl stop database -d ARKONA
[oracle@racdb1 ~]$ srvctl start database -d ARKONA

… se passe sans encontre.

Mais, si nous checkons l'OCR:

[grid@racdb2 racdb2]$  /oracle/11.2.0.3/grid/bin/ocrcheck
PROT-601: Failed to initialize ocrcheck
PROC-22: The OCR backend has an invalid format

Aïe, aïe, cela ne laisse rien de bon à présager.

Si nous consultons l'alert.log du RAC:

[client(6706)]CRS-1006:The OCR location +OCRVOT is inaccessible. Details in /oracle/11.2.0.3/grid/log/racdb2/client/ocrcheck_6706.log.

Il semble bien que le dg OCRVOT est inaccessible.

Mais faisons comme si nous ne la savions pas. Comme si nous ne monitorions pas le cluster (le monitoring c'est bon pour les autres, les problèmes cela n'arrivent qu'aux autresSurprised). Arrêtons un nœud, comme si nous voulions faire une maintenance.

Arrêtons donc, le noeud2 (racdb2).

Il met énormément de temps, le cluster n’arrive pas à s’éteindre. Extinction manuel.

Sur racdb1, testons l’état du cluster :

[grid@racdb1 racdb1]$ crsctl status res -t
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4000: Command Status failed, or completed with errors.

Premier réflexe, consulter l’alert.log du RAC :

[crsd(8647)]CRS-1013:The OCR location in an ASM disk group is inaccessible. Details in /oracle/11.2.0.3/grid/log/racdb1/crsd/crsd.log.
2013-04-20 21:08:09.720
[crsd(8647)]CRS-0804:Cluster Ready Service aborted due to Oracle Cluster Registry error [PROC-26: Error while accessing the physical storage]. Details at (:CRSD00111:) in /oracle/11.2.0.3/grid/log/racdb1/crsd/crsd.log.

 Et le fichier /oracle/11.2.0.3/grid/log/racdb1/crsd/crsd.log en question indique

2013-04-20 21:07:18.687: [  OCRASM][3899844384]proprasmo: The ASM disk group OCRVOT is not found or not mounted
2013-04-20 21:07:18.688: [  OCRRAW][3899844384]proprioo: Failed to open [+OCRVOT]. Returned proprasmo() with [26]. Marking location as UNAVAILABLE.
2013-04-20 21:07:18.688: [  OCRRAW][3899844384]proprioo: No OCR/OLR devices are usable

Il y a donc clairement un problème sur le diskgroup OCRVOT.

Nous stoppons le cluster en mode force:

[root@racdb1 racdb1]$ /oracle/11.2.0.3/grid/bin/crsctl stop crs –f

 Si comme dans mon cas même le force (-f) n’arrive pas à arrêter le cluster, alors il va falloir relancer le serveur mais en annulant le démarrage du crs au boot :

[root@racdb1 racdb1]$ /oracle/11.2.0.3/grid/bin/crsctl disable crs

Après le reboot dans mon cas ou bien l’arrêt forcer du crs peut être dans votre cas, il faut réinstancier les 2 disques ocr-voting perdus :

[root@racdb1 ~]# /usr/sbin/oracleasm createdisk ocrvot2 /dev/sdd1
Writing disk header: done
Instantiating disk: done

[root@racdb1 ~]# /usr/sbin/oracleasm createdisk ocrvot3 /dev/sde1
Writing disk header: done
Instantiating disk: done

Maintenant nous démarrons la couche cluster en mode exclusive mais sans le demon crsd:

[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/crsctl start crs -excl -nocrs

Dans l’alert.log de l’instance ASM1, nous voyons que tous les diskgroups sont bien montés sauf l’OCRVOT :

WARNING: Disk Group OCRVOT containing spfile for this instance is not mounted
WARNING: Disk Group OCRVOT containing configured OCR is not mounted
WARNING: Disk Group OCRVOT containing voting files is not mounted
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk "2" is missing from group number "4"
ORA-15042: ASM disk "1" is missing from group number "4"
ERROR: ALTER DISKGROUP ALL MOUNT /* asm agent call crs *//* {0:0:97} */
SQL> ALTER DISKGROUP ALL ENABLE VOLUME ALL /* asm agent *//* {0:0:97} */
SUCCESS: ALTER DISKGROUP ALL ENABLE VOLUME ALL /* asm agent *//* {0:0:97} */

Le diskgroup OCRVOT n’est pas monté cependant il contient un voting actif, donc il est impossible de le supprimer et de plus il contient un seul disque valide donc il est impossible  de le monter, et pour rajouter une couche comme il n’est pas monté on ne peut pas supprimer les disques pour rajouter les nouveaux. (pour plus de détail voir Resto OCR et Voting : Annexe 1 )

La solution consiste alors à supprimer le voting:

[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/crsctl delete css votedisk +OCRVOT

Ce qui permet alors de dropper le diskgroup

[grid@racdb1 racdb1]$ sqlplus / as sysasm
SQL> drop diskgroup OCRVOT force including contents;

Puis de recréer le diskgroup

SQL>create Diskgroup OCRVOT normal redundancy disk '/dev/oracleasm/disks/OCRVOT1', '/dev/oracleasm/disks/OCRVOT2', '/dev/oracleasm/disks/OCRVOT3' ATTRIBUTE  'compatible.asm'='11.2.0.0.0', 'compatible.rdbms'='11.2.0.0.0';

Et maintenant il ne reste plus qu’à restaurer l’OCR

[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/ocrconfig -restore /oracle/11.2.0.3/grid/cdata/racdb-cluster/backup_20130420_204630.ocr

Il ne faut pas oublier ensuite de recréer les voting:

[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/crsctl replace votedisk +OCRVOT
Successful addition of voting disk 056ff89bd3284fd3bf3ef53eda30c389.
Successful addition of voting disk 1510d86e8b3d4f90bf48f2ab10ab9d95.
Successful addition of voting disk 22a25780ee094f9cbf46f05a06ab78ef.
Successfully replaced voting disk group with +OCRVOT.
CRS-4266: Voting file(s) successfully replaced

Et aussi de rendre enable de nouveau le démarrage automatique du crs au boot du cluster:

[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/crsctl enable crs

Un petit reboot de racdb1 et start de racdb2

 

Ouf nous venons de rattraper notre bêtise... en fait pas tout à fait...

Tout fonctionne normalement, mais il reste un petit quelque chose à régler, nous avons perdu aussi le spfile de l’ASM. Et oui!!! le spfile était dans OCRVOT, il est toujours par défaut dans le même diskgroup que l'OCR.

Rappelez-vous, un peu plus haut nous avions :

ASMCMD [+OCRVOT] > ls */*
+OCRVOT/racdb-cluster/ASMPARAMETERFILE/:
REGISTRY.253.804983509

+OCRVOT/racdb-cluster/OCRFILE/:
REGISTRY.255.804983511

Et maintenant, nous avons:

ASMCMD [+OCRVOT] > ls */*
+OCRVOT/racdb-cluster/OCRFILE/:
REGISTRY.255.804983511

D’ailleurs à la lecture de l’alertASM.log, nous avons :

WARNING: using default parameter settings without any parameter file

Cela est normal, nous avons restaurer l’OCR mais nullement le spfile. Donc si nous n’avons de backup du spfile alors nous avons perdu toute notre customisation. En général on ne  customise par grand-chose à part le paramètre asm_diskstring et peut être le paramètre memory_target quand il y a de nombreuses bases de données de configurées.

Nous remettons le paramètre asm_diskstring à sa valeur d'avant (facultatif)

SQL> ALTER SYSTEM SET asm_diskstring='/dev/oracleasm/disk*' SCOPE=MEMORY SID='*';

Puis générons notre spfile:

SQL> create spfile='+OCRVOT' from memory;

Vérifions:

ASMCMD [+OCRVOT/racdb-cluster] > ls -l *
Type              Redund  Striped  Time             Sys  Name

+OCRVOT/racdb-cluster/ASMPARAMETERFILE/:
ASMPARAMETERFILE  MIRROR  COARSE   APR 25 21:00:00  Y    REGISTRY.253.813707165

+OCRVOT/racdb-cluster/OCRFILE/:
OCRFILE           MIRROR  COARSE   APR 25 20:00:00  Y    REGISTRY.255.813279867

Parfait. Cette fois ci tout est OK. Mais la morale de cette histoire, est qu'il faut penser à backuper le spfile à chaque fois que nous le customisons.

 

 Perte de trois disques

 Cette fois, perdons 3 disques. Nous pourrions croire que c’est le même cas que précédemment, mais il va y avoir quelques différences…Cependant nous allons aller un peu plus vite et mettre un peu moins d'explication dans  cette partie, les principes et analyses ont été détaillés dans les 2 paragraphes précédents.

 Commençons par la destruction des 3 disques composant le diskgroup d’OCR et Voting.

[root@racdb1 ~]#  dd if=/dev/zero of=/dev/sdd1 bs=10M count=100
[root@racdb1 ~]#  dd if=/dev/zero of=/dev/sde1 bs=10M count=100
[root@racdb1 ~]#  dd if=/dev/zero of=/dev/sdc1 bs=10M count=100

Comme précédemment tout continue de fonctionner

On arrêt le noeud2 (racdb2)…
… et là patatra Surprised le cluster sur racdb1 crashe, et le noeud reboot. Mais pas de stress nous ne sommes pas en production Smile

Au reboot premier réflexe…

[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/crsctl disable crs
CRS-4621: Oracle High Availability Services autostart is disabled.

Comme ça si le serveur recrash par la faute du cluster, la couche cluster ne redémarrera pas.

Nous arrêtons ensuite la couche cluster :

[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/crsctl stop crs -f

Nous recréeons les disques:

[root@racdb1 ~]# /usr/sbin/oracleasm createdisk ocrvot2 /dev/sdd1
[root@racdb1 ~]# /usr/sbin/oracleasm createdisk ocrvot3 /dev/sde1
[root@racdb1 ~]# /usr/sbin/oracleasm createdisk ocrvot1 /dev/sdc1
[root@racdb1 ~]# /usr/sbin/oracleasm scandisks

Nous relançons le cluster en exclusif:

/oracle/11.2.0.3/grid/bin/crsctl start crs -excl -nocrs

L’instance ASM a démarré avec un spfile par défaut, nous la stoppons, pour la redémarrer avec le init de backup. Si vous ne l’avez pas backupé, générez en un  (create pfile from memory, modifiez le pfile au moins pour le paramètre diskstring et vous pouvez continuer ce tutoriel)

SQL> shutdown immediate
SQL> startup pfile='/home/grid/initASM_BACKUP.ora'
Total System Global Area  283930624 bytes
Fixed Size                               2227664 bytes
Variable Size                       256537136 bytes
ASM Cache                           25165824 bytes

ORA-15032: not all alterations performed
ORA-15017: diskgroup "OCRVOT" cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup "OCRVOT"

Pas de soucis cette erreur est normale, le diskgoup OCRVOT n’arrive pas à monter car il n’existe pas encore. Créeons le :

SQL> create Diskgroup OCRVOT normal redundancy disk '/dev/oracleasm/disks/OCRVOT1', '/dev/oracleasm/disks/OCRVOT2', '/dev/oracleasm/disks/OCRVOT3' ATTRIBUTE  'compatible.asm'='11.2.0.0.0', 'compatible.rdbms'='11.2.0.0.0';

Maintenant qu’il existe, créeons y le spfile:

SQL> create spfile='+OCRVOT' from memory;

Stop, start de l’instance ASM:

SQL> shutdown immediate;
SQL> startup

Restaurons maintenant l’OCR

[root@racdb1 ~]#  /oracle/11.2.0.3/grid/bin/ocrconfig -restore /oracle/11.2.0.3/grid/cdata/racdb-cluster/backup_20130420_204630.ocr

Puis le voting

[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/crsctl replace votedisk +OCRVOT

N’oublions pas de remettre l’autostart

[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/crsctl enable crs

Un restart de racdb1, et un start de racdb2… tout baigne Cool

 

{jcomments on}