クラスター環境での WS-Notification

WebSphere® Application Server は、アプリケーションを単一サーバー (高可用性) の障害から守れるように、またアプリケーション・ワークロードを多くの等価サーバーに広げられるように (ワークロード・バランシング)、クラスター内でサーバーをグループ化する機能を提供します。 サービス統合バスは、高可用性、ワークロード管理、または両方のどれをクラスター化するかに応じて、いろいろな構成のアプリケーション・サーバー・クラスター内でも構成可能です。例えば、クラスター内で構成されるメッセージング・エンジンの数 (1 からクラスターのサーバー数まで) を選択することができます。また、1 次サーバーが失敗した場合、特定のメッセージング・エンジンがフェイルオーバーするサーバー (ある場合) を選択することができます。

一般的なパターンでは、クラスター内に単一メッセージング・エンジンがある、One of N コア・グループ・ポリシーがメッセージング・エンジン用に構成されます。 また、そのホスト・サーバーが失敗した場合には、 メッセージング・エンジンはクラスター内の他のサーバーに移動できます。これにより、ハードウェアの特定の部品に障害が発生した場合でも、メッセージング・エンジンと関連する状態は、アプリケーションでは使用可能です (例えば、イベント通知およびサブスクリプション)。

ロード・バランシングのトポロジー

このトポロジーでは、管理者は、特定のサーバーに過負荷をかけることなく、 クライアント・アプリケーションの要求をセル内の複数のサーバーで共有することを目的とします。 このためには、WS-Notification サービスのすべての WS-Notification サービスのサービス・ポイントが同じだと考えられる、 特に、すべてのトピック名前空間がブローカーのすべての WS-Notification サービス・ポイントで使用可能であることが必要です。

プロキシー内の WebSphere Application Server 特有の WS-Addressing サポートにより、特定のメッセージング・エンジン (例えば、再開または破棄サブスクリプション・フロー) と親和性のある Web サービスの要求が、メッセージング・エンジンの位置するサーバーに確実に転送されるようになっています。

以下の図は、ロード・バランス用に構成されたクラスター化環境の構成を示しています。3 つの異なるクライアント・アプリケーションからの要求は、WebSphere Application Server プロキシー・サーバーによって受信され、各要求は、異なる単一アプリケーション・サーバーへ転送されます。各要求に関する情報は、個々のデータベースのそれぞれのメッセージング・エンジンによって格納されます。 プロキシー内の WebSphere Application Server 特定の WS-Addressing コードは、各要求を受信したサーバーを記録し、それぞれの後続の要求を正しいアプリケーション・サーバーに経路指定します。

図 1. ロード・バランスが取られたトポロジーの例
この図は、ロード・バランスが取られたトポロジーを示しています。

高可用性のトポロジー

このトポロジーでは、メッセージング・エンジンを含むサーバーで障害が発生した場合、そのサーバーが管理するリソース (サブスクリプション、イベント通知) がリモート・アプリケーションに対して引き続き使用可能となるように、管理者が、単一のメッセージング・エンジンおよび WS-Notification サービス・ポイントを含むサービスのクラスターを作成します。 メッセージ・エンジンは、 高可用性を提供するため、クラスター内の様々なサーバー間でフェイルオーバーするように構成されています。

WS-Notification サービス・ポイントは、クラスター内の各サーバーにデプロイされます。 リソース (サブスクリプション、パブリッシャー登録、およびプル・ポイント) はメッセージング・エンジンに保持されるため、要求を実行する場合、サービス・ポイントは、メッセージング・エンジンが現在実行しているサーバーへの接続を作成します。

WebSphere Application Server プロキシー・サーバーは、要求のエントリーの初期点をエンタープライズに提供するアプリケーション・サーバーの特殊なタイプです。WS-Notification の場合、プロキシー・サーバーが、クラスター内で複数のサーバーに渡って初期要求 (イベント通知など) のワーク・ロード・バランスを取るアプリケーション・サーバーのクラスターのフロントエンドとして頻繁に使用されます。一部の WS-Notification 要求 (サブスクリプションの作成など) は特定のメッセージング・エンジンでアフィニティーを作成するため、そのリソースに関連する後続要求がプロキシー・サーバーによって受信されると、関連性のあるメッセージング・エンジンに現在ホストされているサーバーに経路指定されます (リソースが作成された後、障害が原因でサーバーが変更された場合でも)。

プロキシー内の WebSphere Application Server 特有の WS-Addressing サポートにより、特定のメッセージング・エンジン (例えば、再開または破棄サブスクリプション・フロー) と親和性のある Web サービスの要求が、メッセージング・エンジンの位置するサーバーに確実に転送されるようになっています。

以下の図は、高可用性用に構成されたクラスター化環境の構成を示しています。クライアント・アプリケーションからの要求が WebSphere Application Server プロキシー・サーバーによって受信され、クラスター内のアプリケーション・サーバーに転送されます。プロキシー内の WebSphere Application Server 特定の WS-Addressing コードは、どのサーバーが要求を受信したかを記録します。要求に関する情報は、クラスターのメッセージング・エンジンによってデータベースに格納されます。 アプリケーション・サーバーに障害が発生すると、このアプリケーション・サーバーの処理は、クラスター内の別のサーバーに引き継がれます。プロキシー内の WS-Addressing コードは、後続要求を置換アプリケーション・サーバーに再度経路指定します。

図 2. 高可用性トポロジーの例
この図は、高可用性のトポロジーを示しています。

ロード・バランシングされた高可用性のトポロジー

このトポロジーは、ロード・バランス型トポロジーと高可用性トポロジーを組み合わせたものです。 このトポロジーには、クラスター内に複数のメッセージング・エンジンがあります (メッセージング・エンジンの数はサーバーの数以下です)。 プロキシー・サーバーが受信する初期要求は、クラスター全体で、WS-Notification サービス・ポイントをホストするサーバーに対するロード・バランスが取られています。要求によって作成されるリソース用の後続の要求 (すなわちサブスクリプション) は、 クラスター内の異なるサーバーで故障が発生した可能性のある場合でも、アフィン変換メッセージング・エンジンへ転送されます。

これは、フェイルオーバーの結果としてクラスター内の複数のメッセージング・エンジンが単一サーバーに現在配置されているケースを含んでいることに注意してください。 このケースでは、サービス・ポイントが、正しいメッセージング・エンジンに接続されていることが重要です。

以下の図は、高可用性およびロード・バランス用に構成されたクラスター化環境の構成を示しています。このクラスターには、3 つのアプリケーション・サーバーがあります。これらのサーバーのうち 2 つは同じメッセージング・エンジンを使用し、3 つ目のサーバーは、異なるメッセージング・エンジンを使用します。クライアント・アプリケーションからの要求は WebSphere Application Server プロキシー・サーバーによって受信され、メッセージング・エンジンを共有するアプリケーション・サーバーの 1 つに転送されます。プロキシー内の WebSphere Application Server 特定の WS-Addressing コードは、どのサーバーが要求を受信したかを記録します。アプリケーション・サーバーが障害を起こし、その場所が、他の 2 つのサーバーの 1 つに占領されます。プロキシー内の WS-Addressing コードは、初期要求で作成されたリソースの後続要求 (つまり、サブスクリプション) を同じメッセージング・エンジンを使用する障害を起こしていないアプリケーション・サーバーに経路指定します。

図 3. 高可用性およびロード・バランスが取られたトポロジーの例
この図は、ロード・バランスが取られた高可用性トポロジーを示しています。

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjwsn_scen456
ファイル名:cjwsn_scen456.html