Final Countdown oder Grande Finale: Infrastruktur-Fusion mit einer bedeutenden Neukundin – Teil 4/4

Unser Test-Netz war ein /24​ für IPv4 mit gut 250 nutzbaren Adressen resp. ein /48​ für IPv6 mit unanständig vielen nutzbaren Adressen. Die bisherige Firewall-Infrastruktur nutzte kein VRRP, sondern eine anders funktionierende proprietäre Lösung. Und im Test-Netz hatten wir nur genau eine Test-VM, daher fiel uns das folgende Problem lange Zeit gar nicht auf:

Das Problem

Die Krux mit VRRP ist, dass pro Netzwerk-Segment jeweils 3 IP-Adressen belegt werden. Häufig x.x.x.1​ als virtuelle IP für den Default-Gateway, und x.x.x.2​ sowie x.x.x.3​ für den ersten resp. zweiten Router/Firewall. Während die zwei Geräte über ihre jeweils eigene/individuelle IP-Adresse mit dem Gegenüber kommunizieren, um zu prüfen, ob "der andere" noch da ist, kann die virtuelle IP zwischen den Geräten hin und her wandern. Immer nur dasjenige der zwei Geräte, welches als aktiver Node erkoren ist, hört auf diese Adresse.

Unter den gut 15 Netzwerk-Segmenten waren in den allermeisten noch genügend IP-Adressen frei, um jeweils 2 weitere Adressen, die für VRRP zusätzlich benötigt wurden, zu reservieren. Dummerweise aber nicht in allen … Bei zwei Segmenten waren effektiv alle (!) Adressen belegt – rappelvoll sozusagen.

Die Lösung

Die Lösung war am Schluss, zwei IPv4-Netze zusammenzulegen (aus zwei /28​ mach ein /27​). Dadurch wurden knapp genug IP-Adressen frei, damit es reichte und uns in der späteren Umstellung nicht um die Ohren flog. Die pro IPv4-Segment bestehenden /64 IPv6-Segmente konnten wir so belassen, da dort eine Zusammenfassung durch IPv6-Eigenheiten mühsamer und längerfristig vermutlich störungsanfälliger gewesen wäre.

Migration der VMs

Nachdem wir das Platz-ist-knapp-Puzzle lösen konnten, stand der Migration der einzelnen produktiven VMs nun nichts mehr im Weg. Wir waren sogar ziemlich überzeugt, dass die Umstellung an einem Abend durchführbar wäre. Aber getreu unserem Ansatz, keine Big-Bang-Migration zu machen, planten wir die Umstellung in Etappen und haben dafür mit der Webagentur drei Wartungsfenster definiert. Im ersten und zweiten Wartungsfenster wollten wir die VMs übertragen; das dritte Wartungsfenster war ein Reserve-Slot für den Fall der Fälle.

Überprüfung der Abläufe

In den Tagen vor dem ersten Migrations-Wartungsfenster haben wir mit dem Test-Netzwerk die Abläufe für die Migrations-Nacht nochmals geprüft. Dabei haben wir die Konfigurations-Changes für Router und Firewalls vorbereitet, 4-Augen-reviewed, und noch einmal von Anfang bis Ende komplett durchgetestet und Abweichungen dokumentiert.

Durchführung der Migration

Die effektive Migration begann jeweils um den Mittag herum mit einem manuellen Sync der grundsätzlich ja bereits auf den Ziel-Cluster synchronisierten VMs. Dies, um grössere Daten-Transfers und damit verbundene Wartezeiten am Abend zu umgehen. Dieser Vor-Sync war meist im Bereich von 30-60 Minuten abgeschlossen (für mehrere VMs).

Die Migrations-Crew aus Andri und mir traf sich dann jeweils am späten Abend in einem Call für die effektive Migration. Der Umzug der VMs erfolgte pro Netzwerk-Segment, weil wir gleichzeitig auch die Routing-Weichen umstellten. Somit durchliefen wir pro Netzwerk-Segment folgende Schritte:

• Routing: BGP Announcement seitens Ops One aktivieren resp. scharf schalten und auf den bisherigen Routern deaktivieren.
• Routing: Announcements und Erreichbarkeit der VMs von extern überprüfen.
• Nutanix: VMs erneut synchronisieren, herunterfahren, migrieren, auf Ziel-Cluster wieder starten (alles via Nutanix CLI).
• Netzwerk: Nötige statische Routen setzen resp. entfernen (die für den Über-Kreuz-Betrieb nötig waren), Default Gateway Interface auf bisherigen Firewalls deaktivieren und dafür auf unseren Core-Routern aktivieren.
• Testen, testen und noch 3 Mal testen. 

Der Ausfall pro VM beschränkte sich meist auf zwei kurze Unterbrüche: einmal pro VM, während diese für die Migration kurz heruntergefahren wurde (ca. 1–2 Minuten), und dann noch einmal kurz für alle VMs zeitgleich bei der Umstellung der Default Gateways (wenige Sekunden).

Abschluss und Testing

Mit jedem Segment ging es leichter, und einzelne Segmente konnten durch die vorbereiteten CLI-Commands und Scripte in wenigen Minuten migriert werden. Nachdem die einzelnen Abschnitte übernommen und einzeln getestet wurden, folgten jeweils noch weitere Tests zum Abschluss über alle Segmente hinweg, bevor wir kurz nach Mitte November vermelden konnten, dass jetzt alle Webserver-VMs am neuen Ort laufen. Das angekündigte Reserve-Wartungsfenster wurde nicht benötigt und konnte abgesagt werden.

Out-of-Band-Zugriff

Bis anhin verlief der gesamte produktive Traffic über die erwähnten Firewalls. Auch der Zugriff für die Administration erfolgte darüber. Für den Fall der Fälle war ein Out-of-Band-Zugriff vorhanden, dieser führte aber über Router, die abgelöst werden sollten.

Um hier nicht durch eine Fehlmanipulation den Zugriff auf Management Interfaces zu verlieren, mussten wir uns etwas überlegen. Das Risiko war zu gross, dass wir uns so kurz vor dem Ziel noch selbst aussperren, weil wir versehentlich die eine relevante Verbindung kappen (auch bekannt als "den Ast absägen, auf dem wir sitzen").

Da absehbar war, dass wir hier nur noch temporär überbrücken mussten, erstellten wir kurzerhand eine virtuelle Maschine auf dem abzulösenden Cluster, welche über den Internet-Uplink des Datacenter-Betreibers (eben diesen Out-of-Band-Pfad) unabhängig von den IP-Netzen der Webagentur erreichbar war.

Diese VM konfigurierten wir mit weiteren, in den jeweiligen internen VLANs verbundenen Netzwerk-Interfaces so, dass wir darüber bis zur Abschaltung des Nutanix-Clusters auf die relevanten Systeme Zugriff hatten (Nutanix-Prism-Administrationsoberfläche, Firewall-Management etc.).

Abschaltung und Rückbau

Mit der Migration der einzelnen VMs pro Netzwerk-Segment hatten wir auch das Routing des jeweiligen IP-Netzes umgestellt. Am Ende war derjenige Prefix, über den sie selbst mit öffentlichen IP-Adressen erreichbar waren, das einzige verbleibende BGP Announcement, das die bisherigen Router noch nach aussen tätigten. In einem letzten Migrationsschritt konnte dieses allerletzte Announcement auch noch auf die Router bei Ops One überführt und schlussendlich die zwei bisherigen Router-VMs heruntergefahren werden.

Nachdem damit keine produktiven VMs mehr auf dem Nutanix-Cluster liefen, konnten in einem letzten Schritt über den Out-of-Band-Zugriff auch noch die Firewalls factory-resetted und heruntergefahren, sowie der Nutanix-Cluster aufgelöst und heruntergefahren werden.

Einige Tage später konnten wir sämtliche Geräte aus dem Rack am bisherigen Datacenter-Standort ausbauen. Diesmal ohne Feueralarm und Evakuations-Übung 😰💪🏻.

Konsolidierung DNS-Resolver und Mail-Relay

Vermutlich hätten wir dieses Thema auch früher angehen können. Ans Ende gepackt hatten wir es aus taktischen Gründen: Wären wir nicht schnell genug mit den heissen Themen vorangekommen, hätten wir uns um die bestehenden DNS-Resolver und Mail Relay VMs notfalls auch erst Anfang 2026 kümmern können. Das war schlussendlich dann aber gar nicht nötig und ich konnte die Umstellungen ebenfalls noch vor Weihnachten erledigen.

Kein weiterer Betrieb nötig

Bei der genaueren Analyse zeigte sich, dass die Mail Relay VM gar nicht abgelöst und längerfristig betrieben werden musste. Da nur ganz wenige Server ausgehende Mails über dieses Mail Relay ins Internet rausschickten, war die Lösung am Ende eine einmalige Umstellung der betroffenen Webserver. Diese senden ihre Mails fortan direkt über den lokalen Mailserver raus ins Internet (gleich wie die restlichen Server auch).

Abwicklung über unsere DNS-Resolver

Nur für die migrierten Webserver der Webagentur weiterhin separate DNS-Resolver zu betreiben, parallel zu den bestehenden Ops One DNS Resolvern, erschien uns nicht sinnvoll. Der Zugriff auf unsere DNS Resolver wurde freigegeben, die Erreichbarkeit von allen VMs der Webagentur her geprüft, und anschliessend die Resolver-Konfiguration auf allen VMs umgestellt.

… und noch einmal Firewalls 🙈

Zwischenzeitlich hat uns auf einzelnen Servern hier noch Docker ins Schienbein getreten: Durch das Hinzufügen zusätzlicher Firewall-Regeln in der lokalen Firewall wurde das Ruleset neu geschrieben, und die durch Docker selbständig hinzugefügten Rules dafür entfernt. Resultat war z. B., dass einzelne Container nicht mehr ins Internet verbinden konnten – sich aber (besonders fies!) als "alles OK" gemeldet haben und deswegen auch im Monitoring nicht aufgefallen sind. Für dieses Problem haben Markus und Andri aber zeitnah eine Lösung gefunden und die nächste Firewall-Anpassung erfolgte ohne Probleme. Damit konnten wir 3 weitere VMs ausser Betrieb nehmen, die es nun nicht mehr benötigte.

Aufräumen und Abschluss

Nach etwas abschliessendem Cleanup bei uns intern (z.B. Dokumentation finalisieren) haben wir auch noch das Routing optimiert und z.B. die /24-IPv4-Prefixe zu einem /22​ zusammengefasst (und die /48​ Prefixe bei IPv6 zu einem /29).

Und schliesslich haben wir (noch einmal) von extern die ganzen Netze mittels einem nmap​ Scan auf offene Ports geprüft, einfach um sicherzugehen, dass wir auch nach dem Wegfall der Perimeter-Firewalls nichts übersehen, was vorher noch vor den VMs weggefiltert wurde.

Hier wäre die Migration eigentlich fertig – aber etwas haben wir noch gemacht:

Testlauf DDoS Protection/BGP-Blackholing

Zum Schutz unserer Infrastruktur gegen DDoS Angriffe nutzen wir Voxility. Im Falle eines Falles können wir IP-Netze via BGP über Voxility umleiten. Dort werden die eingehenden Pakete analysiert und nur der "saubere" Traffic an unsere Infrastruktur weitergegeben.

Um sicherzustellen, dass dieser Schutz-Mechanismus nicht nur für die bestehenden Ops One IP-Netze, sondern auch für die neu zu uns migrierten IP-Netze funktioniert, haben wir das geprüft und temporär den Traffic über Voxility umgeleitet. Alle Server waren während des Testlaufs durchgängig erreichbar und unsere dokumentierten Prozesse haben funktioniert (und wurden gleichzeitig auch mitgetestet).

Neben der Umleitung eines ganzen IP-Netzes (viele IP-Adressen) über das Scrubbing-Center zur Filterung gibt es für einzelne angegriffene IP-Adressen auch die Möglichkeit, selektiv nur diese vorübergehend auszuschalten. Auch dieses Szenario haben wir sicherheitshalber mit einem einzelnen Server getestet und dessen Adressen vorübergehend "blackholed", also in ein schwarzes Loch umgeleitet. Nachdem auch diese Prozesse funktioniert haben, konnten wir sicher sein, dass jetzt alles OK ist.

Deadline? Yeah!

Die oben beschriebenen Testläufe konnten wir etwa zehn Tage vor Weihnachten abschliessen, sämtliche Badges zum bisherigen Datacenter retournieren und damit das Projekt erfolgreich und sogar VOR dem Zeitplan abschliessen 💪🏻🎉.

Vielen Dank an alle Beteiligten, sowohl im Ops One Team wie auch auf Seite unserer Kundin. Die Zusammenarbeit hat super geklappt und wir freuen uns darauf, diese auch im etwas ruhigeren Alltagsbetrieb so fortführen zu können ☺️.