Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 4
DRBD, OpenVZ und Heartbeat
OpenVZ
Den OpenVZ-fähigen Kernel haben wir bereits. Es ist nun an der Zeit, die zugehörigen Tools zu installieren:
apt-get install vzctl vzquota
Debian installiert eine Hierarchie von Konfigurationsdateien unter /etc und eine weitere Datei-Hierarchie unter /var/lib/vz. Beides wollen wir unter /vz ablegen, so dass es auf den anderen Rechner repliziert wird, ohne dass wir Weiteres dazu tun müssen. Zuerst verschieben wir /etc/vz nach /vz/etc/vz:
mkdir /vz/etc cp -a /etc/vz/ /vz/etc/ rm -rf /etc/vz ln -s /vz/etc/vz /etc/vz
Die Verzeichnishierarchie von /var/lib/vz kopieren wir einfach und lassen das Original, das nicht sehr groß ist, an Ort und Stelle:
cp -a /var/lib/vz/* /vz
Die Konfigurationsdatei /vz/etc/vz/vz.conf passen wir daraufhin so an, dass alle Vorkommen von /var/lib/vz durch /vz ersetzt werden.
Nun können wir beginnen, Gastsysteme anzulegen, die unter OpenVZ VEs (Virtual Environments) heißen. Eine VE wird normalerweise durch Kopieren eines Templates erstellt. Templates sind nichts anderes als Dateibäume von bereits installierten und ein wenig vorkonfigurierten Linux-Distributionen. Anleitungen zum Erstellen von Templates bietet die OpenVZ-Seite, doch gibt es auch fertige Templates für eine Reihe von Distributionen wie CentOS 4, Debian 3.1 und 4.0, Fedora Core 3 bis 5, Gentoo 2006, Mandriva 2006, OpenSuse 10 und andere (im Verzeichnis contrib). Meist handelt es sich um Minimalinstallationen. Ich will die VEs unter Debian betreiben und verwende daher debian-3.1-x86_64-minimal.
Die Templates sollten unter /vz/template/cache abgelegt werden. Sie sind als tar.gz gepackt, benötigen also nicht allzuviel Platz, und können beliebig oft verwendet werden. Zum Erzeugen einer neuen VE wird das passende Template ausgepackt und in einer neuen Verzeichnishierarchie abgelegt. Das wird aber nicht von Hand gemacht, denn das Tool vzctl erledigt es für uns:
vzctl create 100 --ostemplate debian-3.1-x86_64-minimal
Die Zahl 100 ist die ID dieser VE und kann im Prinzip beliebig gewählt werden. In späteren Kommandos bezieht man sich auf diese ID. Man kann feststellen, dass das Programm einige Konfigurationsdateien in /vz/etc/vz angelegt bzw. modifiziert und den Verzeichnisbaum der VE unter /vz/private/100 erzeugt hat.
Nun müssen wir noch an anderer Stelle aktiv werden, nämlich bei der Netzwerk-Konfiguration. Das ist nötig, damit das Routen zu und zwischen den VEs funktioniert:
sysctl -w net.ipv4.conf.eth1.proxy_arp=100 sysctl -w net.ipv4.conf.eth2.proxy_arp=100
Das tragen wir in /etc/network/interfaces ein, damit es vom nächsten Boot an automatisch aktiviert wird:
iface eth1 inet static ... up sysctl -w net.ipv4.conf.eth1.proxy_arp=100 pre-down sysctl -w net.ipv4.conf.eth1.proxy_arp=0 iface eth2 inet static ... up sysctl -w net.ipv6.conf.eth2.mtu=9000 up sysctl -w net.ipv4.conf.eth2.proxy_arp=100 pre-down sysctl -w net.ipv4.conf.eth2.proxy_arp=0
Der Eintrag mtu=9000 soll übrigens die Performance bei der DRBD-Replikation erhöhen. Er ist in erster Linie für Gigabit-Ethernet mit nForce-Chips gedacht. Es bleibt noch zu messen, wie er sich tatsächlich auswirkt.
Desweiteren muss auf dem Host das Routing aktiviert werden:
echo 1 > /proc/sys/net/ipv4/ip_forward
Auch dies machen wir dauerhaft, was heutzutage bei den meisten Distributionen durch den Eintrag
net.ipv4.conf.default.forwarding=1
in /etc/sysctl.conf erledigt wird. Wenn wir jetzt noch unserer eben eingerichteten VE eine IP-Adresse und einen Namen geben, können wir auch das Netzwerk mit ihr testen. (Beide Attribute wären nicht notwendig, um nur einmal zu sehen, ob die VE startet. Man kann sich auch ohne Netzwerk in die VE einloggen. Hervorragend, wenn die Netzwerk-Konfiguration beschädigt wurde.)
vzctl set 100 --ipadd 172.30.4.100 --save vzctl set 100 --name 100 --save vzctl start 100
Wie man sieht, habe ich die ID der VE mit ihrem Namen und dem letzten Oktett ihrer IP-Adresse gleichgesetzt. Auch wenn man sich das gut merken kann, ist es oft sinnvoll, die Zuordnung des Namens zur IP-Adresse in seiner Host-Datei (/etc/hosts) oder in seinem DNS zu speichern. Beachtenswert ist auch, dass Host und VE im selben IP-Subnetz liegen. Das funktioniert, auch wenn man es nicht erwartet hätte, ohne Probleme, während das Routing bei der Wahl von anderen Adressbereichen kompliziert werden kann.
Anfänglich funktionierte bei mir das Starten der VE nicht. Eine obskure Meldung »fairsched_chwt: Bad file descriptor« warf mich zurück. Im WWW war wenig zu dieser Meldung zu finden. Ein Update des Kernels auf den aktuellsten OpenVZ-Kernel war offenbar nötig, denn er behob das Problem. Wenn die VE 100 bei Ihnen nun läuft - herzlichen Glückwunsch! Sonst sehen Sie in /var/log/vzctl.log nach. Dort findet sich meist ein Hinweis. Setzen Sie auch möglichst die neueste Version von vzctl ein. Wenn die VE läuft, dann sehen wir ihre Prozesse, darunter auch ihren Init-Prozess:
1 ? Ss 0:00 init [2] 6200 ? Ss 0:00 init [2]
Nun ist es möglich, sich in die VE per ssh einzuloggen. Am besten kopiert man dazu sein lokales Verzeichnis .ssh in den Verzeichnisbaum des VE, also beispielsweise cp -a /root/.ssh /vz/private/1/root. Bei entsprechender Konfiguration kann man sich dann ohne Passwort einloggen. Das Einloggen sollte von jedem Rechner im Netz möglich sein. Nur vom Host aus ist ein Einloggen ohne Netz möglich. Das Kommando hierfür lautet vzctl enter 100.
Ein »top« in der VE zeigt eine Handvoll Prozesse wie syslogd, cron und sshd sowie eine CPU-Auslastung von 0% - wohlgemerkt während die Host-CPU eine Berechnung ausführt und zu 100% ausgelastet ist. Daran kann man sich deutlich machen, dass das /proc-Dateisystem vollständig virtualisiert wurde.
Umbenennen von VEs
Eine Operation zum Umbenennen von VEs gibt es nicht, doch kann man sich an der Anleitung zum Klonen von VEs orientieren. Ursprünglich hatte ich meiner ersten VE die Nummer 1 gegeben. Mit den folgenden Schritten taufte ich sie in 100 um:
vzctl stop 1 mv /etc/vz/conf/1.conf /etc/vz/conf/100.conf mv /vz/private/1 /vz/private/100 vzctl start 100
Kopieren von VEs
Zum Kopieren (Klonen) eines VEs geben wir folgende Kommandos ein. Die vorhandene VE ist in diesem Beispiel 100, die neue 101:
vzctl stop 100 mkdir /vz/root/101 cp /etc/vz/conf/100.conf /etc/vz/conf/101.conf cp -a /vz/private/100 /vz/private/101 vzctl start 100 vzctl set 101 --hostname 101 --save vzctl set 101 --ipdel 172.30.4.100 --save vzctl set 101 --ipadd 172.30.4.101 --save vzctl start 101
Nun laufen originale und geklonte VE nebeneinander; der neuen VE muss man, bevor man sie startet, einen eigenen Namen und eine andere IP-Adresse zuweisen.
Automatisieren des Starts
Ich rekapituliere noch einmal kurz, was wir bisher erreicht haben. Der aktuelle Stand sieht folgendermaßen aus: Nach einem Reboot wird zwar DRBD gestartet, bleibt jedoch auf beiden Servern im Zustand Secondary. Dadurch ist es nicht möglich, die Partition /dev/drbd0 auf /vz zu mounten, folglich kann auch keine virtuelle Maschine starten. Erst wenn das Setzen in den Zustand Primary und das Mounten von Hand ausgeführt sind, können die VEs gestartet werden. Wir wollen es natürlich automatisieren, dass einer der beiden Server in den Zustand Primary geht, /vz mountet und die VEs startet. Dazu könnten wir in die Init-Skripte eingreifen, doch das wäre verfrüht. Um eine echte Hochverfügbarkeitslösung zu erhalten, soll nämlich Heartbeat zum Einsatz kommen, das seinen eigenen Satz von Init-Skripten mitbringt. Deren Einrichtung wird in einem späteren Abschnitt beschrieben. Bis dahin bleiben wir beim manuellen Start.
