Comments
Description
Transcript
のシステム設計 WESB 1 ISE. Web
06. WESBのシステム設計 WESBのシステム設計 WESBのシステム設計 ISE. Webインフラストラクチャー Webインフラストラクチャー 中島 由貴 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 1 06. WESBのシステム設計 WESBのシステム設計 Disclaimer 当資料で提供する技術情報は、各製品の出荷前コードに基づくものを含みま す。 この資料は日本アイ・ビー・エム株式会社ならびに 日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレビューを 受けておりません。 当資料は、資料内で説明されている製品の仕様を保証するものではありません。 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2006 年11月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様 が変わる可能性があるのでご注意下さい。 今後国内で提供されるリリース情報は、対応する発表レターなどでご確認くださ い。 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 2 06. WESBのシステム設計 WESBのシステム設計 このセッションの目的 ミッション・クリティカルな環境におけるWESBシステム設計に必要な 知識の習得 WESBシステム・トポロジー設計に影響するWESBコンポーネントを理解する WESBコンポーネントの高可用性・拡張性機能を理解し、WESBシステム・ト ポロジー設計に必要な知識を習得する WESBシステム構築の注意点を確認する 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 3 06. WESBのシステム設計 WESBのシステム設計 Agenda １．WESBシステム設計の考慮点 2. WESB高可用性、拡張性機能 3. トポロジー設計 4. 導入・構成のHints&Tips 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 4 06. WESBのシステム設計 WESBのシステム設計 1.WESBシステム設計の考慮点 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 5 06. WESBのシステム設計 WESBのシステム設計 非機能要件の検討 機能要件と非機能要件 WESBのインフラ設計においては、非機能要件も重要 サービス、サービス・クライアントとの通信形態の定義も重要 機能要件/業務要件 アプリケーション 要件 データ要件 接続先の種類もインフラ設計に 影響 この章では、WESBトポロジー の可用性、拡張性が中心 非機能要件 性能・品質要件 制約 9パフォーマンス 9信頼性(RASIS) 9セキュリティー 9運用管理 9予算 9スケジュール 9スキル 9配置場所/環境 9既存システム 9準拠する標準/規約 WESBはWASをベースとしているので、WASと同様の非機能要件の考慮が必要 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop インフラ設計においては、機能要件/業務要件だけでなく、非機能要件も重要になります。こ の章では、WESBトポロジーを検討するうえで重要となる可用性、拡張性を中心にお話します。 また、WESBは、複数のサービス、サービス・クライアントを柔軟に接続し、その仲介者となり ますので、その接続先のサービス、サービス・クライアントとの通信形態もインフラ設計に大き な影響を与えます。事前にどのような種類のサービスやサービス・クライアントと接続するのか を定義することが重要です。 尚、WESBはWASをベースとしていますので、WASと同様の非機能要件の考慮が必要となります。 WASのインフラ設計については、下記のワークショップ資料もご参照ください。 DeveloperDomainワークショップ資料「WebSphere Application Server V6による基幹システム設 計ワークショップ資料」-「インフラ設計」 http://www-06.ibm.com/jp/software/websphere/developer/was/wv6/enterprise/ws/ 6 06. WESBのシステム設計 WESBのシステム設計 WESBのコンポーネント WESBにおいて管理が必要になるコンポーネント WESBはWAS+SCA CEIも利用することが可能 SCAの 機能 管理コンソール Import Component Messaging Engines Export Component SCA.SYSTEM bus SCA.APPLICATION bus Mediation Component EVENT bus Common Base Event Browser CEI Server CEIの 機能 WESB server 業務DB LoggingDB MEDB1 MEDB2 MEDB3 EVENTDB 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 上記は、WESBに含まれているコンポーネントです。WESBは、WASの機能プラスSCAのランタイム としての機能を持っています。SCAの非同期通信においては、メッセージング・エンジンを使用 しますので、メッセージング・エンジンと、そのデータストアとして使用するデータベースの管 理が必要です。また、WESBはCEI (Common Event Infrastructure) の機能を使用することも可能 です。CEIもメッセージング・エンジンを使用しますので、メッセージング・エンジンと、デー タストアの管理が必要です。 つまり、WESBを使用する場合には、アプリケーション・サーバーだけでなく、メッセージン グ・エンジンとそのデータストアであるデータベースを意識して管理することが重要です。 スタンドアロン・サーバーでは、データベースは自動的にcloudscapeデータベースがセット アップされます。スタンドアロン・サーバーでは、すべてのコンポーネントが1つのJVM上で稼動 します。ただし、高可用性や拡張性を意識した本番環境における、複数台のサーバーを使用した 環境においては、アプリケーション・サーバーのクラスタリングだけでなく、メッセージング・ エンジンの高可用性や、cloudscape以外のデータベースを使用したデータベースの高可用性を検 討する必要があります。 7 06. WESBのシステム設計 WESBのシステム設計 使用するコンポーネントの検討 通信方式の相違 同期・非同期の通信方式の違いにより、使用されるコンポーネントが異なる WESBのシステム設計は、メディエーション・モジュールの設計と関連 CEIの利用の有無 Web Service Client Web Service EAR Mediation Module Service Component Export JMS Mediation Flow Component Import Service Componet Java Component JMS Import EIS EIS ・Exportの種類 ・同期・非同期の 通信形態 コンポーネントが使用 するリソース(DB、 JMS) コンポーネント接続の 同期・非同期の通信 形態 ・Importの種類 ・同期・非同期の 通信形態 Eventの生成の有無 Event通知の方法(同 期・非同期) 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop では、どのような場合に各コンポーネントを使用するのでしょうか。 WESBの各コンポーネントの使用の有無は、サービス・クライアント、サービス、また、モ ジュール間の通信方式と、CEIの使用の有無によって決まります。 通信方式としてJMSなどの非同期通信を使用する場合には、メッセージング・エンジンを使用 します。したがって、メディエーション・モジュールのバインディングの設計とWESBのシステム 設計は依存関係があります。 また、CEIを使用したEventの管理を行う場合には、Event関連のコンポーネントを設計・管理 が必要です。 8 06. WESBのシステム設計 WESBのシステム設計 同期通信の通信方式 SOAP/HTTP通信 SCA(同期)通信 WESBサーバー1 WASサーバー1 Web Service SOAP/HTTP Mediation Module binding Web Service Client SOAP/HTTP Mediation Flow Component WESBサーバー2 Mediation Module SCA binding (同期) Mediation Flow Component IIOP Web Service SOAP/HTTP binding WASサーバー2 Web Service SOAP/HTTP 同期通信では、バスは使用しない 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop SOAP/HTTP通信の場合は、エクスポート作成時に、Webサービス・クライアントが使用するWSDL、 リクエストを受け付けるルーター・サーブレットが生成されます。また、インポート作成時に、 呼び出しを行うサービスのWSDLから必要なEJB (Stateless Session Bean) が生成されます。 メディエーション・モジュール間の通信に使用されるSCA (同期) 通信を行う場合は、IIOPを 使用しての同期通信を行います。 SOAP/HTTP通信やSCA (同期)通信を行う場合は、SCAバスを使用しませんので、バス構成を考慮 する必要はありません。 9 06. WESBのシステム設計 WESBのシステム設計 非同期通信の通信方式 SOAP/JMS通信 JMS通信 非同期通信では、バスを使用 SCA(非同期)通信 WESBサーバー1 WESBサーバー2 Mediation Module WASサーバー1 JMS Client JMS binding Mediation Flow Component Mediation Module SCA binding (非同期) Mediation Flow Component Web Service SOAP/JMS binding WASサーバー2 SOAP/JMS Web Service JFAP ME1 ME2 送信宛先 受信宛先 ME3 ME4 送信宛先 受信宛先 受信宛先 受信宛先 SCA.SYSTEM or APPLICATION Bus 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop SOAP/JMS、JMS、SCA(非同期)通信の場合は、バスを使用した非同期通信が行われます。 SOAP/JMS通信で必要な宛先は、メディエーション・モジュールのインストール時にSCA.SYSTEM バス上に自動生成されます。SOAP/JMSにおける受信宛先は、事前に作成するのではなく、リクエ ストごとに生成・削除されるという特徴があります。 SCA (非同期) 通信で必要な宛先も、メディエーション・モジュールのインストール時に SCA.SYSTEMバス上に自動生成されます。 SCA (非同期) 通信における受信宛先は、永続キューと して作成されます。 JMS通信では、エクスポート、インポートのどちらにおいても、JMSアプリケーションやWMQの キューといったメッセージング・リソースと接続するための送信/受信宛先をSCA.APPLICATIONバ ス上に作成する必要があります。 各通信方式の詳細は下記ワークショップ資料が参考になりますので、ご参照ください。 DeveloperDomainワークショップ資料「WebSphere Enterprise Service Bus V6アナウンスメン ト・ワークショップ資料」-「WebSphere ESBシステム構成」 http://www-06.ibm.com/jp/software/websphere/developer/bi/wesb/v6/workshop/ 10 06. WESBのシステム設計 WESBのシステム設計 2.WESB高可用性、拡張性機能 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 11 06. WESBのシステム設計 WESBのシステム設計 高可用性・拡張性を検討するコンポーネント SCA稼動環境として、高可用性・拡張性を検討するコンポーネント WESBアプリケーション・サーバー メッセージング・エンジン データベース WESB server Mediation Component Import Component 非同期通信に おいて必要 WESB (WAS) server Messaging Engines SCA.SYSTEM bus SCA.APPLICATION bus Export Component MEDB1 MEDB2 CEIやAdapterを使用する場合は、 関連するコンポーネントについて別途検討が必要 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop WESBの中心機能であるメディエーション・モジュール(SCAアプリケーション)の稼働環境の高 可用性、拡張性を検討する場合、下記3つのコンポーネントを考慮する必要があります。 まず、メディエーション・モジュールの実行環境としての、WESBのアプリケーション・サー バーです。メディエーション・モジュールの高可用性・拡張性は、通常のJ2EEアプリケーション と同様にWASのクラスタリング機能を用いて実現します。 エクスポート、インポート、また、メディエーション・モジュール内において、非同期通信を 行う部分がある場合には、メッセージング・エンジンの高可用性・拡張性を検討する必要があり ます。メッセージング・エンジンの高可用性・拡張性については、WASのSIBusのクラスタリング 機能で実現します。 また、メッセージング・エンジンを使用する場合には、メッセージング・エンジンごとにデー タストアとして、データベースを使用します。したがって、データベースの高可用性・拡張性も 検討する必要があります。 尚、WESBのCEIやアダプターを使用する場合には、関連するコンポーネントの高可用性、拡張 性については、別途検討が必要です。 12 06. WESBのシステム設計 WESBのシステム設計 WESBサーバー・クラスタリング WAS NDが提供するアプリケーション・サーバーのクラスタリング機能 WESBサーバー上で稼動するアプリケーション(メディエーション・モジュール)の高可用性・拡張性を 実現 Web WLM HTTPリクエストに対する負荷分散・障害検知を実施 負荷分散・障害検知は、Splayerが実施 トポロジー設計においては、Splayerの配置の検討が必要 EJB WLM EJBリクエストのIIOP通信の負荷分散・障害検知を実施 負荷分散・障害検知は、EJBクライアントが実施 クラスター1 クラスター2 Web WLM Container1 Plug-in EJB Container1 Application Server Splayer (Webサーバー, 負荷分散装置) Web WLM Application Server EJB WLM Web Container2 SOAP/HTTP EJB Container2 WLM Plug-in Application Server IIOP Application Server 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop まず、メディエーション・モジュールの実行環境の高可用性、拡張性を実現するWAS NDのクラ スタリング機能について説明します。 クラスタリングは、同一のアプリケーションを、複数のアプリケーション・サーバーの間で処 理を分散し、障害発生時には、正常なアプリケーション・サーバーにのみリクエストを割り振る 機能です。(WorkLoad Management = WLMと呼ばれることもあります。) これにより、リクエスト を送信するクライアントからは、1つのアプリケーションに対する、パフォーマンス、可用性が 向上します。 クラスタリング機能を使用することにより、メディエーション・モジュールの処理の分散と、 SOAP/HTTP通信などの同期通信の負荷分散、障害検知を行うことができます。 クラスタリングを実施すると、Webコンテナーに対するWLM機能とEJBコンテナーに対するWLM機 能が提供されます。 Web WLM機能はWebコンテナーに対する負荷分散・障害検知を実施します。これを使用して、 SOAP/HTTP通信におけるルーター・サーブレットへの負荷分散を実施します。尚、負荷分散・障 害検知は、Webサーバー・プラグインやEdgeなどのSplayerが実施しますので、トポロジー設計に おいては、Splayerの配置の検討が必要になります。 EJB WLM機能はリモートEJBクライアントからのEJBに対するアクセスの負荷分散・障害検知を 提供する機能です。SCA (同期) 通信のIIOP通信の負荷分散を実施します。 13 06. WESBのシステム設計 WESBのシステム設計 MEクラスタリング-フェイルオーバー WAS NDが提供するメッセージング・エンジンのフェイルオーバー機能 バス・メンバーとしてクラスターを追加することにより、メッセージング・エンジンの 高可用性を実現 クラスター内の1つのアプリケーション・サーバーでメッセージング・エンジンが稼 動 稼動系と待機系のMEは同じデータ クラスター1 ストアを使用 ME HAマネージャーの機能により、障害検知、 フェイルオーバー Application Server data store ME Application Server Bus 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 次に、メッセージング・エンジンの高可用性機能について説明します。 メッセージング・エンジンのフェイルオーバーは、WAS NDのHAマネージャー機能により提供さ れる、メッセージング・エンジンの高可用性機能です。 メッセージング・エンジンのフェイルオーバーを構成するためには、バス・メンバーとしてク ラスターを登録します。クラスター内の1つのアプリケーション・サーバーでメッセージング・ エンジンが起動し、他のアプリケーション・サーバー(クラスター・メンバー)ではメッセージン グ・エンジンが待機状態となります。 稼動中のメッセージング・エンジンに障害が発生すると、他の待機状態のメッセージング・エ ンジンが起動し、処理を引き継ぎます。 稼動系と待機系のメッセージング・エンジンは同じデータストアを利用し、障害発生時には構 成情報やパーシスタント・メッセージを引き継ぎます。 このメッセージング・エンジンのフェイルオーバー機能は、InfoCenterでは、「サービス統合 の高可用性」と表記されています。 14 06. WESBのシステム設計 WESBのシステム設計 MEクラスタリング-ワークロード共用 WAS NDが提供するメッセージング・エンジンの負荷分散機能 バス・メンバーのクラスターにメッセージング・エンジンを追加することにより、メッ セージング・エンジンの拡張性を実現 ひとつの宛先に対して複数のメッセージング・エンジンで処理を実施 クラスター1 ME1 JMS Client application ME3 ME2 data store1 Application Server 負荷 分散 ME1 ME2 data store2 Application Server Bus 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 次に、メッセージング・エンジンの負荷分散機能について説明します。 メッセージング・エンジンのワークロード共用も、WAS NDのHAマネージャー機能により提供さ れます。 メッセージング・エンジンのワークロード共用を構成するためには、バス・メンバーのクラス ターにメッセージング・エンジンを追加します。つまり、バス･メンバーとして、同一のクラス ターを2回追加します。 メッセージング・エンジンのワークロード共用機能を使用することで、1つの宛先に対して複 数のメッセージング・エンジンを紐付けて負荷分散させることが可能です。 「サービス統合のワークロード共用」は、InfoCenterでは「宛先の区画化」、「宛先のパー ティショニング」とも表記されています。 15 06. WESBのシステム設計 WESBのシステム設計 3.トポロジー設計 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 16 06. WESBのシステム設計 WESBのシステム設計 もっとも簡単な構成(単体構成) 一つのアプリケーション・サーバー上ですべての機能を稼動させるこ とも可能 高可用性・拡張性は実現されない WESBのプロファイル作成時に、スタンドアロンのアプリケーション・サーバーを選 択する WASサーバー1 SOAP/HTTP Client SOAP/JMS Client WESBサーバー Mediation Module Mediation Flow Component JMS Client SCA.SYSTEM Bus SCA.APPLICATION Bus Cloudscape WASサーバー2 SOAP/HTTP Web Service SOAP/JMS Web Service JMS Service ME1 ME2 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop ここからは、実際のWESBサーバーのトポロジー構成について検討します。 まず、もっとも簡単な構成として、単体構成でのWESBサーバーについて紹介します。 WESBのプロファイル作成時に、スタンドアロンのアプリケーション・サーバーを選択すること で、この構成を作成することができます。 この構成では、WASのクラスタリング機能を使用していませんので、高可用性や拡張性は実現 されません。 高可用性や拡張性が実現されませんので、実稼働環境としてはお勧めできませんが、スタンド アロンのアプリケーション・サーバーの構築時には、メッセージング・エンジンのデータストア などにデフォルトで組み込まれているcloudscapeのデータベースを使用して自動的にメッセージ ング・エンジンの設定が行われますので、アプリケーションの検証環境などにおいてはお手軽に 環境を構築することが可能です。また、WID上のWESBのテスト・サーバーもスタンドアロンの WESBサーバーが使用されています。したがって、バス環境の設定など、特別な設定を行わなくと も簡単に使用することが可能です。 17 06. WESBのシステム設計 WESBのシステム設計 メディエーションとサービスの分離は必須か サービスやクライアントはWESBサーバーに同居することも可能 WESBはWAS NDの機能をすべて持っているので、WAS ND上で稼動するア プリケーションは、すべてWESB上でも稼動可能 メディエーション処理を補完するロジックを、サービスとして切り出す場合などは、 同一サーバーで稼動させても良い WASサーバー SOAP/HTTP Client SOAP/JMS Client SCA Service WESBサーバー SOAP/HTTP Web Service Mediation Module Mediation Flow Component JMS Client SCA.SYSTEM Bus SCA.APPLICATION Bus SOAP/JMS Web Service Cloudscape JMS Service ME1 ME2 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 1ページ前の図では、サービス・リクエスター、WESBサーバー、サービス・プロバイダーをそ れぞれ異なるアプリケーション・サーバー上で稼動させる図を表示しましたが、WESBサーバー上 で、J2EEのサービス・リクエスターやサービス・プロバイダーを稼動させることもできます。 WESBはWAS NDの機能をすべて持っていますので、WAS上で稼動するJ2EEアプリケーションは、す べてWESB上でも稼動させることが可能です。 メディエーション処理を補完するロジックを、サービスとして切り出す場合などでは、同一 サーバー上で稼動させても問題ありません。これにより、不必要にサーバー台数が増加していく ことを防ぐことができます。 また、この後説明するWESBサーバーをクラスタリングした環境においても、メディエーション が稼動するクラスター上で、サービス・リクエスターやサービス・プロバイダーも同時に稼動さ せることができます。 18 06. WESBのシステム設計 WESBのシステム設計 高可用性・拡張性を意識した構成(複数構成) WESBサーバーの高可用性・拡張性構成は、WAS NDの機能により実現 メディエーション・モジュール WASクラスタリング機能 バス： メッセージング・エンジンのフェイルオーバー機能 メッセージング・エンジンのワークロード共用機能 クラスター1 Bus Web Service SOAP/JMS Web Service Mediation Module binding SOAP/HTTP Mediation binding Flow WESBサーバー1 WASサーバー1 WASサーバー2 ME1 SOAP/JMS Web Service Component SOAP/HTTP Client Splayer (Webサーバー, 負荷分散装置) ME2 WESBサーバー2 Mediation Module Mediation Flow Component ME1’ 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop これから、WESBサーバーの高可用性、拡張性を考慮した複数サーバー構成を説明します。 まず、WESBの複数サーバー構成を検討する場合には、WASのクラスター構成が基本になります。 WASクラスタリングを使用することで、クラスター上で稼動するメディエーション・モジュール の高可用性と拡張性が実現されます。 また、クラスターをバスメンバーとして登録することにより、メッセージング・エンジンの フェイルオーバー機能やワークロード共用機能を使用することができ、これにより、非同期通信 で使用するメッセージング・インフラストラクチャーであるバスの高可用性、拡張性を実現でき ます。 ただし、通信方式の違いにより、高可用性・拡張性を検討するコンポーネントが異なりますの で、以降のページで、通信方式別にトポロジーを検討します。また、同期と非同期の両方の通信 方式をサポートするWESBサーバーを構築する場合には、両方の検討項目を合わせ持つトポロジー を構築することが必要です。 19 06. WESBのシステム設計 WESBのシステム設計 SOAP/HTTP, SCA(同期)のトポロジー SOAP/HTTP WESBサーバーのクラスターは、アプリケーション・サーバーのクラスターにより実施 SOAP/HTTPのリクエスト分散のためにSplayer(Edge/IHS,BIGIP等)が必要 SCA(同期) SCAバインディングのメディエーション・モジュールの連結はEJB WLMにより高可用性・ 拡張性を実現 クラスター1 クラスター3 クラスター2 WESBサーバー1 クラスター4 WESBサーバー3 WASサーバー1 Mediation Module Mediation Module WASサーバー3 SOAP/HTTP WS Client Mediation Flow Component Mediation Flow Component SOAP/HTTP WS Client Splayer WASサーバー1 SOAP/HTTP WS Client Splayer WESBサーバー2 WASサーバー4 WESBサーバー4 Mediation Module Mediation Module Mediation Flow Component Mediation Flow Component SOAP/HTTP WS Client SOAP/HTTP SOAP/HTTP IIOP 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop SOAP/HTTP, SCA(同期)の同期通信のみを使用した場合の高可用性・拡張性トポロジーです。 クラスタリング機能を使用し、WESBサーバーのクラスタリングを行います。これにより、メ ディエーション・モジュールの複数稼動を実現します。 エクスポートにおいて、SOAP/HTTPバインディングを使用する場合、リクエストはルーター・ サーブレットがハンドリングします。クラスタリング機能により、ルーター・サーブレットが稼 動するWebコンテナーは複数稼動することになります。WESBクラスターの前段にSOAP/HTTPのリク エストの負荷分散を実行するSplayer(Edge/IHS/BIGIP等)を配置し、複数のWebコンテナーへリク エストを分散することで、Webサービス・クライアントからWESBクラスター・メンバーへのリク エストを負荷分散することが可能となります。 インポートでSOAP/HTTPバインディングを使用している場合も、考え方は同様です。この場合、 メディエーション・モジュール内のEJB (Stateless Session Bean) が、Webサービスに対するク ライアントとなるので、Webサービス側のSplayerに対してリクエストを送信することで負荷分散 が可能となります。 尚、この構成の場合、Splayer自身の高可用性も検討する必要があります。 SCAバインディングにより、2つのメディエーション・モジュールを連結する場合、メディエー ション・モジュール間の通信はEJBクライアントとEJBの通信になりますので、クラスタリング機 能によるEJB WLMによって負荷分散が実現されます。 同期通信の場合の高可用性・拡張性構成は、通常のJ2EEアプリケーション・サーバーの高可用 設計の考え方がそのまま使用できますので、下記の資料も参考にしてください。 DeveloperDomainワークショップ資料「WebSphere Application Server V6による基幹システム設 計ワークショップ資料」-「インフラ設計」 http://www-06.ibm.com/jp/software/websphere/developer/was/wv6/enterprise/ws/ 20 06. WESBのシステム設計 WESBのシステム設計 SOAP/JMS, JMS, SCA(非同期)のトポロジー 非同期通信の場合のトポロジーは複数考えられる メディエーションとMEを同一クラスターで稼動 vs 異なるクラスターで稼動 MEのワークロード共用を行う vs 行わない 注意：MEのクラスタリングを行う場合は、MEのデータストアとしてcloudscape は使用できない クラスター1 WESBサーバー1 SOAP/JMS WESBサーバー2 Mediation Module Mediation Module Mediation Flow Component Mediation Flow Component WASサーバー1 SOAP/JMS WS Client WASサーバー2 クラスター2 WESBサーバー3 ME ME DB2など WESBサーバー4 SOAP/JMS WS Client SOAP/JMS ME’ ME SCA.SYSTEM or APPLICATION Bus 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop SOAP/JMS, JMS, SCA(非同期)の非同期通信を使用した場合の高可用性・拡張性トポロジーを検 討します。 WESBサーバーのクラスタリングを行い、このクラスターに対してメディエーション・モジュー ルをデプロイすることにより、メディエーション・モジュールの複数稼動を実現します。 また、非同期通信の場合は、通信はバスを介して行われますので、メッセージング・エンジン の高可用性・拡張性を検討する必要があります。 メッセージング・エンジンの高可用性・拡張性を考慮したトポロジーを考える上では、以下の 点を決定する必要があります。 ・メディエーション・モジュールを稼動させるクラスターとメッセージング・エンジンを稼動さ せるクラスターを同一のクラスターとするのか。それとも異なるクラスターでそれぞれを稼動さ せるのか。 ・メッセージング・エンジンのワークロード共用を行うのか、行わないのか 一見、パフォーマンス向上の観点から、メッセージング・エンジンのワークロード共用は常に 行った方がよいと思うかもしれませんが、メッセージング・エンジンのワークロード共用を使用 するには注意点がありますので、次ページ以降で説明する注意点をご確認の上、ワークロード共 用の採用を決定してください。 また、メッセージング・エンジンのフェイルオーバー機能などのメッセージング・エンジンの クラスタリングを行う場合には、デフォルトで組み込まれているcloudscapeのデータベースを メッセージング・エンジンのデータストアとして使用することはできません。メッセージング・ エンジンのクラスタリング機能を使用する場合には、DB2やoracleなどのデータベースを使用す る必要があります。 21 06. WESBのシステム設計 WESBのシステム設計 MEのワークロード共用について MEワークロード共用の利点 拡張性、パフォーマンスが向上 MEワークロード共用の注意 メッセージの順序性が保証されない ワークロード共用されたMEではデータストアを共有しないため MEのフェイルオーバー時にメッセージが孤立してしまう場合がある メッセージの受信は、アプリケーションが最初に接続したMEからのみ行うため 非パーシスタントのメッセージしか使用しない場合は問題ない Request-Reply通信で、受信宛先が負荷分散されてしまう場合がある 必ずしも負荷分散が均等に行われるとは限らない 非同期SCA通信では、受信宛先(永続キュー)が負荷分散対象となる クライアントからのMEの検索順、また、MEから宛先の検索順によって送信先宛先が決定 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop メッセージング・エンジンのワークロード共用を使用する場合の注意点の概要を説明します。 まず、ワークロード共用を行う利点としては、一つの宛先に対するメッセージを複数のアプリ ケーション・サーバーで同時並行的に処理できるため、拡張性、パフォーマンスの向上が実現さ れます。逆に言うと、ワークロード共用を行わない場合には、単一のアプリケーション・サー バーでしかメッセージを処理できないため、メッセージング・エンジンの拡張性が単一のアプリ ケーション・サーバーの処理能力に制限されてしまいます。 次に、ワークロード共用を行う場合の注意点です。 まず、メッセージング・エンジンのワークロード共用を行った場合、メッセージの順序性は保 証されません。これは、ワークロード共用が行われたメッセージング・エンジンでは、それぞれ のメッセージング・エンジンが、それぞれ固有のデータストアを持ち、1つの宛先の一部分(区分 化された宛先)の処理を実行するためです。メッセージの順序が重要なアプリケーションにおい ては、メッセージング・エンジンのワークロード共用を行うことはできません。 次に、メッセージング・エンジンのワークロード共用を行っている場合、メッセージング・エ ンジンのフェイルオーバー時にメッセージが孤立(消費されないメッセージが発生)してしまう場 合があります。詳細は後述します。 また、非同期SCA通信を使用する場合には、受信宛先が永続キューとして作成されるため、受 信宛先も負荷分散の対象となってしまいます。リクエスト・メッセージが送信されるメッセー ジ・ポイントとリプライ・メッセージが送信されるメッセージ・ポイントが同一のメッセージン グ・エンジンになるように、構成に注意する必要があります。詳細は後述します。 また、メッセージング・エンジンのワークロード共用は、必ずしも負荷分散が均等に行われる とは限りません。詳細は後述します。 メッセージング・エンジンのワークロード共用の注意点については、下記のDeveloperWorksの 記事も参照ください。 DeveloperWorks記事「Basic steps for clustering WebSphere Process Server」 http://www128.ibm.com/developerworks/websphere/techjournal/0604_chilanti/0604_chilanti.html 22 06. WESBのシステム設計 WESBのシステム設計 MEワークロード共用の注意① MEのフェイルオーバー時にメッセージが孤立してしまう場合がある 1.メッセージがME1に送られたときにServer1がダウン 2.ME1はServer2にテイク・オーバー 3.Server2にME1,ME2が両方稼動する状態になる 4.MDBの場合、Server2で最初から稼動していたME2からのみメッセージを受け取る → 1 でME1に送られたメッセージは、Server1が復旧するまで消費されない クラスター1 クラスター1 Mediation Module ME1 ME2 data store1 WESBServer1 Mediation Module ME1 Mediation Module ME2 WESBServer2 data store2 ME1 ME2 data store1 WESBServer1 ME1 Mediation Module ME2 ？ data store2 WESBServer2 Bus Bus 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop ここでメッセージング・エンジンのワークロード共用構成をとったときの注意点の1つとして、 メッセージング・エンジンのフェイルオーバー時にメッセージが孤立してしまう場合について説 明します。 メッセージング・エンジンはパーシスタンス・ストアとしてデータストアと呼ばれるデータ ベースを使用し、システムダウンの後も継続して処理が行なえるような仕組みになっています。 このデータストアはワークロード共用構成の際はメッセージング・エンジンごとに別のデータス トアを持ちます。 このような構成で、メッセージがME1に送られたタイミングでサーバーがダウンしたとします。 そのとき、そのメッセージはME1のデータストアであるDataStore1内に留まります。(1) そのとき、ME1がダウンしたことをHAマネージャーが検知し、Server2にME1を立ち上げます。 (2) Server2にME1,ME2の二つのMEが稼動した状態になりますが、このとき、 MDBが接続しているME は、もとから動いているME2です。そのため、ME1のデータストアに残っているリプライ・メッ セージを消費できないことになります。 これは、メッセージの受信を行うMDBは最初に接続したMEからのみ行うためです。 ただし、メッセージが失われた場合も、そのリカバリーをアプリケーション側で考慮している ため、非パーシスタントのメッセージのみしか使用していない場合には、問題になりません。 ワークロード共用されたキュー宛先からの受信についての考慮点は下記のInfoCenterの記載も 参照ください WESB 6.0.1 InfoCenter「キュー宛先のあるワークロード共用」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.pmc.n d.doc/concepts/cjt0014_.html 23 06. WESBのシステム設計 WESBのシステム設計 MEパーティショニングの注意② Request-Reply通信で、受信宛先が負荷分散されてしまう場合がある 非同期SCA通信では、受信宛先(永続キュー)が負荷分散対象となるため 非同期SCA通信においては、受信宛先側のMEをワークロード共用してはいけない MediationモジュールとMEのクラスターを分離することでMediationモジュールの負荷分散は可 能 SOAP/JMS通信では、受信宛先は(一時キュー)のため負荷分散可能 クラスター1 Server1 Mediation Module ME1 Bus クラスター2 Server3 Mediation Module 送信宛先 受信宛先 ME2 受信宛先 ME3 送信宛先 ME1’ Mediation Module Server2 Mediation Module Server4 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop ここでは、SCA非同期通信を行う場合のメッセージング・エンジンのワークロード共用の注意 点を説明します。 SCA非同期通信では、レスポンスを受信する受信宛先が永続キューとして作成されますので、 クラスター1側のメッセージング・エンジンのワークロード共用を行っている場合、受信宛先が 負荷分散の対象となってしまい、必ずしも、メッセージをPUTしたメディエーションにレスポン スが戻らなくなってしまいます。 基本的には、非同期SCA通信を使用する場合には、受信宛先側のメッセージング・エンジンの ワークロード共用を行うことはできません。ただし、上図でServer1とServer3を同一ノードで稼 動し、Server2とServer4を同一ノードで稼動するようにした場合には、メッセージのフローは、 Server1→Server3→Server1とServer2→Server4→Server2となりますので、クラスター1側の メッセージング・エンジンをワークロード共用行うことも可能です。 また、上図では、Server2側では、メディエーション・モジュールもスタンバイ状態となって しまいますが、メディエーション・モジュールとメッセージング・エンジンを稼動するクラス ターを分離することで、メディエーション・モジュールのアプリケーションを並列稼動させるこ とができます。(後述) 尚、SOAP/JMS通信の受信宛先は一時キューとして、メッセージ送信時に作成されますので、 ワークロード共用を行っても、正しくメッセージを受信することが可能です。 24 06. WESBのシステム設計 WESBのシステム設計 MEパーティショニングの注意③ 必ずしも負荷分散が均等に行われるとは限らない JMSクライアントのメッセージング・エンジンの検索順はより近いメッセージング・エンジンが優先 メッセージ・エンジンのローカルに宛先が存在する場合、その宛先に常に送信 メッセージング・エンジンの検索順とメッセージング・エンジンから宛先の検索順に注意する必要が ある JMSクライアントもBusにメンバーとして参加し、宛先までの距離が均等であれば、負荷分散が 行われる 同一アプリケーション・サーバー上やノード上に該当の宛先が存在する場合にはすべてその宛先に送信される クラスター1 ME1 ME2 Mediation Module WESBServer1 WASサーバー1 JMS Client ME1 Bus ME2 Mediation Module WESBServer2 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop メッセージング・エンジンの負荷分散においては、構成や設定によって必ずしも均等に負荷分 散が行われない場合があります。 メッセージの送信を行うJMSクライアントは、まず、メッセージング・エンジンを検索し、接 続したメッセージング・エンジンのローカルに宛先が存在する場合には、常にその宛先にメッ セージを送信します。そのため、特定のクライアントからのメッセージが特定のメッセージン グ・エンジンの宛先に常に送信されてしまう場合があります。これを避けるためには、割り振り 専用のメッセージング・エンジンを作成するなどの考慮が必要です。 メッセージを送信するクライアントからの、メッセージング・エンジンの検索順と検索された メッセージング・エンジンから宛先の検索順に注意する必要があります。 上図の場合で、JMSクライアントもBusにメンバーとして参加し、宛先までの距離が均等であれ ば、負荷分散が行われます。ただし、上図で、JMSクライアントがBusにメンバーとして参加した 場合も同一アプリケーション・サーバー上やノード上に該当の宛先が存在する場合にはすべてそ の宛先にメッセージは送信されます。 メッセージング・エンジンの選択プロセスの詳細は下記のInfoCenterの記載を参照してくださ い。 WESB 6.0.1 InfoCenter「アプリケーションのメッセージング・エンジン選択プロセスの構成」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.pmc.n d.doc/tasks/tjn0034_.html 25 06. WESBのシステム設計 WESBのシステム設計 MediationサーバーとMEサーバーの分離 ME用サーバー(クラスター)を分離する場合(リモート構成)の考慮点 リソースを多く使用する MEのワークロード共用も行った場合、すべてのMEのメッセージを受信できるようにメディエーション 用クラスターを構成する必要があり構成が複雑になる ME用サーバー(クラスター)をメディエーションと同一にする場合(ローカル構成)の考慮点 Mediation用とME用を別々に拡張、チューニングすることができない MEをワークロード共用しない場合、非同期通信を受信するメディエーションは、MEが稼動してい るサーバーでのみ稼動。MEのStandby機は、メディエーションもStandby状態となる WESBサーバー1 WASサーバー1 SOAP/JMS Client Mediation Module Mediation Flow Component WASサーバー2 SOAP/JMS Web Service JMS Service JMS Client WESB(WAS)サーバー2 ME SCA.APPLICATION or SCA.SYSTEM Bus 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop メディエーション用のクラスターとメッセージング・エンジン用のクラスターの分離構成につ いて検討します。 まず、メッセージング・エンジン用のクラスターを分離した場合(MEのリモート構成)の考慮点 です。 リモート構成の場合、アプリケーション・サーバーの数が増加し、その分、サーバー台数やメ モリーリソースなどのリソースを多く使用することになります。また、メッセージング・エンジ ンのワークロード共用を行った場合には、すべてのメッセージング・エンジンのメッセージを受 信できるように、メディエーション用のクラスター(クラスター・メンバー)を構成する必要があ り、構成が複雑になります。 次に、メッセージング・エンジン用のクラスターとメディエーション用のクラスターを同一に する場合(ローカル構成)の考慮点です。 ローカル構成の場合、メディエーション用とメッセージング・エンジン用のクラスターをそれ ぞれ別々に拡張、チューニングを行うことができません。また、メッセージング・エンジンの ワークロード共用を行わない場合に、メッセージの受信はローカルで稼動するMDBによる処理が 優先されますので、結果として、メッセージング・エンジンが稼動しているクラスター・メン バー上のメディエーション・アプリケーションしかメッセージの処理を行いません。メッセージ ング・エンジンがスタンバイ状態のクラスター・メンバー上のメディエーション・アプリケー ションもスタンバイ状態となってしまいます。したがって、メッセージング・エンジンのワーク ロード共用を行わない場合に、メディエーション・アプリケーションの拡張性・パフォーマンス 向上を実現するには、メッセージング・エンジン用のクラスターとメディエーション稼動用クラ スターを分離する構成が推奨されます。 26 06. WESBのシステム設計 WESBのシステム設計 ME使用における一般的な注意点 メッセージの信頼性 MEでは5種類の信頼性レベルが利用可能 信頼性レベル 説明 パーシスタント データ・ストアにメッセージを書き込むことで、メッセージング・エンジン再起動後もメッセージを維 持できます。ただし、データストアに書き込む分、低速で、I/Oがボトルネックになりやすいのが特 徴です。 保証パーシスタント メッセージを受け取ると同時に、データストアに書き込みます。 高信頼性パーシスタント メッセージを受け取ると、一旦バッファに保持して応答を返します。その後非同期でデータストア に書き込みます。 非パーシスタント メッセージをバッファのみに保持することで、メッセージングのパフォーマンスが向上できます。ただし、 メッセージング・エンジン再起動後はメッセージは破棄されます。I/Oがボトルネックになりにくいた め、CPUネックになるまでパフォーマンスが向上します。 高信頼性非パーシスタント メッセージング･エンジン間でメッセージをやり取りするとき、送信先にメッセージが届いたことを確 認後に、メッセージを破棄します。 高速非パーシスタント メッセージング・エンジン間でメッセージをやり取りするとき、送信先にメッセージが届いたことを確 認前に、メッセージを破棄します。 バッファを溢れたメッセージは、一時的にデータ・ストアに退避します。 ベストエフォート非パーシスタント 消去可能バッファをあふれたメッセージは全て破棄します。 メッセージング・エンジン間でメッセージをやり取りするとき、送信先にメッセージが届いたことを確 認前に、メッセージを破棄します。 非パーシスタントのメッセージを使用する場合も、例外宛先のデフォルトの信頼性が「保証パーシスタント」なので注意 （例外宛先にメッセージが溜まってしまわないように） 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop メッセージング・エンジンでは5段階の信頼性レベルを利用できます。信頼性レベルは大きく パーシスタントと非パーシスタントに分かれます。パーシスタントの場合はディスクに書き込み、 非パーシスタントの場合は基本的にディスクに書き込まないので、パフォーマンスだけを考える と、非パーシスタントの方が優れています。 パーシスタントの信頼性レベルは「保証パーシスタント」と「高信頼性パーシスタント」の2 種類です。信頼性レベルごとに、データ・ストアに書き込むタイミングが異なります。一般的に、 パーシスタントを利用すると、多くの場合DISK I/Oがボトルネックになります。 非パーシスタントの信頼性レベルは「高信頼性非パーシスタント」と「高速非パーシスタン ト」と「ベストエフォート非パーシスタント」の3種類です。信頼性レベルごとに、アプリケー ションがメッセージをメッセージング・エンジンに渡すタイミングが異なります。一般的に、非 パーシスタントを利用すると、多くの場合CPUがボトルネックになります。 信頼性レベルは、可能な限り非パーシスタントのいずれかを利用してください。パーシスタン ト・メッセージを利用すると、データストアのバックアップが必要になるので、運用の難易度が 上がります。 メッセージの信頼性の詳細は、下記のInfoCenterの記載を参照ください。 WESB 6.0.1 InfoCenter「メッセージ信頼性レベル」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.pmc.n d.doc/concepts/cjj9000_.html 27 06. WESBのシステム設計 WESBのシステム設計 MEワークロード共用設定の注意点 MEは、HA Managerによって、監視・制御 HAポリシーとして、メッセージング・エンジンの振る 舞いを指定 ポリシー・タイプ 説明 静的ポリシー MEを特定のサーバーでのみ稼動 Nポリシー中の1つ クラスター・メンバーのうち1つがMEを稼動。他のクラス ター・メンバーは待機。 オペレーション・ポリシーなし 障害が発生しても、何もしない設定 HAポリシーの適用範囲は、一致基準（Match criteria）で指定 偏ったアプリケーション・サーバーで MEが起動してしまわないように、HA ポリシーの設定が必須 デフォルト設定では、最初に起動した クラスター・メンバー上ですべての MEが起動してしまう ポリシーに該当するコンポーネントを、HAグループと呼びます。 優先サーバーを設定することで、ME障害時のフェ イルオーバーの優先順位を指定 フェイルバックを有効にすることで、優先度の高い サーバーが復旧した際に、MEを引き継ぐことが可 能 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop メッセージング・エンジンのワークロード共用設定の注意点です。 バス・メンバーとしてクラスターを追加し、複数のメッセージング・エンジンを起動した場合、 デフォルトの設定では、すべてのメッセージング・エンジンが最初に起動したクラスター・メン バー上で稼動してしまいます。複数のクラスター・メンバー上に分散してメッセージング・エン ジンを稼動させるには、HAポリシーの設定が必須です。 このHAポリシーは、メッセージング・エンジンを監視・制御しているHAマネージャーが、どの ようにメッセージング・エンジンを制御するかを指定します。 このHAポリシーには、ポリシー・タイプとしてメッセージング・エンジンの振る舞いを指定す る他、HAポリシーをどのコンポーネントに適用するかを指定する一致基準、そのコンポーネント を稼動させるサーバーの優先順位を指定する優先サーバー、フェイル・バックの有効/無効など を設定します。 HAポリシーの設定方法の詳細は下記のInfoCenterの記載を参照してください。 WESB 6.0.1 InfoCenter「メッセージング・エンジン用のポリシーの構成」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.pmc.n d.doc/tasks/tjt0028_.html 28 06. WESBのシステム設計 WESBのシステム設計 WESB基本コンポーネントの高可用性・拡張性構成のまとめ メディエーション・アプリケーション、バスの高可用性、拡張性はWASのクラスタリング機能 で実現 MEのワークロード共用構成は、使用するバインディング、アプリケーション特性を考慮し、 パーティショニングを行っても問題ない場合に実施 MEのワークロード共用を行わない場合は、メディエーション稼動用のクラスターとME稼動 用クラスターは分離することを推奨 MEのワークロード共用を行う場合は、メディエーション稼動用のクラスターとME稼動用クラ スターは同一クラスターとすることを推奨 クラスター1 WESBサーバー1 同期 SOAP/HTTP 非同期 WESBサーバー2 Mediation Module Mediation Module Mediation Flow Component Mediation Flow Component クラスター2 WESBサーバー3 ME DB2など WESBサーバー4 ME’ SCA.SYSTEM or APPLICATION Bus 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop ここまでに説明した、WESBの基本コンポーネントの高可用性・拡張性構成のまとめです。 メディエーション・アプリケーション、バス(メッセージング・エンジン)の高可用性、拡張性 はWASまたはWAS SIBusのクラスタリング機能により実現されます。 同期通信の高可用性、拡張性構成は通常のJ2EEアプリケーションの場合と同様に考えていただ いて構いません。バスの高可用性、拡張性は、その通信形態、アプリケーション特性に応じて十 分検討する必要があります。メッセージング・エンジンの高可用性、拡張性を考える場合には、 ワークロード共用を行うか否かを検討することがキーになります。 メッセージング・エンジンのワークロード共用を行っても問題ない場合は、パフォーマンスの 観点から、ワークロード共用を実施することをお勧めします。 メッセージング・エンジンのワークロード共用を行わない場合は、メディエーション稼動用の クラスターとメッセージング・エンジン稼動用のクラスターを分離するリモート構成が推奨され ます。メッセージング・エンジンのワークロード共用を行う場合は、メディエーション稼動用の クラスターとメッセージング・エンジン稼動用のクラスターは同一のクラスターとするローカル 構成が推奨されます。 29 06. WESBのシステム設計 WESBのシステム設計 (参考)WMQ接続の高可用性 WESB 6.0.1の場合 (6.0.2 では異なる) JMSバインディングによるWMQ接続の高可用性構成 MQLink機能を使用 WMQサーバー’ クラスター1 Service WESBサーバー1 WESBサーバー2 Mediation Module Mediation Module Mediation Flow Component Mediation Flow Component DB2など QMgr’ WMQサーバー クラスター2 Service HACMP WESB(WAS)サーバー3 ME HACMP IPアドレスのフェイルオー バーが必要。また、メッセージ ング・エンジンのポート番号が フェイルオーバー先でも同一 である必要がある MQ Link WMQ QMgr Channel Bus ME’ WESB(WAS)サーバー4 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop WESB 6.0.1において、WMQと接続する場合には、JMSバインディングを使用し、作成した宛先を MQリンク機能によりWMQのキューと接続する必要があります。メッセージング・エンジンの障害 時の高可用性を実現するには、メッセージング・エンジンのクラスタリング機能によるフェイル オーバーだけでは不十分です。メッセージング・エンジンのフェイルオーバー時にWMQの キュー・マネージャーから新しく稼動したメッセージング・エンジンに正常に接続するためには、 メッセージング・エンジンが稼動するサーバーのIPアドレスをフェイルオーバーする必要があり ます。また、メッセージング・エンジンのポート番号もフェイルオーバーした先で同一である必 要があります。 30 06. WESBのシステム設計 WESBのシステム設計 CEIの高可用性① CEIのコンポーネント イベントの流れ イベント検索・取得の流れ Deployment Manager WESBサーバー1 管理コンソール Eventサーバー WASサーバー3 J2EEアプリケーション (イベント・コンシューマー) CBE Browser EVENTDB ME ME用DB CommonEventInfrastraucture_ Bus WESBサーバー3 エミッター Web Service Client WASサーバー1 エミッター Mediation Flow Component Mediation Module エミッター Web Service WASサーバー2 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 上図は、CEIの概要を示しています。 イベント・ソースは、イベントを生成し、エミッターを経由してイベント・サーバーへイベン トを送信します。イベントの送信方法には、直接的にEJBコールして送信する方法（同期）と、 間接的にJMSを通して送信する方法（非同期）を選択できます。 イベント・サーバーは、イベント・ソースから送信されるイベントを収集して一元管理します。 イベント・サーバーは、イベントをデータベースに保管したり、イベントをモニタリングしてい るアプリケーション（イベント・コンシューマー）へ、イベントを配布します。データベースへ の保管や、イベント・コンシューマーへのイベント配布は、設定で容易に選択できます。 また、送信されたイベントをフィルタリングすることで、イベントのトラフィックを軽減させ ることもできます。 イベント・コンシューマーは、イベント・サーバーやイベント・データベースで管理されている イベントを取得し利用するコンポーネントであり、問題判別やパフォーマンス情報の把握などに 役立てることができます。 イベント・データベースは、イベントを保管するデータベースです。 31 06. WESBのシステム設計 WESBのシステム設計 CEIの高可用性② イベントサーバーとイベント・バスの高可用性 イベントサーバー用アプリケーションをクラスターに導入 イベントバスのバスメンバーをクラスターとする EventサーバーとME の稼動するクラスター を同一にすることも可 高可用性設計方針はメディエーション稼働環境の高可用性と同様 Deployment Manager 通常のメディエーショ ン・アプリケーションが 稼動するクラスター上 でEventサーバーを稼 動させることも可 クラスター1 WESBサーバー1 WESBサーバー2 管理コンソール CBE Browser Eventサーバー Eventサーバー EVENTDB WESBのスタンドアロンプ ロファイルでは、1つのアプ リケーション・サーバー上で すべてが稼動 クラスター2 WESBサーバー3 WESBサーバー4 ME ME用DB ME’ CommonEventInfrastraucture_ Bus 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop CEI環境の高可用性について説明します。 CEI環境において、高可用性を検討するコンポーネントはイベント・サーバーとイベント・バ スです。アプリケーションの高可用性とメッセージング・エンジンの高可用性の検討という意味 で、CEIの高可用性設計も設計方針は、メディエーション稼働環境の高可用性設計と同様です。 イベントサーバーの高可用性を実現するためには、イベントサーバー用のアプリケーションを クラスターに導入します。また、イベントバスの高可用性を実現するには、イベントバスのバス メンバーにクラスターを登録することにより、メッセージング・エンジンのフェイルオーバーを 実現します。 尚、WESBのスタンドアロンサーバーのプロファイルを使用した場合には、単一のアプリケー ション・サーバー上でCEI環境を含むすべてのコンポーネントが稼動します。このことからも分 かるように、イベントサーバーとイベント用のメッセージング・エンジンを稼動するクラスター を同一のクラスターとしたり、通常のメディエーションが稼動するクラスター上でイベントサー バーを稼動させることも可能です。 CEI構築手順の詳細は下記のInfoCenterの記載を参照ください。 WESB6.0.1 InfoCenter「インストール後の構成」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.wesb. doc/doc/ccei_install_postInstallConfig.html 32 06. WESBのシステム設計 WESBのシステム設計 4.導入・構成のHints&Tips 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 33 06. WESBのシステム設計 WESBのシステム設計 WESBで使用するバスの用途 WESBのSCAの非同期呼び出しで使用されるバス SCA.SYSTEM.cell_name.Bus SCA.APPLICATION.cell_name.Bus SOAP/JMSバインディング、SCAバインディングを使用する際に、必要に応じて宛先が作成される JMSバインディングを使用する際に、必要に応じて宛先を作成する CEIを使用する場合に使用するバス CommonEventInfrastructure_Bus イベントの送受信に使用 WASサーバー1 SOAP/JMS Client JMS Client WASサーバー2 WESBサーバー Mediation Module Mediation Flow Component DB1 DB2 SOAP/JMS Web Service JMS Service ME1 SCA.SYSTEM Bus ME2 SCA.APPLICATION Bus 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop SCA.SYSTEM.cell_name.BusとSCA.APPLICATION.cell_name.BusはWESBのセルが作成された時点 で定義されています。それぞれのバス内には少なくとも一つのメッセージング・エンジンが稼動 している必要があります。メッセージング・サービスの使用に必要なバス宛先は、メディエー ション・モジュールをサーバー上にデプロイした際に、必要な宛先がバス上に自動的に作成され ます。 SCA.SYSTEMバスは、管理者が意識することなく、自動的に宛先が作成されるバスとして使用さ れます。SOAP/JMSバインディング等を使用する場合は、このバスが使用されます。 SCA.APPLICATIONバスは、JMSバインディングの際に、管理者が意識してメディエーション処理 用宛先を作成したい場合に使用されるバスです。 メッセージング・エンジンを稼動させるサーバー(またはクラスター)は、「バス・メンバー」 としてバスに登録する必要があります。バス・メンバーには、WESBのサーバーだけでなく、同一 セル内のWAS V6.0のサーバーも選択することができます。 また、CEIを使用する場合には、イベントの送受信用にCommonEventInfarastracture_Busが使 用されます。 34 06. WESBのシステム設計 WESBのシステム設計 MEのデータストアの準備における注意 MEクラスタリングのデータストアに、デフォルトで設定されるcloudscapeは使用で きない MEごとに1つのユーザーおよびスキーマを事前に準備 DB2、oracle、MS SQL Serverなどを使用する必要がある DB2では、ユーザーとスキーマが分離しているので、MEの数分のスキーマを準備 DB2以外では、ユーザーとスキーマが1対1対応しているので、MEの数分のユーザーと スキーマを作成 ユーザーに必要な特権 テーブルを使用するためとテーブルを作成するための特権が必要 DB2の場合の例 DBMS データ・ストア・テーブルを使用するために、メッセージ ング・エンジンに必要な最小の特権。 データ・ストア・テーブルを作成するために、メッセージ ング・エンジンに必要な追加の特権。 DB2 テーブルに対する SELECT、INSERT、UPDATE、 および DELETE 特権が必要 データベースに対する CREATETAB 権限およびテー ブル・スペースの USE 特権に加えて、スキーマに対す る CREATEIN 特権が必要 パーシスタント・メッセージを使用した場合には、テーブルへデータの挿入、削除が頻繁に発生し、 参照系のDBよりも負荷がかかる 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop メッセージング・エンジンのクラスタリング機能は、データストアを引き継ぐことで、業務の 継続性を高めます。データストアが複数ノードにまたがって引き継ぎ可能である必要があるため、 デフォルトのデータストアであり、同一サーバーからしかアクセスできないcloudscapeは利用で きません。 サポートされるデータベースの詳細は下記のサポートリストページを参照ください。 WESBサポートページ「Detailed System Requirements for WebSphere Enterprise Service Bus V6.0.1 and V6.0.2.」 http://www-1.ibm.com/support/docview.wss?rs=2346&uid=swg27006912 また、メッセージング・エンジンを設定するには、メッセージング・エンジンごとにデータ ベースのユーザーおよびスキーマが必要になります。DB2では、ユーザーとスキーマが分離して いますので、少なくとも1つのデータベース・アクセス・ユーザーとメッセージング・エンジン 分のスキーマが必要です。DB2以外では、ユーザーとスキーマが1対1で対応していますので、 メッセージング・エンジン分のユーザーとスキーマが必要になります。 また、上記で指定したデータベース・アクセス・ユーザーには、テーブルを使用するためと、 バス・メンバー登録時に自動的にテーブルを作成する場合にはテーブルを作成するための特権が 必要になります。各DB製品ごとに必要な特権の詳細は下記のInfoCenterの記載を参照ください。 WESB 6.0.1 InfoCenter「データベース特権」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.pmc.n d.doc/ref/rjm0650_.html 尚、パーシスタント・メッセージを使用した場合には、テーブルへのデータの挿入、削除が頻 繁に発生しますので、参照系のデータベースよりも負荷がかかりますのでご注意ください。 35 06. WESBのシステム設計 WESBのシステム設計 MEのデータストアに保管される情報 MEのデータストアには下記のテーブルが作成 テーブル名 目的 SIBOWNER アクティブなメッセージング・エンジンの、データ・ストアへの排他アクセスのために使用 SIBCLASSMAP データ・ストア中のオブジェクト・タイプのカタログ SIBLISTING SIBnnnテーブルのカタログ SIBXACTS 2PCトランザクションのステータスを維持 SIBKEYS メッセージング・エンジン内にあるオブジェクトに固有IDを割当 SIBnnn パーシスタントと非パーシスタントのオブジェクトを保持 SIB000 SIB001とSIB002のテーブルにあるデータ構造についての情報を格納 SIB001 パーシスタント・オブジェクトを格納 SIB002 メッセージング・エンジンのメモリー要件を節減するために、データ･ストアに保管された非パーシ スタント・オブジェクトを格納 ME用のデータストア用のテーブルは、Busにクラスター(アプリケーション・サーバー)をメンバーとして登録時に 自動的に作成することも、DB管理者が事前に作成することも可能 •sibDDLGeneratorコマンドを使用して、DDLを作成可能 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop メッセージング・エンジンのデータストアには、パーシスタント・メッセージの内容だけでな く、メッセージング・エンジン稼動のための定義情報が保管されます。 メッセージング・エンジンのデータストアのテーブル情報の詳細は、下記のInfoCenterの記載 を参照ください。 WESB 6.0.1 InfoCenter「データ・ストアテーブル」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.pmc.n d.doc/ref/rjm0640_.html また、メッセージング・エンジンのデータストア用のテーブルは、バス・メンバー登録時に自 動的に作成することも、DB管理者が事前に作成することもできます。事前にテーブルを作成する 場合には、各DB製品ごとのDDLをsibDDLGeneratorコマンドを使用して生成・確認することができ ます。 WESB 6.0.1 InfoCenter「データベース管理者によるデータ・ストア・テーブルの作成を可能に する」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.pmc.n d.doc/tasks/tjm0100_.html WESB 6.0.1 InfoCenter「sibDDLGenerator コマンド」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.pmc.n d.doc/ref/rjm0630_.html 36 06. WESBのシステム設計 WESBのシステム設計 導入・構成時の注意① プロファイルの選択 インストール時 WESBはWASを拡張した製品ですが、事前にWASを導入する必要はない WESB導入時に、自動的にWASも導入 IHS、Pluginは、WASと同様に別途インストールする必要あり プロファイル作成時 WESB製品から、WESBプロファイル(ノード)だけでなく、WASプロファイル(ノー ド)も作成可能 誤ったプロファイルを作成しないよう注意 起動するプロファイル作成ウィザードが異なる <WESB_install_root>/bin L ProfileCreator L pct<OS_name>.bin L ProfileCreator_wbi L pcat<OS_name>.bin WASプロファイル 作成用 起動されるウィザード の内容もほとんど同じ WESBプロファイル 作成用 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 最後に、WESBサーバーの導入・構築時に注意すべき項目を説明します。 インストール時の注意点としては、WESBはWASを拡張した製品ですが、事前にWASを導入する必 要はありません。WESBを導入することにより、そのベースとなるWASも自動的にインストールさ れます。ただし、IHSやWebサーバーPluginは、WASの導入時と同様に別途インストールする必要 があります。 プロファイル作成時の注意点です。 WESB製品からは、WESBプロファイルだけでなく、WASプロファイルも作成可能になっています。 WESBのプロファイルとWASのプロファイルは、起動するプロファイル作成ウィザードが異なりま す。実行するプロファイル作成ウィザード起動コマンドのパスや起動コマンド名が非常に似てい ますし、起動後のウィザードの内容も似ていますので、注意してください。 37 06. WESBのシステム設計 WESBのシステム設計 導入・構成時の注意② テンプレートの選択 アプリケーション・サーバー、クラスター作成時 WASアプリケーション・サーバー用テンプレートとWESBアプリケーション・サー バー用の2種類のテンプレートが準備 テンプレートの選択時に「default」ではなく、「defaultESBServer」を選択 初期値が「default」になっているので注意 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop また、アプリケーション・サーバーやクラスターを作成するときも、WASのアプリケーショ ン・サーバー用のテンプレートとWESBのアプリケーション・サーバー用の2種類のテンプレート が用意されています。アプリケーション・サーバーやクラスター作成時のデフォルトのテンプ レートの選択がWAS用の「default」になっていますので、WESBのアプリケーション・サーバーや クラスターを作成する場合には、必ずテンプレートの選択を「defaultESBServer」に変更する必 要があります。 38 06. WESBのシステム設計 WESBのシステム設計 導入・構成時の注意③ SCAサポートの構成ウィザード クラスター(AS)がSCAをサポートす るための構成 SCA.SYSTEMバス、 SCA.APPLICATIONバスのMEにアクセ ス、または自身がMEを保持するための 構成ウィザード 管理コンソールで、[サーバー]-[クラスター(アプ リケーション・サーバー)][Cluster_name(AS_name)]-[追加プロパ ティー：拡張構成]を選択 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop また、アプリケーション・サーバーまたはクラスターを作成後、SCAランタイムをサポートす る追加の設定が必要になります。追加設定は、ウィザードが管理コンソール上に準備されていま す。メディエーションを稼動させるアプリケーション・サーバーまたはクラスター上でメッセー ジング・エンジンも一緒に稼動させる場合には、このウィザードを使用して、メッセージング・ エンジンの設定も同時に行われます。リモートのメッセージング・エンジンを使用する場合も、 この構成ウィザードを使用してください。 構成ウィザードの詳細は下記のInfoCenterの記載を参照してください。 WESB 6.0.1 InfoCenter「メディエーション・モジュールのキュー宛先をホストするサーバーま たはクラスターの構成」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.wesb. doc/tasks/twesb_scalocal.html WESB 6.0.1 InfoCenter「メディエーション・モジュールのリモート宛先を使用するサーバーま たはクラスターの構成」 http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websphere.wesb. doc/tasks/twesb_scaremote.html 39 06. WESBのシステム設計 WESBのシステム設計 導入・構成時の注意④ Fix適用 WESBはWASをベース WESB 6.0.1.3 (現在の最新) は、WAS 6.0.2.13 上で稼動 WESBのFix Packを適用することで、内部のWAS の修正レベルもアップ IHS、Pluginについては、ベースとなるWASのバー ジョンと合わせて、WASのFix Packを要適用 WESBのFix # ./versionInfo.sh ///途中略/// インストール済み製品 -------------------------------------------------------------------------------名前 IBM WebSphere Application Server - ND バージョン 6.0.2.13 ID ND ビルド・レベル cf130631.22 ビルド日 8/4/06 インストール済み製品 -------------------------------------------------------------------------------名前 IBM WebSphere Enterprise Service Bus バージョン 6.0.1.3 ID ESB ビルド・レベル o0637.07 ビルド日 9/16/06 Packは、複数の.pakファ イルを含む versionInfoコマンドの 出力結果 WESBの累積Fix、WASの累積Fix、関連 するWASの個別Fixなどが含まれる updateinstallerを複数回起動して、適用 順序に注意してFixを適用 updateinstaller/maintenace ディレクトリー内のファイル # pwd /opt/ibm/WebSphere/ESB/updateinstaller/maintenance # ls -s --block-size=K 合計 482628 130100 6.0.1-WS-WPS-ESB-LinuxX32-FP0000003.pak 243944 6.0.2-WS-WAS-LinuxX32-FP00000013.pak 108460 6.0.2-WS-WASJavaSDK-LinuxX32-FP00000011.pak 76 6.0.2.12-WS-WAS-IFPK29634.pak 48 WS-WAS-IF353793.pak 5つのpakファイル 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop Fix適用時の注意です。 WESBはWASをベースとしていますので、WESBを管理する場合には、WESBのバージョンとその ベースとなっているWASのバージョンを意識する必要があります。WESBの現在の最新バージョン であるWESB 6.0.1.3は、WAS 6.0.2.13をベースとしています。WESBのFixPackを適用することで、 ベースとなるWASの修正レベルもアップします。また、IHS、プラグインについては、WESBの FixPack適用時に、アップグレードされたベースとなるWASのバージョンと合わせてWAS(IHS, Plugin)のFixPackを適用してください。 また、WESBのFixPackの適用方法は、WASと比較して、やや複雑です。WESBのFixPackには、 WESBの累積Fix、WASの累積Fix、関連するWASの個別Fixなどが含まれていますので、 updateinstallerを複数回起動して、適用順序に注意してFixを適用する必要があります。適用順 序の詳細は、FixPackのReadmeを必ずご確認ください。 尚、WESBの最新修正プログラムは、下記のサイトより、ダウンロードしてください。 WESB Supportページ http://www-306.ibm.com/software/integration/wsesb/support/ 40 06. WESBのシステム設計 WESBのシステム設計 まとめ WESBシステム・トポロジー設計においては、メディエーション・モ ジュールとメッセージング・エンジンの高可用性・拡張性を検討する ことが必要 メディエーション・モジュールの高可用性・拡張性はWASのクラスタリ ング機能により実現 メッセージング・エンジンの高可用性・拡張性はWASのクラスタリン グ機能をベースとした、メッセージング・エンジンのフェイルオーバー機 能、ワークロード共用機能により実現 ただし、メッセージング・エンジンのワークロード共用機能には注意 点があるので事前に使用する通信方式やアプリケーションの特性 から行うか行わないかを検討する必要がある 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 41 06. WESBのシステム設計 WESBのシステム設計 参考資料 WESB 6.0.1 InfoCenter http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp DeveloperDomain ワークショップ資料「WebSphere Enterprise Service Bus V6アナウンスメン ト・ワークショップ資料」-「WebSphere ESBシステム構成」,「CEIの使用」 http://www-06.ibm.com/jp/software/websphere/developer/bi/wesb/v6/workshop/ DeveloperDomain 導入構成ガイド「WebSphere Process Server V6 クラスター構成ガイド」 http://www-06.ibm.com/jp/software/websphere/developer/wps/clusterguide/ Redbook「Patterns: SOA Foundation Service Connectivity Scenario」 http://www.redbooks.ibm.com/abstracts/sg247228.html?Open DeveloperWorks記事「Deployment patterns for WebSphere Process Server and Enterprise Service Bus」 http://download.boulder.ibm.com/ibmdl/pub/software/dw/wes/pdf/0611_redlindeploypatterns.pdf DeveloperWorks記事「IBM WebSphere Developer Technical Journal: Basic steps for clustering WebSphere Process Server」 http://www128.ibm.com/developerworks/websphere/techjournal/0604_chilanti/0604_chilanti.html 2006/11 SOA “Webサービス及び ESB””基盤構築Workshop Webサービス及びESB 基盤構築Workshop 42