Praxisbeobachtung: Serverumzug mit IP-Wechsel

[Jürgen Auer]

Da Server-Daten inzwischen seit drei Jahren online ist, stand ein Wechsel der gesamten Hardware auf dem Programm. Mehr Leistung, eine neue Gerätegeneration, mehr Service-Inklusiveleistungen bei HostEurope.

Also neue Server, Switch und Firewall - damit auch eine neue IP-Nummer für den Webserver und für alle Subdomains der Form

kundenname.server-daten.de

sowie für die externen Domains, die intern auf Unterverzeichnisse von Kunden-Subdomains umgelenkt wurden.

Ursprünglicher Plan: Mit dem ganzen System 'in einem Rutsch' in der Nacht vom 25. zum 26.12 umziehen. Natürlich die Sorge, daß dann Kundensubdomains einige Stunden für bestimmte Nutzer nicht erreichbar seien - aber wie sonst?

Tests im Vorfeld ergaben, daß der neue Webserver problemlos auf den alten Datenbankserver zugreifen kann und daß der Performanceverlust durch den langen Weg Webserver - neuer Switch - neue Firewall - HostEurope-Netz - alte Firewall - alter Switch - alten Datenbankserver durch den Performancegewinn des neuen Webservers ausgeglichen wurde.

Am Samstag (20.12) war schließlich alles vorbereitet, gegen 20:00 wurden alle Domaindefinitionen in einem Rutsch auf die neue IP geändert.

Beobachtungen:

• Erste Zugriffe auf den neuen Server gab es nach wenigen Minuten
• Am späten Samstag Abend gingen etwa 1/3 der Zugriffe auf den neuen Server, fast nichts von Suchmaschinen.
• Im Laufe des Sonntags kippte das von 1/3 neu auf 2/3 neu, auch google zog schon größtenteils um
• In der Nacht vom Sonntag auf Montag praktisch nur noch Suchmaschinenzugriffe auf den alten, kaum google, größtenteils Yahoo, etwas MSN und ein paar Splitterbots.
• Yahoo verabschiedete sich heute mittag auf dem alten, seither ist dieser praktisch tot.
• Wie vorgesehen, wird es in der Nacht 25./26.12 den Umzug der Datenbanken geben, da wird es eine kurze Unterbrechung geben (sichern, überspielen, einhängen, ein großes Script laufen lassen). Aber eine Viertelstunde mitten in der Nacht ist zumutbar und zur Sicherstellung der Konsistenz auch notwendig. Außerdem ist dieser Teil längst getestet, das Script wurde entsprechend angepaßt.

Fazit: Vor dem IP-Wechsel und dem damit verbundenen längeren Ausfall hatte ich ursprünglich doch ziemlichen Bammel, deshalb auch der Zeitpunkt an Weihnachten, zu dem (1) sehr wenig im Web los ist, (2) die Firmenkunden in den Büros ohnehin nicht arbeiten (auch wenn es viele Freiberufler bei Kunden gibt, die auch abends drauf sind). Gleichzeitig war der Umzug notwendig und anstehend. Die neue Leistung ist schon sehr viel umfangreicher als das bisherige Paket, das Risiko eines Hardwareausfalls wächst natürlich bei Geräten mit dem Alter.

Statt Bammel: Ein sehr relaxtes Wochenende - abgesehen von der etwas nervigen Kleinigkeit, daß es den Microsoft.Jet.OleDb.4.0 - Treiber nicht für 64-bit - Umgebungen gibt und ich mir noch rasch eine Möglichkeit einfallen lassen mußte, den Download von Daten als Exceltabellen auch so zu realisieren (ging im Endeffekt ganz einfach: Daten in eine Datei schreiben und ein .NET-Programm aufrufen, das mit /platform:x86 kompiliert wurde und die Daten nach Access / Excel schaufelt: In so einer WoW64-Umgebung funktioniert der Jet-Treiber).

Drei Einschränkungen:

Zum einen setzt das eine Trennung zwischen Web- und Datenbankserver voraus. Nur dann kann man mit dem IP-kritischen Webserver umziehen und parallele Zugriffe von altem und neuem Webserver verkraften, ohne Daten zu verlieren oder Inkonsistenzen zu produzieren.

Zum anderen ist dafür die parallele Anmietung der Geräte notwendig. Aber das war in meinem alten Vertrag glücklicherweise inklusive. Das kostet zwar im Ernstfall etwas mehr, wenn man für ein paar Tage Geräte doppelt bezahlt - aber das Ergebnis ist sehr streßschonend. Und der durchgehend störungs- und unterbrechungsfreie Betrieb beim IP-Wechsel ist es wert.

Schließlich: Ohne dezidierte Firewalls wäre das natürlich eine Harikiri-Geschichte. So genügt es, dem neuen Webserver Zugriff auf den alten, ansonsten völlig abgeschotteten Datenbankserver zu ermöglichen - ohne irgendein Risiko eines Zugriffs von außen.

 

[realloc]

Danke, ist immer wieder mal schön, solche Erfolgsgeschichten zu lesen.

 

[Jürgen Auer]

So, jetzt muß ich ein kleines virtuelles Sektglas kippen

Server-Daten läuft nämlich seit 22:44 komplett auf dem neuen System - und das zu meiner eigenen Überraschung ohne Unterbrechung.

Eigentlich war für nachher so zwischen 04:00 und 05:00 geplant: Webserver blockieren, alle Datenbanken sichern, komprimieren, per FTP transferieren, wiederherstellen, ein großes Script laufen lassen, Webserver umschalten und wieder freigeben.

Technisch hatte ich bis vor zwei Stunden keine andere Lösung gesehen!

Gegen 22:15 teste / übe ich das nochmals. Dabei stellte sich heraus, daß das ganze Procedere mindestens zehn Minuten dauert. Alles geht eben bloß sequentiell, alleine das Komprimieren dauert eine ganze Weile.

Die Lösung lag - nach dem Abschluß dieses Tests - in einem Blick in die NET-Trace-Liste, eine Art Debug-Liste, die man einschalten kann und die einem dann doch diverse Hinweise liefert. Da zeigte sich: Praktisch nur GET-Zugriffe innerhalb dieser zehn Minuten, lediglich bei zwei Kundendatenbanken einige POST, die Daten schreiben. GET schreibt innerhalb von Server-Daten nichts. Diese Designentscheidung vor drei Jahren ist jetzt plötzlich wichtig geworden.

Also freche Überlegung: Diese beiden Kundendatenbanken nochmals nachsichern, dann wechseln?

Gedacht, gemacht, das ging natürlich rasend schnell, eingehängt, ein weiterer Blick in das Trace - kein POST seither. Man kann die Liste leeren, damit sieht man das auf einen Blick.

Also den Eintrag in der Global.asax mit dem Servernamen des Datenbankservers geändert, die Datei gespeichert, diese Änderung führt zu einem automatischen Neustart der Webanwendung ... läuft ... läuft immer noch ... auf beispiel.server-daten.de rumgeklickt ... immer noch ok, soll es das schon gewesen sein? So ganz ohne Crash? Ein wenig auf anonym zugänglichen Kundendatenbanken rumgeklickt, alles ok - also funktioniert das doch.


Fazit: Es war vor vier, fünf Jahren bei der Konzeption so eine merkwürdige Ahnung - 'nutze bloß POST zum Anmelden, Schreiben, kein GET'. Jetzt hat das den Kunden und den Lesern der anonym zugänglichen Seiten eine mindestens zehnminütige Unterbrechung erspart. Bei Webseiten ist es einfach immer doof, wenn die nicht erreichbar sind.

Danke für's Lesen - jetzt ist Feierabend.