Config verteilen

Wer die Konfigurationsdatei den eigenen Gegebenheiten angepasst hat, kann sie auf alle Clusterknoten verteilen, beispielsweise mit »scp« . Im laufenden Clusterbetrieb lässt sich diese Aufgabe später auch durch »ccs_tool update /etc/cluster/cluster.conf« erledigen. Wichtig dabei ist, dass nach jeder Änderung die Versionsnummer der Konfigurationsdatei erhöht wird, sonst bekommt der Clustermanager von einer Änderung an der Datei nichts mit.

Liegt nun allen Clusterknoten die Datei vor, geht der Cluster mit »service cman start« in Betrieb. Auch der Cluster-fähige Volume Manager (CLVM) ist nun funktionsfähig und nimmt mit »service clvmd start« seinen Betrieb auf. Der Aufruf »clustat« sollte bestätigen, dass beide Knoten aktive Clustersysteme sind.

Bevor es nun an die Konfiguration der virtuellen Maschinen geht, fehlt noch die passende Netzwerkumgebung. Da sich die VMs mit den Clustersystemen in einem Netzwerk befinden sollen, ist das mit einer Bridge zu bewerkstelligen. Diese lässt sich wie in Kasten 1 gezeigt konfigurieren.

DEVICE=eth0
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
SLAVE=yes
USERCTL=no
Master=bond1

DEVICE=eth0
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
SLAVE=yesUSERCTL=no
MASTER=bond1
/etc/sysconfig/network-scripts/ifcfg-bond1:
DEVICE=bond1
ONBOOT=yes
USERCTL=no
BRIDGE=br0
BONDING_OPTS="mode=1 miimon=100"

DEVICE=br0
TYPE=Bridge
IPADDR=192.168.0.100
NETMASK=255.255.255.0
ONBOOT=yes
DELAY=0

# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT

# brctl show
bridge name     bridge id           STP     enabled interfaces
br0             8000.000e0cb30440   no      br0

Um schließlich die eigentlichen virtuellen Maschinen-Instanzen zu erzeugen, stehen wieder mehrere Wege offen. So existiert mit »virt-manager« ( Abbildung 5 ) eine grafische Anwendung, alternativ bietet das Kommandozeilen-Tool »virt-install« eine Vielzahl von Optionen, wie der Aufruf zum Setup der ersten virtuellen Maschine verdeutlicht ( Listing 8 ).

Abbildung 5: Mit virt-manager steht eine grafische Anwendung zur komfortablen Konfiguration von virtuellen Systemen zur Verfügung.

Die Angabe einer Kickstart-Datei ist optional, es lassen sich auch sämtliche Konfigurationsanweisungen für das zu installierende System manuell angeben. Wichtig ist die Angabe der zuvor erzeugten Bridge »br0« und des logischen Laufwerks »lv_vm1« auf dem iSCSI-Server, das nun als Storage-Backend für die virtuelle Maschine dient.

Die XML-basierten Konfigurationsdateien für die so erzeugten virtuellen Maschinen liegen auf dem lokalen Dateisystem im Verzeichnis »/etc/libvirt/qemu« . Dieses ist zwischen allen Clusterknoten, hier also zwischen Host1 und Host2, synchron zu halten.

Nun ist es Zeit, auch den letzten Abschnitt der Cluster-Konfigurationsdatei zu aktivieren. Hierfür entfernt der Admin einfach die Kommentarzeichen und überträgt die neue Konfigurationsdatei mittels »ccs_tool update« auf alle anderen Clusterknoten. Natürlich nicht ohne die Versionsnummer der Datei hochzuzählen. Mittels »service rgmanager« nimmt dann dieser Dienst seinen Betrieb auf.

SSH ohne Passphrase

Da der Cluster-Ressource-Manager zur Migration der virtuellen Maschinen auf SSH zurückgreift, ist für jeden Clusterknoten ein SSH-Schlüsselbund zu erzeugen. Dabei ist darauf zu achten, beim Anlegen des Schlüssels keine Passphrase zu verwenden. Den Schlüssel erzeugt dann einfach »ssh-keygen« ( Listing 9 ).

Den öffentlichen Teil, also die Datei »/root/.ssh/id_rsa_cluster.pub« , verteilt der Admin auf alle Knoten im Cluster. In der SSH-Client-Config »/root/.ssh/config« muss er noch für alle Clusterknoten die Option »StrictHostKeyChecking« deaktivieren ( Listing 10 ).

Alle hier aufgeführten Schritte, also das Anpassen der Config und das Erzeugen der SSH-Schlüssel sowie deren Verteilung, müssen auf allen Clusterknoten erfolgen. Bei einem abschließenden Test sollte das Root-Login via SSH von jedem Clusterknoten zu jedem anderen Knoten ohne Angabe des Passworts möglich sein. Ist dies nicht der Fall, steht Fehlersuche an, sonst wird der Cluster nicht fehlerfrei funktionieren.