Seitenhistorie
Einleitung
Ab der Nuclos Version 4.4 43 steht der Cluster Betrieb zur Verfügung.
Mehrere Nuclos Server lassen sich in einem Cluster betreiben. Somit So kann eine Lastverteilung erzielt werden bzw. wird die Ausfallsicherheit wird erhöht.
Dabei verwenden alle Server Instanzen (Nodes) die gleiche Datenbank und das gleiche Verzeichnis zur Dokumentenablage.
Als Grundlage dient das Ticket
Jira | ||||||
---|---|---|---|---|---|---|
|
Das Szenario sieht vor das ein Dispatcher/Load Balancer zwischen den Nuclos Client's und Nuclos Server's Servern wirkt.
Dieser ist nicht Bestandteil einer Nuclos Auslieferung.
Installation
Während Mit der Installation kann der Administrator in der Server Konfiguration den Cluster Betrieb ein-/ausschalten.
In der Datei ${NUCLOS_HOME}/conf/server.properties und in der ${NUCLOS_HOME}/nuclos.xml wird die Konfiguration festgeschrieben.
Property in server.properties: cluster.mode=false || true
Der erste Server fährt hoch
Während des Autosetup's von Nuclos wird die Tabelle T_MD_CLUSTER_SERVER erstellt. In dieser Tabelle registrieren sich alle Server,
die im Cluster Betrieb sich mit dieser Datenbank verbinden. Der erste Server der sich anmeldet ist der sogenannte Master.
Nur der Master startet den Quartz Scheduler. Somit laufen alle Nuclos Job's auf ihm.
Beendet sich ein Server, nimmt er seinen Eintrag aus der Tabelle heraus.
Kommunikation untereinander
Alle relevanten Nachrichten werden per JMS an die angemeldeten Server verteilt.
Das betrifft die Server-Seitigen Caches, die Regel-Kompilierung, etc.
Ist ein Client-Seitiger Cache betroffen, wird der Client, der mit einem bestimmten Server verbunden ist ebenfalls aktualisiert.
Ausfall eines Server's (Master's)
Fällt ein Server aus, physikalisch oder die Java Virtual Machine wird abgebrochen, kann er den Eintrag nicht selbstständig aus der Tabelle T_MD_CLUSTER_SERVER herausnehmen.
Alle Server schauen in einem regelmäßigen Zeitabstand nach, ob noch alle angemeldeten Server erreichbar sind. Ist ein Server nicht mehr erreichbar, wird er aus der Tabelle entfernt.
Fällt der Master aus und die anderen bemerken diesen Umstand, wird über das Strategie Pattern ein neuer Master ermittelt. Dieser übernimmt die Job-Steuerung.
Die Strategie, die den neuen Master bestimmt, muss das Interface org.nuclos.server.cluster.NewMasterNodeStrategy implementieren.
Zur Zeit übernimmt der Server, der am längsten Online ist, siehe org.nuclos.server.cluster.OldestNodeStrategy.
Ausgeschalteter Cluster-Betrieb
Läuft der Server nicht im Cluster-Betrieb, erfolgt kein Eintrag in die Tabelle T_MD_CLUSTER_SERVER.
Somit werden keine Nachrichten an andere Server verschickt.
Der Quartz Scheduler für die Hintergrund Jobs wird während des Server-Start gestartet.
Änderungen an Nuclos
- Alle Caches müssen bei Invalidierung den gleichen Vorgang auslösen.
- Bei den eigenen Caches, z.B. ServerParameterProvider wurde das Interface org.nuclos.server.cluster.cache.ClusterCache implementiert.
- Die Spring konfigurierten Caches werden im Cluster Betrieb dekoriert, siehe org.nuclos.server.cluster.cache.NuclosSimpleClusterCacheManager
Im Cluster Betrieb reichen sie die entsprechende Aktion zentral weiter.
- Im Cluster Betrieb darf nur der Master den internen Quartz Scheduler starten.
- ...
Was fehlt noch
- Eine Maske im Client, die alle angemeldeten Server auflistet. Aktionen der Maske:
- Beenden eines Servers
- Server zum Master-Server erheben
- Server pingen (alive Test)
- ...
Weitere Parameter sind
Parameter | Beschreibung |
---|---|
Node hostname | Über diesen Hostnamen ist der Server (die Node) von anderen Nodes aus direkt erreichbar. Diese Erreichbarkeit ist für einen Betrieb nicht unbedingt notwendig, allerdings zu Lasten der Sicherheit. Z.B. prüft eine Master Node ob nicht bereits ein anderer Master läuft, oder der Wartungsmodus prüft zusätzlich mittels eines Rest-Calls ob sich ein Slave im Wartungsmodus befindet. |
Node type |
|
Load balancer protocol | Optional - Falls abweichend gegenüber dem Nuclos Server. |
Load balancer hostname | Optional - Falls abweichend gegenüber dem Nuclos Server. |
Load balancer port | Optional - Falls abweichend gegenüber dem Nuclos Server. |
Load balancer context path | Optional - Falls abweichend gegenüber dem Nuclos Server. |
Load Balancer
Die Parameter des Load Balancers müssen auf die für die Clients benötigen Werte gesetzt werden. Da Nuclos keinen eigenen Balancer mitbringt, sind die Betriebsparameter unbekannt, welche aber für den Rest-Service und dem Webclient benötigt werden.
Hintergrund: An den unterschiedlichsten Stellen im Rest-Service werden in den Ergebnissen URL (Links) auf andere Rest-Services eingebaut. Damit diese URLs auf den Balancer zeigen, werden diese Parameter in einem Cluster-Betrieb vorrangig bei der Generierung von URLs herangezogen.
Hinweis | ||
---|---|---|
| ||
Es ist zwingend erforderlich, dass die Session eines Clients immer mit der gleichen Node kommuniziert. Entsprechend muss der Load Balancer Sticky Sessions unterstützen und aktiviert haben. Fällt eine Node aus, werden automatisch die Sessions aller mit ihm verbundenen Clients ungültig, und eine erneute Anmeldung am Cluster ist erforderlich. |
Cluster Server
Im Web- wie auch im Java-Client kann die Liste der registrierten Cluster Server eingesehen werden (Menü Administration).
Eine Bearbeitung ist an dieser Stelle nicht möglich. Die komplette Einrichtung findet bei der Installation statt.
Aber über diese Ansicht kann man den Status der einzelnen Nodes erfahren, wie auch die Nachrichten die zwischen diesen ausgetauscht werden (max der letzten 24h). Auch ist eine Live Status Abfrage aller Server via Rest möglich. Diese wird vom aktuell verwendeten Server, markiert als Tester, abgesetzt.
Einschränkungen
- Im Cluster-Betrieb wird der Lucene-Indexer automatisch vom Installer deaktiviert.
...