Load-Balancing mit dem Apache HTTP Server

Ein Indianer kommt selten allein

Erik Abele

Bei den heutigen Anforderungen an die Leistungsfähigkeit und Ausfallsicherheit von Web-Anwendungen sind Methoden zur Lastverteilung unverzichtbar. Dieser Artikel beschreibt, wie man mit wenig Aufwand einen effektiver Load-Balancer mit dem Apache-Webervers einrichtet.

Die zunehmende Komplexität moderner Web-Anwendungen erfordert in den meisten Fällen den Betrieb von mehreren Applikationsservern. Die Gründe hierfür sind vielfältig und reichen von steigenden Besucherzahlen, über die Sicherstellung der Verfügbarkeit bis hin zu den stetig wachsenden Anforderungen der Web-Anwendungen selbst. So wird es häufig sogar notwendig selbst statische Web-Seiten über mehrere Server zu verteilen um somit deren zeitige Auslieferung sicherzustellen.

Betrachtet man die unterschiedlichen Technologien und Situationen so wird schnell klar warum zahlreiche, völlig unterschiedliche Lösungen angeboten werden. Beginnend bei einfachen DNS-basierten Verteilungssystemen, reicht die Palette über andwendungsspezifische Load-Balancer bis hin zu hochspezialisierten, auf der Ebene des Netzwerks operierenden Geräten.

Die schematische Darstellung in Abbildung 1 verdeutlicht die dem Artikel zugrundliegende Struktur eines software-basierten und auf der HTTP-Schicht [1] arbeitenden Balancing-Systems.

Abbildung 1: Schematische Darstellung eines typischen, HTTP-basierten Balancing-Systems.

Den Kern bilden in diesem Aufbau mehrere Load-Balancer, sogenannte Frontend-Server oder Gateways, die die eingehenden Anfragen der Besucher nach einem vorgegebenen Muster auf eine Sammlung ("Pool") von Applikationsservern, auch Backend-Server genannt, verteilen.

Weitere dieser Einzelsysteme können im Hinblick auf eine gesteigerte Ausfallsicherheit auch nebeneinander betrieben werden (in Abbildung 1 im Hintergrund dargestellt). In diesem Fall ist jedoch für die Verteilung unterhalb der Einzelsysteme separat Rechnung zu tragen.

Vorbereitungen

Bevor der Indianer als Load-Balancer beziehungsweise Gateway zum Einsatz kommen kann ist es von Nöten die gewünschten Funktionalitäten mittels der gewohnten Modul-Methode zu laden:

LoadModule <emphasize class="replaceable">xyz</emphasize>_module↩
  modules/mod_<emphasize class="replaceable">xyz</emphasize>.so

Wir beschränken uns in diesem Artikel auf die grundlegenden Fähigkeiten eines HTTP-basierten Load-Balancers in Kombination mit Caching, Kompression, dem URL-Rewriting sowie auch der Verarbeitung von Headern. Tabelle 1 enthält daher eine Liste der nur für diesen Artikel speziell benötigten Module; die in der Regel standardmäßig aktiven Module werden vorausgesetzt.

Tabelle 1

Benötigte Module

Modul	Funktion
mod_proxy	Allgemeines Proxy-Modul
mod_proxy_balancer	Balancer-Funktionen zum Proxy-Modul
mod_proxy_http	HTTP-Unterstützung zum Proxy-Modul
mod_cache	Allgemeines Caching-Modul
mod_disk_cache	Datei-basierte Zwischenspeicher zum Caching-Modul
mod_deflate	Modul zur Kompression von Inhalten
mod_rewrite	Modul zum Verwerten und Bearbeiten von URLs
mod_headers	Modul zum Verwerten und Bearbeiten von HTTP-Headern

AJP, oder gar FTP?

Kommen als Backends JServ-fähige Applikationsserver zum Einsatz, wie zum Beispiel Apache Tomcat oder Jetty, so ist es möglich den Gateway ebenfalls mittels des Apache JServ Protokolls (AJP) zu betreiben. Hierzu wird lediglich das Modul »mod_proxy_ajp« anstelle von »mod_proxy_http« geladen sowie die relevanten URLs von http:// auf ajp:// abgeändert.

Die Verwendung dieses, auf einem Binärformat basierenden Protokolls verspricht neben einigen Vorteilen in Bezug auf die Performance der Backend-Verbindungen auch einen insgesamt niedrigeren Resourcenverbrauch. Um dies zu erreichen ist allerdings auch eine erhöhte Anzahl an ständigen Verbindungen zu den Backends in Kauf zu nehmen.

Ein drittes Modul namens »mod_proxy_ftp« sei hier nur der Vollständigkeit halber noch kurz als ein weiteres, unterstütztes Protokoll erwähnt. Weitere Details hierzu können der Dokumentation des Apache HTTP Servers [2] entnommen werden.

Übrigens können natürlich AJP-Backends auch neben HTTP-Backends verwendet werden, selbst innerhalb eines einzelnen Pools.

1 2 3 4 Weiter »