EOL Windows Server 2003: Virtualisierung und Konsolidierung reduzieren die Komplexität

Ob die Zielumgebung nach einer Migration von Windows Server 2003 virtualisiert sein soll, ob man besser physische Systeme einsetzt, oder ob die virtuellen Maschinen in der Cloud oder doch im eigenen Rechenzentrum betrieben werden soll – all das gilt es im Vorfeld einer Migration zu bestimmen. Um den Einsatz neuer Hardware kommt man in den meisten Fällen nicht herum – doch mit den passenden Konsolidierungs-Strategien kann die Komplexität verringert werden. Und mit den neuen Betriebssystemplattformen stehen dann Funktionalitäten wie etwa SMB 3.0 zur Verfügung.

Eine wichtige Frage bei der Migration von Windows Server 2003 auf eine aktuellere Plattform lautet: Soll man seine Anwendungen und das „neue“ Betriebssystem direkt auf der Hardware zum Einsatz bringen, oder soll man eine virtualisierte Umgebung mit einem Hypervisor verwenden. Wer diese Entscheidung fällen muss, der sollte wissen, dass Microsoft erstmals beim Windows Server 2012 ein Konzept verfolgt hat, das als „virtual first“ bezeichnet wird. Sprich Microsoft ging beim Entwurf dieses Server-Betriebssystems davon aus, dass der Windows Server 2012 – und das gilt dann natürlich auch für den Windows Server 2012 Release 2 –  in den überwiegenden Fällen in einer virtuellen Maschine zum Einsatz gebracht wird und nicht mehr in erster Linie auf einer physischen Server-Hardware. Bei Windows Server 2003 war das noch ganz anders: Dabei wurde noch nicht daran gedacht, dass dieses Betriebssystem als Gastbetriebssystem auf einem Hypervisor aktiv ist.

Doch viele Unternehmen lassen „ihre“ Systeme mit Windows Server 2003 mittlerweile schon in virtuellen Maschinen laufen, doch es betreiben immer noch sehr viele Unternehmen ihre Windows Server 2003 auf physischer Server-Hardware. Somit wird die Frage nach dem Ziel einer Migration in vielen Fällen verkompliziert: Es steht im Raum, ob eine Organisation mit der Migration zugleich auch den Umzug in die Servervirtualisierung vollziehen soll.

In den meisten Fällen lässt sich diese Entscheidung allerdings recht einfach treffen: Wo immer es möglich erscheint, Anwendungen zu virtualisieren, sollte man die Vorteile der virtualisierten Umgebungen nutzen. Zu diesen Vorteilen zählen Features wie

• Portabilität,
• Backup/Recovery und
• die schnelle Bereitstellung.

Das lässt sich mit physischen Umgebungen bei weitem nicht so elegant und effizient realisieren.

Doch es gibt immer noch Bereiche, in denen nicht unbedingt der Einsatz der Virtualisierungstechnologie angeraten erscheint. So haben immer noch Anwendungen hohe Anforderungen, die in einer virtualisierten Umgebung nicht erfüllt werden können. ES geht meist darum, dass spezielle Hardware unterstützt werden muss oder dass eine gewisse Leistungsfähigkeit der Plattform nötig ist (wie bei In-Memory-Datenbanken). Zudem kann es Empfehlungen von Herstellern der Applikationen geben, die abraten, diese Anwendung in einer virtualisierten Umgebung zu betreiben.

Generell sollte man vor der Entscheidung immer so viel wie möglich herausfinden, um sicherzugehen, dass der Umstieg auf eine virtualisierte Umgebung auch wie gewünscht funktioniert.

Ist dann aber die Entscheidung für eine virtualisierte Umgebung gefallen, steht die Frage im Raum, ob man seine Arbeitslasten auf einem Virtualisierungs-Host, der im eigenen Rechenzentrum betrieben wird, oder ob man sie in der Public Cloud betreiben soll. Eine allgemeingültige Antwort ist da schlecht möglich – wie so oft muss man zugeben: Es kommt darauf an…

Viele Unternehmen setzen bereits Server ein, die in einem Rack in einem Rechenzentrum eines Providers betrieben werden. Sind die vorliegenden Server mit Windows Server 2003 bereits so untergebracht, dann ist das Umziehen der Arbeitslast in eine Public Cloud und der Betrieb in Form von virtuellen Maschinen (VMs) auf IaaS (Infrastructure as a Service) kein allzu großer Sprung mehr. Es geht lediglich um den Schritt von einem physischen Hosting in fremden Räumlichkeiten zu einem „virtuellen Hosting“ in fremden Räumlichkeiten.

Einsatz der Cloud als Option

Zudem sollte man sich auch noch klar werden, dass der Einsatz einer Cloud keinen „alles oder nichts“-Charakter aufweist. Man kann nur einige Arbeitslasten in die Cloud verschieben, die dann virtuell als VMs auf einer IaaS betrieben werden. Und andere Anwendungen kann man nach wie vor im eigenen Rechenzentrum oder Serverraum laufen lassen. Doch bei zwei Typen von Arbeitslasten sollte man von einer Migration in die Cloud absehen:

• Anwendungen, die man aus existenziellen Gründen nicht nach außen geben soll – etwa weil gesetzliche Vorgaben, Compliance-Regelungen oder interne Richtlinien das verbieten.
• Anwendungen, die nicht offiziell in der Cloud unterstützt werden. Denn es gibt einige Arbeitslasten, die keine offizielle Zertifizierung für einen Cloud-Betrieb haben – meist aufgrund von technischen Vorgaben. Und viele Unternehmen verwenden nur Anwendungen, die vom Hersteller in einer offiziell unterstützten Umgebung betrieben werden.

Generell weist die Cloud viele Vorteile auf, doch die müssen nicht für jeden Anwendungsfall und für jedes Unternehmen passen. Ist sich ein Unternehmen unsicher, ob eine Arbeitslast in die Cloud geschoben werden soll, kann man meist eine Versuchs- oder Testinstallation ausprobieren. Daran lassen sich eventuelle Fallstricke aufdecken. Notfalls muss man sich dann eben für eine (oder mehrere) Alternative(n) zum Betrieb in der Cloud entscheiden.

Im Zuge einer Migration auf eine neuere Plattform und einer Konsolidierung der Server-Hardware kommt es üblicherweise dazu, dass eine Entscheidung zu fällen ist, wie – und ob – die alten Server-Systeme weiterverwendet werden. Mit einem Umstieg auf neuere Server-Konzepte, wie etwa der Blade-basierte VRTX-Ansatz von Dell lassen sich Einsparungen an den Betriebskosten erzielen. Zudem stehen damit eine ausfallsichere und hoch skalierbare 64-Bit-Serverarchitektur zur Verfügung.

Wer die alte Hardware außer Betrieb nimmt, sollte die im Unternehmen dafür zuständigen Abläufe einhalten. Dazu gehört das Löschen vertraulicher Daten auf den Systemen – vor allem die Festplatten müssen mit geeigneten Tools überschrieben werden.
Doch in vielen Fällen – vor allem, wenn die Server-Hardware nicht auf einer veralteten 32-Bit-Architektur basiert, – wird die Frage aufkommen, inwieweit sich diese Rechner noch sinnvoll nutzen lassen. Die Antwort darauf sollte man nicht auf die leichte Schulter nehmen, denn oftmals kommen bei Konsolidierungsprojekten Verzögerungen ins Spiel, weil niemand einen sinnvollen Vorschlag unterbreitet, was mit den vor z.B. zwei Jahren gekauften Servern geschehen soll. Vor allem in Unternehmen, die keinen allzu großen Fokus auf ihre IT-Umgebung haben, herrscht die Einstellung vor, dass Server und Storage solange genutzt werden müssen, bis die Hardware „auseinanderfällt“.

So erscheint der Einsatz von nicht mehr im Produktivbetrieb benötigten, aber doch noch einigermaßen aktuellen Servern in einer Testumgebung als eine gute Idee. Es gibt auch andere Optionen: In den neueren Server-Betriebssystemversionen von Microsoft (sprich ab Windows Server 2012) haben Verbesserungen wie das Protokoll SMB 3.0 Einzug gehalten. Es gibt zwar keinen direkten Upgrade-Pfad von Windows Server 2003 auf Windows Server 2012 oder Windows Server 2012 R2, doch wenn die Server-Hardware passt (Stichwort 64 Bit Architektur), kann man auf einem der nicht mehr benötigten Server zum Beispiel eine neue Kopie von Windows Server 2012 R2 installieren. Dieses System wäre dann in der Lage, zusätzliche Aufgaben – wie etwa die eine Dateiservers – in der IT-Umgebung zu übernehmen. Vor allem Unternehmen mit Zweigstellen können dazu die Funktionalität des Branchcache ausnutzen. Das wird die Anwender in der Zweigstelle mit einer besseren Performance und einer höheren Ausfallsicherheit versorgen.

Rainer Huttenloher