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.

export CATALINA_OPTS=”$CATALINA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9494 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \

Danach hat man erstmal grob Zugang zum Tomcat. Natürlich sollte man das noch mit SSL und nem Passwort absichern. Doch ich wollte erstmal die grundsätzliche Funktionalität Testen. Doch jegliche Versuche damit schlugen fehl. Ersteinmal sei auch gesagt, dass ein “export” davor muss und kein “set“, wie manche schreiben. Bei einer normalen Tomcat Installation ist es damit dann auch schon getan. Doch bei Gentoo muss das ganze nicht in die catalina.sh eingetragen. Trägt man es dort ein, wird es schlicht und einfach ignoriert. Also wohin nun damit? Für den an Gentoo gewöhnten Admin ist es klar das das nach “/etc/conf.d/tomcat-5.5” muss, für einen Debian/Ubuntu Admin ist dies allerdings nicht ganz so klar. Und auch Google verschwieg mir dies Information. Ich hatte mich dann nur daran erinnert das neulich beim Apache ähnlich schritte vollführt werden mussten. Da war es dann auf einmal auch ganz logisch, das dies beim Tomcat ähnlich sein würde. Doch darauf kam ich erst nach einer deprimierenden Suche und vielen im Nachhinein unnötigen Test.

In die “/etc/conf.d/tomcat-5.5” muss nun eben das ganze ohne “export” am Anfang eingetragen werden. Wenn man in der Datei ein wenig nach unten geht, findet man auch schon eine dafür vorbereitet Stelle, um die Daten dort einzufügen. Natürlich können sie innerhalb der Datei überall stehen, doch ein wenig Ordnung schadet ja auch nicht. Also hab ich dann dort Folgendes eingefügt:

export CATALINA_OPTS=”$CATALINA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9494 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \

Nachdem ich also alles in “/etc/conf.d/tomcat-5.5” eingetragen hatte, den Tomcat zum X. mal neu gestartet hatte, konnte ich mich nun endlich per jconsole auf diesen verbinden und mir das innere der JVM ansehen.