STORAGE-MIGRATION

MIGRATION

Bei der Migration sollte das VPS Plattensystem von Hitachi durch das EMC Symmetrix VMAX-System von Dell ausgetauscht werden.

Vorbereitungsphase

In der Vorbereitungsphase musste eine Ist-Aufnahme der vorhandenen, von den Datenbanken verwendeten Platten pro Server durchgeführt werden. Ziel war es, der Storage Administration die Anzahl der Logical Unit Number(LUN), die Namen und die Größe der LUNs mitzuteilen. Eine LUN identifiziert laut Wikipedia „eine spezifische logische Einheit, die Teil einer Festplatte, eine komplette Festplatte oder mehrere Festplatten in einem Storage-Verbund sein kann. LUN kann somit auf ein komplettes RAID, einzelne Festplatten oder Partitionen beziehungsweise mehrere Festplatten oder Partitionen verweisen. In jedem Fall wird die logische Einheit als einzelnes Gerät behandelt und durch die LUN identifiziert“. Um die Übersicht zu behalten, sollten die neu zu erstellenden LUNs den Plattenhersteller im Namen beinhalten.

Mit folgendem Skript kann das durchgeführt werden:

set line 300
col disk_group_name format a20
col disk_file_path format a50
col lun_size_gb format 999999
 SELECT
    a.name Disk_Group_Name,
    replace(b.path,'mapper/','mapper/vmax_') Disk_File_Path,
    b.os_mb/1024||' G' Lun_Size_GB
FROM
    v$asm_diskgroup a JOIN v$asm_disk b USING (group_number)
ORDER BY
    a.name
/

Als Ergebnis wurde folgendes ausgegeben:

Disk_Group_Name   Disk_File_Path                     LUN_Size_GB
DG_CRMCZ1P_DATA   /dev/mapper/vmax_crmcz1p_data_1    500G
DG_CRMCZ1P_FRA    /dev/mapper/vmax_crmcz1p_fra_1     500G
DG_ESBCZ1P_DATA   /dev/mapper/vmax_esbcz1p_data_1    500G
DG_ESBCZ1P_FRA    /dev/mapper/vmax_esbcz1p_fra_1     500G
DG_ESBCZ2P_DATA   /dev/mapper/vmax_esbcz2p_data_1    500G
DG_ESBCZ2P_FRA    /dev/mapper/vmax_esbcz2p_fra_1     500G
DG_MWCZ1P_DATA    /dev/mapper/vmax_mwcz1p_data_1     500G
DG_MWCZ1P_DATA    /dev/mapper/vmax_mwcz1p_data_2     500G
DG_MWCZ1P_FRA     /dev/mapper/vmax_mwcz1p_fra_1      500G
DG_MWCZ1P_FRA     /dev/mapper/vmax_mwcz1p_fra_2      500G
DG_MWHU1P_DATA    /dev/mapper/vmax_mwhu1p_data_1     100G
DG_MWHU1P_FRA     /dev/mapper/vmax_mwhu1p_fra_1      100G
(..)

Diese Anforderungsliste wurde als Change für die Storage-Administration eingestellt.

Migrationsphase

Nachdem die LUNs von der Storage Administration bereitgestellt wurden, kann zunächst überprüft werden, ob der Datenbank-Server die neuen LUNs erkennen kann. Das folgende Kommando muss als root-User ausgeführt werden. Aus Vereinfachungsgründen werden hierbei nur die zur Diskgruppe „DG_CRMCZ1P_DATA“ gehörigen bzw. hinzuzufügenden Luns dargestellt:

[root@server01 ~]# multipath -ll
(..)
vmax_crmcz1p_data_1 (360000970000297700069533030323631) dm-13 EMC     ,SYMMETRIX      
size=500.0G features='1 queue_if_no_path' hwhandler='0' wp=rw
crmcz1p_data_1 (360060e80167c210000017c2100000298) dm-14 HITACHI ,OPEN-V        
size=500.0G features='0' hwhandler='0' wp=rw
(..)

Wir sehen, dass die neue LUN „vmax_crmcz1p_data_1“ dem Datenbank-Server bekannt ist und im EMC VMAX Symmetrix Plattensystem definiert ist.

Mit dem folgenden SQL-Befehl können wir überprüfen, ob die LUN auch dem ASM bekannt ist:

SQL> select path, mode_status from v$asm_disk where header_status in ('CANDIDATE','FORMER','PROVISIONED') order by 1;

Ergebnis:

/dev/mapper/crmcz1p_data_1    ONLINE
(..)

Alternativ kann via asmcmd-Kommando das Ergebnis angezeigt werden:

# asmcmd lsdsk --candidate
Path
/dev/mapper/crmcz1p_data_1

Wenn die LUN hier nicht sichtbar ist, kann es z. B. an einer falschen Permission wie im Abschnitt „Fehlermeldungen“ beschrieben, liegen.

Die Verschiebung auf das neue VMAX-Storage kann mit einer „Step by Step“-Methode (sicherer) oder mit einer „One Step“-Methode durchgeführt werden:

„Step by Step“- Methode

Zunächst wird mit sqlplus (nicht mit ASMCA) die VMAX-LUN zu einer ASM-Diskgruppe hinzugefügt. Der Rebalance-Vorgang , d. h. die Übertragung der Daten von dem Hitachi System auf das EMC VMAX System erfolgt zu diesem Zeitpunkt noch nicht, da  der Parameter  „Power“  auf „0“ gesetzt ist. Etwaige Fehler können dadurch noch rechtzeitig erkannt und behoben werden.

SQL> ALTER DISKGROUP DG_CRMCZ1P_DATA ADD DISK '/dev/mapper/vmax_crmcz1p_data_1' SIZE 500G  REBALANCE POWER  0;
Diskgroup altered.

Anschließend das Kommando zum Löschen der Hitachi LUN:

SQL> ALTER DISKGROUP DG_CRMCZ1P_DATA DROP DISK 'DG_CRMCZ1P_DATA_0000' REBALANCE POWER 0;
Diskgroup altered

Der nachfolgende (eigentliche) Verschiebungsvorgang kann sofort oder auch später angestoßen werden. Je höher das „Power“-Limit angegeben wird, desto mehr Einfluss hat dies auf die Performance und letztendlich auf die Antwortzeiten der Endanwender oder der Batch-Programme. Das „Power“-Limit hat bei Diskgruppen mit einer ASM-Kompatibilität von 11.2 einen Werte-Bereich zwischen 0 und 11, bei einer höheren ASM-Kompatibilität zwischen 0 und 1024. In der vorhandenen Umgebung wurde ein sehr niedriger Wert angegeben, um den laufenden Betrieb nicht zu beeinflussen:

SQL> ALTER DISKGROUP DG_CRMCZ1P_DATA POWER 2;
Diskgroup altered.

Die Meldung „Diskgroup altered.“ wird sehr schnell angezeigt, bedeutet aber nicht, dass die Verschiebung schon beendet ist.

Wenn der aktuelle Status angezeigt werden soll, ist folgende Query aufzurufen:

SQL> SELECT OPERATION, POWER, EST_MINUTES, EST_RATE from V$ASM_OPERATION;
 
OPERATION       POWER      EST_MINUTES       EST_RATE
--------------- ---------- ----------------- --------------
REBAL           2          22                47491
REBAL           2          0                 0

Eine erneute Überprüfung nach 22 Minuten:

SQL> SELECT OPERATION, POWER, EST_MINUTES, EST_RATE from V$ASM_OPERATION;
no rows selected

"no rows selected" bedeutet, dass Rebalancing und Löschen der Hitachi Lun abgeschlossen ist.

Wenn der Rebalance ohne Problem gelaufen ist, erfolgt ein Check, welche Disks der Diskgruppe zugehörig sind:

SET LINESIZE  145
SET PAGESIZE  9999
SET VERIFY    off
COLUMN disk_group_name    FORMAT a20               HEAD 'Disk Group Name'
COLUMN disk_path          FORMAT a30               HEAD 'Disk Path'
SELECT a.name                disk_group_name,
       b.path                disk_path
FROM v$asm_diskgroup a JOIN v$asm_disk b USING (group_number)
WHERE a.name = 'DG_ CRMCZ1P_DATA ';

Der Output hierzu:

Disk Group Name      Disk Path
-------------------- ------------------------------
DG_CRMCZ1P_DATA      /dev/mapper/vmax_ crmcz1p_data_1

Alternativ lässt sich auch folgendes Programm aufrufen:

SQL> SELECT path, mode_status FROM v$asm_disk where header_status='MEMBER' order by 1;
PATH                              Status
--------------------------------- -------------------
/dev/mapper/vmax_crmcz1p_data_1   ONLINE

Was ist aus der gelöschten LUN geworden:

SQL> SELECT path, header_status FROM v$asm_disk WHERE header_status in ('CANDIDATE','FORMER','PROVISIONED') order by 1;
PATH                        Header-Status
--------------------------- -------------------
/dev/mapper/crmcz1p_data_1  FORMER

Die LUN ist nicht mehr Bestandteil der Diskgruppe, aber noch Bestandteil des Hitachi-Plattensystems und könnte wieder für andere Verwendungszwecke benutzt werden. Ein Check mit dem „multipath“-Kommando zeigt, dass die LUN dem System noch bekannt ist:

[root@server01 ~]# multipath -ll
 (..)
vmax_crmcz1p_data_1 (360000970000297700069533030323631) dm-13 EMC     ,SYMMETRIX      
size=500.0G features='1 queue_if_no_path' hwhandler='0' wp=rw
crmcz1p_data_1 (360060e80167c210000017c2100000298) dm-14 HITACHI ,OPEN-V        
size=500.0G features='0' hwhandler='0' wp=rw
(..)

„One-Step“- Methode

Bei der “One-Step“-Methode werden die vorgehenden Verschiebungsbefehle in einem Kommando zusammengeführt:

SQL> ALTER DISKGROUP DG_CRMCZ1P_DATA
          ADD DISK '/dev/mapper/vmax_ crmcz1p_data_1' SIZE 500G
           DROP DISK DG_ CRMCZ1P_DATA _000 REBALANCE POWER 2;
Diskgroup altered.

Auch hier wird der Prompt sofort zurückgegeben, obwohl der Verschiebungsvorgang noch aktiv ist.

SQL> SELECT OPERATION, POWER, EST_MINUTES, EST_RATE FROM V$ASM_OPERATION;
 
OPERA     POWER      EST_MINUTES EST_RATE
--------- ---------- ----------- -----------
REBAL     2          45          21134
REBAL     2          0           0

Aus Sicherheitsgründen hat man sich bei diesem Kunden für die“ Step-by-Step“-Methode entschieden. Um dem DBA bei der hohen Anzahl an Datenbank-Servern und Diskgruppen die Arbeit zu erleichtern, wurden SQL-Skripte für die bei der „Step-by-Step“-Methode erforderlichen Schritte erstellt.

Einrichten Rebalance:

SELECT
   'alter diskgroup '|| NVL(a.name, '[CANDIDATE]')                      
  ||' add disk '''|| replace(b.path,'mapper/','mapper/vmax_')
  ||''' size '|| b.total_mb/1024||'g'
  || ' rebalance power 0;' ||chr(10)||
    'alter diskgroup '|| NVL(a.name, '[CANDIDATE]')                      
  ||' drop disk '|| b.NAME
  || ' rebalance power 0;' add_disks
FROM
    v$asm_diskgroup a JOIN v$asm_disk b USING (group_number)
ORDER BY
    a.name;
    /

Output:

alter diskgroup DG_ASM add disk '/dev/mapper/vmax_asm_1' size 10g rebalance power 0;
alter diskgroup DG_ASM drop disk DG_ASM_0000 rebalance power 0;

alter diskgroup DG_CRMCZ1P_DATA add disk '/dev/mapper/vmax_crmcz1p_data_1' size 500g rebalance power 0;
alter diskgroup DG_CRMCZ1P_DATA drop disk DG_CRMCZ1P_DATA_0000 rebalance power 0;

alter diskgroup DG_CRMCZ1P_FRA add disk '/dev/mapper/vmax_crmcz1p_fra_1' size 500g rebalance power 0;
alter diskgroup DG_CRMCZ1P_FRA drop disk DG_CRMCZ1P_FRA_0000 rebalance power 0;
(..)

Starten Rebalance

SELECT distinct 'alter diskgroup '||NVL(a.name, '[CANDIDATE]') || ' rebalance power 2;'
FROM
    v$asm_diskgroup a JOIN v$asm_disk b USING (group_number)
    where path like '%vmax%'
/

Output:

alter diskgroup DG_ASM rebalance power 2;
alter diskgroup DG_CRMCZ1P_DATA rebalance power 2;
alter diskgroup DG_CRMCZ1P_FRA rebalance power 2;
(..)

Fehlermeldungen bei Hinzufügung der LUNs auf dem neuen Storage

A)

ALTER DISKGROUP DG_CRMCZ1P_DATA ADD DISK '/dev/mapper/vmax_crmcz1p_data_1' REBALANCE POWER 0
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15260: permission denied on ASM disk group

Mögliche Ursache:

Anmeldung in der ASM-Instanz als SYSDBA anstelle als SYSASM

B)

ORA-15032: not all alterations performed
ORA-15031: disk specification '/dev/mapper/vmax_crmcz1p_data_1' ' matches no disks
ORA-15014: path '/dev/mapper/vmax_crmcz1p_data_1' is not in the discovery

Mögliche Ursache:

Der „Owner“ der „Grid Infrastructure“-Installation hat nicht die Berechtigung, auf die Platte zuzugreifen.

ls -la  /dev/mapper/vmax_crmcz1p_data_1

lrwxrwxrwx 1 root root       7 Oct 26 10:17 /dev/mapper/vmax_crmcz1p_data_1-> ../dm-40

ls -la  /dev/mapper/../dm-40

brw-rw---- 1 root disk 249, 1 Oct 26 10:17 ../dm-40

Richtige Permission (z. B.)

brw-rw---- 1 grid asmdba 249, 1 Oct 26 10:17 ../dm-40

Mögliche Abhilfe:

Änderung der UDEV-Konfiguration

C)

ORA-15032: not all alterations performed
ORA-15029: disk '/dev/mapper/ dev/mapper/vmax_crmcz1p_data_1’ is already mounted by this instance

Mögliche Ursache:

Die LUN wurde bereits der Diskgruppe hinzugefügt

D)

Fehler im ASM-Alert-Log:

ERROR: ORA-15041 thrown in ARB0 for group number 1
Errors in file /opt/grid/diag/asm/+asm/+ASM/trace/+ASM_arb0_13017.trc:
ORA-15041: diskgroup " DG_CRMCZ1P_DATA " space exhausted
NOTE: stopping process ARB0

Mögliche Ursache:

Die Kapazität der neuen Platte war zu gering oder die LUN Größen innerhalb der Diskgruppe waren unterschiedlich.

Zusammenfassend lässt sich sagen, dass nur einmal ein Fehler zum Stillstand einer Datenbank geführt hat. Der Grund war die falsche Benennung einer LUN. Die Storage-Administration hat einer Hitachi LUN versehentlich den logischen Namen der VMAX-Umgebung gegeben. Nach Entfernung des Hitachi-Storages aus der Server-Konfiguration war die Datenbank nicht mehr in der Lage, das auf der LUN befindliche Controlfile zu finden, da beide LUNS sich nun physikalisch auf dem Hitachi-System befunden haben. Nachdem der Hitachi-Storage wieder an den Datenbank-Server angeschlossen wurde und die LUN dann auch tatsächlich auf der „VMAX„ eingerichtet wurde, konnte die Datenbank wieder gestartet und der Rebalance der LUN erfolgreich auf dem VMAX-Storage abgeschlossen werden.

FAZIT

Bei Verlagerung von vielen und großen Oracle Datenbanken auf ein anderes Storage-System gibt es mit ASM ein geeignetes Tool, um diesen Vorgang sicher und für den Anwender transparent durchzuführen. Wenn bereits im Vorfeld die Anforderungen konkret spezifiziert werden und eine einheitliche Richtlinie in der Namensvergabe festgelegt wird, können Fehler im eigentlichen Migrationsvorgang durch die Step-by-Step-Methode minimiert werden.