Architektur

Die beiden physischen Clusterknoten in diesem Artikel-Beispiel verfügen über jeweils vier Netzwerkkarten »eth0« bis »eth3« . Die erste ( »eth0« ) und dritte ( »eth2« ) Netzwerkkarte sind dabei zu einem virtuellen Bond-Device »bond0« zusammengeschaltet. Dieses Device ist über eine Bridge »br0« mit einem öffentlichen Netzwerk verbunden. Über dieses Netzwerk ist beispielsweise der Zugriff auf einzelne Applikationen innerhalb der virtuellen Maschinen möglich.

Ein zweites Bond-Device »bond1« besteht aus der zweiten ( »eth1« ) und vierten ( »eth3« ) Netzwerkkarte. Dieses Bond-Device gehört zum privaten Clusternetzwerk. Über dieses Netz läuft die komplette Cluster-Kommunikation der einzelnen Knoten. Hierzu zählen auch die Kommunikation der einzelnen Fencing-Agents sowie der Netzwerkverkehr zum iSCSI-Server. Das Zusammenschalten der einzelnen Netzwerkkarten zu einem virtuellen Bond-Device ist deshalb notwendig, damit nicht die Netzwerkkarten den Single Point of Failure (SPoF) darstellen. Was bringt es sonst, sämtliche Systeme hochverfügbar zu gestalten, wenn die Systeme beim Ausfall einer Netzwerkkarte nicht mehr zu erreichen sind.

Unter Linux gibt es dafür mit dem Kernel-Bonding-Treiber eine bewährte Lösung. Hierbei bilden mehrere Netzwerkkarten ein neues, virtuelles Device. Je nach Bonding-Modus fließen die Daten im Round-Robin-Verfahren oder nach dem Master-Slave-Prinzip über die einzelnen Karten. Für Zugriffe auf den iSCSI-Server steht alternativ die Multipathing-Funktion des Linux-Kernel-Device-Mappers bereit. Ähnlich wie beim Bonding führen auch hier mehrere Pfade zum Ziel. Fällt ein Pfad aus, ist der Zugriff auf die Daten immer noch über die verbleibenden Pfade möglich.

Als Backend-Speicher für die virtuelle Maschinen-Instanz kommen entweder Imagedateien oder Blockdevices auf einem gemeinsam genutzen Datenspeicher in Frage. Blockdevices in Form von logischen Laufwerken, wie sie der Cluster Logical Volume Manager (CLVM) zur Verfügung stellt, sind hier die erste Wahl. Im Vergleich zu Imagedateien oder Raw-Devices haben logische Laufwerke den Vorteil, dass sie ohne den zusätzlichen Overhead eines Cluster-Dateisystems auskommen. Außerdem steht beim Einsatz von CLVM auch dessen Snapshot-Funktion zur Verfügung. Dies ist vor allem zum Sichern virtueller Maschinen interessant.

Die Konfiguration des CLVM ist nahezu identisch mit der von Einzelsystemen. Ein Unterschied besteht in der Art und Weise, wie der CLVM mit Lock-Informationen für Dateizugriffe umgeht. Die Synchronisation dieser Informationen zwischen den einzelnen Clusterknoten ist Aufgabe des CLVM. Somit ist jedes System über entsprechende Datenspeicher-Zugriffe der anderen Systeme informiert. Zur Konfiguration ist auf allen Knoten des Clusters das Paket »lvm2-cluster« zu installieren. Über den Aufruf »lvmconf« aktiviert der Admin dann die entsprechende Locking-Bibliothek ( Listing 1 ). Beim Einsatz des CLVM ist das Cluster-weite Locking (Type 3) zu aktivieren. Die Standardeinstellung des Logical Volume Manager (LVM) ist das lokale File-Locking (Type 1).

Konfiguration

Bevor es an die Konfiguration der virtuellen Systeme geht, ist im ersten Schritt das iSCSI-System einzurichten. Bei iSCSI handelt es sich um ein in RFC 3720 definiertes Verfahren, das herkömmliche SCSI-Befehle über ein TCP/IP-Netzwerk überträgt. Der klassische SCSI-Controller heißt hier Initiator, das Speichermedium Target. Der Vorteil von iSCSI ist, dass sich große Speichernetzwerke mit einer bereits vorhanden Infrastruktur betreiben lassen.

Als Netzwerkkarten bieten sich eventuell TCP/IP-Offload-Karten an, um die CPUs der eingesetzten Rechner zu schonen. Alternativ gibt es auch dedizierte iSCSI-Hardware, die jedoch nicht gerade billig ist, sodass für erste Tests durchaus vorhandene Hardware zum Einsatz kommen kann. Für das Server-Setup gibt es in Linux das Paket »scsi-target-utils« , das üblicherweise in den Repositories der meisten Distributoren enthalten ist. Nach dessen Installation muss der Admin auf dem iSCSI-Server ein entsprechendes Blockdevice erzeugen, das dann über das iSCSI-Protokoll den Clients zur Verfügung steht. Bei dem Device sollte es sich im besten Fall um ein redundantes Hardware-Raid handeln, da ansonsten die exportierte Festplatte wieder einen Single Point of Failure darstellt. Mit wenigen Kommandos ist dann der iSCSI-Server wie in Listing 2 zu konfigurieren.

Der erste Befehl startet den Target-Daemon und aktiviert ihn für den nächsten Reboot. Zeile 2 erzeugt das iSCSI-Target, das durch eine eindeutige ID und einen Namen gekennzeichnet ist. Clients nutzen diese Identifikationsmerkmale, um später Zugriff auf das Target zu erhalten. Im nächsten Schritt ordnet der Admin diesem Target ein oder mehrere lokale Blockdevices des Servers zu. Abschließend ist es möglich, den Zugriff auf den Server mit Hilfe von Access-Control-Listen (ACL) einzuschränken. Im Beispiel bekommt jedoch jeder Rechner Zugriff auf den Server. Hat alles funktioniert, sollte der Aufruf von »tgtadm« die fertige Konfiguration anzeigen ( Listing 3 ).