Freundliche Übernahme

Inhaltsverzeichnis

Wer einen Rootserver durch einen leistungsfähigeren Server ersetzen oder gar komplett den Provider wechseln will, muss sich meist auch mit dem Ändern der IP-Adresse beschäftigen. Und das birgt bei Webservern Komplikationen. Änderungen im DNS sind, abhängig von der „Time To Live“ (TTL) des DNS-Eintrags, erst nach bis zu 24 Stunden bei allen Zugangs-Providern sichtbar. So lange landen Zugriffe zum einen Teil auf der alten, zum anderen auf der neuen IP-Adresse. Während das bei statischen Websites mit etwas Planung zu verschmerzen ist, drohen bei dynamischen Inhalten (etwa mit Kommentarfunktion oder vielen täglichen Änderungen über ein Content Management System) Inkonsistenzen. Mit der richtigen Vorgehensweise und ein paar Hilfsmitteln lässt sich die kritische Übergangsphase deutlich verkürzen und eine nahezu reibungslose Umstellung realisieren.

Den zentralen Bestandteil dieser Vorgehensweise bildet ein transparenter Reverse Proxy auf dem bisherigen Server. Der leitet ab dem Zeitpunkt des Umzugs alle Anfragen an den neuen Server weiter und gibt das Ergebnis an den Client-Browser zurück. Somit arbeitet der alte Server nur noch als Proxy, und die eigentlichen HTTP-Anfragen bearbeitet nur noch der neue Server. Anschließend lässt sich die IP-Adresse im DNS ändern und schließlich der alte Server vom Netz nehmen. Der neue Server muss entsprechend vorbereitet und zum Zeitpunkt der Umstellung auf dem aktuellen Stand sein.

Als konkretes Beispiel dient ein einfacher „LAMP“-Rootserver (Linux, Apache, MySQL, Perl oder PHP) – etwa mit WordPress. Die Schritte sind aber weitgehend auf andere Konstellationen übertragbar.

Vorbereitende Maßnahmen

Zunächst gilt es den neuen Server vorzubereiten. Nach dem Installieren der passenden Softwarepakete gehört dazu das Kopieren aller statischen Dateien und der MySQL-Datenbanken. Für den Dateitransfer bietet sich rsync an, das auf beiden Servern installiert sein muss. Der folgende Befehl – ausgeführt auf dem alten Server – überträgt den Ordner /var/www/ per SSH auf den neuen Server mit der IP-Adresse 192.0.2.1:

rsync -az /var/www/ user@192.0.2.1:/var/www/ 

Die Option -a bewirkt das rekursive Kopieren der Ordner nebst Übernahme aller Eigenschaften und Berechtigungen der Dateien. Es empfiehlt sich also sicherzustellen, dass die relevanten Benutzer (insbesondere der Benutzer, unter dem der Apache httpd läuft) auf beiden Systemen die gleichen UIDs besitzen. Die Option -z schaltet die Kompression zur Übertragung ein.

Zum Übertragen der Datenbanken legt der Zuständige zunächst einen SQL-Dump auf dem alten Server an und kopiert ihn auf den neuen Server:

mysqldump -p --add-drop-database -A > ~/mysql.sql

rsync -z ~/mysql.sql user@192.0.2.1:~/ 

Auf dem künftigen Host folgt zum Importieren:

mysql -p < ~/mysql.sql 

Steht schließlich die gewünschte Apache-Konfiguration in /etc/apache2 auf dem neuen Server, folgt ein Test nach dem Neustart von Apache und MySQL. Ein fester Eintrag „192.0.2.1 www.example.com“ in der hosts-Datei des eigenen Rechners (üblicherweise in /etc/, auf Windows-Systemen in c:\windows\system32\drivers\etc\) gaukelt diesem vor, dass der neue Server bereits im DNS hinterlegt ist.

Berechtigungen anpassen

Insbesondere bei Datei-Uploads lohnt es sich, genauer hinzuschauen, da sie auf Berechtigungen zurückzuführende Schwierigkeiten schnell aufzeigen. Änderungen an der Website im Rahmen der Tests sind durchaus erlaubt, da der neue Server kurz vor der Umstellung noch einmal den letzten Stand des alten übertragen bekommt.

Nachdem sichergestellt ist, dass die Website auch auf dem neuen Server funktioniert und sich die hosts-Datei wieder im ursprünglichen Zustand befindet, kann der alte Server seine Aufgabe als Reverse Proxy übernehmen, und zwar mithilfe des Apache-Moduls mod_proxy (für lighttpd gibt es ein gleichnamiges Modul, bei nginx heißt es HttpProxyModule) zusammen mit mod_proxy_http. Unter Debian Linux heißt der entsprechende Befehl:

a2enmod proxy 

Auch die Konfiguration lässt sich schon vorbereiten. Sie darf jedoch noch nicht bei einem Neustart des Apache aktiv sein. Das passiert erst im Zuge der eigentlichen Umstellung. Die folgende Konfiguration macht den Apache zum Reverse Proxy:

ProxyRequests Off
ProxyPass http://192.0.2.1/ 
ProxyPreserveHost On 

Diese Zeilen können entweder zu Beginn eines <VirtualHost>-Blocks stehen (das erlaubt die Umstellung einzelner virtueller Hosts) oder aber global anstelle der virtuellen Hosts. Die erste Angabe ProxyRequests Off verhindert, dass auf dem Server ein offener Proxy entsteht. Die Direktive ProxyPass stellt dann die eigentliche Durchleitung aller Zugriffe auf die neue IP-Adresse und damit den neuen Server sicher. Eine zusätzliche Angabe ProxyPreserveHost On erhält die Host-Header der Anfragen. Das ist wichtig, damit jeweils der richtige virtuelle Host auf dem neuen Server die durchgeleiteten Zugriffe beantworten kann.

Wer die vorbereitenden Arbeiten abgeschlossen hat, kann den Zeitpunkt der Umstellung frei wählen und ist unabhängig von der folgenden DNS-Änderung. Damit die Daten konsistent bleiben, sind mehrere aufeinanderfolgende Schritte notwendig. Einen kurzen Ausfall gilt es in Kauf zu nehmen, er dauert nicht viel länger als das Auslesen des MySQL-Dump und das anschließende Einspielen der Daten (Lösungsansätze für große Datenbanken und zum Minimieren der Ausfallzeit siehe unten).

Die Befehle für den alten Server lauten:

apache2ctl stop
rsync -azu --delete /var/www/
user@192.0.2.1:/var/www/
mysqldump -p --add-drop-database -A > mysql.sql
rsync -z ~/mysql.sql user@192.0.2.1:~/ 

Dann auf dem neuen Server:

mysql -p < ~/mysql.sql 

Und anschließend auf dem alten Server:

apache2ctl start 

Zunächst stoppt also apache2ctl stop den Webserver. So können während der Umstellung keine Änderungen mehr auftreten. Dann aktualisiert der erste rsync-Aufruf die Dateien auf dem neuen Server. Die Option -u stellt sicher, dass nur Dateien Berücksichtigung finden, die seit der ersten Übertragung hinzugekommen sind oder verändert wurden. Das spart viel Zeit. Mittels --delete löscht rsync Dateien auf dem neuen Server, die es auf dem alten nicht mehr gibt.

Anschließend erstellt mysqldump den MySQL-Dump, den rsync auf den neuen Server kopiert, wo ihn der mysql-Befehl wieder einspielt. Wer Zugriffsstatistiken per Logfile-Analyse erstellt, sollte jetzt außerdem die Log-Dateien vom alten auf den neuen Server übertragen (Schreibrechte für den Webserver beachten!) und dort den Apache neu starten. Zuletzt startet apache2ctl start wieder den Apache auf dem alten Server, der mit der zuvor geänderten Konfiguration nun ausschließlich als Reverse Proxy agiert.

Zu diesem Zeitpunkt gelangen zwar weiterhin alle Anfragen von außen zum alten Server, der sie aber an den neuen durchleitet und die Antwort wiederum an den Browser des Anfragenden zurückliefert. Die tatsächliche Bearbeitung läuft ab jetzt ausschließlich auf dem neuen Server. Funktioniert alles wie gewünscht, kann die DNS-Änderung (etwa im Rahmen eines Domain-Umzugs zum neuen Provider) auf die IP-Adresse des neuen Servers stattfinden. Bis die Änderung überall sichtbar ist, laufen die Zugriffe je nach Zugangs-Provider entweder über den Reverse Proxy auf dem alten Server oder direkt beim neuen Server auf. Am Ende des Vorgangs landen keine Anfragen mehr auf dem alten Server, und er kann abgeschaltet werden.

Fazit

Für einfache LAMP-Webserver bildet die beschriebene Vorgehensweise einen bequemen Weg, ohne langen Ausfall oder die Gefahr von Inkonsistenzen einen (Web-)Host mitsamt IP-Adresse zu wechseln. Für Server mit großen Datenbanken oder um die Ausfallzeit weiter zu minimieren, böte sich eine Master-Slave-Konfiguration für die MySQL-Server an. Dazu richtet man den MySQL-Server auf dem neuen Host zunächst als Slave für den alten Server ein und macht ihn anschließend im Zuge der Umstellung zu einem Master.

Stefan Wild

ist Wirtschaftsinformatiker und realisiert mit seiner Firma sw4.de Websites und Mediendatenbanken für Mittelständler und Großunternehmen.

Alle Links: www.ix.de/ix1106128 (un)