WebSphere Process Server V6 構成ガイド - クラスター編 概要 IBM Software Group
by user
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&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