Hosenlupf mit Ansage: Infrastruktur-Fusion mit einer bedeutenden Neukundin – Teil 1/4

Anfang 2025 kontaktierte uns eine Schweizer Webagentur mit einer spannenden Projekt-Anfrage: Bisher hatten sie den Betrieb der Websites und Webapplikationen, welche aus ihren Kundenprojekten resultierten, selbst übernommen. Aufgrund veränderter Umstände hat sich die Geschäftsführung schliesslich dazu entschieden, das Hosting künftig auszulagern, und zwar an uns! 🥳 Bis es zu diesem Entscheid kam, mussten wir allerdings so einiges liefern:

Assessment und Planung

Die Agentur fragte uns an, ob wir uns vorstellen könnten, gemeinsam eine initiale Auslegeordnung zu machen, sowie daraus dann einen Vorschlag für eine allfällige Übernahme von Teilen des Puzzles abzuleiten. Bei den ersten Gesprächen kam eine schier nicht enden wollende Liste an Themen, Systemen, Applikationen und Dingen zur Sprache. Anfangs war es schwer, nicht den Überblick zu verlieren. Einzelne Dinge schienen zunächst ähnlich wie bei uns, unterschieden sich bei näherem Hinsehen dann aber doch sehr von der Ops-One-Infrastruktur.

Nach und nach entstand gemeinsam ein grobes Bild. Und es reifte die Erkenntnis, dass es sich hier um ein komplettes Universum einer eigenen Hosting-Infrastruktur handelt und nicht nur um "ein paar Webserver". 

Ohne jedes Detail aufzulisten, umfasste die Migration schlussendlich folgende Elemente:

• Netzwerk: Datacenter-Uplinks inkl. Peerings am SwissIX, eigene IP-Prefixe und AS-Nummer, Standort-Vernetzung, alles Dual-Stack mit IPv4 und IPv6
• Geräte: Virtualisierungs-Cluster, Switches, Firewalls, Power-Switches
• Virtuelle Maschinen: Webserver, Mailserver, authoritative DNS-Server und DNS-Resolver, Gitlab Server + Gitlab Runner, Router
• Applikationen: Gitlab, Mailserver, Netbox, DNS-Management, div. interne Web-Applikationen
• Portfolio aller Domain-Namen
• … und noch einiges mehr!

Ausklammerung der internen IT

Bewusst nicht Teil des Konsolidierungs- und Migrations-Projekts war die interne IT (Büro-Netzwerk inkl. WLAN, Endgeräte und Zubehör wie Drucker etc.). Aufgrund gewachsener Strukturen war die interne IT aber stark verzahnt mit der Hosting-Infrastruktur, was sich z. B. durch die Standortverlinkung zeigte. In der Projektplanung mussten wir dies mitberücksichtigen, selbst wenn die interne IT sonst nicht in unsere Zuständigkeit fiel.

Grundsatz-Entscheide für die Projektumsetzung

Für das Projekt haben wir uns auf folgende Strategie und "Spielregeln" geeinigt:

• Wir wollen die bestehende Hardware nicht einfach 1:1 in unser Datacenter übernehmen und weiter betreiben.
• Die Verschiebung von 250+ Websites/Applikationen auf neue Managed-Server sehen wir als zu riskant (und mit viel Aufwand verbunden). Daher sollen ganze VMs migriert werden, ohne dabei ihre IP-Adressen zu ändern. Einzelne Websites/Applikationen können später eine nach der anderen auf einen neuen Managed-Server umziehen, z. B. beim nächsten Upgrade oder Relaunch.
• Es soll keine NAT-Konfigurationen mit internen IP-Adressen mehr geben. Die physischen Firewalls sollen wegfallen.
• Für die Migration beim Routing und den virtuellen Maschinen wollen wir möglichst viel Flexibilität; wir wollen definitiv keine Crash-Boom-Bang-Migration.
• Für eine bestehende site-to-site VPN-Strecke müssen wir möglichst früh im Projekt prüfen, wie wir diese zukünftig betreiben können.
• Möglichst viele Redundanzen sollen aufgelöst und, wo sinnvoll, Bereiche konsolidiert werden.
• Es gibt eine harte Deadline: Ende Dezember 2025 muss alles umgezogen und die Hardware aus dem bisherigen Rack im Datacenter ausgebaut sein.

Nachdem das Bild so für alle Beteiligten klarer geworden war, und wir uns mit der Webagentur bezüglich der vertraglichen und finanziellen Rahmenbedingungen geeinigt hatten, konnten wir direkt mit der Umsetzung starten:

Low-hanging Fruits

In der ersten Phase (ca. Frühling 2025) lag unser Fokus darauf, gemeinsam mit der Web-Agentur die Themen anzugehen, bei denen wir auf bestehende, standardisierte Modulbausteine zurückgreifen konnten. Dazu gehören unser Managed Server, unser Cockpit für die Verwaltung von Servern, Domainnamen und DNS-Zonen sowie SaaS-Lösungen wie GitLab und Mailcow. Da wir dafür keine Engineering-Vorarbeiten zu erledigen hatten, und beispielsweise ein leeres GitLab oder einen Mailserver mit Mailcow durch unsere standardisierten Prozesse jederzeit bereitstellen konnten, ging es hier zügig vorwärts.

Git Repositories, GitLab Runner und Mail

Kniffliger wurde es bei der Migration sämtlicher Git Repositories vom bestehenden GitLab Server, der GitLab Runner sowie der Übertragung der Mailkonten inklusive Anpassung der DNS Records aller migrierten Mail-Domains. Diese Arbeiten mussten terminlich mit der Webagentur und teils deren Kundinnen und Kunden genau abgesprochen und die nötigen Arbeiten zum definierten Zeitpunkt hin ausgeführt werden. Hier hat sich einerseits die Erfahrung von Marco und Markus bei solchen Migrationen gezeigt. Und andererseits einmal mehr unsere Arbeitsweise bewährt, Umstellungen jeweils vorab zu testen und dann script-basiert wiederholbar zu machen.

Domain- und DNS-Portfolio

Parallel dazu kümmerte sich Andri um die Übernahme des Domain- und DNS-Portfolios der Webagentur. Insgesamt galt es, rund 500 Domain-Namen und DNS-Zonen möglichst so zu migrieren, dass davon niemand etwas mitbekommt. Den administrativen Transfer der Domainnamen vom bisherigen Registrar zu Ops One konnten Mitarbeitende der Webagentur nach der Bereitstellung des Cockpit-Zugriffs zum grössten Teil selbst erledigen.

Parallel dazu wurden die nötigen Zugriffe für Ops One auf die bestehende Infrastruktur eingerichtet. Darüber konnte dann die Übernahme der DNS-Zonen vorbereitet werden: Auch diese wurden script-basiert auf dem bisherigen Server exportiert und bei Ops One wieder importiert. Und anschliessend vollautomatisiert, Record für Record abgeglichen, um sicherzustellen, dass alte und neue Nameserver auch definitiv die gleichen Antworten ausliefern.

Deaktivierung DNSSEC für die Migration

Sämtliche .ch-Domains auf den Nameservern der Webagentur waren vor der Migration mit DNSSEC geschützt. Für die Migration prüften wir verschiedene Möglichkeiten. Durch den Vollzugriff auf die bisherigen Nameserver hätten wir die jeweiligen DNSSEC Keys auch mitmigrieren können, sahen darin aber nicht nur Vorteile. Wir entschieden uns in Absprache mit der Webagentur dafür, kurz vor der Migration mittels CDS 0 0 0 0​ (siehe RFC 8078 Abschnitt 4) der Registry zu signalisieren, dass DNSSEC deaktiviert werden soll. Die Registry hat daraufhin für alle so signalisierten Domains DNSSEC deaktiviert, und wir konnten dies einen Tag vor der Umstellung überprüfen. Die Umstellung lief dann an einem Abend problemlos durch und wir konnten die IP-Adressen der Nameserver-Hostnamen umstellen auf die Ops One DNS-Server. Dadurch waren in den einzelnen DNS-Zonen keine Änderungen (neue Nameserver) nötig, da die bisherigen Nameserver-Hostnamen weiterverwendet wurden – sprich, wie auf unserer Website beschrieben, im Whitelabel-Betrieb weitergeführt wurden.

Nach der Umstellung merkten wir, dass zwei Domains nicht mehr auflösbar waren. Es stellte sich heraus, dass diese zwei Domains bei einem externen Registrar registriert sind – kein Einzelfall und eigentlich auch irrelevant für diese Art der Umstellung. Dieser eine Registrar hatte aber über einen automatischen Prozess selbständig in der Nacht vor unserer Umstellung DNSSEC wieder aktiviert. Dieser Automatismus war für uns nicht vorhersehbar. Es brauchte zwei Anläufe und ein paar deutliche Worte, bis der Registrar eingelenkt und den Fehler korrigiert hat.

Nach der Umstellung der DNS-Zonen zu Ops One wurde DNSSEC für alle .ch-Domains selbstverständlich wieder aktiviert.

Fast nebenbei konnten zur weiteren Standardisierung auch noch mehrere bestehende Matomo-Installationen und eine Nextcloud-Installation durch Markus migriert werden. Diese betreiben wir fortan als Managed Applications, was den Aufwand für die laufende Pflege und Updates deutlich vereinfacht.