Lastverteilung, Backends und Statistiken
[mp3 url="http://www.pretzlaff.info/wp/wp-content/uploads/2008/06/21062008-lastverteilung.mp3"]Vorlesen[/mp3]
In den letzten Tagen, schon eher Wochen war es hier recht still. Der Grund ist die Last des Servers gewesen. Da ein Bekannter von mir einen schlecht programmierten Chat benutzt war die Last auf der Datenbank und dem Webserver teilweise sehr hoch. Dadurch konnten ein paar Seiten nicht mehr ausgeliefert werden. Damit meine Seiten erreichbar bleiben habe ich einfach schnell alle hinter einen Loadbalancer gepackt, der diese Seite z.B. auf drei Webserver verteilt. Die Datenbank wurde auf eine zweite MySQL geschoben und alle Webserver benutzen jetzt für diese Seite die neue Datenbank über eine VPN Verbindung.
Das geht aktuell noch sehr gut, sollten die Besucherzahlen weiter so steigen wird auch hier die nächste Lösung zum Einsatz kommen. Diese wird aber aktuell noch getestet, damit nachher nichts schief läuft.
Das nächste Problem war dann mit der Verteilung auf die verschiedenen Server die Uploads beim Wordpress und anderen. Diese werden nur auf dem Server abgelegt, auf dem ein Upload ausgeführt wurde. So sind diese Dateien auf den anderen Servern nicht vorhanden. Dazu wird jetzt regelmässig zwischen den einzelnen Servern synchronisiert. Das übernimmt Unison, da es sehr gut mit SSH funktioniert.
Bei einem anderen Thema wird aktuell an Lastverteilten Front-, Backends und Proxys gebastelt. Der Grund ist Google Analytics, GetClicky usw. die Trackingdaten auf Ihren Servern speichern. Jetzt wird das alle komplett selbst gemacht. Alle Daten werden bei mir gespeichert, nichts mehr an andere Anbieter übertragen. Denn es könnte immer mal sein, das Daten an dritte weitergegeben werden, ein Anbieter stellt seinen Dienst ein oder der Dienst wird kostenpflichtig. Wenn auch nur zum Teil kostenpflichtig, fehlen dann vielleicht dann im kostenlosen Teil die Daten die am wichtigsten sind.
Weitere Argumente gegen einen externen Dienstleister sind Ausfälle bei diesem. Als beim letzten mal Google ausgefallen ist (DNS/Domainklau) waren alle Seiten, die Google Analytics einsetzen nicht mehr erreichbar oder sehr eingeschränkt nutzbar. Es kam immer zu Timeouts beim einbinden des Google Codes und Seiten wurde nur halb oder sogar überhaupt nicht mehr angezeigt. Schlimmer als ein Ausfall ist aber ein erfolgreicher Hack der Google Server. Sollte das einmal passieren könnten Angreifer die Hälfte aller Internetseiten weltweit umleiten auf eigene Seiten.
Damit die eigenen Statistiksoftware stabil und zuverlässig erreichbar ist, ist sie auch hinter einem Loadbalancer, die jeweiligen Frontends sind aber so abgespeckt, das sie nicht mehr viel, bis auf eine Funktion Scriptseitig ausführen können. Sie rufen die angeforderten Inhalte auf den Backends ab, die jeweils wieder nur einen Teil der Aufgaben übernehmen. Ein paar können PHP, die anderen wiederum können z.B. nur Perl. Das ganze setzt sich somit wie folgt zusammen.
- 2 Loadbalancer
- Je Loadblancer 4 Frontends
- Je Frontend 4 PHP und 4 Perl Backends
Die Frontends haben nur die Funktion die Anfragen für die Backends so verarbeiten damit diese mit den richtigen Parametern gefüttert werden. Sollte jetzt jemand z.B. versuchen und auch noch Erfolg haben PHP- oder Perlscripte dazu zu benutzen um externen Code auf dem Webserver abzulegen ist es zwar toll für den Angreifer. Problem ist nur das er im weiteren Verlauf überhaupt nicht auf sein zuvor abgelegtes Script zugreifen kann. Es wurde, wenn es jemand überhaupt schaffen sollte, auf einem der Backends ausgeführt. Diese sind aber überhaupt nicht vom Internet aus erreichbar. Auch nicht über angehängte Parameter könnte man den Frontendserver dazu zubewegen diese weiter durch zureichen. Dazu kommt noch, der Angreifer weiss gar nicht das er auf dahinter liegende Server zugreift und schon gar nicht auf welchen er landet.
Was weiter oben schon angesprochen wurde ist hierbei kein Problem, wenn eine Anfrage sehr langsam oder gar nicht von einem Backend beantwortet werden kann. Bei den ersten Tests war es schon erstaunlich wie schnell die Seiten aufgebaut wurden, auch wenn die entsprechenden Backends komplett abgeschaltet waren. Der Rest der Seite wurde von den anderen geliefert und prompt vom Browser dargestellt.
Zusätzlich wird noch die MySQL-Datenbank in Zukunft mit primary und secondarys betrieben um die lesenden Zugriffe auf mehrere Server besser zuverteilen. Schreibend wird auf den primary zugegriffen, lesend über einen MySQL-Proxy auf allen, je nach dem wie die Last auf den einzelnen Datenbankservern aktuell ist.
Der aktuelle Traffic ist pro Stunde bei ca. 500 - 700 MB, kommt dabei dann dazu das z.B. das Chatsystem wieder einmal amok rennt, wurde es ab und zu einmal eng für die anderen Seiten auf dem Server. Durch die Veränderungen ist es egal, wenn etwas passiert. Sollte ein Server überhaupt nicht mehr erreichbar sein sind noch genug andere vorhanden um die Anfragen zu verarbeiten. Einer der Nebeneffekte ist auch, man kann einzelne Server aus der Verteilung nehmen und auf Testdomains benutzen um mit der Live Konfiguration testen zu können. Klappt alles mit diesem Server nimmt man noch mehr aus der Verteilung, macht die Änderungen auf diesen auch und tauscht die neu konfigurierten Server mit den aktuell genutzten aus. Man muss dann nur noch die restlichen Server umkonfigurieren und anschliessend wieder mit in die Verteilung nehmen. Die User merken nichts davon und es ist auch wesentlich weniger Stress. Man weiß das man in Ruhe auch einmal einen Fehler machen kann.
