© Dirk Houben, Fotolia

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.

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.

Gesundheit

Zum Geschäft der Loadbalancer gehört es, die Belastung und Verfügbarkeit der realen Server zu messen und zu bewerten (Healthcheck oder Monitoring, etwa beim TCP-Connect). Der Scheduler nutzt diese Information für seine Entscheidung, welcher Server welchen Request erhält. Dabei gilt es auch, Sessions persistent auf ihrem Server zu halten: In vielen Webapplikationen speichert der Server Informationen über den Zustand des Clients, zum Beispiel wenn sich der Benutzer einloggt oder einen virtuellen Warenkorb füllt. Das muss der Loadbalancer berücksichtigen, um die Applikation nicht aus dem Tritt zu bringen.

Bessere Loadbalancer implementieren ein Bündel von Techniken, um zu erkennen, welche Requests zu einer gemeinsamen Sitzung gehören. Die Zeus-Appliance wertet zum Beispiel Cookies aus, fügt auf Wunsch eigene Cookies ein oder benutzt eine von vielen weiteren Techniken. Sie schafft es sogar, SOAP-Anwendungen per Loadbalancing zu beschleunigen. Dazu analysiert die Appliance den XML-Inhalt der Nachrichten.

ZXTM 7400

Zeus liefert die Appliance mit fünf Netz-Interfaces (siehe Kasten “Die Hardware”). Eines dient vorrangig dem Out-of-Band-Management (OOB), also dem Admin-Zugang über ein eigenes Kabel. Für die Grundeinstellungen (Netzwerk, Default Gateway …) stehen das Web-GUI oder eine serielle Konsole bereit. Da die Appliance unter Linux läuft (modifiziertes Debian Sarge mit Ubuntu-Kernel), finden Linux-Profis eine gewohnte Kommandozeile vor.

Auch die weitere Konfiguration geht schnell und intuitiv: Pool von realen Servern definieren (Abbildung 1), Healthcheck wählen, Routing zwischen realen Servern und Loadbalancer herstellen, VIP und Scheduling-Algorithmus wählen (Abbildungen 2 und 3), entscheiden, ob Sessions persistent auf ihrem Server bleiben müssen, und das Routing zwischen der VIP und den Clients herstellen.

Um in der Labor-Testumgebung auf den Webservern und der Appliance Last zu erzeugen, kam das bewährte Apache-Benchmarkingprogramm »ab« zum Einsatz. Es gehört zur Basisinstallation vieler Linux-Distributionen. Interessanterweise programmierte Adam Twiss 1996 die erste AB-Version; er ist einer der beiden Gründer der Firma Zeus. Seither pflegt die Apache Software Foundation das Tool. Zudem arbeitet Twiss seit einigen Jahren nicht mehr für Zeus. Daher ist sichergestellt, dass Zeus die Messwerte nicht manipuliert.

Wesentlich für den Test war nicht die reine Antwortzeit auf einen einzelnen Request. Ob der virtuelle Server in 0,4 oder 0,2 Millisekunden antwortet, bemerkt kein Anwender. Solche Verzögerungen gibt es im Internet immer. Viel wichtiger ist die Linearität der Messwerte, also dass der virtuelle Webserver zur Beantwortung von 200 gleichzeitigen Requests nur doppelt so lange braucht als für 100 und nicht plötzlich viermal so lange. Interessant war auch, ob es möglich ist, den Effekt von Connection Management durch Keepalives, HTTP-1.1-Kompression und intelligentes Caching nachzuvollziehen.

Gute Messwerte

Die Messungen in Abbildung 4 stammen vom Abruf einer 4 KByte großen Webseite aus einem Cluster mit zwei Apache-Servern (Abbildung 5) auf gewöhnlicher PC-Hardware. Die Last stieg von 100 auf 1000 gleichzeitige (concurrent) HTTP-Requests. Diese Testbedingungen sind, verglichen mit E-Commerce-Webseiten im realen Einsatz, recht gering. Ein Spitzenprodukt wie die Zeus ZXTM 7400 muss auch 50 000 bis 100 000 HTTP-Requests pro Sekunde verkraften.

Nach Herstellerangaben schafft die Appliance bis zu 92 000 HTTP-Requests pro Sekunde. Das ließ sich in der Testumgebung zwar nicht überprüfen, die interessanten Effekte zeigen sich aber bereits vor der 1000-Grenze. Viele CGI-Skripte und Webapplikation verhaken sich schon bei 70 oder 100 gleichzeitigen Abrufen, statt wie erhofft mit linear steigenden Antwortzeiten zu reagieren.

Die Messwerte zeigen, dass Keepalives nur wenig Vorteil bringen, wenn sie der Loadbalancer nur in den Verbindungen zu den Servern nutzt. Erst wenn er sie auch Client-seitig aktiviert, lässt sich der positive Einfluss gut belegen. Hierbei öffnet die Appliance nur einige wenige Verbindungen zu jedem realen Server und wickelt alle Anfragen über diese bereits geöffneten Connections ab.

Auch der Content-Cache führte zu einer deutlichen Verbesserung der Messwerte. Eine nennenswerte Steigerung durch HTTP-1.1-Kompression war dagegen nicht nachzuweisen; das lag aber vermutlich an der HTTP-Implementierung in »ab« und der reichlich vorhandenen Netzwerkbandbreite.

Reine Performancewerte haben an Bedeutung verloren, da sich die meisten Loadbalancer hierin kaum unterscheiden. Ob einer 92 000 oder 100 000 Requests pro Sekunde schafft, ist kaum relevant. Zudem sind die Herstellerangaben schwer vergleichbar. Bei Asic-Systemen gelten die Zahlen für Layer-4-Loadbalancing, während die Produzenten von PC-basierten Systemen ihre Leistungsfähigkeit lieber auf Layer 7 demonstrieren. Viel wichtiger sind Flexibilität, Features und Stabilität. Intelligente Loadbalancer greifen heute tief in die Datenkommunikation und auf Wunsch sogar in die ausgelieferten Inhalte ein.

Optimierung per Skript

In dieser Disziplin glänzt Zeus mit seinem so genannten Trafficscript. Für einfache Aufgaben wie das Evaluieren der HTTP-Headerfelder gibt es im Browser-basierten GUI einen Rule-Builder-Wizard (Abbildung 7). Wer höhere Ansprüche hat, schreibt die Regeln selber. Dabei gibt ihm eine 154 Seiten starke Referenz Auskunft. Das fertige Skript kopiert er in das Web-GUI der Appliance.

Bei Trafficscript handelt es sich um eine vollwertige Skriptsprache, die anhand der Informationen aus den OSI-Schichten 3 bis 7 bequem Entscheidungen fällen und Daten ändern kann. Zeus unterscheidet zwischen Request-Rules für die hereinkommenden Anfragen und Response-Rules für die Antworten der realen Server. Das folgende Beispiel zieht Informationen aus Layer 7 (hier die URL »/downloads«) und setzt daraufhin einen Layer-3-Parameter (das TOS-Bit im IP-Header; TOS: Type of Service). Dabei bleibt das Skript lesbar und verschont den Admin vor der Komplexität der beteiligten Protokolle:

$url = http.getPath();
if (string.startsWith ($url, "/downloads"))
{
    response.setToS ("THROUGHPUT");
}

Wenn diese Regel an einen virtuellen Server gebunden ist, über den ein Client eine URL abfragt, die mit »/downloads« beginnt, dann markiert die Appliance alle zu dieser Verbindung gehörenden IP-Pakete mit dem TOS-Bit für Throughput. Das Ziel ist maximaler Durchsatz für Download-Dateien. Die Markierung wirkt sich zwar nur auf die eigene Internetverbindung aus, das genügt aber oft schon. Auch zeigt das Beispiel, dass der Hersteller hier ein sehr universelles Mittel anbietet, das die Layer 3 bis 7 verbindet und beeinflusst.

Weitere Einsatzszenarien wären: das Copyright-Datum auf allen ausgelieferten Webseiten ändern, Meta-Tags einfügen, HTTP-Header auswerten (User-Agent, Accept-Language …) oder die Bandbreite von Downloads beschränken. Zeus verteilt nicht nur die Last, die Appliance schützt die realen Server auch vor übermäßiger Belastung. Die Techniken hierfür reichen von simplen White- und Blacklisten bekannter Clients über Connection Limiting (maximale Anzahl der Verbindungen pro Client) und Prüfungen des HTTP-Headers bis zu beliebigen Regeln, implementiert in Trafficscript.

Beste Balance

Die Zeus-Appliance ZXTM hat die Tester beeindruckt durch ihre Flexibilität, einfache Konfiguration und die hervorragenden Messwerte. Sie belegen, dass dank Web Application Optimization ein Cluster mehr ist als die Summe seiner Server. Besonders Trafficscript gewährt enorme Einflussmöglichkeiten.

Lediglich bei IPv6 fällt Zeus im Vergleich zu F5 und Nortel Networks zurück. Während die Konkurrenz bereits mit vollem IPv6-Support wirbt, muss Zeus auf künftige Releases vertrösten, ohne konkrete Zeitangaben. Andererseits ist der Hersteller mit GSLB (siehe Kasten “Globale Sicht”) auf dem besten Wege, seine Produktschiene in die Spitzenliga auszudehnen. Auch die Hardware leistete sich kaum Schwächen und verdient die Note “sehr gut”. Dem harmonisch und durchdacht aufgebauten System ist viel Stabilität zuzutrauen.

Mit der ZXTM 7400 steht dem Admin ein universelles Gerät zur Verfügung, das alle Facetten der Lastverteilung im Webserver-Cluster beherrscht und vom simplen Layer-4-Switching bis zum tiefen Eingriff in den HTTP-Datenstrom und sogar die HTML-Dokumente alles anbietet, um im Web die Balance zu halten. (fjl)