Teculiar

Zero-Downtime DNS-Cutover: Ein Playbook für Live-Migrationen

Erfahren Sie, wie Sie Live-Websites ohne Ausfallzeit migrieren, indem Sie DNS-TTL vorab senken, Split-Horizon-Checks durchführen und sofortige Rollback-Trigger einrichten. Ein praktisches Playbook für Hosting-Reseller.

reseller-hostinghosting-automationmigrationdnsengineering

Sie müssen eine Live-Website auf einen neuen Server umziehen, ohne dass Ihre Besucher es bemerken. Ein einziger Fehler beim DNS-Cutover kann zu stundenlanger Ausfallzeit, Umsatzverlusten und verärgerten Kunden führen. Dieses Playbook zeigt Ihnen, wie Sie eine Migration ohne Ausfallzeit planen und durchführen, indem Sie TTL vorab senken, Split-Horizon-Checks durchführen und sofortige Rollback-Trigger einrichten.

Warum ist DNS-TTL für Migrationen ohne Ausfallzeit wichtig?

DNS-TTL (Time To Live) ist die Anzahl der Sekunden, die Resolver einen DNS-Eintrag zwischenspeichern. Wenn Ihre TTL 86400 (24 Stunden) beträgt, dauert es bis zu einem Tag, bis eine Änderung weltweit propagiert wird. Das ist zu langsam für einen Live-Cutover. Indem Sie die TTL vorab auf einen niedrigen Wert senken, stellen Sie sicher, dass die meisten Resolver die neue IP innerhalb von Minuten übernehmen, wenn Sie den Eintrag ändern. Dies ist die Grundlage einer Migration ohne Ausfallzeit.

Beginnen Sie damit, die TTL für die A- und AAAA-Einträge der Domain, die Sie umziehen möchten, zu senken. Tun Sie dies mindestens zwei Mal die aktuelle TTL vor der Migration. Wenn Ihre TTL beispielsweise 3600 (1 Stunde) beträgt, senken Sie sie mindestens 2 Stunden vor dem Cutover auf 300 (5 Minuten). Dies gibt den Resolvern Zeit, die alte TTL ablaufen zu lassen und die neue zu verwenden.

Wie man die TTL senkt, ohne Probleme zu verursachen

  • Melden Sie sich bei Ihrem DNS-Anbieter an und bearbeiten Sie die TTL für die relevanten Einträge.
  • Setzen Sie die TTL auf 300 Sekunden (5 Minuten) oder sogar 60 Sekunden, wenn Ihr Anbieter dies zulässt.
  • Warten Sie, bis die alte TTL abgelaufen ist. Sie können die Propagation mit Online-Tools oder dig-Befehlen überprüfen.
  • Ändern Sie noch nicht die IP-Adresse. Senken Sie nur die TTL.

Sobald die TTL niedrig ist, können Sie mit den Migrationsschritten fortfahren.

Wie bereitet man den neuen Server für eine Live-Migration vor?

Bevor Sie DNS anfassen, müssen Sie den neuen Server vollständig konfiguriert und getestet haben. Das bedeutet, die Website-Dateien, Datenbanken, E-Mail-Konten und alle anderen Dienste zu replizieren. Verwenden Sie eine Staging-Umgebung, die die Produktionsumgebung so genau wie möglich nachbildet.

Wenn Sie eine Hosting-Automatisierungsplattform wie Teculiar verwenden, können Sie einen neuen Server bereitstellen und die Website Ihres Kunden mit derselben Konfiguration bereitstellen. Teculiar ist eine Plattform, die Hosting-Reseller nutzen, um Hosting-, Domain- und VPS-Dienste zu erstellen, zu verkaufen und zu automatisieren. Sie können eine Staging-Kopie erstellen und gründlich testen.

Wichtige Schritte für das Staging:

  • Kopieren Sie alle Website-Dateien vom alten auf den neuen Server.
  • Exportieren und importieren Sie Datenbanken und stellen Sie die Datenintegrität sicher.
  • Richten Sie E-Mail-Konten ein und testen Sie das Senden/Empfangen.
  • Konfigurieren Sie SSL-Zertifikate auf dem neuen Server.
  • Testen Sie die Website mithilfe eines Hosts-Datei-Eintrags oder einer temporären URL, um DNS-Änderungen zu vermeiden.

Verwenden Sie einen Split-Horizon-DNS-Check, um zu überprüfen, ob der neue Server für verschiedene Regionen korrekt antwortet. Split-Horizon-DNS bedeutet, dass interne und externe Ansichten von DNS unterschiedlich sein können. Sie können dies simulieren, indem Sie die IP des neuen Servers direkt von mehreren Standorten aus abfragen.

Was ist ein Split-Horizon-Check und warum ist er wichtig?

Ein Split-Horizon-Check stellt sicher, dass der neue Server von verschiedenen Netzwerkperspektiven aus erreichbar ist und den richtigen Inhalt bereitstellt. Wenn sich Ihr neuer Server beispielsweise hinter einer Firewall oder einem Load Balancer befindet, können interne und externe DNS unterschiedlich auflösen. Sie müssen bestätigen, dass sowohl interne als auch externe Clients den neuen Server nach dem Cutover erreichen.

Führen Sie diese Checks durch:

  • Verwenden Sie dig oder nslookup gegen öffentliche Resolver (8.8.8.8, 1.1.1.1), um zu sehen, was die Welt sieht.
  • Prüfen Sie von verschiedenen geografischen Standorten aus mit Online-Tools.
  • Wenn Sie internes DNS haben, stellen Sie sicher, dass es ebenfalls auf den neuen Server zeigt.
  • Überprüfen Sie, ob der neue Server auf HTTP/HTTPS-Anfragen mit dem richtigen Inhalt antwortet.

Wie führt man den DNS-Cutover mit sofortigen Rollback-Triggern durch

Jetzt kommt der Moment der Wahrheit: Ändern des DNS-Eintrags, um auf den neuen Server zu zeigen. Aber Sie müssen einen Rollback-Plan bereithalten, falls etwas schiefgeht. Sofortige Rollback-Trigger sind Bedingungen, die bei Erfüllung automatisch oder manuell die DNS-Änderung auf den alten Server zurücksetzen.

Definieren Sie Ihre Rollback-Trigger, bevor Sie beginnen. Häufige Trigger sind:

  • HTTP 5xx-Fehler überschreiten einen Schwellenwert (z. B. 1 % der Anfragen).
  • Die Antwortzeit der Website erhöht sich erheblich.
  • Datenbankverbindungsfehler treten auf.
  • SSL-Zertifikatfehler treten auf.
  • E-Mail-Zustellungsfehler werden festgestellt.

Richten Sie Monitoring ein, um diese Metriken in Echtzeit zu überwachen. Tools wie UptimeRobot, Pingdom oder eigene Skripte können Sie alarmieren. Wenn ein Trigger ausgelöst wird, setzen Sie den DNS-Eintrag sofort auf die alte IP zurück. Da Sie die TTL gesenkt haben, wird der Rollback schnell propagiert.

Schritt-für-Schritt-Cutover-Prozess

  1. Stellen Sie sicher, dass der neue Server vollständig mit den neuesten Daten synchronisiert ist. Möglicherweise müssen Sie die Website kurz in den Wartungsmodus versetzen, um zu verhindern, dass neue Daten auf den alten Server geschrieben werden.
  2. Ändern Sie den DNS-A-Eintrag auf die IP des neuen Servers. Wenn Sie mehrere A-Einträge haben, aktualisieren Sie alle.
  3. Überwachen Sie den Datenverkehr und die Fehlerraten in den nächsten 30–60 Minuten genau.
  4. Wenn alles gut ist, behalten Sie den neuen Server als primären. Wenn nicht, führen Sie einen Rollback durch.
  5. Nach einem erfolgreichen Cutover können Sie die TTL schrittweise wieder auf einen normalen Wert erhöhen (z. B. 3600 oder 86400).

Denken Sie daran, dass DNS-Änderungen nicht überall sofort wirksam werden. Einige Resolver speichern den alten Eintrag möglicherweise noch bis zum Ablauf der TTL zwischen. Deshalb ist das vorherige Senken der TTL entscheidend.

Was nach einem erfolgreichen Cutover zu tun ist

Sobald der neue Server live und stabil ist, können Sie den alten Server außer Betrieb nehmen. Aber überstürzen Sie nichts: Lassen Sie ihn noch ein paar Tage als Fallback laufen. Überwachen Sie auf Probleme, die durch restliches DNS-Caching auftreten könnten.

Aktualisieren Sie Ihre Dokumentation und informieren Sie Ihren Kunden über die erfolgreiche Migration. Wenn Sie eine Plattform wie Teculiar verwendet haben, können Sie zukünftige Migrationen automatisieren und sogar als Service für Ihre Kunden anbieten.

Was als Nächstes zu tun ist

  • Überprüfen Sie Ihre aktuellen DNS-TTL-Einstellungen und planen Sie, sie vor Ihrer nächsten Migration zu senken.
  • Richten Sie Monitoring ein und definieren Sie Rollback-Trigger für Ihre kritischen Websites.
  • Testen Sie Ihren Migrationsprozess in einer Staging-Umgebung, um sicherzustellen, dass er reibungslos funktioniert.
  • Erwägen Sie die Verwendung einer Hosting-Automatisierungsplattform, um zukünftige Migrationen zu optimieren. Prüfen Sie unsere Preise für Optionen.

Beginnen Sie mit einer Überprüfung Ihrer DNS und bereiten Sie eine Checkliste für Ihre nächste Live-Migration vor.