Bewegtdaten wörtlich genommen – Metaways zieht in ein neues Rechenzentrum

Download als PDF

Server, Switche, mehrere Höheneinheiten Storage, hunderte LAN-Kabel, unzählige Stromkabel.. Ein Rechenzentrumsumzug hat es ganz schön in sich. Fragen Sie mal bei der Metaways Infosystems GmbH nach, wir haben das gerade hinter uns.

Grundsätzlich betreibt Metaways Colocations in zwei Rechenzentren in Hamburg, eines davon ISO-27001 zertifiziert. Nun war es an der Zeit, dass auch als zweiter RZ-Standort ein ISO-27001-zertifiziertes Haus her sollte. Gesucht, Vor-Ort-Begehungen durchgeführt, Leistungen verglichen, gefunden: Level 3 sollte das neue Zuhause für einen Teil unserer Server werden. Und mit der Entscheidung ging die Arbeit dann so richtig los.

Weil es kein simpler Umzug war, wo man innerhalb von zwei Tagen alles in Kartons verstaut und die letzten davon erst nach Monaten wieder auspackt, sondern in diesem Fall geschäftskritische Kundensysteme physisch umgezogen wurden, musste ein ausgefeilter Plan her.

Zunächst stand daher eine Inventur an: Welche Gerätschaften hatten wir noch in der Hinterhand, um eine weitere Hosting-Infrastruktur zur Überbrückung aufzubauen? Switche, Server, Festplatten – liegt hier irgendwo noch RAM rum?

Unsere Asservatenkammer gab so einiges her, aber nicht genug, sodass als nächstes Hardware besorgt werden musste. Und wieder neue Fragen einschließlich Entscheidungen: Was brauchen wir mittelfristig sowieso neu? Kann man Hardware über einen kurzen Zeitraum mieten?...

Dann das Ganze aufbauen und einrichten. Dazu wurde extra ein Büroraum geräumt und zu einem provisorischen Lab umfunktioniert. Als das alles so weit lief, ging es darum, die vielen einzelnen Umzüge in ein Konzept zu gießen und die betroffenen Kunden über das Timing zu informieren. Schließlich musste auch auf Kundenseite einiges beachtet werden: Content-Freeze, kurze Downtimes kalkulieren und für den Fall Wartungsseiten bereithalten.

Und erst jetzt ging es an den eigentlichen Umzug. Eine nach der anderen wurden die Kunden-Plattformen in zahlreichen Nachtschichten Schritt für Schritt ins neue Rechenzentrum gebracht.

Schritt 1.) Migration Firewall und Loadbalancing Regelwerk
Erstellung Sicherung Firewall- und Loadbalancing Regelwerk der Plattform
Einspielen Sicherung Firewall- und Loadbalancing Regelwerk der Plattform in Shared Firewall / Loadbalancer im neuen RZ

Schritt 2.) Vorbereitung, Auftrennen der Plattform
Deployment Freeze
Stop Failover Mechanismen auf dem DB Cluster (Heartbeat: MySQL, Redis)
Stop DB Replikation
Stop Redis Replikation
Entfernung Webserver aus dem Loadbalancing
Stop aller VMs auf Server kvm02 und Prüfung Verfügbarkeit

2. Vorbereitung, Auftrennen der Plattform
Transport und Einbau Server kvm02 im Level 3 RZ
Smoke-Test

Schritt 3.) Einrichtung Replikation-NAT und DB Synchronisation (nur Live)
Einrichtung Replikation-NAT von Plattform Level3 RZ zu Plattform bei Versatel
Start und Smoke-Test DB VMs
Einrichtung DB Synchronisation von vdb01 auf kvm01 zu vdb02 im Versatel RZ

Schritt 4.) Golive im Level 3 RZ
Schaltung Wartungsseite (Die Wartungsseite war 15 Minuten geschaltet)
Nachsyncronisation der Daten auf Shared Storage
MySQL und Redis Replikation wurden geprüft
Beenden der Repliation auf Versatel Seite
Beenden der Dienste MySQL/Redis bei Versatel
Starten der HA Service IP Addressen bei Level3
Migration der Gitlab VM, finale Synchronisation
Umstellung öffentliches und internes Routing der Plattform ins neue RZ und somit
Golive
abschließender Gesamttest

Schritt 5.) Wiederherstellung Plattform nach Golive
Shutdown und Ausbau Server kvm01
Transport und Einbau Server kvm01 im Level 3 RZ
Smoke-Test kvm01
Einbindung Server kvm01 in Plattform
Wiederherstellung der DB Replikation
abschließender Gesamttest

So oder so ähnlich sah das zumindest bei den Normalfällen aus. Andere Plattformen erforderten einen wesentlich komplexeren Migrationsplan. Aber dank der guten Planung lief alles erstaunlich glatt. Hier und da gab es vereinzelten Schluckauf (z.B. musste eine Maschine etwas „unlogisch“ konfiguriert werden), aber durch erhöhte Aufmerksamkeit unserer Administratoren und vorher festgelegten Fallback-Plänen, konnten letztlich alle Klippen umschifft werden und manch ein Lob von Kunden eingeheimst werden.

Fazit: Muckis vom Schleppen, hoher Koffein-Bedarf, durchdachte und zukunftssichere Konfiguration der neuen Racks. Vor allem aber konnten wir, nicht ganz freiwillig, die redundanten und hochverfügbaren Setups unserer Kunden auf Herz und Nieren prüfen – und stellten fest: Alles hält so, wie die Theorie es versprach.