Bessere Ressourcenauslastung, zentrale Administration, Konsolidierung – auf dem Papier ist Virtualisierung eine Zaubertechnik. Doch was davon schlägt sich tatsächlich in messbarem Praxisnutzen nieder? Zwei Admins des Kommunalen Rechenzentrums Niederrhein berichten über ihre Erfahrungen.

Wir nennen sie gerne Elektroheizungen: Server, die in ihrer Funktion zwar unabdingbar sind, jedoch eine mittlere Systemlast von zehn Prozent nie überschreiten. Es sind DHCP-, DNS-, Print-, File- und Fax-Server und der eine oder andere in die Jahre gekommene Applikationsserver, den nur noch drei Personen brauchen. Aber wehe, man schaltet ihn ab! Hinzu kommen die unvermeidlichen Testsysteme, die niemand anzufassen wagt. Ihre Hardware ist oft veraltet, aber warum sollte man etwas Neues anschaffen, wenn das alte Blech nicht einmal annähernd ausgelastet ist?

Was bleibt, ist ein flaues Gefühl in der Magengegend, denn klar ist auch: Alte Hardware fällt irgendwann aus und ein abgestürzter DHCP-Server am Montagmorgen ist ein Garant für stundenlanges Chaos, egal ob er ansonsten nur zu wenigen Prozent ausgelastet gewesen wäre.

Auswahlkriterien

Solche Überlegungen waren für die Autoren vor geraumer Zeit Anlass, über Virtualisierung nachzudenken. Wir arbeiten als Administratoren im Kommunalen Rechenzentrum Niederrhein, das als Dienstleiser für Kreise, Städte und Gemeinden sowie öffentliche Institutionen tätig ist und damit zurzeit insgessamt mehr als 11000 Arbeitsplätze bedient.

Zum Zeitpunkt unserer Entscheidung gegen herumstehende Rechner und für eine Virtualisierungslösung waren noch nicht so viele konkurrierende Techniken verfügbar wie heute. Manche boten auch nicht die geforderte Flexibilität, waren also beispielsweise nicht mit dem Betriebssystem-Mix kompatibel, den wir unterstützen müssen.

Wir hatten andererseits aber bereits gute Erfahrungen mit der Workstation von VMware gesammelt, weshalb deren Schwesterprodukte schnell in unser Blickfeld gerieten. Dass der GSX-Server unseren Ansprüchen nicht genügen würde, war schnell klar, und so fiel die Entscheidung schließlich zugunsten des VMware-ESX-Servers aus.

Das Funktionsprinzip des ESX-Servers entspricht prinzipiell dem der Workstation aus dem gleichen Hause – allerdings übernimmt der Server hier zugleich den Part des Betriebssystems. Hier wie dort trennt aber eine Virtualisierungsschicht das Host- von den Gastsystemen. Den Gästen wird jeweils eine isolierte und idealisierte Hardware vorgespielt. So glaubt beispielsweise jedes Gastsystem, seine eigene CPU zu besitzen, oder gar deren zwei, wenn das Hostsystem mit der aufpreispflichtigen Virtual-SMP-Erweiterung ausgestattet ist.

Schichtenaufbau

Faktisch bildet natürlich die Virtualisierungsschicht alle logischen CPUs auf die physisch vorhandenen Prozessoren ab. Auch der Hauptspeicher wird je nach Art und Anforderungen von VMware neu zuordnet, gemeinsam von mehreren Gastsystemen genutzt oder sogar ausgelagert. Das geschieht ohne das Wissen oder Zutun der Gastsysteme und ist für sie vollkommen transparent.

Festplatten und Netzwerk-Adapter erscheinen dem Gastsystem ebenfalls wie eigene physische Ressourcen, wobei jede virtuelle Netzwerkkarte sogar über eine eigene MAC-Adresse verfügt. Die Treiber für Grafik, NIC und so weiter stellt VMware mit den bereits von der Workstation bekannten VMware-Tools bereit.

Bald Nachschub nötig

Für den Betrieb eines ESX-Servers ist ein System mit mindestens zwei CPUs – alternativ eine CPU mit zwei Cores – erforderlich. Hauptspeicher kann nie genug vorhanden sein, ebenso Festplattenplatz. Zwei Netzwerkkarten sind ebenfalls Pflicht, denn eine ist für die Verwaltung des ESX-Servers reserviert, die andere(n) teilen sich die Gastsysteme. In älteren Dokumentationen oder Foren findet sich bisweilen der Hinweis, dass als primäre Netzwerkkarte ein altes 10-MBit-Modell ausreichen würde, weil es nur für die Serververwaltung nötig sei. Das ist eine Ente, denn wer ein Image eines Gastsystems sichern möchte, benutzt genau dieses Interface. Also gilt auch an dieser Stelle: Nicht am falschen Ende sparen.

Unsere ersten Gehversuche mit dem ESX-Server machten wir auf zwei IBM X-Series (x445) mit jeweils acht 2,8-GHz-Xeon-Prozessoren, 24 GByte RAM und redundantem SAN-Anschluss über zwei Fibre-Channel-Karten. Diese beiden Karten erkannte der ESX-Server übrigens gleich direkt bei der Installation als Team und konfigurierte sie automatisch für den Fail-Over

Ausbau mit Bedacht

Nachdem dieses System lief, kamen Kollegen, Chefs und Kunden schnell auf den Geschmack, sodass die Hardware bald zu klein wurde. Die Aufrüstung bestand aus drei HP Proliant DL580 G2 mit je vier 2,0-GHz-Xeons und je 16 GByte RAM. Auch diese Systeme sind selbstverständlich mit zwei Qlogic-SAN-Adaptern ausgestattet.

In der nächsten Wachstumsstufe kamen drei HP Proliant DL 740 G1, mit je acht 2,70-GHz-CPUs, 32 GByte RAM und zwei SAN-Adaptern hinzu. Der letzte Neuzugang war schließlich ein HP Proliant DL 585 G1 mit vier 2,2-GHz-Opteron-Dual-Core-Prozessoren.

Das war leider im Nachhinein nicht die beste Idee, da sich selbst unter Ausnutzung aller Tricks und Zusatzprodukte die Gastsysteme nur umständlich zwischen den verschiedenen Prozessor-Architekturen verschieben lassen. Positiv waren wir aber von der Performance der Opterons überrascht.

Alle Systeme haben neben dem SAN für die virtuellen Systeme auch zwei gespiegelte lokale Platten für das Betriebssystem selbst sowie für ISO-Images und sonstige Installationsablagen. Grund dafür waren aber nicht nur die Kosten (Platz im SAN ist teuer), sondern auch der Umstand, dass die damalige Version 1.5 das Booten vom SAN noch nicht unterstützte. Mit der aktuellen ESX-Version wäre das aber kein Problem mehr.

Mittlerweile betreiben wir eine Serverfarm mit insgesamt neun produktiven Servern (zusammen 60 CPUs), auf der wir mehr als 200 Gastysteme virtualisiert haben. Gastbetriebssysteme sind Windows XP, Windows 2000 Server, Windows 2003 Server, Suse Linux 9.x, SLES 8, SLES 9, Fedora Core 2 und Debian. Die beiden letztgenannten Systeme unterstützt VMware zwar nicht offiziell, es funktioniert aber trotzdem sehr gut.

Einsparung überall

Die Einsparungen durch den Einsatz von Virtualisierungslösungen liegen neben der oft erwähnten besseren Ausnutzung der Hardware (besonders CPU und RAM) auch in der häufig übersehenen Senkung der Portkosten (LAN-, SAN- Anschluss). Darüber hinaus bietet die Virtualisierung die Möglichkeit – entsprechend dimensionierte Hardware vorausgesetzt -, schnell Anforderungen nach neuen Systemen zu bedienen.

Es macht in der Praxis einen enormen Unterschied, ob wir ein dringend benötigtes System erst beim Großhändler bestellen müssen oder per Virtualisierung in wenigen Stunden zur Verfügung haben. Zu diesem Zweck kann man entweder Systeme klonen, was sich gerade bei Linux-Gastsystemen anbietet, oder ein Windows-System per Unattended-Installation mit wenigen Tastendrücken aufsetzen. Das spart in allen Abteilungen viel Zeit und damit letzten Endes auch nicht wenig Geld.

Abbildung 1: Der Ressourcenverbrauch mehrerer parallel laufender virtueller Rechner lässt sich auf dem ESX-Host zentral und mit grafischer Unterstützung überwachen.

Optionales Backup

Ebenfalls nicht zu verachten ist die Möglichkeit, über VMware automatisiert offline und online Image-Sicherungen der Gastsysteme anzufertigen, ohne zusätzliche teure Backup-Lösungen kaufen zu müssen. Wenn wir einmal einen Server virtualisiert haben, sind wir gleichzeitig für alle Zeiten von der Verlegenheit befreit, ihn jemals umständlich auf neue Hardware migrieren zu müssen. Denn selbst wenn die Hardware ausgetauscht wird, müssen wir dank der Virtualisierungsschicht die Gastsysteme überhaupt nicht verändern, sondern wir transferieren sie lediglich auf das neue System. Wenn dann auch noch das Virtual Center und VMotion zum Einsatz kommen, gelingt der Transfer der virtuellen Hosts sogar online!

Abbildung 2: Alle virtuellen Pizza-Boxen dieses Hosts in der Übersicht. Ausfälle oder Amokläufer würde man damit auf den ersten Blick erkennen.

Virtuelles Zentrum

Das Virtual Center ist eine Administrationsoberfläche für VMware GSX und ESX. Sie zeigt alle Server und Gastsysteme in einer Baumstruktur mit Status- und Verbrauchsdaten an. Zur Automatisierung verschiedenster Aufgaben – sie reichen vom Herunterfahren bis zum Klonen der Gastsysteme – gibt es einen recht einfachen Scheduler.

Insgesamt bietet das Virtual Center somit rudimentäre Systemmanagement-Funktionalitäten. In größeren Installationen wird das Virtual Center aber spätestens dann unverzichtbar, wenn man mit dem Zusatz VMotion Gastsysteme online auf eine andere Hardware verschieben möchte. Hierfür ist nämlich das Virtual Center Voraussetzung.

Beim ESX-Server ist die Palette der unterstützten Betriebssysteme, die sich virtualisieren lassen, deutlich geringer als beim GSX-Server und vor allem bei der Workstation. Wer nur Windows-Server virtualisieren will, bekommt diesen Nachteil nicht zu spüren.

Aber gerade bei den Linux-Derivaten ist die Auswahl auf die kommerziellen Distributionen von Red Hat und Suse beschränkt. Open Suse oder Fedora supported der ESX-Server zur Zeit ebenso wenig wie etwa Solaris oder Ubuntu. Außerdem hängt der ESX- dem GSX-Server versionsmäßig immer etwas nach. Eine Übersicht der unterstützen Betriebssysteme findet sich unter [1]. (jcb)