Jetzt wirds ernst: Infrastruktur-Fusion mit einer bedeutenden Neukundin – Teil 2/4

Schulungen und Know-how-Austausch

Zum Start des Projektes gab es mehrere Treffen zwecks Know-how-Austausch und Schulung. So erfuhren wir von Seiten der Webagentur viele weitere Details zum Aufbau ihrer Infrastruktur, was für unser Team sehr hilfreich für die Migration war. Und andererseits konnten wir das Team der Webagentur schulen, wie sie die Managed Server nutzen und via unser Cockpit diverse Arbeiten sehr einfach selbst erledigen können.

So entstanden auch die ersten neuen Managed Server, welche die Webagentur für interne Applikationen und neue Kundenprojekte nutzt – inkl. vollautomatisiertem Deployment mittels GitLab CI.

In der ersten Phase der Migration im Frühling 2025 konnten wir direkt mit den zuständigen Mitarbeitenden der Webagentur die nötigen Arbeiten im Detail planen und absprechen. Danke Jungs, das war mega hilfreich! 👌

Ab dem zweiten Teil des Projektes waren wir dann nach Personalwechseln seitens der Webagentur auf uns selbst gestellt. Der Support von Agentur-Seite war weiterhin gut. Aber weil die zentralen Know-how-Träger, welche die Infrastruktur wie ihren eigenen Hosensack kannten, weggefallen waren, wurde jeder Schritt automatisch etwas anspruchsvoller.

Wir übernehmen Verantwortung

Ein Teil der Abmachung zwischen Ops One und der Webagentur war, dass wir ab Mai 2025 den Betrieb der bisherigen Server übernehmen und diese fortan administrieren, pflegen und den Betrieb der darauf betriebenen Websites und Applikationen unterstützen. Mittelfristig sollen die bestehenden Applikationen nach und nach, sobald passend, auf neue Managed Server überführt werden, zum Beispiel im Rahmen anstehender Upgrades oder Relaunches.

Damit "wir übernehmen Verantwortung" kein leeres Lippenbekenntnis bleibt (ist es für uns nie, und uns ist bewusst, dass das Arbeit bedeutet), haben wir uns im Voraus diverse Gedanken gemacht: Worauf brauchen wir Zugriff, um effizient unterstützen zu können? Was muss noch angepasst werden, was vielleicht nicht auf den ersten Blick ersichtlich ist? Wo müssen wir Zuständigkeiten und Verantwortlichkeiten noch genauer klären?

Physischer Zugriff

Am bisherigen Datacenter-Standort waren keine Umbauten und Erweiterungen vorgesehen. Aber spätestens für den Rückbau am Ende der Migration – und notfalls aber auch schon früher, beispielsweise um eine defekte Komponente vor Ort tauschen zu können – haben wir uns gemeinsam mit dem Team der Webagentur darum gekümmert, dass mehrere Ops-One-Mitarbeitende über einen persönlichen Zutritts-Badge zum Datacenter verfügen, die nötige Sicherheitsschulung besucht, sowie einmal vor Ort den Zutritt geprüft und das Rack mit den verbauten Geräten besichtigt haben.

Ausgerechnet bei dieser Besichtigung vor Ort heulte dann der Feueralarm los und wir konnten das nur Minuten vorher an der Sicherheitsschulung gelernte Verhalten direkt in die Praxis umsetzen und das Datacenter über den nächstgelegenen Notausgang in Richtung Sammelplatz verlassen. Zum Glück handelte es sich nicht um einen Ernstfall, sondern um die periodisch stattfindende Übung des Datacenter-Betreibers. So erlebten wir als kostenloses Add-On gleich auch noch die Notfall-Prozesse einer Evakuation ☺️💪🏻. 

Virtueller Zugriff

Neben dem physischen Zugriff haben wir uns auch damit auseinandergesetzt, wie wir die bestehenden Systeme sicher erreichen und administrieren können. Dazu gehörten neben dem SSH-Zugriff auf die einzelnen VMs auch Zugriffe auf den bisherigen Virtualisierungs-Cluster, die Administrationsoberfläche der Firewalls und die bestehende Config-Management-Umgebung. Diese Zugriffe benötigten wir nicht nur für Betrieb und Wartung, sondern auch für die weiteren Umstellungen im Migrationsprojekt.

In diesem Zusammenhang haben wir auch das Configuration-Management mit Puppet übernommen und das bestehende Set-up leicht optimiert sowie Git-Repositories zusammengelegt. Ab diesem Zeitpunkt hatten die Mitarbeitenden der Webagentur zwar noch lesenden Zugriff, konnten aber an der Konfiguration der bestehenden Webserver-VMs nichts mehr ändern. Das war für die involvierten Personen eine Umstellung – aus Sicht der Betriebsverantwortlichkeit war es jedoch folgerichtig, dass nur dasjenige Team Changes an der Infrastruktur machen kann, welches sich bei Störungen auch um deren Lösung kümmern muss.

Dokumentation der Prozesse

Zeitlich befanden wir uns im späten Frühling, frühen Vorsommer. Durch die beschriebene Übernahme des laufenden Betriebs, und weil sich bei uns alle Engineers im Support regelmässig abwechseln, kamen so auch die sonst nicht direkt in die Migration eingebundenen Teammitglieder nach und nach mit den Support-Anfragen oder Changes der neuen Kundin in Kontakt. Die dabei aufgetretenen Fragen und zu klärenden Prozesse haben wir im Team geteilt, konsequent dokumentiert und abgelegt. So wurde der Wechsel im Support nach und nach einfacher und die teaminternen Rückfragen weniger.

Monitoring ist einfach – oder?

Die Webagentur hatte bisher ein eigenes Monitoring-System betrieben und damit bisher gegen 15 000 Parameter überwacht. Soweit kein Problem und ein gutes doppeltes Sicherheitsnetz. Aber es zeigte sich schnell, dass es doch nicht ganz so einfach ist.

Einerseits ergaben sich Doppelspurigkeiten bei Services, die wir übernommen und selbst zu überwachen begonnen hatten, die gleichzeitig noch durch die Webagentur überwacht wurden. Andererseits ergab sich durch die Regelung der Zuständigkeit für Puppet, dass Störungen, die im Monitoring der Webagentur erkannt wurden, welche sich auf systemnahe Komponenten bezogen, nicht durch das Team der Webagentur selbst gelöst werden konnten. Die Alarmierung bei ihnen machte so natürlich keinen Sinn mehr. Da es bisher keine Trennung gab zwischen Checks für die Websites ihrer Kundinnen und Kunden vs. serverweiten oder gar globalen Infrastruktur-Checks, war dies gar nicht so einfach zu entwirren.

Nach und nach konnten wir das Monitoring gemeinsam mit der Webagentur entflechten und klar aufteilen. Neu wurden bei Ops One ausschliesslich diejenigen Services überwacht, für welche Ops One verantwortlich ist. Und alles, was weiterhin in die Zuständigkeit der Webagentur fällt – und vom entsprechenden Team auch selbständig gelöst werden kann – im Monitoring der Webagentur überwacht und alarmiert.

Offsite-Backup

Die VMs auf dem bisherigen Virtualisierungs-Cluster wurden bereits vor der Migration an einem Remote-Standort gesichert. Dieses Offsite-Backup in der bestehenden Form wollten wir aber nicht 1:1 übernehmen und haben uns daher entschieden, die bestehenden VMs in unser Backup-Konzept mit aufzunehmen. Damit erreichten wir eine weitere Standardisierung und Reduktion von Einzelfällen, einhergehend mit der Vereinfachung unserer internen Prozesse im Support.

Wir konnten die nötigen Zugriffe einrichten und anschliessend in mehreren Etappen die initialen Full Backups der VMs erstellen. Die Daten der VMs der Webagentur kopieren wir nun ebenfalls an den gleichen Offsite-Backup-Standort, an dem wir auch unsere Managed Server sichern.

Nachdem sich gezeigt hatte, dass die tägliche inkrementelle Sicherung funktioniert, konnten die VMs von der bisherigen Backup-Lösung abgehängt und diese schlussendlich abgelöst werden. Selbstverständlich haben wir davor einen Restore-Test durchgeführt und erfolgreich absolviert 💪🏻.

Wartungsarbeiten 2.0

Das Betriebsteam der Webagentur übergab uns eine sorgfältig angelegte Dokumentation, aus welcher detailliert hervorging, welche Wartungsarbeiten wie und in welchem Intervall ausgeführt wurden. Anfangs übernahmen wir diesen Workflow fast 1:1 – die einzige Änderung war, dass die Aufgabe neu aus einem GitLab Issue Template statt einer Checkliste erstellt wurde.

Über die kommenden Monate vereinfachten wir den übernommenen Workflow in mehreren Runden immer weiter, mit dem Ziel, diesen möglichst einfach und fehlerfrei auszugestalten – unter anderem durch reines Copy-Paste von CLI Commands, weniger Einzelschritte und mehr Automatisierung.

Vorarbeiten Netzwerk-Migration

Eher im Hintergrund konnten Andri und ich für die spätere Netzwerk-Übernahme die nötigen Vorarbeiten erledigen.

Dazu wurden bei RIPE bereits früh im Projekt sämtliche Ressourcen (IP-Prefixe, AS-Nummer) der Webagentur an Ops One als LIR (Local Internet Registry) übertragen, in der PeeringDB die nötigen Einträge angepasst und schlussendlich der nun leere LIR-Account der Webagentur bei RIPE aufgelöst. Damit erreichten wir, dass wir alles Weitere bezüglich der bestehenden IP-Ranges fortan selbst und ohne externe Abhängigkeit steuern können.

Gleichzeitig war ab jetzt nach aussen erstmals sichtbar, dass Ops One hier im Infrastruktur-Betrieb involviert ist – auch wenn die zwei autonomen Systeme unter zwei AS-Nummern weiterhin separat aktiv waren.

Firewalls

Es klang so trivial: Firewall Ruleset aus den bisherigen Firewalls auslesen und am neuen Ort 1:1 abbilden, Feierabend. Ganz so einfach gings dann doch nicht – dieser vermeintlich kleine Umbau der Firewalls hat mich wohl einige meiner restlichen Haare gekostet …

Der Grundsatz-Entscheid zu Projektbeginn gab vor, dass wir die bestehenden Perimeter-Firewalls (physische Geräte) nicht mitnehmen und nicht weiter betreiben wollen. Damit die VMs (primär Webserver) weiterhin erreichbar sind, aber dennoch nicht komplett ungeschützt im öffentlichen Internet stehen, konnten wir die vorgelagerten Firewalls nicht ersatzlos weglassen.

Wir entschieden uns daher, auf Basis von nftables​ flottenweit auf den VMs lokale Firewalls einzurichten. Somit wurde jede einzelne VM "zur eigenen Zone" und es wurde festgelegt, wohin diese VM (ausgehend) verbinden darf, und von wo Traffic (eingehend) erlaubt ist. Für die meisten VMs konnte ein generelles Default Ruleset appliziert werden. Das Firewall-Modul wurde in Puppet jedoch so flexibel vorbereitet, dass auch spezifische Regeln pro Server möglich blieben.

Herausforderungen im Abbilden der Rulesets

Die grosse Krux stellte dabei das bisherige Ruleset dar, welches aus verschiedenartigen Regeln zusammengesetzt war. Neben Regeln, die den Zugriff von/zu einem explizit benannten Server erlaubten, gab es auch noch solche, welche ganze Gruppen von Servern umfassten. Soweit halb so schlimm. Die einzelnen VLAN/Prefix-Paare waren zudem in Zonen zusammengefasst, und es gab auch Firewall-Regeln, die sich auf ganze Zonen bezogen. Und dann gab es auch noch Dinge wie Verbindungen zwischen Servern innerhalb einer Zone, welche bislang nicht über die Firewall gingen, und damit weder als Regel noch in der Protokollierung der Firewall ersichtlich waren.

Eine weitere Herausforderung stellte das uralte FTP-Protokoll dar, bei dem es natürlich nicht reichte, den Port 21 zu öffnen. Das Protokoll sieht vor, dass für Passive-FTP nach dem Session-Aufbau die Ports gewechselt werden, und weitere Datenpakete dann von/zu Ports gehen, die geblockt werden. Zum Glück bietet nftables​ einen entsprechenden Helper, der den Datenverkehr mithört und dynamisch den ausgehandelten Port für diese Verbindung ebenfalls öffnet. Sobald dieser Helper konfiguriert ist, funktioniert der Datentransfer wieder.

Iterativer Rollout der lokalen Firewalls

Den flottenweiten Roll-out der lokalen Firewalls gestalteten wir in mehreren kleinen Etappen – man könnte es auch iterativ oder gar agil nennen: Auf jeweils wenigen Servern wurde die lokale Firewall aktiviert, eine Zeit lang beobachtet, ob irgendwas versehentlich geblockt wird, und dann nach einem Tag erneut kontrolliert. Der Roll-out zog sich daher über mehrere Tage hin und wir konnten kleinere Fehler – einzelne fehlende Rules – jeweils zeitnah korrigieren. Eine besondere Challenge stellten dabei z.B. Imports/Uploads dar, die nicht häufig genug, sondern z.B. immer am Samstag um 9 Uhr laufen (und wir am Donnerstag zuvor den betroffenen Server bereits als "läuft alles, wurde nichts geblockt" auf der Roll-out-Liste abgehakt hatten …).

So liefen dann über einige Wochen hinweg bis zum Wegfall der Firewalls (dazu später mehr) faktisch zwei Firewalls hintereinander: die physische Perimeter-Firewall und dahinter die lokale Firewall.