Comments
Description
Transcript
システム設計の考慮点 トピック 2004/06/14 製品の選択
＜MQ-WAS連携-第３章＞ システム設計の考慮点 2004/06/14 ＜MQ-WAS連携-第３章＞ トピック 製品の選択 WebSphere MQと組み込みMQの選択 トポロジー設計 MQ-WAS連携で、パフォーマンスと可用性を確保するには まとめ 要件別 MQ-WAS連携トポロジー例 2 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ ＜製品の選択＞ 3 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ blank page 4 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ JMSの使用に必要なコンポーネント JMSプロバイダーとJMSクライアント JMSプロバイダー 以下のいずれかを選択 – WebSphere MQ（WMQ） ：別途ライセンスが必要 – 組み込みMQプロバイダー ：WASに付属（Express Editionを除く） JMSクライアント アプリケーションがJMSプロバイダーにアクセスするために必要となるライブラリ（JARファイルなど） ２つの接続形態 – クライアント ：JMSプロバイダーとTCP/IP経由で接続 – バインディング ：ローカル（同一マシン）のJMSプロバイダーとメモリ間通信で接続 （※）バインディング接続は、JMSプロバイダーが WebSphere MQの時のみ可能 JMS クライアント （※） WAS JMSプロバイダー （WMQ / 組み込みMQ) JMSプロバイダー （WMQ / 組み込みMQ) 5 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ JMSの使用に必要なコンポーネント ＜Note＞ WAS環境に、以下を導入します。 JMSプロバイダー 以下のいずれかを用途によって選択します．選択方法については、次ページ以降を参照してください。 1. WebSphere MQ（WMQ） – WASのほかに別途WMQのライセンスが必要となりますが、WebSphere MQが提供するすべての機能を使用 することができます 2. 組み込みMQ – WASに含まれるコンポーネント(Express Editionを除く）なため別途ライセンスは不要ですが、既存のMQネッ トワークに接続できないなど、制限があります． – 主に小規模システムや、テスト環境で使用するJMSプロバイダーです JMSクライアント JMSプロバイダーにアクセスするために必要となるクラス・ライブラリです。WAS導入時に”組み込みメッセージング・クラ イアント“フィーチャーを選択することで導入されます。 JMSアプリケーションが稼動するWASマシン上に導入します。 WMQ / 組み込みMQのどちらにもアクセス可能です。 JMSクライアントには、クライアント接続とバインディング接続の2種類の接続形態があります。 組み込みMQプロバイダーを使用している場合は、クライアント接続のみ可能です。 JMSプロバイダーとして組み込みMQを使用している場合は、アプリケーションが稼動するWASと、組み込みMQが稼 動する環境が同一セル内である必要があります。 6 ＜MQ-WAS連携-第３章＞ JMSプロバイダーの選択 WebSphere MQ V5.3 既存のWebSphere MQネットワークとの接続が可能 WebSphere MQの機能をフルに使用可能 WASのほかに、製品版WebSphere MQのライセンスが別途必要 組み込みMQ 実体は、WebSphere MQ V5.3 の機能制限版 小規模サイトや、テストシステムをターゲットとしている WASに付属（Express Edition を除く） “組み込みメッセージング・サーバー” フィーチャーをインストール時に選択 １つのマシンにWMQと組み込みJMSプロバイダーを両方インストールすることも可能 すでにWMQが導入されているマシンで、WAS導入時に組み込みMQも導入することができます。 すでにWAS+組み込みJMSが導入されているマシンで、組み込みJMSをWMQへグレードアップすること ができます。 手順の詳細は、InfoCenter をご参照下さい。 7 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ blank page 8 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ WebSphere MQ JMS プロバイダーとしてWebSphere MQを選択することで、以下が可能 既存のWebSphere MQネットワークとの接続 既存の非JavaのMQアプリケーションとの連携 IMS・CICSブリッジを介したレガシー・システムとの連携 WebSphere Business Integrator Message Broker (WBIMB) やEvent Brokerとの連携 WebSphere MQの機能をフルに使用可能 MQクラスター SSLで保護された接続 Base Javaインターフェースの使用 CUI/GUI ツールによるMQ資源の構成管理 Copyright ISE Co,.Ltd 9 ＜MQ-WAS連携-第３章＞ 組み込みMQ JMS プロバイダーとして組み込みMQを選択した場合の制限事項 J2EE環境内の非同期通信でのみ使用可能 WebSphere MQネットワークとの接続は不可 同一セル 内WAS上で稼動するJMSクライアントからのみアクセス可能 アクセス可能なプログラミング・インターフェースはJMSのみ その他 MQクラスターの使用不可 １つのノードに複数キュー・マネージャーを定義できない キュー等の管理は、wsadmin か管理コンソール経由のみ MQExplorer/Service といったツールは使用不可 パラメーターの変更はほとんどできない SSLチャネルの使用不可 <組み込みMQのキューマネージャー設定値> 設定値 WAS_ホスト名_サーバー名 SYSTEM.DEAD.LETTER.QUEUE 819 104857600 2MB(512page） 3 60 キュー・マネージャー名(QMNAME) デッド・レター・キュー(DEADQ) CCSID(CCSID) 最大メッセージ長(MAXMSGL) ログサイズ(LogFilePages) １次ログ(LogPrimaryFiles) ２次ログ(LogSecondaryFiles) 10 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ （参考）JMSプロバイダーの選択 主な相違点 WebSphere MQ 組み込みMQ ライセンス 別途MQのライセンスが必要 WebSphere のライセンスに含まれる メンテナンス方法 WebSphere MQのCSD WebSphere Application fix pack 他のMQとの接続 ○ ○ MQクラスター プログラミングI/F 機能 管理 × JMS以外も可能 （Base Java、C、VBなど） × JMSのみ セキュリティー WebSphere MQ ネイティブのセキュリティー J2EEセキュリティー アプリケーションの接続形態 バインディング（ローカル）接続 クライアント接続 クライアント接続のみ 起動・停止 MQ提供のコマンド/ツール WebSphere 管理コンソール オブジェクト（キュー・チャネル 等）の管理 MQ提供のコマンド/ツール WebSphere 管理コンソール wsadmin JNDI オブジェクト（QCF、 Destination等）の管理 WebSphere 管理コンソール WebSphere 管理コンソール 11 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ blank page 12 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ (参考)メンテナンス方法について WebSphere MQ とWASのバージョンの関係 WASのバージョンを基準に、WebSphere MQのメンテナンス・レベルを維持する必要があり ます WASのバージョンと、MQの前提メンテナンス・レベル WebSphere Application Server のバージョン 5.0.0 no fix pack 5.0.1 fix pack 1 5.0.2.x fix pack 2 + any cumulative fix for 5.0.2 5.1.0.x no fix pack + any cumulative fix for 5.1 MQのCSDレベル MQ V5.3 ＋ CSD1 MQ V5.3 ＋ CSD2 MQ V5.3 ＋ CSD3 MQ V5.3 ＋ CSD4 13 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ (参考)メンテナンス方法について ＜Note＞ WebSphere MQと組み込みMQのメンテナンス方法は構成によって異なります。 1.WebSphere MQのみをJMSプロバイダーとしてインストールしている場合 WebSphere MQのCSDを使ってメンテナンスします。 WASのfix pack適用時には、「Embedded Messaging / WebSphere MQ update」オプションをはずしてください（適用し ない） 2.組み込みMQのみをJMSプロバイダーとしてインストールしている場合 WASのfix packを使ってメンテナンスします。 WebSphere MQのCSDを適用してはいけません。 fix pack インストール時「Embedded Messaging update」オプションを選択して下さい。 3.WebSphere MQと組み込みMQの両方をインストールしている場合 WebSphere MQのCSDと、WASの fix pack の両方を適用してメンテナンスします。 WebSphere MQのCSDが、MQのメンテナンスを行います。 WASの fix pack が、JMS組み込みBrokerのメンテナンスを行います。 先にWebSphere MQのCSDを適用し、次に WAS の fix pack を適用してください。 WASの fix packは、WebSphere MQのCSDがインストールされていることを検知し、JMS組み込みBrokerのみのメ ンテナンスを行います。 WebSphere MQのCSDを適用する際、WASの fix packにインストールされるCSDのレベル以上である必要がありま す。 →前ページの表参照 出典：TechNote「Applying maintenance to WebSphere® Application Server V5 Embedded Messaging」 http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&uid=swg21166016&loc=en_US&cs=utf-8&lang=en 14 ＜MQ-WAS連携-第３章＞ ＜トポロジー設計＞ 15 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ トポロジー設計における検討事項 MQ-WAS連携のシステム設計を行う上で考慮する要素 機能要件 オンライン / 非同期 照会処理 / 更新処理 メッセージの順序性保障する / しない etc・・・ 非機能要件 パフォーマンス 可用性 トランザクション・レート レスポンス・タイム 連続稼動時間 障害検知時間＋Take Over時間 セキュリティー メンテナンス性 コスト 16 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ MQ-WAS連携トポロジー 全体像 以下の２箇所のトポロジー構成を検討 Webサーバー⇔WAS間 WAS⇔MQ間 ※WebコンテナとEJBコンテナのJMSを分けた構成はここでは触れません。 詳細は、以下の資料を参照して下さい。 W/S資料「WebSphreインフラストラクチャー・デザイン・ワークショップ」 W/S資料「WAS 5.1 インフラ構成の心得」 Webサーバー WAS MQ MQ Appl WAS MQ MQ Appl LoadBalancer Webサーバー 17 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ blank page 18 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ Webサーバー⇔WASの１：１構成 WebサーバーからWASへの割り振りが１：１にマッピング WASの障害検知とリクエストの割り振りはLoadBalancerが行う LoadBalancerからのヘルスチェックとしてWAS上のアプリケーションを使用することで、MQ資 源の障害も検知可能 ヘルスチェック・アプリケーションと従来のMQ監視の仕組み（イベントなど）を組み合わせることで、様々 な障害を検知することが可能 →ヘルスチェックについては後述 WASサーバー Web サーバー 業務用 アプリケーション Webサーバー プラグイン ヘルスチェック アプリケーション Web サーバー WASサーバー キュー・マネージャー LoadBalancer 業務用 アプリケーション Webサーバー プラグイン ヘルスチェック アプリケーション キュー・マネージャー Copyright ISE Co,.Ltd 19 ＜MQ-WAS連携-第３章＞ Webサーバー⇔WASの１：N構成 WebサーバーからWASへの割り振りが１：N（たすきがけ） WASの障害検知とリクエストの割り振りはWebサーバーPlug-inが行う WebサーバーPlug-inがWASの障害を検知 リクエストに対して返答を戻さないサーバーには割り振りを行わない WebサーバーPlug-inが検知するのはWASのプロセス障害のみで、ヘルスチェックアプリケーションの実 行は不可 MQ資源を含めた監視は難しい WASサーバー Web サーバー 業務用 アプリケーション Webサーバー プラグイン キュー・マネージャー LoadBalancer Web サーバー WASサーバー 業務用 アプリケーション Webサーバー プラグイン キュー・マネージャー 20 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ MQ障害時の挙動の違い １：１構成 LoadBalancerが正常な系統にリクエストを割り振る ヘルスチェック・アプリケーションによるMQ障害の検知（後述） Webサーバー WAS MQ LoadBalancer WAS Webサーバー MQ １：N構成 WebサーバーPlug-inの機能ではMQ障害を検知不可 WASがダウンしない限り、リクエストは両系統に割り振られる→アプリケーションや運用でカバーが必要 Webサーバー WAS MQ LoadBalancer WAS Webサーバー MQ Copyright ISE Co,.Ltd 21 ＜MQ-WAS連携-第３章＞ （参考）1:1 vs 1:N の判断材料 MQの監視以外の観点からも、Web⇔WAS間のトポロジーを検討 コスト、メンテナンス性など １：１ １：N １： 障害検知の範囲 Webサーバー、WAS、サブシステムまで 検知することができる LoadBalancerはWebサーバーまで検知可能 WebサーバーPluginはWASまで検知可能だが アプリケーションやサブシステムの検知はできない 障害検知時間 ヘルスチェックの実行間隔（デフォルト7 秒） Webサーバー障害時は同左 WAS障害時はPluginが即時に検知 Webサーバー障害時 １：１でマッピングされているので、WAS も1台分使えなくなる WASのアベイラビリティは変わらない WAS障害時 １：１でマッピングされているので、Web サーバーも使えなくなる Webサーバーのアベイラビリティは変わらない 定期/緊急時メンテナンス 片肺運転について LoadBalancerによりリクエストをの割り 振りを動的に制御できる WebサーバーPluginを手動編集して対応 コスト Webサーバーがリモートの場合Webサーバーの台数分だけ１：Nが高くなる 22 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ MQ⇔MQ間のトポロジー 機能要件・パフォーマンス・可用性を踏まえて、以下の３つの観点で選択する ① WASと同一筐体にMQを入れる/入れない ② 1:1接続 vs 1：N （MQクラスター）接続 ③ キュー・マネージャーの2重化をする/ しない ① Webサーバー WAS ② ③ MQ Appl MQ Appl MQ LoadBalancer WAS Webサーバー MQ HA Takeover MQ Appl Copyright ISE Co,.Ltd 23 ＜MQ-WAS連携-第３章＞ 機能要件 機能要件と、MQ⇔MQトポロジー設計は密接に関係する例 オンライン / ディレード ディレード処理の場合はWASマシンにMQを配置し、バインディング接続を行うことを検討 –バックエンド障害 や N/W障害時にも、WAS上のアプリケーションは処理を続行したい オンライン処理のみの場合はクライアント接続で要件が満たせることが多い バインディング接続 WAS MQ チャネル MQ Appl MQ Appl クライアント接続 WAS 照会処理 / 更新処理 照会処理などで、メッセージのロストを容認できる場合 –メッセージはNon-Persistent –障害時の資源の引継ぎは不要なのでMQ資源の2重化は必須ではない 更新処理などで、メッセージのロストを容認できない場合 –メッセージはPersistent –障害時に資源の引継ぎは必須 → MQ資源の2重化（HA構成）を検討 24 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ パフォーマンス要件を満たす方法 1.MQクラスターによる負荷分散 クラスターによる負荷分散 MQ アプリケーションは１つの宛先のみ意識する クラスター内の各キュー・マネージャーに対し、 ラウンド・ロビン方式による負荷分散を行う PUSH型のワークロードバランシング WAS MQ MQ MQクラスター 2.キュー共用による負荷分散 （ｚ/OSのみ） キュー共用グループ アプリケーションは１つの宛先のみ意識する キュー共用グループに属するキュー・マネージャーの うちいずれかがメッセージを処理する、PULL型の ワークロードバランシング MQ WAS MQ MQ 3.アプリケーションによる負荷分散 アプリケーションが宛先を切り替えながらメッセージの送信 を行う コーディングが煩雑になるためあまりお奨めではない MQ WAS MQ MQ Copyright ISE Co,.Ltd 25 ＜MQ-WAS連携-第３章＞ 可用性を向上させる方法 1.MQクラスターの使用 クラスターの使用 キュー・マネージャー障害時や、N/W障害時には、自動的にメッセージを稼動中のキュー・マネー ジャーに振り分ける 障害発生時に処理中の資源（メッセージ）は引き継がれない –障害対象のキュー・マネージャーの復旧を 待つ必要がある MQ WAS MQ MQ MQクラスター 2.キュー・マネージャーの キュー・マネージャーの2重化 キュー・マネージャーの 重化 別マシン上で同一キュー・マネージャーをリスタート 手動による切り替え –障害発生時に処理中の資源（メッセージ）は引き継がれない 自動切換え –障害発生時に処理中の資源（メッセージ）を引き継ぐ WAS MQ Takeover 共有DISK MQ MQ 26 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ 可用性を向上させる方法（続き） 3.キュー共用の使用 （ｚ/OSのみ） 障害発生時には、キュー共用グループ内で稼動中の キュー・マネージャーが処理を引き継ぐ（Peer Recovery） –資源（メッセージ）は引き継がれる キュー共用グループ MQ WAS MQ MQ 4.アプリケーションによる接続先切り替え アプリケーションがメッセージの送信に失敗したら、別の キュー・マネージャーに送信を行う コーディングが煩雑になるためあまりお奨めできない MQ –資源の引継ぎは別途考慮する必要あり WAS MQ 27 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ blank page 28 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ ①WASと同一筐体にMQを入れる/入れない WASと同一筐体にMQを入れない アプリケーションは、キュー・マネージャーにクライアント接続 WAS側にキュー・マネージャーが不要なため、低コスト・運用の簡素化 N/W障害時、接続先キュー・マネージャー障害時には処理続行不可 –同期型アプリケーションに向いている WAS MQ Appl バックエンド・サーバー WASと同一筐体にMQを入れる アプリケーションは、同一OS上のキュー･マネージャーにアクセス バックエンドのキュー・マネージャー障害、N/W障害時にもアプリケーションの処理を続行可能 –非同期型アプリケーションに向いている アプリケーションはバインディング接続でキュー・マネージャーに接続 WAS MQ MQ Appl バックエンド・サーバー 29 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ ①WASと同一筐体にMQを入れる/入れない ＜Note＞ WASと同一筐体にMQを入れない アプリケーションは、リモート・マシン上のキュー・マネージャーに、ネットワーク経由でクライアント接続します。 この構成ではWAS側にWebSphere MQを導入する必要がないため、コスト、運用・管理の簡素化という点で有利です。 但し、ネットワーク障害時や、リモート・マシン上のキュー・マネージャー障害時には処理が続行できませんので、同期型のアプリ ケーションには対応できますが、非同期型アプリケーションには不向きです。 WASと同一筐体にMQを入れる アプリケーションは、同一OS上のキュー･マネージャーにアクセスします。 バインディング接続を使用します(※) キュー・マネージャーとメモリ間接続で接続します。 この構成では、リモート・マシン上のキュー・マネージャー障害時や、ネットワーク障害時にもアプリケーションはメッセージを send することが可能です。従って、非同期アプリケーションに適しています。 また、MQクラスター機能を使用してMQ⇔MQ間でたすきがけ構成を取りたい場合には、WAS側にMQを導入します。 （※）WASと同一筐体にMQを入れる場合でも、クライアント接続を使用することも可能です。 30 ＜MQ-WAS連携-第３章＞ ②MQ⇔MQの1:1構成 MQ⇔MQは１：１で接続 パフォーマンス WAS⇔バックエンド・サーバー間でワークロード・バランシングは発生しない –WASのワークロードの比率がそのままバックエンド・サーバーのワークロードの比率となる 可用性 N/W障害やバックエンドのMQ障害時には、WAS以降の系統がすべて使用不能になる –LoadBalancerやWebサーバーで障害を検知し、正常サーバーへのリクエストの割り振りを行わ せる Webサーバー WAS Webサーバー WAS MQ Appl MQ Appl MQ LoadBalancer MQ ※この構成の場合は、非同期通信の要件が無ければWAS側にMQは不要です。 WAS上のアプリケーションから直接バックエンドのMQにクライアント接続を行うことで要件を満たすことが できます。 Copyright ISE Co,.Ltd 31 ＜MQ-WAS連携-第３章＞ ②MQ⇔MQの1:N構成 MQ：MQが、１： １：Nの構成 １： MQクラスターを使用して１：N のたすきがけを実現 WAS側にキュー・マネージャーが必要 パフォーマンス フロントエンドのMQ⇔バックエンドのMQでラウンドロビン式の負荷分散 Web⇔WAS間で、重み付け割り振りやAffinityを使用している場合でも、バックエンドの処理は 均一化される MQ Cluster Webサーバー WAS Webサーバー WAS MQ Appl MQ Appl MQ LoadBalancer MQ バックエンド・サーバー ※MQクラスター以外の１：N構成の方法（共用キューやアプリによる振り分け）については当セッションでは触れません。 Copyright ISE Co,.Ltd 32 ＜MQ-WAS連携-第３章＞ ②MQ⇔MQの1:N構成(続き) 可用性 バックエンドのMQ障害時 MQクラスターの機能により、稼動中のMQにリクエストが割り振られる 障害が発生したMQ上で処理中だったメッセージについては、そのMQを再起動するまで処理不可 →しかかり中メッセージに対応するためには、バックエンドMQの2重化を検討（後述） フロントエンドのMQ障害時 アプリケーションの処理は続行不可 LoadBalancerやWebサーバーに障害を検知させ、正常サーバーへリクエストを割り振らせ る必要がある N/W障害時 非同期アプリケーションは処理継続可能。同期アプリケーションはタイムアウト MQ Cluster Webサーバー WAS Webサーバー WAS MQ Appl MQ Appl MQ LoadBalancer MQ Copyright ISE Co,.Ltd 33 ＜MQ-WAS連携-第３章＞ ③キュー・マネージャーの2重化 H/Wを二重化しておき、障害時には別のマシンに切り替えることによって業務の継続が可能 1.資源の引継ぎが不要な場合 別マシン上で待機系キュー・マネージャーをスタート 手動による切り替え 2.資源の引継ぎが必要な場合 別マシン上で同一キュー・マネージャーをリスタート メッセージは障害直前の状態に回復（パーシステント・メッセージの場合） チャネルはそのまま継続使用可能 WAS上アプリケーションはキュー・マネージャーに再接続 するだけでよい MQ 以下のような製品を使用 Appl HACMP ホスト名：host1 Solaris QMGR名 ：QMGR1 for AIX Sun Cluster HP Service Guard Windows MSCS OS/390 ARM Takeover 共有DISK MQ Appl ホスト名：host1 QMGR名 ：QMGR1 34 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ MQ-WAS連携における障害設計 従来（非WAS環境）のMQ監視 MQコマンド / OSコマンド / イベント監視ツールを使用して、以下の情報を監視 MQイベント・メッセージ MQシステム・メッセージ（エラー･ログ） オブジェクト の属性 MQオブジェクトの属性 従来のMQ監視の方法については、以下の資料を参照 SIL「WebSphere MQ 運用管理ガイド」（SIL-04-038N） Appl エラーログ MQ イベント MQ-WAS連携におけるMQ監視 LoadBalancerやWebサーバーの障害検知機能と、従来のMQ監視機能を組み合わせて 監視を行う オブジェクト の属性 アドバイザー LoadBalancer WASPlug-in Webサーバー Appl エラーログ MQ イベント 35 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ MQ-WAS連携における障害設計 ＜Note＞ 従来（非WAS環境）のMQ監視 MQは、以下の3種類のインターフェースを通じて稼動状況を報告します。 MQイベント・メッセージ –イベント発生時に、MQはイベント・キューにMQメッセージを出力 –キューのイベント・メッセージを監視 MQシステム・メッセージ（エラー･ログ） –イベント発生時に、MQはエラー・ログ（ファイル）にエラー・メッセージを出力 –エラー・ログのメッセージを監視 MQオブジェクトの属性 –イベント発生時に、MQはMQオブジェクトの属性を更新 –以下を使用して、オブジェクトの属性を定期的に照会 »RUNMQSCコマンド / コマンド・メッセージ / MQINQコール 一般的なMQ監視では、これらの情報を、MQコマンド / OSコマンド / ツール で監視し、必要なアクションを起こします。 MQ-WAS連携におけるMQ監視 WAS環境でMQを使用する場合は、従来のMQ監視に加えて、LoadBalancerのアドバイザーやWebサーバーPlug-inといっ た機能を使用してMQ資源の監視を行い、クライアントからのリクエストを割り振る必要があります。 ここでは、MQ-WAS連携特有の監視方法とその考慮点について説明します。 36 ＜MQ-WAS連携-第３章＞ ヘルスチェックによる障害検知 Webサーバーのヘルスチェック アドバイザーによるヘルスチェックはデフォルトで７秒間隔 順番に１つずつ実行される（Webサーバー１、Webサーバー２･･･） １つのサーバーのヘルスチェックに要する時間は、ヘルスチェック・アプリケーション依存 ヘルスチェック・アプリケーションから返答がない場合は、デフォルトで21秒でタイムアウトし、次のサーバー のチェックに移る MQを監視するヘルスチェック・アプリケーションの処理時間が増えれば、障害検知時間も長くなる ヘルスチェック アプリケーション MQ Webサーバー ヘルスチェック アプリケーション MQ Webサーバー ヘルスチェック アプリケーション MQ Webサーバー LoadBalancer 37 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ ヘルスチェックによる障害検知 ＜Note＞ Webサーバーのヘルスチェック Webサーバーのヘルスチェックを行うには、前述のようにWebサーバーとWASが１：１構成である必要があります。 LoadBalancerはバックエンド・サーバーの障害検知を、定期的にアドバイザーを実行することで行います。このアドバイザーの 実行間隔は、デフォルト7秒です。また、デフォルトで21秒間レスポンスがなかった場合にサーバーをダウンとみなします。 アドバイザーは同時に実行されず、例えば3台のバックエンド・サーバーが存在した場合、それらに対して順番に実行されます。 例えば、3台のうち2台目のサーバーがダウンしていた場合、まず１台目のヘルスチェックを行い、2台目のサーバーで21秒間タイ ムアウトを待ちます。次に、3台目のサーバーに対するヘルスチェックを終えます。 つまり、アドバイザーの実行時間も合わせると障害検知に最低約28秒間かかることになります。よって、LoadBalancerによる 障害検知では、対象サーバーが増えれば増えるほど、検知に時間がかかってしまう恐れがあります。 ヘルスチェック・アプリケーションの実行時間が長い場合は、障害検知時間はさらに長くなります。 38 ＜MQ-WAS連携-第３章＞ ヘルスチェックによるMQ資源の監視 ヘルスチェック・アプリケーションによるMQ資源の障害検知 ローカルのMQ資源のみ監視 - ① 非同期型アプリケーションの場合は、ローカルの資源のみ監視 –キュー・マネージャー・プロセス –キュー バックエンドのMQ資源やアプリケーションまで監視 - ② 同期型（Request-Reply)の場合は、リモートの資源まで監視することが必要 –チャネル / ネットワーク –バックエンドのキュー・マネージャ・プロセス –宛先キュー –バックエンドのアプリケーション ヘルスチェック アプリケーション Webサーバー LoadBalancer MQ ② ① ヘルスチェック アプリケーション Webサーバー Appl MQ バックエンド・サーバー MQ Appl MQ Copyright ISE Co,.Ltd 39 ＜MQ-WAS連携-第３章＞ ヘルスチェックによるMQ資源の監視 ローカルMQ資源の障害 方法 ： ヘルスチェック・アプリケーションは、キュー・マネージャーに接続し、キューに対して メッセージのPUTを行う 障害検知時間 ： キュー・マネージャープロセス障害 キュー障害 － ヘルスチェック実行時（MQとの接続時）に即時に検知 － ヘルスチェック実行時（キューへのPUT時）に即時に検知 キューFULL LoadBalancer ヘルスチェック アプリケーション Webサーバー 障害検知 40 MQ Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ ヘルスチェックによるMQ資源の監視 リモートのMQ資源・アプリケーション 方法1： ヘルスチェック・アプリケーション用に、下図のようなキュー構成を組む ヘルスチェック・アプリケーションは、RemoteキューにPUTし、リプライを待つ 監視できる範囲は、リモートのキュー・マネージャーとチャネルのみ – リモートのアプリケーションや、業務用のキューの監視まで行う場合は、方法２を使う Appl ヘルスチェック アプリケーション RemoteQ ReplyQ 方法2： XMITQ RemoteQ MQ XMITQ MQ ヘルスチェック・アプリケーションはRequestメッセージを送信し、Replyを待つ ヘルスチェック・アプリケーションは、業務用のRequestキューとReplyキューを使用 – この方法が採れるかどうかは、アプリケーションに依存 障害検知時間 ： ヘルスチェック・アプリケーションがReplyメッセージを待つ際に指定するタイムアウト値に依存 タイムアウト値は、正常時のレスポンス・タイムを元に計算 長すぎると、結果として障害検知時間が長くなってしまう 41 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ ヘルスチェックによるMQ資源の監視 ＜Note＞ ヘルスチェック･アプリケーションでリモートのMQ資源・アプリケーションを監視する方法にはいくつか考えられますが、 代表的なものとして以下があります。 方法1： ヘルスチェック・アプリケーション用に、上図のような構成を組みます。 MQのリモート・キューの定義を組み合わせることにより、WAS側のRemoteキューにPUTすると自動的にReplyキューに返っ て来る構成にします。 WAS側のRemoteキューは、バックエンド側のRemoteキューをポイントする バックエンド側のRemoteキューは、WAS側のReplyキューをポイントする ヘルスチェック・アプリケーションは、RemoteキューにPUTし、Replyを待ちます。この場合、監視できる範囲はリモートの キュー・マネージャーとチャネルです。バックエンドのアプリケーションや、業務用のキューの監視を行うことはできません。 方法2： ヘルスチェック・アプリケーションは業務用Requestメッセージを送信し、Replyを待ちます。 ヘルスチェック・アプリケーションは、業務用のRequestキューとReplyキューを使うため、この方法が採れるかどうかは、アプリ ケーションに依存します。 方法1の監視範囲に加え、バックエンドのアプリケーションや、業務用キューの監視も行えます。 考慮点 これらの方法は、ヘルスチェック・アプリケーションがRequestメッセージをPUTしてからReplyメッセージを待つため、障害発生 時の検知時間が長くなり、あまり効率的な障害検知は望めません。 従来のMQ監視の仕組みとヘルスチェックを組み合わせることで、より効率的な障害検知を行うことができます。 42 ＜MQ-WAS連携-第３章＞ イベント・メッセージの使用 MQイベント・メッセージ機能をヘルスチェックと合わせて使用する MQイベント・メッセージを監視し、障害発生時にヘルスチェック・アプリケーションが使用する キューをPUT禁止にすることで、LoadBalancerへの障害通知時間を短縮可能 ヘルスチェック・アプリケーションはローカルMQ資源のみを監視し、リモートのMQ資源はイベント・メッ セージを使用して監視 監視可能なイベントの例 チャネル障害（リモートのキュー・マネージャ・プロセスや、ネットワーク障害を含む） キューFULL / キューの滞留状況 キューのサービス間隔 イベント監視ツールを使用 MQ和尚 ,Tivoli , OMEGAMON など 製品によっては、リモートのキュー・マネージャーで発生したイベントを検知することも可能 – リモートのMQ資源の障害検知時間の短縮 イベント監視 ツール PUT禁止 ヘルスチェック アプリケーション Webサーバー LoadBalancer イベント MQ Appl MQ Copyright ISE Co,.Ltd 43 ＜MQ-WAS連携-第３章＞ （参考）イベント・メッセージ ＜Note＞ MQはMQの稼動状況やエラー情報をイベントとして出力 チャネル停止や、キューFULLといった「イベント」が発生すると、「イベント・メッセージ」がイベント・キューにPUTされます。 出力されたイベント・メッセージを取得（GET）することで、MQ資源の監視を行うことが可能です。この方法には以下の２つがあ ります。 イベント・キューを監視するアプリケーションを作成する MQ和尚、Tivoli、OMEGAMONのような製品を使用 詳細は、SIL「WebSphere MQ運用管理ガイド」を参照してください。 キュー・マネージャー キュー・マネージャー チャネル アプリケーション ネットワーク イベント チャネル キューFULL キュー イベント・キュー 44 エラーログ ＜MQ-WAS連携-第３章＞ （参考）ヘルスチェックとMQクラスター MQクラスター構成を取っている場合は、バックエンドMQ/ネットワークの片系障害時の 検知はMQが行う MQクラスターの機能で障害系へのメッセージ割り振りを停止 ヘルスチェックの監視範囲は、WASと同一Node上のMQまで 但し、両系障害の場合はMQイベント監視によるLoadBalancerへの通知を検討 MQクラスターによる障害監視 MQクラスターによる障害監視 LoadBalancerによる障害監視 LoadBalancerによる障害監視 Webサーバー ヘルスチェック アプリケーション MQ ヘルスチェック アプリケーション MQ MQ Appl MQ Appl LoadBalancer Webサーバー バックエンド・サーバー 45 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ ＜まとめ＞ 46 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ 1.J2EE環境と既存のMQネットワークを連携する場合 トポロジー例１ Webサーバー⇔WASは１：１構成 MQクラスターによる負荷分散＋可用性の確保 バックエンドサーバー側MQで、障害時に短時間での資源引継ぎが必要な場合は、 2重化を検討 ミッションクリティカルなシステム・大規模なシステム向け バックエンド・サーバー MQ Cluster Webサーバー WAS Webサーバー WAS MQ Appl MQ Appl MQ LoadBalancer MQ HA Takeover MQ 47 Appl Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ 1.J2EE環境と既存のMQネットワークを連携する場合＜Note＞ トポロジー概要 Webサーバー⇔WAS間 MQ資源の監視の観点から、たすきがけは行いません。 WAS上にはMQ資源を監視するヘルスチェック・アプリケーションを配置します。 WAS⇔バックエンド・サーバーのMQ MQクラスターを構成し、負荷分散と、障害時のリクエストの正常サーバーへの自動割り振りを行います。 バックエンド・サーバーのMQは必要に応じてHA構成にし、片系障害時の早期復旧と資源の引継ぎを行います。 メリット フロントエンド・サーバー⇔バックエンド・サーバー間の負荷分散 フロントエンド・サーバーでの負荷比率にかかわらず、バックエンド同士の負荷比率は均等になるというメリットがあ ります。 バックエンド・サーバー障害時のリクエスト自動割り振り MQクラスターの機能により、アプリケーションには透過的に正常サーバーへのリクエスト割り振りが行われます。 デメリット WAS側にもMQが必要になるため、コストがかかります。 WAS側にもMQが必要になるため、MQの運用や監視を考慮する必要があります。 48 ＜MQ-WAS連携-第３章＞ 1.J2EE環境と既存のMQネットワークを連携する場合 トポロジー例２ MQクライアント接続を利用し、WAS⇔MQ間の負荷分散は行わない 障害時にはLoadBalancerに検知させ、正常サーバーにリクエストを割り振らせる Webサーバー⇔WASは１：１構成 WAS上にヘルスチェック・アプリケーションを配置 バックエンドサーバー側MQで障害時に資源の引継ぎが必要な場合は、2重化を検討 バックエンド・サーバー Webサーバー WAS LoadBalancer MQ Appl MQ Appl クライアント接続 Webサーバー WAS HA Takeover MQ 49 Appl Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ 1.J2EE環境と既存のMQネットワークを連携する場合＜Note＞ トポロジー概要 Webサーバー⇔WAS間 MQ資源の監視の観点から、たすきがけは行いません。 WAS上にはMQ資源を監視するヘルスチェック・アプリケーションを配置します。 WAS⇔バックエンド・サーバーのMQ WAS上のアプリケーションはバックエンド・サーバーのキュー・マネージャーにクライアント接続を行います。 負荷分散は行われません。 バックエンド・サーバー障害時には、WAS上で稼動するヘルスチェック・アプリケーションによりLoadBalancerに障害を検 知させる必要があります。 障害時に短時間での資源の引継ぎが必要な場合は、バックエンド・サーバーのMQをHA構成にします。 メリット WAS側にキュー・マネージャーが不要なため、コスト的に有利です。 WAS側にキュー・マネージャーが不要なため、運用・管理を単純化することができます。 デメリット 負荷分散を行えません。 いかなるコンポーネント（Webサーバー、WAS、MQ、サーバーアプリ)で障害が発生しても、片系統の全面障害とみなされ、リ クエストは割り振られません。 50 ＜MQ-WAS連携-第３章＞ 2．J2EE環境内で非同期アプリケーションを作成する場合 トポロジー例 （JMSプロバイダーとして組み込みMQを使用した場合の構成） JMSプロバイダー障害時にはLoadBalancerに検知させ、正常系にリクエストを割り振らせる Webサーバー⇔WASは１：１構成 フロントエンドWAS⇔バックエンドWAS間での負荷分散はない 以下を行うのであれば、WebSphere MQが必要 Webコンテナ⇔EJBコンテナ間の負荷分散 JMSプロバイダーやEJBコンテナの片系障害時に、正常系にのみリクエストを割り振る JMSプロバイダーの2重（HA)化 サーブレット JavaBean Webサーバー 組み込みMQ • 帳票作成 大量SQLなど WAS （EJBコンテナ） WAS （Webコンテナ) LoadBlancer MDB レスポンスに時間 の掛かる処理 クライアント接続 Webサーバー サーブレット JavaBean MDB 組み込みMQ WAS （Webコンテナ) WAS （EJBコンテナ） セル 51 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ 2．J2EE環境内で非同期アプリケーションを作成する場合 ＜Note＞ トポロジー概要 Webサーバー⇔WAS間 MQ資源の監視の観点から、たすきがけは行いません。 WAS上にはMQ資源を監視するヘルスチェック・アプリケーションを配置します。 WAS⇔バックエンド・サーバーのMQ WAS上のアプリケーションはバックエンド・サーバーのキュー・マネージャーにクライアント接続を行います。 負荷分散は行われません。 バックエンド・サーバー障害時には、WAS上で稼動するヘルスチェック・アプリケーションによりLoadBalancerに障害を検 知させる必要があります。 メリット 組み込みMQを使用するため、コスト的に有利です。 デメリット 負荷分散を行えません。 いかなるコンポーネント（Webサーバー、WAS、JMSプロバイダー、サーバー側アプリ)で障害が発生しても、片系統の全面障 害とみなされ、リクエストは割り振られません。 以下の要件がある場合にはJMSプロバイダーとしてWebSphere MQ が必要になります。 バインディング接続（ローカル接続） バックエンドのWAS障害時にも処理を続行する必要のある、非同期アプリケーションなど フロントエンドWAS⇔バックエンドWAS間の負荷分散 MQクラスターの使用 キュー・マネージャーのHA化 52 ＜MQ-WAS連携-第３章＞ 参考資料 マニュアル WAS V5.0.x / V5.1 InfoCenter WebSphere MQ Using Java (SC34-6066-01) RedBook / WhitePaper等 Selecting the most appropriate JMS provider for your applications. (White Paper) JMS Topologies and Configurations with WebSphere Application Server and WebSphere Studio Version5 (IBM Software Services for WebSphere) IBM WebSphere Application Server V5.1 System Management and Configuration (Red Book) ISE 資料 W/S資料「WMQ Javaインターフェース(Base & JMS) W/S」 W/S資料「WAS 5.1 インフラ構成の心得」 W/S資料「WebSphreインフラストラクチャー・デザイン・ワークショップ」 SIL「WebSphere MQ 運用管理ガイド」（SIL-04-038N） 53 Copyright ISE Co,.Ltd ＜MQ-WAS連携-第３章＞ blank page 54 Copyright ISE Co,.Ltd