Krankenhäuser setzen ihre zahlreichen Softwareprodukte meistens jeweils auf eigenen Servern ein. Im Lauf der Jahre kommen dadurch viele unterschiedliche Hardwareplattformen, Betriebssystem-Versionen und Datensicherungskonzepte zusammen. Für die Administration ist ein kaum zu bewältigender Aufwand notwendig.

Fatale Vorsorge

Noch gravierender ist die Vorsorge gegen Server-Ausfälle. Um Betriebsstörungen und Datenverluste zu vermeiden, gibt es viele Systeme doppelt, wobei ein Server in Reserve bereitsteht. Dieser wird erst bei Ausfall des Haupt-Servers zugeschaltet; die aktuellen Daten werden dann von einer Sicherungskopie eingelesen werden. Hier wirkt oft der Hersteller des Systems mit, er vollzieht das Backup. Jedoch existiert gerade bei jahrelang bewährten Systemen der Hersteller häufig nicht mehr. Häufig gibt es auch keine Möglichkeit, das Programm auf einer moderneren Hardwareplattform zu installieren.

Vor dieser Situation stand auch das Bezirkskrankenhaus (BKH) Augsburg Anfang 2005. Einige der alternden Server zeigten erste Ausfallerscheinungen; viele Recher waren ohnehin an der Grenze der Leistungsfähigkeit. Zu manchen Programmen gab es inzwischen keine Installationsroutinen mehr, bei anderen verlangten die Hersteller viel Geld für eine Neuinstallation auf modernen Betriebssystemen und neuer Hardware.

Ein radikaler Eingriff

Statt aber die alten Server durch neue zu ersetzen und dabei noch weitere anzuschaffen, entschied sich die Krankenhausleitung, die physikalischen Server gegen virtuelle auszutauschen. Vier leistungsfähige IBM-x366-Server mit jeweils vier Prozes- soren und 16 GB Hauptspeicher wurden mittels Fibre Channel an ein 3 TB großes Storage Attached Network (SAN) angeschlossen. Jeder einzelne Rechner birgt eine variable Anzahl virtueller Maschinen. Beim Ausfall eines Systems können die übrigen Server dessen virtuelle Maschinen übernehmen und weiterbedienen.

Als Virtualisierungsplattform kommt VMware ESX-Server 2.5 zum Einsatz. Durch das Programm "Physical to Virtual" (P2V) von VMware ist es möglich, physikalische Server relativ einfach in virtuelle zu verwandeln. Dadurch kann man defekte oder veraltete Hardware aussortieren, ohne die Software neu installieren zu müssen. Gleichzeitig ergab sich eine höhere Ausfallsicherheit.

Probleme bei OP-Vorbereitung

Hierbei zeigten sich die ersten drei Schwachstellen: Der VM- ware ESX-Server 2.5 unterstützt erstens keine USB-Ports, was bewirkt, dass ein Server, der einen USB-Dongle verwendet, nicht unter ESX laufen kann und weiter als physikalischer Server arbeiten muss. Diese Virtuali- sierungslösung kann zweitens keine Snapshots (Kopien der Systemfestplatten) laufender virtueller Server erzeugen, wie es andere VMware-Produkte können. Nur mit Hilfe der Kommandozeilen-Tools lässt sich ein Snapshot und dadurch eine Datensicherung für die laufende Maschine herstellen. Drittens erfolgt bei einem Rechnerausfall kein automatisches Umschalten aller virtuellen Server auf eine andere Hardware. Hier müssen die Administratoren von Hand eingreifen. Und dies ist schon beim Aufsetzen eines virtuellen Servers zu berücksichtigen.

Neben den IBM-Servern mit ESX wurde auch ein separater Server für "Virtual Center" (VC) von VMware aufgesetzt. Dieses Programm ermöglicht eine einfache und übersichtliche Administration sowohl der physischen ESXServer als auch aller virtuellen Maschinen. Durch VC wird es überhaupt erst möglich, virtuelle Server im laufenden Betrieb von einer Hardware auf eine andere zu übertragen, ohne dass die Benutzer davon etwas mitbekommen. Dadurch konnte das IT-Team des BKH während der Migration neue Server einfach auf die Hardware verteilen und so sie Systemlandschaft gleichmäßig auslasten.

Bei der Migration wurden zuerst einige Test-Server in der virtuellen Umgebung erzeugt sowie Ausfälle verschiedenster Art und Neustarts simuliert. Dann wurde zuerst ein virtueller Server aufgesetzt, der ein unmodifiziertes Windows-2003-Betriebssystem mit allen Funktionen besitzt, die immer wieder benötigt werden. Dazu zählen neben den aktuellen Service-Packs auch die Konfiguration von SNMP und die Installation des Remote-Desktops (RDP) zur Administration des Rechners. Dieses Grundgerüst wurde als Vorlage für alle neuen Server definiert. Durch dieses Template lassen sich neue virtuelle Server innerhalb weniger Minuten erzeugen. Weil im BKH Augsburg und den angeschlossenen anderen Bezirkskrankenhäusern Schwabens hauptsächlich Terminal-Server im Einsatz sind, wurden auch noch Vorlagen für neue solche Rechner erzeugt, auf denen neben dem Office-Paket gleich das Krankenhausinformationssystem mitinstalliert ist.

Erweiterte Erstversorgung

So wurden nacheinander neue Datei-, Druck- und Terminal-Server sowie Domain-Controller aufgesetzt und die Clients auf die Verbindung zu diesen Rechnern umkonfiguriert. Dies war insbesondere bei den Terminal-Servern notwendig, weil die Clients vorher eine Verbindung zu einem NLB-Cluster (Network Load Balancing) aufbauten und nun die einzelnen Berufsgruppen mit individuellen Terminal-Servern ausgestattet wurden. Erst dadurch ist es möglich, den Ärzten andere Programme zur Verfügung zu stellen als beispielsweise den Pflegern oder der Verwaltung.

Die Umstellung der Benutzer auf die neuen Terminal-Server ist noch nicht abgeschlossen. Andere Server, die durch virtuelle Maschinen ersetzt wurden, sind inzwischen ausgeschaltet oder neuen Aufgaben zugeführt worden.

Insbesondere die Migration der File-Server erforderte eine Wochenendaktion, weil zuerst über 100 GB Daten, inklusive aller Benutzerrechte und Freigaben, vom physischen Server über das Netzwerk auf den neuen virtuellen Server zu kopieren waren. Natürlich durften in dieser Zeit keine Anwender mit den Daten arbeiten, weil die Verknüpfungen auf den Desktops auf die Daten auf dem alten File-Server zeigten. Diese mussten anschließend auf den neuen File-Server umgestellt werden. Hier kam das Tool "Scriptlogic" vom gleichnamigen Anbieter zum Einsatz.

Komplikationen

Als Herausforderung entpuppten sich die Server, die nicht neu installiert werden konnten. Vier Gründe waren Auslöser solcher Situationen: Ein Server mit Windows NT enthielt zum Beispiel keine Installationsprogramme für die gesamte Software. In einem anderen Fall waren die geforderten Kosten zu hoch. Auf anderen Systemen waren zu viele Daten gespeichert, oder die Neuinstallation wäre zu aufwändig gewesen.

Hier kam das Programm P2V zum Einsatz. Mit ihm kann man eine Kopie der Festplatten eines Servers anfertigen, diese auf den ESX-Server portieren und dort als zusätzliche virtuelle Platte einem virtuellen Server zuordnen. P2V untersucht anschließend die Festplattenkopie und ersetzt alle Treiber und Registry-Einträge durch VMware-eigene Versionen. Wenn man dann dem virtuellen Server diese Festplattenkopie als Boot-Platte vorgibt und neu startet, hat man eine lauffähige Kopie des ehemaligen Hardware-Servers in der virtuellen Umgebung. Zumindest theoretisch.

Assistenten benötigt

In der Praxis ergeben sich dabei nämlich ein paar Probleme. Die Festplatte ließ sich unter Windows NT nicht erstellen, weil die Kopiersoftware nicht mit der für NT installierten Grafikkarte funktionierte. Und P2V konnte auch die Netzwerkkarte nicht erkennen. Erst das Programm "Ghost" vermochte eine Festplattenkopie zu erzeugen und diese dann im virtuellen Server in eine virtuelle Festplatte umzuwandeln.

In einem anderen Fall war die Festplatte des Servers in einem Software-Raid von Windows gespiegelt. Damit konnte erst eine neuere Version von P2V etwas anfangen und eine Kopie erzeugen. Hier hat sich eine Beraterfirma als hilfreich erwiesen, da die Administratoren des BKH Augsburg zu wenig Erfahrung mit P2V hatten, um anhand dessen teilweise kryptischer Fehlermeldungen zu erahnen, wo das Problem lag.

Inzwischen sind im BKH Augsburg fast alle Server auf virtuelle Server umgestellt. Lediglich jene Rechner, mit denen das nicht geht, weil sie von ESX nicht unterstützte Hardware benötigen, bleiben eigenständig erhalten - zumindest bis zu einer Version von ESX, die USB-Dongles und ISDN-Karten unterstützt.

Kleine Rückschläge

Auf den ESX-Servern laufen derzeit mehr als 40 virtuelle Maschinen, die meisten davon als Terminal-Server. Die Auslastung der damit beschäftigten physischen Systeme geht allmählich an die Grenze, die Performance verschlechtert sich merklich. Hier zeigt sich ein prinzipielles Problem der virtuellen Umgebung: Ein neuer Server ist innerhalb von zehn Minuten installiert und einsatzbereit. Man gerät schnell in Versuchung, für jede neue Aufgabe und für jeden Test kurzerhand einen neuen virtuellen Server einzurichten. Der nächste Schritt der Server-Konsolidierung wird daher darin bestehen, virtuelle Server wieder zusammenzufassen und die Zahl der virtuellen Maschinen zu reduzieren.

Im Server-Raum ist nun wieder viel Platz, überflüssige Racks sind abgebaut, und der Energieverbrauch ist deutlich gesunken. Die unterbrechungsfreie Stromversorgung (USV) war vor der Umstellung so weit über ihrer Leistungsgrenze, dass eine zweite angeschafft werden musste. Jetzt laufen beide USVs mit herabgesetzter Leistung und können sich gegenseitig vor Ausfällen schützen.

Funktionen wieder hergestellt

Die frei gewordenen Rechner konnten veraltete, zu langsame oder defekte Server ersetzen. So ließ sich endlich die gesamte Datensicherung in einen anderen Server-Raum auslagern. Alle Workstations, die einst als Server installiert waren, weil keine neue Hardware zur Verfügung stand, sind inzwischen wieder als Arbeitsplatzsysteme im Einsatz. Server, die in einer virtuellen Umgebung laufen, sind durch VMware jetzt ausfallsicher, ohne dass neue Hardware angeschafft werden musste, und die Daten sind auch bei einem Ausfall sofort wieder verfügbar. Über Snapshots werden nun auch Backups von Servern angelegt, von denen das bisher nicht möglich war. Von Test-Servern lassen sich vor einer Erprobung Sicherungen erzeugen, die nachher wieder eine saubere Installation herstellen.

Zu Kräften gekommen

Die Administration der Server durch Virtual Center ermöglicht es, virtuelle Maschinen von einer Hardware auf eine andere zu verschieben, um die Hardware gleichmäßig auszulasten. Ressourcen wie Hauptspeicher, CPU-Leistung sowie Festplattenplatz sind rein virtuell und können jederzeit den Anforderungen entsprechend reduziert oder aufgestockt werden. So hat das IT-Team anfangs ein paar Server mit zu viel virtuellem Speicher installiert. Dieser ließ sich schrittweise reduzieren und anderen virtuellen Maschinen zur Verfügung stellen.

Die Nachversorgung

Server mit einer hohen CPU-Auslastung können eine zweite CPU zugeschaltet bekommen, Server mit zu wenig Plattenspeicher erhalten einen größeren virtuellen Speicher. Anfangs zu großzügig dimensionierte virtuelle Festplatten lassen sich wieder beschränken. Für Partitionierungsoperationen sind allerdings Zusatz-Tools wie "Parti- tion Magic" nötig. Mit ESX 2.5 ist lediglich die Vergrößerung oder Verkleinerung der Festplatten über Scripts möglich. Hier ist die IT-Mannschaft auf die Version 3 des ESX-Servers gespannt, die es demnächst einführen will.

Das IT-Team erhofft sich von ESX 3 insbesondere:

• Verbesserung der Performance der Windows-Terminal-Server durch Unterstützung von mehr als zwei CPUs pro Server,

• Unterstützung von USB-Hardware in den Gast-Betriebssystemen,

• ein Dateisystem auf dem SAN, das Verzeichnisse unterstützt, um die Übersichtlichkeit zu verbessern,

• eine automatische Migration der Betriebssysteme durch VMotion im Falle eines Hardwareausfalls,

• einfache Erstellung von Snapshots zur einfachen Datensicherung der laufenden Server und

• eine einfachere Lastverteilung der virtuellen Server auf den ESX-Servern.

Etwas Sorgen bereitet allerdings die Migration der ESX-Server 2.5 auf die Version 3. Hier kursieren viele Gerüchte, die den Schluss nahe legen, dass es am besten wäre, die Server komplett neu zu installieren. Außerdem muss für das neue Dateisystem wohl das SAN neu installiert werden. Das bedeutet, dass sämtliche Server des BKH Augsburg abgestellt werden müssen und erst wieder zur Verfügung stehen, wenn alle ESX-Server neu installiert sind. Das würde einen Ausfall von mehreren Tagen bedeuten. Und das ist schlichtweg nicht möglich. (ls)