High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

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.

Kasten 1: Bridge für das öffentliche Netzwerk

Um auch im öffentlichen Netzwerk keinen SPoF beim Setup der Netzwerkkarten zu haben, kommt ein Bond-Device »bond1« zum Einsatz. Es setzt sich jeweils aus beiden Karten »eth0« und »eth2« zusammen. Die Bridge selbst muss nicht unbedingt eine IP-Adresse erhalten, sollen aber die Clusterknoten aus dem öffentlichen Netzwerk erreichbar sein, ist die Angabe einer IP-Adresse in der Bridge-Konfiguration möglich. Dies nutzt das Beispiel, da die Installationsroutine der virtuellen Maschinen auf einen Rechner im öffentlichen Netzwerk zugreift, der ein Fedora-Installationsrepository sowie Kickstart-Dateien zur automatischen Installation bereitstellt. Die Netzwerk-Init-Skripte sind in wenigen Schritten erzeugt:

/etc/sysconfig/network-scripts/ifcfg-eth0:

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

/etc/sysconfig/network-scripts/ifcfg-eth1:

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"

/etc/sysconfig/network-scripts/ifcfg-br0:

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

Der abschließende Iptables-Befehl leitet den ganzen Netzwerk-Traffic über die Bridge an die virtuellen Maschinen:

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

Schließlich liest ein »service network restart« die Konfiguration ein und startet das Bridge-Device, wie die Ausgabe von »brctl« beweist:

# 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).

Listing 8

virt-install

 

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).

Listing 9

ssh-keygen

 

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).

Listing 10

/root/.ssh/config

 

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.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021