Eine Website ohne Downtime migrieren

Die Migration einer Website auf einen neuen Host oder Server wird oft als hochriskante Operation dargestellt. Viele gehen davon aus, dass es dabei unvermeidlich diese Lücke gibt, in der die alte Seite offline geht und die neue noch nicht ganz fertig ist.

Das muss nicht so sein. Die eigentliche Technik für eine Zero-Downtime-Migration ist alles andere als exotisch. Es geht einzig und allein um die richtige Reihenfolge: Zuerst den neuen Server komplett funktionsfähig machen, ihn gründlich prüfen, während der alte Server noch den echten Traffic bedient, und erst dann umschalten – und zwar mit einer DNS-TTL, die schon Tage vorher massiv gesenkt wurde.

Tage vorher: Die TTL senken

DNS-Records haben eine TTL (Time to Live), die lokalen Resolvern exakt vorgibt, wie lange sie eine Antwort cachen dürfen. Wenn der A-Record einer Domain eine TTL von 24 Stunden hat und Sie die IP ändern, werden einige Besucher stur bis zu einen ganzen Tag lang weiter auf den alten Server zugreifen.

Senkt man die TTL ein paar Tage vor der Migration auf einen extrem kurzen Wert – etwa 300 Sekunden –, gibt das der alten, hartnäckigen TTL genug Zeit, überall natürlich abzulaufen:

example.com.  300  IN  A  203.0.113.10

Wenn dann der eigentliche Switch ansteht, ist die gecachte Antwort in jedem Resolver maximal fünf Minuten alt. Das ist exakt der Unterschied zwischen "die Änderung greift in fünf Minuten" und "die Änderung greift irgendwann morgen, je nach Besucher".

Den neuen Server komplett aufbauen und testen, bevor das DNS angefasst wird

Das ist der Schritt, der das Risiko tatsächlich eliminiert – und ironischerweise der Schritt, der am häufigsten überstürzt wird. Auf dem neuen Server sollte die Applikation fertig deployt und die Datenbank aus einem aktuellen Backup wiederhergestellt sein. Er muss zu 100 % testbar sein – und das alles, ohne dass das öffentliche DNS jemals auf ihn zeigt.

Der saubere Weg, einen noch nicht öffentlichen Server zu testen, führt über das lokale Überschreiben der DNS-Auflösung auf der eigenen Maschine:

# /etc/hosts auf dem eigenen Rechner
203.0.113.10  example.com

Mit dieser einen Zeile landet man beim Aufruf von example.com im Browser auf dem neuen Server, während der Rest der Welt weiterhin den alten aufruft. Genau hier möchte man die Probleme finden: eine fehlende Umgebungsvariable (Environment Variable), ein nicht migrierter Datei-Upload-Pfad oder ein Hintergrunddienst, der neu gestartet werden muss. Man findet sie, während null Zeitdruck herrscht und kein einziger Besucher davon betroffen ist. Ist etwas kaputt, repariert man es und testet noch einmal. Es gibt keinen Stress, denn es ist ja noch nichts live.

Die Datenbank: Der Teil, der echte Aufmerksamkeit erfordert

Statische Dateien und Applikations-Code können problemlos im Vorfeld kopiert und kurz vor dem Cutover mit einem simplen rsync neu synchronisiert werden.

Die Datenbank ist heikler, weil sie sich auf dem alten Server bis auf die exakte Sekunde des Cutovers ständig weiter verändert. Der direkteste Ansatz: Man zieht ein finales Backup und spielt es exakt zum Zeitpunkt des Cutovers auf dem neuen Server ein. Dafür nimmt man ein sehr kurzes Zeitfenster in Kauf (die Zeit, die Dump, Transfer und Restore eben brauchen), in dem die Seite idealerweise in den Wartungsmodus gezwungen oder zumindest für Schreibvorgänge auf Read-Only gesetzt wird.

# Auf dem alten Server, kurz vor dem Cutover
mysqldump --single-transaction myapp_db | gzip > final-dump.sql.gz
scp final-dump.sql.gz new-server:/tmp/
# Auf dem neuen Server
gunzip -c /tmp/final-dump.sql.gz | mysql myapp_db

Für riesige Seiten, bei denen auch nur wenige Minuten Read-Only-Status absolut inakzeptabel sind, schließt eine Datenbank-Replikation (der neue Server wird vorab als Echtzeit-Replica des alten konfiguriert und beim Cutover zum Master befördert) diese Lücke. Aber für die allermeisten kleinen bis mittleren Sites sind ein paar Minuten "Die Seite lädt, aber neue Kommentare und Bestellungen sind pausiert" während eines geplanten, verkehrsarmen Wartungsfensters ein unglaublich vernünftiger Kompromiss im Vergleich zur massiven Komplexität, die das Aufsetzen einer Replikation für einen einmaligen Umzug mit sich bringt.

Der eigentliche Cutover

Wenn der neue Server via /etc/hosts auf Herz und Nieren getestet wurde, die TTL bereits auf 300 Sekunden gesenkt ist und ein finaler Datenbank-Sync stattgefunden hat, ist die eigentliche DNS-Änderung fast schon unspektakulär:

example.com.  300  IN  A  198.51.100.20

Innerhalb dieses Fünf-Minuten-Zeitfensters verschiebt sich der weltweite Traffic fließend auf den neuen Server.

Der alte Server bleibt danach noch ein oder zwei Tage unangetastet weiterlaufen. Er dient als sofortiges Fallback, falls unter echtem Produktions-Traffic doch noch etwas Unerwartetes auftaucht. Und er stellt sicher, dass vereinzelte Besucher, die durch fehlerhaftes DNS-Caching noch bei ihm landen, keinen toten Server zu sehen bekommen.

Warum das ohne Spezial-Tools funktioniert

Nichts davon erfordert teure, migrationsspezifische Software. Die wahre Ursache für "Downtime" bei einer überstürzten Migration ist das Testen nach dem DNS-Switch – das Finden kritischer Fehler, wenn der neue Server bereits als einziger live ist.

Genau diese Reihenfolge umzukehren – zuerst vollständig fertig und getestet, die DNS-Änderung ganz zum Schluss, mit einer TTL, die rechtzeitig drastisch verkürzt wurde – macht den Cutover selbst zu einem absoluten Non-Event. Die Vorbereitung ist die Migration. Die DNS-Änderung ist lediglich der letzte, winzigste Schritt.