Bei der Gestaltung des
WebSphere MQ-Netzwerkes,
das Ihrer
WebSphere Event Broker-Brokerdomäne zugrundeliegt, sollten
Sie sich überlegen, ob Sie Cluster nutzen möchten.
Warteschlangenmanager-Cluster
haben zwei wesentliche Vorteile:
- Reduzierte Systemverwaltung
Cluster benötigen nicht so viele Definitionen
für den Aufbau eines Netzwerkes. Sie können Ihr Netzwerk schneller und einfacher
installieren.
- Verbesserte Verfügbarkeit und besserer Lastausgleich
Wenn Instanzen
derselben Warteschlange auf mehrere Warteschlangenmanager definiert werden,
haben Sie den Vorteil, dass die Auslastung durch die Cluster verteilt wird.
Sie sollten folgende Punkte berücksichtigen, wenn Sie Cluster mit WebSphere Event Broker,
verwenden:
- Für SYSTEM.BROKER-Warteschlangen:
- SYSTEM.BROKER-Warteschlangen werden bei der Erstellung von
WebSphere Event Broker-Komponenten für Sie definiert, jedoch
nicht als Clusterwarteschlangen. Sie sollten dieses Attribut nicht ändern.
- Für Broker, Konfigurationsmanager- und
Benutzernamensserver-Konnektivität:
- Bei der Definition der Warteschlangenmanager, die Ihre Broker,
den Konfigurationsmanager und den Benutzernamensserver zu
einem Cluster unterstützen, können Sie von der vereinfachten Verwaltung der
WebSphere MQ-Cluster profitieren.
Dies kann bei Brokern in einem Brokerverbund von besonderer Bedeutung sein, die
alle WebSphere MQ-Zwischenverbindungen haben müssen.
- Für Nachrichtenfluss-Eingabewarteschlangen:
- Wenn Sie eine Eingabewarteschlange als Clusterwarteschlange definieren,
sollten Sie berücksichtigen, welche Auswirkungen dies auf die Reihenfolge der
Nachrichten bzw. die Segmente einer segmentierten Nachrichten hat. Dies hat
die gleichen Auswirkung wie für jede andere
WebSphere MQ-Clusterwarteschlange. Insbesondere
muss die Anwendung sicherstellen, dass beim Senden segmentierter Nachrichten
alle Segmente von derselben Zielwarteschlange und somit von derselben
Instanz des Nachrichtenflusses im gleichen Broker verarbeitet werden.
- Für Nachrichtenfluss-Ausgabewarteschlangen:
-
- WebSphere Event Broker definiert beim Öffnen einer
Ausgabewarteschlange immer MQOO_BIND_AS_Q_DEF. Wenn Sie erwarten, dass
segmentierte Nachrichten in eine Ausgabewarteschlange gestellt werden oder
eine Serie von Nachrichten von derselben Verarbeitung behandelt werden soll,
müssen Sie bei der Definition dieser Warteschlange DEFBIND(OPEN) angeben. Damit
stellen Sie sicher, dass alle Segmente einer einzelnen Nachricht bzw. alle
Nachrichten in einer Folge in die selbe Zielwarteschlange gestellt und von
derselben Instanz der empfangenden Anwendung verarbeitet werden.
- Wenn Sie Ihre eigenen Ausgabeknoten erstellen, müssen Sie beim
Öffnen der Ausgabewarteschlange MQOO_BIND_AS_Q_DEF angeben und DEFBIND(OPEN),
wenn Sie die Warteschlange definieren, die Reihenfolge der Nachrichten
garantieren oder ein einzelnes Ziel für segmentierte Nachrichten sicherstellen
möchten.
- Für Publish/Subscribe:
-
- Handelt es sich bei der Zielwarteschlange einer Veröffentlichung um
eine Clusterwarteschlange, müssen Sie den Nachrichtenfluss des
Publish/Subscribes in allen Brokern auf den
Warteschlangenmanagern im Cluster implementieren. Ein Cluster stellt
jedoch keine Failover-Funktionen für die Topologie und Funktionen der
Brokerdomäne zur Verfügung. Wenn ein Broker, auf den eine Nachricht
veröffentlicht wird bzw. bei dem sich ein Subskribent registriert, nicht verfügbar
ist, wird die Verteilung der Veröffentlichung oder Registrierung nicht von
einem anderen Broker übernommen.
- Wenn ein Client eine Subskription bei einem Broker registriert, der
auf einem Warteschlangenmanager aktiv ist, der Mitglied eines Clusters ist,
übersendet der Broker eine Proxy-Registrierung an seine Nachbarstationen
innerhalb der Brokerdomäne. Die Details der Registrierung werden dabei
nicht für andere Mitglieder des Clusters zugänglich gemacht.
Im Handbuch WebSphere MQ Queue Manager
Clusters finden Sie weitere Beschreibungen über den Einsatz von Clustern
und die Auswirkungen auf Clusterwarteschlangen.