...

WebSphere Process Server V6 構成ガイド - クラスター編 概要 IBM Software Group

by user

on
Category: Documents
34

views

Report

Comments

Transcript

WebSphere Process Server V6 構成ガイド - クラスター編 概要 IBM Software Group
®
IBM Software Group
WebSphere Process Server V6 構成ガイド
- クラスター編
概要
2006年7月1日
日本アイ・ビー・エム株式会社
日本アイ・ビー・エム システムスエンジニアリング 株式会社
© IBM Corporation
この資料は「WebSphere Process Server V6解体新書」(下記関連記事[3])の中の「WebSphere Process
Server構成ガイド」が対象としているWebSphere Process Server V6.0ではサポートされず、V6.0.1で追加さ
れたクラスター構成について解説するものです。関連の深いところは本資料の中で「復習」として取りあげ
ていますが、「WebSphere Process Server構成ガイド」を先に一読されることをお勧めします。
この資料はWebSphere Process Server V6.01.1のもとに作成されています。
前提知識
WebSphere Process Server V6の製品概要を理解していることを前提とします。
関連記事
[1]WebSphere Process Server V6
http://www-06.ibm.com/jp/software/websphere/bi/diamond/v6/wps/
[2]プロセス・インテグレーションの世界へようこそ!
http://www-06.ibm.com/jp/software/websphere/developer/wbi/wpi/
[3]WebSphere Process Server V6解体新書
http://www-06.ibm.com/jp/software/websphere/developer/wbi/diamond/
1
IBM Software Group | WebSphere software
特記事項
この資料に含まれる情報は可能な限り正確を期しておりますが、日本アイ・ビー・エム株式会社による正式なレ
ビューは受けておらず、当資料に記載された内容に関して日本アイ・ビー・エム株式会社が何ら保証をするもの
ではありません。したがって、この情報の利用またはこれらの技法の実施はひとえに使用者の責任においてな
されるものであり、当資料の内容によって受けたいかなる被害に関しても一切の保証をするものではありません
のでご了承ください。当資料は正式なマニュアルをはじめとするドキュメントの補完資料として参照して下さい。
当資料は、製品の特定バージョンを使ってテストをした結果を基に記述しています。
今後のPTF, Fix Pack の適用により動作が当資料に記述された内容とは異なってくる可能性がありますのでご
了承下さい。
2
IBM Software Group | WebSphere software
この資料の内容
基礎知識の復習
WASクラスター
WPSが使用するリソース
WPSの主なリソース(データベース)
WPSで使用されるバス
メッセージング・エンジンの配置
SIBusのメッセージング・エンジンフェイルオーバーとワークロード共用
メッセージング・エンジン(Active/Passive)のローカル配置
メッセージング・エンジン(Active/Passive)のリモート配置
(参考)メッセージング・エンジンのパーティショニング(Active/Active)構成
クラスター構成での負荷分散形態
ビジネス・プロセスの負荷分散のポイント
サービス・コンポーネント概要
WPSのクラスター構成例 1 - プロセスとサービスが同居
WPSのクラスター構成例 2 - プロセスとサービスが別クラスターで稼動
バイディング・タイプによる負荷分散形態の違い
Webサービス・バインディング (SOAP/HTTP)
Webサービス・バインディング (SOAP/JMS)
JMSバインディング
ステートレス・セッションBeanバインディング
SCAバインディング
この資料は WebSphere Process Server V6.0.1(以下WPSと省略します)でサポートが追加されたクラスター
構成について解説するものです。まず、クラスターに入る前に関連の深い事柄について復習します。
次に、メッセージング・エンジンの配置について解説します。
(メッセージング・エンジンについては基礎知識部分で触れますが、WPSが内部で使用するJMSのプロバイ
ダーです)
クラスター構成での負荷分散形態では、ビジネス・プロセスからサービスを呼ぶという形態のアプリケー
ションを配置する際にとりうる構成について解説します。
最後に、サービスの呼ばれ方(SCAのバインディング・タイプ)ごとに負荷分散のしくみがどのようになされる
のかを解説します。
3
IBM Software Group | WebSphere software
基礎知識の復習
基礎知識の復習
ここでは、WPSのクラスターについて解説する前に関連の深い事柄について復習します。
4
IBM Software Group | WebSphere software
WAS クラスター
クラスター
複数のアプリケーション・サーバーで処理を分散し、障害時には、他の
サーバーで処理を引き継ぐ機能
クラスターには「クラスター・メンバー」と呼ばれるアプリケーション・サー
バーを複数定義可能
Web
サーバー
Server
Server
負荷分散
装置
Server
Server
Web
サーバー
Cluster 01
Cluster 02
EJBのWLM
まず、本資料がとりあげる「クラスター」の確認をしましょう。
WebSphere Application Server(以下WASと表記します。)の Network Deploymentエディションでは、高可
用性とスケーラビリティが「クラスター」という機能で提供されます。クラスターは複数のアプリケーション・
サーバーで処理を分散し、障害時には、他のサーバーで処理を引き継ぐことが可能な機能です。
(Workload Management = WLMと呼ばれることもあります。)
WebSphere Process ServerもNetwork Deploymentの上位エディションとなりますので同じ機能が使用でき
ます。
クラスターには「クラスターを構成することで同じJ2EEアプリケーションが稼動するアプリケーションサー
バーを容易に構成することが可能となります。
同じクラスターのメンバー間では、負荷分散・フェイルオーバーがサポートされますので、クライアントから
見ると1つのアプリケーションに対するパフォーマンス・可用性が向上します。
クラスタリング環境で提供されるWLM(Workload Management)機能で代表的なものは、Webコンテナー
に対するWLMとEJBコンテナーのWLMです。WebコンテナーのWLM機能はHTTPリクエストの負荷分散・
障害検知です。負荷分散装置(Edgeコンポーネントのロードバランサーなどが代表的)やWebサーバーの
WPS/WASのプラグインの機能を使用して負荷分散します。SOAP/HTTPプロトコルも同じ仕組みで負荷
分散・障害検知を実施することが可能です。
EJBコンテナーのWLMは、EJBクライアントがクラスター内で稼動するEJBにアクセスするときに負荷分散・
フェイルオーバーの機能を提供します。 このとき、EJBクライアントは、アクセスするEJBとは別プロセスで
稼動する必要があります。(EJBクライアントとEJBコンテナーが同一プロセス上で稼動する場合、全ての
EJBクライアントのリクエストは同一プロセス上のEJBコンテナーへとルーティングされます。)
5
IBM Software Group | WebSphere software
WPSが使用するリソース
データベースとメッセージング・エンジンを使用する
データベース
OS 1
Cell wpsCell01
OS 2
DM
LDAP
Server
CEIDB
ME
NA
BPEDB WPRCSDB
Process
DataStore
メッセージング・エンジン (下記のバス内に存在する)
DM … Deployment Manager
NA … Node Agent
•BPC.<cell_name>.Bus
• SCA.SYSTEM. <cell_name>.Bus
• SCA.APPLICATION. <cell_name>.Bus
•CommonEventInfrastructure_Bus
次に、WPSが使用するリソースについて確認しましょう。
WPSのコンポーネントである個々のアプリケーションは、さまざまなWAS上のリソースを使用します。大きく
分けると、データベース関連とメッセージングシステム関連とがあります。SIBusとはWAS6に内蔵されてい
るメッセージング・システムです(SIBusについて8、9ページをご参照下さい)。SIBusで永続化メッセージを
保管するにはデータベース(DataStore)を使用します。それぞれのリソースが使用される範囲はサーバー、
クラスター、セルで異なります。ヒューマン・タスクを使用する場合、特定のユーザーだけがあるタスクを実
行させることがあります。この場合、ユーザー情報を保管するレジストリーが必要です。WPS環境ではユー
ザーレジストリーとしてローカルOS、LDAP、カスタムレジストリーが使用可能です。
6
IBM Software Group | WebSphere software
WPSの主なリソース(データベース)
セル単位のデータベース
WPRCSDB – レポジトリー・データベース
各種コンポーネントが共通で使用するデータベース
サポートデータベース
– CloudScape(ローカルの場合のみ)
– DB2、Oracle, DB2/zOS-DB2(Network Deployment環境)
CEIDB – CEIイベント・カタログ及びイベント・ストア
CEIサーバーが使用
サポートデータベース
– CloudScape(ローカルの場合のみ)
– DB2、Oracle、DB2/zOS-DB2 (Network Deployment環境)
サーバー単位のデータベース
BPEDB – ビジネス・プロセス・コンテナ用データベース
ビジネス・プロセス、ヒューマン・タスク・マネージャー、ビジネス・ステート・マシンが使用
プロセス・サーバーまたはクラスター単位で1つのデータベース
サポートデータベース
– CloudScape(ローカルの場合のみ)
– DB2、Informix、Oracle、DB2/zOS-DB2、MSSQL
SIBusのメッセージング・エンジン用データベース
メッセージング・エンジン(サーバー単位)ごとに1つのデータベースが必要(*)
サポートデータベース
– CloudScape(ローカルの場合のみ)
– DB2、Informix、Oracle、DB2/zOS-DB2、MSSQL (Network Deployment環境)
WPSでWPRCSDB、CEIDB、BPEDB及びSIBusのメッセージング・エンジンが使用するDataStoreという4種類のデータベー
スが必要です。それぞれの利用単位及びサポートするデータベース製品が異なります。
詳細は製品のシステム要件のページで確認が必要です。
IBM Software - WebSphere Process Server - System requirements
http://www-306.ibm.com/software/integration/wps/sysreqs/
(*) メッセージング・エンジンが使用するデータベースは、スキーマを分ければ一つのデータベースに統合可能。
7
IBM Software Group | WebSphere software
WPSで使用されるバス
SCAの非同期呼び出しで使用
SCA.SYSTEM.<cell_name>.Bus
SOAP/JMSバインディング、SCAバインディングを使用する際に必要に応じて宛先が作成され
る
SCA.APPLICATION.<cell_name>.Bus
JMSバインディングを使用する際に、必要に応じて宛先を作成する
BPC Bus
BPC.<cell_name>.Bus
ビジネス・プロセス・マネージャー、ヒューマン・タスク・マネージャー、ビジネス・ステート・マシン
が使用
バスの代わりにWebSphere MQも使用可能
CEI Event Bus
CommonEventInfrastructure_Bus
イベントの受送信に使用
バスの代わりにWebSphere MQも使用可能
SCA.SYSTEM.<cell_name>.BusとSCA.APPLICATION.<cell_name>.BusはWPSのセルが作成された時点
で定義されています。
それぞれのバス内には少なくとも一つのメッセージング・エンジンが稼動している必要があります。
メッセージング・エンジンを稼動させるサーバー(またはクラスター)は、「バス・メンバー」としてバスに登録
する必要があります。バス・メンバーには、WPSのサーバーだけでなく、同一セル内のWebSphere
Application Server V6 のサーバーも選択することができます。
8
IBM Software Group | WebSphere software
(補足)SIBus
SIBusとは
サービス連携に必要な通信インフラストラクチャーを提供するコンポーネント
SIBusが提供する機能
通信の複雑性を隠蔽しWebサービス間の疎結合を実現
メッセージの同期/非同期通信のサポート
ルーティング及びフォーマット変換などメディエーション機能を提供
メッセージ転送の信頼性、高可用性、ワークロード・マネジメント及びセキュリティ機能を提供
JMSプロバイダ機能を提供
WebSphere MQ/Brokerなど他のESB実装への接続機能を提供
セル
SIBus
バスリンク
WMQ
Web
サービス
JMS
JMS
SIBus
Web
サービス
JMS
JMS
SIBusはWebサービス連携に必要な通信インフラストラクチャーを提供するコンポーネントです。単に「バ
ス」と呼ぶ場合もあります。
SIBusは、WebSphere Application Server V6の機能として提供されており,WPSはSCAやビジネス・プロセ
ス・コンテナーを起動するためにSIBusを使用しています。
SIBusは、以下の機能を提供します:
•
通信の複雑性を隠蔽しWebサービス間の疎結合を実現
SIBusを介してWebサービスの呼び出しが可能です。プロトコル変換機能も提供します。
•
メッセージングの同期/非同期通信のサポート
SIBus内部でプラットフォーム・メッセージングと呼ばれるメッセージング機能を使用し、メッセージ
の転送を行ないます。同期/非同期の転送方法をサポートします。またメッセージ転送の信
頼性を提供します。
•
コンテンツ・ベースのルーティング及びフォーマット変換などメディエーション機能を提供
•
WASの高可用性、ワークロード・マネジメント及びセキュリティ機能を利用可能
SIBusがWASV6に統合されているため、WASが持っているHAマネージャー機能、ワークロード・
マネジメント及びセキュリティ機能を利用可能です。
•
JMSプロバイダ機能を提供
SIBusはJMSプロバイダとしても利用可能です。これはWASV5から提供されている組み込みメッ
セージング・エンジンのWASV6版です、最新のJMS1.2をサポートします、またWASと同一プ
ロセスに稼動するのが特徴です。
•
WebSphere MQ/Brokerなど他のESB実装への接続機能を提供
9
IBM Software Group | WebSphere software
(補足) SIBusのメッセージング・エンジン
バス・メンバー
バスに追加されたアプリケーション・サーバーまたはクラスター
バス・メンバーとして指定されるとMEが自動的に構成される
Server
SIBus
Server
Server
ME
ME
ME
Server
ME
Cluster
WASのアプリケーション・サーバーまたはクラスターをバス・メンバーとして指定できます。
バスはそのメンバーとして追加された、1つ以上の相互に接続されたサーバーのグループです。セルは
WASの論理的な管理単位であり、それはバスの管理単位にもなります。管理者が管理コンソールからセ
ル内のバスを一元的に管理できます。一つのセル内では複数のバスを構成可能です。バス・メンバーとし
てアプリケーション・サーバーまたはクラスターを指定できます。バス・メンバーにはメッセージング・エンジ
ンが構成されます。
10
IBM Software Group | WebSphere software
メッセージング・エンジンの配置
メッセージング・エンジンの配置
WPSのクラスターを構成するときは、WPS内部で使用するメッセージング・エンジンをどこに配置するかと
いうことが重要な考慮点の一つになります。ここでは、メッセージング・エンジンの構成の代表的なパター
ンを紹介します。
メッセージング・エンジンそのものについての詳細の情報は下記にまとめられています。
WPSの設計や運用管理に携わる方に必要な情報ですので、一読されることをお勧めします。
参考資料
[1]WebSphere Application Server V6 管理ガイド - 第3章 SIBus構成
http://www-06.ibm.com/jp/software/websphere/developer/was/wv6/guide/
[2]WAS V6 SIBus 構成ガイド
SOAP/JMS、外部接続、メディエーション編
http://www-06.ibm.com/jp/software/websphere/developer/was/wv6/sibus/soapjms/
11
IBM Software Group | WebSphere software
SIBusのメッセージング・エンジン
フェイルオーバーとワークロード共用
フェイルオーバー
WAS NDが提供するHAマネージャー機能により実現
ワークロード共用
バス・メンバーとしてクラスターを追加
バス・メンバーとしてクラスターを追加
バス・メンバー内に複数のMEを同時に起動し
クラスター内で稼動するMEは1つ
処理を分散、スケーラビリティーの向上
MEが起動しているクラスター・メンバーのプロセス障害
ひとつの宛先に対して複数のMEで処理
時に、MEをフェイルオーバーし、サービスを継続
ME障害時のフェイルオーバーも実現可能
稼働系(Active)と待機系(Passive)のMEは同じデータ・ス
トアを利用
構成情報やデータを引継
Server3
Server3
ME
ME1
ME2
DataStore1
ME2
DataStore2
DataStore1
Server4
ME
Cluster MECluster01
Server4
ME1
Cluster MECluster01
WAS V6では、HAマネージャーによる高可用性の機能を提供しています。このHAマネージャーの機能に
より、サーバー障害時にMEを他サーバーへフェイルオーバーする機能を提供します。
MEをフェイルオーバーする構成にするためには、バス・メンバーとしてクラスターを定義します。クラスター
内の1サーバー上でMEが1つ起動し、他クラスターメンバーのMEが待機状態となります。稼働系と待機系
のMEは同じデータ・ストアを利用し、障害発生時に構成情報やデータを引き継ぎます。通常、クラスター
内の1サーバー上で、ひとつのMEが起動します。このフェールオーバー機能は、InfoCenterでは「サービ
ス統合の高可用性」と表記されています。 クラスターにMEを追加することにより、処理を分散(ワークロー
ド共用)し、スケーラビリティーを向上させることができます。
MEの高可用性と同時に実現可能で、クラスター内の複数のMEもHAマネージャーによるMEフェイルオー
バーが可能です。ワークロード共用はInfoCenterでは「宛先の区画化」「宛先のパーティショニング」とも表
記されています。そのため、この構成を「パーティショニング構成」とも表現している箇所もあります。(ただし、
ワークロード共用の構成でMEのフェイルオーバーが起っている場合、一部のメッセージが取得できない現象が発生
する可能性があるため、この資料ではこの構成はお勧めしていません。詳細はこの後の「 (参考)メッセージング・エン
ジンのパーティショニング(Active/Active)構成」のページで解説します。」)
次のページから、この機能を踏まえてメッセージング・エンジンのパターンを紹介しますが、構成の名前を
わかりやすくするため、下記参考資料の[2]に倣って略称を用いています。メッセージング・エンジンを1つ
稼動させフェイルオーバー機能のみ使用する構成を「Active/Passive」構成、ワークロード共用構成を使
用してメッセージング・エンジンを複数稼動させる構成を「Active/Active」構成と補足的に表わしています。
* 「Active/Passive」は、参考資料[3]のように「Active/Stand-by」と呼ばれる場合もあります。意味的には同
じですので、どちらを使用しても構いません。
参考資料
[1]WebSphere Application Server V6 InfoCenter ワークロード共用
http://publib.boulder.ibm.com/infocenter/ws60help/topic/com.ibm.websphere.pmc.nd.doc/concepts/cjt0013_.html
[2] WebSphere Application Server Network Deployment V6: High Availability Solutions, SG24-6688-00
http://www.redbooks.ibm.com/abstracts/sg246688.html
[3]IBM WebSphere Developer Technical Journal: Basic steps for clustering WebSphere Process Server
http://www-128.ibm.com/developerworks/websphere/techjournal/0604_chilanti/0604_chilanti.html
12
IBM Software Group | WebSphere software
メッセージング・エンジン(Active/Passive)のローカル配置
プロセスが稼動するクラスターとメッセージング・エンジン(ME)が同居
クラスター内でバスにつき1つのメッセージング・エンジンを稼動させる(Active/Passive)
OS 1
Cell wpsCell01
Server1
Process
Service
OS 2
OS 3
ME
BPEDB WPRCSDB
Server2
Process
Service
LDAP
CEIDB
ME
DataStore
Cluster wpsCluster01
これはWPSのクラスター上にビジネス・プロセス・コンテナーを作成し、そこにメッセージング・エンジンを同
居させる配置です。
メッセージング・エンジンは1つのバスにつき1つ 稼動させます。(*)
使用するプロセスが少ないため、メモリー・リソースが少ないマシン用の構成です。
クラスター・メンバーの中の1つでメッセージング・エンジンが稼動するため、稼動するアプリケーションが内
部でメッセージングを多く使用する構造になっていると、メッセージング・エンジン側のクラスター・メンバー
により負荷がかかるという特徴があります。
•SCA.SYSTEM.<cell_name>.Bus, SCA.APPLICATION.<cell_name>.Bus,BPC.<cell_name>.Bus
(CommonEventInfrastructure_Bus)の4つ(CEIを構成していない場合は3つ)のバスにそれぞれメッセージン
グ・エンジンが1つ稼動するので、合計4つ(3つ)のメッセージング・エンジンが稼動します。
13
IBM Software Group | WebSphere software
メッセージング・エンジン(Active/Passive)のリモート配置
プロセスが稼動するクラスターとは別にメッセージング・エンジン(ME)配置用のクラスターを準備
クラスター内でバスにつき1つのメッセージング・エンジンを稼動させる
WPSを導入するOSが2つの場合の図。
OS 3
OS 1
Cell wpsCell01
Server1
Server3
Process
Service
ME
OS 5
LDAP
CEIDB
OS 2
Server2
Process
Service
Cluster wpsCluster01
OS 4
Server4
ME
BPEDB WPRCSDB
DataStore
Cluster MECluster01
メッセージング・エンジンをビジネス・プロセス・コンテナーとは別に作成し、そこへリモート接続することも
可能です。前のページと同様、メッセージング・エンジンは1つのバスにつき1つ 稼動させます。
ビジネス・プロセスが稼動するクラスター内のクラスター・メンバーからはどちらも偏りなくメッセージング・エ
ンジンに接続できます。
専用のクラスターを用意するため、メッセージング・エンジンのローカル構成よりもリソースを多く必要としま
す。
14
IBM Software Group | WebSphere software
(参考)メッセージング・エンジンのパーティショニング(Active/Active)構成
クラスター内で1つのバスのメッセージング・エンジン(ME)が複数同時に稼動する(Active/Active)構成
正確には、Active/Passiveを相互に構成している状態
WebSphere Process Serverにおいて、メッセージング
メッセージング・
メッセージング・エンジンの
エンジンのパーティショニングは
パーティショニングは推奨されない
推奨されない
理由
リクエスト・リプライでリプライ・メッセージが取得できない場合がある
メッセージ順序を保つことができない
OS 1
Cell wpsCell01
Server1
Process
Service
OS 2
MEME
DataStore1
Server2
Process
Service
MEME
DataStore2
Cluster wpsCluster01
さて、ここでメッセージング・エンジンのパーティショニング構成ですが、下記の参照資料にも述べられて
いるように、WPSでは推奨されない構成です。
最も大きな理由は、メッセージングエンジンに送信したアプリケーションがそのメッセージの返りを待ち受
けるというリクエスト・リプライが発生する場合、稼動しているメッセージング・エンジンが複数あるために返り
のメッセージを受け取れなくある場合があることです。(一例を次のページで紹介します。)また、メッセージ
順序が重要になる場合があったときも、パーティショニング構成をしていると順序を保つことはできません。
参照資料
IBM WebSphere Developer Technical Journal: Basic steps for clustering WebSphere Process Server
http://www-128.ibm.com/developerworks/websphere/techjournal/0604_chilanti/0604_chilanti.html
15
IBM Software Group | WebSphere software
(参考)メッセージング・エンジンのパーティショニング(Active/Active)構成
1. メッセージがME1に送られたときにServer1がダウン
2. ME1はServer2にテイク・オーバー
3. Server2にME1,ME2が両方稼動する状態になる
4. MDBの場合、Server2で最初から稼動していたME2からのみメッセージを受けとる
→”1”でME1に送られたメッセージは、Server1が復旧するまで消費されない
Server1
Process
Service
Server1
ME1ME2
DataStore1
Server2
Process
Service
Server2
ME1ME2
Cluster wpsCluster01
図1
Process
Service
DataStore2
Process
Service
ME2
ME1
DataStore1
ME1
ME2
DataStore2
Cluster wpsCluster01
図2
さて、ここでメッセージング・エンジンのパーティショニング構成をとったときに発生する現象について述べ
ます。
メッセージング・エンジンはパーシスタンス・ストアとしてデータストアと呼ばれるデータベースを使用し、シ
ステムダウンの後も継続して処理が行なえるような仕組みになっています。このデータストアはパーティショ
ニング構成の際はメッセージング・エンジンごとに別のデータストアを持ちます。
このような構成で、メッセージがME1に送られたタイミングでサーバーがダウンしたとします。そのとき、そ
のメッセージはME1のデータストアであるDataStore1内に留まります。(1)
そのとき、ME1がダウンしたことをHAマネージャー(*)が検知し、Server2にME1を立ち上げます。(2)
Server2にME1,ME2の二つのMEが稼動した状態になりますが、このとき、 MDBが接続しているMEは、もと
から動いているME2です。そのため、ME1のデータストアに残っているリプライ・メッセージを消費できない
ことになります。
* HAマネージャーは、セル内の全てのJVM上(デプロイメント・マネージャー、ノード・エージェント、アプリ
ケーション・サーバー)で稼動するサービスで、トランザクションやメッセージング・エンジンのフェイルオー
バーを実現します。
16
IBM Software Group | WebSphere software
クラスター構成での負荷分散形態
クラスター構成での負荷分散形態
ここでは、ビジネス・プロセスをクラスター化するときに考えられる負荷分散形態について解説します。
17
IBM Software Group | WebSphere software
ビジネス・プロセスの負荷分散のポイント
クライアント
ビジネス・プロセス
負荷分散のポイント
プロセスAPI経由でプロセス起動
WPS
SCAコンポーネントとしてプロセス起動
モジュール
スタンドアロン参
照またはエクス
ポート
R
I
プロセス
R
I
インポート
WAS
負荷分散のポイント
アプリケーション
WPS上で稼動させるアプリケーションの代表的なものは、BPEL(Business Process Execution Language)
で記述されたビジネス・プロセスです。ビジネス・プロセスはいくつかのサービスを組み合わせて実装され
ます。サービスは、WPS上ではSCA (Service Component Architecture)というAPIを通して呼び出されます。
SCAのコンポーネントはWPSの開発ツールのWID (WebSphere Integration Developer)で開発する際、「モ
ジュール」という単位で管理され、この「モジュール」を元にJ2EEアプリケーション(EAR)が作成され、 WPS
上で稼動できる形になります。
ビジネス・プロセスから呼び出されるサービスは、ビジネス・プロセスと同じモジュール内に配置することも
別モジュールに配置することも可能です。また、J2EEアプリケーションを呼び出すことも可能です。
こういった構造をとるアプリケーションを、負荷分散や高可用性を考慮してクラスター環境で稼動させる場
合、リクエストが分散される箇所が大きく分けて二箇所あります。
一つはビジネス・プロセスそのものへのリクエスト、もう一つはビジネス・プロセスからサービスへのリクエス
トです。
この資料ではこの2箇所の負荷分散や高可用性のポイントを中心にクラスターの構成例について説明して
いきます。
18
IBM Software Group | WebSphere software
(参考)サービス・コンポーネント概要
Java
Java
WSDL
ポート・タイプ
WSDL
ポート・タイプ
インターフェース
リファレンス
SCDL
Java
BPEL
ビジネス
ルール
Human
Task
Selector
インプリメンテーション・タイプ
SCAで取り扱うサービスは、SCAランタイム上で稼動する『サービス・コンポーネント』として定義されます。サービス・コン
ポーネントにはサービスの呼び出し方法、サービスの実装、サービス・コンポーネントから呼び出すその他のサービスなど
の情報が定義されています。
こうしたサービス・コンポーネントの情報はSCDL(Service Component Definition Language)を使ってXML文書に記述され、
そこには『コンポーネント名』、『インターフェース』、『リファレンス』、『インプリメンテーション』といった定義が含まれます。
『インターフェース』と『リファレンス』に関しては、一つに限らず複数個定義することが可能です。
19
IBM Software Group | WebSphere software
WPSのクラスター構成例 1
- プロセスとサービスが同居
OS 1
Cell wpsCell01
Web
サーバー
DM
NA
Server1
Process
Service
負荷分散
装置
OS 3
LDAP
CEIDB
Server2
Web
サーバー
Process
Service
NA
BPEDB WPRCSDB
DataStore
Cluster wpsCluster01
OS 2
DM … Deployment Manager
NA … Node Agent
まず、ビジネス・プロセスとサービスの配置の最も単純な形態から考えていきましょう。
この構成例では、ビジネス・プロセスと呼び出されるサービスが同じサーバー(JVMプロセス)上に同居しています。
これは、マシンリソースが少ないなどの理由で採られる比較的単純なクラスター構成です。この場合、ビジネス・プロセ
スとサービス間のやりとりは基本的に同じサーバー内で完結すると考えていただいて構いません。(内部のフローを正
確に考慮すると、そうでも無い場合もありますが、ここでは割愛します。)
従って、リクエストが分散される箇所としては、クライアントがクラスター内のビジネス・プロセスを呼び出す部分になりま
す。ビジネス・プロセスの呼び出し方は様々で、SCAコンポーネントとして呼び出したり、ビジネス・プロセスのAPIを使
用して呼び出したりします。(*) 上記の図は、最も一般的と考えらえる、サーバー上のサーブレットなどのWebコンポー
ネントからビジネス・プロセスのAPIを呼んだ場合のリクエストを記述しています。
この場合通常のWebアプリケーションと同様、負荷分散装置をWPSのフロント・エンドに配置し、クライアントからのリク
エストを分散させます。さらに、Webサーバー(IBM HTTP ServerやApacheなど)からのリクエストをWPSのプラグインが
クラスターへリクエストを割り振ります。(**)
* ビジネス・プロセスを呼び出す方法については、下記のサンプルコードが参考になります。
Business Process Choreographer Samples
Interaction with Processes
http://publib.boulder.ibm.com/bpcsamp/index.html
** Webサーバーやプラグイン構成の考慮点については下記の資料を参照してください。
WebSphere Application Server V6による基幹システム設計ワークショップ資料
(インフラ設計 1:1構成と1:N構成 P120-)
http://www-06.ibm.com/jp/software/websphere/developer/was/wv6/enterprise/ws/index.html
WPSはWebSphere Application Serverの上位エディションのため、インフラ設計は、WebSphere ASの考え方がほぼそ
のまま適用できます。上記のワークショップ資料以外にもWebSphere AS関係の資料を前提知識として目を通すことを
お勧めします。
20
IBM Software Group | WebSphere software
OS 5
WPSのクラスター構成例 2
- プロセスとサービスが別クラスターで稼動
LDAP
CEIDB
BPEDB WPRCSDB
DataStore
OS 1
OS 3
Cell wpsCell01
Web
サーバー
DM
NA
Server
Server
Process
NA
Service
NA
Server
負荷分散
装置
NA
Web
サーバー
OS 2
Server
Process
Cluster wpsCluster01
サービス呼び出しのタイプ(詳細後述)により負荷分散の仕組みが異なる
Service
OS 4 Cluster wasCluster01
DM … Deployment Manager
NA … Node Agent
次に、ビジネス・プロセスから呼び出されるサービスが別のサーバー(JVMプロセス)配置されたことを考えます。これは、
WPS上から他システム上のサービスを呼び出すような構成の際に採られる構成です。
プロセス側もサービス側もSPOF (Single Point Of Frailer)を避けてクラスター化しています。
このような構成では、サービスをどのように呼び出すかによって負荷分散の仕組みが異なります。
ビジネス・プロセスから別のサーバーにあるサービスを呼び出すためには、いくつかの方法があるため、まずどのよう
な呼び出し方針があるかを次から解説します。
21
IBM Software Group | WebSphere software
バイディング・タイプによる負荷分散形態の違い
バイディング・タイプによる負荷分散形態の違い
ここでは、ビジネス・プロセスとそこから呼び出されるサービスが分散配置されるときの負荷分散形態の違
いについて解説します。
22
IBM Software Group | WebSphere software
SCAのインポート
サービス・モジュール外のサービスを呼び出すための仕組み
WAS
WPS
Web
サービス
SOAP/HTTP
SOAP/JMS
JMS
Process
Stateless
Session Bean
サービス
コンポーネント
サービス・モジュールに対し、どのように外部の
サービス・モジュールに対し、どのように外部の
サービスがバインドされているかを記載
サービスがバインドされているかを記載
サービス・コンポーネントが別のサービスを呼び出す場合、モジュール内にもう一つサービス・コンポーネ
ントを作成し、そのインプリメンテーションにサービスを定義してリファレンス/インターフェース経由で呼
び出すことが可能です。しかし、このやり方だと呼び出されるサービスはサービス・モジュールの内部に配
置せねばならず、分散アプリケーション環境には対応できません。
分散アプリケーション環境でもサービスを呼び出すためには、サービス・モジュール外のサービスを呼び
出すための仕組みが必要です。そのために提供されているのが『インポート』です。インポートを定義する
ことで、サービス・モジュールの外部にあるサービスを呼び出すことができます。インポートには『インポート
名』、『インターフェース』、『esbBinding』を定義します。(インターフェースは複数個定義が可能です。)
インポートの情報は、<インポート名>.importというSCDLに記載されます。インポートには実際の呼び出し
先のバインディング情報を記載します。バインディングの対象は他のSCAサービス・コンポーネント、Web
サービス、EJB Session Bean、JMSなど各種の実装が考えられます。こうした呼び出し先はインポート内
『esbBinding』に定義します。
※ 『esbBinding』はXMLのタグ名です。IDE環境では「Binding」などと記載されています。
23
IBM Software Group | WebSphere software
OS 5
Webサービス・バインディング
(SOAP/HTTP)
LDAP
CEIDB
BPEDB WPRCSDB
行き
帰り
DataStore
OS 1
OS 3
Cell wpsCell01
Web
サーバー
DM
NA
Server
Server
Process
負荷分散
装置1
NA
Service
NA
Server
負荷分散
装置2
NA
Web
サーバー
OS 2
Server
Process
Cluster wpsCluster01
Service
OS 4 Cluster wasCluster01
WPS
WAS
DM … Deployment Manager
NA … Node Agent
Webサービス・バインディングとしてはSOAP/HTTPバインディングとSOAP/JMSバインディングの2つがあります。
ます、SOAP/HTTPバインディングでは、プロセスからサービスへのリクエストのプロトコルとしてはHTTPが使用されま
す。そのため、Webアプリケーションへの負荷分散と同様、負荷分散装置やWebサーバーのWPS/WASのプラグイン
の機能を使用して負荷分散します。
(上の図の負荷分散装置1と2は論理的にわかりやすいように分けて図示していますが、物理的に同じ装置を兼用する
ことが可能です。)
24
IBM Software Group | WebSphere software
行き
帰り
OS 5
Webサービス・バインディング
(SOAP/JMS)
LDAP
CEIDB
BPEDB WPRCSDB
SCA.APPLICATION.<セル名>.Bus内のMEに送信用の宛先を作成しておく
OS 1
DataStore
OS 3
Cell wpsCell01
DM
NA
NA
Server
Server
Process
Server
NA
NA
Cluster wpsCluster01
Server
Service
Process
OS 2
Service
ME
ME
OS 4 Cluster wasCluster01
WPS
WAS
バス内で有効なMEの宛先にリクエストが送信される
DM … Deployment Manager
NA … Node Agent
もう一つのWebサービス・バインディングであるSOAP/JMSバインディングでは、JMSのメッセージング・イン
フラを使用してSOAPメッセージを送信するプロトコルが使用されます。
プロセス側のWSDLファイルには、送信宛先JNDI名やキュー接続ファクトリーJNDI名やJNDIブートストラッ
プアドレスなどの接続情報が含まれています。
「jms:/queue?destination=jms/EJBforSoapJMSQ&amp;connectionFactory=jms/EJBforSoapJMSCF」
サービスは、JMSの宛先に結びついたMDB (Message-driven Bean) 経由で起動されます。MDBはMEに
対してローカルのものが優先してメッセージを消費するため、サービスはMEが稼動しているサーバー側で
のみ稼動することになります。
25
IBM Software Group | WebSphere software
OS 5
JMSバインディング
LDAP
行き
帰り
CEIDB
BPEDB WPRCSDB
送信用の宛先が必要
(バスやWMQの宛先が利用可能)
OS 1
DataStore
OS 3
Cell wpsCell01
DM
NA
Server
Process
Server
ME
NA
Service
ME
OS 2
NA
Server
NA
Server
Service
Process
ME
ME
Cluster wpsCluster01
OS 4 Cluster wasCluster01
WPS
WAS
バス内で有効なMEの宛先にリクエストが送信される
DM … Deployment Manager
NA … Node Agent
JMSバインディングを使用する際に注意しなくてはいけないのは、使用する宛先などのリソースをあらかじ
めサーバー上に定義しておく必要があるということです。JMSバインディングを作成した場合は作成してお
いたJMSリソースの情報をバインディング情報に入力する必要があります。サービスは、JMSの宛先に結び
ついたMDB (Message-driven Bean) 経由で起動されます。MDBはMEに対してローカルのものが優先し
てメッセージを消費するため、サービスはMEが稼動しているサーバー側でのみ稼動することになります。
上記の図は送信用の宛先をサービス(WAS)側のクラスターに、受信用の宛先をプロセス(WPS)側のクラス
ターに作成した例です。
図のように、送信用の宛先をSCA.APPLICATION.<セル名>.Bus内のMEに作成することもできますし、セ
ル内/外の任意のバスのMEの宛先を利用することも、WebSphere MQに定義した宛先を利用することも可
能です。
26
IBM Software Group | WebSphere software
OS 5
ステートレス・セッションBeanバインディング
LDAP
CEIDB
BPEDB WPRCSDB
行き
帰り
DataStore
OS 1
OS 3
Cell wpsCell01
Web
サーバー
DM
NA
Server
Server
Process
NA
Service
NA
Server
負荷分散
装置
NA
Web
サーバー
OS 2
Server
Process
Cluster wpsCluster01
Service
OS 4 Cluster wasCluster01
WPS
WAS
EJBのWLM機能によって負荷分散される
DM … Deployment Manager
NA … Node Agent
ステートレス・セッションBeanバインディングでは、EJBへのリモート・アクセスを簡単に実現できます。
使用するプロトコルは、EJBへリモート・アクセスするときのプロトコルであるRMI/IIOPです。
このとき、負荷分散やフェイル・オーバーは、WASの機能であるEJBのWLM機能で実現されます。
27
IBM Software Group | WebSphere software
OS 5
SCAバインディング(同期呼び出し)
LDAP
CEIDB
BPEDB WPRCSDB
行き
帰り
DataStore
OS 1
OS 3
Cell wpsCell01
Web
サーバー
DM
NA
Server
Server
Process
NA
Service
NA
Server
負荷分散
装置
NA
Web
サーバー
OS 2
Server
Process
Cluster wpsCluster01
WPS
SCA呼び出しもEJBのWLM機能によって負荷分散される
Service
OS 4 Cluster wasCluster01
DM … Deployment Manager
NA … Node Agent
SCAバインディングを使用できるのは、WPS同士での呼び出しになります。(WASV6はSCAの実行環境が
ないため)
SCAバインディングの呼び出しに使用されるプロトコルは、呼び出し方法が同期か非同期かで異なります。
同期呼び出しの場合、SCAバインディングでの通信の内部ではEJBのリモート呼び出しをしているため、
RMI/IIOPを使って通信しています。
28
IBM Software Group | WebSphere software
OS 5
SCAバインディング (非同期呼び出し)
LDAP
CEIDB
行き
帰り
BPEDB WPRCSDB
SCAモジュールのデプロイ時に
SCA.SYSTEM.<セル名>.Bus内のMEに送信用の宛先が作成される
OS 1
DataStore
OS 3
Cell wpsCell01
DM
NA
NA
Server
Server
Process
Server
NA
NA
Cluster wpsCluster01
Server
Service
Process
OS 2
Service
ME
ME
OS 4 Cluster wasCluster01
WPS
バス内で有効なMEの宛先にリクエストが送信される
DM … Deployment Manager
NA … Node Agent
非同期呼び出しの場合、SCAバインディングでの通信はバスを使用したメッセージ通信となります。
ただし、JMSバインディングやSOAP/JMSバインディングのときと違い、 SCAバインディングでは宛先の作成はデプロ
イの際に自動生成されます。
29
IBM Software Group | WebSphere software
まとめ
WebSphere Process Server V6.0.1のクラスター構成
クラスター環境でのメッセージング・エンジンの配置
メッセージング・エンジン(Active/Passive)のローカル配置
メッセージング・エンジン(Active/Passive)のリモート配置
ビジネス・プロセスとサービスが同居する場合と分散配置される場合がある
ビジネス・プロセスとサービスが分散配置される場合は、SCAバインディン
グによって負荷分散方法が異なる
Webサービス・バインディング (SOAP/HTTP)
Webサービス・バインディング (SOAP/JMS)
JMSバインディング
ステートレス・セッションBeanバインディング
SCAバインディング
これまでの内容のまとめです。
30
Fly UP