WebSphere® Message
Broker を HTTP トポロジーに統合する方法、またロード・バランシング、フェイルオーバー、および管理を目的としたさまざまな構成の結果について学習します。
このトピックで説明される各シナリオでの
WebSphere Message
Broker の構成は、HTTP リスナーの選択と密接な関係があります。 リスナーは、ブローカー全体のリスナーと実行グループ (組み込み) リスナーのいずれかを選択できます。 これらのリスナーの違い、これらの構成方法、およびリスナーへのポートの割り振り方法については、
HTTP リスナーを参照してください。
一般的ないくつかの HTTP トポロジーと、それぞれの場合に
WebSphere Message
Broker を構成する方法について学習します。 トポロジーの選択とブローカーの構成によって生じる影響について理解してください。 以下のシナリオは、下に行くほど複雑になっています。
- シナリオ 1: 単一のマシン、単一のブローカー。使いやすが最優先。ロード・バランシングは比較的重要。マシン・フェイルオーバーと高いスループットの優先度は高くない。
このシナリオでは、ブローカー全体のリスナーを使用してポート 7080 で listen します。クライアントからのすべての HTTP 通信はこのリスナーによって処理されます。 ロード・バランシングは、実行グループ内にメッセージ・フローのインスタンスを追加することと、実行グループ全体のメッセージ・フローで同じ URL を使用することによって実現されます。
長所:- 管理および Web サービス・ディスカバリーの単純化: すべてのインバウンド要求 (およびすべての応答) は、HTTP の単一ポート (必要に応じて、2 番目は HTTPS) を介してルーティングされます。
- メッセージ・フローおよび実行グループにわたるロード・バランシング: 特定の Web サービス (URL) に対する要求を、その URL を処理するために登録されているメッセージ・フローで処理できます。 メッセージ・フロー (MF1、MF2) は別個の実行グループ (ExGp1、ExGp2) に配置できるため、それらの間で要求のロード・バランシングを行うことができます。 通常どおり、各実行グループ内では、必要に応じて各フローの追加インスタンスをデプロイできます。 この構成では、ある一定レベルのフェイルオーバー機能を備えた、拡張が容易なロード・バランシング・ソリューションを実現できます。ある実行グループで障害が発生しても、その実行グループの再始動中に、他の実行グループが当該ワークロードを引き続き処理できます。
短所: - フェイルオーバー: Single Point of Failure があります (ブローカーまたはマシン)。
マシン・フェイルオーバーを実装する場合には、複雑になります。2 次マシンは、1 次マシンの IP アドレスを引き継ぐ必要があります。
- アクティビティーの区分化: ブローカーによって管理されるアクティビティー間で区分化されません。
- スループット: 1 つのリスナーが、ブローカー上の 2 つのポートを介して送信されるすべての HTTP メッセージおよび HTTPS メッセージを処理します。 プロセスおよびエラー処理のポイントが単一であるため、高いメッセージのスループットが必要な場合に、ボトルネックとなることがあります。
- シナリオ 2: 単一のマシン、単一のブローカー。高いスループットが最優先。マシン・フェイルオーバーとロード・バランシングの優先度は高くない。
このシナリオでは、実行グループ・リスナーを使用してメッセージのスループットを向上させます。
長所:
- 高いスループット: 高いスループットの要件を満たすため、メッセージ・フローを異なる実行グループにデプロイして、HTTP (または HTTPS) メッセージを複数のポート上の複数のリスナーで処理することができます。
- 単純な構成: これらのリスナーは、HTTP トランスポート・ネットワークと直接通信します。中間のキューは必要ありません。
- アクティビティーの区分化: ブローカーによって管理されるアクティビティーは、別個の実行グループに区分化されます。
短所: - フェイルオーバー: Single Point of Failure があります (実行グループ、ブローカー、またはマシン)。 マシン・フェイルオーバーを実装する場合には、複雑になります。1 次マシンの IP アドレスを引き継ぐ 2 次マシンが必要になります。
- 入力ノードと応答ノードの両方を同じメッセージ・フローに含めるか、異なるメッセージ・フローを同じ実行グループにデプロイして、同じリスナーを使用させなければなりません。一致する入力メッセージおよび応答メッセージを、同じポートで処理する必要があります。
- シナリオ 3: 複数のマシン、複数のブローカー。フェイルオーバーが最優先。ロード・バランシングとセキュリティーも重要です。
このシナリオでは、ブローカー全体のリスナーを使用します。 ロード・バランサーおよびネットワーク・ディスパッチャーとして機能するサーバーもあるため、クライアント・インターフェースが単純化されます。 メッセージ・フローおよび実行グループの構成は、複数のブローカーの間で複製されます。また、ロード・バランシング・サーバーは、ブローカー全体で高可用性クラスター・マルチプロセッシング (HACMP™) を管理するように構成されます。
長所:
- ロード・バランシング: ネットワーク・ディスパッチャーおよびロード・バランサーとして機能するサーバーを持つことによって、このシナリオではロード・バランシング機能が強化されます。
- フェイルオーバー: システム全体にブローカーを分散させることによって、マシンとブローカーの両方のフェイルオーバーが可能になります。
- 単純化されたクライアント構成: ロード・バランシング・サーバーによって、クライアントとの接点を単一ポイントにすることができます。
短所: - 複雑さ: クライアントに対しては一元化された場所で管理して複雑さを隠すことができますが、このシナリオは複雑です。