Einen LoadBalancer richtet man ebenso einfach ein. Zuerst braucht man aber mindestens einen Worker und damit es Sinn macht am besten gleich einen 2. dazu. Den Balancer kann man frei benennen. Mit „worker.TestBalancer.balance_workers“ legt man fest, welche Worker Teil des Balancer sind. Dort Komma- separiert die Liste an Tomats mit ihren Worker-Namen eintragen. „worker.TestBalancer.type“ setzt man dann auf „lb“. Wenn man in seiner Webapplikation mit Seesions arbeitet sollte man dann noch „worker.adminbalancer.sticky_session“ auf „1“ setzten. Damit man immer auf dem selben Worker bleibt und nicht mit jeden Request hin und her springt. Für die „method“ gibt es dann mehrere Optionen, hier ein Auszug aus der offiziellen Doku(1):

• If method is set to R[equest] the balancer will use number of requests to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This is the default value and should be working well for most applications.
• If method is set to S[ession] the balancer will use number of sessions to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. Because the balancer does not keep any state, it actually does not know the number of sessions. Instead it counts each request without a session cookie or URL encoding as a new session. This method will neither know, when a session is being invalidated, nor will it correct its load numbers according to session timeouts or worker failover. This method should be used, if sessions are your limiting resource, e.g. when you only have limited memory and your sessions need a lot of memory.
• If set to T[raffic] the balancer will use the network traffic between JK and Tomcat to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This method should be used, if network to and from the backends is your limiting resource.
• If set to B[usyness] the balancer will pick the worker with the lowest current load, based on how many requests the worker is currently serving. This number is divided by the workers lbfactor, and the lowest value (least busy) worker is picked. This method is especially interesting, if your request take a long time to process, like for a download application.

Request und Session haben sich bis jetzt bewährt. Der gesamte Parameter wird dann wieder mit „worker.TestBalancer.method“ gesetzt. Damit wäre dann auch ein Balancer konfiguriert. diesen dann nur noch in der „worker.list“ mit seinen Namen hinzufügen.

(1): http://tomcat.apache.org/connectors-doc/reference/workers.html

In der obigen Abbildung ist der Standardaufbau des Apache-Konfigurationsverzeichnisses zu sehen. Die Einzelnen Punkt werden nun im Folgenden durchgegangen. Sie werden der Rehe nach von oben nach unten durchgegangen.

conf.d

Im Verzeichnis „conf.d“ liegen zusätzliche Konfigurationsdateien, welche nicht unbedingt vom Apache2 selbst stammen müssen. Viele Applikationen legen ihre Konfigs hier ab um sich so in den Apache einzubinden. Zum Beispiel legt Nagios seine Apache spezifischen Konfigs hier ab. Alle Dateien die hierin liegen, werden automatisch eingebunden. Standardmäßig liegen hier auch immer die Dateien „charset“ und „security“. „charset“ würde den Apache2 dazu veranlassen, beim ausreichen von Dateien dies in einen Andern Charset auszugeben. Aber dies ist meist immer deaktiviert, da es an sich eine schlecht Idee ist, das Charset so zu manipulieren. „security“ gibt an, was der Apache im Fehlerfall an Informationen preisgeben soll. So Informationen wie Name, OS, Module, Requestbody, Signatur. Sollte man immer auf ein so wenig wie möglich begrenzen.

mods-available und mods-enabled

Unterhalb von „mods-available“ liegen alle Konfigurationen der mit Apache2 ausgelieferten und auch im Nachhinein installierten Module. Meist sind es nur simple Load-Anweisungen. Aber auch komplette Konfigurationen wie zum Beispiel bei mod_fcgi und mod_jk. Konfiguration in diesem Verzeichnis werden nicht automatisch geladen. Sie werden hier nur vorgehalten. Dies erklärt sich im Zusammenhang mit dem Verzeichnis namens „mods-enabled“. Denn wenn hier eine Konfig liegt, wird diese wieder automatisch eingebunden. Im laufe der zeit hatte es sich beim Apache2-Projekt eingebürgert, die Konfigs immer vor zuhalten und dann bei bedarf in „mods-enabled“ rein zu linken. D.h. die Konfigs liegen unterhalb von „mods-available“ und werden nur mittels eines symbolischen Links in „mods-enabled“ in die Gesamtkonfiguration vom Apache2 eingebunden. Dies ist allerdings Keine Pflicht. Man kann Konfigs auch direkt unterhalb von „mods-enabled“ ablegen.

sites-available und sites-enabled

Mit den Sites verhält es sich ähnlich wie mit den Mods. Es gibt einmal das „available“ Verzeichnis wo die eigentlichen Konfigs drin liegen und dann das „enabled“ Verzeichnis wo dann die aktiven Sites rein gelinkt werden. Daran wird sich bei der jetzigen Konfiguration allerdings nicht gehalten. Die aktiven Konfigs der Seiten liegen auch direkt im „enabled“ Verzeichnis. Sie werden nicht noch extra rein gelinkt.

SSL allgemein

Hier liegen die SSL-Zertifikate welche der Apache2 benutzen soll. Dieses Verzeichnis muss nicht immer bestehen, teilweise wird auch auf „/etc/ssl“ zurückgegriffen. Meist liegen die Zertifikate in „pem“-Form vor. Das heißt das Key und Zertifikat in einer Datei vereinigt sind. Daneben liegt dann meist noch das CA-Bundle. Dieses liefert noch einmal die Root-Zertifikate, mit welchen das eigene Zertifikat unterschrieben wurde. Das macht pro Domain dann immer 2 Dateien. Obwohl, wenn man die Zertifikate alle vom Selben Aussteller hat, es reichen würde immer auf ein ca-bundle zu verweisen.

Zertifikate haben immer nur eine begrenzte Gültigkeit. Danach müssen sie erneuert werden. D.h. In den meisten Fällen neu ausgestellt werden. Zertifikate lassen sich günstig und einfach von http://www.ready2host.de/ beziehen. Dort gibt es dann auch immer eine Einbauanleitung.

apache.conf

In der apche2.conf steht die Hauptkonfiguration des Apache2-Webserver. Hier muss man eigentlich selten Hand anlegen, da die Presets immer sehr gut funktionieren. Wichtig sind für einen nur zB. Die KeepAlive-Einstellungen. Diese stehen ganz oben in der Konfig. Auch sind dort gleich die Einstellungen zum Thread-Management. Am Ende der Datei stehen noch einige vHost-Sondereinstellungen (siehe 3.2.1).

envvars

Hier sind nur 3 Variablen hinterlegt. Dies ist eine Eigenart von Debian/Ubuntu. Die Variablen, besagen nur unter welchen User und welcher Gruppe der Webserver ausgeführt werden soll. Weiterhin noch wo die PID gespeichert werden soll.

httpd.conf

Diese Datei ist meist leer. In mach anderen Systemen ist dies die Hauptkonfiguration. Deswegen existiert sie auch hier, falls Programme nach ihr suchen. Aus welchen Gründen auch immer.

jk-workes-properties

Diese Datei ist zwar kein Standard,aber in Zusammenhang mit Tomcat wichtig. Sie besagt welcher Tomcat unter welchen Namen in der Apache2-Konfiguration anzusprechen ist. Auch werden hier die Balancer konfiguriert. Diese Datei ist immer im Zusammenhang mit „mod_jk“ zu betrachten.

ports.conf

Diese Datei stellt wieder eine Eigenart von Debian/Ubuntu dar. Hier sind allein nur die Ports gelistet auf welchen der Apache2 lauschen soll. Im Standardfall sind dies immer Port 80 und Port 443.

apt-get install php5-cgi php5-cli

fcgid installieren:
fcgid lässt sich relativ leicht durch das repository installieren. Dazu reicht ein einfaches apt-get aus.

apt-get install libapache2-mod-fcgid

Nach dem sollte es nun noch konfiguriert werden. Dazu nehmen wir aus der Apache2 Konfiguration erstmal das bisherige PHP5-Modul raus. Dazu entfernen wir einfach die LoadModul Aufforderung in der apache2.conf/httpd.conf oder wie bei Debian/Ubuntu-Systemen, dort löschen wir einfach die php5.conf und php5.load aus dem Verzeichnis “/etc/apache2/modules-enabled/”. Da es sich dabei nur um Symlinks handelt bleiben die eigentlichen Dateien also für den Notfall oder ein Rollback erhalten.

Nachdem wir nun das alte php5-Modul entfernt haben binden wir das neue ein. Dies tun wir durch die Direktive

LoadModule fcgid_module /usr/lib/apache2/modules/mod_fcgid.so

Das Modul muss natürlich an dieser Stelle auch liegen! Nutzen wir Ubuntu oder Debian wurde die Konfiguration schon nach “modules-enabled” geschrieben. So sollte das Modul schon einmal geladen werden. Jetzt muss es natürlich noch konfiguriert werden. Allgemein kann man wieder in der httpd.conf/apache2.conf folgenden Block einfügen oder diesen unter “modules-enabled/fcgid.conf” bearbeiten:

< IfModule mod_fcgid.c >
AddHandler fcgid-script .fcgi
SocketPath /var/lib/apache2/fcgid/sock
IdleTimeout 600
IdleScanInterval 200
BusyTimeout 300
BusyScanInterval 120
ErrorScanInterval 6
ZombieScanInterval 3
ProcessLifeTime 1200
# SpawnScoreUpLimit 10
# SpawnScore 1
# TerminationScore 2
MaxProcessCount 250
DefaultMaxClassProcessCount 10
DefaultMinClassProcessCount 0
IPCConnectTimeout 20
IPCCommTimeout 200
MaxRequestsPerProcess 500
< /IfModule >

Damit ist das fcgid-Modul schon mal grundsätzlich einsatz bereit. Fehlen nur noch 2 kleine Sniplets und wir sind fertig! Nach den Apache-Konfigurations-Anpassungen muss nun noch ein Wrapper-Skript her um die PHP-Prozesse zu steuern. Dies legen wir uns an einen beliebigen Ort, aber dort wo der Apache2 es auch lesen kann und machen es ausführbar. Ich habe meins z.B. dort abgelegt: “/etc/php5/php-procs.sh”. Der Inhalt des Skripts ist wie folgt:

#!/bin/sh
PHP_FCGI_CHILDREN=5
PHP_FCGI_MAX_REQUESTS=100
export PHP_FCGI_CHILDREN
export PHP_FCGI_MAX_REQUESTS
exec /usr/lib/cgi-bin/php5 "$@"


Zu beachten sei noch der Pfad zum php5-cgi Binary. Dieser sollte noch überprüft werden, da das Ding ja auch mal woanders installiert sein kann oder einen anderen Namen haben kann. Die Anzahl der Kinder kann man je nach Last auf dem System noch hoch oder runter stellen. Genauso wie die Maximalen Requests pro Kind, bevor dieses zerstört wird. Haben wir das alles nun getan, fehlt uns nur noch ein Eintrag im jeweiligen VHost, welcher mit PHP arbeiten soll. Dazu fügen wir in diesen zwei Directory-Kontainer ein oder bearbeiten Vorhandene dementsprechend.

< Directory / >
Options +FollowSymLinks
AllowOverride all
< /Directory >
< Directory /var/customers/webs/Zombie/ >
AddHandler fcgid-script .php
FCGIWrapper /etc/php5/php-procs.sh .php
Options Indexes +FollowSymLinks MultiViews ExecCGI
AllowOverride None
Order allow,deny
allow from all
< /Directory >

FollowSymlinks ist für Anwendungen außerhalb des Webroots gedacht. Das nutz ich meist um phpMyAdmin in verschiedenen Domains zu nutzen, ohne es X-Mal installieren zu müssen. Ist dies dann auch getan, sind wir fertig und geben noch ein finales

/etc/init.d/apache2 reload

ein. Damit werden all unsere Änderungen aktiv und wir können gucken ob sie auch funktionieren. Das sollten sie eigentlich auch ;-)