JBoss Clustering

Einer für alle, alle für einen

JBoss ist einer der am meisten verbreiteten Applikationsserver. Er kommt in immer mehr Unternehmen zum Einsatz. Doch was ist, wenn das System eine besonders hohe Verfügbarkeit garantieren muss oder die umfangreichen Aufgaben den Rechner zunehmend an seine Leistungsgrenze treiben? Sei es durch gestiegene Zugriffszahlen oder die immer komplexer werdenden, auf dem Server betriebenen Anwendungen? Die Lösung ist einfach: Man verteilt die Last auf verschiedene Rechner (Clustering). Dieser Artikel stellt die Funktionsweise eines Clusters grob dar und geht auf die wichtigsten Konfigurationsschritte ein.

Warum Clustering?

Um einen Cluster aufzusetzen, gibt es im Wesentlichen zwei Gründe. Zum einen kann durch das Clustering die Performance gesteigert werden, indem die Last auf mehrere Maschinen verteilt wird. Zum anderen kann die Ausfallsicherheit des Gesamtsystems durch den Einsatz mehrerer Rechner deutlich erhöht werden.

Knoten und Partitionen

Die einzelnen Bestandteile eines Clusters stellen die so genannten Nodes (Knoten) dar. Der Zusammenschluss mehrerer Knoten bildet eine Partition. Eine zusammenhängende Partition wird durch einen eindeutigen Partitionsnamen und eine eindeutige Konfiguration definiert. Jeder Knoten einer Partition muss also denselben Partitionsnamen und dieselben Konfinfigurationseinstellungen wie alle anderen Bestandteile des Clusters besitzen.

Abb. 1: Verschiedene Partitionen in einem Netzwerk.

Über diese eindeutige Zuordnung ist es auch möglich, mehrere Partitionen innerhalb eines Netzwerkes laufen zu lassen (siehe Abbildung 1). Theoretisch kann man sogar einen einzelnen Knoten so konfigurieren, dass er gleichzeitig Mitglied in verschiedenen Partitionen innerhalb desselben Netzwerkes ist. In einer solchen Konstellation ist der interne Verwaltungsaufwand in der Regel jedoch so hoch, dass der durch das Clustering erzielte Performance-Gewinn dadurch wieder aufgehoben wird.

Kommunikation zwischen den Knoten

Um mehrere JBoss-Instanzen im Rechnerverbund als Cluster laufen zu lassen, müssen die einzelnen Knoten Verwaltungsdaten untereinander austauschen. Um jede Client-Anfrage bearbeiten zu können, ist es erforderlich, dass jeder einzelne Knoten über die hierfür notwendigen Daten verfügt. Dies sind in erster Linie die Session und die Session-Daten eines jeden Clients. Zudem muss es möglich sein, auf die Instanz einer Stateful Session Bean zuzugreifen, die einem bestimmten Client bzw. einer bestimmten Session zugeordnet ist.

Die Kommunikation der einzelnen Knoten untereinander erfolgt (standardmäßig) per IP-Multicast und über das UDP-Protokoll. Das Netzwerk, in dem die Partition laufen soll, muss also so konfiguriert werden, dass Multicasts und die Kommunikation über das UDP-Protokoll möglich sind.

Java Naming and Directory Interface(JNDI)

Eine JBoss-Instanz, die als Standalone-Server läuft, verwendet einen JNDI-Service für die Verwaltung und den Zugriff auf verschiedene Objekte. Wenn mehrere JBoss-Instanzen zusammen als Cluster agieren, kommt zusätzlich ein clusterweiter JNDI zum Einsatz:

Dieser High Availability-JNDI (HA-JNDI) stellt bei der Suche eines Knotens nach einem Objekt die erste Anlaufstelle dar. Wenn das gesuchte Objekt nicht im globalen Naming Service enthalten ist, so wird im nächsten Schritt im lokalen JNDI nach ihm gesucht. Wenn das Objekt auch dort nicht gefunden werden kann, so stellt der Knoten eine Anfrage an alle anderen im Cluster befindlichen Knoten. Diese suchen dann ihrerseits in ihrem lokalen JNDI nach dem angefragten Objekt und liefern dieses im Erfolgsfall an die anfragende Instanz zurück.

Hochverfügbarkeit / Lastverteilung

Um die Hochverfügbarkeit einer Anwendung sicherzustellen, ist zunächst einmal wichtig, über welchen Weg und auf welche Art und Weise die einzelnen Clients letztlich auf den Cluster bzw. die einzelnen Knoten zugreifen. Abhängig davon muss eine Strategie angewandt werden, die darauf reagiert, wenn ein Knoten des Clusters nicht mehr erreichbar ist.

Abb. 2: Verwendung eines clientseitigen Interceptors.

Abb. 3: Verwendung eines serverseitigen Load Balancers.

Die erste Möglichkeit ist die Verwendung eines clientseitigen Interceptors (siehe Abbildung 2). In diesem Szenario verfügt der Interceptor über die IP-Adressen aller Knoten des Clusters und besitzt eigene Strategien zur Verteilung der Aufrufe für eine gute Lastverteilung.

Darüber hinaus führt der Interceptor eine Failover-Strategie durch, wenn ein angesprochener Knoten nicht erreichbar ist. Das heißt, in einem solchen Fall wird die Anfrage für den Client transparent an einen anderen Knoten gerichtet. Die verfügbaren Knoten des Clusters und deren Auslastung werden dem Interceptor in regelmäßigen Abständen übermittelt. Dies geschieht, indem diese Informationen als Zusatz zu einer clientseitig iniziierten Anfrage an die zugehörige Antwort angehängt werden.

Die zweite Möglichkeit besteht darin, einen serverseitigen Load Balancer einzusetzen,der alle Anfragen zentral entgegennimmt und dann auf die verschiedenen Knoten verteilt (siehe Abbildung 3). Dieses Anwendungsbeispiel birgt natürlich den Nachteil, dass der gesamte Cluster nicht mehr erreichbar ist, wenn der Load Balancer ausfällt.

Um die Ausfallwahrscheinlichkeit möglichst gering zu halten, sollte an dieser Stelle entweder ein Hardware Balancer verwendet werden, der eine hohe Ausfallsicherheit garantiert, oder es sollten mehrere Load Balancer zum Einsatz kommen (z. B. durch den Einsatz mehrerer Web-Server), die sich gegebenenfalls gegenseitig ersetzen können.

Cluster-Erstellung ganz einfach

Alle relevanten Dienste und Funktionalitäten, die für den Aufbau eines Clusters nötig sind, bringt JBoss von Haus aus mit. Zusätzliche Erweiterungen oder Komponenten müssen also nicht installiert oder integriert werden.

Um einen Cluster aus mehreren Rechnern aufzubauen, reicht es zunächst einmal aus, die einzelnen Knoten, die den Cluster bilden sollen, in ein Netzwerk zu stellen und in der All-Konfiguration zu starten. Die Rechner werden daraufhin alle der Default-Partition hinzugefügt und somit in einen zusammenhängenden Verbund eingebettet.

Konfiguration des Clusters

Alle relevanten Einstellungen zum Aufbau eines Clusters, der nicht den Standardvorgaben der JBoss-All-Konfiguration entspricht oder einen anderen Grundaufbau erfordert, beispielsweise wenn mehrere Partitionen innerhalb eines Netzwerkes laufen sollen, können in der zentralen Konfigurationsdatei cluster-service.xml im deploy-Verzeichnis der Konfiguration vorgenommen werden.

Hier werden alle MBeans konfiguriert, die für den Cluster-Betrieb notwendig sind. Dazu zählen beispielsweise die ClusterPartition-Bean, die die Partition parametrisiert und konfiguriert und die HANamingService-Bean, die den globalen Naming Service bereitstellt. Abbildung 4 listet die wichtigsten Attribute dieser beiden MBeans auf. Generell sind alle Parameter vorkonfiguriert und beinhalten teilweise JBoss-interne Platzhalter. So zum Beispiel die Angabe ${jboss.bind.address}, die zur Laufzeit durch die Angabe der IP-Adresse ausgetauscht wird, die der JBoss-Instanz zugewiesen worden ist.

Deployment

Um eine Applikation im Cluster verteilen zu können, stellt JBoss einen Mechanismus zur Verfügung, der es ermöglicht, entsprechende Deployment-Dateien, also WAR-, EAR- oder SAR-Archive, die sich auf einem Cluster-Knoten befinden, im ganzen Cluster zu verteilen. Dieser so genannte Farming-Service ist standardmäßig in der All-Konfiguration vorhanden.

Er stellt dem Anwender neben dem deploy-Ordner ein zusätzliches Verzeichnis zur Verfügung, in das alle Archive abgelegt werden können, die nicht nur lokal, sondern im ganzen Cluster verteilt werden sollen. Dieses Verzeichnis trägt (standardmäßig) den Namen farm und ist im Konfigurationsverzeichnis des JBoss-Verzeichnisbaums zu finden.

Wenn nach einer erfolgreichen Verteilung einer Anwendung weitere Cluster-Knoten hinzugeeschaltet werden, werden alle im Cluster verteilten Anwendungen automatisch auch auf die neu hinzugekommenen Knoten kopiert und dort gestartet.

Der Farming Service wird in der Konfigurationsdatei farm-service.xml parametrisiert, die sich innerhalb des deploy-Verzeichnisses der jeweiligen JBoss-Konfiguration im Ordner deploy.last befindet. Die hier möglichen Einstellungen erlauben beispielsweise das Setzen von Deployment-Filtern oder die Angabe, wie oft das farm-Verzeichnis auf neue, hinzugekommene Dateien überprüft werden soll.

Redeployment

Über den Farming Service können im Cluster verteilte Anwendungen auch sehr einfach wieder aus dem Rechnerverbund entfernt werden. Hierfür genügt es, das entsprechende Archiv im farm-Ordner eines der Knoten zu entfernen. Alle anderen aktiven Knoten entfernen daraufhin ebenfalls das entsprechende Archiv aus ihrem lokalen farm-Ordner.

Dieser Mechanismus greift allerdings nicht bei JBoss-Instanzen, die zum Zeitpunkt des Redeployment nicht aktiv sind. Aus diesem Grunde muss das Archiv der entsprechenden Applikation aus diesen Knoten manuell entfernt werden, anderenfalls würde der Farming Service die Anwendung beim nächsten Start des Servers wieder im gesamten Cluster verteilen.

Fazit

Wenngleich dieser Artikel nur eine sehr kurze Einführung in die Thematik sein kann, wird dennoch deutlich, dass der Open Source Server JBoss dem Anwender alle Dienste und Werkzeuge zur Verfügung stellt, um einen Cluster-Verbund aus mehreren JBoss-Instanzen zu erstellen und Web- oder Enterprise-Applikationen darauf zu verteilen.

Wie man sieht, gestaltet sich die Einrichtung im einfachsten Fall äußerst simpel und ist praktisch ohne irgendeine Konfigurationseinstellung oder Anpassung zu bewerkstelligen. Für einen tieferen Einblick in die Thematik und den Erwerb von Detail- und Hintergrundwissen, empfehlen wir Ihnen, eines unserer JBoss-Seminare in dem gerade erst erweiterten und neu gestalteten Schulungszentrum in Wiesbaden zu besuchen.

Alexander Zeller (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen