Der erste Post dieser Serie hat die grundlegenden Konzepte hinter dem Clustering mit JBoss AS 7 und EAP 6 behandelt. Wir haben erklärt, wie Clustering für eine einfache Java EE-Anwendung verwendet werden kann und haben eine einfache Cluster-Umgebung im Standalone-Mode aufgesetzt. In diesem Post erklären wir jetzt den Domain-Mode und wie man Cluster-Umgebungen mit Hilfe von Managed-Domains verwaltet.
Übersicht
Eine Managed-Domain umfasst mehrere Hosts mit zentralisierten Administrations- und Verwaltungsrichtlinien. Jeder Host, der im Domain-Mode läuft kann mehrere Server-Instanzen enthalten, die zu einer Domäne gehören. Der Domain-Mode ist einer von zwei möglichen Betriebsmodi der EAP 6 bzw. des JBoss AS 7. Der andere zur Wahl stehende Modus ist der Standalone-Mode. Ein JBoss Application-Server, der im Standalone-Mode betrieben wird, ist ein unabhängiger Prozess. Dieser Modus ähnelt denen früherer Versionen des JBoss Application-Servers. Die unterschiedlichen Betriebsmodi haben keinen Einfluss auf die Fähigkeiten des Application-Servers, aber darauf, wie ein oder mehrere Server verwaltet werden. Der Domain-Mode ist also komplett unabhängig vom Clustering. Allerdings stellt er viele nützliche Features zur Verwaltung von geclusterten Umgebungen zur Verfügung, beispielsweise Abwicklung von Deployments von mehreren Instanzen. Wenn zum Beispiel der JBoss AS 7 im Standalone-Mode läuft, unterstützt er die früheren Farming-Deployment-Fähigkeiten nicht mehr. Dies kann mit den Domain-Mode-Fähigkeiten erreicht werden, und natürlich gibt es auch Features wie das Starten und Stoppen von Servern von einer einzigen Konsole. Das macht das Arbeiten mit geclusterten Umgebungen einfacher.
Server Topologie in unserer Managed-Domain
Im letzten Post haben wir ein Cluster mit zwei Knoten auf einer Maschine erstellt. In diesem Post wollen wir ein Cluster mit vier Knoten auf zwei verschiedenen Maschinen im selben Netzwerk einrichten, so wie die Grafik unten zeigt. Die Serverknoten werden in einer Domäne verwaltet.
Managed-Domain-Architektur
Eine Domäne kann aus vielen physischen oder virtuellen Hosts bestehen. Jeder Host benötigt einen Host-Controller, der den Lebenszyklus der Server verwaltet. Jede Domäne braucht einen Domain-Controller für zentralisierte Management-Aufgaben. Der Domain-Controller kann entweder einer der Host-Controller sein oder eine speziell dafür vorgesehene Instanz. In unserer Beispiel-Umgebung verwenden wir einen eigenen Host als Domain-Controller. Wir empfehlen diese Architektur auch aus Sicht der Verfügbarkeit, weil die anderen Hosts in diesem Fall vollständig unabhängig von administrativen Aufgaben sind.
Im Domain-Mode ist es möglich mehrere Server-Instanzen auf einem Host zu verwalten. Aus diesem Grund braucht jeder Host einen separaten Host-Controller, der die Server-Instanzen auf diesem Host steuert. Der Domain-Controller interagiert mit den Host-Controllern, um die Server-Instanzen zu verwalten. Jede Server-Instanz einer Domäne gehört zu einer virtuellen Server-Gruppe. Die Idee ist, dass alle Server derselben Server-Gruppe die gleiche Aufgabe ausführen. Wenn man eine Anwendung deployt, wird man sie nicht auf einen Server deployen, sondern auf eine ganze Server-Gruppe. Es ist auch möglich verschiedene Server-Gruppen in einer Domäne zu verwalten, beispielsweise eine Produktive, eine zum Vorzeigen und eine zum Testen.
Der Controller und die Server-Instanzen von jedem Host sind separate JVM-Prozesse, diese werden von einem Prozess-Controller überwacht. Der Prozess-Controller ist ebenfalls ein separater JVM-Prozess, der dafür verantwortlich ist, die anderen Prozesse zu starten und ihren Lebenszyklus zu überwachen. Falls der Host-Controller-Prozess abbricht, startet der Prozess-Controller den Host-Controller sowie jeden Server, der mit dem auto-start-Parameter konfiguriert ist. Doch wenn der Server-Prozess einer Server-Instanz unerwartet terminiert, startet der Prozess-Controller die Server-Instanzen nicht automatisch neu. Dafür ist externes Monitoring notwendig.
Domain Setup
Jetzt können wir unsere geclusterte Domäne aufsetzen. Zunächst brauchen wir eine frische Kopie des EAP 6 bzw. den neusten JBoss AS 7 auf jeder Maschine.
Domain-Controller-Setup
Wie bereits erwähnt, werden wir auf einem der Hosts unseren Domain-Controller aufsetzen. Die Server-Konfiguration der Domain wird entsprechend der Richtlinien der Domain-Konfiguration durchgeführt. Diese Konfigurationen sind zentralisiert in der Datei domain.xml des Domain-Controllers. Die domain.xml befindet sich in domain/configuration/. Sie enthält die Hauptkonfiguration für alle Server-Instanzen. Diese Datei wird nur für den Domain-Controller benötigt. Ein physikalischer Host in einer Managed-Domain wird mit der Datei host.xml konfiguriert, die sich ebenfalls in domain/configuration/ befindet. Diese Datei beinhaltet Host-spezifische Konfigurationen wie Netzwerk-Interface-Bindings.
In der Datei domain.xml definieren wir eine Server-Gruppe cluster-ha für die Server-Instanzen, die zu dieser Gruppe gehören. Die Standard-Konfiguration beinhaltet bereits zwei Server-Gruppen. Die Konfiguration werden wir mit der folgenden Server-Gruppen-Konfiguration für unsere Domain ersetzen:
[sourcecode language=”xml”]
<domain xmlns="urn:jboss:domain:1.3">
…
<server-groups>
<server-group name="cluster-ha" profile="ha">
<jvm name="default"/>
<socket-binding-group ref="ha-sockets" />
</server-group>
</server-groups>
</domain>
[/sourcecode]
Jede Server-Gruppe braucht einen eindeutigen Namen und eine Referenz zu einem Profil der Domain-Konfiguration. Die Standard-Konfiguration enthält vier vorkonfigurierte Profile:
- default – Support des Java EE Web-Profils plus einige Erweiterungen wie RESTful Web Services oder Support für EJB3 Remote-Invocations.
- full – Support des Java EE Full-Profils und aller Server-Fähigkeiten ohne Clustering
- ha – Standard-Profil mit Clustering-Fähigkeiten
- full-ha – vollständiges Profil mit Clustering-Fähigkeiten
Ein Profil enthält die Konfiguration des unterstützten Subsystems, das von einer Erweiterung hinzugefügt wird. Wir haben das ha Profil gewählt, da unsere Anwendung keine zusätzlichen Technologien außer Java EE Web Profile-Technologien und Cluster-Fähigkeiten benötigt.
Das referenzierte Profil wird von der Server-Gruppe zu einer Socket-Binding-Gruppe zugeordnet. Eine Socket-Binding-Gruppe referenziert logische Interface-Namen anstatt direkt die Interfaces eines Hosts zu referenzieren. Diese logischen Interfaces sind in der <interfaces>-Sektion in der Konfigurationsdatei domain.xml definiert. Die logischen Interfaces und die Socket-Binding-Gruppe repräsentieren die Socket-Adressen von jedem Host.
Zusätzlich zum Profil und der Konfiguration der Socket-Binding-Gruppe einer Server-Gruppe, kann der Domain-Controller systemweite Properties zur Verfügung stellen und eine Referenz zu einer JVM-Konfiguration, diese ist in der Konfigurationsdatei host.xml zu finden.
Für den Domain-Controller benutzen wir die vorkonfigurierte Konfigurationsdatei host-master.xml, diese beinhaltet die notwendige Konfiguration für den Host, bspw. das physikalische Network-Binding des Management-Interfaces oder die JVM-Konfiguration. Mit der folgenden Konfiguration in der host-master.xml wird der Host zum Domain-Controller.
[sourcecode language=”xml”]
<host name="master" xmlns="urn:jboss:domain:1.3">
…
<domain-controller>
<local/>
</domain-controller>
…
</host>
[/sourcecode]
Bevor wir den Domain-Controller starten müssen wir noch einen Administrationsbenutzer für den Domain-Controller erstellen. Dieser Benutzer ist notwendig, wenn der Host-Controller eine Verbindung zum Domain-Controller aufbauen muss. Dafür ist im bin-Verzeichnis der JBoss AS-Distribution das Script add-user.sh.
$./add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a): a Enter the details of the new user to add. Realm (ManagementRealm) : Username : domainadmin Password : Re-enter Password : Are you sure you want to add user 'domain' yes/no? y About to add user 'domain for realm 'ManagementRealm' Is this correct yes/no? y Added user 'domain' to file '/standalone/configuration/mgmt-users.properties' Added user 'domain' to file '/domain/configuration/mgmt-users.properties' Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller? yes/no? y To represent the user add the following to the server-identities definition
Die letzte Frage muss mit yes oder y beantwortet werden, um zu zeigen, dass der Benutzer dazu verwendet wird, vom Host-Controller zum Domain-Controller zu verbinden. Der generierte geheime Wert ist das Base64-kodierte Passwort für den neu erstellten User.
Jetzt können wir den Domain-Controller mit dem folgenden Kommando starten. Wir werden die Bind-Adresse des physikalischen Netzwerks mit der Property jboss.bind.address.management auf die Host-Konfiguration setzen. Das Management-Interface muss für alle Hosts in der Domain erreichbar sein, um eine Verbindung mit dem Domain-Controller aufzubauen.
./domain.sh \ --host-config=host-master.xml \ -Djboss.bind.address.management=192.168.0.1
Konfiguration des Hosts
Nachdem der Domain-Controller konfiguriert und gestartet ist, ist der nächste Schritt die beiden Hosts aufzusetzen. Auf jedem Host brauchen wir eine frische Kopie der JBoss AS-Distribution.
Die Hauptkonfiguration für die Hosts ist die Datei host.xml, die sich, wie bereits erwähnt, in domain/configuration/ befindet. In unserem Beispiel werden wir die vorkonfigurierte Datei slave-host.xml für den Host-Controller verwenden. Diese Datei ist ebenfalls im Verzeichnis der Domain-Konfiguration der JBoss AS 7-Distribution.
Als erstes muss ein eindeutiger Name für jeden Host in unserer Domain gewählt werden, damit es nicht zu Konflikten kommt. Andernfalls ist der Default-Wert der Host-Name des Servers.
[sourcecode language=”xml”]
<host name="server1" xmlns="urn:jboss:domain:1.3">
…
</host>
[/sourcecode]
Wie bereits erwähnt muss der Host-Controller wissen, wie eine Verbindung zum Domain-Controller aufgebaut wird. Die folgende Konfiguration auf dem Host spezifiziert, wo sich der Domain-Controller befindet. So kann der Host-Controller sich selbst beim Domain-Controller registrieren. Der remote Tag muss den Benutzernamen und den Security-Realm des Domain-Controllers beinhalten.
[sourcecode language=”xml”]
<host name="master" xmlns="urn:jboss:domain:1.3">
…
<domain-controller>
<remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" username="domainadmin" security-realm="ManagementRealm"/>
</domain-controller>
…
</host>
[/sourcecode]
Außerdem muss der geheime Wert bekanntgegeben werden. Dieser wird zusammen mit dem Nutzernamen für die Authentifizierung benötigt. Der geheime Wert ist die letzte Ausgabe des Scripts add-user.sh, welches wir vorher ausgeführt haben. Dieser Wert ist nur das Base64-kodierte Passwort des Domain-Users. Wir empfehlen sensible Daten wie Passwörter mit dem Vault-Tool-Script zu kodieren. Das Skript befindet sich im bin Verzeichnis des JBoss AS.
[sourcecode language=”xml”]
<host name="server1" xmlns="urn:jboss:domain:1.3">
<management>
<security-realms>
<security-realm name="ManagementRealm">
<server-identities>
<!– Replace this with either a base64 password of your own, or use a vault with a vault expression –>
<secret value="c2VjcmV0"/>
</server-identities>
<authentication>
<local default-user="$local" />
<properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/>
</authentication>
</security-realm>
…
</security-realms>
…
</management>
…
</host>
[/sourcecode]
Der letzte Schritt ist die Konfiguration des Serverknotens in der Datei host-slave.xml auf beiden Hosts. Wir werden die existierende Konfiguration für unsere beiden Server-Instanzen der cluster-ha Gruppe mit der folgenden Konfiguration ersetzen.
[sourcecode language=”xml”]
<host name="server1" xmlns="urn:jboss:domain:1.3">
…
<servers>
<server name="server-one" group="cluster-ha" auto-start="false"/>
<server name="server-two" group="cluster-ha" auto-start="false">
<!– server-two avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group –>
<socket-bindings port-offset="150"/>
</server>
</servers>
</host>
[/sourcecode]
Das Flag auto-start zeigt an, dass die Server-Instanzen nicht automatisch gestartet werden, wenn der Host-Controller gestartet wird.
Für den zweiten Server wird ein port-offset konfiguriert, um Port-Konflikte zu vermeiden. Mit dem Port-Offset können wir die Socket-Binding-Gruppe der Domain-Konfiguration für mehrere Server-Instanzen auf dem Host wiederverwenden.
Das war bereits die komplette notwendige Konfiguration des Hosts. Nachdem diese Konfiguration auf beiden Hosts eingefügt ist, kann der Host-Controller auf beiden Hosts mit dem folgenden Kommando gestartet werden:
./domain.sh \ --host-config=host-slave.xml \ -Djboss.domain.master.address=192.168.0.1 \ -Djboss.bind.address=192.168.0.2 \ -Djboss.bind.address.management=192.168.0.2
beziehungsweise
./domain.sh \ --host-config=host-slave.xml \ -Djboss.domain.master.address=192.168.0.1 \ -Djboss.bind.address=192.168.0.3 \ -Djboss.bind.address.management=192.168.0.3
Zu diesem Zeitpunkt sind nur die Host-Controller auf beiden Hosts gestartet. Wenn wir in die Datei host-controller.log des Domain-Controllers schauen, sehen wir, dass server1 und server2 als Remote-Slave-Hosts registriert sind.
[Host Controller] 23:32:00,082 INFO [org.jboss.as.domain] (slave-request-threads - 1) JBAS010918: Registered remote slave host "server1", JBoss EAP 6.0.0.GA (AS 7.1.2.Final-redhat-1) [Host Controller] 23:32:16,739 INFO [org.jboss.as.domain] (slave-request-threads - 1) JBAS010918: Registered remote slave host "server2", JBoss EAP 6.0.0.GA (AS 7.1.2.Final-redhat-1)
Domain-Management via Kommandozeileninterface
Um zu demonstrieren, wie wir jetzt unsere Domäne verwalten und Anwendungen deployen können, werden wir die Anwendung aus unserem letzten Post verwenden.
Der Code kann bei github ausgecheckt werden. Das Projekt baut mit Maven, indem man das mvn package Kommando ausführt.
$ git clone https://github.com/akquinet/jbosscc-as7-examples.git Cloning into jbosscc-as7-examples... $ cd cluster-example/ $ mvn package [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Cluster Web Application example 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] ... [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.512s [INFO] Finished at: Wed Jun 20 22:29:15 CEST 2012 [INFO] Final Memory: 10M/81M [INFO] ------------------------------------------------------------------------
Nachdem wir die Anwendung gebaut haben können wir jetzt das gepackte Web-Archiv mittels Kommandozeile auf die ganze Server-Gruppe deployen und unsere Domäne verwalten. All diese Verwaltungsaufgaben können auch mit der Web-Konsole durchgeführt werden.
Zunächst müssen wir das Kommandozeileninterface mit dem Domain-Controller verbinden. Mit den folgenden Kommandos baut das Kommandozeileninterface eine Verbindung zum Domain-Controller auf:
./bin/jboss-cli.sh You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. [disconnected /] connect 192.168.0.1 Authenticating against security realm: ManagementRealm Username: domainadmin Password: [domain@192.168.0.1:9999 /]
Mit dem deploy Kommando können wir die Anwendung jetzt auf unsere Server-Gruppe deployen.
[domain@192.168.0.1:9999 /] deploy jbosscc-as7-examples/cluster-example/target/cluster-example-1.0-SNAPSHOT.war --server-groups=cluster-ha
Die Informationen des Deployments werden in der Datei domain.xml des Domain-Controllers gespeichert. Nach einem Neustart ist das Deployment auf der Server-Gruppe immer noch verfügbar.
[sourcecode language=”xml”]
<deployments>
<deployment name="cluster-example-1.0-SNAPSHOT.war" runtime-name="cluster-example-1.0-SNAPSHOT.war">
<content sha1="8634e58ce0919e459474c1bcfb4ba888aceae075"/>
</deployment>
</deployments>
<server-groups>
<server-group name="cluster-ha" profile="ha">
…
<deployments>
<deployment name="cluster-example-1.0-SNAPSHOT.war" runtime-name="cluster-example-1.0-SNAPSHOT.war"/>
</deployments>
</server-group>
</server-groups>
[/sourcecode]
Nachdem die Anwendung deployt ist, können wir mit dem folgenden Kommando alle Server-Instanzen der cluster-ha Server-Gruppe starten:
[domain@192.168.0.1:9999/] /server-group=cluster-ha:start-servers
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
Die vier Server-Instanzen bilden einen Cluster, weil sie alle zur cluster-ha Gruppe gehören, die mit dem ha Profil der Domain-Konfiguration assoziiert ist. Das ha Profil enthält Standard-Konfigurationen für eine UDP-basierte Cluster-Umgebung.
Im letzten Post haben wir bereits den httpd-Server und mod_cluster für Load-Balancing konfiguriert. Wenn die Hosts in derselben UDP-Multicasting-Gruppe wie der httpd-Server sind, können wir unsere Anwendung über http://192.168.0.1/cluster erreichen und sehen, welche Server-Instanz die Anfrage bearbeitet.
Jetzt stoppen wir den Knoten, der die Anfrage bearbeitet hat.
[domain@192.168.0.1:9999/] /host=server1/server-config=node-one:stop
{
"outcome" => "success",
"result" => "STOPPING"
}
Nach einem Refresh der Browser-Seite sieht man, dass ein Failover zu einem anderen Node durchgeführt wurde und die Session immer noch verfügbar ist.
Zusammenfassung
Der Domain-Mode ist eines der mächtigsten Features von EAP 6 und JBoss AS 7. Der Operationsmodus ist unabhängig von der Cluster-Funktionalität, aber er bietet einige nützliche Features für das Verwalten einer Cluster-Umgebung, wie das Deployment von Anwendungen, zentralisierte Konfiguration oder das Starten und Stoppen von Server-Instanzen.
Dieser Post war der zweite in einer Reihe über die Clustering-Fähigkeiten des JBoss AS 7. Im nächsten Post zeigen wir, wie komplexere Cluster-Topologien mit dem JBoss AS 7 und den darunterliegenden Subsystemen erstellt werden können.
2 Gedanken zu „Verwalten von Clusterknoten im Domain-Mode des JBoss AS 7 und EAP 6“
Kommentare sind geschlossen.