Linux-basierter Loadbalancer und Web-Applikationsbeschleuniger

Immer in Balance

von Jörg Fritsch

Erschienen im Linux-Magazin 2007/04

Die Last der Anfragen in einem Cluster von Webservern zu verteilen ist weit mehr als reihum die Requests zuzuordnen. Zeus zeigt mit seiner Appliance ZXTM 7400, welche technischen Finessen von Protokollschicht 4 bis 7 nötig sind, um stark frequentierte Webauftritte in Schwung halten.

Irgendwann stößt auch der stärkste Webserver an seine Grenzen und braucht Hilfe. Die zu besorgen ist kein Problem, sie zu koordinieren sehr wohl. Jeder Cluster aus Servern (hier Webservern) muss Anfragen intelligent verteilen, um die gemeinsame Kraft auch sinnvoll einzusetzen. Von all dem soll der Client nichts bemerken, alles passiert hinter den Kulissen. Beispielsweise durch die hier getestete Appliance ZXTM 7400 von Zeus Technology [1].

Loadbalancer unterscheiden zwischen den realen Servern (Abbildung 1) und der virtuellen IP (VIP, Abbildung 2). Die realen Server sind Webserver, jeder ist mit einer eigenen, eindeutigen IP ausgestattet (reale IP, RIP). Die VIP ist nur auf dem Loadbalancer konfiguriert. Die Clients sehen nur die VIP des Webauftritts und wenden sich an die Adresse, nicht ahnend, dass sie tatsächlich bei einem Lastverteiler landen, der die Anfrage mittels Scheduling-Algorithmus einem Server zuteilt.

Eine recht simple Umsetzung dieses Prinzips arbeitet wie Destination-NAT (Network Address Translation), das die Zieladresse der Anfrage ändert (von VIP auf RIP) und bei den Antworten passend die Quelle (aus RIP mach VIP). Meist zu finden ist diese Variante in Asic-basierten Geräten (Application Specific Integrated Circuit), die mit ihrer hoch spezialisierten Hardware die Manipulation sehr schnell vornehmen. Gerade in der Anfangszeit der Web-Loadbalancer (siehe Kasten "Sieben Jahre Loadbalancing") galten Asics als Garanten für ausreichend Performance.

Sieben Jahre
Loadbalancing

Die Idee, mehrere Webserver per Loadbalancing parallel zu betreiben, ist keineswegs neu. Sie hat allein in den vergangenen sieben Jahren zahlreiche Reinkarnationen erlebt. Auf dem Zenit der Dotcom-Blase (1999 bis 2001) war die Notwendigkeit von Lastverteilung damit begründet, dass im harten E-Commerce-Geschäft der Anbieter zum Zug kommt, dessen Systeme am schnellsten antworten. Der Kunde galt als latent ungeduldig. Die Lastverteilung fand damals ausschließlich auf OSI-Layer 4 statt, also auf der Transportschicht.

Nach den Ereignissen des 11. September wechselte die Argumentation. So genannte Flash Events (FE) oder Flash Crowds erzeugen plötzliche Spitzenlasten, die einen Server schnell in die Knie zwingen, wenn er nicht ausreichend vorbereitet ist und Ressourcen auf Reserve vorhält. Als FEs gelten erfolgreiche Werbekampangenen ebenso wie populäre Schlagzeilen oder tatsächliche Katastrophen.

Als potenzielles Nadelöhr darf ein Loadbalancer selbst kein Bremsklotz sein. Folglich verwendeten die Hersteller meist spezialisierte und Asic-basierte Hardware (Application Specific Integrated Circuit) in ihren Loadbalancern und Application Switches. Durch geschickte Zuteilung der Ressourcen (Scheduling) holten sie das Maximum aus der vorhandenen Webserver-Hardware. Nur wenige der Hersteller, die damals schon auf PC-basierte Systeme setzten, habe bis heute überlebt. Dazu gehören F5 Networks und Arraynetworks.

Der schwere Weg nach oben

Heute haben sich die Ziele der Hersteller stark verändert. Ein moderner Layer-7-Loadbalancer wie die getestete Zeus-Appliance ZXTM 7400 verspricht, einer Webserver-Farm mehr Performance und Stabilität zu verleihen, als die Summe der einzelnen Teile bietet. Wer vier Webserver betreibt und diese mit einem modernen Loadbalancer verbindet, erhält mehr als die vierfache Leistung - so das Versprechen. Die neuen Systeme erreichen ihre Ziele mit mehreren Mitteln. Sie harmonisieren zum Beispiel die Anzahl und das Handling der TCP-Verbindungen von Client zu Server und nutzen Layer-7-Technologien wie HTTP-1.1-Kompression und intelligentes Content-Caching.

Zusätzlich können die Hersteller von Layer-7-Loadbalancern darauf setzen, dass die meisten Webauftritte nicht optimal programmiert sind und sich daher gut optimieren lassen. Weil diese Tricks komplexe Logik verlangen, verzichten viele Anbieter heute auf Asics und setzen PC-basierte Serverhardware ein.

PC-Technik statt Spezialhardware

Wenn es mehr sein soll, geraten die Algorithmen schnell zu aufwändig für Asics. Glücklicherweise reicht die Prozessorleistung in Server- und PC-Hardware heutzutage auch für anspruchsvolle Aufgaben, wie die getestete Appliance beweist. Sie arbeitet eher wie ein Reverse Proxy, der keine IP-Adressen umschreibt, sondern die TCP-Verbindung des Clients terminiert und eine neue TCP-Verbindung zum Real Server öffnet. Auf diesem Weg hält er die Verbindungen unter Kontrolle und kann auch in den Datenstrom eingreifen. Der reale Server sieht die Source-IP-Adresse des Loadbalancers und schickt die Antwort dann zur Appliance, die diese an den Client weiterreicht.

Nur ein Prozess pro Core

Um mit der hohen Asic-Geschwindigkeit Schritt zu halten, fordern PCs eine clevere Programmierung. Der britische Hersteller Zeus hat dank seines hauseigenen Webservers viel Wissen in der Entwicklung optimierter Netzwerksoftware. Daraus leiteten die Programmierer ab, dass ein herkömmliches Multi-Processing- oder Multi-Threading-Modell nicht ausreicht, weil zu viel Zeit beim Kontextwechsel verloren geht.

Die Zeus-Lösung passt zu Dan Kegels Empfehlungen [3] für flotte Netzwerksoftware und belegt jeden CPU-Core mit genau einem Prozess. Das Programm nutzt den »epoll«-Mechanismus, um blockierungsfrei auf allen offenen Verbindungen nach Daten zu suchen - ganz ohne Kontextwechsel. Für alle Bearbeitungsschritte verwenden die Programmierer nicht-blockierende Funktionen.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.