WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

HTTP-Topologie konfigurieren

Hier erfahren Sie, wie Sie WebSphere Message Broker in Ihre HTTP-Topologie integrieren können und wie sich verschiedene Konfigurationen auf Lastausgleich, Failover und Verwaltung auswirken.

Die Konfiguration von WebSphere Message Broker in den einzelnen in diesem Abschnitt beschriebenen Szenarios hängt sehr von dem von Ihnen ausgewählten HTTP-Empfangsprogramm ab. Sie können zwischen brokerweiten Empfangsprogrammen und Ausführungsgruppen-Empfangsprogrammen (integrierten Empfangsprogrammen) wählen. Informationen zu den Unterschieden zwischen diesen Empfangsprogrammen, zu ihrer Konfiguration und der Zuordnung von Ports finden Sie im Abschnitt HTTP-Empfangsprogramme.
Lernen Sie allgemeine HTTP-Topologien kennen und sehen Sie, wie WebSphere Message Broker jeweils konfiguriert wird. Machen Sie sich die Auswirkungen Ihrer Auswahl hinsichtlich Topologie und Brokerkonfiguration klar. Im folgenden sind verschiedene Szenarios mit zunehmender Komplexität aufgeführt.
  1. Szenario eins: Einzelnes System, einzelner Broker. Benutzerfreundlichkeit hat die oberste Priorität. Ein Lastausgleich ist relativ wichtig. Systemfailover und hoher Durchsatz haben keine hohe Priorität
    Einzelner Broker, brokerweites Empfangsprogramm

    In diesem Szenario wird ein brokerweites Empfangsprogramm verwendet, das an Port 7080 empfangsbereit ist. Die gesamte HTTP-Kommunikation von den Clients wird von diesem Empfangsprogramm verarbeitet. Für den Lastausgleich werden zusätzliche Nachrichtenflussinstanzen innerhalb der Ausführungsgruppen eingesetzt, außerdem wird ausführungsgruppenübergreifend in den Nachrichtenflüssen dieselbe URL verwendet.

    Stärken:
    • Einfache Verwaltung und Web-Service-Erkennung: alle eingehenden Anforderungen (sowie alle Antworten) werden über einen einzelnen Port für HTTP (und gegebenenfalls einen zweiten Port für HTTPS) weitergeleitet.
    • Lastausgleich zwischen Nachrichtenflüssen und Ausführungsgruppen: eine Anforderung an einen bestimmten Web-Service (URL) kann von jedem für die Bearbeitung dieser URL registrierten Nachrichtenfluss verarbeitet werden. Die Nachrichtenflüsse (MF1, MF2) können in verschiedenen Ausführungsgruppen (ExGp1, ExGp2) enthalten sein, die Anforderungslast wird zwischen den Nachrichtenflüssen verteilt. Wie gewöhnlich können innerhalb der einzelnen Ausführungsgruppen nach Bedarf zusätzliche Instanzen der verschiedenen Nachrichtenflüsse implementiert werden. Diese Konfiguration bietet eine skalierbare Lösung mit Lastausgleich und einem gewissen Ausgleichbetrieb. Bei einem Fehler einer Ausführungsgruppe setzen die anderen Ausführungsgruppen die Verarbeitung der Arbeitslast fort, während die erste Ausführungsgruppe neu gestartet wird.
    Schwachstellen:
    • Failover: Single Point of Failure (Broker oder System). Ist ein Systemfailover implementiert, so ist es kompliziert: die sekundäre Maschine muss die IP-Adresse der primären Maschine übernehmen.
    • Aktivitätspartitionierung: Es erfolgt keine Partitionierung zwischen den vom Broker verwalteten Aktivitäten.
    • Durchsatz: Ein einzelnes Empfangsprogramm verarbeitet alle HTTP- und HTTPS-Nachrichten, die über zwei Ports auf dem Broker gesendet werden. Da es nur diesen einen Verarbeitungs- und Fehlerbehandlungspunkt gibt, können Engpässe entstehen, wenn ein hoher Nachrichtendurchsatz erforderlich ist.
  2. Szenario zwei: Einzelnes System, einzelner Broker. Ein hoher Durchsatz hat die oberste Priorität. Systemfailover und Lastausgleich haben keine hohe Priorität
    Einzelner Broker, integrierte Empfangsprogramme

    In diesem Szenario werden zur Verbesserung des Nachrichtendurchsatzes Ausführungsgruppen-Empfangsprogramme verwendet.

    Stärken:

    • Hoher Durchsatz: Nachrichtenflüsse können in verschiedenen Ausführungsgruppen implementiert werden, die HTTP- (oder HTTPS-)Nachrichten können folglich von mehreren Empfangsprogrammen an mehreren Ports verarbeitet werden, um die Anforderungen bezüglich eines hohen Durchsatzes zu erfüllen.
    • Einfache Konfiguration: Diese Empfangsprogramme kommunizieren direkt mit dem HTTP-Transportnetz. Es sind keine zwischengeschalteten Warteschlangen erforderlich.
    • Aktivitätspartitionierung: Vom Broker verwaltete Aktivitäten werden in verschiedene Ausführungsgruppen partitioniert.
    Schwachstellen:
    • Failover: Single Point of Failure (Ausführungsgruppe, Broker oder System). Ist ein Systemfailover implementiert, so ist es kompliziert, die sekundäre Maschine muss die IP-Adresse der primären Maschine übernehmen.
    • Es müssen sowohl Empfangs- als auch Antwortknoten in denselben Nachrichtenfluss aufgenommen werden oder aber es müssen verschiedene Nachrichtenflüsse in derselben Ausführungsgruppe implementiert werden, damit sie dasselbe Empfangsprogramm verwenden. Zusammengehörige Eingabe- und Antwortnachrichten müssen von demselben Port verarbeitet werden.
  3. Szenario drei: Mehrere Systeme, mehrere Broker, Failover hat die oberste Priorität; Lastausgleich und Sicherheit sind auch wichtig.
    Mehrere Broker und Server

    In diesem Szenario werden brokerweite Empfangsprogramme verwendet. Außerdem gibt es einen Server, der für den Lastausgleich sorgt und als Netzdispatcher fungiert. Dadurch wird die Clientschnittstelle vereinfacht. Die Konfiguration von Nachrichtenflüssen und Ausführungsgruppen wird unter mehreren Brokern repliziert. Der Lastausgleichsserver ist so konfiguriert, dass er den brokerübergreifenden Mehrprozessorbetrieb eines Hochverfügbarkeitsclusters (HACMP) verwaltet.

    Stärken:

    • Lastausgleich: Dadurch, dass es einen Server gibt, der als Netzdispatcher fungiert und für den Lastausgleich sorgt, bietet dieses Szenario mehr Möglichkeiten für die Lastverteilung.
    • Failover: Dadurch, dass die Broker auf mehrere Systeme verteilt sind, ist sowohl ein System- als auch ein Broker-Failover möglich.
    • Vereinfachte Clientkonfiguration: Der Lastausgleichsserver stellt die zentrale Anlaufstelle für Clients dar.
    Schwachstellen:
    • Komplexität: Dieses Szenario ist komplex. Allerdings kann die Komplexität vor den Clients verborgen und zentral verwaltet werden.
Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:22:44


TaskthemaTaskthema | Version 8.0.0.5 | bc55240_