Netzwerk-Bonding

Damit nicht die Netzwerkkarten und somit der Anschluss an das Cluster- und Storage-Netzwerk einen Single Point of Failure bilden, sind auch diese redundant auszulegen. Idealerweise ist dabei jede Netzwerkkarte mit einem anderen Switch verbunden, um auch hier Ausfälle unbeschadet zu überstehen. Unter Linux dient für das Zusammenlegen von Netzwerkkarten üblichweise das Bonding-Modul des Kernels.

Im Setup kommt der Master-Slave-Modus zum Einsatz, da hierfür keine besondere Konfiguration der Netzwerk-Switches notwendig ist und dieser den Ausfall einer Karte verschmerzen kann. Das Listing 4 zeigt beispielhaft die Konfiguration für die erste Netzwerkkarte in der Datei »/etc/sysconfig/network-scripts/ifcfg-eth0« . Alle anderen Karten des gleichen Bond sind entsprechend konfiguriert. Listing 5 zeigt die Konfiguration »/etc/sysconfig/network-scripts/ifcfg-bond0« für das Bond-Device. Über die Anweisung »BONDING_OPTS« ist der gewünschte Mode einzustellen.

Eine detaillierte Beschreibung mit allen Konfigurationsmöglichkeiten zum Bonding-Treiber steht im Kernel-Dokumentationsordner [5] . Im laufenden Betrieb liefert die Datei »/proc/net/bonding/bond0« hilfreiche Informationen zum Status des Device und seiner Slaves.

Bonding virtuell

Was für den iSCSI-Server gilt, das gilt genauso für die Clusterknoten selbst. Um einen SPoF im Netzwerk zu vermeiden, sind sowohl die Netzwerkkarten für das öffentliche Netzwerk ( »eth0« und »eth2« ) als auch die Karten für das Cluster- und Storage-Netzwerk ( »eth1« , »eth3« ) zu einem virtuellen Bond-Device zusammenzulegen. Die Konfiguration erfolgt entsprechend der Bonding-Konfiguration des iSCSI-Server.

Damit nun auch auf den Clustersystemen das exportierte iSCSI-Device zur Verfügung steht, ist im nächsten Schritt das Paket »iscsi-initiator-utils« zu installieren. Auch dieses findet sich in den Standard-Software-Repositories der meisten Distributoren. Die folgenden Kommandos erlauben dann den Zugriff auf das exportierte iSCSI-Target ( Listing 6 ).

Hier zeigt ein iSCSI-Discovery alle Targets auf dem angegebenen Server an, bevor im nächsten Schritt das Login auf dem Server erfolgt. Danach steht das exportierte Device lokal zur Verfügung. Der Aufruf von »fdisk -l« sollte nun neben dem lokalen Device auch das iSCSI-Device auflisten. Aus diesem Device setzt sich nachher die Volume Group des Linux Device-Mappers zusammen.

Wie beim LVM üblich erfolgt deren Konfiguration über folgende Kommandos:

# pvcreate /dev/sdb1
# vgcreate vg_cluster /dev/sdb1
# lvcreate -n lv_vm1 -L 50G vg_cluster
# lvcreate -n lv_vm2 -L 50G vg_cluster

Der erste Befehl hinterlegt die notwendige LVM-Signatur auf der ersten Partition des eingebundenen iSCSI-Device. Im nächsten Schritt erzeugt der Aufruf von »vgcreate« die Volume-Gruppe »vg_cluster« , die aus einem einzelnen Device besteht. Abschließend erzeugt »lvcreate« die logischen Laufwerke, die später als Backend für die virtuellen Maschinen-Instanzen dienen. Damit die so erzeugten logischen Laufwerke allen Clusterknoten zur Verfügung stehen, ist der »clvmd« -Dienst auf allen Clusterknoten zu starten. Dies ist jedoch erst nach der Einrichtung des Clusters möglich.