Serverumzug vollständig!

Der schon vor einiger Zeit angekündigte Serverumzug zu einem anderen Anbieter und Wechsel von einem Webhostingpaket zu einem vServer ist jetzt endlich abgeschlossen. Probleme gab es erstaunlicherweise so gut wie gar keine.

Als Anbieter hat Strato das Rennen gemacht. Das Preis/Leistungsverhältnis hat einfach gestimmt (simple Studenten-Rechnung: Je teurer und leistungsfähiger der Server, desto weniger 5-Minuten-Terrine im Schrank. Und was würden wir ohne Konservenfutter nur tun? :P) Leider hört man zu Strato einige negative Berichte, die aber auch alle ein wenig älter sind… Allerdings gehören zu jedem größeren Anbieter enttäuschte Kunden und schlechte Kritiken. (ich habe echt keinen mit einer ganz weißen Weste gefunden) Also probiere ich das jetzt einfach aus. Sollte es Probleme geben, so kann ich aber relativ einfach kündigen und wieder den Server wechseln, daher ist das Risiko denke ich gering. (obwohl der Frustfaktor und die zusätzliche Arbeit wohl hoch wäre)

Die alte Website auf den neuen Server zu bringen war erstaunlich einfach: Ich hatte in der Zeit zuvor alles, was auf dem Server lag in einzelne, unabhängige Module zerlegt. (Der vorige Webspace wurde nicht nur von mir genutzt, sondern auch von ein paar anderen Leuten. Außerdem lief einiges an Software (Foren, Bildergalerien, etc.) darauf, was teilweise durch hässliche PHP-Hacks miteinander verbunden war.)

Diese einzelnen Stücke, meistens bestehend aus einer MySQL-Datenbank oder einigen Tabellen daraus, PHP-Scripten und HTML konnte ich dann einzeln auf den neuen Server schieben, während auf dem alten noch alles weiter lief. Dann war für das “veröffentlichen” der Module auf dem neuen Server sobald alles stabil lief nur noch eine Änderung der DNS-Einstellungen nötig.  🙂 Die Ausfallzeit war marginal, einzige Probleme gab es mit dem Umzug der Domains: Zum einen hatte ich den Aufwand nicht bedacht, mit dem der Umzug einer .net-Domain verbunden ist (zig Unterschriften & Ausweiskopie per Post/Fax versenden). Zum anderen hatte der Umzug ziemlich merkwürdige Seiteneffekte: So waren teilweise Subdomains kurzzeitig mit anderen Zielen als vorgesehen verknüpft, die Haupseite durch das Standard-Schild (“Hier entsteht eine neue Homepage!”) ersetzt mit der IP des alten Servers als Ziel, während ein Unterordner (example.com/blah) verfügbar war und auf die IP des neuen Servers zeigte… Wie das möglich war ergibt sich mir noch immer nicht, das sollte soweit ich weiß technisch gar nicht gehen… Nach drei Tagen jedoch waren die Probleme weg und alles funktionierte wie geplant. (naja, fast – PHP wollte noch eine kleine Sonderbehandlung)

Zu den technischen Details: Auf dem Server läuft – hätte bestimmt kein Leser dieses Blogs vermutet 😛 – Debian Squeeze mit PHP, MySQL, Perl und Python. Als Webserver wollte ich zunächst Lighttpd verwenden (mein Standard-Testserver), da aber auch Nginx ganz interessant aussah, habe ich beides ausprobiert. Relativ schnell bin ich dann auch auf Cherokee gestoßen. Dieser Webserver verspricht ähnliche Performance wie Lighttpd und Nginx (soll angeblich sogar besser sein) und bietet als besonderes Feature eine grafische Konfigurationsoberfläche (webbasiert).

Da ich auf dem neuen vServer zunächst wenig kaputtmachen konnte (es war ja noch kein Inhalt da) und ich eh ziemlich experimentierfreudig bin, habe ich beschlossen – nach der Installation und Konfiguration von Nginx, welche wirklich nicht so schwer ist, wie gedacht (man muss auch kein Russisch mehr dafür können!) – doch auch mal Cherokee auszuprobieren. Die GUI-Konfiguration habe ich dabei zunächt nicht benutzt, da mir das doch etwas “seltsam” vorkam, einen Server grafisch einzurichten. Inzwischen gefällt mir die Oberfläche jedoch recht gut, vor allem da man eventuelle Probleme in einer übersichtlichen GUI manchmal schneller findet als in einem oder mehreren config-files. Cherokee wird aktiv entwickelt, Bugs werden (anders als es offenbar bei Lighttpd bei einigen Bugs zugeht) schnell behoben und es existiert eine kleine Community. Die mangelnde Apache-Kompatibilität ist manchmal etwas lästig, ansonsten ist Cherokee aber sehr einfach zu verwalten.

Ich setzte den Server jetzt auf allen Seiten produktiv ein und hoffe, dass alles weiterhin so gut läuft 🙂 . Verglichen mit vorher laden alle Websiten merklich schneller und die “Error 505”-Fehler sind nun auch alle passé. Die Performance von Cherokee ist schonmal absolut ausreichend und ist zu Spitzenzeiten sogar geringfügig besser als die von Lighttpd (zu Nginx habe ich keine Daten – man kann “Lastbetrieb” auch nur schwer simulieren. Ein DDoS-Angriff zum Webservertest wäre mal cool 😛 )