Neues in mod_jk und Technisches White Paper September 2006

Transkript

1 Technisches White Paper September 2006 Autor: Rainer Jung Version: 1.1 kippdata informationstechnologie gmbh Bornheimer Straße 33a Bonn Telefon: 0228 / Telefax: 0228 / Web: info@kippdata.de

3 Inhalt: 1 Einleitung Die Möglichkeiten der Weiterleitung Traditionell: JkMount Dynamisch: JkMountFile Invertiert: Worker-Attribut mount Apache HTTPD-Stil: SetHandler und Environment-Variablen Änderungen in der workers.properties Worker-Hierarchie Mehrzeilige Attribute Abgekündigte Attribute Load-Balancing Balancing-Methoden Aktivierungszustand Fehlererkennung Wiederanlauf Interne Wartung Inter-Prozess-Kommunikation Gruppierung und Vervielfältigung Der Status-Worker Logging Sonstiges Zusammenfassung Literaturhinweise...26 Seite 3 von 26

4 Seite 4 von 26

5 1 Einleitung Webserver gelten seit vielen Jahren als ausgereifte Komponenten. In der letzten Zeit werden jedoch einige neue Anforderungen an sie gestellt, die wesentliche Weiterentwicklungen nötig machen. Komple xere Protokolle, die über HTTP getunnelt werden, AJAX und Mobile-Clients, LDAP-Integration und neue Backends, über die eine Lastverteilung aufgespannt werden muss, sind Beispiele für solche An forderungen. Im Zusammenspiel des Apache-Webservers mit dem Tomcat-Container kommt in diesem Zusammen hang dem Apache-Modul mod_jk eine Schlüsselrolle zu. Nach einiger Zeit der Stagnation ist es 2006 zu einem starken Entwicklungsschub gekommen, dessen Ergebnisse wir hier vorstellen wollen. Die beiden Releases und , die in diesem Jahr bislang veröffentlicht wurden, hat der Autor dieses Doku mentes, Rainer Jung, als Release Manager betreut. Darüber hinaus hat er den größten Teil der Weiter entwicklung selbst durchgeführt. Zur großen Freude des Tomcat-Projektes haben die beiden neuen Releases von mod_jk sehr viel positives Feedback aus der Community erhalten. Viele der Vorschläge aus den Rückmeldungen zu sind be reits in umgesetzt worden. In der Beta-Phase wurde die Version innerhalb von drei Tagen über 100 Mal heruntergeladen. Dieses Dokument, das die Weiterentwicklung des Moduls mod_jk detailliert beschreibt, richtet sich nicht an mod_jk-anfänger. Grundkenntnisse in der Basis-Konfiguration müssen bereits vorhanden sein ([1]). Wir hoffen, dass die Leser unsere Begeisterung über die vielen Fortschritte nach der Lektüre dieses Doku mentes teilen. Wer auch in Zukunft auf dem Laufenden bleiben möchte, findet das Changelog jedes neu en Releases im Internet [2]. Die kontinuierliche Diskussion zur Entwicklung und die Commit-Nachrichten der Versionsverwaltung können ebenfalls im Internet unter [3] verfolgt werden. Viele Aspekte dieses Dokumentes werden auch in zwei gemeinsamen Artikeln mit Peter Roßbach im Ja vamagazin besprochen ([5],[6]). Eine Bemerkung am Rande: Im neuesten Apache 2.2 sind Erweiterungen zu mod_proxy implementiert worden, die auf lange Sicht mod_jk für Apache ablösen sollen: mod_proxy_balancer und mod_proxy_ajp. Die Möglichkeiten dieser proxy-erweiterungen sind jedoch noch weit von der Mächtig keit von mod_jk entfernt Es ist allerdings zu erwarten, dass ein Wechsel im Laufe des Jahres 2007 möglich ist, nicht zuletzt weil wir uns bemühen werden bis dahin Features von mod_jk für mod_proxy zu portieren. Wir beschränken uns in dieser Beschreibung auf den Einsatz von mod_jk in Verbindung mit dem ApacheWebserver. Die Aussagen gelten allgemein für Apache 1.3, 2.0 und 2.2. Auf Besonderheiten in Ver bindung mit anderen Webservern wie etwa Microsoft IIS gehen wir hier nicht ein. Die Pfade in diesem Dokument sind in Unix-Notation geschrieben. Alle Aussagen gelten aber auch ana log für die Filesysteme der vielen anderen Plattformen, für die mod_jk zur Verfügung steht. Seite 5 von 26

6 2 Die Möglichkeiten der Weiterleitung Der Modul mod_jk dient dazu, Anfragen die einen Webserver erreichen an einen oder mehrere nachge lagerte Tomcat-Instanzen weiterzuleiten. In der Regel ist es jedoch so, dass nicht alle Anfragen weiterge leitet werden sollen. Als Erkennungsmerkmal, welche Anfragen weiterzuleiten sind, dienen meist URLPrefixe und -Suffixe. Insgesamt gibt es in mod_jk vier recht verschiedene Methoden, Weiterleitungen zu konfigurieren. Da für drei dieser vier Methoden die mod_jk-releases und wichtige Ergänzungen und Fehlerbe hebungen beinhalten, möchten wir hier alle vier Varianten vorstellen. 2.1 Traditionell: JkMount JkMount ist eine Direktive, die in der Apache-Konfiguration eingesetzt wird. Sie kann auf zwei Weisen verwendet werden JkMount mit URL-Muster In diesem Fall wird das URL-Muster explizit angegeben. Beispiel: Jk M o u n t / m y a p p / * my w o r k e r Dieses Mapping leitet also alle Anfragen, die mit /myapp/ beginnen, an den Worker myworker weiter. Der angegebene Pfad muss mit einem / beginnen. Er darf die speziellen Zeichen? und * enthalten. Dabei steht? für ein einziges beliebiges Zeichen und * für beliebig viele Zeichen. Es handelt sich hierbei also nicht um klassische reguläre Ausdrücke. Enthält die Pfadangabe weder ein?, noch ein *, dann gibt es nur einen Match für Anfragen, deren URL exakt gleich dem angegebenen Pfad ist. Häufig möchte man den Kontext-Namen der Webapplikation mappen, sowie alle URLs darunter, also etwa /myapp, /myapp/, /myapp/*, nicht jedoch /myappext. Bislang verwendete man hierfür zwei Direktiven: Jk M o u n t / m y a p p my w o r k e r Jk M o u n t / m y a p p / * my w o r k e r Mittlerweile geht dies mit einer syntaktischen Abkürzung: Jk M o u n t / m y a p p / * myw o r k e r Der senkrechte Strich bedeutet, dass die Pfadangabe in zwei Pfade aufgelöst wird, einmal alles bis zum Strich, und die zweite Pfadangabe alles bis zum Ende, aber ohne den Strich. Um Ausnahmen von einem Mapping zu definieren, verwendet man die Direktive JkUnMount: Jk U n M o u n t /m y a p p / s t a t i c / * Seite 6 von 26 my w o r k e r

7 Auch hier ist bei Bedarf die Strich-Notation einsetzbar. Ein vorangestelltes - schaltet das Mapping des dahinterstehenden Pfades ab JkMount in einem Location-Element Verwendet man JkMount in einem Location-Element, dann darf es keine Pfadangabe bekommen, son dern erbt den Pfad aus dem Location-Element. Beispiel: <L o c a t i o n /*. j s p > Jk M o u n t my w o r k e r </ L o c a t i o n > Bei Verwendung dieser Notation ist äußerste Vorsicht geboten! Der Pfad aus dem Location-Element wird exakt so, wie er in der Konfiguration steht für das JkMount übernommen. Das hat zur Folge, dass er mit einem / beginnen muss. Weiterhin kann man diese Notation zwar auch in LocationMatch verwenden, aber die Bedeutung von * in LocationMatch ist eine völlig andere, als im JkMount. Es wird deshalb stark davon abgeraten, diesen Ansatz mit LocationMatch zu verbinden. Neben JkMount ist auch wieder JkUnMount in einem Location-Element erlaubt. Es funktioniert ganz ana log zum JkMount Weitere Tricks: JkMountCopy und JkAutoAlias Arbeiten Sie mit mehreren virtuellen Servern und haben einige Mappings, die für alle virtuellen Server gelten, dann können Sie diese im globalen virtuellen Server definieren und dort das Flag JkMountCopy setzen. Dann erben alle virtuellen Server die Mappings vom globalen virtuellen Server. Beispiel: Jk M o u n t C o p y On Die Direktive JkAutoAlias dient dazu, auf möglichst einfache Weise statischen Content vom Webserver ausliefern zu lassen. Dies funktioniert nur, wenn der Webserver Zugriff auf die ausgepackten Web applikationen hat. In sicherheitsrelevanten Installationen wird man dies vermeiden wollen. Für einfachere Umgebungen kann es jedoch sehr bequem sein. Pro virtuellem Server ist jedoch nur eine JkAutoAlias-Di rektive erlaubt. Beispiel: Jk A u t o A l i a s /o p t / w e b a p p s Jk M o u n t / c o n t r o l l i n g / * wc Jk U n M o u n t /c o n t r o l l i n g / s t a t i c / * wc Jk M o u n t / o r d e r s / * wo Jk U n M o u n t /o r d e r s / *. h t m l wo Jk U n M o u n t /o r d e r s / *. g i f wo Jk U n M o u n t /o r d e r s / *. j p g wo Jk U n M o u n t /o r d e r s / *. c s s wo Seite 7 von 26

8 Jk U n M o u n t /o r d e r s / *. j s wo Jk M o u n t / r e p o r t s / *. j s p wr Jk M o u n t / r e p o r t s / *. d o w r Die drei Anwendungen müssen hierfür im Verzeichnis /opt/webapps ausgepackt sein, und zwar als Unterverzeichnisse controlling, orders und reports. Für controlling werden alle Anfragen an den Worker wc gesendet. Alle Requests, die auf den Unterordner static zeigen, werden nicht weitergeleitet, sondern von Apache verarbeitet. Bei der Anwendung orders haben wir ein Beispiel, bei dem alle Anfragen mit bestimmten Suffixes ausgenommen wurden. Schließlich haben wir bei reports das umgekehrte Verfahren gewählt, näm lich nur Anfragen an den Worker zu geben, die auf bestimmte Suffixes enden. 2.2 Dynamisch: JkMountFile Die Worker-Mappings lassen sich auch in einer speziellen Datei definieren. Dies hat den Vorteil, dass mod_jk am Zeitstempel der Datei erkennen kann, ob sie sich geändert hat. In diesem Fall lädt er sie im laufenden Betrieb neu. Diese Überprüfung geschieht alle 60 Sekunden. Beispiel: Jk M o u n t F i l e co n f / u r i w o r k e r m a p. p r o p e r t i e s Der Dateiname ist frei wählbar. Der hier gezeigte Name wird häufig verwendet. In jedem virtuellen Server kann die JkMountFile-Direktive nur einmal verwendet werden. Das Format der Datei ist zeilenorientiert. In jeder Zeile steht ein Mapping-Muster und ein Workername, jeweils verbunden mit einem Gleichheitszeichen. Kommentare beginnen mit einem #. Beispiel: # Ma p th e wh o l e co n t r o l l i n g /c o n t r o l l i n g / * = w c # Un m a p s t a t i c!/ c o n t r o l l i n g / s t a t i c / * con t e x t # Ma p JS P s an d St r u t s in th e re p o r t s co n t e x t /r e p o r t s / *. j s p = w r /r e p o r t s / *. d o = w r # Di s a b l e ma p p i n g - /o r d e r s / * = w o we mi g h t h a v e e n a b l e d ea r l i e r in th e co n f i g u r a t i o n Ein führendes Ausrufezeichen! entspricht in der Bedeutung exakt dem JkUnMount-Befehl. Regeln, die so definiert wurden, unterbinden die Weiterleitung auf jeden Fall. Beginnt eine Regel mit einem -, dann wird dadurch ein eventuell vorher stattgefundenes Mapping auf den gleichen Pfad abgeschaltet. Sollte später jedoch erneut ein solches Mapping gelesen werden, dann wird es im Unterschied zu! wieder angeschaltet. Seite 8 von 26

9 2.3 Invertiert: Worker-Attribut mount Bislang haben wir jeweils einem Pfad einen Worker zugeordnet. Es geht jedoch auch umgekehrt: einem Worker werden ein oder mehrere Pfade zugeordnet. Dies kann in der Worker-Konfigurationsdatei ge schehen. Beispiel: Jk W o r k e r s F i l e co n f / w o r k e r s. p r o p e r t i e s In der Datei workers.properties können wir nun bei den dort definierten Workern mit dem At tribut mount zugehörige Pfad-Mappings angeben. Dabei sind seit Version von mod_jk auch mehrere mount-zeilen je Worker erlaubt: Beispiel: wo r k e r. l i s t = w c wo r k e r. w c. t y p e = a j p 3 wo r k e r. w c. h o s t = m y h o s t wo r k e r. w c. p o r t = wo r k e r. w c. m o u n t = / c o n t r o l l i n g / * wo r k e r. w c. m o u n t =! / c o n t r o l l i n g / s t a t i c / * 2.4 Apache HTTPD-Stil: SetHandler und Environment-Variablen Schon länger war es möglich, mittels der Direktive SetHandler jakarta-servlet in der Apache-Konfiguration einen Request über mod_jk weiterzuleiten. Allerdings wurde dann stets der erste Worker in der Worker-Definition verwendet. Für alle praktischen Zwecke war diese Einschränkung zu stark. Seit mod_jk ist es jetzt möglich SetHandler mit einer Environment-Variable zu kombinieren, die man auf den Namen des gewünschten Workers setzen kann. Der Name der Environment-Variablen ist JK_WORKER_NAME. Er kann jedoch mit der Direktive JkWorkerIndicator umgesetzt werden. Beispiel: # Us e th e va r i a b l e WO R K E R _ V A R Jk W o r k e r I n d i c a t o r W O R K E R _ V A R to s t o r e th e w o r k e r na m e # Ma p al l su b d i r s t o wo r k e r s vi a n a m i n g ru l e # an d ex c l u d e st a t i c co n t e n t. <L o c a t i o n /a p p s / > Se t H a n d l e r j a k a r t a - se r v l e t Se t E n v I f RE Q U E S T _ U R I ^ / a p p s / ( [ ^ / ] * ) / WO R K E R _ V A R $1 Se t E n v I f RE Q U E S T _ U R I ^ / a p p s / ( [ ^ / ] * ) / s t a t i c no - j k </ L o c a t i o n > Wir schicken also alle Requests, die mit /apps/ beginnen, an Worker weiter. Das besondere hierbei ist, dass wir den Namen des Workers automatisch aus dem Namen des nächsten Verzeichnisses nach /apps/ in der URL bestimmen. Seite 9 von 26

10 Dieser Weg der mod_jk-konfiguration ist ausgesprochen mächtig. Environment-Variablen lassen sich insbesondere beim Einsatz von mod_rewrite sehr flexibel setzen. Seit Apache 2.2 ist es außerdem möglich auch den Handler (hier: jakarta-servlet) mittels mod_rewrite zu setzen. Allerdings ist dieses zuletzt vorgestellte Verfahren auf einer anderen Basis implementiert. Wenn Sie es zusammen mit einem der anderen Verfahren einsetzen und die Weiterleitungsregeln sich widersprechen, dann ist es nicht immer ganz einfach das Ergebnis zu verstehen. Vereinfacht lässt sich sagen, dass das SetHandler-Verfahren dann ausgeführt wird, wenn die obigen drei Verfahren keinen Match erzeugen. Sie können also weder positive Matches der anderen Verfahren hiermit verändern. Noch verhindert ein JkUn Mount eine Ausführung von SetHandler. Seite 10 von 26

11 3 Änderungen in der workers.properties Im Release wurden einige Code-Teile, die für das Lesen der Worker-Konfigurationsdatei wor kers.properties zuständig sind, überarbeitet. Hierdurch ergeben sich zwei wesentliche neue Möglichkeiten in der Konfiguration. Außerdem ist es jetzt möglich, Attribute auch abzukündigen (depre cation). 3.1 Worker-Hierarchie Gerade beim Einsatz von Load-Balancer-Workern ist es häufig so, dass man viele Worker in der Konfigu ration stehen hat, bei denen die meisten Attribute gleich konfiguriert sind. Das neue Attribut refe rence ermöglicht es, Attribute zwischen Workern zu vererben. Hier zunächst ein einfaches Beispiel: wo r k e r. l i s t = t i c, t a c # wo r k e r to e d e f i n e s so m e de f a u l t wo r k e r. t o e. t y p e = a j p 1 3 wo r k e r. t o e. h o s t = m y h o s t wo r k e r. t o e. s o c k e t _ k e e p a l i v e = t r u e wo r k e r. t o e. c o n n e c t _ t i m e o u t = wo r k e r. t o e. r e c o v e r y _ o p t i o n s = 3 se t t i n g s # wo r k e r s ti c an d t a c in h e r i t th o s e va l u e s wo r k e r. t i c. r e f e r e n c e = w o r k e r. t o e wo r k e r. t i c. p o r t = wo r k e r. t a c. r e f e r e n c e = w o r k e r. t o e wo r k e r. t a c. p o r t = Die Worker tic und tac erben hier fünf Attribute vom Worker toe. Bitte beachten Sie, dass der Wert des Attributes reference nicht nur toe, sondern worker.toe ist. Wir überlassen es dem Leser herauszufinden, was passiert, wenn die Einträge für toe nicht mit worker.toe, sondern z.b. mit template.toe beginnen. Die Vererbung von Attributen kann auch mehrstufig geschehen, d.h. ein Worker von dem geerbt wird, kann selbst auch wieder von einem Worker erben. Bitte konfigurieren Sie aber keine endlosen Schleifen. Studieren Sie doch einmal die folgende Konfiguration und vergleichen Sie den Umfang, wenn Sie diese ohne Referenzen aufbauen: # We on l y us e on e l o a d b a l a n c e r wo r k e r. l i s t = l b # Le t ' s d e f i n e so m e de f a u l t s wo r k e r. b a s i c. p o r t = wo r k e r. b a s i c. t y p e = a j p 1 3 wo r k e r. b a s i c. s o c k e t _ k e e p a l i v e = t r u e wo r k e r. b a s i c. c o n n e c t _ t i m e o u t = wo r k e r. b a s i c. r e c o v e r y _ o p t i o n s = 7 # An d we us e t h e m i n tw o gr o u p s wo r k e r. l b 1. d o m a i n = d o m 1 wo r k e r. l b 1. d i s t a n c e = 0 Seite 11 von 26

12 wo r k e r. l b 1. r e f e r e n c e = w o r k e r. b a s i c wo r k e r. l b 2. d o m a i n = d o m 2 wo r k e r. l b 2. d i s t a n c e = 1 wo r k e r. l b 2. r e f e r e n c e = w o r k e r. b a s i c # No w we co n f i g u r e th e l o a d b a l a n c e r wo r k e r. l b. t y p e = l b wo r k e r. l b. m e t h o d = B wo r k e r. l b. b a l a n c e d _ w o r k e r s = w 1 1, w 1 2, w 2 1, w 2 2 wo r k e r. w 1 1. h o s t = m y h o s t 1 1 wo r k e r. w 1 1. r e f e r e n c e = w o r k e r. l b 1 wo r k e r. w 1 2. h o s t = m y h o s t 1 2 wo r k e r. w 1 2. r e f e r e n c e = w o r k e r. l b 1 wo r k e r. w 2 1. h o s t = m y h o s t 2 1 wo r k e r. w 2 1. r e f e r e n c e = w o r k e r. l b 2 wo r k e r. w 2 2. h o s t = m y h o s t 2 2 wo r k e r. w 2 2. r e f e r e n c e = w o r k e r. l b Mehrzeilige Attribute Ebenfalls neu ist die Möglichkeit in allen Einträgen in der workers.properties, die mehrfache Werte erlauben, diese in mehrere Zeilen aufteilen zu können. Stellen Sie sich vor, Sie wollen einen LoadBalancer definieren, der über 100 Ziel-Worker verteilen soll. Dann wird das Attribut balance_wor kers, welches die Komma-separierte Liste aller Ziel-Worker enthält schon sehr unangenehm lange. Die folgenden Attribute erlauben eine Verteilung ihrer Werte auf mehrere Zeilen: worker.list: Die Liste der in den Pfad-Mappings erlaubten Worker worker.myworker.mount: Mappings, die für einen Worker namens myworker de finiert werden sollen (vgl. Abschnitt ) worker.mylbworker.balance_workers: Die Liste der Ziel-Worker, auf die ein Load-Balancer Worker namens mylbworker verteilen soll Beispiel: wo r k e r. l i s t = l b 1 # No w co m e s th e co n f i g u r a t i o n fo r th e l o a d b a l a n c e r... wo r k e r. l b 1. b a l a n c e _ w o r k e r s = w 1 1 # An d he r e we ad d t h e co n f i g u r a t i o n fo r w wo r k e r. l b 1. b a l a n c e _ w o r k e r s = w 1 2 # An d he r e we ad d t h e co n f i g u r a t i o n fo r w wo r k e r. l i s t = l b 2 # No w co m e s th e co n f i g u r a t i o n fo r th e l o a d b a l a n c e r... wo r k e r. l b 2. b a l a n c e _ w o r k e r s = w 2 1 # An d he r e we ad d t h e co n f i g u r a t i o n fo r w wo r k e r. l b 2. b a l a n c e _ w o r k e r s = w 2 2 # An d he r e we ad d t h e co n f i g u r a t i o n fo r w Seite 12 von 26 lb 1 lb 2

13 Wie man sieht, erlaubt diese Aufteilung eine logischere und weniger fehleranfällige Anordnung in der Konfiguration. 3.3 Abgekündigte Attribute Einige Attribute wurden ab Version formal abgekündigt. Für alle diese Attribute existieren äquiva lente Nachfolge-Attribute. In allen Fällen funktionieren sogar die abgekündigten Attribute noch. Allerdings kann dies in kommenden Versionen entfallen. Um das Abkündigen vernünftig umzusetzen, wird jetzt beim Starten von Apache im Log-Level warn ge logt, welche abgekündigten (deprecated) Attribute gefunden wurden. Hier eine Übersicht der Abkündigungen: cachesize: Ersetzt in durch connection_pool_size cache_timeout und recycle_timeout: Ersetzt seit Version durch connection_pool_timeout balanced_workers: Ersetzt in durch balance_workers (man beachte den Wegfall des letzten Buchstabens d ) disabled und stopped: Ersetzt in durch activation Auch wenn die alten Konfigurationen noch funktionieren, empfehlen wir eine Anpassung der Konfigura tionen auf die neuen Attribute. Dabei ist zu beachten: cache_timeout und recycle_timeout: Diese beiden Attribute hatten schon lange exakt die gleiche Wirkung, so dass es nur konsequent war, sie durch ein einziges Attribut zu ersetzen. disabled und stopped: Bislang war es möglich, aus den beiden Attributen vier Kombina tionen zu konfigurieren. Allerdings waren stopped und stopped+disabled immer schon äquivalent. Das neue Attribut activation lässt als Werte stopped, disabled und active (Default) zu, wobei nur der erste Buchstabe zählt und groß oder klein geschrieben werden kann. Seite 13 von 26

14 4 Load-Balancing Eine wesentliche Überarbeitung hat auch der Load-Balancer erfahren. Vieles davon geschah unter der Haube. Der Code wurde aufgeräumt und einige nicht unwesentliche Unschönheiten wurden beseitigt. Aber auch an der Oberfläche hat sich etliches geändert. Zum Einsatz von mod_jk mit Load-Balancing und einem Tomcat-Cluster verweisen wir auf den detaillierteren Erfahrungsbericht [4]. 4.1 Balancing-Methoden Es gibt mittlerweile drei Methoden der Lastverteilung auf mehrere Ziel-Worker. Sie werden mit dem At tribut method des Load-Balancer-Workers gesetzt. Dabei wird nur der erste Buchstabe ausgewertet und Groß- und Kleinschreibung sind irrelevant. Requests (Default): der Load-Balancer zählt die Requests, die jeder Ziel-Worker verarbeitet hat und versucht allen Workern akkumuliert gleich viele Requests zu senden. Das Verfahren Requests ist einfach und gibt häufig eine gute Verteilung, insbesondere dann, wenn es keine gute Last-Unterscheidung für verschiedene Requests gibt. Traffic: der Load-Balancer addiert die Anzahl der zwischen Apache und Tomcat verschickten By tes (Summe über beide Richtungen) und versucht diese Zahl für alle Worker akkumuliert gleich zu halten. Das Verfahren Traffic ist besonders geeignet für Bandbreiten-getriebene Verteilung. Busyness: bei dieser Methode wird nicht versucht akkumulierte Last auszugleichen, sondern der Load-Balancer versucht, die Anzahl der gerade in Bearbeitung befindlichen Requests für jeden Ziel-Worker gleich zu halten. Das Verfahren führt also zu einer möglichst gleichmäßigen Par allelität in der Bearbeitung und gleicht automatisch etwa Unterschiede in der Leistungsfähigkeit der Ziel-Tomcats aus. Diese Methode ist neu seit Version Eine aktivierte Stickiness stellt natürlich ein widersprüchliches Ziel zur Last-Verteilung dar. Solange die Anwendung viele Sitzungen hat, deren Nutzungsintensität sich statistisch gleich verteilt, wird man dennoch keine Probleme sehen. Schwierig kann es in Situationen werden, in denen nur wenige Sitzungen existieren, die auch noch sehr unterschiedlich stark frequentiert werden, etwa zu Schwachlastzeiten. Die beiden akkumulierenden Methoden Requests und Traffic haben noch eine weitere Eigenschaft: da Asymmetrien in der Last umso unwichtiger werden, je länger sie zurückliegen, wird der Lastzähler regel mäßig durch 2 geteilt. Damit wird eine gewisse Dämpfung erreicht. Dieses Verkleinern der Lastzähler ge schieht während der globalen Maintenance-Phase (vgl. Abschnitt 4.5). Alle Methoden erlauben es, eine gewünschte Asymmetrie einzustellen. Dies geschieht über das Attribut lbfactor der Ziel-Worker. Vor mod_jk wurde in der Implementierung Floating-Point-Arithme tik eingesetzt. Dies haben wir ab durch ein ganzzahliges Verfahren ersetzt, da Ganzzahl-Arithme tik deutlich schneller ist. Eine weitere Optimierung seit Version betrifft das Lastverteilungsverhalten bei schwacher Last. Bis dahin war es so, dass im Falle von gleichen Lastzahlen immer der gleiche Worker den Request zuge ordnet bekam. Wenn bei sporadischen Requests also etwa alle Lastzähler immer gleich 0 sind, würden alle Requests stets an den ersten Worker gehen. Insbesondere ist dies relevant für die Methode Busyn Seite 14 von 26

15 ess, bei der es besonders leicht vorkommen kann, dass wegen niedriger Last die Lastzahlen bei der Ver teilung von neuen Requests häufig alle gleich 0 sind. Mittlerweile ist der Algorithmus optimiert und wählt jeweils zyklisch den ersten Worker nach dem zuletzt ausgewählten. 4.2 Aktivierungszustand Die Ziel-Worker eines Load-Balancers kennen zwei besondere Zustände, die über die Konfiguration verwaltet werden: disabled und stopped. Ein Worker im Zustand disabled bekommt nur noch Anfragen, die bereits zu einer Sitzung gehören, die auf ihm liegt, und bei eingestellter Stickiness auf ihn weitergeleitet werden müssen. Neue Sitzungen werden jedoch nicht mehr eröffnet. Ein Worker im Zu stand stopped bekommt keinerlei Anfragen weitergeleitet. Vorsicht beim Einsatz von disabled: der Modul mod_jk kann nicht zwischen gültigen also noch existierenden Sitzungen und ungültigen also nicht mehr existierenden Sitzungen unterscheiden. Auch Requests, die ungültige Sitzungen tragen werden im Zustand disabled weitergeleitet. Sie können also durch den Status disabled im Laufe der Zeit dafür sorgen, dass ein Ziel-Worker nur noch einige Sitzungen trägt. Es lässt sich aber nicht komplett verhindern, dass auch neue Sitzungen angelegt werden, z.b. durch alte Bookmarks mit enkodierten Requests, oder alte Cookies. In mod_jk wurde der Fehler beseitigt, dass ein Load-Balancer, der nur einen Ziel-Worker hat, den Zustand disabled nicht korrekt berücksichtigte. Bislang war es möglich, aus den beiden Attributen disabled und stopped vier Kombinationen zu konfigurieren. Allerdings waren stopped und stopped+disabled immer schon äquivalent. Das neue Attribut activation lässt als Werte stopped, disabled und active (Default) zu, wobei nur der erste Buchstabe zählt und groß oder klein geschrieben werden kann. Die alten Attribute stopped und disabled werden in einigen Releases wegfallen. 4.3 Fehlererkennung Zunächst einmal wollen wir beschreiben, was wir hier unter einem Fehler verstehen. Der Modul mod_jk erkennt einen Fehler in der Request-Verarbeitung, wenn es zu einem Kommunikationsfehler mit dem Tomcat gekommen ist. Ein vollständig durchgeführter Request-Response-Zyklus stellt keinen Fehler dar, auch wenn dieser mit einem HTTP-Fehler-Code endet. Typische Fehlersituationen im Sinne von mod_jk sind: der Worker konnte sein Tomcat-Ziel im Netz nicht erreichen (Connect-Fehler) bei der Benutzung einer bestehenden Verbindung zum Tomcat-Ziel ist ein Fehler aufgetreten, meist ein Timeout beim Versuch, den Response an den Client zurückzuliefern, ist ein Fehler aufgetreten, etwa weil der Client die Verbindung bereits geschlossen hatte die maximal erlaubte Anzahl von Verbindungen zum Tomcat-Ziel ist erreicht, so dass der Request nicht mehr zu Tomcat gesendet werden kann ein Load-Balancer-Worker hat nur noch Ziel-Worker, die in einem Fehlerzustand sind, und erzeugt in Folge dessen selbst einen Fehler Seite 15 von 26

16 Neben einer Klarstellung der Defaults und ihrer Bedeutung und der vielen möglichen Timeouts in der mod_jk-dokumentation hat es in zwei Bereichen Anpassungen in den neuen Versionen gegeben: das Verhalten beim Auftreten eines Fehlers in der Kommunikation mit dem Client und der genaue Ablauf von Retries im Load-Balancer. Das schon länger bekannte Attribut recovery_options von Load-Balancer-Workern erlaubt jetzt durch Setzen des Bit 2 das Schließen der Verbindung zum Tomcat, wenn es in der Kommunikation mit dem Client zu einem Fehler gekommen ist. Die zur Zeit setzbaren Bits sind also: Bit 0 (Wert 1): Der Request wird nicht nochmals an einen Tomcat gegeben, wenn nach der er folgreichen Übertragung an einen Ziel-Worker ein Fehler aufgetreten ist. Bit 1 (Wert 2): Der Request wird nicht nochmals an einen Tomcat gegeben, wenn bereits die Headers des Response an den Client gesendet wurden. Bit 2 (Wert 4): Die Verbindung zu Tomcat wird geschlossen, wenn in der Kommunikation mit dem Client ein Fehler aufgetreten ist. Die Werte können additiv konfiguriert werden. Der Default des Attributes ist leider 0. Wir empfehlen für produktive Umgebungen den Wert 3 oder 7. Die ersten beiden Bits sind nötig, wenn man vermeiden möchte, dass durch Retries Transaktionen doppelt ausgeführt werden (doppelte Bestellungen etc.). Das Retry-Verhalten des Load-Balancers wurde in Version insgesamt stark verbessert. Wenn alle Verbindungen des Ziel-Wokers belegt sind, wird zunächst 25 Millisekunden gewartet, bevor erneut ver sucht wird, eine freie Verbindung zu bekommen. Danach wird vor jedem weiteren Versuch doppelt so lange gewartet wie zuvor bis zu maximal 100 Millisekunden. Im Default werden nur 2 Retries versucht, der Wert kann jedoch durch das Attribut retries des Load-Balancers angepasst werden. Retries sollten bei Apache nur auftauchen, wenn man die Größe des connection pools auf einen Wert kleiner als die Anzahl von Threads pro Prozess eingestellt hat. Im Default ist der Wert automatisch gleich der Anzahl der Threads. In der Regel sollte man es beim Default belassen und keine eigene Konfiguration vornehmen. 4.4 Wiederanlauf Ein Ziel-Worker, der bei einer Request-Weiterleitung auf einen Kommunikationsfehler mit seinem Tom cat-ziel stößt, geht in den Zustand Error und bekommt dann vom Load-Balancer keine Anfragen mehr weitergeleitet. In regelmäßigen Abständen werden alle Worker, die sich im Zustand Error be finden, darauf überprüft, ob sie wieder funktionieren (Recovery). Dies geschieht, indem sie einfach wieder Requests vermittelt bekommen. Der Worker geht bei der Überprüfung dann vom Zustand Error in den Zustand Recovering über, wenn seit dem Auftreten des Fehlers mindestens soviel Zeit in Se kunden vergangen ist, wie sein Attribut recovery_timeout angibt (Default: 60 Sekunden). Wenn alle Worker auf Error stehen, gehen sie bei jeder Überprüfung alle sofort in den Zustand Recove ring (Forced Recovery). Der Zustand Recovering bedeutet, dass diese Worker wieder Anfragen bekommen. Sie gehen beim nächsten Request, den die Worker weitergeleitet bekommen sofort wieder über in Error, falls wieder ein Fehler aufgetreten ist, oder in OK, falls der Request erfolgreich bearbei tet wurde. Seite 16 von 26

17 Bis mod_jk war es nicht möglich, das Attribut recovery_timeout auf Werte kleiner als 60 Sekunden zu setzen. Seit ist das Minimum eine Sekunde. Beachten Sie jedoch, dass die Prü fung auf Recovery nicht kontinuierlich geschieht, sondern nur während der global Maintenance, die im Default nur alle 60 Sekunden geschieht (vgl. Abschnitt 4.5). Wenn Sie sicherstellen möchten, dass Reco very schneller geschieht, müssen Sie auch den Wert von worker.maintain nach unten anpassen. Vermeiden Sie jedoch sehr kleine Werte, etwa unterhalb von 10 Sekunden. In Version wurde auch ein Fehler beseitigt, der dafür sorgte, dass Worker, die disabled waren, nie aus einem Error-Zustand in Recovering gingen, sondern bis zum Webserver-Neustart in Er ror blieben. Ein besonderer Trick in der Lastverteilung sorgt in dieser Version ebenfalls dafür, dass Worker, die in Re covering gehen, nicht sofort mit extremer Last konfrontiert werden. Bei den Lastverteilungsmethoden Requests und Traffic werden die Lastzähler über einige Zeit akkumuliert. Ein Worker, der auf Error steht, bekommt keine Last mehr und hätte deshalb Nachholbedarf. Wir setzen deshalb den Lastzähler eines Workers im Zustand Recovering auf den maximalen Lastzähler aller Worker im Load-Balan cer, damit dieser Worker sanft angefahren wird. 4.5 Interne Wartung Die sogenannte Maintenance-Methode im mod_jk hat nichts mit einer Wartung einer Benutzerapplikati on zu tun. Sie wurde für Aufgaben eingeführt, die innerhalb des gesamten Web-Servers nur ab und zu durchzuführen sind. Es gibt eine lokale und eine globale Maintenance. Die lokale Maintenance läuft in einem Prozess dann, wenn er einen Request bekommt, und seit dem letzten Aufruf der lokalen Mainte nance im gleichen Prozess mindestens die Zeit in Sekunden vergangen ist, die im Attribut wor ker.maintain festgelegt wurde (Default: 60 Sekunden). Die lokale Maintenance ist zur Zeit dafür verantwortlich, Verbindungen zwischen dem Webserver und dem Tomcat, die lange Zeit nicht benutzt wurden (connection_pool_timeout) wieder zu schließen. Dies dient dazu, die an den Ver bindungen hängenden Threads auf Tomcat-Seite wieder freizugeben, und ist insbesondere dann nützlich, wenn viele Webserver sich mit einem Tomcat verbinden. Die globale Maintenance läuft dann, wenn ein Request eintrifft und seit der letzten Ausführung der globalen Maintenance in irgendeinem Prozess die Zeit in Sekunden vergangen ist, die im Attribut worker.maintain festgelegt wurde (Default: 60 Sekunden). Zur Zeit werden drei Aufgaben von der globalen Maintenance übernommen Die Dämpfung der Lastzahlen der akkumulierenden Methoden Requests und Traffic (vgl. Ab schnitt 4.1) Die Überprüfung aller Worker, die sich im Status Error befinden, und ob eine Weiterleitung über sie wieder versucht werden soll (Recovery, vgl. Abschnitt 4.4). Das Umsetzen des Status von Workern, die seit der letzten globalen Maintenance keinen einzigen Request abgearbeitet haben von OK auf N/A (not available). Damit soll ausge drückt werden, dass die Funktionsfähigkeit dieses Workers mangels Benutzung nicht sicher ist. Der Status wird im Status-Worker angezeigt (vgl. Kapitel 5). Seite 17 von 26

18 4.6 Inter-Prozess-Kommunikation Die verschiedenen Zustände (OK, N/A, Error, Recovering und Busy) und die vielen StatistikZähler, die der Load-Balancer mittlerweile pflegt, werden auch bei einem Multi-Prozess Webserver von allen Prozessen (und natürlich Threads) gemeinsam genutzt. Dies hat den unmittelbaren Vorteil, dass es nur eine einheitliche Sicht auf die aktuelle Last und die Zustände der Worker gibt. Darüber hinaus kommt es hierdurch auch zu weniger Requests mit Fehlern, da schon ein Request mit einem Fehler den entspre chenden Ziel-Worker für den gesamten Web-Server in den Zustand Error versetzt. Diese gemeinsame Nutzung der Informationen ist durch ein Shared Memory-Segment realisiert. In mod_jk Version wurde die benötigte Größe für diesen Shared Memory deutlich verringert. Wei terhin wurde in der gleichen Version das Locking für die Synchronisierung paralleler Zugriffe wesentlich verbessert. 4.7 Gruppierung und Vervielfältigung Attribut distance Eine neue Fähigkeit seit Version ist die Gruppierung von Ziel-Workern nach Präferenzen. Einige Versionen früher war bereits das Attribut local_worker weggefallen, weil man den Eindruck hatte, dessen Möglichkeiten auch durch den Zustand disabled für die nicht-lokalen Worker ausdrücken zu können. In Wirklichkeit gab es jedoch längst den Bedarf, die durch local_host ausgedrückte Idee weiter auszubauen. Hierfür gibt es jetzt das Attribut distance für die Ziel-Worker eines Load-Balan cers. Requests werden jeweils nur auf die Gruppe von Ziel-Workern verteilt, die zu der kleinsten konfigu rierten Distance gehören, zu der nicht alle Worker im Status Error sind. Das Attribut distance nimmt ganzzahlige Werte entgegen. Der Default ist 0. Häufig gibt es in großen Installationen mehrere Internet-Anschlüsse, die jeweils in eigenen Zellen mit Apache-Webservern enden. Dahinter gibt es dann an den gleichen Standorten jeweils einen TomcatLayer. Im Normalfall sollen nun Anfragen, die bei einem Apache ankommen, am gleichen Standort wei terverarbeitet werden. Nur wenn dort alle Tomcats ausgefallen sind, sollen auch die anderen Standorte angesprochen werden. Hierfür gibt man den lokalen Ziel-Workern den Wert 0, und den anderen den Wert Attribut jvm_route Ein weiterer interessanter Aspekt trat durch einen Administrator auf, der den gleichen Tomcat in ver schiedenen Load-Balancern ansprechen wollte. Jeder Load-Balancer war für einen anderen Kontext zu ständig. Nun hatte er aber Bedarf, die Konfigurationen dieses Workers in den verschiedenen Load-Balan cern unterschiedlich zu setzen (Timeouts). Das war nicht möglich! Und zwar weil der Name des Workers bei Stickiness gleich dem Attribut jvmroute in der Engine-Konfiguration von Tomcat sein muss. Der gleiche Tomcat konnte also nur von einem Worker angesprochen werden, der dann auch nur eine Konfi guration haben konnte. Da die Anwender immer wieder über die verlangte Namensgleichheit der Worker mit der jvmroute bei Stickiness gestolpert sind, gibt es jetzt das neue Attribut jvm_route. Seite 18 von 26

19 Wird das Attribut jvm_route bei einem Ziel-Worker nicht gesetzt, richtet sich seine Stickiness nach wie vor nach seinem Namen. Wird jedoch das Attribut jvm_route verwendet, dann bestimmt dieses, welche Anfragen an den Worker sticky gesendet werden. Damit wird es nicht nur möglich, den gleichen Tomcat mit unterschiedlichen Konfigurationen anzusprechen. Viele Konfigurationen können mit Hilfe des Attributes auch einfacher und logischer aufgebaut werden. Seite 19 von 26

20 5 Der Status-Worker Schon seit einigen Versionen gibt es den Status-Worker. Er erlaubt es, insbesondere bei Verwendung von Load-Balancern sehr schöne Einblicke in den Zustand von mod_jk zu bekommen. Der Status-Worker wurde weiter ausgebaut und wird auch in zukünftigen Versionen weitere neue Möglichkeiten bekommen. Als kleinen Appetithappen zeigen wir hier einen Screenshot des aktuellen Status-Workers: Seite 20 von 26

21 Sehr viele Attribute von Workern können durch den Status-Worker im laufenden Betrieb verändert werden. Dies funktioniert ohne Neustart des Webservers. Das ist deshalb möglich, weil der Status-Wor ker das gleiche Shared Memory-Segment nutzt wie der Rest von mod_jk. Allerdings sind Änderungen, die durch den Status-Worker vorgenommen werden nicht persistent! Sie werden nicht abgespeichert und sind nach einem Neustart nicht mehr vorhanden. Mit Hilfe des Status-Workers können alle neueren Attribute bereits dynamisch gemanagt werden. Für viele ältere Attribute wird diese Möglichkeit in den nächsten Releases Zug um Zug geschaffen werden. Der Status-Worker gibt Ihnen viele Einblicke in Laufzeit-Zustände. Bei Ziel-Workern von Load-Balancern kann man deren Zustand (OK, N/A, Error, Recovering, Busy), Zugriffs- und Fehlerzähler und Lastzahlen sehen und z.b. auch, wie lange es noch dauert bis ein Error-Worker auf Recovering geht. Wir möchten Ihnen einen Blick in den Status-Worker sehr ans Herz legen. Auch wenn dieses Doku ment kein Tutorial sein soll, geben wir hier kurz die dafür nötige Konfiguration wieder: wo r k e r. l i s t = j k s t a t u s wo r k e r. j k s t a t u s. t y p e = s t a t u s wo r k e r. s t a t u s. m o u n t = / j k - st a t u s Sie sollten natürlich in produktiven Umgebungen den Zugriff auf die hier für den Status-Worker verwendete URL /jk-status mit einem Zugriffsschutz versehen. Diesen muss der Webserver realisieren. Der Status-Worker kennt keine Benutzer. Seit Version kennt der Status-Worker den Request-Parameter refresh, der eine Sekunden-An zahl als Wert hat und dafür sorgt, dass der Browser die Anzeige regelmäßig aktualisiert. In haben wir hierfür ein kleines Formular im Status-Worker untergebracht. Um die Fehlergefahr im Zusammenspiel zwischen Browser und Status-Worker zu verringern, wird seit Version nach einem schreibenden Zugriff auf den Status-Worker ein Redirect auf die Grundanzeige durchgeführt, damit ein späteres Reload im Browser nicht zu einem erneuten Ausführen des schreibenden Zugriffs führt. Zuletzt noch ein kleiner Tipp: der Status-Worker listet auch die URL-Mappings für die Worker. Diese sind jedoch vom angesprochenen virtuellen Server abhängig. Rufen Sie also den Status-Worker über einen ad ministrativen virtuellen Server auf, sehen Sie zwar alle Worker und deren Zustände korrekt, aber die URLMappings werden typischerweise leer sein, da Sie meist nicht in den administrativen virtuellen Server aufgenommen werden. Seite 21 von 26

22 6 Logging Sehr spannende neue Möglichkeiten gibt es im Logging von mod_jk. Bislang war es nur schwer möglich, zu verfolgen, über welche Worker Requests weitergeleitet wurden. Dies war bislang laut Dokumentation nur über ein mod_jk-eigenes Request-Log möglich. Im Zusammenspiel mit einem Load-Balancer ergab sich aber das enttäuschende Ergebnis, dass stets der Load-Balancer ausgegeben wurde und nicht der eigentlich interessante Ziel-Worker. Eine weitere, bislang nicht dokumentierte Variante, wurde jetzt stär ker ausgebaut. Wir nutzen nun seit Version eine Apache-interne Struktur, die Notes-Tabelle, um während der mod_jk-verarbeitung Arbeitsergebnisse abzulegen. Aus dieser Tabelle kann man dann mittels des Stan dard-moduls mod_log_config Daten auswählen und über das LogFormat in das access-log aufnehmen. Hier eine kleine Tabelle dazu, welche Notes zur Zeit verfügbar sind: Note JK_WORKER_NAME Name des durch das URI-Mapping ausgewählten Workers JK_WORKER_TYPE Typ des durch das URI-Mapping ausgewählten Workers JK_REQUEST_DURATION Request-Verarbeitungsdauer. Zur Zeit nur funktional in Kom bination mit einem definierten JkRequestLogFormat JK_LB_FIRST_NAME Load-Balancer: Name des ersten versuchten Ziel-Workers JK_LB_FIRST_TYPE Load-Balancer: Typ des ersten versuchten Ziel-Workers JK_LB_FIRST_ACCESSED Load-Balancer: Zugriffszähler des ersten versuchten Ziel-Wor kers JK_LB_FIRST_READ Load-Balancer: An Tomcat gesendete Bytes des ersten ver suchten Ziel-Workers JK_LB_FIRST_TRANSFERRED Load-Balancer: Von Tomcat empfangene Bytes des ersten versuchten Ziel-Workers JK_LB_FIRST_ERRORS Load-Balancer: Fehlerzähler des ersten versuchten Ziel-Wor kers JK_LB_FIRST_BUSY Load-Balancer: Anzahl parallel in Bearbeitung befindlicher Requests auf dem ersten versuchten Ziel-Worker JK_LB_FIRST_ACTIVATION Load-Balancer: Aktivierungszustand des ersten versuchten Ziel-Worker JK_LB_FIRST_STATE Load-Balancer: Laufzeitzustand des ersten versuchten ZielWorker JK_LB_LAST_NAME Load-Balancer: Name des letzten versuchten Ziel-Workers JK_LB_LAST_TYPE Load-Balancer: Typ des letzten versuchten Ziel-Workers JK_LB_LAST_ACCESSED Load-Balancer: Zugriffszähler des letzten versuchten ZielWorkers Seite 22 von 26 Description

23 Note JK_LB_LAST_READ Description Load-Balancer: An Tomcat gesendete Bytes des letzten ver suchten Ziel-Workers JK_LB_LAST_TRANSFERRED Load-Balancer: Von Tomcat empfangene Bytes des letzten versuchten Ziel-Workers JK_LB_LAST_ERRORS Load-Balancer: Fehlerzähler des letzten versuchten Ziel-Wor kers JK_LB_LAST_BUSY Load-Balancer: Anzahl parallel in Bearbeitung befindlicher Requests auf dem letzten versuchten Ziel-Worker JK_LB_FIRST_ACTIVATION Load-Balancer: Aktivierungszustand des letzten versuchten Ziel-Worker JK_LB_FIRST_STATE Load-Balancer: Laufzeitzustand des letzten versuchten ZielWorker Hier ein kleines Beispiel für ein sehr ausführliches Log-Format: Lo g F o r m a t "% h %l %u %t \ " % r \ " %> s %b \" % { R e f e r e r } i \ " \ " % { U s e r - Ag e n t } i \ " %{ J K _ W O R K E R _ N A M E } n %{ J K _ W O R K E R _ T Y P E } n %{ J K _ R E Q U E S T _ D U R A T I O N } n % { J K _ L B _ F I R S T _ N A M E } n %{ J K _ L B _ F I R S T _ V A L U E } n %{ J K _ L B _ F I R S T _ A C C E S S E D } n %{ J K _ L B _ F I R S T _ E R R O R S } n % { J K _ L B _ F I R S T _ B U S Y } n %{ J K _ L B _ F I R S T _ S T A T E } n %{ J K _ L B _ L A S T _ N A M E } n %{ J K _ L B _ L A S T _ V A L U E } n %{ J K _ L B _ L A S T _ A C C E S S E D } n %{ J K _ L B _ L A S T _ E R R O R S } n %{ J K _ L B _ L A S T _ B U S Y } n %{ J K _ L B _ L A S T _ S T A T E } n " jk _ v e r b o s e Neu in Version ist jetzt die lange vermisste Möglichkeit des Einsatzes eines Piped Loggers für das mod_jk-logfile. Sie können jetzt im Wert der Direktive JkLogFile ganz genau wie auch bei CustomLog einen String angeben, der mit einem Pipe-Zeichen beginnt. Dann wird das Log durch diese Pipe ge schrieben (Beispiel: rotatelogs). Für Apache 2.0 war dies schon lange möglich. Im Zuge dieser Neuerung wurden auch einige Fehler im Logging beseitigt, die zur Folge hatten, dass bis zu Version korrupte Logzeilen im Logfile auftauchen konnten und unter Last sehr häufig die Log zeilen nicht in chronologischer Reihenfolge ausgegeben wurden. Für alle Webserver gibt es jetzt auch einen Default-Loglevel, nämlich info. Sie müssen jetzt also die Direktive JkLogLevel info nicht mehr angeben. In allen Logzeilen erscheint außerdem zusätz lich die Prozess-ID und die Thread-ID. Hier eine Beispiel-Zeile mit den hervorgehobenen neuen IDs: [S u n Se p : 2 3 : ] [ : ] [d e b u g ] si z e = fr e e = ad d r = 0 x 2 a 9 9 a do _ s h m _ o p e n : : j k _ s h m. c (3 2 7 ) : I n i t i a l i z e d s h a r e d me m o r y Diese Angaben helfen dabei, Fehlermeldungen anderen Zeilen im Apache Error-Log zuzuordnen. Beim Starten des Webservers werden seit Version alle Attribute der Konfiguration, die mittlerwei le abgekündigt (deprecated) sind, als Hinweis ausgegeben (vgl. Abschnitt 3.3). Dies erleichtert die rechtzeitige Umstellung von Konfigurationen. Seite 23 von 26

24 7 Sonstiges Einige weitere Änderungen wollen wir an dieser Stelle auch auflisten. Sie betreffen jedoch einzelne unzu sammenhängende Details. Wir listen sie hier deshalb nur der Vollständigkeit halber auf. Die neue Option DisableReuse schaltet die Verwendung persistenter Verbindungen ab. Jeder Request baut bei der Weiterleitung eine neue Verbindung zu Tomcat auf. Die Option ist im Default abgeschaltet und wird mittels JkOptions +DisableReuse aktiviert. Diese Option wirkt sich stark negativ auf die Performance aus und ist als akuter Workaround für den Fall gedacht, dass es zu Problemen mit Firewalls zwischen Apache und Tomcat kommt. Bei sol chen Problemen sollte aber zunächst das Worker-Attribut socket_keepalive in Zu sammenhang mit einer korrekten Konfiguration des TCP-Stacks auf dem Apache-Server einge setzt werden. Das neue Attribut max_packet_size für Worker vom Typ AJP13 vergrößert die Pakete, in denen mod_jk die Request-Headers an Tomcat sendet. Diese sind im Default 8KB groß, was etwa bei der Weiterleitung von Client-Zertifikaten inklusive Zertifikatsketten zu Problemen füh ren kann. Das Attribut ist noch experimentell und mit Absicht noch nicht dokumentiert. Es kann nicht ohne Anpassungen am Tomcat-Connector eingesetzt werden (neues Attribut packetsize). Ein weiteres neues Attribut connection_pool_minsize erlaubt es, festzulegen, wie viele Verbindungen im Verbindungspool zwischen einem Worker und Tomcat bestehen bleiben sollen, obwohl sie lange Zeit unbenutzt waren. Der Default ist die halbe Pool-Größe. Seit Version war die Erkennung von Fehlern beim Versenden von Antworten an Clients fehlerhaft. Das hatte zwar die angenehme Folge, dass es weniger Fehlermeldungen im mod_jklogfile gab und kaum noch Broken Pipe-Exceptions in den Tomcat-Logfiles auftraten, aber leider konnten auch Servlets nicht mehr erkennen, ob die Kommunikation zum Client überhaupt noch bestand. Dieser Fehler ist seit wieder beseitigt. In der Dokumentation wurde jetzt klargestellt, dass auch die Zeichen Minus - und Unterstrich _ als Bestandteile von Worker-Namen zugelassen sind. Seite 24 von 26

25 8 Zusammenfassung Der Modul mod_jk hat sich in diesem Jahr wesentlich weiterentwickelt. Neben vielen Bug-Fixes haben sich seine Fähigkeiten vor allem in folgenden Bereichen verbessert Load-Balancing Status-Worker Logging Konfigurationsflexibilität Kombination von mod_rewrite und mod_jk Damit hat mod_jk nach wie vor viele Vorteile gegenüber der aktuellen Implementierung von mod_proxy. Je nach Skill-Level in den verschiedenen IT-Bereichen Server und Netze stellt mod_jk sogar eine ernst hafte Alternative zu Load-Balancer-Appliances dar. Seite 25 von 26

26 9 Literaturhinweise [1] [2] [3] [4] Rainer Jung, Peter Roßbach: Mission Possible. Apache und Tomcat-Cluster im Einsatz, in Java Magazin [5] Rainer Jung, Peter Roßbach: Kater unter Last. Skalierbare Services: Neue Möglichkeiten der Last verteilung durch mod_jk , wird erscheinen in Java Magazin [6] Rainer Jung, Peter Roßbach: Fortsetzung von [5], wird erscheinen in Java Magazin Seite 26 von 26