Tomcat im Cluster

[Dietmar Müller]

Hallo Liste,

ich (bzw. meine Firma) betreibt einige Seiten erfolgreich mit Tomcat 5.5.7
mit Apache 2.0.53 und jk 1.2.8.

Ich habe vor kurzem von jk2 mit 5.0.18 auf jk mit 5.5.7 migriert und bin
von der neuen Version begeistert.

Um die stabilität unserer Anwendung zu erhöhen, habe ich mir jetzt einen
kleinen Cluster in unserer Testumbegung aufgebaut. (ähnlich wie Peter es
in der Columne macht). Prinzipiell sieht es sehr gut aus aber es haben
sich hier einige Fragen ergeben:

-->
im Buch "Professional Apache Tomcat5" (Wrox) ist eine Cluster mit jk2
aufgebaut und es werden Varianten mit Sticky- und ohne Sticky Sessions
dargestellt.
Da ich mir noch nicht vom Vorteil der Sticky Session im klaren bin
hab ich versucht die Umgebung ohne jvmRoute aufzubauen. Leider nimmt
Tomcat keine Requests entgegen, wenn der Eintrag jvmRoute nicht
konfiguriert ist. Es wird auch keine Meldung an der Konsole ausgeworfen.
Funktioniert jk mit und ohne StickySession? und wie sieht es dann mit
den jk2 Parametern StickySession bzw. Route aus?
Im SourceCode scheint mir diese Route doch sehr essenziell für die
Replikation zu sein!

Wenn ich ohne StickySession arbeite, dann müßte ich unter <Sender..
replicationMode synchronous oder pooled einstellen, so daß sichergestellt
ist, daß alle Sessiondaten sofort repliziert werden?

-->
in der Servlet 2.4 Spez. ist zu lesen, daß in der web.xml distributeable
zu setzten ist, wenn die Applikation im Cluster läuft! Leider ist dies
im balancer - Beispiel der Distro nicht der Fall. Inwieweit hat dieses
beim Tomcat Auswirkungen oder wird eh implizit durch das Replizieren
die NotSerializableException geschmissen?

-->
wie sieht es mit dem Session Manager aus. In der def. Konfiguration
(nicht geclustert) werden beim Shutdown die Sessions der App ins Filesystem
geschrieben. Ist dies beim Cluster auch der Fall und weiters, wird
dann nur mehr das Delta (die neuen Sessions und die inzwischen geänderten
Sessions) abgeglichen oder werden in diesem Fall alle Sessions neu
abgeglichen?

-->
Ich starte meinen Tomcat mit einem ServiceWrapper. Leider gibt es hier noch
ein kleines Problem und erst mit einem Timeout von 20 Sekunden wird der
Tomcat niedergefahren. Der Context wird aber sofort beendet und bis die
20 Sekunden vorbei sind sieht jk den Tomcat als lebendig und als Folge werden
alle Sessions (mit Sticky) die dieser Node zugeordnet sind weiter an diese
Node geleitet und mit einem 404 abgefertigt. Wie wird erkannt ob der Node aktiv
ist und weiters wie kann man einen aktiven Tomcat für jk dekativieren, sodaß
man erst dann den shutdown beginnt?

-->
Aufgrund meines Applikationsdesigns verwende ich statische Varibalen zum
protokollierens meiner Requests. Diese Daten werden dann aufgrund von einem
sessionDestroyed Event in die DB gespeichert.
Wird der Event dann an (in) allen Nodes geschnissen oder nur an der Node auf
der die Session zuletzt war?

Ich wäre (wie immer) für jeden Tip dankbar.
Hab zwar schon viele Zeilen vom Tomcat / Cluster Code gelesen, aber
konnt nicht alle Antworten finden.

lg Dietmar

[Dietmar Müller]

Nachtrag:

--> start von einer Node ohne jvmRoute geht doch. Muß ein Konfigurationsfehler gewesen sein.

--> habe jetzt eine Doku gefunden bei der der Parameter sticky_session (für jk) beschrieben steht. Bin beim evaluieren.

lg Dietma

[PRossbach]

Hey Dietmar,

da hast du aber viele Fragen:

a) Stickysession solltest du machen damit nich so einfach Inkonsistenzen vorkommen können. Die Replikation im Cluster sicher nur einen Ausfall eines Knotens ab.
b) Schau Dir das 5.5.9 Release an, dort habe ich wichtige Erweiterungen im Cluster realisiert. Es gibt nun einen weiteren Async Mode "fastasyncqueue". Ich habe erhebliche Erweiterungen der MBeans gemacht die Dir wertvolle über die Arbeitsweise des Clusters iefern.
c) Wenn Du Ernst im Cluster machen möchtest, muss Du den fastasyncqueue Mode nehmen. Nur diese Modus realisiert das Clustering als echtes sekundär Eigenschaft, wenn die Server mal richtig unter Last geraten.
d) Nutze das jk 1.2.9 hier haben wir entlich wieder ein Status Seite auf Seiten des Apache integiert. Sogar während der Laufzeit können damit Knoten aus dem Betrieb gehen. Ich habe im 5.5.9 dafür einen entsprechend Ant Task geschieben JkStatusUpdateTask.

Pete

[Dietmar Müller]

Danke Peter für Deine Nachricht.

Hast Du eine binary für jk 1.2.9 für Apache2 / 2.0.53 / Win32 da im Download nur 1.2.8 ist und ich nicht so fit mit dem C - Compiler bin?

Zur Info: Ohne Sticky Session rennt jk 1.2.8 nicht stabil.

Wie ist es mit den SessionListeners? Werden die Events an allen Konten gefeuert?

Danke und lg Dietma

[Dietmar Müller]

Danke Peter für Deine Nachricht.

Habe mir jk1.2.9 gebaut und geladen. Sieht sehr gut aus und die Funktionen scheinen gut zu sein.

Danke für Dein Mail in der Usergroup:
http://marc.theaimsgroup.com/?l=tomcat-dev&m=110847441418653&w=2

Ist es so geplant, daß die Aktualisierungen (status vom Node) erst nach einem Request gemacht werden? Ich glaubte zu lesen oder zu hören, daß jk periodisch einen Ping an ajp sendet. Und wenn dies so ist, warum hat man nicht diese Informationen für den Status der Node genommen? (Quelle: Doku Tomcat: Advanced worker directives,....)

Zur Info: Ohne Sticky scheint jk 1.2.8 nicht stabil zu arbeiten?
Habe einige 500 er bekommen die mir nicht klar waren.

Wie ist es mit den SessionListeners? Werden die Events an allen Konten gefeuert?

Danke und lg Dietma

[PRossbach]

Hi,

a) Die Konfiguration der worker im mod_jk solltest Du für ein Operatives System noch mit den Parameter cachesize und cache_timeout ergänzen. Diese Parameter sind unter Windows und im Apache (worker MPM) für den Durchsatz und Steuerung der Tomcat Threads entscheidend.

b) Das mit den Fehler ohne Sticky Session ist seltsam, aber ich habe das auch schon beoachtet. Hast Du dafür einen einfachen Test? Ich habe die Vermutung, dass etwas schiefgeht wenn man
im Stateless Mode trotzdem Cookies/URLParameter sendet.

c) Noch ist es so, dass die Session start/stop Events auf allen Knoten gesendet werden. Mit notifyListenersOnReplication="false" im Cluster Element, unterdrückt man nur die Attribute Change Events. Eine Veränderung wäre vermutlich sinnvoll. Du kannst aber an der SessionID <id>.<jvmRoute> ableiten, ob die Session vom Primärknoten ist oder nicht. Allerdings bei einem Failover kann diese Unterscheidung problematisch werden. Vielleicht schreibst Du für Deine Statistiken lieber ein Valve, der sich dann bei neuen Session registiert und bei den Event Zugang zu dem internen Tomcat API der Sessions hat.

d) Das mod_jk kann seit 1.2.6 vor einem Request ein Ping senden. Damit wird sichergestellt, dass der Knoten erreichbar ist. Dies macht man meist wenn der Tomcat ziemlich weit entfernt, evtl an durch eine Wählleitung angebunden ist oder die Verfügbarkeit fraglich ist.

e) Der Status des mod_jk 1.2.9 wird nach dem Versuch einen Request an den Tomcat zu schicken aktualisiert. Mehr gibt das AJP 1.3 nicht her, aber es sind Planung für ein AJP 1.4 angelaufen.

f) Für das nächste Release werde ich die Cluster Doku schreiben.
Reviewer/Übersetzer gesucht.

g) Dreh mal die Loglevel des Cluster auf org.catalina.org.cluster=DEBUG dann wirst Du jede Menge weitere Informationen über die Arbeitsweise des Clusters bekommen. ( Auf der CD zur TomC@ Kolumne 02/05 müßte ein entsprechendes Log4j Template liegen:-))

h) Wenn eine Anwendung distributable ist, wird dieser Anwendung ein Cluster Sessionmanager untergeschoben. Die Sessions bleiben nur solange erhalten bis der letzte Knoten/Anwendung aktiv ist. Wenn alle aktiven Knoten runtergefahren werden sollen, mußte Du halt vorher einen anderen Knoten hochfahren der die Sessions für die wirklich aktiven Knoten vorhält. Vorsicht mit udpates der Anwendung in einem solchen Fall kann es häßlichen Fehler kommen.

i) Starte die Konten in einem Cluster immer hintereinander, und warte bis die Initialisierung der Anwendung wirklich abgeschlossen ist. Der Java Service Wrapper ist super, aber in einem Cluster kann ein Failover eines Knotens schnell zu einem Dominospiel werden!

Pete

[Dietmar Müller]

Hallo Peter,

vorerst einmal Danke für Deine ausführliche Antwort.

lg Dietma

[PRossbach]

Gern geschehen
und ich hoffe sehr es hilft einwenig.
Pete