WS-Notification in einer Clusterumgebung

WebSphere Application Server bietet die Möglichkeit, Server in einem Cluster zu gruppieren, sodass die Anwendung vor dem Ausfall eines einzelnen Servers geschützt (hohe Verfügbarkeit) bzw. die Workload der Anwendung auf mehrere äquivalente Server verteilt werden kann (Lastausgleich). Der Service Integration Bus (SIB) kann in einem Anwendungs-Server-Cluster, abhängig davon, ob Sie den Cluster für hohe Verfügbarkeit, Lastausgleich oder beides benötigen, verschiedenartig konfiguriert werden. Beispielsweise können Sie auswählen, wie viele Messaging-Engines im Cluster konfiguriert werden (angefangen bei einer bis hin zur Anzahl der Server im Cluster). Außerdem können Sie den Server (sofern vorhanden) auswählen, von dem eine bestimmte Messaging-Engine im übernommen werden soll, wenn der primäre Server ausfällt (Failover).

Ein gebräuchliches Verfahren ist, eine 1-zu-N-Stammgruppenrichtlinie für eine Messaging-Engine zu konfigurieren, bei der es eine einzige Messaging-Engine im Cluster gibt, die auf jeden anderen Server im Cluster verschoben werden kann, falls der Host-Server ausfällt. Auf dieser Weise wird sichergestellt, dass der der Messaging-Engine zugeordnete Status (z. B. Ereignisbenachrichtigungen und Subskriptionen) den Anwendungen auch dann zur Verfügung steht, falls eine bestimmte Hardwarekomponente ausfällt.

Topologie mit Lastausgleich

In dieser Topologie sorgt der Administrator dafür, dass die Anforderungen von Clientanwendungen auf mehrere Server in der Zelle verteilt werden, ohne dabei einen bestimmten Server zu überlasten. Dies setzt voraus, dass alle WS-Notification-Servicepunkte des WS-Notification-Service als identisch betrachtet werden können, insbesondere dass alle Topic-Namespaces an jedem WS-Notification-Servicepunkt des Brokers verfügbar sind.

Die in WebSphere Application Server spezifische WS-Addressing-Unterstützung im Proxy-Server stellt sicher, dass Web-Service-Anforderungen, die eine Affinität zu einer bestimmten Messaging-Engine haben (z. B. für Nachrichtenflüsse zum Wiederaufnehmen und oder Löschen einer Subskription) an den Server zurückgeleitet werden, in dem sich die Messaging-Engine befindet.

Die folgende Abbildung zeigt eine Konfiguration einer Clusterumgebung, die für Lastausgleich konfiguriert ist. Anforderungen von drei unterschiedlichen Clientanwendungen werden von einem WAS-Proxy-Server empfangen, und jede Anforderung wird an einen anderen Anwendungsserver weitergeleitet. Die Informationen zu jeder Anforderung werden von jeder Messaging-Engine in einer separaten Datenbank gespeichert. WAS-spezifischer WS-Addressing-Code im Proxy-Server protokolliert, welcher Server welche Anforderung empfangen hat, und leitet jede nachfolgende Anforderung an den richtigen Anwendungsserver weiter.

Abbildung 1. Beispiel für eine Topologie mit Lastausgleich
Diese Abbildung beschreibt die Topologie mit Lastausgleich.

Topologie mit hoher Verfügbarkeit

In dieser Topologie erstellt der Administrator einen Cluster von Servern mit einer einzigen Messaging-Engine und einem WS-Notification-Servicepunkt, um sicherzustellen, dass bei einem Ausfall des Servers, der die Messaging-Engine enthält, die von dieser Engine verwalteten Ressourcen (Subskriptionen, Ereignisbenachrichtigungen) für die fernen Anwendungen verfügbar bleiben. Die Messaging-Engine wird so konfiguriert, dass sie von den Servern im Cluster übernommen werden kann (Failover), um einen Betrieb mit hoher Verfügbarkeit zu gewährleisten.

Der WS-Notification-Servicepunkt wird auf jedem Server im Cluster implementiert. Die Ressourcen (Subskriptionen, Publisher-Registrierungen und Pull-Punkte) werden in der Messaging-Engine verwaltet. Um eine Anforderung auszuführen, stellt der Servicepunkt eine Verbindung zu dem Server her, in dem die Messaging-Engine derzeit ausgeführt wird.

Der Proxy-Server von WebSphere Application Server ist ein spezieller Typ von Anwendungsserver, der den ersten Einstiegspunkt für Anforderungen in das Unternehmen darstellt. Bei WS-Notification wird ein Proxy-Server meistens als Front-End für einen Cluster von Anwendungsservern verwendet. Von dieser Position aus verteilt er die ersten Anforderungen (z. B. Ereignisbenachrichtigungen) gleichmäßig auf die Server im Cluster. Einige WS-Notification-Anforderungen (z. B. das Erstellen einer Subskription) stellen eine Affinität zu einer bestimmten Messaging-Engine her. Wenn nachfolgende Anforderungen, die sich auf diese Ressource beziehen, vom Proxy-Server empfangen werden, werden diese an den Server weitergeleitet, in dem die entsprechende Messaging-Engine derzeit ausgeführt wird, selbst wenn sich dieser Server nach dem Erstellen der Ressource aufgrund eines Ausfalls geändert hat.

Die in WebSphere Application Server spezifische WS-Addressing-Unterstützung im Proxy-Server stellt sicher, dass Web-Service-Anforderungen, die eine Affinität zu einer bestimmten Messaging-Engine haben (z. B. für Nachrichtenflüsse zum Wiederaufnehmen und oder Löschen einer Subskription) an den Server zurückgeleitet werden, in dem sich die Messaging-Engine befindet.

Die folgende Abbildung zeigt eine Konfiguration einer Clusterumgebung, die für hohe Verfügbarkeit konfiguriert ist. Anforderungen von Clientanwendungen werden von einem Proxy-Server von WebSphere Application Server empfangen und an einen Anwendungsserver in einem Cluster weitergeleitet. WAS-spezifischer WS-Addressing-Code im Proxy-Server protokolliert, welcher Server die Anforderung empfangen hat. Die Informationen über die Anforderung werden von der Messaging-Engine für den Cluster in einer Datenbank gespeichert. Wenn der Anwendungsserver ausfällt, nimmt ein anderer Server im Cluster seinen Platz ein. Der WS-Addressing-Code im Proxy-Server leitet nachfolgende Anforderungen an den Ersatzanwendungsserver um.

Abbildung 2. Beispiel für eine Topologie mit hoher Verfügbarkeit
Diese Abbildung beschreibt die Topologie mit hoher Verfügbarkeit.

Topologie mit Lastausgleich und hoher Verfügbarkeit

Diese Topologie ist eine Kombination der Topologie mit Lastausgleich und der Topologie mit hoher Verfügbarkeit. In dieser Topologie gibt es mehrere Messaging-Engines im Cluster (wobei die Anzahl der Messaging-Engines kleiner-gleich der Anzahl der Server ist). Erste Anforderungen, die vom Proxy-Server empfangen werden, werden gleichmäßig auf die Server im Cluster verteilt, die WS-Notification-Servicepunkte haben. Nachfolgende Anforderungen für eine Ressource, die von dieser Anforderung (d. h. einer Subskription) erstellt wurde, werden an die affine Messaging-Engine zurückgeleitet, selbst wenn diese von einem anderen Server im Cluster übernommen wird.

Dies ist beispielsweise der Fall, wenn sich mehrere Messaging-Engines im Cluster aufgrund eines Failover derzeit in einem Server befinden. In diesem Fall bleibt es wichtig, dass der Servicepunkt eine Verbindung zur richtigen Messaging-Engine herstellt.

Die folgende Abbildung zeigt eine Konfiguration einer Clusterumgebung, die für hohe Verfügbarkeit und Lastausgleich konfiguriert ist. Dieser Cluster enthält drei Anwendungsserver. Zwei dieser Server verwenden dieselbe Messaging-Engine, der dritte Server eine andere. Eine Anforderung von einer Clientanwendung wird von einem WAS-Proxy-Server empfangen und anschließend an einen der Anwendungsserver weitergeleitet, die sich eine Messaging-Engine teilen. WAS-spezifischer WS-Addressing-Code im Proxy-Server protokolliert, welcher Server die Anforderung empfangen hat. Der Anwendungsserver fällt aus, und einer der beiden anderen Server nimmt seinen Platz ein. Der WS-Addressing-Code im Proxy-Server leitet nachfolgende Anforderungen für eine Ressource, die von der ersten Anforderung (d. h. einer Subskription) erstellt wurde, an den 'überlebenden' Anwendungsserver weiter, der dieselbe Messaging-Engine verwendet.

Abbildung 3. Beispiel für eine Topologie mit hoher Verfügbarkeit und Lastausgleich
Diese Abbildung veranschaulicht eine Topologie mit hoher Verfügbarkeit und Lastausgleich.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjwsn_scen456
Dateiname:cjwsn_scen456.html