Virtualisierung an der ETHZ

Die zentralen Informatikdienste versorgen sämtliche Anwender an der ETH Zürich mit IT-Services von E-Mail über Netzwerk-Backup bis zum Server-
betrieb. Jürgen Winkelmann leitet die Abteilung Systemdienste, die innerhalb der Informatikdienste für die Betreuung der Server und der High-Performance-Computer sowie für das Speichernetzwerk zuständig ist: Die ETH-internen Kunden können nach der Implementation einer zentralen Speicherplattform seit über anderthalb Jahren Speicherplatz mit NAS- oder SAN-Zugriff im Abonnement beziehen.

Nach der Storage- die Servervirtualisierung

«Wir hatten schon vor vier Jahren den Eindruck, dass uns künftig auch die Servervirtualisierung von Nutzen sein kann», meint Winkelmann. «Wir haben aber nicht etwa von Anfang an geplant, welche bestehenden Server zu welchem Zeitpunkt virtualisiert werden sollten. Statt dessen haben wir ein abteilungsinternes Pilotprojekt in Angriff genommen: Die rund 200 Mitarbeiter der Informatikdienste sollten mit einem Citrix-Service für den Zugriff auf die Windows-basierte Messaging-Infrastruktur versorgt werden. Viele Mitarbeiter hatten nämlich nur zu diesem Zweck neben ihrer Unix-Workstation noch einen Windows-PC auf dem Schreibtisch stehen.»


Den Citrix-Dienst hätte man auch auf einem physischen Server installieren können. Aus Flexibilitätsgründen hat sich Winkelmanns Team aber für ein virtualisiertes System entschieden – und dies hat sich bis heute bewährt: «Alles, was wir uns damals im Hinblick auf Skalierbarkeit und Zuverlässigkeit überlegt hatten, hat sich bewahrheitet. Der Citrix-Dienst ist heute noch in Betrieb und läuft auf mehreren virtuellen Maschinen unter Vmware ESX Server.»

Im Vergleich zu anderen grösseren Virtualisierungsprojekten bezeichnet Winkelmann die Vorgehensweise an der ETHZ als etwas untypisch: «Wir haben im Pilotprojekt gleich einen produktiven Service virtualisiert. Weitere Server sind zudem nicht nach einem fixen Fahrplan hinzugekommen. Die VMware-Umgebung ist gewissermassen mit dem Citrix-Service als Kristallisationspunkt organisch gewachsen: Als wir genügend Erfahrung für einen zuverlässigen Betrieb hatten, boten wir virtualisierte Server als Option an – zunächst intern für Anwender bei den Informatikdiensten.» Als erstes wurden Testinstallationen mit virtualisierten statt mit physischen Servern implementiert, die jedoch oft so gut liefen, dass sie später direkt in den produktiven Betrieb übernommen wurden.

250 virtuelle Maschinen

Nach den guten Erfahrungen bei den Informatikdiensten offerierten die Systemdienste auch den übrigen ETH-internen Kunden virtuelle Server zur Wahl. So entstand eine recht grosse Nachfrage. Eine virtuelle Maschine (VM) kann laut Winkelmann ziemlich formlos bestellt werden und wird zu wesentlich geringeren Kosten verrechnet als die Installation eines physischen Servers.


Heute laufen an der ETHZ rund 250 VMs auf 24 Hosts. Die meisten Hostsysteme sind in Form von zwei Blade-Chassis von Dell mit je 10 Blades realisiert, dazu kommen einige Standalone-Geräte aus früheren Zeiten.

Die virtuelle Infrastruktur hat einen klaren Einfluss auf die Hardwarebeschaffung: «Einige VMs wurden wohl nur deshalb eingerichtet, weil sich damit so leicht eine Testumgebung aufsetzen lässt, und wären in physischer Form gar nie realisiert worden», meint Winkelmann, «aber insgesamt konnten wir mit der Virtualisierung bisher sicher die Anschaffung von 150 physischen Servern vermeiden.» Bestehende Server wurden dabei erst am Ende ihrer Lebensdauer virtualisiert und nicht vorzeitig ersetzt. «Bei uns läuft ein Server während drei bis fünf Jahren, das ist ein überschaubarer Zyklus. Wir lassen die Systeme einfach auslaufen – wenn es ohnehin um eine Ablösung geht, ist dies auch psychologisch der richtige Zeitpunkt zum Umstieg auf eine virtuelle Maschine. Die Anwender haben dann nicht das Gefühl, dass man ihnen die Hardware mutwillig entreisst.»

Gegenargumente entkräftet

Am Anfang stiess die Virtualisierung ganzer Serversysteme bei den Anwendern auf Skepsis. Jürgen Winkelmann traf wiederholt auf zwei Gegenargumente: Performance-Verlust und mangelnde Zertifizierung für bestimmte Systeme und Anwendungen.


Für den Leiter der Systemdienste sind diese Zweifel in erster Linie eine psychologische und weniger eine technische Frage. Leistungseinbussen wurden besonders von Anwendern, die auf schnellen Datenbankzugriff angewiesen sind, schon bei der Einführung des SAN befürchtet – und schon damals hatten sich die Befürchtungen nicht bewahrheitet. Im Gegenteil: Die zentrale Storage-Plattform bietet meist besseren Durchsatz als die früher üblichen kleinen lokalen Disk-Arrays. Auch wenn zusätzlich noch der Server virtualisiert wird, ändert sich wenig: Eine VM bringt grundsätzlich nicht weniger Leistung als ein physischer Server.

Ein allfälliger Flaschenhals bleibt der Speicherzugriff. «Für Hardcore-Anwendungen können wir aber auch einem virtuellen Server Raw-Access aufs SAN ermöglichen. Damit verliert man zwar etwas an Flexibilität, aber jeder sonst allenfalls vorhandene Unterschied beim Zugriff zwischen einem physischen und einem virtuellen Server verschwindet.»
Auch das zweite Argument lässt Winkelmann nicht gelten: «Manche Systeme und Anwendungen werden offiziell nicht unterstützt, wenn sie in einer virtualisierten Umgebung laufen. Wenn es drauf ankommt, verweigern die Hersteller den Support dann aber doch nicht.» Dennoch laufen an der ETHZ noch nicht alle Applikationen virtualisiert: «Unser produktives SAP-System läuft nach wie vor auf physischen Servern, es ist aber auch in der Pipeline für die Virtualisierung.»

Fast alles wird virtualisiert

Für neu einzurichtende Server haben die ETHZ-Informatikdienste heute eine klare Regelung: Bei jedem Antrag wird geprüft, ob der Server virtualisierbar ist. Im Zweifelsfall wird der Dienst zunächst auf einem virtuellen Server implementiert. Nur wenn der Anwender beweisen kann, dass es so wirklich nicht funktioniert, erhält er statt dessen einen physischen Server.

«Unser Ziel ist klar: Praktisch alles, was wir für die zentralen Informatikdienste benötigen, soll virtualisiert werden. Dazu gehören Fileserver, Webserver, Datenbankserver, überhaupt alle LAMP- oder Windows-basierten Server für den allgemeinen Einsatz. Die Institute dagegen entscheiden frei. Die einen sind aktiv interessiert und bestellen virtuelle Server, andere haben oft spezielle Forschungs­geräte, die über spezielle Karten direkt an einen Server angeschlossen werden müssen – so etwas eignet sich natürlich nicht für die Virtualisierung.»

VMware von Anfang an klar

Beim ersten Virtualisierungsprojekt fiel die Wahl der Lösung leicht: Erstens hatte man bei den Systemdiensten Erfahrung mit den Workstation-Virtualisierungsprodukten von Vmware, zweitens gab es laut Winkelmann damals eigentlich keine Alternative zum ESX Server. «Die anderen Hersteller waren schlicht noch nicht soweit. Die Lösungen von Xensource und Microsoft erfüllten unsere Bedürfnisse bei weitem nicht.»

Auch wenn Winkelmann heute neu entscheiden müsste, fiele die Wahl wieder auf VMware: «Wenn die virtuelle Infrastruktur wächst, steht und fällt die Verwaltbarkeit mit den zur Verfügung stehenden Tools. Migrationen zwischen Hosts, Backups und andere regelmässige Aufgaben sind bei 250 VMs ohne ausgeklügelte Hilfsmittel extrem schwierig. In diesem Bereich bietet VMware mit der Infrastructure Suite halt immer noch am meisten, auch wenn die Mitbewerber aufgeholt haben.»


Auch aus diesem Grund kommen an der ETHZ zumindest bei den Systemdiensten keine anderen Virtualisierungstechniken zum Einsatz: «Systeme mit firmwarebasierter Virtualisierung lassen sich nicht nahtlos integrieren – man braucht ein zweites Toolset, anderes Know-how und so weiter. Mit böser Zunge könnte man sogar sagen, firmwarebasierte Virtualisierung sei ein Relikt aus der Zeit, als rein per Software realisierte Virtualisierung noch nicht mit genügender Effizienz möglich war.»



Die VMware-Suite dagegen wird an der ETH in allen Teilen genutzt. Neben dem ESX Server kommen sämtliche administrativen Möglichkeiten zum Einsatz, darunter die automatisierte Migration, bei der die Komponente DRS aufgrund der Auslastung selbst entscheidet, wann welche VM mit Hilfe von VMotion auf welchen Host migriert werden soll, und die High-Availability-Option zur automatischen Migration der betroffenen VMs bei einem Host-Ausfall.

Backup und Storage

Grosse Bedeutung misst Winkelmann auch der relativ neuen Funktion «Consolidated Backup» zu: Damit lässt sich ohne Umweg übers LAN ein strukturiertes Backup der virtualisierten Systeme erstellen. «Wenn man konventionell vorgeht, auf dem virtuellen Server den Netbackup-Client installiert und über das ohnehin stark belastete LAN sichert, wird dies rasch zum Performance-Killer. Das ist bei VMs nicht anders als bei physischen Servern. Sichert man andererseits einfach die Filesystem-Ebene, auf der die virtuellen Disks liegen, verliert man aus Sicht der VMs die Struktur – das Backup lässt sich für die Disaster Recovery des gesamten Host, nicht aber für die gezielte Wiederherstellung einzelner Dateien aus den VMs nutzen.»


Ein vollständiges Backup ist laut Winkelmann in einer virtualisierten Umgebung aber ohnehin nicht unbedingt nötig: «Das einzig Individuelle an einer virtuellen Maschine sind neben einigen Konfigurationsinformationen ja die Daten, und diese sind via NAS auf der zentralen Speicherplattform abgelegt, die sowieso regelmässig gesichert wird. Der Rest ist Standard und lässt sich unkompliziert und rasch aus einem Template wiederherstellen.»



Generell wird die Anbindung der Server an die Storage-Plattform durch die Virtualisierung klar erleichtert, stellt Winkelmann abschliessend fest: «Eine virtuelle Maschine ist in dieser Hinsicht nichts anderes als ein verallgemeinertes Front-end zum Speicher. Der physische Zugang zum SAN erfolgt ja nicht auf der Ebene der einzelnen VM, sondern durch den Host.» Während bei jedem physischen Server peinlich darauf zu achten ist, ob die Konfiguration des Betriebssystems im Detail stimmt und der Host-Bus-Adapter exakt die geforderte Firmware-Version aufweist, muss in einer virtualisierten Umgebung nur das Host-System aufs SAN abgestimmt werden.

(ubi)