Verbundarchitektur

Die Gruppe der Liberty-Server in einer einzigen Managementdomäne wird als Verbund bezeichnet. Ein Verbund besteht aus mindestens einem Server, in dem das Feature collectiveController-1.0 aktiviert ist. Dieser Server wird als Verbundcontroller bezeichnet. Ein Verbund kann optional viele Server enthalten, in denen das Feature collectiveMember-1.0 definiert ist. Diese Server werden als Verbundmember bezeichnet. Ein Verbund kann so konfiguriert werden, dass er viele Verbundcontroller enthält.

Der Verbundcontroller stellt einen zentralen Steuerpunkt für die Verwaltung bereit, über den Operationen wie MBean-Routing, Dateiübertragung und Cluster-Management ausgeführt werden können. Eine zentrale Aufgabe von Verbundcontrollern besteht darin, Informationen (z. B. MBean-Attribute und den Betriebszustand) von den Membern im Verbund zu empfangen, sodass die Daten schnell abgerufen werden können, ohne dass eine Operation für jedes einzelne Member aufgerufen werden muss.

Abbildung 1. Liberty-Verbundarchitektur
Die Gruppe der Liberty-Server in einer einzigen Managementdomäne wird als Verbund bezeichnet. Ein Verbund besteht aus mindestens einem Server, in dem das Feature collectiveController-1.0 aktiviert ist. Optional kann er viele Verbundmember haben, und er umfasst eine Gruppe von Verbundcontrollern.

Eine Gruppe von Verbundcontrollern wird als Replikatgruppe bezeichnet. Pro Verbund gibt es nur eine einzige Replikatgruppe und alle Controller müssen Teil dieser Replikatgruppe sein. Wenn mehrere Verbundcontroller vorhanden sind, repliziert jeder Verbundcontroller seine Daten an die anderen Verbundcontroller in der Replikatgruppe, um hohe Verfügbarkeit und Datenschutz zu ermöglichen. Die Replikatgruppe ist auch dann logisch vorhanden, wenn nur ein einziger Controller verwendet wird. Wenn Sie Ihre Konfiguration in mehrere Replikate in einer Gruppe ändern, schließen Sie mindestens drei Replikate in die Gruppe ein. Die Controller in der Replikatgruppe können miteinander über ein Collaboration-Schema kommunizieren, um sicherzustellen, dass die Daten in der gesamten Controllergruppe repliziert werden, unabhängig davon, welcher Controller in der Gruppe eine Operation zum Speichern von Daten empfängt. Jeder Controller hat einen dedizierten Port, der vom Replikationsprotokoll verwendet wird. Die Kommunikation zwischen den Controllern in der Replikatgruppe wird immer mit SSL authentifiziert und geschützt. Für die Sicherstellung der Konsistenz zwischen Controllerreplikaten wird ein Quorumalgorithmus verwendet. Für die Hochverfügbarkeit muss die Anzahl der Controller in einer Replikatgruppe eine ungerade Zahl sein. Um die Beibehaltung des Quorums sicherzustellen, dürfen die Replikatgruppenmember des Verbundcontrollers nicht mehrere Rechenzentren umfassen. Fehlendes Quorum, Änderungen, wie z. B. ein Serverstart oder Serverstopp, oder Konfigurationsaktualisierungen können nicht am Verbund vorgenommen werden.

Ein Verbundmember kann mit mehreren Verbundcontrollerendpunkten konfiguriert werden. Ein Verbundmember kommuniziert jeweils nur mit einem einzigen Verbundcontroller. Allerdings ermöglicht eine Konfiguration mit mehreren Verbundcontrollerendpunkten Failover und Lastausgleich. Die Kommunikation zwischen Member und Controller erfolgt immer in Form von MBean-Operationen, die über den IBM® JMX-Rest-Connector ausgeführt werden. Die Kommunikation zwischen den Controllern und Membern wird immer mit SSL authentifiziert und geschützt.

Weitere Informationen finden Sie unter Server-Management-Umgebung für Liberty mithilfe von Verbünden einrichten.

Konfiguration der Verwaltungsdomänensicherheit:
Die Konfiguration der Verwaltungsdomänensicherheit umfasst zwei Bereiche:
  • Benutzerdomäne

    Diese Domäne verwendet die rollenbasierte Java™-Sicherheit, die die Administratorrolle definiert. Sie kann den Benutzern in der konfigurierten Benutzerregistry zugeordnet werden.

  • Serverdomäne

    Diese Domäne verwendet die auf SSL-Zertifikaten basierende Authentifizierung.

Weitere Informationen zur Sicherheit im Verbund finden Sie unter Verbundsicherheit.

Konfigurierte und Standby-Replikate

Replikate, die einer konfigurierten Replikatgruppe hinzugefügt wurden, sind aktiv (aktive Replikate) oder gestoppt (inaktive Replikate). Ein Replikat, das gestartet ist und keiner konfigurierten Replikatgruppe hinzugefügt wurde bzw. das aus einer konfigurierten Replikatgruppe entfernt wurde, wird als Standby-Replikat bezeichnet.

Abbildung 2. Konfigurierte und Standby-Replikate in einem Verbundcontroller
Ein Verbund kann eine konfigurierte Replikatgruppe enthalten, die aktive und gestoppte (inaktive) Replikate hat, und er kann auch Standby-Replikate enthalten. Diese Standby-Replikate sind aktive Replikate, die der konfigurierten Replikatgruppe nicht hinzugefügt wurden bzw. die aus der konfigurierten Replikatgruppe entfernt wurden.

Zusammenfassung der Begriffe der Verbundarchitektur

collective
Die Gruppe der Liberty-Server in einer einzigen Managementdomäne.
Verbundcontroller
Ein Server, in dem das Feature collectiveController-1.0 aktiviert ist.
Verbundmember
Ein Server, in dem das Feature collectiveMember-1.0 aktiviert ist.
Replikatgruppe
Eine Gruppe von Verbundcontrollern. Für eine optimale Funktion und hohe Verfügbarkeit muss eine Replikatgruppe mindestens drei Controller enthalten.
Replikatport
Ein dedizierter Port in einem Controller, der vom Replikationsprotokoll verwendet wird.
Konfigurierte Replikatgruppe
Die Einheit aktiver und inaktiver Replikate.
Aktive Replikate
Die gestarteten Replikate, die der konfigurierten Replikatgruppe hinzugefügt wurden.
Inaktive Replikate
Die gestoppten Replikate, die der konfigurierten Replikatgruppe hinzugefügt wurden.
Standby-Replikat
Die gestarteten Replikate, die der konfigurierten Replikatgruppe nicht hinzugefügt wurden bzw. die aus der konfigurierten Replikatgruppe entfernt wurden.

Symbol das den Typ des Artikels anzeigt. Konzeptartikel

Dateiname: cwlp_collective_arch.html