Netzwerksegmentierung: dezentral ↔ zentral

Status: dokumentiert/vorbereitet — reale Firewall-/Netzwerktopologie einer Bank ist hier nicht nachstellbar, dies beschreibt das übliche Muster und die Rolle des WAS-Admins darin.

Zwei Netzwerkwelten

Die Anzeige nennt Netzwerk "(dezentral/zentral)" explizit als eigenen Bindeglied-Punkt. Gemeint sind zwei getrennt verwaltete Zonen:

Dezentral: die Linux-/Liberty-Welt — Web-/App-Server, meist in einem klassischen Rechenzentrums- oder Cloud-Netz, oft mit DMZ/Internal-Zonen-Aufteilung, von einem "normalen" Netzwerk-/Server-Team betrieben.
Zentral: das Mainframe-Netz — historisch eigene Netzwerktechnik (u. a. VTAM/SNA-Erbe, auch wenn heute TCP/IP-Zugriff über DDF Standard ist), eigenes Betriebsteam, oft striktere Change-Prozesse, weil hier das Kernbanksystem hängt.

Der WAS-Admin sitzt an der Nahtstelle: Liberty läuft dezentral, muss aber gezielt zentrale Endpunkte (DB2-for-z/OS-DDF, ggf. weitere Mainframe-Services) erreichen können — nicht durch ein offenes Netz, sondern durch einzeln beantragte, eng gefasste Firewall-Regeln.

Typische Port-/Verbindungstabelle

Verbindung	Port	Richtung	Zweck
Client → Liberty HTTP	19080 (dev, siehe `docs/10-installation-konfiguration/`)	eingehend	normaler Web-Traffic, i. d. R. hinter einem Load Balancer
Client → Liberty HTTPS	19443	eingehend	wie oben, TLS-terminiert am Server (siehe `docs/60-security-lifecycle/`)
Liberty → LDAP	389 (bzw. 636 mit TLS)	ausgehend	Authentifizierung/Rollen, siehe `docs/60-security-lifecycle/`
Liberty → DB2 for z/OS (DDF)	446 (unverschlüsselt) / 447 (SSL, Standard für produktionsnahe Umgebungen)	ausgehend, dezentral → zentral	Kerndaten-Zugriff, siehe `01-db2-fuer-zos-und-mainframe-grundlagen.md`
Liberty → IBM MQ (Messaging-HA)	1414 (Standard-Listener-Port, konfigurierbar)	ausgehend	siehe `docs/70-high-availability/`

Jede Zeile "Liberty → zentral" bedeutet in der Praxis: eigenes Firewall-Ticket, oft mit Quell-/Ziel-IP-Paar, Port und manchmal sogar Zeitfenster für die Freigabe — nicht einfach "Internet-Zugriff an, Rest zu".

Warum das für WAS-Admin-Alltag relevant ist (nicht nur einmalig beim Aufbau)

Neue Liberty-Instanz/neuer Knoten (z. B. für die HA-Demo in docs/70-high-availability/): jede neue Quell-IP, die gegen DB2 for z/OS sprechen soll, braucht potenziell eine eigene Firewall-Freigabe — das ist einer der Gründe, warum Skalierung im Mainframe-nahen Umfeld nicht "einfach mehr Container starten" ist, sondern koordiniert werden muss.
DVIPA/Sysplex Distributor (siehe Doc 01): aus Firewall-Sicht oft nur eine Ziel-IP, obwohl dahinter mehrere physische DB2-Mitglieder stehen — vereinfacht die Netzwerk-Freigabe, verschleiert aber die tatsächliche HA-Topologie, wenn man sie nicht kennt.
Troubleshooting: bei SQLCODE -30081 (siehe Doc 01) ist die Netzwerksegmentierung oft die erste Verdachtsstelle — ein WAS-Admin, der die Zonen-Grenze kennt, kann gezielt fragen ("ist die Firewall-Regel Liberty-Subnetz → DDF-Port 447 noch aktiv, gab es eine IP-Änderung?"), statt pauschal "die Datenbank ist down" zu melden.

Zusammenfassung des Ausbaustufe-4-Kapitels

Die drei Dokumente dieser Ausbaustufe zusammen (01, 02, 03 hier) decken die Anzeigen-Zeile "Bindeglied zwischen Java-Entwicklung und Administration von WebSphere Application Server sowie DB2 für z/OS, Netzwerk (dezentral/zentral)" vollständig ab: was DB2 for z/OS technisch/organisatorisch von gewöhnlichen Datenbanken unterscheidet, wie der Vier-Parteien-Prozess konkret abläuft (inkl. server.xml-Beispiel), und welche Netzwerkgrenzen dabei eine Rolle spielen.

⌂ Cockpit