Login
Login-Name Passwort


 
Newsletter
Werbung

Fr, 24. November 2006, 00:00

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

Virtualisierung im Vergleich

In dieser Folge der Artikelreihe wird es theoretisch. Verschiedene Virtualisierungslösungen stehen zur Wahl. Zumindest eine Vorauswahl ist nötig, wenn man nicht alle Systeme einzeln ausprobieren will. Dieser Artikel beschreibt die wichtigsten Eigenschaften der verschiedenen Systeme.

Vorwort

Das Projekt, das ich hier beschreibe, heißt nicht ganz ohne Grund »Virtueller hochverfügbarer Linux-Server«. Es soll irgendeine Art von Virtualisierung zum Einsatz kommen, die in der Lage ist, verschiedene Dienste, besonders Web- und Datenbankserver, so anzubieten, als handle es sich um mehrere getrennte Server. Die Trennung muss dabei strikt genug sein, dass einer der virtuellen Server vom Internet her zugänglich ist, der andere jedoch nicht.

Im Artikel »Virtualisierung« haben wir eine grundsätzliche Übersicht gegeben, wie Virtualisierung funktioniert und wie sie realisiert werden kann. Emulation und vollständige Virtualisierung sollen hier aber nicht weiter erörtert werden - Software wie Qemu, VMware oder Parallels ist mit gewissen Leistungseinbußen verbunden und zudem ganz oder in Teilen proprietär.

Im Folgenden beschreibe ich daher die mir bekannten Virtualisierungslösungen für Linux, die nicht in die obigen Kategorien fallen, und stelle abschließend die Features nochmals in einer Übersicht dar. Es handelt sich um Xen, Linux Virtual Server (VServer), FreeVPS und OpenVZ. Die Beschreibungen stellen zunächst reine Theorie dar, da ich nicht alle Lösungen ausprobieren werde. Die Übersicht wird nach Bedarf erweitert und aktualisiert.

OpenPkg

OpenPkg ist mehr eine Distribution oder Paketsammlung, hauptsächlich für Server. Virtualisierung bietet es, anderes als ich ursprünglich dachte, nicht, und damit könnte man es bereits bewenden lassen. Doch wenn wir schon mal dabei sind, können wir gleich noch einen gründlicheren Blick auf OpenPkg werfen.

OpenPkg kann mehrere Instanzen des Systems auf einem Rechner installiert haben. Allerdings kann immer nur eine dieser Instanzen gleichzeitig aktiv sein. Somit ist auch keine Virtualisierung möglich. OpenPkg könnte dennoch für den einen oder anderen Administrator interessant sein, besonders für die, die mit mehreren Betriebssystemen arbeiten (Linux, BSD, Solaris...) und auf allen eine identische Umgebung einrichten wollen. Es bietet geringe Eingriffe ins Hostsystem und Plattformunabhängigkeit, läuft ohne Performanceverlust, nutzt alle CPUs des Systems und benötigt keine Reservierung einer bestimmten Menge RAM oder Festplattenplatz. Ferner kann ich mir gut vorstellen, dass OpenPkg gut mit Virtualisierung harmoniert: Man kann seine virtuellen Maschinen mit einer Minimalinstallation seines Lieblings-Betriebssystems und der Grundinstallation der OpenPkg-Umgebung starten und dann in jeder die benötigte Software mit OpenPkg verwalten.

Nach eigenen Angaben ist OpenPkg ein plattformübergreifendes Paketsystem. Wie eine Linux-Distribution, die funktionell identische Pakete für mehrere Architekturen anbietet, hält OpenPkg Pakete für verschiedene Betriebssysteme bereit. Ein Blick ins Archiv zeigt die weite Spanne von unterstützten Systemen von FreeBSD 5.4 auf x86_64 über Mandriva 10.2 auf x86 bis zu Solaris 8 auf Sparc64. 19 Systeme sind es in OpenPkg 2.5, und für jedes stehen 579 Binärpakete bereit.

Installiert wird OpenPkg am besten in ein separates Unterverzeichnis, beispielsweise /openpkg. Über ein 26 MB großes Shell-Archiv kann man die Quellen der Basispakete entpacken und installieren. Diese liegen in einem eigenen Verzeichnis unterhalb von /openpkg. So lassen sich verschiedene Versionen parallel installieren. Die in einer Instanz gestarteten Programme lassen sich alle gemeinsam mit einem einzelnen Kommando starten und beenden. So kann man binnen Sekunden zwischen zwei Instanzen wechseln, um beispielsweise ein Versionsupdate durchzuführen.

Xen

Xen dürfte unter den hier vorgestellten die umfassendste Virtualisierungslösung sein. Es ist ein Hypervisor, der die Hardware vollständig virtualisiert. Es stellt dem Gastsystem einen vollständigen virtuellen PC mit eigenem BIOS, eigenem Netzwerkanschluss usw. zur Verfügung. Aus diesem Grund kann Xen im Prinzip beliebige Gastsysteme booten. Allerdings muss das Gastsystem so angepasst sein, dass es nicht auf die echte, sondern auf die virtualisierte Hardware zugreift. Das unterscheidet es von VMware oder Qemu, die beliebige Betriebssysteme unmodifiziert ausführen können, dies aber mit Leistungseinbußen bezahlen. Mit der Unterstützung von Virtualisierung in Hardware, die in den neuesten Prozessoren von Intel (VT-Technologie) und AMD (Pacifica-Technologie) steckt, ist auch das Ausführen von unmodifizierten Gastsystemen möglich. Dies soll auch die Performance-Einbußen, die angeblich bei rund 5% liegen, weiter verringern.

Auf 32-Bit-Servern kann Xen 3.0 durch seine PAE-Unterstützung bis zu 64 GB Speicher verwalten. Auf 64-Bit-Servern sind es noch ein paar Bytes mehr. SMP wird unterstützt, wobei dem Gastsystem bis zu 32 Prozessoren vorgegaukelt werden können. Besonders interessant im Zusammenhang mit Hochverfügbarkeit ist die Möglichkeit, virtuelle Maschinen unter Xen praktisch ohne merkliche Unterbrechung auf einen anderen Rechner zu verlagern (Live Relocation).

Xen garantiert den Gastsystemen bestimmte Ressourcen, was umgekehrt bedeutet, dass ähnlich wie bei VMware oder Qemu eine bestimmte Menge von Speicher und Festplattenplatz für jeden Gast reserviert werden muss. Das begrenzt die Zahl der Gastsysteme, sollte für mich aber kein Problem darstellen, da das RAM mit 4 GB von Anfang an auf den Einsatz von Xen ausgelegt war. Zusätzlich kann Xen den Gastsystemen auch Bandbreite bei Ein/Ausgabe (z.B. Festplatte) und Netzwerk garantieren. Von dieser Möglichkeit werde ich voraussichtlich keinen Gebrauch machen.

Da Xen 3.0 mittlerweile in die meisten Distributionen Einzug gehalten hat, dürfte der einfachste Einstieg die Installation der entsprechendenen Distributionspakete darstellen. Wer seinen eigenen Kernel erstellen will, kann das mit Hilfe des Quellcodes tun. Dabei ist zu beachten, dass Xen 3.0.2 eine Kopie der Quellen von Linux 2.6.16 installiert. Xen 3.0.3 verwendet Linux 2.6.16.29 in der gleichen Weise. Ich habe noch keinen Xen-Patch für Linux 2.6.17 oder 2.6.18 gesehen, allerdings bietet Debian einen 2.6.17-Kernel mit Xen an.

Die Installation von Xen erledigt man, zumindest fürs erste Kennenlernen, am besten mit Paketen der Distribution, die man einsetzt. Damit sollten sich der Xen-Kernel und der als Dom0 laufende Linux-Kernel schmerzfrei und schnell installieren lassen. Wie man danach die Gast-Domains einrichtet, ist abhängig von der gewünschten Distribution. Soll das Gastsystem ein Debian-System sein, würde man mit debootstrap ein Basissystem auf die Partition aufbringen, die man per Loopback zunächst auf dem Hostsystem mountet.

Will man Xen aus den Quellen installieren, dann sieht das ungefähr so aus, wobei man die Kernel-Konfiguration auch noch an eigene Vorstellungen anpassen kann:

Auspacken der Xen-Quellen
cd xen-3.0.3_0-src
cd linux-2.6.16.29-xen
Eigene Konfigurationsdatei kopieren oder anlegen
make menuconfig
cd ..
make KERNELS="linux-2.6-xen0 linux-2.6-xenU"
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung