ASM unter Linux dynamisch erweitern

Immer wieder besteht die Notwendigkeit, dass man ASM Diskgruppen erweitert. Dazu muss man zuerst eine neue LUN bereitstellen, dem Server(n) zuordnen (zoning) und dann einbinden.

Dabei muss man noch beachten, dass es seitens Oracle immer wieder Änderungen bei den Voraussetzungen gibt (ASM hat lange Zeit zwingend Partitionen benötigt - bei aktuellen Oracle Releases ist das zwar nicht mehr so, nur sollte man aus Wartbarkeitsgründen nicht "mischen").

Folgende Konfiguration wurde zum Test verwendet:

OEL/RHEL 5.5 64bit
Oracle 11.2.0.2
Multipathing ("native Multipathing")
EMC Storage

Grundsätzlich sollte die Vorgangsweise ab Oracle 10g unter OEL/RHEL 5 oder 6 bei der Nutzung von Multipath für jede beliebige Storage ident sein.

Die Beschreibung ist so geschrieben, dass man damit auch in einem Oracle Grid Infrastruktur Cluster korrekt vorgeht. Wenn man nur eine Single Server Grid Infrastruktur nutzt, ist der Hinweis, dass dies auf allen Cluster Knoten erfolgen muss, nur eine Information (es ist nichts weiter zu tun).

Zuerst müssen die neuen LUNs für das OS "sichtbar" machen

Es gibt dafür auch verschiedene Scripts wie "rescan-scsi-bus.sh" oder andere, der hier beschriebene Weg sollte mit allen gängigen HBAs funktionieren.

# for i in `ls -1 /sys/class/scsi_host`; do

	> echo "- - -" > /sys/class/scsi_host/${i}/scan

	> done

Die neuen LUNs sind nun in /proc/partitions sichtbar (als unpartitionierte Disken). (Im Fehlerfall /var/log/messages prüfen!)

Multipathing konfigurieren

Zum Konfigurieren von Multipathing werden die WWIDs der neuen Disken benötigt. Üblicherweise genügt es einfach die "neuen" Zeilen in /proc/partitions dafür zu verwenden.

Mit dieser Information kann /etc/multipath.conf ergänzt werden (Beispiel):

multipaths {

	..

	multipath {

	wwid 360000970000294900664533030344239

	alias ACFS0001

	path_grouping_policy failover

	}

	..

	}

Bei Clustersystemen müssen diese Anpassungen auf allen Cluster Knoten gemacht werden.

Vorsicht bei NetApp Storage Lösungen, sofern man SnapManager für Oracle nutzen will

SMO - SnapManager für Oracle - unterstützt keine "alias Namen" in der Multipath Konfiguration, hier darf man somit im multipath.conf keine Einträge unter "multipaths { ... }" machen!

Die neue Multipath Konfiguration aktualisieren

Der folgende Befehl sorgt dafür, dass die Multipath Konfiguration neu geladen wird:

# /etc/init.d/mulitpathd reload

Dies muss auf jedem Cluster Knoten ausgeführt werden.

Danach sollten im Verzeichnis /dev/mapper die neuen Disken sichtbar sein (z.B. als /dev/mapper/ACFS0001).

Anlegen einer Partition auf der ASM Disk

Wie schon oben beschrieben, ist dies bei aktuellen Oracle Releases nicht mehr zwingend nötig, aber immer noch empfohlen. Man sollte aus administrativen Gründen alle ASM Disks gleich konfigurieren.

Oracle empfiehlt für ASM Disken eine Partition pro Disk anzulegen.

Dabei wird "fdisk" gegen das Mapper Device durchgeführt, allerdings mit der ID aus /dev/disk/by-id:

# fdisk /dev/mapper/360000970000294900664533030344239

	Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel

	Building a new DOS disklabel. Changes will remain in memory only,

	until you decide to write them. After that, of course, the previous

	content won't be recoverable.

	

	The number of cylinders for this disk is set to 23251.

	There is nothing wrong with that, but this is larger than 1024,

	and could in certain setups cause problems with:

	1) software that runs at boot time (e.g., old versions of LILO)

	2) booting and partitioning software from other OSs

	(e.g., DOS FDISK, OS/2 FDISK)

	Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

	

	Command (m for help): u

	Changing display/entry units to sectors

	

	Command (m for help): n

	Command action

	e extended

	p primary partition (1-4)

	p

	Partition number (1-4): 1

	First sector (32-47619839, default 32): 128

	Last sector or +size or +sizeM or +sizeK (129-47619839, default 47619839):

	Using default value 47619839

	

	Command (m for help): p

	

	Disk /dev/mapper/360000970000294900664533030344239: 24.3 GB, 24381358080 bytes

	64 heads, 32 sectors/track, 23251 cylinders, total 47619840 sectors

	Units = sectors of 1 * 512 = 512 bytes

	

	Device Boot Start End Blocks Id System

	/dev/mapper/360000970000294900664533030344239p1 128 47619839 23809855+ 83 Linux

	

	Command (m for help): w

	The partition table has been altered!

	

	Calling ioctl() to re-read partition table.

	Syncing disks.

Das Offset für den ersten Sektor der Partition ist EMC-spezifisch und sollte für andere Storage Systeme nicht ungeprüft wiederverwendet werden! Grundsätzlich muss man aber darauf achten, dass die Partition korrekt "ALIGNED" ist (dass der Startsektor der Partition den darunterliegenden Storage RAID Grenzen entspricht).

Partitionen sichtbar machen

Nach dem Partitionieren mit "fdisk" sind die neuen Partitionen noch nicht im /dev/mapper Verzeichnis sichtbar:

# ls -l /dev/mapper/ACFS*

	brw-rw---- 1 root disk 253, 31 Jan 18 10:05 /dev/mapper/ACFS0001

	brw-rw---- 1 root disk 253, 32 Jan 18 10:05 /dev/mapper/ACFS0002

# wc -l /proc/partitions

	107 /proc/partitions

(hier kommt die Anzahl die bei Ihrem System korrekt ist)

Mit "kpartx" - wenn nicht bereits installiert, wie folgt installieren:

# yum install kpartx

und die Partitionen "einlesen"

# kpartx -l /dev/mapper/ACFS0001

	ACFS0001p1 : 0 47619711 /dev/mapper/ACFS0001 129

	# kpartx -a /dev/mapper/ACFS0001

	# kpartx -l /dev/mapper/ACFS0002

	ACFS0002p1 : 0 47619711 /dev/mapper/ACFS0002 129

	# kpartx -a /dev/mapper/ACFS0002

	

	# ls -l /dev/mapper/ACFS000*

	brw-rw---- 1 root disk 253, 31 Jan 18 10:05 /dev/mapper/ACFS0001

	brw-rw---- 1 root disk 253, 36 Jan 18 10:13 /dev/mapper/ACFS0001p1

	brw-rw---- 1 root disk 253, 32 Jan 18 10:05 /dev/mapper/ACFS0002

	brw-rw---- 1 root disk 253, 37 Jan 18 10:13 /dev/mapper/ACFS0002p1

	

	# partprobe

	# wc -l /proc/partitions

	109 /proc/partitions

(jetzt muessen die neuen Partitions sichtbar sein)

Verifizieren Sie auf den anderen Cluster Knoten, dass diese die Partitions ebenfalls korrekt sehen. Dies sollte mit folgenden Befehlen sichergestellt sein:

# partprobe

# ls -l /dev/mapper/ACFS000*

	brw-rw---- 1 root disk 253, 31 Jan 18 10:05 /dev/mapper/ACFS0001

	brw-rw---- 1 root disk 253, 36 Jan 18 10:13 /dev/mapper/ACFS0001p1

	brw-rw---- 1 root disk 253, 32 Jan 18 10:05 /dev/mapper/ACFS0002

	brw-rw---- 1 root disk 253, 37 Jan 18 10:13 /dev/mapper/ACFS0002p1

Sollten die Partitions nicht sichtbar sein, müssen Sie diese mittels "kpartx -a ...." wie oben beschrieben einlesen.

	Danach nochmals partprobe ausführen und mit "ls -la" verifizieren, dass die Partitions jetzt sichtbar sind.

Nun können die neuen Disken im ASM genutzt werden

Im Fall eines Grid Infrastruktur Clusters sollten Sie lieber zwei mal überprüfen ob alle partitionierten Devices wirklich auf allen Knoten korrekt zur Verfügung stehen, die Fehlersuche ist teilweise recht mühsam.

# oracleasm createdisk ACFS0001 /dev/mapper/ACFS0001p1

	# oracleasm createdisk ACFS0002 /dev/mapper/ACFS0002p1

Auf den übrigen Cluster Knoten

# oracleasm scandisks

Im ASM entsprechend einbinden

Das Einbinden geht am einfachsten im SQLPLUS, wenn man mit "/ as sysasm" angemeldet ist.

SQL> alter diskgroup ACFSDG add disk 'ORCL:ACFS0002', 'ORCL:ACFS0001';

zuletzt kann man nachsehen wie weit der ASM schon mit der Einbindung (rebalancing) ist:

SQL> select * from v$asm_operation;

Der zusätzliche Diskspace steht schon nach einigen Sekunden zur Verfügung, die volle Performance haben Sie erst, wenn die "Rebalance" Operation beendet ist.

Breadcrumb

ASM dynamisch erweitern