Konfiguration

Die in Listing 1 abgedruckte Beispielkonfiguration zeigt die grundlegenden Einstellungen eines Frontend-Servers; sie könnte so zum Beispiel einen virtuellen Host erweitern.

ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
ProxyErrorOverride On
ProxyTimeout 30
<Proxy balancer://<emphasize class="replaceable">pool1</emphasize>>
  BalancerMember http://<emphasize class="replaceable">server1</emphasize>:8080 \
    min=10 max=50 loadfactor=2
  BalancerMember http://<emphasize class="replaceable">server2</emphasize>:8080 \
    min=5 max=25 loadfactor=1
</Proxy>
ProxyPass /<emphasize class="replaceable">shop</emphasize> balancer://<emphasize class="replaceable">pool1</emphasize> \
  lbmethod=byrequests \
  nofailover=Off maxattempts=3 \
  stickysession=<emphasize class="replaceable">PHPSESSIONID</emphasize>

Zunächst wird der normale Proxy-Modus mittels »ProxyRequests« deaktiviert um einen sogeannten Reverse Proxy, oder korrekterweise Gateway, zu erhalten. Das gleichzeitige Abschalten der Weitergabe der Via-Header mittels »ProxyVia« bewirkt die Unsichtbarkeit des Gateways. Die beiden Anweisungen »ProxyPreserveHost« und »ProxyErrorOverride« stellen zudem sicher, daß die in der Anfrage enthaltenen Host-Header an die Backends weitergereicht werden und, daß etwaige, durch die Backends generierte, Fehlermeldungen durch den Load-Balancer ersetzt und somit vereinheitlicht werden. Die Angabe eines geeigneten Timeouts mittels »ProxyTimeout« rundet die Basis-Konfiguration ab.

Die eigentliche Definition des Herstücks, eines Backend-Pools inklusive seiner Mitglieder, erfolgt hingegen mittels eines »Proxy« Containers und der Angabe des speziellen balancer:// Schemas gefolgt vom Namen des Pools. Die im Container enthaltenen »BalancerMember« Anweisungen sowie ihre Parameter legen hierbei die einzelnen Mitglieder fest und bestimmen auch deren Eigenschaften.

Zum Ende der Konfiguration wird der zuvor definierte Backend-Pool einem eigenen URL-Raum zugewiesen; weitere Parameter bestimmen hierbei die allgemeine Arbeitsweise des Load-Balancers. Um in den Genuss einfacher, regulärer Ausdrücke zu kommen, könnte hier anstatt »ProxyPass« auch einfach die erweiterte »ProxyPassMatch« Anweisung Verwendung finden.

Alternativ steht mit Hilfe des des Rewrite-Moduls ( »mod_rewrite« ) und eigens erstellter Regeln natürlich immer auch die volle Leistungsfähigkeit von regulären Ausdrücken zur Verfügung. In diesen Fällen wird jedoch die Verwendung von »ProxySet« notwendig, da per Regel keine Parameter des Load-Balancers beeinflusst werden können:

ProxySet balancer://<emphasize class="replaceable">pool1</emphasize>↩
  lbmethod=bytraffic
...
RewriteEngine On
RewriteRule ^/+(.*)$↩
  balancer://<emphasize class="replaceable">pool1</emphasize>/$1 [P,L]

Im Fall des Beispiels in Listing 1 werden also zwei Backend-Server im Pool pool1 definiert. Die Verteilung der Anfragen wird anhand der Anzahl dieser Anfragen bestimmt (siehe »lbmethod« Parameter), wobei aufgrund der Einstellung des sogenannten "Load Factors", server1 im Vergleich zu server2 immer die doppelte Anzahl an Anfragen erhält. Verbindungen werden wiederverwendet, aber auch auf einen oberen Maximalwert begrenzt. Als URL-Raum wird der komplette Raum unterhalb der URL " /shop " gewählt.

Eine Übersicht über die gebräuchlichsten Parameter der »ProxyPass« und »BalancerMember« Anweisungen findet sich in Tabelle 2 . Die Dokumentation des Apache HTTP Servers [2] enthält jedoch eine weit ausführlichere Beschreibung aller Parameter und sollte in jedem Fall konsultiert werden.

Möglichkeiten

Neben den schon zahlreichen Optionen zur Basis-Konfiguration stellt das Proxy-Modul ( »mod_proxy« ) des Apache HTTP Servers eine schier unüberschaubare Fülle an speziellen Einstellungsmögklichkeiten zur Verfügung. Für nahezu jede denkbare Situation wird ein geeignetes Werkzeug angeboten und einer individuellen Ausgestaltung der Balancer-Funktionalität steht somit nichts im Wege.

Mit Hilfe des »status« Parameters ist es zum Beispiel möglich einen sogenannten "Hot Standby Server" zu betreiben:

BalancerMember http://<emphasize class="replaceable">server4</emphasize>:1080↩
  ... status=+H

Hiermit wird erreicht, daß server4 nur im Fall des Versagens der restlichen Pool-Mitglieder zur Verwendung kommt. Er ist also die letzte "Verteidungslinie" und lässt sich im Katastrophenfall zum Beispiel dazu benutzen, um eine eingeschränkte Version der Web-Anwendung auszuliefern oder gar um auf ein Ersatz-System zu verweisen.

Eine weitere, häufig anzutreffende Konfiguration findet sich in der Unterstützung von sogenannten "Sticky Sessions":

BalancerMember http://<emphasize class="replaceable">server6</emphasize>:1080↩
  ... stickysession=JSESSIONID

Der Einsatz des »stickysession« Parameters in Kombination mit dem Namen eines von den Backends unterstützten Cookies bestimmt, daß die von einem einzelnen Besucher ausgehenden Anfragen jeweils zu dem gleichen Backend-Server geleitet werden. Diese Art der limitierten Verteilung stellt zwar die Persistenz der Anfragen sicher, ist aber auch dem eigentlichen Load-Balancing sehr abträglich. Leider ist dies in der Praxis keine Ausnahme.

Um gezielt Informationen an die Backend-Server weiterzugeben oder die Kommunikation mit diesen zu beeinflussen, erlaubt das Proxy-Modul auch die Verwendung von eigens definierten Umgebungsvariablen und HTTP-Headern. So lässt sich einerseits die Verbindung zu den Backends limitieren oder aber zum Beispiel auch die Verwendung von SSL mitteilen:

SetEnv proxy-nokeepalive 1
...
RequestHeader set Front-End-Https "On"

Einige schon definierte Standard-Variablen und -Header wie zum Beispiel »proxy-nokeepalive« , »proxy-sendcl« , »X-Forwarded-For« oder auch »X-Forwarded-Server« , erleichtern die Arbeit und ersparen Tipparbeit.

Übrigens lassen sich alle eigens und auch vordefinierten Variablen als zusätzliche Log-Angaben in gewohnter Manier verwenden: »%{ VAR }i« .