Umzugsstrategie so ok? (Server A zu B, inkl. Plesk zu ISPConfig)

[honse33]

Hallo,

ich möchte von einem Server auf einen anderen umziehen. Gründe liegen in der verwendeten Hardware. Für diesen Umzug strebe ich auch noch das Ziel an, von Plesk zu ISPConfig zu wechseln.

Den Umzug selbst habe ich mir so vorgestellt:
- zweiten Server parallel mieten, OS aufsetzen, ISPConfig installieren
- Domains und Mailkonten bei ISPConfig einrichten
- Daten von Server A auf Server B kopieren

Die Projekte, die eine Datenbank benötigen, stelle ich so ein, dass diese bereits auf den neuen Datenbankserver zugreifen.

Wie gehe ich nun weiter vor, um einen möglichst kleinen Ausfall zu erreichen?
Speziell die Stichpunkte Mailserver und DNS-Settings (Nameserver vom Serveranbieter) machen mir Sorgen.

 

[Milchbroetchen]

Hi,
es gibt ein Umzugs Tool für ISPConfig, wende dich mal ans Howtoforge Forum und dort an Till er ist der Entwickler und Betreiber von ISPConfig und Howtoforge. Aber mit ISPConfig hast du meiner Meinung nach eine sehr sehr gute Wahl getroffen.

 

[nexus]

Wie gehe ich nun weiter vor, um einen möglichst kleinen Ausfall zu erreichen?
Speziell die Stichpunkte Mailserver und DNS-Settings (Nameserver vom Serveranbieter) machen mir Sorgen.

Grob skizziert:
- neuen Server komplett einrichten
- alten Server vom Netz nehmen (hier beginnt die Downtime)
- Backup der Datenbanken und eventuell anderer Nutzerdaten auf dem alten Server und Übertragen auf den neuen Server
- alten Webserver zum Proxy umkonfigurieren, der alles auf den neuen Webserver weiterleitet
- alten Mailserver als Backup-MX umkonfigurieren
- DNS-Zuweisungen (in der Regel A-, AAAA- und MX-Record) auf den neuen Server ausrichten, den MX vom alten Mailserver belassen, aber in der Prio herabsetzen
- beide Server ans Netz bringen (hier endet die Downtime)
Ist aber nur eine grobe Übersicht, die Feinheiten mußt du entsprechend deiner Konfiguration noch anpassen.

Wenn du alles gut vorbereitest, sollte die Downtime im Minutenbereich liegen.

Alle Anfragen an den Webserver werden nun entweder über den Proxy an den neuen Server geleitet oder (soweit sich die DNS-Änderungen schon rumgesprochen haben) direkt auf das neue Ziel gerichtet.
Ähnlich beim Mailserver...Wenn der alte Server angesprochen wird, speichert er die Mails und reicht sie wegen der Backup-Funktionalität an den neuen Server weiter.
In der Regel sollten sich die DNS-Änderungen nach 24-48 Stunden weltweit rumgesprochen haben. In den Logfiles des alten Servers siehst du dann, daß irgendwann keine Anfragen mehr dort ankommen. Dann kann der alte Server vom Netz genommen werden.

Nachtrag:
Wenn du ganz sichergehen willst, daß alles reibungslos klappt, dann solltest du das Ganze lokal auf deinem PC mit zwei virtuellen Maschinen durchtesten. So kannst du mögliche Fehlerquellen minimieren und bekommst schon vorab ein Gefühl dafür, was genau auf dich zukommt.

 

[dataforest]

Die Frage ist bei sowas aus meiner Sicht immer: Wie kritisch sind die gehosteten Webseiten / Dienste? Wenn man die TTL vorab auf 60 Sekunden stellt, kann man sich die Proxy-Geschichte aus meiner Sicht ehrlich gesagt klemmen. Wir administrieren z.B. einen (Pseudo-)Webcluster, der für die Content-Auslieferung ausschließlich über DNS-Balancing fährt, und wenn planmäßig ein Server aus dem System genommen wird, sind 95% des Traffics fünf Minuten nach DNS-Änderung auch wirklich weg. Übrig bleiben meist irgendwelche Bots aus China, Russland etc.

Sofern man doch noch ein paar Minuten mehr Uptime rausholen möchte, kann ein Proxy natürlich sinnvoll sein. Ich würde aber schon rein aus Bequemlichkeit - und um mich darum während des Umzugs selbst nicht kümmern zu müssen - hierfür einen eigenen (v)Server dahernehmen, den man schon vorher Proxy spielen lässt. So kannst du entspannt umziehen und musst danach nur noch deine Proxy-Config ändern. Das alte System kann dann sofort abgeschaltet werden, womit du etwaige Inkonsistenzen effektiv vermeiden kannst.

Leistung braucht man für sowas ja nicht.

 

[Nilpferd]

Grob skizziert:
- neuen Server komplett einrichten
- alten Server vom Netz nehmen (hier beginnt die Downtime)
- Backup der Datenbanken und eventuell anderer Nutzerdaten auf dem alten Server und Übertragen auf den neuen Server

Daten würde ich im Vorfeld schonmal mit rsync auf die neue Kiste schieben - also vor der eigentlichen downtime, dann dauert die Synchronisierung der Daten nicht mehr so lange und die Downtime wird um einiges verkürzt.

 

[nexus]

Die Frage ist bei sowas aus meiner Sicht immer: Wie kritisch sind die gehosteten Webseiten / Dienste? Wenn man die TTL vorab auf 60 Sekunden stellt, kann man sich die Proxy-Geschichte aus meiner Sicht ehrlich gesagt klemmen. Wir administrieren z.B. einen (Pseudo-)Webcluster, der für die Content-Auslieferung ausschließlich über DNS-Balancing fährt, und wenn planmäßig ein Server aus dem System genommen wird, sind 95% des Traffics fünf Minuten nach DNS-Änderung auch wirklich weg. Übrig bleiben meist irgendwelche Bots aus China, Russland etc.

Naja...es gibt leider immer noch genug (auch deutsche) Internetnutzer, die bei standardmäßiger Verwendung der Nameserver ihres ISP teilweise über viele Stunden nach einer DNS-Änderung noch veraltete DNS-Informationen geliefert bekommen. Da nützt auch eine kurze TTL bei der DNS-Änderung nichts.
Insoweit ist die Proxy-Lösung die robustere Variante. Letztlich ist es sicher auch eine Frage von Aufwand und Nutzen...

Ich würde aber schon rein aus Bequemlichkeit - und um mich darum während des Umzugs selbst nicht kümmern zu müssen - hierfür einen eigenen (v)Server dahernehmen, den man schon vorher Proxy spielen lässt.

Wenn man den alten Webserver zum Proxy ummodelt, dann braucht man doch nur eine Konfig-Datei ändern oder noch besser gegen eine vorbereitete Datei austauschen. Im Vergleich dazu würde ich das Aufsetzen eines zusätzlichen Proxy-Servers aber für wesentlich aufwändiger halten.

Daten würde ich im Vorfeld schonmal mit rsync auf die neue Kiste schieben - also vor der eigentlichen downtime, dann dauert die Synchronisierung der Daten nicht mehr so lange und die Downtime wird um einiges verkürzt.

Datenbankinhalte, Emails u.ä. kannst du erst nach Beginn der Downtime übertragen, sonst würdest du dir eine Inkonsistenz zwischen dem Sync und dem Beginn der Downtime schaffen.
Alle anderen Daten (Webseiten, Scripte o.ä.), die sich bis zum Beginn der Downtime nicht ändern werden, können (und sollten) natürlich schon vorher auf dem neuen System implementiert sein.

 

[Nilpferd]

Datenbankinhalte, Emails u.ä. kannst du erst nach Beginn der Downtime übertragen, sonst würdest du dir eine Inkonsistenz zwischen dem Sync und dem Beginn der Downtime schaffen.

Das hast du falsch verstanden. Im Endeffekt kann man nicht wissen ob sich nochmal was verändert hat. Darum macht man während der Server noch in Betrieb ist einen sync. Alles was sich jetzt noch bis zum Start der Downtime ändert wird dann nochmal mit einem sync, welcher in der Downtime statt findet aktualisiert. Damit ist auch die Inkonsistenz weg die zwischenzeitlich auftreten kann. Der Erste sync ist genau dafür da alles zu übertragen was sich nicht mehr ändert, was sich dann noch geändert hat folgt nochmal im zweiten sync der dann hoffentlich viel kürzer dauert.

 

[nexus]

Der Erste sync ist genau dafür da alles zu übertragen was sich nicht mehr ändert, was sich dann noch geändert hat folgt nochmal im zweiten sync der dann hoffentlich viel kürzer dauert.

Auf diesem Weg erreichst du die größte Minimierung der Backupzeit, da hast du natürlich recht

Nachtrag:
Ich hab mal lokal ein wenig rumgespielt und hab festgestellt, daß die sync-Variante einige Vorteile bietet.
Tatsächlich spart man gerade bei größeren Datenmengen einiges an Zeit gegenüber einem Fullbackup.
Außerdem hat man ja als guter Admin eine funktionierende Backupstrategie, die man hierfür direkt nutzen kann und nicht extra eine 'Umzugsvariante' basteln muß
Danke für den Denkanstoß, ich werde das bei zukünftigen Umzügen berücksichtigen.

 

[honse33]

Vielen Dank für die zahlreichen Antworten!

Der Ansatz, die Daten aus dem Backup zu ziehen und den Rest per rsync zu übertragen, finde ich schon mal sehr gut. Bezüglich der Downtime-Sache mache ich mir noch mal ein paar Gedanken.

Sofern keiner mehr was schreiben möchte, wäre der Thread für mich erstmal als erledigt angesehen.

 

[Nilpferd]

Ich denke wenn du das mit der TTL und dem ersten sync + Einrichtung und Konfiguration der Dienste im Vorfeld gut vorbereitest, wird das nicht so problematisch.

Bezüglich dem Umzung von Plesk auf ISPConfig würde ich mir noch etwas sorgen machen, ob sich das alles so einfach migrieren lässt. Aber das sind ja alles Dinge die man im Vorfeld erarbeiten muss und haben dann nichts mehr mit dem eigentlichen Umzug zu tun.