High Availability: AppServer (24x7-Anwendung)

Status: verifiziert. Zwei echte, gleichzeitig laufende Liberty-Prozesse, beide erreichbar, beide mit identischem LDAP-basiertem Auth-/Rollen-Ergebnis.

Warum zwei Knoten der Kern von "24x7" sind

Ein einzelner Liberty-Prozess ist ein Single Point of Failure: Neustart nach einem Konfigurationswechsel, ein Absturz, oder einfach ein OS-Patch auf dem darunterliegenden Server bedeutet Downtime. Die grundlegende Antwort ist immer dieselbe: mehr als eine Instanz, die dieselbe Anwendung bereitstellt, plus etwas, das den Traffic verteilt/umleitet. Alles Weitere (Session-Replikation, Sysplex-artige Kopplung wie bei DB2 for z/OS, siehe docs/40-bindeglied-dev-ops-db2-netzwerk/) baut auf diesem Grundprinzip auf.

Der reale Zwei-Knoten-Test

Beide Knoten laufen als unabhängige Liberty-Serverinstanzen (Liberty verwaltet mehrere benannte Server innerhalb einer einzigen wlp-Installation, genau dieses Feature wird hier genutzt), gestartet über die Liberty-CLI statt über den liberty-maven-plugin (der verwaltet nur einen Server pro Modul):

cd concordia-portal/target/liberty/wlp/bin

# Knoten 2 anlegen und mit der HA-Variante konfigurieren
./server create concordiaPortalNode2
cp ../../../concordia-portal.war ../usr/servers/concordiaPortalNode2/apps/concordia-portal.war
cp ../../../../src/main/liberty/config/server-ha-node2.xml ../usr/servers/concordiaPortalNode2/server.xml

# beide gleichzeitig starten
export CONCORDIA_LDAP_BIND_PASSWORD="..."
./server start concordiaPortalServer   # Knoten 1, Port 19080/19443
./server start concordiaPortalNode2    # Knoten 2, Port 19081/19444

Reale Ergebnisse, beide Knoten gleichzeitig oben:

$ curl -s http://localhost:19080/concordia-portal/health
{"status":"UP","service":"concordia-portal"}

$ curl -s http://localhost:19081/concordia-portal/health
{"status":"UP","service":"concordia-portal"}

$ curl -s -u "m.bauer:AdminDemo123!" http://localhost:19080/concordia-portal/secure/whoami
{"principal":"m.bauer","isPortalAdmin":true,"isPortalUser":false}

$ curl -s -u "m.bauer:AdminDemo123!" http://localhost:19081/concordia-portal/secure/whoami
{"principal":"m.bauer","isPortalAdmin":true,"isPortalUser":false}

Der entscheidende Beweis liegt in der letzten Zeile: beide Knoten liefern für dieselben Credentials dasselbe Auth-/Rollen-Ergebnis, weil beide gegen dasselbe zentrale LDAP-Verzeichnis prüfen (siehe docs/60-security-lifecycle/02-ldap-registry.md) — kein Knoten hat einen eigenen, potenziell abweichenden Nutzerbestand. Genau das macht die beiden Knoten zu echten, austauschbaren HA-Partnern statt zwei zufällig ähnlichen Servern.

Was für eine echte Produktionsumgebung zusätzlich fehlt

Ein Load Balancer/Reverse Proxy davor (in diesem Workspace bereits als Muster vorhanden: Traefik in shared/enterprise-infrastructure, siehe docs/40-bindeglied-dev-ops-db2-netzwerk/03-netzwerksegmentierung.md) — hier bewusst nicht verdrahtet, weil beide Knoten als Maven-gebaute lokale Prozesse laufen, nicht als Container, und Traefik in diesem Workspace ausschließlich Container über Docker-Labels entdeckt.
Getrennte physische/virtuelle Server statt zwei Prozesse auf demselben Host — sonst schützt die "zweite Instanz" nicht vor einem Hardware-/OS-Ausfall des einzigen Hosts.
Session-Replikation oder zustandslose Anwendung: concordia-portal hält bewusst keinen Server-seitigen Session-Zustand (jeder Request ist über BASIC-Auth unabhängig authentifiziert) — genau deshalb funktioniert der Test oben ohne weitere HA-Mechanik. Eine Anwendung mit HttpSession-Zustand bräuchte zusätzlich Session-Replikation zwischen den Knoten oder eine "Sticky Session"-Konfiguration am Load Balancer.

Weiter mit 02-messaging-ha.md für den zweiten Anzeigen-Punkt ("High Availability Messaging").

⌂ Cockpit