Rechenzentrums-Migrationen leicht gemacht

Es ist eine Mammuttaufgabe ein komplettes Rechenzentrum zu migrieren. Mit diesen Tipps klappt es.

Sie kennen das: Never changing a running system. Nirgendwo sonst ist dieser Spruch so prägend wie in der IT. Aber immer dann, wenn es um die Sanierung des eigenem in die Jahre gekommenen Rechenzentrums geht oder man von einem Dienstleister weg möchte, dann muß man ran an den Speck und die unliebsame Aufgabe in Angriff nehmen.

Vorüberlegungen

Bevor Sie mit dieser Aufgabe beginnen nehmen Sie sich folgenden Rat zu Herzen: nehmen Sie sich ausgiebig Zeit für die Migration Ihres Rechenzentrums. Nicht selten haben wir es erlebt, dass Kunden die Anzahl der Server zählen und der Meinung sind, das schaffen wir in drei Monaten. Weit gefehlt.

Bevor Sie anfangen machen Sie eine Bestandsaufnahme aller Systeme, das bedeutet Server, Storage, Switches, KVMs usw., die Sie im Rechenzentrum verbaut haben und gleichen dieses mit Ihrer CMDB ab. Ist Ihr Rechenzentrum bei einem Dienstleister gehostet, lassen Sie sich einen Extrakt aus seiner CMDB geben und vergleichen Sie, ob die Assets übereinstimmen. Oft genug haben wir es erlebt, dass nach der Rechenzentrums-Migration Systeme im Rechenzentrum übrig blieben, von denen kein Mensch mehr etwas weiß. Mit dieser Maßnahme verringern Sie Überraschungen dieser Art.

Anschließend schauen Sie sich die Applikations-Landkarte an. Gruppieren Sie Applikationen nach Service-Levels und Kritikalität. Je wichtiger ein System für das Unternehmen ist, desto höher sind die Ansprüche an die Migrationsplanung. Planen Sie auf keinen Fall die Migration aller zu einer Serviceklasse gehörenden Applikationen auf einmal ein. Geht hierbei etwas schief könnte unter Umständen Ihre Infrastruktur und damit Ihr unternehmerischer Fortbestand schwer zu retten sein. Gehen Sie also behutsam und mit einem gehörigen Augenmaß ans Werk und überlassen Sie die Planung jemanden, der genügend Erfahrung mit Rechenzentrums-Migrationen hat. An dieser Stelle ein wichtiger Hinweis: vergessen Sie auch nicht die Systeme aufzuführen, die für den Betrieb Ihrer IT notwendig sind. Also Monitoring-Systeme, DHCP-Server, DNS und so weiter.

Gruppieren Sie Ihre Migrationsplanung in Phasen. Ordnen Sie jeder Phase einzelne Systeme zu, die logisch zusammenhängen oder logisch am einfachsten zusammenhängend sich migrieren lassen. Allein das ist bereits ein Analyseaufwand, der eine gewisse Zeit in Anspruch nimmt und gewissenhaft durchgeführt werden muß. Beachten Sie hierbei auch die Tatsache, daß es virtuelle Systeme und physische Systeme gibt. Betrachten Sie genau, welche physischen Systeme eventuell virtualisierbar sind. Damit können Sie die Komplexität der Migration reduzieren. Sollte das nicht möglich sein und es bleiben Systeme, die physisch gemoved werden müssen, dann planen Sie ausreichend große Wartungsfenster in Abhängigkeit der physischen Entfernung ein.

Als letztes machen Sie sich Gedanken um die Daten des Unternehmens. Diese sind der wichtigste Teil der gesamten Migration, denn was nützen die System im neuen Rechenzentrum, wenn die Unternehmensdaten weg sind. Bedenken Sie bei der Datenmigration auch Latenzzeiten auf der Migrationsleitung. Je nach Größe der Datenmengen können verschiedene Szenarien zur Datenübertragung erforderlich sein. In einem unserer Rechenzentrums-Migrationen haben wir uns für die Methode “Datenübertragung via Adidas” entschieden und ein gesamtes NAS betankt, ins Flugzeug befördert und am Ziel wieder zurückgespielt.

Vorbereitungen

Eine der wichtigsten Vorbereitungen sind sicherlich das Festzurren der Rahmenparameter. Dazu gehören unter anderem:

  • Zu wann ist das alte Rechenzentrum verlassen und kann übergeben werden?
  • Welche Personen oder Rollen müssen in die  Rechenzentrums-Migration involviert werden?
  • An dieser Stelle nicht vergessen! Werden externe Dienstleister, die beispielsweise eine Applikation betreiben, bei der Migration benötigt?
  • Wie lassen sich die bestehenden Datenbestände am sinnvollsten migrieren?
  • Sind bestehende physische Server eventuell virtualisierbar und welche Einflüsse hat dieses auf lizenzrechtliche Bestimmungen oder den IT-Betrieb?
  • Sind Lizenzen an IP-Adressen oder System-Parameter gebunden und müssen  nach der Migration neu lizensiert werden?

Sind diese Fragen geklärt gilt es in Abhängigkeit zur Datenmenge eine groß genug dimensionierte Datenleitung zwischen dem alten und dem neuen Rechenzentrum aufzubauen. Auch hier müssen Sie bedenken, daß die Provider einige Zeit benötigen um die Migrationsleitung zu realisieren. Schließlich muß das Ziel-Rechenzentrum gut vorbereitet werden. Nicht selten haben wir es erlebt, dass der Kunde am Ziel nicht ausreichend Racks, Strom oder Klima zur Verfügung hatte, um die Systeme aufnehmen zu können. Das muß unbedingt vor der Migration geklärt sein. Auch wenn eine sukzessive Besiedelung des neuen Rechenzentrums geplant wird, müssen die grundlegenden Komponenten sukzessive ausgebaut werden und zwar bevor die Systeme am Zielort ankommen.

Das Projekt

Das Projektteam und seine Kompetenzen müssen sauber aufgestellt sein. Dazu gehören nicht nur die technischen Kompetenzen, sondern auch die, in dessen Rahmen der Projektmanager alleine ohne Hinzuziehen des Managements Entscheidungen zur Migration treffen darf.

Planen Sie ausreichend Personen für die Migration mit ein. Falls Sie über keine eigenen verfügen heuern Sie externe Hilfe an. Beachten Sie aber: Linienmitarbeiter, die die aktuelle Infrastruktur betreiben, sollten und können Sie nicht durch externe Kräfte ersetzen, da dieses das Projekt nur behindert. Genau diese Linienmitarbeiter können auch nicht nur zu einem Bruchteil ihrer Zeit dem Projekt zugeordnet werden. Es sei denn, Sie ziehen das Projekt entsprechend in die Länge – wobei hier erfahrungsgemäß oftmals die Zeit unzureichend ist.

Binden Sie Applikationsverantwortliche rechtzeitig in die Planung der Migration mit ein. Beachten Sie Frozen Zones, die eventuell in Ihrem Business entstehen können. Beispielsweise wegen Rechnungsläufe oder Jahresabschlüsse. Tragen Sie diese Frozen Zones in den Projektplan mit ein. Erstellen Sie einen umfangreichen aber sauber strukturierten Projektplan. Dieser muß allen Projektmitgliedern in Gänze, den Linienverantwortlichen für Ihre jeweilige Aufgabe zugänglich sein.

Für jede Migrationsphase oder Applikationslandschaft erstellen Sie Cutover-Pläne. Die Erfahrung hat gezeigt, dass Sie rechtzeitig alle Personen, die von dieser Migration betroffen sind, in die Gespräche einbinden müssen. Beachten Sie auch Urlaubspläne und den Betriebsrat, sofern vorhanden. Nicht selten kann der Betriebsrat der Showstopper für eine geplante Migration werden. Zu jedem Cutover-Plan gehört die lückenlose und vollständige Aufzählung von Aktionen, die für den Cutover notwendig sind. Sind vorbereitende Maßnahmen erforderlich, so gehören die unserer Meinung nach ebenfalls in die Cutoverpläne hinein um am Tag des Cutovers noch einmal auf einem Blick sehen zu können, ob alle Vorbereitungen auch tatsächlich abgeschlossen sind.

Last but not least planen Sie funktionale Tests nach der Migration ein. Das bedeutet, dass die Fachgruppen die Applikation nach einem genau definierten Testmuster testen und zum Abschluß bestätigen, dass die migrierte Applikation funktioniert. Bleiben Altsysteme im alten Rechenzentrum zurück gehören diese nach einer Karenzzeit abgebaut. Erst danach gilt die Migration als vollständig abgeschlossen.

Die Durchführung

Die eigentliche Planung und Vorbereitung ist der größte Anteil der zu leistenden Arbeit, die bei einer solchen Rechenzentrums-Migration auf Sie zukommen wird. Ist diese sauber durchgeführt, die Risiken der Migration je Phase oder Applikationslandschaft sauber aufgezeigt, dann ist die eigentliche Arbeit des Cutovers relativ schnell und einfach machbar. Aber seien Sie hier auf das Unvorhersehbare gefasst: nicht selten kommt es plötzlich am Ziel zu Problemen, an die niemand im Vorfeld gedacht hat. So hat beispielsweise bei einer unserer Migration ein fehlerhafter Netzwerktreiber auf dem VM-Host dazu gesorgt, dass VLANs nicht sauber eingelesen und implementiert wurden. Glücklicherweise konnte während des Cutovers ein Workaround gefunden werden. Allerdings musste bis zur endgültigen Lösung alle nachstehenden Migrationen auch erst einmal verschoben werden.

Die fachlichen Tests zur Bestätigung der reibungslosen Funktion der migrierten Applikation runden den Cutover ab. Oftmals interessiert den Applikationsverantwortlichen die Migration nicht wirklich, zumal ja immer wieder der Projektmanager bestätigt, dass nach der Migration alles wieder so funktioniert wie vorher. Der Sinn eines fachlichen Funktionstests ist oftmals nicht offensichtlich. Dennoch bestehen Sie auf diese Tests, da das Ergebnis der Tests über den Erfolg oder Mißerfolg der Migration entscheidet.

Es gibt aber auch Situationen, in denen abzuwägen ist, ob man den geplanten Cutover nun durchführt oder nicht. So existierte vor einem unserer Cutover einmal ein Problem mit der Applikation selbst, welches nach dem Aufspielen eines Updates zu Tage gefördert wurde. Da nun weder Tests vor und schon gar nicht nach dem Cutover vom Fachteam durchgeführt werden konnten, entschieden wir uns den Cutover mit der Begründung einer fehlerhaften Applikation abzusagen. Alternativ – und das war ebenfalls in der Diskussion – hätte man auch bestätigen können, den Fehler mit zu migrieren und auf der Zielseite nach dem Cutover zu eliminieren.

Bei der Durchführung des Cutovers hat sich der sogenannte “LAST-CALL” als sehr nützlich erwiesen. In diesem LAST-CALL war jeder, der mit der Migration betraut war, zugegen und es war die letzte Möglichkeit, ein Veto gegen den Cutover einzubringen. Obiges Beispiel kam genau in dem LAST-Call zur Sprache und führte dann letztendlich zur entsprechenden Entscheidung den Cutover nicht durchzuführen. Es muß immer daran gedacht werden, dass ein Unternehmen und sein Erfolg von der Migration abhängt und dementsprechend gehandelt und entschieden werden muß.

Der Abschluß

Sind alle Migrationen mit einem erfolgreichen Cutover abgeschlossen, gilt es abermals das alte Rechenzentrum zu analysieren, ob nicht doch noch einige Komponenten “vergessen” wurden. In unserer Praxis zeigten sich trotz sorgsamer Planung beispielsweise Komponenten, die bereits aus den Büchern und der CMDB verschwunden, aber tatsächlich im Rechenzentrum noch verbaut waren. Das älteste was wir hier erlebten waren Systeme, die seit 15 Jahren ohne Netzanschluß voll betriebsbereit vor sich her liefen. Wenn nicht bereits geschehen und beim initialen Abgleich mit der CMDB aufgefallen, dann ist genau jetzt der Zeitpunkt sich um diese Gerätschaften zu kümmern. Danach kann das Rechenzentrum ausgefegt werden und der Schlüssel an dem Nachfolger übergeben werden. Das Projekt Rechenzentrums-Migration wurde erfolgreich abgeschlossen.