インテリジェント管理 （２） WebSphere クライアント・テクニカル・プロフェッショナルズ 大脇 李奈 1
by user
Comments
Transcript
インテリジェント管理 （２） WebSphere クライアント・テクニカル・プロフェッショナルズ 大脇 李奈 1
WASV8.5最新情報セミナー インテリジェント管理 （２） 日本アイ・ビー・エム株式会社 WebSphere クライアント・テクニカル・プロフェッショナルズ 大脇 李奈 1 Agenda 1. インテリジェント管理の概要 2. 保守モード 3. ヘルス管理 4. アプリケーション・エディション管理 5. まとめ © 2012 ＩBM Corporation 2 2 1. インテリジェント管理の概要 © 2012 ＩBM Corporation 3 3 インテリジェント管理機能各要素の概要 インテリジェント・ルーティング インテリジェント・ルーティング •優先度とゴールに基づく サービス・レベル管理 性能 ビジネス優先度に応じて、重要度の低いリクエストをキューイングし、重要度の高いリクエストを即座に処理 ビジネス優先度に応じて、重要度の低いリクエストをキューイングし、重要度の高いリクエストを即座に処理 パフォーマンス管理 パフォーマンス管理 •過負荷状況の自動回避 •リソースの有効活用 ーラ スケ ティ ビリ ー 負荷状況に応じて割り振りの重みを動的に計算 負荷状況に応じて割り振りの重みを動的に計算 リソース状況に応じてアプリケーションの配置を変更し、JVMの数を動的に制御 リソース状況に応じてアプリケーションの配置を変更し、JVMの数を動的に制御 ヘルス管理 ヘルス管理 •障害の未然防止と迅速な 復旧 性 可用 障害兆候の検知 障害兆候の検知 自動対処 自動対処 アプリケーション・エディション管理 アプリケーション・エディション管理 •サービス無停止でのアプリ ケーション更新 運用 アプリケーション・バージョンの無停止でのリリース＆ロールバック アプリケーション・バージョンの無停止でのリリース＆ロールバック 複数バージョンの並行稼働 複数バージョンの並行稼働 © 2012 ＩBM Corporation 4 インテリジェント管理機能の各要素と、新しいITトレンドにおける非機能要件とのマッピングです。 １．インテリジェント・ルーティングが優先順位に応じて流量制御を行い、優先度とビジネス目標に基 づくサービス・レベル管理が可能になり、サービス・レベル向上につながります。 ２．パフォーマンス管理が本番稼働中突発的なトランザクション増加にも対応可能で、サーバーの過 負荷状況を回避しつつ、割り振りの重みを動的に計算して割り振りをします。またリソース状況に応 じてアプリケーションの配置を動的変更してJVMの数を動的に制御し、リソースを有効利用しながら スケーラビリティーーを向上させます。 ３．ヘルス管理機能は障害の未然防止と迅速な復旧を可能にし、システムの可用性や耐障害性を 向上させます。 ４．アプリケーション・エディション管理はユーザーに影響を与えずアプリケーションのバージョンアッ プや並行稼働を容易に実現し、サービスの継続性を実現しながら、運用負荷の低減を実現します。 このセッションでは、インテリジェント・ルーティングとパフォーマンス管理を説明して、この後のセッシ ョンでは、ヘルス管理およびアプリケーション・エディション管理を説明します。 4 2. 保守モード © 2012 ＩBM Corporation 5 5 保守モード 保守モード：サーバーは稼働中のまま、対象ノードへのリクエストの割振りを停止 しかかり中の処理を終えてからサーバー停止が可能 ユーザーの作業を中断せずにノードを停止し、保守作業が可能 アプリケーション・エディション管理で前提となる機能 ヘルス管理におけるアクションに含まれる ⇒詳細は次章 WebSphere ND V8.5環境 稼働ノード ③保守作業の実施 OSパッチの適用やH/W部品交換 など ①保守モード 対象ノードへの新規リクエス オンデマンド・ルーター ト の ルーティングを停止 保守対象ノード ⑤保守モード解除 保守モードを解除すると リクエストのルーティング © 2012 ＩBM Corporation を再開 ②サーバー停止 しかかり中の処理の完了を待って アプリケーション・サーバーを停止 ④サーバーの再開 サーバーを再度スタート 6 6 保守モード メンテナンス対象サーバーへのODRからのリクエスト割り振りを停止 動的クラスターの場合、最小インスタンス数の確保が可能 他のサーバーに影響を与えずにメンテナンスや問題判別が可能 APCと連携して最小値を満たすように他サーバーを起動 3つのレベルでの保守モードをサポート ノード アプリケーション・サーバー ODR ¾ © 2012 ＩBM Corporation ODR メンテナンス中 前段にIHS plug-inの配置が前提 7 7 保守モードの種類 アプリケーション・サーバー単位での保守モードの設定には、３種類がある 保守モード デフォルトの保守モードでは、新規セッションのリクエストの割振りが停止される。その サーバーにセッションを保持するリクエストの割振りは継続されるので、一定時間タイム アウトなどでセッション数がある程度減るのを待ってサーバー停止が図ることが可能。 保守モード - アフィニティー中断 サーバーで処理中のリクエストの終了を待たずに、ただちに保守モードに移行。 保守モード - 即時停止 アフィニティー中断モードに加えて、サーバーを停止。 ノード単位での保守モードでは、「アフィニティー中断」はない © 2012 ＩBM Corporation 8 アプリケーション・サーバーレベルでは、アプリケーション・サーバーがWAS ND V8.5の場合に限り 以下の3つの種類の保守モードをサポートします。 保守モード： アフィニティーのあるリクエスト（既存のHTTPセッションのリクエスト）以外のリクエスト は他のサーバーに振るモード。新規リクエストは保守モード中のサーバーには振られない。 保守モード – アフィニティー中断： アフィニティーがあるリクエストも他のサーバーに振られるモード。 セッションを持続させるためには、サーバー間でのセッション共有が必須。 保守モード－即時停止： しかかり中のリクエストも含めて即時に割り振りを停止するモード 保守モードの対象がNon-WebSphereの場合は、どの種類の保守モードでも「保守モード-アフィニ ティー中断」の挙動になり、アフィニティーはブレークされます。 標準： 保守モードを解除し、リクエストの割振りを再開します なお、ここでnon-WebSphereサーバーの対象はミドルウェア・エージェントが導入された環境をさし、 汎用サーバー・クラスターのメンバー・サーバーには保守モードは適用できませんのでご注意くださ い。 8 保守モード：まとめ 保守モードを使用すると、 サービスを維持したまま、サーバーメンテナンスやアプリケ ーションの更新が可能に ⇒無停止運用が求められる環境などに有用 ヘルス管理でも利用可能 アプリケーション・エディション管理を使う上で前提となる © 2012 ＩBM Corporation 9 9 3. ヘルス管理 © 2012 ＩBM Corporation 10 10 ヘルス管理とは：障害の兆候検知と復旧 サーバー#1 サーバー#2 販売業務 一般ユーザー サーバー#3 ヘルス・ポリシー 販売業務用クラスター 応答が遅いな ODR #1 販売業務 応答時間 販売業務 メモリ使用量 テストユーザー ダンプ出力・サーバー再起動 うん、遅い ヘルス条件 以下の3つを設定して監視 ・ヘルス条件 ・ヘルス・アクション ・ターゲット ヘルス・アクション ヘルス条件に違反したら アクション実施 ・異常を通知（メール /SNMPトラップ） ・ダンプ出力 ・サーバー再起動 モニタリングしたい項目を設定 ヘルス管理機能は障害の兆候を未然に検知して ヘルス管理機能は障害の兆候を未然に検知して アクションを実行 アクションを実行 システムの「健康状態」を監視し、ヘルス・ポリ システムの「健康状態」を監視し、ヘルス・ポリ シーに従って検知＆アクションを実行 シーに従って検知＆アクションを実行 ヘルス・ポリシーでは、検知のためのヘルス条件と ヘルス・ポリシーでは、検知のためのヘルス条件と 検知時のアクションの内容を定義 検知時のアクションの内容を定義 WAS WASV8.0以前では障害が起きてから対処とリアク V8.0以前では障害が起きてから対処とリアク ティブであったのに対し、V8.5からは障害を未然に防 ティブであったのに対し、V8.5からは障害を未然に防 止する機能を実装しプロアクティブに対処できる 止する機能を実装しプロアクティブに対処できる © 2012 ＩBM Corporation レポート 通知（メール・SNMP) DM 監視アクション実施 命令 システム管理者 11 11 ヘルス・ポリシー ヘルス条件とヘルス・アクションとターゲットを組み合わせ、ヘルス・ポリシーとして定義 ヘルス・ポリシーの定義 ヘルス条件 メモリー使用量などの閾値を条件として設定 この閾値を越えるとポリシー違反とみなされる ヘルス・アクション ヘルス条件違反時にとるアクションを定義。 サーバー再始動、メモリー/ヒープダンプの取 得などのアクションがとれる。 ターゲット モニタリング対象： セル、クラスター、サー バー/ノード、ODR から選択 © 2012 ＩBM Corporation 12 12 ヘルス管理による障害未然防止の例 ヘルス管理 割り振りを停 止した上で 自動で資料 取り＆ 回復処理を 自動実行！ 異常検知 ヘルス条件に、 タスク管理（DM) ・要求タイムアウト超過 ・メモリー使用量超過条件 を指定 管理者 通知受信 保守モード設定 各アクション実行毎に タスク登録 ヘルス管理のアクション 実行結果の確認 （タスク画面でのログ 確認） スクリプト実行 （通知） 必要に応じてプロセス 障害通知 ヒープダンプ 取得 必要に応じてサー バーアクセス ダンプの退避 サーバー再起動 ヘルスモニタリングの運用手順 保守モード解除 保守モード解除を確認 障害を未然防止・アクションを自動化することで、 運用の負荷を低減 © 2012 ＩBM Corporation 13 13 ヘルス条件とアクション 「ヘルス条件」には、事前定義ヘルス条件とカスタム・ヘルス条件の2種類 がある 事前定義ヘルス条件 ¾ カスタム・ヘルス条件 ¾ WAS ND V8.5のインストール時に作成されるデフォルトで 使用できる条件 PMIなどでの計測情報などを元に自分で条件を作成できる 「ヘルス・アクション」は以下2つの観点から定義する 「リアクション・モード」 ¾ ¾ 自動：違反時に自動アクション 監視：ランタイムタスクに通知され、 オペレーターの承認を待って実行 「ヘルス・アクション」の内容 ¾ ¾ サーバー再始動やダンプ出力などがある カスタムアクションとしてスクリプトの実行など が可能 © 2012 ＩBM Corporation 14 ■事前定義ヘルス条件 ・WAS ND V8.5のインストール時に作成される条件 ・応答時間超過やメモリー使用量超過などの定義がある ■カスタム条件 ・デフォルトで足りない場合に作成する 14 【参考】ヘルス条件：事前定義ヘルス条件の一覧 ヘルス条件 説明 期間ベース条件 モニタリング対象サーバーの開始時からの最大存続時間を設定。時間または日で設 定。 要求タイムアウト超過条件 モニタリング対象サーバーが処理する要求の中でタイムアウトが発生する比率の閾 値（%)を設定。 応答時間超過条件 モニタリング対象サーバーからの平均応答時間の閾値を設定。 メモリー条件：メモリー使用量超過 モニタリング対象サーバーのメモリー使用量の最大ヒープサイズに対する比率の閾 値と、その閾値を超えている時間の閾値を設定。 メモリー条件：メモリー・リーク メモリー・リーク検知のための条件。検出のレベルとして3段階から選択。低速検出で はより長い時間での過去データが使用されるため検出の精度は高くなるが検出には 時間がかかる ストーム・ドレイン条件 エラーを返しているようなケースで、応答時間が正常時に比べて著しく短くなっている 状態を検知するための条件。検出のレベルは2段階から選択。 ワークロード条件 モニタリング対象サーバーが開始してから処理可能な合計リクエスト数の閾値を設定 。 ガーベッジ・コレクション・パーセンテージ 指定された期間内で JVM がガーベッジ・コレクションに使用する時間が、定義された パーセンテージを超えていないかどうかを判定。 New © 2012 ＩBM Corporation 15 15 【参考】ヘルス条件：カスタムヘルス条件の一覧 条件をルールで記述 管理コンソールでは、ルール作成を支援するルール副次式ビルダーを提供 ヘルス条件 説明 PMI メトリック: サーバー始動から 接続プール（JDBC）、システムモジュール、プロセスモジュール、EJB モジュール、Webアプリケーションモジュール、JVMランタイムモジュ ール、スレッドプールモジュール PMI メトリック: 最後に報告された間隔 ODR サーバー・レベル・メトリック: サー バー始動から ODR サーバー・レベル・メトリック: 最後 に報告された間隔 ODR セル・レベル・メトリック: ODR 開始 から ODR セル・レベル・メトリック: 最後に報 告された間隔 MBean 属性メトリック: Long 戻りの型 出発数、応答時間 (ミリ秒)、現在実行中の要求数、サービス時間 (ミ リ秒)、平均待機時間 (ミリ秒)、サービス時間 (ミリ秒)、平均待機時間 (ミリ秒)、エラー、サービス済み、タイムアウト 出発数、応答時間 (ミリ秒)、現在のキューの長さ、サービス時間 (ミ リ秒)、エラー、平均キュー長、サービス済み、タイムアウト、現在実 行中の要求数、到着数、キュー・オーバーフロー除去数、遅延、平均 待機時間 (ミリ秒) Mbeanの値をもとに条件を作成 MBean 属性メトリック: String 戻りの型 URL戻りコード・メトリック ターゲット・サーバー上のURLから返されるステータスコードをもとに 条件を作成 外部URL戻りコード・メトリック 外部URLから返されるステータスコードをもとに条件を作成 © 2012 ＩBM Corporation 16 16 【参考】ヘルス・アクション アクション一覧 アクション 説明 サーバー再始動 ヘルス条件に違反したサーバーを再起動。APCと連携してサービ ス・ポリシー違反を起こさないように実施される スレッド・ダンプの取得 ヘルス条件に違反したサーバー上でスレッドダンプを取得 JVMヒープダンプの取得 ヘルス条件に違反したサーバー上でJVMヒープダンプを取得 SNMPトラップの生成 SNMPマネージャーにトラップを送信。 サーバーを保守モードに設定す る ヘルス条件に違反したサーバーを保守モードに設定。アフィニティ ーがあるものは、終了を待って保守モードに移行。 サーバーを保守モードおよびア フィニティー中断に設定する ヘルス条件に違反したサーバーを保守モードに設定。アフィニティ ーがあるものも、強制的に中断される。 サーバーを保守モードから外す 保守モードを解除し標準モードへ切り替える リアクションモード 自動 監視 © 2012 ＩBM Corporation 17 ■本番環境でいきなり自動モードにするのではなく、テスト環境において十分に検証をするのはもち ろん、本番環境でもある程度の運用期間を設けておいてから、自動モードに切り替えることをお勧め 17 カスタム・アクション カスタム・アクション 独自のスクリプト、プログラムを実行 コンソールで登録 ¾ ¾ アクションの実行先は選択可能 ¾ ¾ ¾ ¾ 「動作ポリシー > カスタム・アクション」にて 定義 実行可能ファイル、引数、OSなどを指定 違反を起こしたノード DMGR ODRノード/サーバー 指定したノード/サーバー 複数アクションの実行をサポート 設定例（ログ収集シェル） 名前: LogCollect 実行可能ファイル: /opt/mws/bin/logCollector.sh 実行可能引数: なし オペレーティング・システム: UNIX /opt/mws/bin/ ©作業ディレクトリー: 2012 ＩBM Corporation 18 ヘルスモニタリングでは、適用可能な条件、アクションには一部制約がありますが、non-WebSphereがヘルスモ ニタリングの対象として選択可能になりました。 また、カスタム条件およびカスタムアクションの作成をサポートします。カスタム条件は、コマンドライン・ユーティ リティーから管理コンソールのメニューに登録します。カスタム条件では、モニタリングしたいヘルス条件を複数 組み合わせてより複雑な条件を作成したり、以下のような情報を組み込むことが可能です。 •ODR上のPMIメトリック •URIリターンコード（ODRで取得） •各サーバーのPMIメトリック、MbeanのOperationまたはAttribute（WAS ND V8.5 サーバーのみサポート） •ANDやORを使用した複数条件の組み合わせ また、カスタム・アクションでは、あらかじめ用意した独自のシェルスクリプトやjava、non-javaを含むプログラムを アクションを実行したノードに配置しておき、そのファイルのロケーションを指定することでアクションとして実行 することをサポートします。カスタム・アクションは実行ファイルのパスやパラメーターなどをあらかじめ管理コンソ ールから登録しておくことで1アクションとしてヘルスポリシー定義時に選択可能となります。アクションの実行は 違反を起こしたサーバー以外にもデプロイメント・マネージャーやODRを含めたどのノード、どのサーバー上で も実行可能です。 また、複数アクションの実行もサポートされています。アクションはステップの番号順に実行されます。 18 【参考】ヘルス・ポリシーの新規作成画面（カスタム条件） ルールの記述には、副次式ビルダーを使用できる © 2012 ＩBM Corporation 19 19 ヘルス・コントローラー ヘルス管理を司るオートノミック・マネージャー 以下の設定項目がある コントロール・サイクル長：ヘルス条件のチェックを行う時間間隔 最大連続再始動： サーバーの再始動を試行する回数。この回数 を越えても開始しない場合、サーバーは使用不可とみなされる 再始動タイムアウト： サーバーの再始動が失敗したとみなすまで 待機する時間 最小再始動間隔： サーバーの次の再始動までに待機する時間。 この時間中のヘルス条件違反へのアクションは保留される （値範囲： １５分~３６５日） 再始動禁止時間： サーバーの再始動を禁止する期間 © 2012 ＩBM Corporation 20 20 【参考】ヘルス・コントローラーの無効化方法(1/2) 方法（管理コンソールから）: 1. 2. 管理コンソールから、「動作ポリシー」>「オートノミック・マネージャー」>「ヘルス ・コントローラー」を開く 「構成」または「ランタイム」タブの「ヘルス・モニターを使用可能にする」のチェ ックを外して、OKを押す – – ランタイム： 一時的にヘルス・コントローラーを停止 構成： 恒久的にヘルス・コントローラーを停止 © 2012 ＩBM Corporation 21 詳細はこちら⇒ http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wve.doc/ae/twve_oden ablehealth.html http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-ndmp&topic=rwve_odhmmscripts ■ヘルス管理を無効にするケース 基本的に動いていてOKなものなので、止める理由はない テストのときなどに、ポリシーに違反させないように一時的に止めるといったことがケースとし て考えられる 21 【参考】ヘルス・コントローラーの無効化方法(2/2) 方法（スクリプトから）： 1. 2. <APP_SERVER_ROOT>/bin ディレクトリに移動 wsadmin.sh –profile HmmControllerProcs.jacl –c ”disable” を実行 – 無効化に成功してもメッセージは何も出ないことに注意 使用状況の確認方法： 1. 2. <APP_SERVER_ROOT>/bin ディレクトリに移動 wsadmin.sh –profile HmmControllerProcs.jacl –c ”isEnabled” を実行 – このケースでは無効化になっていることが確認できる © 2012 ＩBM Corporation 22 22 ヘルス管理：まとめ ヘルス管理を使用すると、 障害を未然に防止することが可能に ⇒無停止運用が求められる環境などに有用 ヘルス状態のモニタリングから復旧アクションを自動化 ⇒管理者の運用負荷を軽減 © 2012 ＩBM Corporation 23 23 4. アプリケーション・エディション管理 © 2012 ＩBM Corporation 24 24 アプリケーション・エディション管理とは 複数の同一アプリケーションを異なるエディションとして管理でき、サービス停止 することなくアプリケーションをロールアウトが可能 妥当性検査モードにより、本番環境内にテスト環境を一時的に作成して最終テス トを行うことも可能 従来のWAS NDにも「更新のロールアウト」機能があったが、V8.5からはアプリ ケーション・エディション管理によるアップデートが推奨される 保守モードがバックで動くためODRが必須 機能としては3つに分かれる 複数エディション管理 ロールアウト 妥当性検査モード 妥当性検査 ロールアウト 又はアクティブ化 第2回 アプリ導入 ロールアウト 又はアクティブ化 非アクティブ 第1回 アプリ導入 アクティブ アンインストール アンインストール © 2012 ＩBM Corporation アプリケーションのライフサイクル 25 ■アプリケーションのライフサイクルとは： ・第1回アプリケーション導入 アプリケーション導入時にエディションを指定 エディション管理は、ear単位（又はwarでも可） ・第2回アプリケーションを導入してロールアウト 2つ目のエディションのアプリは、導入時には非アクティブ状態 ロールアウトして対象エディションが活動化されて、前エディションは活動停止 グループ・ロールアウトとアトミック・ロールアウトの２つの方法 ・妥当性検査（オプション） テスト用の一時的な動的クラスタが自動作成され、アプリケーションを稼働 25 アプリケーション・エディション管理による無停止運用例 ②ロールアウト： ・V2をロールアウトしてアクティブ化 ・V1は非アクティブ状態になる サーバー#1 通常アクセス 一般ユーザー ODR #1 サーバー#3 V1 V1 V1 V1 V2 V2 V2 V2 V2 テスト クラスター V2 テストユーザー サーバー#2 本番 クラスター ①複数エディション 管理： ・V1を本番クラス ターに導入（アクティ ブ状態） ・V2も同じ本番クラ スターに導入（非ア クティブ状態） テスト用アクセス ③妥当性検査モード ・テストクラスターを自動作成 ・V2がマッピングされてアクティブ化 ・テストユーザーのみアクセスなど、 ルーティング・ポリシーを設定 ・V2を本番クラスターへロールアウト すると、テストクラスターは自動削除 © 2012 ＩBM Corporation アプリケーションの更新 中も、サービス継続 26 26 ロール・アウトとは 概要 複数のエディションが導入されている場合、次期リリースのエディションを「ロール・アウト」するこ とで、無停止で切り替えが可能 ロール・アウトには「アトミック」および「グループ」の2種類の「ポリシー」が利用可能。特性を理解 して使い分ける必要がある ¾ グループ・ロールアウト ： 指定したサーバー・インスタンス数ずつ更新 ¾ アトミック・ロールアウト ： 半分ずつ更新 ODRと連携：更新処理中のリクエストを制御 DCluster01 ノード1 グループ・ロールアウト実行例 ノード2 ODR ノード3 ユーザー 制約 入れ替え対象の新旧アプリケーションは、以下の要件と満たしている必要がある ¾ ¾ セッションを維持したい場合、セッション共有構成は必須 エディション間での互換性は必須 同時に複数のロールアウトを実行することは不可 ロールアウト中の管理操作は不可 © 2012 ＩBM Corporation 27 ■制約事項： ・セッションを維持したい場合、セッション共有構成は必須 ・新旧アプリケーションでセッション・オブジェクトは共有されるため、アプリ ケーションが扱うセッションの内容に変更があるような場合は考慮が必要 ・エディション間での互換性は必須 ・アプリケーションの仕様上、画面遷移に不整合が発生するようなケース では適用不可 ・つまりメジャーリリースの様な大きな更新の場合は、一旦すべてのユー ザーのアクセスを停止する必要があるケースが多いため、バグFixやUIの 変更など業務ロジックなどに変更が加わらないような場合に適用する事に なる（その場合、並行稼働を検討） ■その他： ・ロールアウト実行時には、ファイルの転送が発生しないため更新処理が迅速 ・バージョンの戻し（ロールバック）も同様の手順でサポート ・オンラインサーバーが1台でもサービス中断が発生しない。 ・更新中のリクエストはODRでキューイング 27 ロールアウトの流れ アトミックロールアウトの更新フロー 更新前 更新中 全アクセスが Edition2 STOP 更新開始 更新中 全サーバ Edition2に 更新完了 STOP 全アクセス がEdition1 へ 更新完了 グループ・ロールアウトの更新フロー 更新前 更新中１ STOP 新規ユーザーリ クエストが Edition1にふら れる可能性有 © 2012 ＩBM Corporation 更新中３ 更新完了 STOP 更新開始 更新中２ 最後の1台の更 新が開始される とEdition2のみ アクセス可 28 28 【参考】ロールアウト実行時のパラメータ ロール・アウトのポリシーとして「アトミック」か「グループ化」を択一指定。 アプリケーションの更新単位をどのように分割するかを指定するパラメータ。 切り替え時のリセット方法として、「ソフト」か「ハード」か、を択一指定。 アプリケーションのロードをどのようにして行うか、を指定するパラメータ。 •ソフト・リセット： アプリケーションの停止・開始 •ハード・リセット： サーバーの停止・開始 「ドレーン間隔」を、秒単位で指定。 • 新規リクエストの割振りを停止し、エディションの切替えを実施するまでの時間 • この間、セッション・アフィニティーを持つリクエストのみ対象サーバーに割振られ る © 2012 ＩBM Corporation 29 29 ロールアウト実行時のパラメータの特性比較 ロール・アウト計画 アドミック・ロールアウト ポリシー グループ・ロールアウト メンバー数 ÷2 切り替え時の更新単位（メンバー 数） 指定した数 なし エディションの混在 あり あり 応答遅延 なし 比較的短い 更新時間 比較的長い 処理能力が半減 その他考慮点（選択基準） アプリのバージョンが混在 計画のリセット ソフト・リセット ポリシー ハード・リセット アプリケーション リセット単位 サーバープロセス 短い 起動処理時間 長い なし ライブラリの更新 あり ドレーン間隔 ODRは、ロールアウトを開始したグループへの新規リクエストの割振りを停止し、アフィニティーの効いた リクエストのみ割振りを継続。この時間は、アフィニティーが効いたクライアントからの一連のリクエストの 終了を待機するために存在する。このドレーン間隔の長さは、ロールアウト開始時に秒単位で指定するこ とが可能。 © 2012 ＩBM Corporation 30 30 複数エディション管理とは 概要 以前のWASの構成では、一時点で導入可能な同一アプリケーションは1エディショ ンのみ WAS ND V8.5からは、導入時に「エディション」を指定することで、複数のエディ ションを導入可能 エディションには、「アクティブ/インアクティブ」などのライフサイクルの概念 が存在 アプリケーションのエディション系の管理は、「エディション・コントロール・セン ター」で実施 制約 1時点でアクティブにできるのは、同一ターゲット内で1つのみ ¾ ¾ 異なるターゲットであれば、1時点で複数のエディションをアクティブに設定可能 その場合は併せてルーティング・ルールの設定を行い、どのような条件どのターゲット（=エディショ ン）に割り振りを行うか、の設定が必要 © 2012 ＩBM Corporation 31 31 複数エディションの導入 複数のアプリケーション・エディションを導入可能 同一アプリケーション名、同一コンテキストを持つアプリケーションをエディション名で個別に識別、管理 通常のアプリケーション導入と同様の手順でインストール ¾ 「インストール・オプション」画面でエディションを明示的に指定 1アプリ1ディレクトリ、ディレクトリ下に 分けてEARが保持される 導入時に、エディションを指定 エディションの管理は、エディション・ コントロール・センター で行う エディションの設定内容は、ibm-edition-metadata.propsに保持 #File contains metadata for all editions of the application #Tue Mar 06 20:05:42 JST 2012 config.state-edition2.0=ACTIVE edition.desc-edition2.0= config.state-edition1.0=INACTIVE edition.desc-edition1.0= © 2012 ＩBM Corporation 32 32 複数エディションの同時稼働 ルーティング・ポリシー によって、条件に応じた割り振り制 御が可能です。 御が可能 通常アクセス サーバー#1 販売業務 販売業務 V1 V1 一般ユーザー ODR #1 テストユーザー サーバー#2 サーバー#3 販売業務用 本番 クラスター 販売業務 V1 販売業務 V1 販売業務用 テスト クラスター 販売業務 販売業務 V2 V2 販売業務 V2 ターゲットが異なる場合（こ こでは、本番/テスト クラスター）は、 同じ 販売業務のV1、 V2を 同時に稼働状態することが 可能 販売業務 V2 テスト用アクセス ターゲットが 同じ ターゲットが ターゲットが違う 違う © 2012 ＩBM Corporation アクティブなのは1つ 複数同時にアクティブ 33 33 妥当性検査モードとは 概要 一種の「複数エディション同時稼働」形態 テスト環境の自動生成 ¾ ¾ 本番構成の動的クラスターから1クリックでクローン・クラスターを生成 一時的にテスト環境で新エディションを稼働、テスト可能 z ¾ ¾ ルーティング・ルールに基づきODRがリクエストを振り分け 新エディションのロールアウトを実行するとテスト構成は自動削除 本番とテスト環境のリソース共有が可能に 一般 ユーザーリクエスト DCluster02 ODR テスターリクエスト DCluster02-Validation © 2012 ＩBM Corporation 34 妥当性検査モードも、1種の「複数エディション同時稼働」形態だが、 通常の「複数エディション同時稼働」と異なる点として、2つ目に稼働させようとするエディションの実 行環境（妥当性検査クラスター）を、元の導入クラスターのコピーとして、1クリックで作成してくれる点 がある 「複数エディション同時稼働」のケースと同様に、妥当性検査クラスターへの割り振りのルールを（ル ーティング・ポリシーとして）設定する必要がある。 テスト終了後は、「キャンセル（元の状態に戻す）」もしくは、ロール・アウト（元のクラスターで新エディ ションを稼働）を選択することが可能。その際、妥当性検査クラスターは削除される。 前提・制約 1つのアプリケーションで妥当性検査モードに出来るのは1つのエディションのみ アプリケーションの接続先となるデータソース設定もコピーされるので、テスト操作によるデ ータの更新を望まない場合は、テストを開始する前にテスト用データソースなどに変更を行 っておく必要がある 34 妥当性検査モードの設定の流れ 「エディション・コントロール・センター」から、「妥当性検査」をクリックすること で、妥当性検査モードが開始される もともと存在していたクラスターのコピーとして、 「妥当性検査クラスター」が 作成される アプリケーションのデプロイ・ターゲットが、 「妥当性検査クラスター」に変更さ れる © 2012 ＩBM Corporation 35 35 妥当性検査モード使用の前に 使用の前に、以下の追加設定・確認を行う必要がある テストに合わせたリソース設定 ¾ ¾ リソース設定などは、コピー元クラスターと同じ設定になっているので、そのまま使用す ると元のリソース設定のまま動作する 例えば、本番用データソースがそのまま使用され、意図せずデータの更新を行ってしま う事がありえるので、ルーティング・ルールの設定を行う前にテスト用データソースへの 切り替えなどを行っておく必要がある ルーティング・ポリシーの設定 ¾ ルーティング･ポリシーのルーティング･ルールにしたがってODRがエディション間の割り 振りを制御 z ¾ そのままでは妥当性検査クラスターへのルーティングは行われないので、どのような条件で 妥当性検査クラスターへルーティングを行うかを決定し、設定する必要がある ルーティング・ポリシーについては次ページ サーバー・リソース使用量に注意 ¾ 本番環境で妥当性検査モードを使用してクラスター環境を作ると、その分のリソースを 消費するため、あらかじめキャパシティーに余裕があるか確認する © 2012 ＩBM Corporation 36 36 ルーティング・ポリシーとは ① 概要 ODRがクライアントのリクエスト条件を判別 ¾ 例：妥当性検査時に、テストユーザーと一般ユーザーで割 り振り先を変える 条件に応じたアクションを採ることが可能 設定 以下を指定 ¾ ¾ 適用するルール・条件（①） 選択するアクション（②） ①リクエスト条件を判別 アプリケーション サーバー ② ODR アプリケーション サーバー ②条件に応じたアクション © 2012 ＩBM Corporation 37 37 【参考】ルーティング・ポリシーの構成 リクエストの割振りを制御するルールを設定 複数のルーティング・ルールを設定可能（上から順番に適用される） ルーティング・ルールは適用するルール（条件）とアクションからなる（副次式ビ ルダーで生成可能） ルールでは、変数に対する条件を設定 ¾ ¾ 変数： クライアントIP、クッキー等々（詳細は次ページ） 条件式： 等しい、等しくない、In、類似（LIKE）、大小文字を区別しない類似（LIKEIGNORECASE）、NULL、NOT NULL、類 似In、連結（＋）等々 アクションは次の6つから選択 ¾ ルーティングの許可： z 指定したエディションが稼働するサーバーへルーティング ¾ アフィニティーによるルーティングの許可 ¾ ルーティングのリダイレクト先 ¾ 戻りコードによるルーティングの拒否： ¾ 保守モードのサーバーへのルーティングの許可： ¾ 保守モードのサーバーへのアフィニティーを使用したルーティングの許可： z z z z z 指定したエディションにルーティングし、応答ヘッダにアフィニティーのためのクッキーを挿入 設定されたURLへリダイレクト 要求を拒否し、指定されたHTTPコードを応答 稼働するエディションに関わらず、保守モードのサーバーへルーティング 稼働するエディションに関わらず、保守モードのサーバーへルーティングし、応答ヘッダにアフィニティーのための クッキーを挿入 38 © 2012 ＩBM Corporation 38 【参考】 ルール条件に使用可能なHTTPオペランド オペランド 説明 要求照会パラメーター パラメーター名およびその値を設定。またはIS NULL、IS NOT NULLを使ってパラメーター自 体が存在するかを条件にすることも可能。 要求ヘッダー名 HTTPヘッダー名およびその値を設定。またはIS NULL、IS NOT NULLを使ってヘッダー自体 が存在するかを条件にすることも可能。 Cookieヘッダー名 Cookie名およびその値を設定。またはIS NULL、IS NOT NULLを使ってCookie自体が存在す るかを条件にすることも可能。 MIMEタイプ リクエストのMIMEタイプと値を設定。 HTTPメソッド 値にはGET/PUT/POST/DELETEが設定可能 クライアントホスト クライアントのFully-qualified client host nameを値に設定可能。演算子にIN,LIKEなどは使 用不可。 クライアントIPV4 クライアントのIPアドレス（IPV4) クライアントIPV6 クライアントのIPアドレス（IPV6) サーバーホスト サーバーのFully-qualified client host nameを値に設定可能。演算子にIN,LIKEなどは使用 不可。 サーバーIPV4 サーバーのIPアドレス（IPV4） サーバーIPV6 サーバーのIPアドレス（IPV6) ポート リクエストを受け付けるサーバーのポート番号を設定可能 プロトコル HTTP/HTTPS/SOAP/SOAPSが選択可能 © 2012 ＩBM Corporation 39 39 【参考】管理コンソール ルーティング・ポリシー設定 副次式ビルダー © 2012 ＩBM Corporation ルーティング・ポリシー設定 40 40 アプリケーション・エディション管理：まとめ アプリケーション・エディション管理を使用すると、 サービスを継続したまま、アプリケーションの更新が可能に ⇒エンドユーザー向けサービスなど、サービス無停止が求められ る環境に有用 ターゲットを変えることで複数エディションも並行稼働が可能に ⇒ユーザー別にアプリケーションのバージョンを変えたい場合や、 妥当性検査モードでのテスト時に有用 妥当性検査モードにより、本番環境でのテストが可能に ⇒本番と同等環境でテストをしたい、テスト環境が準備できないな どの場合に有用 © 2012 ＩBM Corporation 41 41 5. まとめ © 2012 ＩBM Corporation 42 42 インテリジェント管理：まとめ インテリジェント・ルーティング インテリジェント・ルーティング •優先度とゴールに基づく サービス・レベル管理 性能 ビジネス・ユーザーごとにサービス・レベルが異なる場合など ビジネス・ユーザーごとにサービス・レベルが異なる場合など サービス・ポリシーや動的ワークロード・マネージャーによって、サービス・レベルを維持可能に サービス・ポリシーや動的ワークロード・マネージャーによって、サービス・レベルを維持可能に パフォーマンス管理 パフォーマンス管理 •過負荷状況の自動回避 •リソースの有効活用 ーラ スケ ティ ビリ ー リソースがサイロ化している環境でサーバー集約したい場合など リソースがサイロ化している環境でサーバー集約したい場合など 動的クラスターによって、柔軟なリソース配置が可能に 動的クラスターによって、柔軟なリソース配置が可能に ヘルス管理 ヘルス管理 •障害の未然防止と迅速な 復旧 性 可用 ミッションクリティカルなシステムで障害発生による影響を最小化したい場合など ミッションクリティカルなシステムで障害発生による影響を最小化したい場合など 障害の未然防止と自動アクションによって、運用負荷の低減が可能に 障害の未然防止と自動アクションによって、運用負荷の低減が可能に アプリケーション・エディション管理 アプリケーション・エディション管理 •サービス無停止でのアプリ ケーション更新 運用 一般ユーザー向けなど止められないサービスのアプリケーションがある場合など 一般ユーザー向けなど止められないサービスのアプリケーションがある場合など 複数エディションのロールアウトによって、サービス無停止運用が可能に 複数エディションのロールアウトによって、サービス無停止運用が可能に © 2012 ＩBM Corporation 43 まとめ 43 【参考】ODRが必須の機能 ODRの構成が前提 備考 動的クラスター ARFM・APC・DMLMが稼働するため アプリケーション・エディション管理 保守モードを前提とするため Visualization ODRで取得する情報を使用するため 保守モード ODRでリクエストをキューイングするため © 2012 ＩBM Corporation 44 詳細： http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-ndmp&topic=welc6topwve 44 参考文献 「WebSphere Application Server V8.0 アナウンスメント・ワークショップ 資料」 ¾ 「WebSphere Application Server V8.0によるWebシステム基盤設計ワ ークショップ資料」 ¾ http://www.ibm.com/developerworks/jp/websphere/library/wxd/wve7_ws/ 「WebSphere Virtual EnterpriseによるWebシステム運用負荷軽減のヒ ント」 ¾ http://www.ibm.com/developerworks/jp/websphere/library/was/was8_guide/ 「WebSphere Virtual Enterprise ソリューション・ワークショップ資料」 ¾ http://www.ibm.com/developerworks/jp/websphere/library/was/was8_ws/ http://www.ibm.com/developerworks/jp/websphere/library/wxd/wve61_usecase/ 「WebSphere Virtual Enterprise を複雑な WebSphere Application Server のトポロジーに組み込む」 ¾ http://www.ibm.com/developerworks/jp/websphere/library/wxd/wve_was_topology/ © 2012 ＩBM Corporation 45 45 ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提 供の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むも のでもありません。本講演資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗 示にかかわらずいかなる保証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる 損害が生じた場合も、IBMは責任を負わないものとします。 本講演資料に含まれている内容は、IBMまたはそのサプライヤーやライセンス交付者から いかなる保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図した ものでもなく、またそのような結果を生むものでもありません。 本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを暗 示するものではありません。本講演資料で言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定 権をもっていつでも変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありま せん。本講演資料に含まれている内容は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、また は暗示することを意図したものでも、またそのような結果を生むものでもありません。 パフォーマンスは、管理された環境において標準的なIBMベンチ マークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおける マルチプログラミングの量、入出力構成、ストレージ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。 したがって、個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではありません。 記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示さ れたものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。 IBM、IBM ロゴ、ibm.com、WebSphereは、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。 他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。 現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。 UNIXはThe Open Groupの米国およびその他の国における登録商標です。 JavaおよびすべてのJava関連の商標およびロゴは Oracleやその関連会社の米国およびその他の国における商標または登録商標です。 © 2012 ＩBM Corporation 46 46