Das Clustering zur Replikation von Session-Daten ist seit geraumer Zeit im Umfang von Tomcat enthalten. Dabei durchlief die Lösung diverse Iterationen, die sich auch durch geänderte Konfigurationselemente bemerkbar machten. Mit der Version 6 hat sich Tomcat in diesem Bereich stark verändert, insbesondere im internen Aufbau. Dieser Artikel gibt einen Überblick über die geänderten Strukturen, Funktionalitäten, und Konfigurationsparameter.

Auf den ersten Blick erscheint der Cluster des Tomcat 6 im Vergleich zu seinen Vorgängern nur unwesentlich verändert. Dies ist darauf zurückzuführen, dass die größte Veränderung eine Aufteilung der Codebasis ist. Die zuständigen Codeteile für Replikation und Kommunikation wurden voneinander getrennt. Der Teil für die Kommunikation im Cluster wurde in ein neues Framework ausgegliedert. Dieses hat den Namen „Tribes" und wird zusammen mit Tomcat ausgeliefert. Näheres dazu finden Sie im weiteren Verlauf dieses Artikels.

Die für die Replikation zuständigen Programmteile wurden zudem in ein anderes Java-Package mit dem Zusatz ha (für High Availability) verschoben. Die erste, offensichtliche Änderung ist folglich, dass alle am Cluster beteiligten Komponenten nun andere Namen haben oder aber zumindest andere Package-Pfade enthalten.

Tribes

Tribes ist als reines Framework für Cluster-Verbünde ausgelegt. Es erweitert die Funktionalität der für die Kommunikation im Cluster zuständigen Komponenten, die bisher direkter Bestandteil von Tomcat waren. Folglich stellt es den bekannten Multicasting-Mechanismus zur Cluster-Bildung zur Verfügung.

Abb. 1: Übersicht über den Aufbau der Komponente „Channel".

Der Versand von Nachrichten innerhalb des Clusters wird nun ebenfalls von Tribes abgedeckt. Tribes definiert somit, wie die Daten im Cluster ausgetauscht werden. Organisatorisch ist es so, dass Tomcat in seiner Cluster-Konfiguration nun einen Channel definiert, der den Versand der Nachrichten regelt. Abbildung 1 zeigt einen Überblick über die hierfür von Tribes zur Verfügung gestellten Komponenten.

Channel

Wie sich erkennen lässt, ist der Channel eine in sich geschlossene Einheit mit 4 Unterelementen. Der Channel definiert die im Cluster für den Nachrichtenaustausch gültige Versandart. Es kann zwischen synchronem und asynchronem Versand ausgewählt werden.

Beim asynchronen Versand wird die Bearbeitung des Requests fortgesetzt, während die Replikation im Hintergrund noch läuft. Die Replikation wird daher zwar nicht 100%ig zugesichert, hat aber so auch nur einen geringen Einfluss auf die Antwortzeit der Anwendung.

Bei Bedarf kann der asynchrone Versand durch eine Empfangsbestätigung abgesichert werden. Beim Ausbleiben der Bestätigung wird die Replikation erneut angestoßen.

Das Membership-Element hat sich im Vergleich zu den Vorgängern nicht verändert. Es wird auch weiterhin eine gemeinsame UDP-Multicast-Adresse definiert, über welche die Cluster-Mitgliedschaft von jedem Knoten publiziert wird.

Neues Messaging

Das Empfänger- (Receiver-) und Sender-Elementpaar steuert auch weiterhin den eigentlichen Datenaustausch. Neu ist hier die Möglichkeit des Senders, mehrere Nachrichten gleichzeitig an mehrere Empfänger zu senden. Die Tribes-Dokumentation spricht in diesem Zusammenhang vom „Parallel Concurrent Messaging". Hierfür gibt es nun am Sender und Empfänger zusätzliche Attribute zur Dimensionierung, um je nach Versandart ausreichende Threads für den gleichzeitigen Versand bzw. Empfang bereitzustellen.

Interceptors

Ein neues Konzept im Tomcat 6 Cluster sind die Interceptors innerhalb des Channels. Diese ermöglichen die Bewertung und Manipulation von Nachrichten vor dem Versand oder nach dem Empfang. Ein Beispiel ist der Interceptor vom Typ TcpFailureDetector. Bei einem Ausbleiben des UDP-Heartbeats eines Knotens A wird Knoten B diesen als tot definieren. Dazu versendet er an alle anderen Mitglieder des Clusters eine entsprechende Nachricht. Dabei kann es durchaus zu Fehlmeldungen kommen, weil z. B. der Heartbeat verloren ging oder einfach nur zu spät bei B angekommen ist.

Der TcpFailureDetector hat die Aufgabe, diese Fehlalarme zu verhindern. Dazu erkennt er den entsprechenden Typ der Nachricht noch vor dem Versand und führt zunächst eine Prüfung durch. Kann der vermeintlich ausgefallene Knoten A via TCP erreicht werden, wird von einem Fehlalarm ausgegangen. Die ursprüngliche Cluster-Nachricht wird verworfen. Kann Knoten A auch via TCP nicht erreicht werden, wird ein Ausfall als sicher betrachtet und die entsprechende Cluster-Nachricht wird wie geplant an die anderen Verbundmitglieder versendet.

Neue SessionManager

Neben der Kapselung der Cluster-Kommunikation im Channel-Element gibt es noch weitere Neuerungen. So kann nun der SessionManager pro Context ausgewählt werden. Bisher war dies nur für den gesamten Cluster möglich. Zudem steht nun ein weiterer, clusterfähiger SessionManager zur Verfügung: der BackupManager. Während der bisher verwendete DeltaManager immer auf alle Knoten im Verbund repliziert, bietet der BackupManager nun die gezielte Replikation auf genau einen Knoten an. Dies soll das Manko der Replikation beheben, dass diese nicht gut skaliert. Ob der BackupManager diesen Ansprüchen gerecht wird, kann noch nicht beurteilt werden, da hier zunächst Praxiserfahrungen gesammelt werden müssen.

Neue Instabilität

Auch wenn die Komponenten teilweise gleiche Benennungen tragen, sind sie doch größtenteils neu entwickelt worden. Dass solch große Veränderungen in der Regel die Stabilität einer Software gefährden, zeigt sich auch bei Tomcat. Bei einer ersten Lastmessung unter Laborbedingungen erwies sich der Cluster von Tomcat 6.0.10 als noch relativ instabil. Insbesondere die asynchrone Kommunikation bereitete erhebliche Probleme und führte häufig zum Zusammenbruch der Kommunikation im Verbund. Ein als Referenz hinzugezogener Tomcat 5.5.20 Cluster zeigte diese Auffälligkeiten nicht.

Fazit

Zusammengefasst hinterlässt der Cluster von Tomcat 6 einen gemischten Eindruck. Der BackupManager vereinfacht die Bildung von kleineren Verbünden und das Konzept der Interceptors erscheint schlüssig. Die Ausgliederung des Codes für den Nachrichtenversand in ein eigenes Framework wird sich auf lange Sicht sicherlich als positiv erweisen. Dass dieser grobe Schnitt nicht ohne negative Folgen geblieben ist und die Stabilität des Clusters gelitten hat, ist die Kehrseite der Medaille. Es bleibt zu hoffen, dass diese Probleme in zukünftigen Versionen behoben werden.

Michael Heß (info@ordix.de).