Installation der CluserCommunication für den Securityserver

ClusterCommunication für den securityserver

Einführung

Die ClusterCommunication ist für den Fall, dass mehrere Securityserver Knoten parallel betrieben werden, zum Beispiel um Ausfallsicherheit zu garantieren. In diesem Fall greifen alle Knoten auf eine einzige Datenbank zurück, wobei die Aufgabe der ClusterCommunication ist, Änderungen, die auf einem Securityserver Knoten vorgenommen wurden an den/die anderen weiter zu geben.

Einrichtung

Datenbanktabelle

Zuerst müssen die Datenbanktabellen CLUSTER_MESSAGE und HIBERNATE_SEQUENCES erstellt werden. Voraussetzung ist außerdem, dass die Tabellen CERTSTORE und CERERRORRULESTORE vorhanden sind. Diese sind aber schon mit der Installation des Securityservers und den damit auszuführenden Datenbankskripten entstanden. Die ersten beiden genannten Tabellen sind ebenfalls in den Securityserver-Datenbankskripten im SVN zu finden und können auf Anfrag zur Verfügung gestellt werden. Da diese Tabellen erst später hinzugefügt wurden, sind sie bei früher Einrichtung des Securityservers wahrscheinlich noch nicht vorhanden.

Desweiteren ist in der hibernate.cfg.xml folgender Inhalt zu ergänzen:

<hibernate-configuration>
  <session-factory>
    <!-- ... -->
    <mapping class="com.nextlevel.b2b.platform.cluster_communication.persistence.vo.ClusterMessage"/>
  </session-factory>
</hibernate-configuration>

Konfigurationsdateien im Securityserver anpassen

In der start.bat Datei muss ein Knotenname für den Securityserver Knoten definiert werden indem diese Zeilen für die ClusterCommuication hinzugefügt werden:

set JAVA_OPTS=%JAVA_OPTS% -Dcluster.node="NODE_01" -Dcluster.service.period="10"
REM cluster.node: Jedem Knoten muss hier eine eindeutige ID zugewiesen werden, zwei unterschiedliche Knoten dürfen nicht die gleiche ID haben.
REM cluster.service.period: Poll-Intervall in Sekunden. Alle x Sekunden prüft der Knoten in der ClusterCommunication Tabelle, ob eine Änderung erfolgt ist.

In diesem Fall wurde als Knotenname NODE_01 gewählt. Andernfalls kann auch NODE_xy gewählt werden.

Die Eigenschaft -Dcluster.service.period sollte nicht kleiner als 10 Sekunden gewählt werden. Es müssen in diesem Intervall alle Zertifikate geladen werden können.

Gegebenenfalls kann die Option fürs Debuggen hinterlegt werden:

set JAVA_OPTS=%JAVA_OPTS% -Xdebug -Xrunjdwp:transport=dt_socket,address=8002,server=y,suspend=n

In der log4j.properties sollten folgende Zeilen ergänzt werden (error wird hier empfohlen):

log4j.logger.org.hibernate=error
log4j.logger.com.nextlevel.platform.service.runtime=ERROR

Neuen Securityserver Knoten anlegen

Der alte Securityserver Ordner kann erst mal dupliziert werden. Folgende Konfigurationsdateien müssen dann im duplizierten Knoten angepasst werden:

  • in der start.bat der -Dcluster.node="NODE_01" muss in beispielsweise NODE_02 umbenannt werden.
  • falls vorhanden muss der Debug Port an dieser Stelle geändert werden
  • in der application.conf muss der Port geändert werden ACHTUNG! Nicht den Port des/ der B2B Knoten wählen

Anpassungen in der Oberfläche

Es wird empfohlen, die Global Property SECURITY_SERVER zu nutzen. Diese kann beispielsweise wie folgt konfiguriert sein:

localhost:2551;localhost:2552

Es werden jeweils Server und Port beider Securityserver Knoten getrennt durch ein Semikolon hinterglegt.

View Me   Edit Me