High Availability: Messaging

Status: dokumentiert, nicht live verifizierbar — ein echter IBM-MQ-Cluster/-Queue-Manager ist in dieser Umgebung nicht sinnvoll aufsetzbar (Lizenz/Ressourcenaufwand). Das Referenzprojekt labs/novaris-versicherung-legacy nutzt echtes IBM MQ für seine JMS-Integrationstests (wmqJmsClient-2.0-Feature, siehe dortiges novaris-integration-tests/README.md) — als Beleg, dass die Basis-Anbindung im Workspace bereits verifiziert wurde; HA speziell (Cluster/Failover) ist auch dort nicht abgedeckt.

Zwei unterschiedliche Bedeutungen von "Messaging-HA"

1. Hochverfügbarkeit des Messaging-Systems selbst (IBM MQ als Infrastruktur) — Aufgabe des Messaging-/Infrastruktur-Teams, nicht direkt des WAS-Admins, aber relevant genug, um im Troubleshooting-Gespräch mitreden zu können.
2. Wie Liberty als JMS-Client mit dieser Hochverfügbarkeit umgeht — das ist der Teil, den ein WAS-Admin tatsächlich konfiguriert.

IBM-MQ-seitige HA-Muster (zum Wiedererkennen, nicht zum Selbstbetreiben)

• Multi-Instance Queue Manager: zwei MQ-Server-Instanzen (aktiv/passiv) teilen sich gemeinsamen Storage; bei Ausfall des aktiven Knotens übernimmt der passive automatisch denselben Queue-Manager-Namen.
• Uniform Cluster / Queue-Manager-Cluster: mehrere aktive Queue Manager, Nachrichten werden über Cluster-Queues auf verfügbare Instanzen verteilt — näher am "mehrere gleichzeitig aktive Knoten"-Modell aus 01-appserver-ha-demo.md als am Aktiv/Passiv-Modell oben.

Wie sich das in Libertys server.xml niederschlägt

Anknüpfend an das reale server.xml-Muster aus dem Novaris-Referenzprojekt (novaris-policy-ear/src/main/liberty/config/server.xml, dort mit echtem IBM-MQ-Container verifiziert — siehe Zitat dort):

<jmsQueueConnectionFactory jndiName="jms/concordia/qcf" connectionManagerRef="mqConnMgr">
    <properties.wmqJms
            hostName="${env.CONCORDIA_MQ_HOST}"
            port="${env.CONCORDIA_MQ_PORT}"
            channel="${env.CONCORDIA_MQ_CHANNEL}"
            queueManager="${env.CONCORDIA_MQ_QMGR}"
            transportType="CLIENT"/>
</jmsQueueConnectionFactory>
<connectionManager id="mqConnMgr" maxPoolSize="10"/>

Für HA speziell kommt zusätzlich eine Connection-Name-Liste statt eines einzelnen Hosts zum Einsatz — der JMS-Client versucht die Einträge der Reihe nach, bis einer erreichbar ist (clientseitiges Failover, ergänzend zum serverseitigen MQ-Cluster/Multi-Instance-Setup oben):

<properties.wmqJms
        connectionNameList="mq-node1.concordia-bank.local(1414),mq-node2.concordia-bank.local(1414)"
        channel="${env.CONCORDIA_MQ_CHANNEL}"
        queueManager="${env.CONCORDIA_MQ_QMGR}"
        transportType="CLIENT"/>

connectionNameList statt hostName/port: genau dieser eine Attributwechsel ist der Unterschied zwischen "Verbindung zu einem einzelnen MQ-Knoten" und "Verbindung mit Client-seitigem Failover über mehrere Knoten" — ein Detail, das man kennen sollte, weil es sich leicht überliest, wenn man nur die einfache hostName-Variante aus Tutorials kennt.

Bezug zur Netzwerksegmentierung

Wie bei DB2 for z/OS (siehe docs/40-bindeglied-dev-ops-db2-netzwerk/03-netzwerksegmentierung.md): jeder zusätzliche MQ-Knoten in der connectionNameList bedeutet potenziell eine weitere Firewall-Freigabe (Port 1414 bzw. der konfigurierte Listener-Port) — Messaging-HA ist also nicht nur eine Liberty-Konfigurationsfrage, sondern berührt dieselbe Vier-Parteien-Koordination wie die DB2-Anbindung.