Die Migration von Infrastruktur zwischen Rechenzentren zählt zu den anspruchsvolleren Aufgaben im Bereich IT-Outsourcing und IT-Infrastruktur. Sie erfordert einen präzisen Plan, eine gute Kenntnis der Umgebung des Kunden und eine enge Abstimmung mit den Anbietern der Datenverbindungen. Im Folgenden beschreiben wir Schritt für Schritt, wie wir die gesamte produktive Netzwerk- und Serverumgebung unseres Kunden verlagert und dabei den Betrieb seiner Dienste aufrechterhalten haben.
Der Auftrag
Unser langjähriger Kunde, für den wir eine Reihe umfassender Leistungen erbringen, beauftragte uns mit der Migration seiner gesamten produktiven Netzwerk- und Serverinfrastruktur vom georedundanten Standort zum Hauptstandort. Im laufenden Betrieb übernehmen wir für ihn unter anderem:
- umfassenden IT-Support,
- die Administration der Server- und Netzwerkinfrastruktur vor Ort und in der Cloud,
- die Konfiguration und Wartung von Firewalls und VPN-Konzentratoren.
Da wir den aktuellen Zustand der Netzwerkinfrastruktur und die Richtung ihrer Weiterentwicklung kannten, konnten wir gezielt mit der Umsetzung des Auftrags beginnen.
Bestandsaufnahme
Wir begannen mit der Bestandsaufnahme der Hardware und ihrer Anordnung in den Racks. Dabei erfassten wir 24 Geräte der produktiven Serverinfrastruktur (Virtualisierungshosts und Speichersysteme) sowie 14 Netzwerkgeräte: Switches, BGP-Router, einen DMZ-Router, Firewalls und VPN-Konzentratoren.
Anschließend prüften wir, welche Geräte und Verbindungen in die Migration einbezogen werden mussten. Außerdem verschafften wir uns einen ersten Überblick über den verfügbaren Platz für zusätzliche Hardware im Zielrechenzentrum (DC1). Danach planten wir im Detail, wo jedes Gerät in den Racks untergebracht werden sollte.
Vorbereitung
Zu Beginn bot der Serverraum in DC1 nur wenig freien Platz für zusätzliche Hardware. Nachdem wir mehrere Racks von alten Geräten geräumt hatten, war ausreichend Platz vorhanden. Anschließend entstand ein Projektplan, der alle wesentlichen Punkte festlegte:
- die Reihenfolge der zu migrierenden Dienste,
- die Anordnung der Geräte in den Racks,
- die Verkabelung der Netzwerk- und Stromanschlüsse mit einer möglichst weitgehenden physischen Trennung der Dienste innerhalb desselben Raums und zwei unabhängigen Stromversorgungsleitungen.
Wir legten dem Kunden den Plan zusammen mit den Terminen, den potenziellen Risiken und sämtlichen Arbeitsschritten vor. Dazu zählten auch die Tests nach Abschluss der Arbeiten, die wir gemeinsam mit den Telekommunikationsdienstleistern durchführten. Diese mussten die Zugangsverbindungen zu den Diensten wie MPLS, BGP, Internet usw. verlagern. Für die gesamte Migration planten wir vier Tage und teilten sie in vier Phasen auf.
Konfiguration
Im ersten Schritt bereiteten wir im Serverraum die Konfiguration für die neuen Geräte auf Grundlage des zuvor ausgearbeiteten Projekts vor. Da dieser Teil der Arbeiten die laufende, vollständig im Produktivbetrieb befindliche und kritische Infrastruktur nicht berührte, führten wir ihn während der regulären Arbeitszeit aus, ohne den Betrieb der Dienste zu beeinträchtigen.
Migration
Im zweiten Schritt migrierten wir die kritischen Server zwischen den Virtualisierungshosts von DC2 nach DC1.
Der dritte Schritt war die physische Verlagerung der Serverhardware mit Unterstützung eines professionellen Transportunternehmens. Aufgrund der dort betriebenen Dienste fand dieser Schritt an einem Sonntag statt. Wir verlagerten die Hardware aus den Racks in DC2 in die vorbereiteten Racks in DC1. Dieser Schritt verlief ohne größere Probleme. Alle Aufgaben schlossen wir innerhalb der vorgesehenen Zeitfenster ab.
Der letzte und vierte Schritt, die Verlagerung der Netzwerkgeräte, war weitgehend nur noch eine Formalität. Unsere Netzwerktechniker trafen am Morgen gemeinsam mit den Mitarbeitern des Telekommunikationsdienstleisters am Standort ein. Wir bauten die Netzwerkhardware in DC2 ab, transportierten sie nach DC1 und installierten sie dort.
Nach dem physischen Anschluss der Geräte sowie der Prüfung der Ports, des Betriebs der Dienste und der Failover-Mechanismen betrachteten wir das gesamte Projekt als erfolgreich abgeschlossen. Während der Migration kam es bei keinem kritischen Dienst auch nur zu einer Sekunde ungeplanter Unterbrechung. Die einzige beobachtete Unterbrechung trat beim Test eines Failover-Mechanismus auf. Sie dauerte 21 Pings und lag innerhalb der akzeptierten, geplanten Testszenarien. Für die Benutzer und die im 24/7-Betrieb laufenden Dienste war außer einer geplanten Unterbrechung von etwas mehr als zehn Sekunden nichts zu bemerken.