OLR/OCR/VOTING, kesako?
- Détails
- Catégorie : News
- Publié le mercredi 7 octobre 2015 19:22
- Écrit par Administrator
- Affichages : 56538
Il y a souvent confusion entre l’OCR (Oracle Cluster Registry) et les voting disks. Pourtant ils ont des rôles bien différents. Leur seul point commun est l’obligation lors d’une installation Oracle RAC 11gR2 (et plus) avec ASM d’être mis dans le même storage (même diskgroup). En effet à l’installation on indique les disks ASM qui vont former le diskgroup « initial » et va stoker l’OCR (je dis bien OCR et pas les OCR) et les voting disk (je dis bien les voting disks et pas le voting disk).
Je vais donc dans cet article expliquer à quoi servent l’OCR et les voting disk, mais aussi détailler où ils se cachent et sous quelle forme. Mais avant je rajouterai un autre fichier : l’OLR (Oracle Local Regitry) bien souvent méconnu et pourtant tout aussi critique lors du démarrage du cluster sur un noeud. De plus du fait de son nom il peut y avoir une confusion avec l’OCR alors que leur rôle et leur stockage sont totalement différents.
Pour illustrer mon article je vous ai fait un petit schéma « maison » !
OLR
Commençons par l’OLR : Oracle Local Registry, car il est lu avant les voting et l’OCR, en fait au tout début de démarrage du cluster. Ce fichier contrairement aux autres, est en local sur chaque nœud du cluster, il n’est donc pas partagé.
Sans ce fichier le cluster ne pourrait pas démarrer sur le nœud en question. Mais à quoi sert-il ?
Comme nous le verrons plus loin le cluster a besoin de l’OCR (Oracle Cluster Registry), la configuration cluster y est contenue, en particulier les ressources, mais… l’OCR est dans ASM et… pour démarrer ASM il faut le spfile d’ASM qui… se trouve dans ASM !!! Si le spfile est dans ASM c’est qu’évidement il doit être partagé sur tous les nœuds. Pour résoudre « le chien qui se mord la queue » c’est là qu’intervient l’OLR, le process du cluster OHASD (le premier à démarrer) lit son contenu et trouve les informations pour aller chercher le spfile. L’OLR ne contient pas que des informations sur le spfile, il contient plein d’autres informations nécessaires au démarrage du cluster. Mais pour l’exemple nous prenons le cas du spfile à retrouver dans ASM sans ASM.
L’OLR contient donc entre autre le DiscoveryString qui va permettre de retrouver le spfile pour le démarrage d’ASM.
Jouons à l’OHASD :
1er étape : ils sont où les disques ASM ?
[root@racdb1 cdata]# cd /oracle/11.2.0.3/grid/cdata
[root@racdb1 cdata]# strings racdb1.olr |grep -i discovery
tp://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.grid-pnp.org/2005/11/gpnp-profile gpnp-profile.xsd" ProfileSequence="18" ClusterUId="0586af0c4722ff73ffd7d4b594672d20" ClusterName="racdb-cluster" PALocation=""><gpnp:Network-Profile><gpnp:HostNetwork id="gen" HostName="*"><gpnp:Network id="net1" IP="10.10.0.0" Adapter="eth0" Use="public"/><gpnp:Network id="net2" IP="10.10.1.0" Adapter="eth1" Use="cluster_interconnect"/></gpnp:HostNetwork></gpnp:Network-Profile><orcl:CSS-Profile id="css" DiscoveryString="+asm" LeaseDuration="400"/><orcl:ASM-Profile id="asm" DiscoveryString="/dev/oracleasm/disk*" SPFile="+OCRVOT/racdb-cluster/asmparameterfile/registry.253.813876625"/><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>ErIZ1m8G1+pSMQ50eYS+XHS5tM4=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>CJifwcq/wa2VY6uoTllbNN5sywttgvtgmDiY5cArsvtM6w8R6s8H82vMotEMc7xEISHowjG0SB5IETuaol9plX4JKXrBXPpvsFaCRE0+r0OnDsvpeEQkJvF1E4IYzyUl9AVqWQjF/t8mb9D8S7Jdwvs87J++DZA2tCzA+VSTTMM=</ds:SignatureValue></ds:Signature></gpnp:GPnP-Profile>
OK, j’ai trouvé ils sont dans "/dev/oracleasm/disk*"
2nd étape : lequel contient une copie du spfile ?
[root@racdb1 ~]# ls -l /dev/oracleasm/disk*
total 0
brw-rw----. 1 grid asmadmin 8, 81 Oct 2 22:14 DATA1_1
brw-rw----. 1 grid asmadmin 8, 97 Oct 2 22:14 DATA1_2
brw-rw----. 1 grid asmadmin 8, 113 Oct 2 22:14 DATA2_1
brw-rw----. 1 grid asmadmin 8, 129 Oct 2 22:14 DATA2_2
brw-rw----. 1 grid asmadmin 8, 145 Oct 2 22:14 FRA1
brw-rw----. 1 grid asmadmin 8, 161 Oct 2 20:53 FRA2
brw-rw----. 1 grid asmadmin 8, 33 Oct 2 22:14 OCRVOT1
brw-rw----. 1 grid asmadmin 8, 49 Oct 2 22:14 OCRVOT2
brw-rw----. 1 grid asmadmin 8, 65 Oct 2 22:14 OCRVOT3
Je récupère les major/minor des disks. Ici ils ont tous le major à 8 et les minor sont 81, 97, 113...65
[root@racdb1 ~]# ls -l /dev/sd*1
brw-rw----. 1 root disk 8, 1 Oct 2 20:50 /dev/sda1
brw-rw----. 1 root disk 8, 17 Oct 2 20:50 /dev/sdb1
brw-rw----. 1 root disk 8, 33 Oct 2 22:10 /dev/sdc1
brw-rw----. 1 root disk 8, 49 Oct 2 20:50 /dev/sdd1
brw-rw----. 1 root disk 8, 65 Oct 2 20:50 /dev/sde1
brw-rw----. 1 root disk 8, 81 Oct 2 20:50 /dev/sdf1
brw-rw----. 1 root disk 8, 97 Oct 2 20:50 /dev/sdg1
brw-rw----. 1 root disk 8, 113 Oct 2 20:50 /dev/sdh1
brw-rw----. 1 root disk 8, 129 Oct 2 20:50 /dev/sdi1
brw-rw----. 1 root disk 8, 145 Oct 2 20:50 /dev/sdj1
brw-rw----. 1 root disk 8, 161 Oct 2 20:50 /dev/sdk1
Et maintenant il suffit de scanner les entêtes de disque avec la commande kfed :
[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/kfed read /dev/sde1| grep -E spf
kfdhdb.spfile: 59 ; 0x0f4: 0x0000003b
kfdhdb.spfflg: 1 ; 0x0f8: 0x00000001
Trouvé! C’est le disque /dev/sde partition 1 : kfdhdb.spfflg égal à 1 au lieu de 0 et le spfile se trouve à l’offset 59.
3ème la lecture (dump)
La ausize d’ASM est de combien ? (ausize block de donnée au niveau ASM)
[root@racdb1 ~]# /oracle/11.2.0.3/grid/bin/kfed read /dev/sde1| grep -E ausize
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
1Mo donc, le spfile est donc forcément entièrement dans le bloc de 1Mo à partir de l’offset 59, dumpons le dans un fichier :
dd if=/dev/sde1 of=spfileASM.dump.ora skip=59 bs=1M count=1
Il ne reste plus qu’à le lire:
[root@racdb1 ~]# strings spfileASM.dump.ora
[…]
*.asm_diskgroups='FRA','DATA2','DATA1','OCRVOT'# Manual Mount
asm_diskstring='/dev/oracleasm/disk*'
*.core_dump_dest='/oracle/11.2.0.3/grid/log/diag/asm/+asm/+ASM1/cdump'
*.local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.0.12)(PORT=1521))))'
Et voilà sans qu’ASM ne soit up nous avons réussi à lire le spfile enfermé dans ASM!
Je crois que nous avons fini par faire du hors sujet. Mais nous avons compris à quoi servait l’OLR, c’est un peu le fichier de boot du clusterware sur un nœud. Pour rappel la recherche du spfile n’était qu’un exemple, il sert aussi à l’OHASD à démarrer les process CSSD, GPNPD.
OCR
Sans l’OLR le clusterware ne démarre pas sur le nœud qui l’héberge, sans l’OCR c’est le cluster qui ne démarre pas.
L’OCR : Oracle Cluster Registry, contient les configurations/informations/états sur toutes les ressources qui composent le cluster : ressources du RAC (listeners, instances, services), les serverpools , diskgroups, réseau (VIP, interface…), backup de l’OCR, … et plein d’autres choses comme l’emplacement des voting disk dont nous verrons un peu plus loin leur rôles.
L’OCR est donc LE FICHIER central du cluster, chaque commande d’administration du cluster lit update insère ou delete des informations dans l’OCR. C’est le process CRSD qui lit et écrit dans l’OCR et il en maintient une copie en mémoire sur le nœud où il tourne.
L’emplacement de l’OCR est indiqué dans /etc/oracle/orc.loc :
[grid@racdb1 oracle]$ pwd
/etc/oracle
[grid@racdb1 oracle]$ cat ocr.loc
ocrconfig_loc=+OCRVOT
local_only=FALSE
Comme vu précédemment l’OCR est obligatoirement dans un stockage partagé en général dans ASM mais il peut être aussi dans un filesystem clustérisé (ça existe mais je n’ai jamais vu en production une telle configuration pour une 11g).
L’OCR est un seul et unique fichier mais il est fortement conseillé dans une production de la mettre dans un diskgroup ASM de redondance normal (mirroring), comme dans le schéma ci-dessus. Dans ce schéma nous voyons que l’OCR est dans le diskgroup DG_OCRVOT composé de 3 failgroups FG_OCRVOT_1 à 3. Chaque failgroup correspondant à un disque ASM. L’OCR est donc dans se schéma dans un diskgroup de redondance normal cela signifie que le « fichier » OCR est mirroré sur 2 failgroups.
La question qui se pose alors est : pourquoi mettre le diskgroup en mirroring sur 3 failgroup ? Si on regarde le schéma nous voyons que le diskgroup DG_DATA est en mirrroring mais sur 2 failgroups, cela semble plus logique non ?
Et bien vous aurez la réponse dans le prochain paragraphe sur les voting disks !!! Mais sachez donc que cette configuration est dû aux voting disk, et ne serait pas nécessaire si pendant l’installation du clusterware nous pouvions « au moment de l’installation » choisir 2 diskgroups différents pour héberger l’OCR et les voting, car techniquement il n’y a aucune raison que les voting et l’OCR soit sur le même diskgroup.
Voting Disks
Voting disk, en français on pourrait dire disque de vote… cela correspond bien à leur rôle. Les voting disks enregistrent les informations des nœuds membre du RAC. Il y a inscrit une partie statique comme des informations sur les nœuds mais surtout une partie dynamique très important dans laquelle toutes les secondes la présence des nœuds est mise à jour. Ce sont les process CSS (Cluster Synchnonize Service) qui écrivent dans les voting disks dans un block réservé au nœud dont chacun est issu. Ils écrivent donc pour leur nœud mais aussi lisent les informations des autres nœuds pour savoir s’ils sont toujours présents et en « bonne santé ». Si jamais un CSS ne met pas à jour les voting disk dans un cycle du battement de cœur (heartbeat) il va être considéré comme pas sûr et flaggé (par les autres CSS) dans le voting comme à tuer. Le cluster se reconfigure alors. Les CSS de tous les nœuds relisent les voting disks et seul les nœuds qui trouve bien les blocks de leur heartbeat dans les voting disks seront considéré à mettre dans le cluster, les autres seront déclarés morts. Evidement le nœud considéré mort, se suicide soit parce qu’il n’arrive pas à lire les voting disk, soit parce qu’il arrive à lire au heartbeat suivant mais que les autres nœuds l’ont évincés.
Les voting disk servent donc de communication pour tous les membres du RAC, mais il y a aussi un autre mécanisme par réseau (network heartbeat). Les deux mécanismes travaillent de concert.
Pour que ce mécanisme de heartbeat avec les voting disks fonctionne, il faut que les voting disks soient toujours en nombre impair : 1, 3 ou 5. Or si nous sommes en production, il est conseillé de créer le diskgroup initial qui accueille l’OCR et les voting en normal redondancy (dg_ocrvot sur le schéma). Cela implique donc que nous sommes obligé de prendre 3 disks ASM pour créer ce diskgroup au lieu de 2 (2 : minimum pour faire du miroring). Pour les plus paranoïaques, il est même conseillé par Oracle de créer le diskgroup en high redundancy ce qui implique 5 failgroups (1 par disque ASM). Et si c’est un banc de test, le diskgroup peut être en external redondancy et donc il n’y aura dans ce cas qu’un voting disk.
Pourquoi impair et pas pair ? Un nœud doit pouvoir lire et écrire (communiquer) sur une majorité absolu de voting disk sinon, s’il ne voit pas la majorité absolue, le nœud se suicide, cela pour éviter le partage de cerveau (split brain) : les 2 nœuds ne travaillent plus de concert sur les ressources du RAC. Si par exemple dans un RAC il y a 2 voting disk, si chaque nœud ne communique qu’avec un voting disk différent alors chaque nœud ne pourra savoir si il est seul ou pas, alors que si il y a 3 voting disk celui qui accède à au moins 2 voting disk peut être sûr qu’il a la majorité et ce qu’il lira dans les voting disk représentera bien la majorité absolue.
Si le fichier OCR lui est visible dans ASM par un simple ls dans asmcmd :
ASMCMD [+DG_OCRVOT/racdb-cluster/OCRFILE] > ls -l
Type Redund Striped Time Sys Name
OCRFILE MIRROR COARSE OCT 07 21:00:00 Y REGISTRY.255.813876723
Les voting disks ne sont pas visibles par ls, ils peuvent être identifiés avec la commande crsctl. Ils sont « inclus » dans les disk ASM constituant le diskgroup DG_OCRVOT mais ils ne sont pas sous ASM à proprement parlé, c’est pour cela qu’ils n’apparaissent pas dans asmcmd.
[grid@racdb1 ~]$ crsctl query css votedisk
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1. ONLINE 1e61f7f8bf234fcdbf2621e54a97b7c9 (/dev/oracleasm/disks/OCRVOT1) [DG_OCRVOT]
2. ONLINE 37f922eaf3234f56bf45a175d417c24c (/dev/oracleasm/disks/OCRVOT2) [DG_OCRVOT]
3. ONLINE a4137c2595294f1abffd6f81efa568aa (/dev/oracleasm/disks/OCRVOT3) [DG_OCRVOT]
J'espère que maintenant le rôle des OLR, OCR et voting disk est clair pour vous... ou un peu plus 
{jcomments on}