EOL von Windows Server 2003: Testumgebung für die Migration reduziert Umstiegsprobleme

Wer die Migration gut plant und dann nach einer entsprechenden Umstellungsaktion die Produktivumgebung auf der neuen Plattform „live“ schaltet, der geht immer ein Risiko ein. Daher raten umsichtige Projektmanager dazu, zuerst die Migration in einer Testumgebung auszuführen. Denn damit – so ihre Argumentation – wird nicht nur die Validität des Migrationsplans (nach dem Motto: Wie passen die Applikationen zum neuen Betriebssystem) geprüft, sondern auch eine Aussage getroffen, inwieweit die Hardware-Ressourcen zum neuen Konzept passen.

Mitte Juli diesen Jahres, genau am 14. Juli 2015, ist es soweit: Windows Server 2003 bekommt das Attribut „End of Life“ (EOL) verpasst – sprich es gibt von Microsoft keinen offiziellen Support mehr für dieses Serverbetriebssystem. Das bedeutet zwar nicht, dass ab diesem Zeitpunkt die Systeme auf dieser OS-Basis nicht mehr laufen – es wird lediglich keine Updates mehr geben. Treten dann noch Probleme etwa im Bereich der Sicherheit aus, wie es beispielsweise bei der SSL 3.0-Schwachstelle der Fall war, dann sind von Microsoft keine Patches mehr zu erwarten. Damit werden einige Unternehmen gezwungen sein, eine Migration auf eine aktuellere Plattform anzugehen.

Ein weiterer Grund für die Migration auf eine aktuellere Betriebssystembasis sind die Applikationen. Programme von Drittherstellern für Windows Server 2003 werden nach dem EOL der Betriebssystem-Plattform sicher auch nicht mehr viel länger unterstützt werden. Denn alle Neuerungen oder Verbesserungen in der Applikation, die derzeit noch mit Windows Server 2003 funktioniert, werden womöglich nicht mehr auf Windows Server 2003 geprüft – denn ein Testen auf einer nicht mehr unterstützten Plattform macht wenig Sinn. Damit kann das Aufspielen eines Updates der Anwendung mehr Probleme bereiten, als es einem lieb ist.

Wer von einer Plattform mit Windows Server 2003 auf eine aktuellere Infrastruktur migriert, der sollte sich mit dem Thema „Konsolidierung“ befassen. Auf der Ausgangsplattform lautet die Devise noch, dass für jede Applikation – wie etwa Exchange oder den SQL Server – ein eigener physischer Server zu betreiben ist. Sprich im Produktivbetrieb würde nur entweder Exchange oder der SQL Server auf der Hardware und dem Betriebssystem laufen – beide Applikationen dagegen nicht auf einem gemeinsamen System.

Das sieht nun bei Windows Server 2012 oder dem zugehörigen Release 2 (R2) anders aus: Die meisten Einsatzfelder werden in Form von Virtuellen Maschinen (VMs) abgedeckt – auf einer entsprechend mächtigen Hardware wird eine Virtualisierungsplattform – wie Hyper-V oder vSphere – eingesetzt und darauf arbeitet die Applikationen in VMs mit dem Gastbetriebssystem – etwa Windows Server 2012 R2. Der Betrieb von Exchange und einem SQL Server in einer einzigen VM ist in diesem Szenario ebensowenig ratsam.

Wenn ein Unternehmen eine derartige Konsolidierung der Arbeitslast eingeht, gilt es im Vorfeld, die Ressourcen-Ausnutzung der einzelnen Anwendungen genau zu kennen. Insgesamt muss die Virtualisierungsplattform ausbalanciert sein – sprich die verschiedenen Anwendungen dürfen nicht zu einer „Überbeanspruchung“ einer Hardware-Ressource – wie CPU, RAM, Storage oder Netzwerk – des Systems führen. Angenommen es werden mehrere CPU-intensive Arbeitslasten auf demselben Virtualisierungs-Host zum Einsatz gebracht, dann kann es bei den CPUs einen Flaschenhals geben. Besser ist der Ansatz. Nur wenige CPU-intensive Lasten auf einem Host konzentrieren dafür aber andersgeartete Bedürfnisse (wie Storage oder Netzwerk) mit einer CPU-intensiven Last kombinieren.

Dazu muss der Systembetreuer allerdings genau wissen, welche Anwendungen welche Belastungen nach sich ziehen. Hier helfen Tools wie Microsofts Systemcenter-Familie – etwa der Operations Manager und der Virtual Machine Manager. Damit kann der Administrator dann auch ein Verschieben der Lasten über verschiedene Knoten eines Virtualisierungs-Clusters anstoßen, so dass die Hardware optimal ausgenutzt wird. Idealerweise ist sogar ein automatisches Verschieben der VMs mit den Anwendungen gegeben. Damit wird in der Regel ausgeschlossen, dass ungewöhnliche Belastungsspitzen die anderen Anwendungen auf dem Virtualisierungs-Host negativ beeinflussen.

Testumgebung für die Migration

Wer die Migration gut plant und dann nach einer entsprechenden Umstellungsaktion die Produktivumgebung auf der neuen Plattform „live“ schaltet, der geht immer ein Risiko ein. Daher raten umsichtige Projektmanager dazu, zuerst die Migration in einer Testumgebung auszuführen. Denn damit – so ihre Argumentation – wird nicht nur die Validität des Migrationsplans (nach dem Motto: Wie passen die Applikationen zum neuen Betriebssystem) geprüft, sondern auch eine Aussage getroffen, inwieweit die Hardware-Ressourcen zum neuen Konzept passen.

Angenommen in einem Unternehmen ist geplant, einige Arbeitslasten in eine virtuelle Umgebung zu migrieren und man weiß auch in etwa, welche Hardware-Spezifikationen die finale virtuelle Umgebung haben wird. Wenn der Verantwortliche in einer Testumgebung die migrierte Arbeitslast ausprobiert, kann er dann genauer feststellen, inwieweit die eigentlichen Annahmen zutreffen – und im Falle eines Falles auch entsprechend agieren.

Wer das in einer Test-Migrationsumgebung verifizieren möchte, dem sei geraten, dass er seine Tests „Stück für Stück“ ausführt: Sprich man sollte zu einem Zeitpunkt immer nur eine Arbeitslast von Windows Server 2003 auf einen Windows Server 2012 (oder 2012 R2) migrieren. Damit prüft man allerdings immer nur eine Last in der Testumgebung und nicht alle auf einmal – mit allen Vor- und Nachteilen.

Nach diesen Ausführungen stellt sich vor allem die Frage, was eine gute Testumgebung für eine derartige Migration ausmacht. Dabei sollte der Administrator einige Dinge beachten: Es gilt zunächst, eine Testumgebung zu finden, mit der sich valide Aussagen treffen lassen, ob der Migrationsplan aufgeht – oder ob es zu einem Scheitern kommt. Denn in der „echten“ Migration möchte man auf keine Probleme stoßen, die das gesamte Projekt gefährden. Dies ist umso ärgerlicher, wenn man diese Gefahren in der Testumgebung hätte gut erkennen können.

Der zweite Aspekt für die passende Testumgebung lautet: Es muss nicht die „finale Umgebung“ Eins-zu-Eins kopiert werden. Denn die Testumgebung muss nicht die Anforderung der Produktivumgebung erfüllen – sie dient in erster Linie dazu, den Test der Migration auszuführen. Man könnte zum Beispiel als Migrationsziel einen Failover-Cluster mit acht Knoten und Hyper-V (mit jeder Menge RAM und Prozessor-Power) benötigen, um die migrierten Arbeitslasten im Produktivbetrieb optimal zu handhaben. Doch für das Testen der Migration muss die Testumgebung bei weitem nicht so mächtig sein – in der Regel wird es auch ein Cluster mit zwei Konten tun – vor allem um ein Failover-Szenario testen zu können.

Die Hauptsache im Test wird es sein, dass man prüft, ob die Hardware-Ressourcen, die einer VM zugewiesen werden, für den Betrieb der Anwendung ausreichen. Des Weiteren geht es darum festzustellen, ob es generell irgendwelche Probleme gibt, wenn die Applikation auf dem neuen Betriebssystem zum Einsatz kommt.

Wenn man die Tests Schritt für Schritt ausführt, ist es auch nicht nötig, alle Arbeitslasten in der Testumgebung gleichzeitig zu betreiben. Damit wäre zwar eine Aussage machbar, wie die Hardware-Auslastung aussehen wird. Wer die einzelnen Arbeitslasten in der Testumgebung prüft, kann mit einer guten Näherung dann hochrechnen, wie die Anforderungen an die spätere Umgebung – mit den kombinierten Lasten – aussehen wird. Generell aber sollte die Testumgebung so ausgelegt sein, dass sie zumindest die Anwendung mit den höchsten Performance-Ansprüchen befriedigen kann.

Rainer Huttenloher