Cluster-Umgebung
Einrichtung Cluster-Umgebung
Dieses Dokument beschreibt, wie Sie beim Formularserver mehrere WildFly-Server parallel laufen lassen können. Die Anleitung zeigt dies exemplarisch an zwei parallel laufenden WildFly-Servern.
Einrichtung ohne Docker
WildFly Server
Die Benamung der neuen WildFly Server-Instanzen ist beliebig, die "2" am Ende ist daher nur ein exemplarisches Beispiel.
Anlegen eines WildFly-Users incl. Homeverzeichnis und Gruppenaufnahme wildfly:
Den neuen WildFly-user in die Apache-Gruppe aufnehmen:
WildFly-Ordner kopieren:
Der Besitzer des WildFly-Ordners muss wie folgt angepasst werden:
Innerhalb des neuen WildFly-Verzeichnisses können die folgenden Verzeichnisse oder Dateien gelöscht werden: logs, tmp, artifact_backups
sowie die Datei standalone/configuration/logging.properties
Im neu entstandenen WildFly-Ordner muss die Datei standalone.conf am Ende wie folgt ergänzt werden:
-Deureka.serviceUrl.default=http://localhost:8080/server/api/eureka"
Einfügen einer neuen Property
In der Datei /opt/wildfly2/.formsolutions/general.properties muss noch der folgende Eintrag ergänzt werden:
Diese Property sorgt dafür, dass einzelne Bestandteile nur vom primären WildFly ausgeführt werden.
Aufnahme des neuen WildFlys als Dienst am Beispiel systemctl:
cp wildfly.conf /etc/wildfly2/
cp wildfly.service /etc/systemd/system/wildfly2.service
Die Datei muss dann wie folgt angepasst werden:
Description=The WildFly Application Server
After=syslog.target network.target
Before=httpd.service
[Service]
Environment=LAUNCH_JBOSS_IN_BACKGROUND=1
EnvironmentFile=-/etc/wildfly2/wildfly.conf
User=wildfly2
LimitNOFILE=102642
PIDFile=/var/run/wildfly/wildfly2.pid
ExecStart=/opt/wildfly2/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND
StandardOutput=null
[Install]
WantedBy=multi-user.target
/etc/systemd/system/wildfly2.service (END)
Kopieren der launch.sh:
chmod +x /opt/wildfly2/bin/launch.sh
In der kopierten Datei launch.sh muss dann noch das WildFly-Homeverzeichnis angepasst werden auf /opt/wildfly2
Aktivieren des neuen WildFly als Dienst:
systemctl enable wildfly2.service
Apache
Sofern noch nicht vorhanden muss das Modul lbmethod_bybusyness sowie proxy_balancer installiert werden a2enmod lbmethod_bybusyness proxy_balancer
Anpassungen in allen vhost-ofs-Dateien
<Proxy "balancer://wildflycluster">
BalancerMember "http://localhost:8080" route=1
BalancerMember "http://localhost:9080" route=2
ProxySet stickysession=ROUTEID lbmethod=bybusyness
</Proxy>
Da bei der WildFly-Konfiguration für die Ports ein Offset von 1000 angegeben wurde, ergibt sich für den zweiten Cluster ein Port von 9080.
Des Weiteren müssen die ProxyPass- und ProxyPassReverse-Einträge auf den Balancer wie folgt umgestellt werden:
ProxyPassReverse /servlet balancer://wildflycluster/servlet
Eintrag in der Datei kndb_settings.inc.php:
und zum Abschluss noch den Apache neu starten.
Mit Docker-Umgebung
Apache
Es müssen zwei neue Apache-Module installiert werden. Dies sind lbmethod_bybusyness und proxy_balancer.
Dazu öffnen Sie bitte die Datei '/opt/docker/fs/web/image/' und ändern den Eintrag in
in
Anpassungen in allen vhost-ofs-Dateien
<Proxy "balancer://wildflycluster">
BalancerMember "http://wildfly:8080" route=1
BalancerMember "http://wildfly:8080" route=2
ProxySet stickysession=ROUTEID lbmethod=bybusyness
</Proxy>
Des Weiteren müssen die ProxyPass- und ProxyPassReverse-Einträge auf den Balancer wie folgt umgestellt werden:
ProxyPassReverse /servlet balancer://wildflycluster/servlet
Eintrag in der Datei kndb_settings.inc.php
WildFly
Duplizieren von Verzeichnissen
Damit wir für den zweiten WildFly Server einzelne Bestandteile abschalten können, bekommt in der Docker-Umgebung jeder ein eigenes Properties-Verzeichnis. Dazu kopieren wir das bestehende Verzeichnis wie folgt:
Leider ist es nicht möglich, dass sich die beiden WildFly Server die Deployment-Verzeichnisse teilen. Daher kopieren Sie bitte das Deployment-Verzeichnis wie folgt:
Anpassungen an den Properties von wildfly2
Mit Ausnahme des primären WildFly Servers muss in den general.properties ein weiterer Eintrag hinzugefügt werden:
In unserem Beispiel erfolgt dies in der /opt/docker/fs/wildfly/properties2/general.properties
Docker-compose.yml
Sollte bislang nur ein WildFly-Container vorhanden sein, ist es sinnvoll den WildFly-Container in wildfly1 umzubenennen.
Anschließend kopieren wir den WildFly-Block und fügen diesen erneut ein und benennen den kopierten WildFly-Knoten wildfly2.
Neben der Anpassung der Volume-Angaben für die Properties und Deployments sollte auch das gemountete Verzeichnis für den neuen WildFly Container angepasst werden.
Das Beispiel unten zeigt den entsprechenden Abschnitt
- ./logs/wildfly2:/opt/jboss/wildfly/standalone/log
- ./secure_html:/srv/secure_html
- ./wildfly/config:/opt/jboss/wildfly/standalone/configuration
- ./wildfly/deployments2:/opt/jboss/wildfly/standalone/deployments
- ./wildfly/properties2:/opt/jboss/.formsolutions
Nach Abschluss der Konfiguration muss der neue Container gestartet werden und der Apache neu gestartet werden. Gegebenenfalls vorhandene Skripte müssen dahingehend ergänzt werden, dass der neue WildFly gestartet und gestoppt wird.
Wichtige Hinweise für das Einspielen von Updates in der Cluster-Lösung
- Es müssen vor dem Ausführen des Updates alle WildFly-Container gestoppt werden.
- Nach Ausführen des Installers muss der Inhalt des deployment-Verzeichnisses in allen Containern ersetzt werden.
- Mit Ausnahme der clusterPrimaryNode-Property müssen alle neu einzuführenden Properties in allen WildFly-Containern eingeführt werden.
- Die entsprechenden Skripte für Starten und Stoppen müssen so angepasst werden, dass diese alle WildFly-Container miteinbeziehen.