Table of Contents
Ziel
Dieser Blogeintrag stellt den Start einer neuen Blogserie dar. In dieser Serie werden Ausfall Szenarien in einer Oracle Hochverfügbarkeitsumgebung simuliert. Der erste Beitrag dieser Serie befasst sich mit einem zerstörten Header einer ASM Disk, die Bestandteil einer gemounteten ASM Diskgroup ist.
Voraussetzungen
Für das Simulieren von Ausfällen kritischer RAC Komponenten verwende ich einen virtuellen Oracle Real Application Cluster in der Version 11g Release 2 (Version 11.2.0.1). Als Betriebssystem kommt CentOS 5.5 und als Systemarchitektur wurde x86_64 gewählt. Eine Anleitung für die Einrichtung eines RACs findet sich hier.
In meinem Testsystem wurden drei Diskgroups angelegt, die die folgenden Merkmale aufweisen:
- Diskgroup CONFIG, Redundancy NORMAL – Gespiegelte Diskgroup für OCR und Voting Disks (ab 11g Release 2 möglich)
- Diskgroup DATA, Redundancy NORMAL – Gespiegelte Diskgroup zur Speicherung der Datendateien der Datenbank
- Diskgroup FRA, Redundancy NORMAL – Gespiegelte Diskgroup für die Fast Recovery Area (ehemals Flash Recovery Area)
Für die Simulation wird nur die Diskgroup DATA verwendet.
Die ASM Disks wurden mithilfe von ASMLib gelabelt. Das Mapping sieht wie folgt aus.
[root@rac01 ~]# /etc/init.d/oracleasm querydisk /dev/sd[c-k]1 Device "/dev/sdc1" is marked an ASM disk with the label "CONFIG01" Device "/dev/sdd1" is marked an ASM disk with the label "CONFIG02" Device "/dev/sde1" is marked an ASM disk with the label "CONFIG03" Device "/dev/sdf1" is marked an ASM disk with the label "DATA01" Device "/dev/sdg1" is marked an ASM disk with the label "DATA02" Device "/dev/sdh1" is marked an ASM disk with the label "FRA01" Device "/dev/sdi1" is marked an ASM disk with the label "FRA02"
Bevor der Ausfall simuliert wird, muss sicher gestellt werden, dass alle notwendigen RAC Ressourcen ordnungsgemäß funktionieren.
[grid@rac01 ~]$ crsctl status res -t -------------------------------------------------------------------------------- NAME TARGET STATE SERVER STATE_DETAILS -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.CONFIG.dg ONLINE ONLINE rac01 ONLINE ONLINE rac02 ora.DATA.dg ONLINE ONLINE rac01 ONLINE ONLINE rac02 ora.FRA.dg ONLINE ONLINE rac01 ONLINE ONLINE rac02 ora.LISTENER.lsnr ONLINE ONLINE rac01 ONLINE ONLINE rac02 ora.asm ONLINE ONLINE rac01 Started ONLINE ONLINE rac02 Started ora.eons ONLINE ONLINE rac01 ONLINE ONLINE rac02 ora.gsd OFFLINE OFFLINE rac01 OFFLINE OFFLINE rac02 ora.net1.network ONLINE ONLINE rac01 ONLINE ONLINE rac02 ora.ons ONLINE ONLINE rac01 ONLINE ONLINE rac02 -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE rac01 ora.oc4j 1 OFFLINE OFFLINE ora.rac01.vip 1 ONLINE ONLINE rac01 ora.rac02.vip 1 ONLINE ONLINE rac02 ora.scan1.vip 1 ONLINE ONLINE rac01 ora.test.db 1 ONLINE ONLINE rac01 Open 2 ONLINE ONLINE rac02 Open
Hinweis: Der Befehl crs_stat wurde in 11g Release 2 als deprecated gekennzeichnet, kann aber weiterhin verwendet werden.
Wie man sieht laufen alle RAC Ressourcen ordnungsgemäß. Es wurde bereits eine Datenbank mit dem Namen TEST angelegt, die ich für die Veranschaulicherung eines zerstörten ASM Headers verwenden werde.
Simulation – Zerstörter ASM Header bei Disk in gespiegelter Diskgroup
In dieser Simulation werde ich den Header von einer der beiden ASM Disks der Diskgroup DATA zerstören. Dafür verwende ich das dd Kommando. Bevor ich den ASM Header zerstöre, lass ich ihn mir mithilfe von kfed (Kernel Files Editor) auslesen. Mithilfe, des von Oracle bereitgestellten Werkzeugs, kfed kann man sich die Headerinformationen einer ASM Disk auslesen.
[root@rac01 ~]# /u01/app/11.2.0/grid/bin/kfed read /dev/sdg1 kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0 kfbh.block.obj: 2147483650 ; 0x008: TYPE=0x8 NUMB=0x2 kfbh.check: 1541245862 ; 0x00c: 0x5bdd8ba6 kfbh.fcn.base: 4179 ; 0x010: 0x00001053 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdhdb.driver.provstr: ORCLDISKDATA02 ; 0x000: length=14 kfdhdb.driver.reserved[0]: 1096040772 ; 0x008: 0x41544144 kfdhdb.driver.reserved[1]: 13104 ; 0x00c: 0x00003330 kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000 kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000 kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000 kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000 kfdhdb.compat: 186646528 ; 0x020: 0x0b200000 kfdhdb.dsknum: 2 ; 0x024: 0x0002 kfdhdb.grptyp: 2 ; 0x026: KFDGTP_NORMAL kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: DATA02 ; 0x028: length=6 kfdhdb.grpname: DATA ; 0x048: length=4 kfdhdb.fgname: DATA02 ; 0x068: length=6 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 32951179 ; 0x0a8: HOUR=0xb DAYS=0x1c MNTH=0x2 YEAR=0x7db kfdhdb.crestmp.lo: 1711486976 ; 0x0ac: USEC=0x0 MSEC=0xce SECS=0x20 MINS=0x19 kfdhdb.mntstmp.hi: 32951179 ; 0x0b0: HOUR=0xb DAYS=0x1c MNTH=0x2 YEAR=0x7db kfdhdb.mntstmp.lo: 1711770624 ; 0x0b4: USEC=0x0 MSEC=0x1e3 SECS=0x20 MINS=0x19 ...
In dieser Ausgabe erkennt man zum Beispiel, dass die Festplatte /dev/sdg1 zu der Diskgroup DATA (fdhdb.grpname) gehört und mit dem ASM Label ORCLDISKDATA02 (kfdhdb.driver.provstr) gelabelt wurde.
Hinweis: Mit Oracle 11g ist kfed ein zentraler Bestandteil geworden. Es muss nicht mehr, wie bei Oracle 10g, zunächst mit make erstellt werden.
Alternativ kann man sich den Header der Disk mit od in der ASCII Schreibweise anzeigen lassen.
[root@rac01 ~]# od -c /dev/sdg1 | head -n 10 0000000 001 202 001 001 \0 \0 \0 \0 002 \0 \0 200 246 213 335 [ 0000020 S 020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 O R C L D I S K D A T A 0 2 \0 \0 0000060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000100 \0 \0 \v 002 \0 002 003 D A T A 0 2 \0 \0 0000120 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000140 \0 \0 \0 \0 \0 \0 \0 \0 D A T A \0 \0 \0 \0 0000160 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000200 \0 \0 \0 \0 \0 \0 \0 \0 D A T A 0 2 \0 \0 0000220 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
Im nächsten Schritt wird nun der ASM Header übrschrieben. Die Diskgroup ist weiterhin ONLINE und auch die Datenbank ist geöffnet.
[root@rac01 ~]# dd if=/dev/zero of=/dev/sdg1 bs=8k count=1 1+0 Datensätze ein 1+0 Datensätze aus 8192 Bytes (8,2 kB) kopiert, 4,7e-05 Sekunden, 174 MB/s
Was passiert nun mit der Datenbank und der ASM Diskgroup?
Überprüfen wir zunächst den Status der ASM Diskgroup.
[grid@rac01 ~]$ srvctl status diskgroup -g DATA Plattengruppe DATA wird auf rac01,rac02 ausgeführt
Der Status der ASM Diskgroup hat sich nicht verändert. Oracle zeigt auch keine der Disks als OFFLINE an, wie man mithilfe des Kommandozeilenwerkzeuges asmcmd sehen kann.
[grid@rac01 ~]$ asmcmd lsdsk -p -G DATA Group_Num Disk_Num Incarn Mount_Stat Header_Stat Mode_Stat State Path 3 0 3915922613 CACHED MEMBER ONLINE NORMAL ORCL:DATA01 3 2 3915922616 CACHED MEMBER ONLINE NORMAL ORCL:DATA02
Schauen wir uns nun die Datenbank an.
[grid@rac01 ~]$ srvctl status database -d TEST Instanz TEST1 wird auf Knoten rac01 ausgeführt Instanz TEST2 wird auf Knoten rac02 ausgeführt
Die Datenbank scheint noch zu laufen, aber was passiert wenn nun jemand versucht auf die Daten in der Diskgroup zuzugreifen?
[oracle@rac01 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 28 12:37:05 2011 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options SQL> select name, open_mode from v$database; NAME OPEN_MODE --------- -------------------- TEST READ WRITE SQL> select count(*) from dba_objects; COUNT(*) ---------- 13079
Wie man sehen kann, läuft die Datenbank ohne Probleme weiter. Auch Abfragen auf das Data Dictionary sind ohne Weiteres möglich.
Überprüft man nun wieder mit kfed den ASM Header der Disk, sieht man folgendes.
[root@rac01 ~]# /u01/app/11.2.0/grid/bin/kfed read /dev/sdg1 kfbh.endian: 0 ; 0x000: 0x00 kfbh.hard: 0 ; 0x001: 0x00 kfbh.type: 0 ; 0x002: KFBTYP_INVALID kfbh.datfmt: 0 ; 0x003: 0x00 kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0 kfbh.block.obj: 0 ; 0x008: TYPE=0x0 NUMB=0x0 kfbh.check: 0 ; 0x00c: 0x00000000 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 ERROR!!!, failed to get the oracore error message
Das Abrufen des ASM Headers schlägt fehl. Der Wert KFBTYP_INVALID für den Parameter kfbh.type bedeutet, dass es sich bei der Platte um keine ASM Disk handelt oder das der Header defekt ist.
Ein zweiter Test wird direkt über die ASM Instanz durchgeführt. Es werden die ASM Disks Informationen über die View v$asm_disk abgerufen. Bei der Verwendung von v$asm_disk wird ein Disk Discovery durchgeführt. Wird dagegen die View v$asm_disk_stat verwendet, ruft Oracle die Disk Informationen aus dem Speicher ab. In diesem Fall muss v$asm_disk verwendet werden!
[grid@rac01 ~]$ sqlplus / as sysasm SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 28 12:40:23 2011 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Real Application Clusters and Automatic Storage Management options SQL> select group_number, name from v$asm_diskgroup; GROUP_NUMBER NAME ------------ ------------------------------ 1 CONFIG 2 FRA 3 DATA SQL> set linesize 250 SQL> col path for a40 SQL> select disk_number, mount_status, header_status, state, name, path from v$asm_disk where group_number=3 DISK_NUMBER MOUNT_S HEADER_STATU STATE NAME PATH ----------- ------- ------------ -------- ------------------------------ ---------------------------------------- 0 CACHED MEMBER NORMAL DATA01 ORCL:DATA01 2 CACHED CANDIDATE NORMAL DATA02 ORCL:DATA02
Wie man sieht erkennt Oracle die Disk nicht mehr als Member einer Diskgroup (Header Status CANDIDATE).
Erneutes Mounten der ASM Diskgroup
In diesem Test wird nun überprüft was passiert, wenn die Diskgroup erneut gemountet wird (zum Beispiel durch einen Neustart des Servers). Ich stoppe zuvor die Datenbank.
[grid@rac01 ~]$ srvctl start database -d TEST
Anschließend remounte ich die ASM Diskgroup DATA.
[root@rac01 ~]# /u01/app/11.2.0/grid/bin/srvctl stop diskgroup -g DATA -n rac01,rac02 -f PRCR-1064 : Ressource ora.DATA.dg konnte auf Knoten rac01 nicht gestartet werden ORA-15032: not all alterations performed ORA-15040: diskgroup is incomplete ORA-15042: ASM disk "2" is missing from group number "3" CRS-2674: Starten von "ora.DATA.dg" auf "rac01" nicht erfolgreich PRCR-1064 : Ressource ora.DATA.dg konnte auf Knoten rac02 nicht gestartet werden ORA-15032: not all alterations performed ORA-15040: diskgroup is incomplete ORA-15042: ASM disk "2" is missing from group number "3" CRS-2674: Starten von "ora.DATA.dg" auf "rac02" nicht erfolgreich
Oracle verweigert das Mounten der Diskgroup, da Oracle die ASM Disk mit der Nummer 2 nicht finden kann.
Sollte es sich, wie in diesem Fall, um eine durch ASM gespiegelte Diskgroup handeln und sollte nur einer der beiden ASM Header zerstört sein, lässt sich das Mouten der Diskgroup erzwingen.
[grid@rac01 ~]$ sqlplus / as sysasm SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 28 13:08:50 2011 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Real Application Clusters and Automatic Storage Management options SQL> alter diskgroup DATA mount force; Diskgroup altered.
Überprüft man nun die Diskgroup, sieht man, dass Oracle die Platte mit dem intakten Header mounten konnte.
[grid@rac01 ~]$ asmcmd lsdsk -p -G DATA Group_Num Disk_Num Incarn Mount_Stat Header_Stat Mode_Stat State Path 3 2 3915922621 MISSING UNKNOWN OFFLINE NORMAL 3 0 3915922620 CACHED MEMBER ONLINE NORMAL ORCL:DATA01
Hinweis: Bei einer nicht gespiegelten Platte muss der ASM Header wiederhergestellt werden. Hierfür sollte der Oracle Support zur Hilfe gezogen werden.
Wiederherstellen des ASM Spiegels
Möchte man nun den ASM Spiegel wiederherstellen, sollte man sich zunächst eine neue LUN von Administrator geben lassen. Ich empfehle die alte zerstörte ASM Disk nicht mehr zu verwenden.
Ich verwende dafür die neue Disk /dev/sdj1.
[root@rac01 ~]# /etc/init.d/oracleasm querydisk /dev/sdj1 Device "/dev/sdgj" is marked an ASM disk with the label "DATA03"
Nachdem die Disk formatiert und mit einem ASM Label (nur bei Verwendung von ASMLib) gelabelt wurde, kann die neue Disk der Diskgroup DATA hinzugefügt werden.
[grid@rac01 ~]$ sqlplus / as sysasm SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 28 13:15:16 2011 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Real Application Clusters and Automatic Storage Management options SQL> alter diskgroup DATA add disk 'ORCL:DATA03'; Diskgroup altered.
Oracle stellt nun den Spiegel wieder her. Dieser Vorgang wird Rebalance genannt.
[grid@rac01 ~]$ asmcmd lsop Group_Name Dsk_Num State Power DATA REBAL RUN 1
Oracle entfernt die alte, defekte Disk erst nach erfolgreichen Abschluss des Rebalance aus der Diskgroup.
[grid@rac01 ~]$ asmcmd lsdsk -p -G DATA Group_Num Disk_Num Incarn Mount_Stat Header_Stat Mode_Stat State Path 3 2 3915922621 MISSING UNKNOWN OFFLINE FORCING 3 0 3915922620 CACHED MEMBER ONLINE NORMAL ORCL:DATA01 3 1 3915922623 CACHED MEMBER ONLINE NORMAL ORCL:DATA03
Nach Abschluss des Rebalance ist der ASM Spiegel wieder korrekt hergestellt. Die alte ASM Disk wurde endgültig entfernt.
[grid@rac01 ~]$ asmcmd lsdsk -p -G DATA Group_Num Disk_Num Incarn Mount_Stat Header_Stat Mode_Stat State Path 3 0 3915922620 CACHED MEMBER ONLINE NORMAL ORCL:DATA01 3 1 3915922623 CACHED MEMBER ONLINE NORMAL ORCL:DATA03
Fazit
Ein zerstörter ASM Header hat zunächst keinen Einfluss auf den Betrieb der ASM Diskgroup oder möglicher Datenbanken, die auf diese Diskgroup zugreifem. Erst der Versuch eines erneuten Mounts der Diskgroup schlägt fehl.
Die Headerinformationen sind für Oracle nur während des Startens der ASM Instanz bzw. des Mounten der ASM Diskgroups von Relevanz.
Ich persönlich empfehle das Spiegeln der Diskgroups mithilfe von ASM. Dadurch ist man gegen zerstörte Header besser geschützt.