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 ClusterCommunication hinzugefügt werden:

set JAVA_OPTS=%JAVA_OPTS% -Dcluster.node="FSS_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 FSS_01 gewählt. Andernfalls kann auch FSS_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.

Konfigurationsdateien im Securityserver fürs Debuggen anpassen

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="FSS_01" muss in beispielsweise FSS_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

Sollen alle Knoten für die Ver- und Entschlüsselung verwendet werden, so muss ein Loadbalancer vorgeschaltet und in der Global Property SECURITY_SERVER_BASE_URL angegeben werden.

Soll der neue FSS-Knoten nicht für die Ent- und Verschlüsselung, sondern zum Beispiel nur für die neue UI verwendet werden, so ist hier keine Anpassung notwendig.

View Me   Edit Me