Bei den geschäftskritischen Diensten sind höhere Anforderungen notwendig, als es die Standardlösungen der Firma manitu bieten. Die wichtigsten Kriterien sind hochwertige Serverhardware, redundante Netzteile mit getrennten Stromkreisen, redundante interne Kommunikation (Cross-Over-Kabel und Vlan). Ich spreche hier ausdrücklich von Standardlösungen, Lösungen von der Stange, bzw. Angebote die auf der Homepage zu finden sind. Wir suchten eine kostengünstige Lösung.

Da wir relativ viele Dienste mit geringer Last als virtuelle Maschinen betreiben, benötigten wir eine Virtualisierungslösung. Die Anzahl der virtuellen Maschinen ergibt sich aus der Anzahl der Dienste (ein Dienst pro Server / virtueller Maschine). Ich wählte Xen als Hypervisor.

Im Februar bestellten wir zwei Root-Server XXLx4. Wenig Zeit später waren die Maschinen verfügbar. Danach begann die Qual…

Neben Xen als Hypervisor wählte ich CentOS als Distribution. Nach der Installation über das Rettungssystem von Manitu booteten die Server mit dem Xen-Kernel nicht. Die Server bei Manitu haben keine Remotmanagementkarte, für 25,00 EUR Tagesmiete kann ein KVM-Switch gemietet werden. Mit dem KVM-Switch war das Problem schnell zu finden, der Kernel darf nicht mit acpi=off gestartet werden, was bei Manitu mit dem selbstkompilierten Kernel standardmäßig der Fall ist.

Die nachfolgende Konfiguration lief problemlos.

Durch die Virtualisierung ist die Auswirkung eines Ausfalles eines physischen Servers relativ groß, die Kosten für einen Server jedoch relativ gering. Dadurch betreiben wir alle wichtigen Dienste (also jede VM) in einem Hochverfügbarkeitscluster (HA-Cluster). Sofern der Dienste (die Anwendung) keine Ausfallsicherheit per Design bietet. DNS ist ein klassisches Beispiel bei dem ein HA-Cluster nicht unbedingt notwendig ist.

Auch die Installation und Konfiguration der virtuellen Maschinen, der Cluster und der Anwendungen lief problemlos.

Für ein kleines privates Projekte installierte ich einen Hadoop-Cluster bestehend aus 3 Nodes und führte ein paar Berechnungen aus. Bei den Berechnungen bemerkte ich, dass ein physischer Server nicht mehr reagierte. Der Hard-Reset des manitu Supports bootete den Server wieder. Das Projekt war zu Ende und ich betrachtete die Angelegenheit nicht mehr aktiv.

Der Fehler trat immer wieder auf. Ich teilte die Dienste und die Last auf beide Maschinen auf, so dass eine Lastspitze in einer verteilten Anwendung regelmäßig dazu führte, dass beide Server nicht mehr reagierten. Manchmal konnte ich die Server noch über das Rettungssystem von Manitu zu einem Neustart bewegen – oft musste der Support helfen.

Das Problem bei Manitu musste erst mal warten, da auch die geschäftskritischen Dienste ein neues Rechenzentrum brauchten. Mit der gemachten Erfahrung wählte ich testweise KVM und machte nach der Installation ausgiebige Stresstests. Bis heute keinen Absturz oder ähnliche Probleme die mit Xen auftraten. Wobei ich hier auch schreiben muss, dass es sich um Redhat Enterprise  zertifizierte Dell PowerEdge Server handelt. Weder von der Hardware noch vom Preis vergleichbar mit den Servern bei Manitu.

Wir bestellten einen weiteren Server bei Manitu und wählten diesmal KVM als Hypervisor. Die Umstellung auf KVM war zeitintensiv, da viele Daten kopiert werden mussten und die virtuellen Maschinen so verschoben werden mussten, dass es nicht zu einer längeren Nichtverfügbarkeit kam. Seit einer Woche ist diese Umstellung abgeschloßen und es gab bisher noch keinen Ausfall. KVM läuft äußert stabil, auch Stresstests über einige Tagen liefen problemlos durch.

Der Support von Manitu reagierte während der ganzen Zeit schnell und hilfsbereit.

Unverständnis ruft die Wahl der Festplatten hervor. Bei uns sind in zwei Servern jeweils 4x 2TB Green-Modelle von Western Digital und in dem neueren Server 4x 2TB Samsung  EcoGreen verbaut. Die wenigsten werden doch 4TB (Raid10) oder 8TB (Raid0) in einem Rootserver benötigen und wenn dann noch der Hersteller über die eigenen Festplatten das Folgende schreibt:

Business Critical RAID Environments – WD Caviar Green Hard Drives are not recommended for and are not warranted for use in RAID environments utilizing Enterprise HBAs and/or expanders and in multi-bay chassis, as they are not designed for, nor tested in, these specific types of RAID applications. For all Business Critical RAID applications, please consider WD’s Enterprise Hard Drives that are specifically designed with RAID-specific, time-limited error recovery (TLER), are tested extensively in 24×7 RAID applications, and include features like enhanced RAFF technology and thermal extended burn-in testing.

Dazu kommt noch die schlechte Performance und das “Problem” mit den 4k-Sektoren.

Fazit: Zufrieden, aber nicht uneingeschränkt zu empfehlen – schade eigentlich.

Native Virtualisierung

Gemeinschaft ist eine Asterisk Distribution der Firma Amooma GmbH. Die Virtualisierung eines Asterisk-Servers bietet sich durch die typischerweise geringe Hardwareanforderung und das Bedürfnis nach hoher Verfügbarkeit geradezu an. Zumindest wenn man davon ausgeht, dass man ein Mediagateway für die Umsetzung IP <> ISDN verwendet. Die Virtualisierung einer PCI-Karte ist keine wünschenswerte Aufgabe, das macht keinen Spaß!

Citrix XenServer ist in einer kostenlosen Version auch für den kommerziellen Einsatz nutzbar. Mit der Software erhält man eine ausgereifte Virtualisierungslösung out of the box.

Paravirtualisierung

In diesem Artikel wird erklärt, wie man eine vollständig virtualisierte Linux Distribution in ein paravirtualisiertes System überführt. Gemeinschaft nutzt ein Debian Lenny; die Vorgehensweise unterscheidet sich nicht grundlegend zu anderen Distributionen.

1. Für die Installation der VM muss “Other install media” als Template und der Gemeinschaft Installer als ISO-Image ausgewählt werden.
2. Nach der Installation werden die XenServer Tools und der XenServer Kernel installiert. Dazu die CD mounten oder den Inhalt über scp auf die VM kopieren:
dpkg -i Linux/xe-guest-utilities_5.5.0-458_i386.deb
dpkg -i Linux/debian-generic/linux-image-2.6*

3. Mit der Paravirtualisierung wird sich das Blockdevice der Festplatte von hda in xvda ändern. In /etc/fstab und /boot/grub/menu.lst die entsprechenden Vorkommnisse ändern. Die Datei /etc/fstab ist selbsterklärend, in menu.lst an der folgende Stelle:
   title Debian GNU/Linux, kernel 2.6.29-xs5.5.0.14
root (hd0,0)
kernel /boot/vmlinuz-2.6.29-xs5.5.0.14 root=/dev/xvda1 ro quiet
initrd /boot/initrd.img-2.6.29-xs5.5.0.14

4. Wahrscheinlich wird im XenCenter der login prompt nicht mehr erscheinen, in der Datei /etc/inittab tty1 durch hvc0 ersetzen:
   # Format:
# :::
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
1:2345:respawn:/sbin/getty 38400 hvc0

5. Die VM mit poweroff herunterfahren.

Unter der Konsole des XenServers wird die eigentliche Virtualisierungsmethode umgestellt. Das muss übrigens nicht zwingend auf dem Pool Master durchgeführt werden.

1. Jeder VM ist einer UUID zugeordnet, diese kann mit dem Kommando xe vm-list herausgefunden werden.
2. Jetzt folgt die eigentliche Umstellung der Virtualisierungsmethode:
   xe vm-param-set uuid=<uuid> HVM-boot-policy=""
xe vm-param-set uuid=<uuid> PV-bootloader=pygrub
xe vm-param-set uuid=<uuid> PV-args="-- quiet console=hvc0"

3. Die virtuelle Festplatte ist noch nicht zum Booten bereiten. Für die Aktivierung wird die VBD-UUID benötigt, das Kommando xe vm-disk-list uuid=<uuid> liefert eine Liste der Blockdevices:
   Disk 0 VBD:
uuid ( RO) : <vb-uuid>
vm-name-label ( RO): Other install media (1)
userdevice ( RW): 0Aktivierung des Blockdevices:
   xe vbd-param-set uuid=<vb-uuid> bootable=true

Fertig! Viel Glück mit der Umsetzung.