Oracle RAC 11.2 - SAN wechsle dich!

03.
September
2012
Veröffentlicht von: Richard Meinhardt

Auch im langen Leben eines Oracle Real Application Clusters (RAC) - in unserem Fall eines Oracle RAC 11.2.0.2 basierend auf Oracle Clusterware 11.2.0.2 mit ASM - kann es Situationen geben, an denen sich das RAC von altbewährtem trennen muss. In unserem Fall ist es das in die Jahre gekommene zentrale SAN Storage; dieses soll nun duch ein neues SAN ersetzt werden.

Auch im langen Leben eines Oracle Real Application Clusters (RAC) - in unserem Fall eines Oracle RAC 11.2.0.2 basierend auf Oracle Clusterware 11.2.0.2 mit ASM - kann es Situationen geben, an denen sich das RAC von altbewährtem trennen muss. In unserem Fall ist es das in die Jahre gekommene zentrale SAN Storage; dieses soll nun duch ein neues SAN ersetzt werden.

Hinweis: Das Oracle RAC 11.2 in dieser Beschreibung wurde unter Oracle Linux 5.5 installiert. Oracle ASM (Automatic Storage Management) wurde als Speicherort für alle Datenbank- und Backupdateien als auch für die OCR und Voting Disks verwendet.

UPDATE: Mittlerweile gibt es hierzu ein einfacheres Vorgehen, bei dem alle Daten in einem Befehl online auf ein neues Storage migriert werden können. Weitere Informationen in folgendem MOS Dokument:
Opens external link in new windowExact Steps To Migrate ASM Diskgroups To Another SAN/Disk-Array/DAS/etc Without Downtime. (Doc ID 837308.1)


1. Datenbankdateien

Durch den Einsatz von Oracle ASM als zentrale Komponente für alle Datenbankdateien, Archivelogs und diskbasierten Backups war es uns ein leichtes, alle eben genannten Dateien im laufenden Betrieb (keine RAC-Datenbank benötigte eine Downtime) und ohne spürbare Beeinträchtigung der Anwender auf das neue SAN umzuziehen.

Hierfür wurden einfach die beiden vorhandenen Diskgruppen DATA und FRA (bei Exadata auch schon mal RECO genannt) um neue Disks, die ausschliesslich vom neuen SAN (im Weiteren als SAN2 gekennzeichnet) stammten, erweitert und nach einem erfolgreichen Rebalance der Diskgruppen die Disks des alten SAN (im Weiteren SAN1 genannt) aus den Diskgruppen entfernt.


Beispiel für das Hinzufügen neuer Disks zu Standard-Diskgruppen

Tipp: Ab Clusterware 11.2 muss man sich für Änderungen an Diskgruppen als "SYS AS SYSASM" verbinden.

a) Diskgroup Redundancy EXTERNAL und Verwendung von ASMLIB-Disks

[grid@s-sl-rac10a:~]>export ORACLE_SID=+ASM1
[grid@s-sl-rac10a:~]>sqlplus / as sysasm
sys@+ASM1> ALTER DISKGROUP data ADD DISK 'ORCL:ASM_SAN2_DISK3',
                                         'ORCL:ASM_SAN2_DISK4';
sys@+ASM1> ALTER DISKGROUP fra  ADD DISK 'ORCL:ASM_SAN2_DISK5',
                                         'ORCL:ASM_SAN2_DISK6';

b) Diskgroup Redundancy EXTERNAL und Verwendung von Multipath-Devices

[grid@s-sl-rac10a:~]>export ORACLE_SID=+ASM1
[grid@s-sl-rac10a:~]>sqlplus / as sysasm
sys@+ASM1> ALTER DISKGROUP data ADD DISK '/dev/mapper/asm_san2_disk3',
                                         '/dev/mapper/asm_san2_disk4';
sys@+ASM1> ALTER DISKGROUP fra  ADD DISK '/dev/mapper/asm_san2_disk5',
                                         '/dev/mapper/asm_san2_disk6';


Beispiel für das Löschen der alten Disks der Standard-Diskgruppen

Tipp: Hier werden nicht mehr die physikalischen Dateinamen verwendet, sondern die ASM-intern vergebenen Namen.

a) Verwendung von ASMLIB-Disks

sys@+ASM1> ALTER DISKGROUP data DROP DISK ASM_SAN1_DISK2, ASM_SAN1_DISK3;
sys@+ASM1> ALTER DISKGROUP fra  DROP DISK ASM_SAN1_DISK4, ASM_SAN1_DISK5;

b) Verwendung von Multipath-Devices

sys@+ASM1> ALTER DISKGROUP data DROP DISK DATA_0000, DATA_0001;
sys@+ASM1> ALTER DISKGROUP fra  DROP DISK FRA_0000, FRA_0001;


2. OCR und Voting Disks

Wie steht es aber nun mit den zentralen Dateien, die die Clusterware selbst verwendet: der OCR und Voting Disks? Geht das auch online oder benötigt man hierfür dann leider doch noch eine - oft schwierig zu organisierende - Downtime?

Zum Glück haben wir aber bereits die Version 11.2 im Einsatz. Und da geht auch dieser Schritt komplett ohne Downtime einer Datenbank oder eines Clusterknotens.

Im Unterschied zu den oben skizzierten Schritten für normale Diskgruppen wird jedoch eine neue Diskgruppe mit entsprechender Redundanz benötigt. Wir legen deshalb eine neue Diskgruppe mit dem Namen OCRVOTE2 und EXTERNAL REDUNDANCY an.

Tipp: Ohne das Attribute 'COMPATIBLE.ASM' = '11.2' würden Sie beim Erstellen der neuen OCR oder Voting Disks den folgenden Oracle Fehler in der ASM-Alertdatei erhalten:

ORA-15221: ASM operation requires compatible.asm of 11.2.0.0.0 or higher


Beispiel für das Erstellen der neuen Diskgruppe OCRVOTE2

a) Diskgroup Redundancy EXTERNAL und Verwendung von ASMLIB-Disks

sys@+ASM1> CREATE DISKGROUP ocrvote2 EXTERNAL REDUNDANCY
                  DISK 'ORCL:OCRVOTE_SAN2_DISK1'
                  ATTRIBUTE 'COMPATIBLE.ASM' = '11.2';

b) Diskgroup Redundancy EXTERNAL und Verwendung von Multipath-Devices

sys@+ASM1> CREATE DISKGROUP ocrvote2 EXTERNAL REDUNDANCY
                  DISK '/dev/mapper/ocrvote_san2_disk1'
                  ATTRIBUTE 'COMPATIBLE.ASM' = '11.2';

sys@+ASM1> CREATE DISKGROUP ocrvote2 EXTERNAL REDUNDANCY                                     DISK '/dev/mapper/ocrvote_san2_disk1'                  ATTRIBUTE 'COMPATIBLE.ASM' = '11.2';&nb


2.1 OCR Datei verschieben

Als erstes müssen Sie die aktuelle Diskgruppe für die OCR Dateien identifizieren.

Dies geschieht mit dem Befehl ocrcheck.

[grid@s-sl-rac10a:~]>ocrcheck
Status of Oracle Cluster Registry is as follows :
         Version                  :          3
         Total space (kbytes)     :     262120
         Used space (kbytes)      :       3528
         Available space (kbytes) :     258592
         ID                       : 1859458837
         Device/File Name         :   +ocrvote
                                    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 bypassed due to non-privileged user

Hier ist zu erkennen, dass es derzeit nur eine einzige OCR-Datei gibt, die auf der Diskgruppe OCRVOTE liegt.

Im ersten Schritt müssen wir nun eine weitere OCR-Datei erzeugen, und zwar in der neuen Diskgruppe OCRVOTE2. Damit wird eine Spiegeldatei der ersten OCR-Datei erzeugt, der von der Clusterware gepflegt und verwaltet wird (CRSD-Prozess). In der Datei /etc/oracle/ocr.loc ist nun auch ein Eintrag für die neue OCR-Datei zu finden.

Das Ganze muss als Benutzer root durchgeführt werden.

[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/ocrconfig -add +OCRVOTE2
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
         Version                  :          3
         Total space (kbytes)     :     262120
         Used space (kbytes)      :       3528
         Available space (kbytes) :     258592
         ID                       : 1859458837
         Device/File Name         :   +ocrvote
                                    Device/File integrity check succeeded
         Device/File Name         :  +OCRVOTE2
                                    Device/File integrity check succeeded

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

         Cluster registry integrity check succeeded


         Logical corruption check succeeded


Abschließend muss nun noch die alte OCR-Datei in der Diskgruppe OCRVOTE entfernt werden (auch dies geschieht wieder als root).

[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/ocrconfig -delete +OCRVOTE
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
         Version                  :          3
         Total space (kbytes)     :     262120
         Used space (kbytes)      :       3528
         Available space (kbytes) :     258592
         ID                       : 1859458837
         Device/File Name         :  +OCRVOTE2
                                    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

Die OCR liegt nun im neuen SAN. Alles online möglich.


2.2 Voting Disks verschieben

Zuerst sollte wieder identifiziert werden, auf welcher Diskgruppe die Voting Disks liegen. Dies ist mit dem Befehl crsctl möglich.

[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   5c6237d9f6104fd9bfe64c13a10c55dc (ORCL:OCRVOTE_SAN1_DISK1) [OCRVOTE]
Located 1 voting disk(s).

Hier ist zu sehen, dass die Voting Disks in der Diskgruppe OCRVOTE beziehungsweise genaugenommen auf der ASMLIB-Disk OCRVOTE_SAN1_DISK1 liegen.

Das Verschieben der Voting Disks von OCRVOTE auf OCRVOTE2 erfolgt bei Verwendung von ASM in einem einzigen Schritt: nicht über ADD und anschließendem DELETE, sondern über ein einfaches REPLACE.

Der Befehl dazu lautet crsctl replace votedisk (ausführen als root).

[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/crsctl replace votedisk +OCRVOTE2
Successful addition of voting disk 3363150a88bc4fb3bfd8614c9e8c2d8b.
Successful deletion of voting disk 5c6237d9f6104fd9bfe64c13a10c55dc.
Successfully replaced voting disk group with +OCRVOTE2.
CRS-4266: Voting file(s) successfully replaced


Noch ein schneller Blick, ob es auch wirklich funktioniert hat.

[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   3363150a88bc4fb3bfd8614c9e8c2d8b (ORCL:OCRVOTE_SAN2_DISK1) [OCRVOTE2]
Located 1 voting disk(s).

Sieht doch gut aus!

Nun, da sowohl die Voting Disks als auch die OCR Dateien nicht mehr auf der Diskgruppe OCRVOTE liegen, könnte man glauben, die alte Diskgruppe kann nun gelöscht werden.

Aber ist gibt noch einen weiteren kleinen "geheimen" Passagier auf dieser Diskgruppe: das SPFILE der ASM-Instanzen.


2.3. ASM-SPFILE verschieben

Wenn man im Zuge des SAN-Wechsels auch für das ASM-SPFILE die neue Diskgruppe OCRVOTE2 nutzen will, kommt man nicht um einen Neustart der Clusterware auf den einzelnen Knoten herum - wobei dies natürlich im Rolling-Verfahren geschehen kann, um eine komplette Downtime der Datenbanken zu verhindern.


Offline-Variante:

Dies würde am einfachsten über den spcopy Befehl in asmcmd gehen.

[grid@s-sl-rac10a:~/bin]>asmcmd
ASMCMD> spget
+OCRVOTE/s-sl-rac10/asmparameterfile/registry.253.789133423
ASMCMD> lsdg
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  NORMAL  N         512   4096  1048576     20092    15312             1198            7057              0             N  DATA/
MOUNTED  NORMAL  N         512   4096  1048576     20092    11897             2053            4922              0             N  FRA/
MOUNTED  EXTERN  N         512   4096  1048576      1023      658                0             658              0             N  OCRVOTE/
MOUNTED  EXTERN  N         512   4096  1048576      1023      628                0             628              0             Y  OCRVOTE2/
ASMCMD> spcopy -u +OCRVOTE/s-sl-rac10/asmparameterfile/registry.253.789133423 +OCRVOTE2/spfileASM.ora
ASMCMD>


Danach müssen Sie nur noch als root den HA Stack jedes Knoten, nacheinander neu starten und verifizieren das die ASM Instanz mit dem neuen SPFILE gestartet ist.

[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 's-sl-rac10a'
CRS-2673: Attempting to stop 'ora.crsd' on 's-sl-rac10a'
CRS-2790: Herunterfahren der von Cluster Ready Services verwalteten Ressourcen auf 's-sl-rac10a' wird gestartet
........
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 's-sl-rac10a' has completed
CRS-4133: Oracle High Availability Services has been stopped.
[root@s-sl-rac10a ~]#
[root@s-sl-rac10a ~]# /u01/app/11.2.0/grid/bin/crsctl start crs
CRS-4123: Oracle High Availability Services has been started.

[grid@s-sl-rac10a:~]>asmcmd
ASMCMD> spget
+OCRVOTE2/spfileASM.ora
ASMCMD>


Online-Variante:

Es ist jedoch möglich, auch diesen Schritt komplett online zu machen. Oracle erkennt dies auch als legitimen Weg an (geklärt per MOS).

Das Ganze würde dann folgendermaßen ablaufen:

Da die Diskgruppe OCRVOTE ja ansich eigentlich eine ganz normale ASM Diskgruppe ist (ohne Quorum-Disks zu beinhalten), könnte man sie ja auch wie eine solche behandeln. Und einfach durch das Hinzufügen und Entfernen von Disks aus SAN2 resp. SAN1 - wie oben bereits beschrieben - dafür sorgen, dass die Diskgruppe am Ende nur noch auf Disks des neuen SAN liegt.

sys@+ASM1> ALTER DISKGROUP ocrvote ADD DISK 'ORCL:ASM_SAN2_DISK2';
sys@+ASM1> ALTER DISKGROUP ocrvote DROP DISK OCRVOTE_SAN1_DISK1;

Oder entsprechend bei Verwendung von Multipath-Disks:

sys@+ASM1> ALTER DISKGROUP ocrvote ADD DISK '/dev/mapper/asm_san2_disk2',
sys@+ASM1> ALTER DISKGROUP ocrvote DROP OCRVOTE_0001;

Jetzt endlich sollten die Disks des alten SAN (SAN1) nicht mehr in Benutzung sein.

Hinweis:
Bevor sie nun aber das alte SAN in aller Euphorie einfach abschalten, sollten Sie sich doch noch einmal vergewissern, ob es nicht doch noch weitere Diskgruppen oder Devices gibt, die das SAN verwenden.

Wir helfen Ihnen natürlich gerne auch persönlich weiter: Besuchen Sie einfach unsere Opens internal link in current windowSchulung zum Thema Oracle RAC 11.2 oder wenden Sie sich vertrauensvoll an unsere Opens internal link in current windowConsulting-Abteilung.

Storage RAC Linux

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.