Version: GSB 7Umsetzung

Zur Umsetzung der obigen Strategien ist die Weiterleitung der Requests vom Apache an die zugehörigen Tomcats von zentraler Bedeutung. Der Webserver Apache verfügt derzeit mit den Modulen

• mod_proxy
• mod_jk

zwei unterschiedliche Module, mit deren Hilfe die Tomcat-Apache Kopplung definiert werden kann. Bei der Untersuchung möglicher Umsetzungsalternativen sind folgende Fragenstellungen von besonderer Bedeutung:

• Verteilung von Anfragen auf unterschiedliche Tomcats
• Session Replication
• Wechsel des verwendeten Generator-Caches
• Trennung von Generator und Indexer
• Erstellung mandanten-spezifischer Indices

Die oben genannten zentralen Fragenstellungen werden im folgenden auf Basis der beiden verfügbaren Apache Module mod_jk und mod_proxy diskutiert.

Basis: Apache-Modul mod_proxy

Im gegenwärtig aktuellen GSB Release wird zur Tomcat/Apache-Anbindung standardmäßig das Modul mod_proxy verwendet. Das Modul mod_proxy ist gut dazu geeignet, Anfragen an den Apache an beliebige nachgelagerte WebServer, ServletContainer, ApplicationServer etc. weiterzuleiten, indem der Apache als Proxy-Server fungiert.

Zur Tomcat/Apache-Anbindung werden für jeden Mandaten ein oder mehrere so genannte VirtualHost-Eintrage generiert, die zu den vom jeweiligen Mandanten verwendeten im globalen DNS offiziell eingetragenen Hostnamen, wie z.B. http://www.mandant.de und http://mandant.bund.de korrespondieren.

Verteilung von Anfragen

Innerhalb eines jeden Virtualhosteintrages des Apaches wird ein fester Tomcat konfiguriert, der für den entsprechenden Hostnamen eingehende Requests bearbeitet. Es ist also möglich, sogar innerhalb eines Mandanten, für unterschiedliche Hostnamen, unterschiedliche Tomcats anzusprechen. Dies trifft allerdings lediglich auf den ersten Request, den ein Internet-User auf einen Hostnamen eines GSB-Mandanten absendet im vollen Umfang zu. Dadurch dass nämlich alle internen http-Links auf der Site mit einem festen Hostnamen, wie er im CoreMedia-Repository im Dokument

/Sites/MANDANT/SiteGlobals/_config/ServerFQHN

hinterlegt wurde, dargestellt werden, werden alle nachfolgenden, durch einen Klick auf einen Link ausgelösten Requests an diesen festen Hostnamen gesandt, so dass hier keine echte Lastverteilung innerhalb eines Mandanten stattfinden kann.

Es ist außerdem nicht möglich, die einmal festgelegten Tomcats ohne Umkonfiguration und Neustart des Apaches auszutauschen. Falls also ein Tomcat ausfallen sollte, so muss dies durch externe Tools festgestellt und der Apache durch manuellen Eingriff oder entsprechende Skripten umkonfiguriert und durchgestartet werden.

Session Replication

Eine Session Replication ist mit dem Apache Modul mod_proxy wahrscheinlich möglich bzw. theoretisch denkbar. Zur Session Replication wird in der allgemeinen Praxis derzeit allerdings ausschließlich das Modul mod_jk eingesetzt. Unseres Wissens nach existieren derzeit keine nennenswerten Erfahrungen oder gezielte Aktivitäten in der Apache Community das Apache Modul mod_proxy in der Apache 2.0.x Serie für einen derartigen Einsatz zu erweitern.

Basis: Apache-Modul mod_jk

Das Apache-Modul mod_jk ist im Vergleich zum Modul mod_proxy ein relatives neues Modul, das mit der aktuellen Version 1.2.12 einen stabilen Zustand erreicht hat.

Das Modul mod_jk ist speziell dazu gedacht, den ServletContainer Tomcat insbesondere in den Versionen 5.0.x/5.5y an den Apache anzubinden. Durch diese Spezialisierung ist es dem Apache beispielsweise möglich, Annahmen über das Format der SessionID des Tomcats zu treffen und so den Tomcat auf seinen Verfügbarkeit hin zu überprüfen. Mit dem Modul mod_jk kann darüber hinaus ein spezifisches, binäres Kommunikations-Protokoll (AJP=Apache Java Protocol) verwendet werden, das einen Performancegewinn gegenüber der Weiterleitung per mod_proxy ermöglicht.

Verteilung von Anfragen

Im Gegensatz zum Apache-Modul mod_proxy ermöglicht es das Modul mod_jk , auf Basis des Webservers, also unabhängig vom Loadbalancer, Anfragen dynamisch über mehrere Tomcats zu verteilen. So ist es z.B. möglich, für jeden Tomcat, der durch das Modul mod_jk bedient wird, einen Backup-Tomcat zu konfigurieren, der beim Ausfall/Herunterfahrens des primären Tomcats angesprochen wird.

Ebenso ist es möglich, im laufenden Betrieb dynamisch einen Tomcat von der Lastverteilung durch den Apache komplett auszunehmen, oder sogar die Erzeugung neuer Sessions auf einem gegebenen Tomcat zu verhindern. Dies kann über die mod_jk-Manager-Konsole, die In der im letzten Kapitel beschriebenen Konfiguration unter www.mandant.de/jkmanager erreichbar ist geschehen. WICHTIG ist, dass in dieser Konfiguration der Zugriff auf diese Applikation per Passwort geschuetzt werden muss!!

Falls die Erzeugung neuer Sessions auf einem Tomcat unterbunden wird, werden Anfragen, die nicht innerhalb einer bereits auf dem Tomcat existierenden Session gesendet wurden, an den entsprechenden Tomcat nicht weitergeleitet sondern von seinem Backup-Tomcat beantwortet. Dies ermöglicht Tomcat-Aktualisierungen, die für den Internet-User vollkommen transparent sind, indem

• seitens mod_jk die Erstellung neuer Sessions auf dem zu aktualisierenden Tomcat unterbunden wird; Requests aus vorhandenen Sessions werden weiterhin an den Tomcat geleitet
• gewartet wird, bis alle Sessions auf dem Tomcat ausgelaufen sind; gegenwärtig werden Sessions bei längerer Inaktivität des Users invalidiert; falls ein User allerdings regelmäßig Requests innerhalb seiner Session absendet, kann die Lebensdauer beliebig lang werden; zur besseren Analyse/Management der Sessionverwaltung ist evtl. eine separate JMX-Konsole, wie z.B. MC4J zu verwenden, da die Standard-Manager-Applikation lediglich die Anzahl der aktiven Sessions anzeigt, explizites Invalidieren, Analyse der Session-Attribute etc. lassen sich nur durch eine separate Überwachung per JMX erreichen
• die Aktualisierung inkl. Tomcat-Restart, CacheWarmup durchgeführt wird
• der Tomcat seitens des mod_jk wieder in die Lastverteilung aufgenommen wird

Ohne diesen Update-Mechanismus gehen die aktuellen Sessions des Tomcats verloren, was dazu führt, dass bereits angemeldete Benutzer sich erneut, allerdings auf einem anderen Tomcat authentifizieren müssen und evtl. in der Session gespeicherte Suchergebnisse, mehrseitige HTML-Formulardaten etc. verloren gehen. Für weitere Informationen zur mod_jk-Administration siehe http://tomcat.apache.org/connectors-doc.

Session Replication

Session Replication im Tomcat ist nach aktuellem Stand der Technik zwar über das Modul mod_jk zu erreichen, allerdings sind hierzu einige Besonderheiten zu beachten. In der einschlägigen Fachliteratur wird dieses Feature insbesondere in der Tomcat 5.0 Serie als noch nicht vollständig ausgereift klassifiziert. Derzeit konzentriert sich die aktuelle Tomcat-Entwicklung auf den Tomcat 5.5 mit gelegentlichen Updates/Bugfixes des Tomcat 5.0, so dass mit einer vollständigen und stabilen Implementierung im Tomcat 5.0.x leider nicht zu rechnen ist.

Die Version Tomcat 5.5 jedoch wird nach Aussage des Supports von CoreMedia vom 21.03.2005 in naher Zukunft nicht freigegeben.

Insgesamt erscheint es gegenwärtig daher nicht empfehlenswert, Sessions im GSB-Context über mehrere Tomcats zu replizieren.

Bei der (ggf. späteren) Einführung von replizierten Sessions wären unter anderem folgende Maßnahmen an Mandanten-Modulen und der Netzwerk-Infrastruktur notwendig:

• Anpassung sämtlicher JSPs/Java-Klassen an die neuen Mechanismen der Session-Replication. Insbesondere ist dabei sicherzustellen, dass nur serialisierbare Java-Objekte innerhalb einer Session gespeichert werden.
• Aufbau von Multicast-Gruppen auf Netzwerkebene, da zur Replikation der Sessions Multicast-Messages der Tomcats innerhalb einer Domain ausgetauscht werden
• Intensive Kontrolle der Größe der in der Session abgelegten Objekte, um zum einen den notwendigen Netzwerkverkehr zur Replikation zur minimieren. Zum anderen zeigen erste Evaluationen, dass es bei Speicher-intensiven Session-Objekten leicht zu OutOfMemoryExceptions kommen kann, wenn ein neuer Tomcat zu einer Domain hinzugefügt und wird, da beim Startup alle bereits existierenden Sessions initial auf den neuen Tomcat repliziert werden müssen.