:::: MENU ::::

WebDevExp

Meine Erfahrungen in der Webentwicklerwelt

Layer 7 Loadbalancing

Loadbalancing

Layer 7 Loadbalancing

Nachdem wir feststellten, dass unsere Softwarelösung zu Fehleranfällig war, legten wir uns zwei Kemp Loadmaster 2500 zu (zwei damit die Highavailability-Funktionalität weiterhin vorhanden ist, fällt ein Balancer aus, übernimmt sofort der Andere IP und Services).

Die Loadmaster unterstützen Layer7 (OSI-Layer) Balancing, wodurch man besser verwalten kann, wohin welcher Traffic fließen soll (Content-Switching). Desweiteren unterstützen sie auf Layer7-Basis SSL, wodurch der Webserver keine Arbeit mehr mit dem Verschlüsseln, Entschlüsseln oder den Zertifikaten hat. Dies passiert dann alles im Loadmaster.

Wir nutzen eine One-Armed (oder One-Legged) Konfiguration (mittels „direct-return routing“), was heißt, dass die Webserver den Besuchern direkt antworten, ohne Umweg über den Balancer .

Nun gibt es fürs Layer7 Balancing zwei Möglichkeiten: tranparent und non-transparent.

Transparent bedeutet, dass die IP-Adresse des Besuchers auch als diese beim Webserver ankommt (für Logfiles, PHP usw). Hat allerdings den entscheidenen Nachteil, dass ALLE Webserver den Loadbalancer als Default-Gateway eingetragen haben müssen. Dies ist einer der Gründe, warum wir uns für die andere Möglichkeit entschieden, damit der Traffic nicht komplett über den Balancer zurückläuft (was Performance kosten würde).

non-Transparent hat den Nachteil, dass die Adresse nicht direkt beim Webserver angelangt, sondern immer nur die des Loadbalancers. Diese wird dann in den Logs ausgegeben und ist in PHP als $_SERVER[„REMOTE_ADDR“] verfügbar, wodurch ein IP-Logging oder Operationen, für welche die IP benötigt wird, unmöglich gemacht werden würden. Die Loadmaster können allerdings einen weiteren HTTPHeader in den Stream hinzufügen (X-Forwarded-For), in welchem sich die echte Besucher Adresse befindet.

Für lighttpd, welchen wir auf den Webservern nutzen, gibt es hierfür ein Modul (ModExtForward), dass diesen Header ausliest und die dort vorhandene IP-Adresse als Besucheradresse setzt (aus Sicherheitsgründen allerdings NUR wenn der Header auch von einem der Loadbalancer kommt!).
Durch dieses Modul ist es dann auch möglich, die IP-Adresse in PHP weiterhin mit $_SERVER[„REMOTE_ADDR“] auszulesen, ohne auf irgendwelche unsicheren Header zurückgreifen zu müssen. Unsicher, da Header grundsätzlich manupuliert werden können und es hier in vielen anderen Systemen schon SQL-Injections durch Headermanipulation gab. Nebenbei ist es, meines Wissens nach, nur mit Apache möglich, einigermaßen einfach auf die HTTPHeader zuzugreifen.

UPDATE
So leicht ist es dann wohl doch nicht. Ich stehe momentan in Kontakt mit dem Support der Geräte, da diese aus irgendeinem Grund den X-Forwarded-For Header nicht anhängen. Nachdem ich dachte, es könnte am lighttpd liegen, habe ich den Stream mit Wireshark kontrolliert und hier den entsprechenden Header nicht gefunden.
Bin mir momentan unsicher, ob dies an einem Konfigurationsfehler unsererseits liegt oder ob da tatsächlich ein Bug vorliegt.

UPDATE
Hier liegt wohl ein wenig was von allem vor. Nach ein wenig Kommunikation mit dem KEMP Support, kam heraus, dass eine Persistency für den VirtualService gesetzt sein muss. Egal welche, egal wie lange sie gültig ist. Dann wird auch der entsprechende Header mit eingespeist. Mod_extForward von lighttpd macht dann den Rest und alles klappt. Montag morgen gehts dann auch im Livesystem online (bis jetzt läuft der Layer7 Test auf dem Testserver mit einem Test-VirtualService, das Livesystem läuft noch auf Layer4), was es schwer macht, die Seite einfach in den „Wartungsmodus“ zu versetzen.

UPDATE
Es lief dann letztendlich doch. Allerdings musste das Netzwerkdevice lo:0 heruntergefahren werden und NAT statt direct-route return genutzt werden. Als wir uns allerdings richtung Mittag bewegten und mehr User online waren, stieg der CPU Load der Balancer ins unermessliche und sie stürzten ab. Nach viel hin und her sind wir doch wieder bei Layer4. Aber direkt mit dem KEMP-Support in Kontakt, damit das Problem, hoffentlich, bald gelöst wird.

UPDATE
KEMP hat uns ein Firmwareupdate zur Verfügung gestellt, mit dem es nun endlich einwandfrei funktionieren sollte. Mal sehen, was uns erwartet, aber ich bin guter Dinge, dass nun endlich doch alles so klappt, wie es klappen sollte.

Leave a comment

Loading Facebook Comments ...