クラスターを使用する Business Process Choreographer のシナリオに関するさまざまな構成オプションおよび考慮事項について説明します。
Business Process Choreographer インスタンスに対して WebSphere® Process Server クラスターを使用する主な利点は以下のとおりです。
Business Process Choreographer を構成する方法は多数あるため、クラスターの構成は、通常、きわめて複雑になります。アプリケーション・サーバーの作成を開始する前に検討するための主なオプションの一部について、以下にその概要を説明します。
異なる Business Process Choreographer インスタンス間でワークロードを配分するには、各アプリケーション・サーバーのビジネス・プロセス・コンテナーが使用するキュー・マネージャーが、同じ WebSphere MQ クラスターのメンバーであることが必要です。この構成ではフェイルオーバー機能が提供されないため、通常はお勧めしません。
クラスター・タイプ: このトピックでは、異なる 2 種類のクラスター について言及します。WebSphere クラスター は、アプリケーション・サーバーをグループ化してワークロードを共有し、サービス可用性を向上させます。WebSphere MQ クラスター (旧称 MQSeries® クラスター) は、WebSphere MQ キュー・マネージャー群をグループ化したもので、プロセス内ワークロード・バランシングを実現するために使用できます。
Business Process Choreographer サービスの高可用性を実現するには、以下の項目について検討してください。
パフォーマンスを向上させるためには、同じノード上に複数のアプリケーション・サーバー・インスタンスを作成する必要があります。これにより、Business Process Choreographer は使用可能なシステム・リソースを使用できます。
ホストの対象となるキューが存在しないキュー・マネージャーにのみメッセージを書き込むと、その結果、メッセージはクラスター内のすべての get キュー・マネージャーに均等に分配されます。 インストール・ウィザードを使用し、ビジネス・プロセス・コンテナーをクラスター上にインストールして構成したら、アプリケーション・サーバーごとに 2 つの接続ファクトリーを手動で変更して、ローカルの get キュー・マネージャーおよび put キュー・マネージャーを指すようにする必要があります。
データベースのホスティングは、(なるべくホット・スタンバイ機能を備えた) 専用サーバー上での実行をお勧めします。 データベースの格納先のサーバーは WebSphere セルの外側でも構いませんが、そこにはデプロイメント・マネージャーがアクセスできる必要があります。
データベースの計画を立てる場合は、以下の点を考慮してください。
Business Process Choreographer は、クラスタリング、ワークロード管理、フェイルオーバーをサポートする WebSphere デフォルト・メッセージングを使用できます。
デフォルト・メッセージングを使用するときに適用する考慮事項の詳細については、『クラスター化環境の構築』を参照してください。
Business Process Choreographer は、WebSphere MQ キューを使用して要求の受信や応答の送信を 実行できます。クラスター化シナリオを使用する場合は、JMS プロバイダーとしては WebSphere MQ をお勧めしません。WebSphere MQ を使用する場合は、Business Process Choreographer がインバウンドとアウトバウンドのサービス呼び出しのために使用する Service Component Architecture (SCA) のデフォルト・メッセージングを引き続き構成する必要があります。Business Process Choreographer のホストとして動作する各アプリケーション・サーバーには、次のいずれかのオプションが必要です。
中央キュー・マネージャー
中央キュー・マネージャーをすべてのキューに対して使用すると、管理が容易になります。1 つのキュー・マネージャーが、ヒューマン・タスクおよびビジネス・プロセスのすべての複製コンテナーによって使用されます。 ただし、中央キュー・マネージャーを使用すると、高可用性システムでのホスティングが必要な Single Point of Failure が発生します。
次の図に、別のサーバー上にある 1 つの中央キュー・マネージャーを使用する WebSphere クラスター内のすべてのアプリケーション・サーバーを示します。ビジネス・プロセス・コンテナーと一緒に表示されている各アプリケーション・サーバーは、ヒューマン・タスク・コンテナーも保有できます。
WebSphere MQ クラスタリングを使用しないローカル・キュー・マネージャー
この例では、Business Process Choreographer の標準的なスタンドアロン構成を示しています。各ビジネス・プロセス・コンテナーには、ローカル・キュー・マネージャーが 1 つずつ存在します。 この方法では、プロセス内ワークロード共用機能もフェイルオーバー・サービスの可用性も提供されません。
WebSphere MQ クラスタリング
この複雑な手法はお勧めしません。 この手法では、WebSphere クラスター内の Business Process Choreographer サービスに対してプロセス内ワークロード共用機能がサポートされます。クラスター内のすべてのビジネス・プロセスは、UNIX® ワークステーションか Windows® ワークステーションのいずれか一方のみの上で実行する必要があります。UNIXサーバーと Windowsサーバーを組み合わせた場合は動作しません。
各アプリケーション・サーバーには、2 つのローカル・キュー・マネージャーが必要です。1 つはメッセージの書き込み用で、もう 1 つはメッセージの読み取り用です。すべてのキュー・マネージャーは、同じ WebSphere MQ クラスターのメンバーになります。Windows システムの場合は、すべてのキュー・マネージャーが同じバインディング・プロトコルを使用する必要があります。UNIX システムの場合は、put キュー・マネージャーと get キュー・マネージャーが異なるプロトコルを使用する必要があります。例えば、すべての put キュー・マネージャーがバインディング・プロトコル (プロセス間通信) を使用し、すべての get キュー・マネージャーがデフォルトのクライアント (TCP/IP) プロトコルを使用するようにキューの接続ファクトリーを変更できます。
Windows システムおよび UNIX システムの場合、ローカルのバインディング・トランスポート・タイプを使用すると、クライアント・トランスポート・タイプを使用した場合より約 5% 高速になりますが、ローカルの WebSphere MQ キュー・マネージャーを停止するためにアプリケーション・サーバー全体を停止する必要があるという影響があります。
WebSphere クラスター内の各ビジネス・プロセス・コンテナーは、それ専用のキュー・マネージャーに合わせてカスタマイズする必要があります。
WebSphere MQ クラスター内の複数のキュー・マネージャーによってクラスター・リポジトリーを構成することをお勧めします。
次の図には、アプリケーション・サーバーが使用するキュー・マネージャーが WebSphere MQ クラスター内でグループ化される仕組みを示します。キュー・マネージャーの WebSphere MQ クラスターは、アプリケーション・サーバーの WebSphere クラスターと並列になっています。 要求はクラスター内の読み取りキュー全体で共有されます。
Business Process Choreographer に対してクラスターを作成するための手順は、いくつかあります。次の手順をお勧めします。
(c) Copyright IBM Corporation 2005, 2006.
本製品では Eclipse テクノロジーが採用されています。(http://www.eclipse.org)