Linux Techblog

Hier nun einer der erste Artikel in unserem neuen Linux Techblog, “den besten den gibt auf der Welt ™”.

Kommen wir nun zum eigentlich Thema: einem SAN der Marke Infortrend, ausgestattet mit redundanten Controllern mit jeweils 512 MB Cache Speicher, 12×2.5 Zoll Bay’s, wovon 10 mit 146 GB SAS Festplatten bestückt sind, 2 SuperMicro Server Systemen mit jeweils 16 GiB RAM, 2×1 Intel QuadCore Xeon 5130 CPU, einem Emulex LP11002 4 Gbit Dual-Port HBA und einem 3ware 9650SE RAID-Controller mit jeweils 2×250 GB S-ATA Festplatten im RAID-1 Verbund laufend.

Sozusagen beste Grundvoraussetzungen um einen performanten Virtualisierungs Cluster, was das eigentliche Ziel der Hardwareanschaffung war, aufzubauen.

Angefangen damit einen der beiden Server zu installieren, musste ein passendes OS gewählt werden. Da ich, wie oben schon erwähnt, eher Debian basierende Distri’s favorisiere, fiel die Wahl auf das frisch erschienene Ubuntu 8.04 LTS. Vorteile dabei zu anderen Distri’s ist der Long-Term-Support, also Updates bis 2013, sowie die unterstützung von Seitens VMware für den VMware Server. Kurze Rede, langer Sinn - nach ungefähr einer Halben Stunde partitionierens, wartens und neustartens war Ubuntu 8.04 LTS fertig installiert. Freudigerweise und wie auch nicht anders gewohnt, lieferte Ubuntu für die gesamte Hardware passende Treiber.

Als nächstes war die Planung des SAN’s dran. Wie wird darauf zugegriffen, Shared Storage oder besser eigene LUN’s für die Cluster Node’s? Entschieden habe ich mich im Endeffekt für eine Disk-Volumegroup aus 8 HDD’s auf dem ein RAID10 läuft. Die 2 übrig gebliebenen HDD’s dienen als Global Spares für das RAID10. Da als Filesystem OCFS2, ein Clusterfähiges Filesystem aus dem Hause Oracle, eingesetzt werden soll, wurden pro SAN Controller 2 LUN’s (Channel 0 und Channel 1) erstellt, sodass es möglich sein sollte einen shared Cluster zu betreiben. Wie sich im Nachhinein zeigen wird, eine sehr guter Plan.

Als nächstes machte ich mich daran die Verbindung vom Sever zum SAN herzustellen. Da in den Servern Dual-Port HBA’s verbaut sind und die SAN-Controller jeweils 2 FC-Anschlüsse haben, macht es Sinn
, die LUN’s via Multipathing anzusprechen. Multipathing bedeutet in dem Sinne, dass der HBA-Controller über seine Anschlüsse, dass ihm zugeordnete LUN doppelt sieht, er kennt also mehrere Pfade zum Ziel. Dies bringt den Vorteil, jenachdem wie man es konfiguriert, dass die Anbindung an’s SAN Hochverfügbar und Performant ist.

Da die LUN’s über den HBA als ganz normale SCSI-Devices bereitgestellt werden, hat man nach dem erstellen der LUN’s im SAN, einfach 2 /dev/sdx Devices. Um auf diesen OCFS2 installieren zu können, benötigen wir als erstes die ocfs2-tools die man via

aptitude install ocfs2-tools

installieren kann. Dabei ist natürlich zu beachten das der Kernel ocfs2 als Filesystem überhaupt unterstützt. Ansonsten besteht noch die Möglichkeit die Sourcen bei Oracle herunter zu laden und selbst zu kompilieren. Da Ubuntu 8.04 LTS dies von Haus aus unterstützt, musste ich mir darum keine sorgen machen. Um nun ocfs2 auf das LUN’s zu bekommen, muss man als erstes eine Partition auf dem vom HBA bereitgestellten SCSI-Devices installieren. Mit fdisk -l sollte man mehrere SCSI-Devices angezeigt bekommen, wobei bei meiner Konfiguration 2 Devices ohne Partitionierung erschienen, recht es auf einem der Devices eine Partition zu erstellen. Eine neue Partition auf dem Device kann man z.B. via cfdisk /dev/sdx vom Type Linux (82) erstellen. Diese kann man dann via

mkfs.ocfs2 /dev/sdx1

mit dem ocfs2 Filesystem beschreiben. Danach erstellt man sich eine cluster.conf und legt diese nach /etc. Ein Beispiel für eine cluster.conf findet man unter /usr/share/doc/ocfs2-tools/cluster.conf.example. Um nun zu testen ob alles geklappt hat, lädt man als erstes via

/etc/init.d/o2cb start

die benötigten Kernel Module sowie die Cluster-Management Software um dann via

mount -t ocfs2 -o rw,_netdev /dev/sdx1 /mnt

die ocfs2 Partition zu mounten.

Die Realisisierung von Multipathing wollte ich erst über den vom SAN mitgelieferten Eon-Path Treiber realisieren. Da dieser jedoch nur unter RHEL5 und SLES10 zum laufen zu bekommen ist und wildes patchen an den Sourcen nicht’s brachte musste eine andere Lösung herhalten.

Dank Googles hilfe kam ich dann auf DM-Multipath einem Device-Mapper Kernel Modul, welches es ermöglicht SAN unabhängiges multipathing zu betreiben. Also ganz fix via

aptitude install multipath-tools

die Userspace Programme installiert. Dank einer sehr guten Anleitung ging die Installation der Multipath-Tools ohne größere Probleme von statten. Nach anlegen und ändern der /etc/multipath.conf hat man nach einem Neustart ein neues Devicemapper Device unter /dev/mapper/. Um jetzt noch die gewünschte Partition zur Verfügung zu stellen, auf der sich das ocfs2 Filesytem befindet, führt man

kpartx -a /dev/sdx

aus. Diese Tool erstellt ein neues Device unter /dev/mapper/, welches Ihr nun mounten könnt. Nach einem erneuten reboot , solltet ihr nun via multipath -ll zwei Pfade zum SAN sehen.

Nachdem das ganze nun klappt, können erste Test der “Anbindung” gemacht werden. Und hier war der Punkt an dem ich echt erstaunt war. Ich startete den Test mit dd und dem folgenden Aufruf:

dd if=/dev/zero of=./10G bs=1M count=10000

Das ergebnisse erfreute mich: 10485760000 bytes (10.0 GB) copied, 36.1837 s, 283.0 MB/s. Auch die Ergebnisse mit bonnie konnten Sich blicken lassen, da bonnie mir mit 273 MB/s ein ungefähr gleiches Ergebniss bestätigte. Nach der Installation und Konfiguration des 2ten Servers, kamen mit bonnie, beim gleichzeitigen schreiben unter Volllast auf das SAN, immer noch gute 47 MB/s raus.

Ich kann also nur jedem raten, wer einmal die Zeit und die passende Hardware hat, dies mal auszuprobieren. Im zusammenspiel mit einem SAN macht multipathing und ocfs2 eine echt gute Figur. Bei Fragen nach der genauen Konfigurationen und anderen Sachen zu diesem Projekt, könnt Ihr euch gerne melden.

MfG Maddin