Login
Login-Name Passwort


 
Newsletter
Werbung

So, 20. Januar 2008, 00:00

Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 7

Prozessor-Upgrade, neues Xen und neue Ideen

Den in Folge 6 vorgestellten Stand unseres virtuellen hochverfügbaren Linux-Servers wollen wir in diesem Artikel weiter ausbauen. Ein Upgrade auf Dual-Core-Prozessoren mit niedrigem Leistungsbedarf führt im Anschluss zu einem Update von Xen und eröffnet für die Zukunft neue Möglichkeiten. Eine Konfiguration für hochverfügbares Routing wird beschrieben.

Einleitung

Dies ist Teil 7 der Workshops »Virtueller hochverfügbarer Linux-Server«. Die weiteren Teile finden Sie über das Inhaltsverzeichnis.

Den Sommer über tat sich nicht viel an meinen Servern. Sie versahen ihren Dienst, und ich war mit zahllosen anderen Dingen beschäftigt und wartete auf neue Prozessoren. Dieser Artikel baut auf der in Teil 6 besprochenen Konfiguration auf. Um sie komplett nachvollziehen zu können, sollten Sie auch Teil 2 und bei Bedarf die anderen Teile lesen.

Neue Prozessoren

Gespannt wartete ich im Sommer darauf, dass AMD seine neuen Vierkern-Prozessoren vorstellen würde, die ja in den AM2-Sockel passen sollten. Etwas enttäuscht war ich dann, als Anfang September die ersten Typen erschienen, jedoch einen Stromverbrauch von 90 Watt und mehr aufwiesen. Mein Ziel war nun eher, den Stromverbrauch zu senken. Zuvor hatte es (kurzzeitig) eine CPU von AMD mit nur 35 Wattt Verbrauch gegeben, doch diese war nirgends aufzutreiben. Mir ist unbekannt, ob diese CPU je über das Ankündigungsstadium hinauskam.

In dieser Zeit kündigte AMD jedoch einen neuen Dual-Core-Prozessor an, der mit 45 Watt auskommen sollte. Er wurde in den Varianten 1,9 GHz (X2 BE-2350) und 2,1 GHz (X2 BE-2350) mit nur geringen Preisunterschieden angeboten. Da ich nicht mehr auf die Quad-Core-Prozessoren warten wollte, von denen auch kein geringerer Energieverbrauch zu erwarten war, schlug ich zu.

Nachdem die guten Stücke angekommen waren und ich einen Rechner aus dem Cluster genommen hatte, um die neue CPU einzubauen, kam die erste Überraschung: Der Rechner fuhr nicht hoch. Ich vermutete sofort, dass es am BIOS liegen musste, und lag damit richtig. Auf der ASUS-Homepage lag ein BIOS-Update bereit. Dummerweise war der Server von ASUS, der offenbar mit Windows-»Technologie« betrieben wird, an diesem Abend gerade unpässlich. Ich fürchtete schon, das ganze Internet nach dem BIOS durchsuchen zu müssen, doch eine Stunde später war der Server schließlich doch wieder erreichbar.

Nun bietet ASUS dummerweise noch kein BIOS-Updateprogramm für Linux an. Ich musste also zu einer DOS-Bootdiskette greifen und das Programm samt BIOS darauf kopieren. Da die beiden Server kein Floppy-Laufwerk haben, musste ich aus meiner Bastelkiste eines herauskramen und anschließen. Schließlich gelang das Flashen und mit dem neuen BIOS erwachte auch die neue CPU zum Leben. Bis dahin waren bereits mehrere Stunden vergangen. Es war ein ebenso unterhaltsamer wie langer Samstagabend mit dem obligatorischen Verfluchungen in Richtung Award (BIOS-Hersteller), ASUS und Microsoft.

Nachdem beide Server wieder liefen, war festzustellen, dass sich die Leistung wie erwartet annähernd verdreifacht hatte. Die Hardware-Unterstützung für die Virtualisierung, die von Xen bereits in Version 3.0 genutzt werden kann, machte sich besonders im Netzwerkbereich bemerkbar, ganz wie ich es mir erhofft hatte. Die Latenzzeiten bei NFS waren verschwunden. Die Geschwindigkeit von NFS über das Gbit-Netzwerk war nun höher als beim Zugriff auf eine lokale Platte.

Virtuelle Maschinen mit mehreren CPUs

Damit die Virtuellen Maschinen (VMs) auch von der höheren CPU-Leistung profitieren können, kann man in der Xen-Konfiguration eine kleine Änderung durchführen. Genau genommen ist es die Konfigurationsdatei der betreffenden VM, in der eine Anweisung zu ändern ist. Statt vcpus = 1 schreiben wir

vcpus = 2

Damit wird die betreffende VM zu einem SMP-Rechner mit zwei Prozessoren. Der eingesetzte Debian-Kernel ist ohnehin SMP-fähig, so dass sich diese Änderung sofort nach dem Neustarten der VM auswirken sollte.

Beim Einsatz eines Hochverfügbarkeitsclusters nicht vergessen, die Änderung auf beiden Hosts durchzuführen!

Xen- und Kernel-Update

Nicht lange nach diesem Update blieb der erste Server mit einer Kernel Panic stehen. Der Trace ließ vermuten, dass es sich um ein Problem im Netzwerktreiber handelte. Normalerweise hätte ich nun einen aktuellen Kernel genommen, da es zwischenzeitlich Verbesserungen an diesem Treiber gegeben hatte. Doch wegen Xen war ich an die Kernel-Version 2.6.18 gebunden.

Ich entschloss mich, erst einmal Xen zu aktualisieren. Da von Debian im September 2007 noch keine Pakete für Xen 3.1 zur Verfügung standen, verwendete ich das Binärpaket von der Xen-Homepage. Packt man dieses aus, legt es ein Verzeichnis dist an. Mit

cd dist; ./install.sh

wird es installiert. Nun müssen wir einen Blick in /boot/grub/menu.lst werfen und sicherstellen, dass folgender Eintrag gebootet wird:

 root (hd0,0)
kernel /boot/xen-3.1.0.gz
module /boot/vmlinuz-2.6.18-xen root=/dev/sda1 ro console=tty0 max_loop=128
module /boot/initrd.img-2.6.18-xen
savedefault

Die Option max_loop=128 sollte Ihnen bekannt vorkommen. Richtig, wir haben sie früher mal von Hand in /etc/modprobe.d/options eingetragen. Nun bereitet uns Xen 3.1 die unerwünschte Überraschung, dass der Loop-Treiber nicht als Modul vorliegt, sondern fest im Kernel eingebaut ist. Damit wird die Modul-Option wirkungslos und wir müssen sie an der Kernel-Kommandozeile angeben.

Der DRBD-Treiber ist leider nicht Bestandteil des Xen-Pakets. Wir müssen ihn daher neu compilieren, wobei wir die neueste Version der 0.7er-Reihe einsetzen. Ein Update auf die inzwischen stabile Nachfolgeversion 8 ist geplant, doch wäre zum jetzigen Zeitpunkt zu kompliziert. Zuviele Änderungen auf einmal können nur zu Chaos führen.

Damit die Compilierung gelingen kann, müssen zwei Voraussetzungen erfüllt sein: Die Kernel-Quellen müssen vorliegen und die Version von GCC muss 3.4 sein, da das Xen-Binärpaket mit dieser Version erstellt wurde. Ersteres erfordert, auch das Quellpaket von Xen 3.1 herunterzuladen und zu entpacken. Nun könnten wir auch Xen komplett mit GCC 4 neu erstellen, doch ich verzichtete darauf. Im Verzeichnis von DRBD genügt nun ein Kommando, das benötigte Modul zu erstellen:

make KDIR=/path/to/xen-3.1.0-src/build-linux-2.6.18-xen_x86_64 CC=gcc-3.4

Dann können wir das Modul auf die beiden Server kopieren:

scp drbd/drbd.ko root@erdbeere:/lib/modules/2.6.18-xen/kernel/drivers/block
scp drbd/drbd.ko root@himbeere:/lib/modules/2.6.18-xen/kernel/drivers/block

Nun ist es an der Zeit, den Server neu zu starten. Meinen Beobachtungen nach macht Heartbeat jedoch Probleme, wenn man einfach neu bootet, weil sich dann der neu gebootete Server wieder meldet, bevor die Migration der VMs auf den anderen Rechner vollendet ist. Die VMs sind noch am Hochlaufen und werden nicht zurück migriert, sondern bleiben auf dem zweiten Server. Daher ist es besser, den ersten Server herunterzufahren und ein paar Minuten zu warten. Wir werden dieses Problem nach dem Update von Heartbeat angehen.

Nach diesem Neustart sollte alles sauber laufen. Offenbar wurde entweder in Xen selbst oder im mitgelieferten Kernel eine Korrektur vorgenommen, so dass kein weiterer Absturz im Netzwerktreiber oder sonstwo vorkam. Erst ein Vierteljahr später stieß ich wieder auf ein Problem, dazu aber später mehr.

Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung