Eine Migration ist ein Projekt, kein Ticket.
Die stark besuchte Plattform eines Verlags, für Skalierung neu aufgebaut, unter Last getestet und auf unser Bare Metal umgezogen. Die für den Kunden sichtbare Auswirkung war ein Fenster von etwa fünf Minuten innerhalb eines zweistündigen Einsatzes.
In diesem Artikel 4 Abschnitte
- Die Gruppe stark besuchter Websites eines großen Verlags musste das Rechenzentrum wechseln und auf unser Bare Metal ziehen, auf dem Weg für Skalierung neu aufgebaut. Traffic bei Eilmeldungen ist ihr Geschäft, und jeder Leser würde einen schlechten Cutover sehen.
- Wir haben zuerst die Plattform entworfen: einen zweistufigen Edge-Cache auf All-Flash-SAN, einen Load Balancer, abgestimmt auf sehr hohe Verbindungszahlen, eine Datenbankschicht mit Read/Write-Trennung und eine Object-Cache-Schicht.
- Dann haben wir sie mit einem Lasttest in voller Größe bewiesen, bevor ein einziger echter Leser bewegt wurde.
- Der Cutover war ein zweistündiger Einsatz mit einem für den Kunden sichtbaren DNS-Fenster von etwa fünf Minuten, jede Phase mit einem Rollback-Pfad.
Es handelt sich um Nachrichten- und Lifestyle-Websites, bei denen die Traffic-Spitze das Geschäft ist. Eine Migration, die sie zum Stillstand bringt oder langsamer wieder hochfährt, ist für jeden Leser mitten in einer Eilmeldung sichtbar. Das war nie ein Ticket. Es war ein Projekt mit einer Cutover-Nacht.
Warum ein Team für die ganze Arbeit
Die Aufgabe brauchte zwei Dinge gleichzeitig, aus einem Team: die Ingenieursleistung, die Caching- und Datenbankschichten neu aufzubauen, und die Infrastruktur in unserem Eigentum (All-Flash-Enterprise-SAN, eine echte Netzwerk-Fabric), auf der sie landen konnte. Wir haben die Ingenieure und das Metall zusammengebracht, und die Cutover-Nacht lag in unserer Verantwortung.
Die Plattform, wie entworfen
Die Entwurfsabsicht waren drei Dinge auf einmal: Neuaufbau für Skalierung bei Cache und Datenbank, Cutover mit einem minimalen, begrenzten Fenster, und jedes Stück des neuen Entwurfs unversehrt durch den Cutover tragen. Das ist daraus geworden.
Zweistufiger Varnish-Edge-Cache
HAProxy davor
ProxySQL auf jedem Web-Knoten
Percona-XtraDB-Cluster
Valkey + Sentinel
Deterministisch schlägt elegant
Die Datenbank zog per frischem Hot Backup um statt per Live-Replikation mit Aufholen. Das war eine Entwurfsentscheidung mit ausgesprochener Begründung: Ein Backup ist deterministisch, also ist das, was im Backup steckt, das, was das neue Cluster hat, ohne Replikationszustand, den man im ungünstigsten Moment entwirren muss. Der elegantere Weg existiert, und wir haben ihn bewusst abgelehnt. In der Cutover-Nacht wollen Sie den Umzug, dessen Ergebnis Sie bereits kennen.
Um die Daten schnell zu bewegen, wurden sie in zwei Sprüngen übertragen: über das öffentliche Internet auf ein Staging-Relay, dann über das interne LAN mit Line Rate, womit aus einer durch die Verschlüsselung begrenzten Kopie wenige Minuten wurden. Am Ziel wurde das Cluster aus dem Backup neu aufgebaut und Knoten für Knoten neu synchronisiert.
Und ein Dateisystem-Sync trug eine chirurgische Ausschlussliste, damit die Migration die Konfiguration des neuen Zuhauses nicht überschreiben konnte: die Konfiguration des Datenbank-Pointers, das Drop-in des Object-Cache und der zweistufige Cache-Aufbau wurden alle ausdrücklich bewahrt. Das eine Stück Zustand, das ein Datenbank-Restore stillschweigend löscht, die Aktivierung des Cache-Purge-Plugins, war im Voraus kartiert, mit seiner Reaktivierung bereit zum Auslösen. Das bedeutet es, den Cutover zweimal zu planen: einmal vorwärts, und einmal für alles, was unterwegs beißen könnte.
Die Daten, in zwei Sprüngen
Öffentliches Internet auf ein Staging-Relay, dann das interne LAN mit Line Rate. Minuten, nicht Stunden.
Cluster aus dem Hot Backup wiederhergestellt
Knoten für Knoten neu synchronisiert.
Dateisystem-Umzug, abgesichert
Eine Ausschlussliste schützt die neue Architektur vor dem Überschreiben.
DNS schaltet um
Das sichtbare Fenster: etwa fünf Minuten.
Die eine stillschweigend gelöschte Einstellung, reaktiviert
Nach Plan, weil sie im Voraus kartiert war.
“Wir haben nicht Ihre Server umgezogen. Wir haben Ihre Plattform neu gebaut und auf unserer gelandet, in einem Fenster von etwa fünf Minuten, im Voraus geplant.”
Was aus der Beziehung wurde
Die Migration war der Einstieg, nicht das Ende. Die Schwesterseiten folgten demselben Muster, und die betriebliche Disziplin kam als Teil des Aufbaus und nicht als späteres Upselling: häufige Hot Backups der Datenbank und aufbewahrte Dateisystem-Snapshots, abgestimmte Edge-Caches, eine flottenweite Schicht für Performance-Monitoring und Validierung per Lasttest vor dem Start. Die Beziehung pendelte sich ein auf «wir betreiben und entwickeln die Plattform weiter», nicht «wir hosten sie».
Klare Antworten
Können Sie eine stark besuchte Website migrieren, ohne sie abzuschalten?+
Wir planen ein begrenztes Fenster und nennen es im Voraus. In diesem Projekt: etwa fünf Minuten für den Kunden sichtbare DNS-Propagierung innerhalb eines zweistündigen Einsatzes.
Backup-Restore oder Replikation für eine Datenbankmigration?+
Beides ist legitim. Wir haben hier ein frisches Hot Backup gewählt, weil es deterministisch ist: Was im Backup steckt, ist das, was das neue Cluster hat, ohne Replikationszustand, den man mitten im Cutover entwirren muss. Der elegante Weg ist nicht immer der sichere.
Was sollte ein Rollback-Plan für eine Migration enthalten?+
Einen Rollback-Pfad in jeder Phase und einen dokumentierten Weg zurück zum Ursprung, bis die neue Plattform Vertrauen verdient hat.
Bauen Sie während einer Migration neu auf oder ziehen Sie nur um?+
Wenn der Umzug ein Projekt wert ist, ist er in der Regel auch den Neuaufbau wert. Diese Plattform bekam auf dem Weg einen zweistufigen Edge-Cache, eine Datenbankschicht mit Read/Write-Trennung und eine Object-Cache-Schicht. Lift-and-Shift ist manchmal richtig, aber es ist eine Entscheidung, kein Standard.
Planen Sie einen Umzug? Bringen Sie uns die Plattform, nicht ein Ticket.
Entwurf, Lasttest, Cutover-Playbook, Rollback-Seile. Wir nennen Ihnen das ehrliche Fenster vor der Nacht, und wir halten das Netz.
Mit einem Ingenieur sprechenSie haben das Ende erreicht.
Setzen Sie das Gelesene um
Was betreiben Sie?
Erzählen Sie uns von Workload, Traffic und Anforderungen an die Wiederherstellung. Beginnen Sie mit dem Server-Konfigurator oder besprechen Sie die Details mit einem Ingenieur.
Geschrieben von den Ingenieuren, die die beschriebene Infrastruktur bauen und betreiben.Mit einem Ingenieur sprechen