クラスタリングに合わせた Business Process Choreographer のシナリオ

クラスターを使用する Business Process Choreographer のシナリオに関するさまざまな構成オプションおよび考慮事項について説明します。

Business Process Choreographer インスタンスに対して WebSphere® Process Server クラスターを使用する主な利点は以下のとおりです。

構成オプション

Business Process Choreographer を構成する方法は多数あるため、クラスターの構成は、通常、きわめて複雑になります。アプリケーション・サーバーの作成を開始する前に検討するための主なオプションの一部について、以下にその概要を説明します。

WebSphere Process Server セル内のノード数
1 つ以上。すべてのノードは、1 つのデプロイメント・マネージャーから管理します。
各 WebSphere Process Server クラスター内のノード数
1 つ以上。WebSphere の水平方向のクラスタリングにより、サービス可用性と全体のワークロード容量が向上します。
各ノードでのアプリケーション・サーバーの数
1 つ以上。WebSphere Process Server の垂直方向のクラスタリングにより、リソースの使用効率が向上します。
データベース・ホスト
  • 専用サーバー上で、リモート
  • クラスター内のいずれかのアプリケーション・サーバーにローカル
データベースは、(なるべくホット・スタンバイ機能を備えた) 専用サーバー上でホストすることをお勧めします。
アプリケーション・メッセージ・キュー
  • ローカル・キュー
  • リモート・キュー
接続 (デフォルトのメッセージング)
デフォルトのメッセージングを使用する場合は、同じクラスターまたはリモートのクラスター内でメッセージ・エンジンを構成できます。Business Process Choreographer の場合は、他の WebSphere Process Server コンポーネントに使用した手法と同じ手法を使用してください。考えられるシナリオの詳細については、『サービス・アプリケーションをサポートするサーバーまたはクラスターの作成』を参照してください。推奨の構成では、Business Process Choreographer のインストール先クラスターとは別のクラスターでメッセージング・エンジンを稼働します。 この方法は、WebSphere MQ と組み合わせて使用できる中央キュー・マネージャー構成の場合に類似しています。
接続 (WebSphere MQ キュー・マネージャー)
  • 1 つのクラスター内にあるアプリケーション・サーバーのキューをホストする 1 つの中央 (リモート) キュー・マネージャー 通常はこの構成をお勧めします。
  • アプリケーション・サーバーごとに 1 つのローカル・キュー・マネージャー。この場合はフェイルオーバー機能やプロセス内ワークロードの共用機能がありません。
  • ノードごとに 2 つのローカル・キュー・マネージャー、および複数のアプリケーション・サーバー間のワークロードについてバランスを取るために使用する WebSphere MQ クラスタリング。

    異なる Business Process Choreographer インスタンス間でワークロードを配分するには、各アプリケーション・サーバーのビジネス・プロセス・コンテナーが使用するキュー・マネージャーが、同じ WebSphere MQ クラスターのメンバーであることが必要です。この構成ではフェイルオーバー機能が提供されないため、通常はお勧めしません。

クラスター化シナリオを使用する場合は、JMS プロバイダーとしては WebSphere MQ をお勧めしません。
データベース・システム
Cloudscape を除き、サポートされているすべてのデータベースを使用できます。
ホット・スタンバイ・サーバー
ホット・スタンバイ・サーバーのオプションは、以下のとおりです。
  • なし
  • データベース用
  • 中央キュー・マネージャー用

クラスター・タイプ: このトピックでは、異なる 2 種類のクラスター について言及します。WebSphere クラスター は、アプリケーション・サーバーをグループ化してワークロードを共有し、サービス可用性を向上させます。WebSphere MQ クラスター (旧称 MQSeries® クラスター) は、WebSphere MQ キュー・マネージャー群をグループ化したもので、プロセス内ワークロード・バランシングを実現するために使用できます。

高可用性

Business Process Choreographer サービスの高可用性を実現するには、以下の項目について検討してください。

垂直クラスタリングによるリソース使用効率の最大化

パフォーマンスを向上させるためには、同じノード上に複数のアプリケーション・サーバー・インスタンスを作成する必要があります。これにより、Business Process Choreographer は使用可能なシステム・リソースを使用できます。

ワークロードの共用

ワークロードを共用するために Business Process Choreographer の異なるインスタンスが必要な場合は、これらのインスタンスが使用するキュー・マネージャー構成は、以下のいずれかにする必要があります。
中央キュー・マネージャー
中央キュー・マネージャーは、Business Process Choreographer が必要とするキューのホストとして動作します。WebSphere クラスター内にあるすべての Business Process Choreographer インスタンスは、同じキューから読み取ります。
WebSphere MQ クラスター
各アプリケーション・サーバーには、2 つのキュー・マネージャーがあります。一方のキュー・マネージャーはローカル・キューのホストとして動作し、メッセージの読み取り用として使用されますが、もう一方のキュー・マネージャーにはホストの対象となるキューが存在せず、メッセージの書き込み専用として使用されます。WebSphere クラスター内にあるすべての Business Process Choreographer インスタンスのすべてのキュー・マネージャーは、WebSphere MQ クラスターの構成メンバーになっています。

ホストの対象となるキューが存在しないキュー・マネージャーにのみメッセージを書き込むと、その結果、メッセージはクラスター内のすべての get キュー・マネージャーに均等に分配されます。 インストール・ウィザードを使用し、ビジネス・プロセス・コンテナーをクラスター上にインストールして構成したら、アプリケーション・サーバーごとに 2 つの接続ファクトリーを手動で変更して、ローカルの get キュー・マネージャーおよび put キュー・マネージャーを指すようにする必要があります。

Business Process Choreographer データベース

データベースのホスティングは、(なるべくホット・スタンバイ機能を備えた) 専用サーバー上での実行をお勧めします。 データベースの格納先のサーバーは WebSphere セルの外側でも構いませんが、そこにはデプロイメント・マネージャーがアクセスできる必要があります。

データベースの計画を立てる場合は、以下の点を考慮してください。

WebSphere デフォルト・メッセージング JMS プロバイダー

Business Process Choreographer は、クラスタリング、ワークロード管理、フェイルオーバーをサポートする WebSphere デフォルト・メッセージングを使用できます。

以下の 2 つのトポロジーがサポートされています。
  • メッセージング・リソースのホストになっているのは、アプリケーションとは異なるクラスターです。 このクラスターはフェイルオーバー機能を備えているだけではなく、管理オーバーヘッドも少ないため、これは推奨のトポロジーです。 このトポロジーは、WebSphere MQ の中央キュー・マネージャー手法の場合と似ています。
  • メッセージング・リソースとアプリケーションのホストになっているのは、同じクラスターです。 このトポロジーは高性能を発揮するには理想的ですが、管理上の労力が増えます。特に変更の適用時が顕著です。

デフォルト・メッセージングを使用するときに適用する考慮事項の詳細については、『クラスター化環境の構築』を参照してください。

WebSphere MQ

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 クラスター内のすべてのアプリケーション・サーバーを示します。ビジネス・プロセス・コンテナーと一緒に表示されている各アプリケーション・サーバーは、ヒューマン・タスク・コンテナーも保有できます。

この図には、別のサーバー上にある 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 クラスターと並列になっています。 要求はクラスター内の読み取りキュー全体で共有されます。

この図では、アプリケーション・サーバーによって使用されるキュー・マネージャーが WebSphere MQ クラスター内でグループ化され、それがアプリケーション・サーバーの WebSphere クラスターと並列になっている様子を示します。要求はクラスター内の読み取りキュー全体で共有されます。

WebSphere クラスターの作成方法

Business Process Choreographer に対してクラスターを作成するための手順は、いくつかあります。次の手順をお勧めします。

  1. クラスター・メンバーのサーバー・テンプレートである defaultProcessServer テンプレートを使用して、クラスターを作成します。
  2. クラスターにメンバーを追加します。
  3. サービス・アプリケーションに対してクラスターを使用可能にします。
  4. クラスター上で Business Process Choreographer を構成します。
  5. WebSphere MQ を使用していて、WebSphere MQ の構成がローカル・キュー・マネージャーの WebSphere MQ クラスターである場合は、接続ファクトリーを変更する必要があります。 各キュー・マネージャーの名前は異なるため、各複製アプリケーション・サーバーの接続ファクトリーを変更して、クラスター全体にわたる標準的な Business Process Choreographer インストール・ウィザード構成との固有の違いを反映させる必要があります。
関連概念
Business Process Choreographer および Network Deployment

ご利用条件 |


(c) Copyright IBM Corporation 2005, 2006.
本製品では Eclipse テクノロジーが採用されています。(http://www.eclipse.org)