zittersplitter.de

Ich nutze für meine GPFS Tests HP Hardware.

Aus dem angehängten Disk Array schneide ich mir mittels hpacucli Raid5s zurecht und möchte die in GPFS nutzen. Typischerweise linkt hpacucli seine Devices nach /dev/cciss/*.

 

 

 

root@gpfs01:/dev/cciss# ls -la

total 0

drwxr-xr-x 2 root root 260 Jun 26 18:12 .

drwxr-xr-x 15 root root 2960 Jun 26 17:43 ..

brwxrwxr-x 1 root disk 104, 0 Jun 26 11:11 c0d0

brwxrwxr-x 1 root disk 104, 1 Jun 26 11:11 c0d0p1

brwxrwxr-x 1 root disk 104, 2 Jun 26 11:11 c0d0p2

brwxrwxr-x 1 root disk 104, 3 Jun 26 11:11 c0d0p3

brwxrwxr-x 1 root disk 104, 5 Jun 26 11:11 c0d0p5

brwxrwxr-x 1 root disk 104, 16 Jun 27 17:58 c0d1

brwxrwxr-x 1 root disk 104, 32 Jun 27 17:58 c0d2

brwxrwxr-x 1 root disk 104, 48 Jun 27 17:58 c0d3

brwxrwxr-x 1 root disk 104, 64 Jun 27 17:58 c0d4

brwxrwxr-x 1 root disk 104, 80 Jun 27 17:58 c0d5

brwxrwxr-x 1 root disk 104, 96 Jun 27 17:58 c0d6

root@gpfs01:/dev/cciss#

 

Meine Reihe GPFS Devices ist die c0d1-6.

Im Diskfile gebe ich den absoluten Pfad der Disk an, somit sieht ein Eintrag wie folgt aus:

 

/dev/cciss/c0d1:::dataAndMetadata::gpfs1nsd:

…

…

 

Jetzt bauen wir die NSDs

 

root@gpfs01:~/GPFS-Files# mmcrnsd -F /root/GPFS-Files/NSDfile -v no

UTF-8: unknown locale

UTF-8: unknown locale

mmcrnsd: Processing disk cciss/c0d1

mmcrnsd: Processing disk cciss/c0d2

mmcrnsd: Processing disk cciss/c0d3

mmcrnsd: Processing disk cciss/c0d4

mmcrnsd: Processing disk cciss/c0d5

mmcrnsd: Processing disk cciss/c0d6

mmcrnsd: Propagating the cluster configuration data to all

affected nodes. This is an asynchronous process.

root@gpfs01:~/GPFS-Files#

 

Die NSDs werden dann sauber erstellt.

 

root@gpfs01:~/GPFS-Files# mmlsnsd

File system Disk name NSD servers

—————————————————————————

(free disk) gpfs1nsd (directly attached)

(free disk) gpfs2nsd (directly attached)

(free disk) gpfs3nsd (directly attached)

(free disk) gpfs4nsd (directly attached)

(free disk) gpfs5nsd (directly attached)

(free disk) gpfs6nsd (directly attached)

root@gpfs01:~/GPFS-Files#

 

Will man nun ein FS erstellen läuft man in folgenden Fehler:

 

root@gpfs01:~/GPFS-Files# mmcrfs fs1 -F NSDfile -T /gpfs -B 512K -A yes

Unable to open disk ‘ gpfs5nsd on node ep-gpfs01-data.

No such device

Unable to open disk ‘gpfs3nsd’ on node ep-gpfs01-data.

No such device

Unable to open disk ‘gpfs2nsd’ on node ep-gpfs01-data.

No such device

Unable to open disk ‘gpfs4nsd’ on node ep-gpfs01-data.

No such device

Unable to open disk ‘ gpfs1nsd’ on node ep-gpfs01-data.

No such device

Unable to open disk ‘gpfs6nsd’ on node ep-gpfs01-data.

No such device

Error accessing disks.

mmcrfs: tscrfs failed. Cannot create fs1

mmcrfs: Command failed. Examine previous error messages to determine cause.

root@gpfs01:~/GPFS-Files#

 

Das hat mich einen guten Tag gekostet, weil ich davon ausging, dass GPFS die Disks ja schon durch den obigen Task kennt und ich mit „Systemdevices“ nichts mehr zu tun habe. Leider ist dem nicht so, da auch der Devicescan nur die Devices in /dev erkannte, aber nicht in dessen Subfoldern.

Also muss man dem GPFS irgendwie beibringen auch in Subfoldern zu suchen.

 

Aus den Sample-Configs nimmt man sich die nsddevices, editiert die einfach passend und schubst sie nach /var/mmfs/etc/

 

root@gpfs01:~# cp /usr/lpp/mmfs/samples/nsddevices.sample /var/mmfs/etc/nsddevices

 

In die nsddevices gibt man an der richtigen Stelle folgenden Fetzen an:

 

osName=$(/bin/uname -s)

 

if [[ $osName = Linux ]]

then

for x in /dev/cciss/c0d* ; do

echo “$x generic”

done

fi

 

Mit dem kleinen Hack-Dings sind nun die, die wir brauchen sichtbar. Kleiner Benefit meiner Faulheit: Es sind nur die, die vom RAID-Controller kommen für GPFS sichtbar ;)

 

root@gpfs01:~/GPFS-Files# mmdevdiscover

/dev/cciss/c0d0 generic

/dev/cciss/c0d0p1 generic

/dev/cciss/c0d0p2 generic

/dev/cciss/c0d0p3 generic

/dev/cciss/c0d0p5 generic

/dev/cciss/c0d1 generic

/dev/cciss/c0d2 generic

/dev/cciss/c0d3 generic

/dev/cciss/c0d4 generic

/dev/cciss/c0d5 generic

/dev/cciss/c0d6 generic

root@gpfs01:~/GPFS-Files#

 

Jetzt klappt dann auch der mmcrfs!

root@gpfs01:~/GPFS-Files# mmcrfs /gpf1 /dev/gpfs1 -F NSDfile -B 256K

The following disks of gpfs1 will be formatted on node ep-gpfs01-data:

gpfs1nsd: size 471859200 KB

gpfs2nsd: size 471859200 KB

gpfs3nsd: size 471859200 KB

gpfs4nsd: size 471859200 KB

gpfs5nsd: size 471859200 KB

gpfs6nsd: size 471859200 KB

Formatting file system …

Disks up to size 4.5 TB can be added to storage pool system.

Creating Inode File

Creating Allocation Maps

Creating Log Files

Clearing Inode Allocation Map

Clearing Block Allocation Map

Formatting Allocation Map for storage pool system

Completed creation of file system /dev/gpfs1.

mmcrfs: Propagating the cluster configuration data to all

affected nodes. This is an asynchronous process.

root@gpfs01:~/GPFS-Files#

 

Wir benötigen mindestens Kernel 2.6.32 – also entweder ein Debian 6 oder was vergleichbares, aber bitte wirklich auf 2.6er Kernel achten!

Bei den Tests hat sich ergeben, dass die 3er Kernel, insbsondere Debian 7, noch nicht unterstützt werden. Die Unterstützung für Debian 7 soll zum Release von GPFS 4 kommen.

 

 

Zum auflösen der Abhängigkeiten isntallieren wir folgende Pakete:

 

build-essential

linux-headers (für den verwendeten kernel *G*)

ksh

gawk

libaio1

 

GPFS kommt in zwei Stufen:

Der GPFS Folder mit der Basis und dem Update/Patch.

 

Im GPFS_3.5 BASE-Folder benötigen wir nur die gpfs_install-3.5.0-0_x86_64

 

Im aktuellen Patch liegen *.rpm, wie auch *.deb Pakete.

Wir benötigen nur die *.deb Pakete.

 

Nach einem Übertrag der Pakete müssen wir noch ein wenig Vorarbeit leisten.

 

Der Hostname muss in der /etc/hosts eingetragen werden:

 

10.10.10.1 gpfstest gpfstest.fritz.box

 

Als Rootuser muss auch unser SSH-Key ohne Passphrase funktionieren und in der eigenen authorized_keys eingetragen sein.

 

Jetzt können wir den Installer mittels ./gpfs_install-3.5.0-0_x86_64 –text-only anwerfen. Drollig ist allerdings, dass der Installer nicht wirklich installiert, sondern nur nach /usr/lpp/ entpackt.

 

Nachdem der Installer durchgelaufen ist liegen in /usr/lpp/mmfs/3.5 die eigentlichen Pakete…

 

Ein beherztes dpkg -i *.deb installiert das Base 3.5 GPFS letztendlich.

 

root@gpfstest:/usr/lpp/mmfs/3.5# dpkg -l | grep gpfs

ii gpfs.base 3.5.0-3 General Parallel File System

ii gpfs.docs 3.5.0-3 General Parallel File System

ii gpfs.gpl 3.5.0-3 General Parallel File System

ii gpfs.msg.en-us 3.5.0-3 General Parallel File System

 

 

Die Updates aus dem “Updatefolder” können nun ebenfalls mit dpkg -i *.deb installiert werden.

 

root@gpfstest:/usr/lpp/mmfs/3.5# dpkg -l | grep gpfs

ii gpfs.base 3.5.0-10 General Parallel File System

ii gpfs.docs 3.5.0-10 General Parallel File System

ii gpfs.gpl 3.5.0-10 General Parallel File System

ii gpfs.msg.en-us 3.5.0-10 General Parallel File System

 

 

In /usr/lpp/mmfs/src können wir nun mit der eigentlichen Arbeit anfangen:

 

make Autoconfig

make World

make InstallImages

Danach sollten die Module und Co sauber gebaut sein und alles laufen.

Checkt das mit mmfsenv

 

root@gpfstest ~# /usr/lpp/mmfs/bin/mmfsenv

Unloading modules from /lib/modules/2.6.32-5-amd64/extra

Loading modules from /lib/modules/2.6.32-5-amd64/extra

Module Size Used by

mmfs26 1612545 0

mmfslinux 260046 1 mmfs26

tracedev 26157 2 mmfs26,mmfslinux

mmfsenv: This node does not belong to a GPFS cluster.

mmfsenv: The GPFS configuration information is incorrect or not available.

root@gpfstest ~#

 

Jetzt ist ein GPFS auf dem System vorhanden.

Den $PATH sollte man noch um /usr/lpp/mmfs/bin erweitern.

 

Weiter gehts HIER – Clusterconfig & FS erstellen

 

###########

Schönen Dank auch an meinen Kollegen Sascha, der die erste, sehr ausführliche, Version der Installanleitung geschrieben hat.

Diese könnt ihr HIER einsehen

 

 

 

 

Einer meiner XSCFs ist gestern gestorben und zwar durch das OpsCenter. Laut Oracle hat das XSCF in M-Klasse Hardware keine wirkliche HDD sondern einen NAND-Flashspeicher, welcher durch viele RW-Operationen sterben kann – soweit so gut, dass allerdings die OpsCenter Checks für den Tod des XSCF durch Verschleiß des Flashspeichers verantwortlich sind ist mir neu.

Ich kann mir allerdings denken, dass beim damaligen Design der m9000 schlichtweg nicht an das OpsCenter gedacht wurde. Aber, wie schon mein Kollege sagte “Enterprise is was anderes”.

 

Um es klar zu machen: bei m9000 & m8000 weniger ein Problem, die m5000 und darunter haben worst Case keinen online tauschbaren oder rendundanten XSCF und somit ein deutlich höheres Fehlerpotential. Seitens Oracle gibt es “demnächst einen Patch dazu” und bis auf weiteres sollen wir doch einfach OpsCenter nicht mit den XSCFen reden lassen.