Verschieben vieler Websites auf einen neuen Server - Was ist der schnellste Weg, um ihre DNS-Einträge zu aktualisieren?

Ich plane die Migration einer großen Anzahl von Websites (ca. 100) auf einen neuen Server und bin im Migrationsplanungsprozess.

Eine typische DNS-Zone für jede Website verfügt über zwei A-Einträge, die auf die IP des Webservers verweisen, einen für example.comund einen für die wwwSubdomain.

Wenn wir alle eingerichtet und bereit sind, den neuen Server für die Produktion zu starten, ist das Ändern von 100x2-DNS-Einträgen zeitaufwändig. Daher suche ich nach einer Möglichkeit, dies zu beschleunigen. In einigen Fällen habe ich über das Erstellen eines Bash-Skripts gelesen, das die DNS-Einträge iteriert und eine Suche durch die neue IP durchführt. In anderen Themen habe ich Vorschläge zum Hinzufügen von A-Einträgen mit der neuen IP gelesen, sodass der DNS-Server die Anforderungen auf den nächsten Eintrag verweist, der die neue IP enthält, wenn der aktuelle Server nicht mehr verfügbar ist.

Abgesehen von diesen gibt es ein Szenario, in dem ich die A-Einträge durch einen anderen DNS-Eintragstyp ersetzen könnte, z. B. einen Hostnamen, sodass ich zu gegebener Zeit nur die IP des Hostnamens durch den neuen ändern und alle haben kann Websites zeigen auf den neuen Server? Ich bin mir sicher, dass 'Hostname' nicht der richtige Begriff ist. Ich hoffe, Sie alle haben die Idee.

Der gesuchte Begriff ist CNAME und die Antwort auf Ihre Frage lautet Ja und Nein.

Hier ist zunächst ein Beispiel dafür, wie ein CNAME in einer Zonendatei funktioniert.

example.se  IN SOA  ns1.example.se. hostmaster.example.se. (
            [....]
            )

server1    A       10.1.2.3
www        CNAME   server1

Jetzt müssen Sie nur noch den server1Datensatz aktualisieren , um beide server1und wwwdie neue IP-Adresse zu verschieben.

Der CNAME muss nicht auf eine Adresse innerhalb derselben Domäne verweisen. es könnte auch so aussehen:

example.se  IN SOA  ns1.example.se. hostmaster.example.se. (
            [....]
            )

www         CNAME   server1.example.org.

Wenn Sie nun den A-Datensatz für server1in der Zone aktualisieren example.org, www.example.sefolgt der Datensatz für ohne weitere Konfiguration.

Der schlechte Teil aus Ihrer Sicht ist, dass dies für den Apex-Datensatz nicht funktioniert - das bedeutet die "nackte" Domain. Mit anderen Worten, Sie können www.example.comeinen CNAME erstellen, aber das können Sie nicht example.com. Dies liegt daran, dass Sie bei Verwendung eines CNAME-Datensatzes keine zusätzlichen Datensätze für diesen Eintrag haben können. Dies bedeutet, dass Sie keine Mailserver-Datensätze oder Nameserver-Datensätze haben können. Dies bedeutet, dass die Domäne nicht mehr funktioniert.

Die Best-Practice-Lösung besteht darin, eine Art Konfigurationsverwaltungssoftware wie Puppet, Chef oder Ansible zu verwenden, um die Zonendateien aus einer Vorlage zu generieren. Wenn dies aus irgendeinem Grund für Sie nicht möglich ist, würde ich ein Skript verwenden, um die IP-Adressen in allen Dateien zu ersetzen.

Sie möchten auch den TTL-Wert für die Domäne rechtzeitig vor der Migration reduzieren. (Und vergessen Sie nicht, die Seriennummer der Zonendatei zu aktualisieren - ich habe, und es ist sehr peinlich ...)

Erstens hängt die Antwort davon ab, wie Ihr DNS implementiert ist. Hosten Sie sich selbst mit etwas wie Binden, Ungebundenem oder verschiedenen anderen DNS-Servern? Verwenden Ihre DNS-Server Textdateien zur Konfiguration, verwenden sie eine GUI-Schnittstelle (z. B. Windows-Server), verwenden sie eine Skript-API (z. B. PowerShell) oder verwenden sie eine Webschnittstelle (häufig, wenn Sie DNS ausgelagert haben). Ausgelagertes DNS verfügt manchmal auch über eine REST-API, die Sie verwenden können.

Möglicherweise möchten Sie entweder eine Skript-API verwenden, um die Aktualisierungen durchzuführen, oder eine Textdatei bearbeiten, da beide problemlos automatisiert werden können. Wenn es sich um eine Textdatei handelt, können Sie diese sogar im Voraus vorbereiten und bei der Migration einfach an Ort und Stelle kopieren.

Im Übrigen verwenden viele Leute DevOps-Tools wie Chef, Ansible, Puppet, Salt usw., um diese Art von Änderung in Ihrer Größenordnung vorzunehmen. Offensichtlich handelt es sich hierbei um große Tools, die geplant werden müssen, sodass dies nicht der Fall sein wird von sofortiger Hilfe für dieses spezielle Bedürfnis, aber es kann Ihr Leben auf lange Sicht erleichtern.

Einige andere wichtige Überlegungen:

• Überprüfen Sie Ihre TTL. Ändern Sie etwa einen Tag oder eine Woche vor Ihrer Migration die TTL auf die kürzeste, die Sie durchführen können. Erhöhen Sie die TTL nach Abschluss der Migration.

• Vergessen Sie nicht, die Seriennummer im SOA-Datensatz zu erhöhen! APIs und Webschnittstellen können dies automatisch für Sie tun oder nicht. Wenn Ihr DNS-Server Textdateien verwendet, müssen Sie daran denken, dies zu tun.

• Prüfen Sie je nach Art des Servers, ob Sie den alten und den neuen Server ein wenig nebeneinander ausführen können. Wenn Sie können, müssen Sie möglicherweise nicht alle DNS-Updates gleichzeitig durchführen.

Wenn ich das richtig verstehe, hat der alte Server eine einzige IP-Adresse und der neue auch nur eine.

Sie können also den neuen Server einrichten und darauf den gesamten relevanten http / https / ftp / beliebigen Datenverkehr an die alte IP weiterleiten und dann die DNS-Einträge aktualisieren, um die neue IP anzuzeigen.

Wenn Sie nur eine IP haben, können Sie mit einem einfachen Suchen / Ersetzen alle IPs im DNS gleichzeitig ändern (vergessen Sie nicht, die Seriennummer zu aktualisieren) und warten, bis Ihre aktuelle TTL abgelaufen ist. Sobald die TTL abgelaufen ist, können Sie einfach die Routen auf dem neuen Server entfernen und Ihre anderen Einstellungen anpassen, sodass sie die Sites direkt bedienen, anstatt sie umzuleiten.

Vor dem Entfernen der Routen sollten die Websites offensichtlich an den neuen Speicherort verschoben worden sein. Dies hat den Vorteil, dass Sie sich nicht auf andere DNS-Server verlassen müssen, um deren Einträge rechtzeitig zu aktualisieren. Sie können einfach "abwarten". Um diesen Zeitraum zu verkürzen, können Sie die TTL reduzieren. Beachten Sie jedoch, dass einige DNS-Caches die TTL-Einstellungen ignorieren. Deshalb verlasse ich mich nicht mehr auf TTLs.

Bearbeiten / weitere Erklärung: Zum leichteren Verständnis:

Sie können jetzt auch einfach Ihren neuen Server installieren, alles konfigurieren und alle Ihre Sites auf die neue IP verschieben und dann den gesamten Datenverkehr vom alten Server zum neuen Server leiten.

ZB hat Ihr alter Server die IP 192.0.2.1 Ihr neuer Server hat die IP198.51.100.2

Ihr DNS zeigt auf 192.0.2.1alle Sites (?) Und der Webserver entscheidet, welcher Inhalt unter dem Namen der angeforderten Domain bereitgestellt werden soll, z. B. example.com-> /var/www/sites/example.comund www.example.com-> /var/www/sites/example.com.

Sie drehen also einfach Folgendes:

example.com -> 192.0.2.1

In diese (sobald Sie die Websites auf 198.51.100.2 verschoben haben):

example.com -> 192.0.2.1 -> 198.51.100.2

Ändern Sie dann die DNS-Einträge so, dass sie auf 198.51.100.2 verweisen:

example.com -> 198.51.100.2

Das Problem mit DNS besteht darin, dass das Update niemals sofort erfolgt. Daher zeigt example.com für einige Ihrer Kunden für einen variablen Zeitraum immer noch auf 198.51.100.2 (entweder die von Ihnen festgelegte TTL oder, wenn sie es ignorieren, wer weiß wie lange).

Mein Punkt ist also: Anstatt sich auf DNS zu verlassen, leiten Sie den Datenverkehr auf der IP-Schicht um, damit Sie Ausfallzeiten reduzieren. Ich hoffe das macht es etwas klarer.

Unter Ubuntu können Sie dies mit Weiterleitung und NAT tun (z. B. Weiterleiten von http und https für Ihr altes Ziel 198.51.100.2 an Ihr neues Ziel 198.51.100.2; diese Einstellungen werden auf Ihrem alten Server vorgenommen):

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp --dport 443 -m state --state NEW -j ACCEPT

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 198.51.100.2:80
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 198.51.100.2:443
iptables -t nat -A POSTROUTING -j MASQUERADE

Eine schnelle Lösung (nicht die eleganteste, aber wahrscheinlich funktionierende) wäre, einfach die alte IP durch die neue durch eine einfache Suche zu ersetzen.

Sichern Sie zuerst die Zonendateien.

Dann auf Probleme prüfen:

grep 'ol\.d\.i\.p' *.zone

Überprüfen Sie, ob Zeilen vorhanden sind, bei denen es sich nicht um Datensätze handelt, die Sie ersetzen möchten

Als nächstes ersetzen Sie die IP:

sed -i 's/ol\.d\.i\.p/ne.w.i.p/g' *.zone
grep 'ne\.w\.i\.p' *.zone # check if the new lines look correct

Dies ist nichts, was Sie in einem Skript tun sollten, das jeden Tag ausgeführt wird. Für eine einmalige Migration kann dies jedoch gerade ausreichen, um das Problem zu lösen, ohne mit der Programmierung ausgefeilter Migrationstools zu beginnen.

• Der grepBefehl sucht nur nach Zeilen, die den regulären Ausdruck enthalten (hier: eine wörtliche Übereinstimmung der IP, die maskiert werden .muss, weil sie in Regex eine besondere Bedeutung haben).
• sedwird für zeilenbasierte Operationen an Streams oder Dateien verwendet (mit der -iOption). s/regex/replacement/gErsetzt den regulären Ausdruck (wie im grepBefehl verwendet) durch den Ersatz (die neue IP). /gbedeutet global, wodurch sichergestellt wird, dass die IP mehrmals ersetzt wird, wenn mehrere Übereinstimmungen in einer einzelnen Zeile vorhanden sind.