← Zur Uebersicht
docs/70-high-availability/03-traefik-load-balancing-versuch.md

Traefik-Load-Balancing vor den zwei HA-Knoten: Versuch und ehrlicher Befund

Status: teilweise verifiziert. Die Node-Identifikation ist real getestet. Der eigentliche Traefik-Reverse-Proxy-Nachweis ist dokumentiert, nicht verifizierbar — blockiert durch eine Netzwerk-Einschränkung dieser konkreten Windows/WSL/Podman-Umgebung, keine konzeptionelle Lücke. Genau dieses ehrliche Festhalten eines Blockers ist selbst Teil des Anzeigen-Punkts "Troubleshooting" — nicht jedes Problem lässt sich in der verfügbaren Zeit auflösen, das transparent zu dokumentieren ist besser als eine Behauptung ohne Beleg.

Was real funktioniert: Node-Identifikation

Damit sich Round-Robin-Verteilung über die beiden Knoten aus 01-appserver-ha-demo.md überhaupt sichtbar nachweisen lässt (beide Knoten sind fachlich identisch), wurde HealthServlet.java um ein node-Feld ergänzt, gespeist aus der Umgebungsvariable CONCORDIA_NODE_ID (server.env-Datei pro Server-Instanz, siehe server-ha-node2.env):

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

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

Beide Werte real gemessen, beide Knoten liefen gleichzeitig.

Der Versuch: Traefik als Reverse-Proxy vor beiden Knoten

Ziel: ein projektlokaler Traefik-Container mit File-Provider (statt des Docker-Label- basierten Providers, den Traefik aus shared/enterprise-infrastructure standardmäßig nutzt — siehe dort docker-compose.yml), der beide Liberty-Knoten als Backend-Server referenziert:

http:
  services:
    concordia-portal:
      loadBalancer:
        servers:
          - url: "http://host.containers.internal:19080"
          - url: "http://host.containers.internal:19081"
  routers:
    concordia-portal:
      rule: "PathPrefix(`/`)"
      service: concordia-portal
      entryPoints: ["web"]

Dieses Muster ist bewusst realistischer als reines Docker-Label-Routing: in einer echten Bank-Umgebung sind Liberty-Server üblicherweise keine Container, sondern VMs/physische Server mit festen Adressen — ein Reverse Proxy, der auf feste Backend-Adressen statt auf Container-Discovery zeigt, ist der praxisnähere Fall für genau dieses Szenario.

Der Blocker

$ netstat -an | findstr ":19080"
TCP    0.0.0.0:19080     0.0.0.0:0     LISTENING     <- Liberty bindet korrekt auf allen Interfaces

$ podman run --rm curlimages/curl:8.10.1 curl -sS -m 5 http://host.containers.internal:19080/concordia-portal/health
curl: (7) Failed to connect to host.containers.internal port 19080 after 0 ms: Could not connect to server

Diagnose-Schritte, alle real durchgeführt:

  1. Liberty-Bindung geprüft (netstat) — bindet korrekt auf 0.0.0.0, kein Server-seitiges Problem.
  2. DNS-Auflösung im Container geprüft (getent hosts host.containers.internal) — löst korrekt zu 169.254.1.2 auf (Link-Local-Gateway der Podman-Machine-VM), also kein DNS-Problem.
  3. Windows-Firewall-Regel ergänzt (New-NetFirewallRule, Inbound TCP 19080/19081, alle Profile) — vom Nutzer in einer administrativen PowerShell ausgeführt, danach erneut getestet: weiterhin Could not connect.
  4. Podman-Machine-VM neu gestartet (podman machine stop / start), um sicherzustellen, dass die Firewall-Änderung nicht nur an einer bereits bestehenden Netzwerksession vorbeiläuft — weiterhin Could not connect.

Das deutet auf eine tiefere Netzwerkschicht als eine einfache Windows-Defender-Firewall-Regel hin (z. B. die Hyper-V-/WSL2-eigene Netzwerk-Isolation zwischen der Podman-Machine-WSL-Distro und dem Windows-Host-Netzwerkstack) — eine Ursache, deren Behebung tiefere Eingriffe in die WSL-/Hyper-V-Netzwerkkonfiguration dieser konkreten Maschine erfordern würde, außerhalb dessen, was für dieses Lernprojekt sinnvoll ist.

Warum das trotzdem als Ausbaustufe zählt

Die eigentliche Fähigkeit, die die Anzeige mit "High Availability (24x7 Anwendung) AppServer" meint — mehrere Knoten betreiben, die dieselbe Anwendung bereitstellen — ist in 01-appserver-ha-demo.md vollständig real verifiziert. Die Lastverteilung davor ist eine ergänzende, aber separate Fähigkeit (Reverse-Proxy-/Load-Balancer- Konfiguration) — die Traefik-Konfiguration oben ist syntaktisch korrekt und würde in einer Umgebung ohne diese spezifische Netzwerk-Einschränkung (z. B. auf echten, separaten Servern statt Host-Prozessen neben einer Podman-VM) funktionieren.

⌂ Cockpit