Die Zeiten ändern sich.
Dieser Beitrag scheint älter als 15 Jahre zu sein – eine lange Zeit im Internet. Der Inhalt ist vielleicht veraltet.
Gekürzte und etwas veränderte Dokumentation eines Projekts der Firma Sylphen, welches ich durchgeführt habe. Achtung! Diese Informationen sind relativ alt und ich würde es heute auch nicht mehr so machen. Wer keine Angst vor Microsoft hat, sollte sich auf jeden Fall den kostenlosen Hyper-V Server anschauen.
Projektbeschreibung
Aus Platz-, Kosten- und Energieeffizienzgründen sollen die bestehenden physikalischen Server eines Unternehmens virtualisiert und auf einem einzigen physikalischen Server in virtuellen Maschinen installiert werden.
Weiterhin soll ein Backupserver zur Verfügung gestellt werden, der bei einem Ausfall des Hauptservers dessen Arbeit übernimmt, so dass ein unterbrechungsfreier Arbeitsfluss gewährleistet wird. Hier wird ein Distributed Replicated Block Device (DRBD) angestrebt, welches, ähnlich einem RAID1-System, für Redundanz im Serverbetrieb sorgt und somit eine optimale Lösung für einen Ausfallserver darstellt.
Lösungsansätze
In Betracht kamen zwei Lösungsansätze:
- Synchronisierung des Hauptservers mit dem Ausfallserver über rSync
- Einsatz eines DRBD
Aufgrund der großen Datenmengen würde rSync schnell an seine Grenzen geraten, insbesondere da virtuelle Maschinen teilweise sehr groß (10 GB und mehr) werden können. Würde nun während einer Synchronisierungsphase der Hauptserver ausfallen, wäre die virtuelle Maschine, die gerade synchronisiert wird, auf dem Ausfallserver ebenfalls defekt. Der entscheidende Vorteil von DRBD ist jedoch aufgrund der Ähnlichkeit zu einem RAID1, dass hier jedes geänderte Bit einzeln übertragen wird und bei Ausfall des Hauptservers das Backup nur wenige Sekunden alt ist und die Arbeit nach nur einer kurzen Unterbrechung direkt wieder an der Stelle aufgenommen werden kann, die zum Zeitpunkt des Ausfalls bestand.
Der Einsatz von DRBD ist somit die geeignetste Lösung.
Realisierung
Grundsystem
Als Grundsystem wird ein Debian 5.0 (Lenny) 64bit installiert, auf dem der VMware-Server installiert wird. Da das Betreiben eines VMware-Servers auf dem Host-System keine großen Ansprüche hat, reicht die Basisinstallation des Debian-Systems.
Dabei werden dem System eine statische IP sowie ein Hostname zugewiesen. Der Server erhält folgende Netzwerkkonfiguration für die erste Netzwerkkarte (eth0):
Hostname: hauptserver
IP: 192.168.0.11
Subnetzmaske: 255.255.255.0
Standardgateway: 192.168.0.254
Die Rolle des Standardgateways übernimmt hier der vorhandene DSL-Router.
Es wird zusätzlich zu root der Benutzer vmware eingerichtet.
Um zu gewährleisten, dass keine aktuell bekannten Probleme den Betrieb stören, wird ein Update des Debian-Systems mit apt-get update durchgeführt.
Der Backupserver erhält die gleiche Konfiguration wie der Hauptserver. Einzig die IP-Adresse und der Hostname werden anders gewählt:
Hostname: ausfallserver
IP: 192.168.0.12
DRBD
Auf beiden Systemen kann nun DRBD installiert werden. Dazu ist es notwendig, noch einige Pakete zu installieren:
apt-get install make gcc flex drbd8-utils drbd8-modules-2.6-686
apt-get install linux-headers-2.6.26-686 psmisc build-essential
Es wird zunächst in das Verzeichnis /usr/src gewechselt, um die Source-Dateien von DRBD herunter zu laden und zu entpacken:
wget http://oss.linbit.com/drbd/8.3/drbd-8.3.1.tar.gz
tar -xzf drbd-8.3.1.tar.gz
DRBD soll als Modul gestartet werden, also nicht direkt in den Kernel eingebunden werden. Deshalb wird folgender Befehl ausgeführt:
cd drbd-8.3.1
make clean all
Ist die Kompilierung zum Modul erfolgreich verlaufen, wird das Modul im System installiert:
make install
Beide Systeme erhalten nun auf der zweiten Netzwerkkarte IP-Adressen, um miteinander kommunizieren zu können. Die zweite Netzwerkarte ist insofern nützlich, als das der gewöhnliche Netzwerk-Verkehr durch das DRBD nicht eingeschränkt wird.
Das Hauptsystem, hauptserver, erhält die IP-Adresse 192.168.1.11 auf eth1 und der Backupserver, ausfallserver, erhält die IP-Adresse 192.168.1.12 auf eth1.
Wichtig ist es, in die Datei /etc/hosts beide Server mit ihren Adressen auf eth1 einzutragen, um später eine Namensauflösung zu ermöglichen:
192.168.1.11 hauptserver 192.168.1.12 ausfallserver
Die Systeme werden direkt miteinander verbunden, um den Umweg über einen Switch zu vermeiden, womit auch eine potentielle Problem- oder Fehlerquelle ausgeschlossen wird.
Nach der Installation des DRBD-Moduls und der Konfiguration der Netzwerkumgebung wird die Datei /etc/drbd.conf auf jedem Server angepasst.
global {
usage-count no;
}
common {
protocol C;
}
resource r0 {
on hauptserver {
device /dev/drbd0;
disk /dev/sdb;
address 192.168.1.11:7789;
meta-disk internal;
}
on ausfallserver {
device /dev/drbd0;
disk /dev/sdb;
address 192.168.1.12:7789;
meta-disk internal;
}
}
Um das DRBD zu initialisieren, wird der Befehl drbdadm up r0 ausgeführt. Dieser Befehl beinhaltet die einzelnen Befehle create-md, attach, syncer und connect. Mit create-md werden die Metadaten des DRBD erstellt. Der Befehl attach asoziiert das DRBD mit seinem Gegenpart, während syncer die die Synchronisierungsparameter setzt und connect schließlich die Verbindung zum Gegenpart herstellt.
Um zu prüfen, ob das DRBD erfolgreich initialisiert wurde, wird der Befehl cat /proc/drbd eingegeben. Das Ergebnis sieht ungefähr wie folgt aus:
version: 0.7.22 (api:79/proto:74)
SVN Revision: 2554 build by root@hauptserver, 2009-06-19 20:47:34
0: cs:Connected st:Secondary/Secondary ld:Inconsistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:752 lo:0 pe:0 ua:0 ap:0
Um dem DRBD nun noch mitzuteilen, welches System das Primärsystem ist, wird folgender Befehl auf hauptserver eingegeben:
drbdadm -- --overwrite-data-of-peer primary r0
DRBD beginnt nun, sich zu synchronisieren, was einige Minuten in Anspruch nimmt. Das DRBD ist somit erschaffen.
Im Anschluss wird das DRBD mit einem Dateisystem zu versehen, damit es verwendet werden kann:
mkfs.ext3 /dev/drbd0
Heartbeat
Damit ausfallserver im Notfall als Ausfallserver einspringen kann, ist es notwendig, zusätzlich ein Heartbeat-Service einzurichten. Andernfalls würde das DRBD nur ein nicht-lesbares Device auf ausfallserver zur Verfügung stellen.
Zunächst wird Heartbeat auf beiden Systemen installiert:
apt-get install heartbeat-2
Für die Konfiguration des Heartbeat-Services werden nun auf hauptserver die Konfigurationsdateien erstellt:
cd /etc/ha.d
cp -a /usr/share/doc/heartbeat-2/authkeys .
chmod 0600 authkeys
cp -a /usr/share/doc/heartbeat-2/ha.cf.gz .
gunzip ha.cf.gz
cp -a /usr/share/doc/heartbeat-2/haresources.gz .
gunzip haresources.gz
Die Datei ha.cf wird folgendermaßen angepasst:
logfacility local0 ucast eth1 192.168.1.12 auto_failback on node hauptserver node ausfallserver
Die Datei haresources wird mit folgenden Werten gespeichert:
hauptserver drbddisk::r0 \ Filesystem::/dev/drbd0::/data::ext3 \
Zum Abschluss der Grundkonfiguration wird in der Datei authkeys noch die Authentifizierungsmethode gewählt. Da es sich um eine vertrauenswürdige Umgebung handelt, wird die einfachste Methode „CRC“ gewählt:
auth 1 1 crc
Anschließend werden die Konfigurationsdateien, die auf beiden Servern, mit einer Ausnahme in der ha.cf, identisch sein müssen, nach ausfallserver übertragen:
scp ha.cf haresources authkey ausfallserver$PWD:
Auf ausfallserver wird in der ha.cf die IP-Adresse auf 192.168.1.11 geändert.
Initial wird der Heartbeat-Service mit folgendem Befehl auf beiden Systemen gestartet:
/etc/init.d/heartbeat
Unter /data ist nun der Speicherplatz vorhanden, der für die VMs genutzt werden soll.
VMware
Zur Installation des VMware-Servers sind weiterhin noch zusätzliche Pakete notwendig, die noch nachinstalliert werden müssen:
apt-get install psmisc build-essential
Vorbereitend zur Installation des VMware-Servers wird das Verzeichnis /data/VMs erstellt, in dem später die virtuellen Maschinen gespeichert werden sollen.
Der VMware-Server befindet sich bereits auf einer CD, die in das System gemounted wird. Das VMware-Server-Paket wird nach /tmp kopiert und dort entpackt.
cd /tmp
tar xvfz VMware-server-2.0.1-156745.x86_64.tar.gz
Nach dem Entpacken des Paketes wird der VMware-Server installiert.
cd VMware-server-2.0.1-156725.x86_64
./vmware-install.pl
Alle Abfragen, die das Installationsscript stellt, werden mit den Standardwerten beantwortet. Die Annahme der Lizenzvereinbarung wird mit der Eingabe „yes“ bestätigt. Bei der Abfrage nach dem Speicherort für die virtuellen Maschinen wird der Pfad /data/VMs angegeben.
Der Abschluss der Installation ist die Eingabe Seriennummer für den VMware-Server.
Nun können über die Weboberfläche des VMware-Servers (hier https://192.168.0.11:8333) die virtuellen Maschinen angelegt werden.
Fehlervermeidung und -behebung
Die virtuellen Maschinen werden bei einem Ausfall des primären Servers automatisch auf dem Sekundärserver gestartet. Da vorher in der Regel kein Beenden der virtuellen Maschinen auf dem Primärsystem durchgeführt wurde, kann es dazu kommen, dass die Dateisysteme der virtuellen Maschinen inkonsistent werden. Nach Möglichkeit sollten deshalb so bald wie möglich die virtuellen Maschinen neu gestartet werden, um Inkonsistenzen durch Checkdisk zu beheben.
Sollte die Verbindung zwischen beiden Systemen unterbrochen werden, starten sich die virtuellen Maschinen auf dem Sekundärsystem automatisch, wodurch jeder virtuelle Server nun zweimal im Netzwerk vorhanden ist. In diesem Fall müssen die virtuellen Maschinen auf dem Sekundärsystem manuell wieder heruntergefahren werden. Abhilfe kann hier die Implementierung von STONITH (Shoot the other node in the head) schaffen.
Um weitere Probleme zu vermeiden, sollte man, wenn nötig, immer zuerst das Sekundärsystem herunter fahren und danach das Primärsystem. Bei der Startreihenfolge ist die umgekehrte Reihenfolge zu beachten. Zuerst sollte das Primärsystem gestartet werden, danach erst das Sekundärsystem.
3 comments on “Redundante Servervirtualisierung”