Eine Website ohne Downtime migrieren
Eine Website-Migration, neuer Host, neuer Server, manchmal ein komplett neuer Stack, wird oft als riskant dargestellt, weil die Annahme ist, dass es einen Moment gibt, in dem die alte Seite weg ist und die neue noch nicht bereit. Das muss nicht sein. Die eigentliche Technik für eine Zero-Downtime-Migration ist nicht exotisch, sie ist Reihenfolge: zuerst den neuen Server vollständig zum Laufen bringen, ihn gründlich testen, während der alte noch live ist und echten Traffic bedient, und erst dann den Wechsel vollziehen, mit einer DNS-TTL, die schon lange vor all dem gesenkt wurde.
Tage vorher: die TTL senken
DNS-Records haben eine TTL (Time to Live), die Resolvern sagt, wie lange sie eine Antwort cachen sollen. Hat der A-Record einer Domain eine TTL von 24 Stunden und man ändert sie, treffen manche Besucher bis zu einen Tag lang weiter auf den alten Server. Die TTL ein paar Tage vor der Migration auf etwas Kurzes zu senken, etwa 300 Sekunden, gibt der alten, langen TTL Zeit, überall zuerst abzulaufen:
example.com. 300 IN A 203.0.113.10
Wenn der eigentliche Wechsel stattfindet, ist die gecachte Antwort jedes Resolvers höchstens fünf Minuten alt, was den Unterschied macht zwischen "der Wechsel wirkt in fünf Minuten" und "der Wechsel wirkt irgendwann im nächsten Tag, abhängig vom Besucher".
Den neuen Server vollständig aufbauen und testen, bevor DNS angefasst wird
Das ist der Schritt, der das Risiko tatsächlich eliminiert, und gleichzeitig der, der am häufigsten überstürzt wird. Der neue Server sollte die Anwendung deployed haben, die Datenbank aus einem aktuellen Backup wiederhergestellt oder, idealerweise, bis zum Cutover per Replikation synchron gehalten haben, und vollständig testbar sein, ohne dass DNS schon darauf zeigt. Die Art, einen Server zu testen, der noch nicht live ist, ist die DNS-Auflösung lokal zu überschreiben:
# /etc/hosts auf der eigenen Maschine
203.0.113.10 example.com
Damit landet man, wenn man example.com im Browser aufruft, auf dem neuen Server, während alle anderen weiterhin den alten erreichen. Genau hier findet man die Probleme, eine fehlende Umgebungsvariable, ein File-Upload-Pfad, der nicht migriert wurde, ein Service, der neu gestartet werden muss, ohne Druck und ohne dass irgendwelche Besucher betroffen sind. Ist etwas defekt, beheben und erneut testen. Es gibt keine Eile, weil noch nichts live ist.
Die Datenbank: der Teil, der wirklich Sorgfalt braucht
Statische Dateien und Code lassen sich vorab kopieren und kurz vor dem Cutover mit etwas wie rsync nochmal synchronisieren. Die Datenbank ist heikler, weil sie sich bis zum Moment des Cutovers auf dem alten Server ständig ändert. Der unkomplizierte Ansatz: ein letztes Backup ziehen und es genau zum Cutover-Zeitpunkt auf dem neuen Server wiederherstellen, wobei man ein kurzes Zeitfenster (die Zeit für Dump, Transfer und Restore) akzeptiert, in dem die Seite idealerweise read-only sein oder kurz speziell für Schreibvorgänge nicht verfügbar sein sollte.
# Auf dem alten Server, direkt 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 Seiten, bei denen selbst ein paar Minuten read-only nicht akzeptabel sind, schließt Datenbankreplikation (den neuen Server vorab als Replica des alten einrichten und ihn beim Cutover befördern) diese Lücke weiter, aber für die meisten kleinen bis mittelgroßen Seiten sind ein paar Minuten "die Seite funktioniert, aber neue Kommentare/Bestellungen pausieren" während eines geplanten Zeitfensters mit wenig Traffic ein vernünftiger Tradeoff gegenüber dem Aufwand, Replikation für eine einmalige Migration aufzusetzen.
Der eigentliche Cutover
Wenn der neue Server vollständig über /etc/hosts getestet ist, die TTL schon niedrig ist und ein letzter Datenbank-Sync gelaufen ist, ist die DNS-Änderung selbst fast eine Enttäuschung, weil so wenig dabei passiert:
example.com. 300 IN A 198.51.100.20
Innerhalb des TTL-Fensters verschiebt sich der Traffic auf den neuen Server. Der alte Server bleibt danach noch ein oder zwei Tage laufen und unberührt, sowohl als Fallback, falls unter echtem Traffic etwas Unerwartetes auftaucht, als auch damit Besucher, die ihn über eine veraltete gecachte DNS-Antwort noch erreichen, nicht auf einen toten Server treffen.
Warum das ohne spezielle Tools funktioniert
Nichts davon braucht migrationsspezifische Software, denn die eigentliche Quelle von "Downtime" bei einer überstürzten Migration ist, das Testen nach dem Wechsel zu machen, Probleme zu finden, während der neue Server schon der einzige live ist. Diese Reihenfolge umzudrehen, erst vollständig fertig und getestet, DNS-Änderung zuletzt, und eine TTL, die schon niedrig war, als es darauf ankam, macht den Cutover selbst fast zum Nicht-Ereignis. Die Vorbereitung ist die Migration; die DNS-Änderung ist nur der letzte, kleinste Schritt.