websphere virtual enterprise...
TRANSCRIPT
© 2012 IBM Corporation
WVEソリューション・ワークショップ
WebSphere Virtual Enterpriseソリューション・ワークショップ~最高のエクスペリエンスを実現する自律型Webシステム~
優先度に応じた流量制御 と 動的リソース・アサイン
© 2012 IBM Corporation2
Disclaimer
この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレビューを受けておりません。
当資料は、資料内で説明されている製品の仕様を保証するものではありません。
資料の内容には正確を期するよう注意しておりますが、この資料の内容は2012年4月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能性があるのでご注意下さい。
今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。
IBM、IBMロゴおよびibm.comは、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点でのIBMの商標リストについては、http://www.ibm.com/legal/copytrade.shtmlをご覧ください。
JavaおよびすべてのJava関連の商標およびロゴは Oracleやその関連会社の米国およびその他の国における商標または登録商標です。
Microsoft, Windows および Windowsロゴは、Microsoft Corporationの米国およびその他の国における商標です。
Linuxは、Linus Torvaldsの米国およびその他の国における登録商標です。
UNIXはThe Open Groupの米国およびその他の国における登録商標です。
© 2012 IBM Corporation3
アジェンダ
1. ソリューション概要
2. サービス・ポリシー
3. リクエストの流量制御
4. 動的ワークロード管理
5. 動的クラスター
まとめ
© 2012 IBM Corporation4
ソリューション概要
~優先度に応じた流量制御と動的リソース・アサイン~
© 2012 IBM Corporation5
このセッションの位置づけ
5
可用性性能 スケーラビリティ運用管理効率化
アジリティ
仮想化 自動化
Webアプリケーション基盤に求められる機能仮想化&自動化による自律的アプリケーション基盤の実現へ
サービス継続性管理•障害兆候の監視と未然防止•障害の切り離し•障害からの自動復旧
サービス・レベル管理•ビジネス目標に則った必要なサービス・レベルの監視・維持
アプリケーション管理•サービス無停止でのアプリケーション更新・ロールバック•リリース前テスト支援
リソース管理•負荷の変動や障害等に応じたリソースの動的配分•容易なリソースの追加/変更
ワークロード管理•リソース間の負荷の平準化•過負荷による性能低下の防止
保守・運用作業支援•サービス無停止での保守作業
© 2012 IBM Corporation6
Webシステムのリクエスト処理における課題・原因・解決策
インフラが個々のアプリケーションのピークに合わせた冗長な構成となっている
資源増強を迅速に行えない
重要な処理のリクエストが、重要で無いリクエストと混在し、重要な処理の応答が悪化してしまう
課題 原因
インフラとアプリケーションが密接な関係をもっており、切り離して考えられないため
処理の種類に応じた優先度の設定やそれに基づく管理を行えていないため
アプリケーション層での仮想化を行い、インフラとアプリケーションを疎な関係に(インフラ・リソースをプール化)する
解決策
アプリケーションのリクエストの種類を識別し、それぞれに優先度を設定し、優先度に応じた割り振りを行う
優先度に応じた流量制御と動的リソース・アサイン
© 2012 IBM Corporation7
優先度に応じた流量制御の適用効果
顧客管理
顧客管理
顧客管理
サーバー#1
サーバー#2
サーバー#3
顧客管理クラスター
ユーザー層別・業務等による 優先度付けに対応したリクエストの流量制御
コールセンター
社内一般ユーザー(閲覧)
待機
社内一般ユーザー(特定の顧客処理)
セッションの有無、ユーザー層別・業務等による選択的な要求拒否
各サーバーの負荷に応じて割振りの重み付け を動的に変更
高
優先度
中
低
高
中
低
販売管理
販売管理
販売管理
販売管理クラスター
100%
0%50
%
CPU
100%
0%50
%
CPU
100%
0%50
%
CPU
ODRODR
アプリケーション・サーバーの一時的な高負荷時にも、優先度に応じて処理を行い、重要な処理を優先
© 2012 IBM Corporation8
動的リソース・アサインの適用効果
国内業務
国内業務 海外業務
海外業務
サーバー#1
サーバー#2
サーバー#3
国内業務用クラスター
海外業務用クラスター
リクエスト量に応じて、動的にアプリケーション・サーバーを起動/停止
国内ユーザー
動的にアプリケーション・サーバーの起動/停止を行うことで、
リソースを有効活用
海外ユーザー
100%
0%50
%
CPU
100%
0%50
%
CPU
100%
0%50
%
CPU
負荷の上昇
リクエストを停止し、
国内業務から海外業務へ変更
夜間は、国内ユーザーは減少し、海外ユーザーが増加
応答時間の悪化応答時間の減少
負荷の減少
ODRODR
© 2012 IBM Corporation9
オンデマンド・ルーター(ODR)
WAS
他社製アプリケーション・サーバー
優先度高
優先度低
リクエスト
1秒最高GOLD
5秒
3秒
目標平均応答時間
低
高
優先度
BRONZE
SILVER
サービス・ポリシー
サービス・ポリシー設定
優先度に応じた流量制御と動的リソース・アサインの関連コンポーネント
ARFM
DWLM APC
オートノミック要求フロー・マネージャー(ARFM)・ サービス・ポリシーごとのキューイング・ 優先順位付け・ 流量制御
動的ワークロード管理(DWLM)・ 動的重み付け・ ルーティング・ アフィニティー・ フェイル・オーバー
アプリケーション配置コントローラー(APC)・ サーバー負荷状況の取得・ アプリケーション・サーバーの動的起動・ アプリケーション・サーバーの動的停止
© 2012 IBM Corporation10
【参考】優先度に応じた流量制御と動的リソース・アサインの各コンポーネント
オンデマンド・ルーター (ODR)– Java プロキシー上に実装されたインテリジェントなリバース・プロキシー– オートノミック要求フロー・マネージャー及び動的ワークロード・マネージャーが動作
オートノミック要求フロー・マネージャー (ARFM)– オンデマンド・ルーター(ODR)に到着したリクエストは、サービス・ポリシー(重要度&目標応答時間)ごとのキューに入れられる(長さはデフォルト1000)
– 各サービス・ポリシーごとに、リクエスト処理に要したCPUリソース量を計測– 到着したリクエストの必要リソース量(CPU/メモリー等)を計算し、不足が想定される場合にはキューで保持(直ちに拒否するオプションもあり)
– サービス・ポリシーに基づき、目標値を達成するようにキューからサーバーへディスパッチ– 高い重要度のサービス・ポリシーを優先
動的ワークロード・マネージャー (DWLM)– サーバーの負荷状況を分析して、各サーバーへの割振りの重み付けを決定– 重み付けラウンド・ロビン方式で、リクエストをルーティング– オン/オフが可能(デフォルトでは、動的クラスターではオン、静的クラスターではオフ)
アプリケーション配置コントローラー (APC)– ARFMからのCPUリソース不足の通知を受けて、必要ならアプリケーションの配置を変更– 配置変更の決定に基づき、動的クラスター・メンバーの起動/停止を実行
© 2012 IBM Corporation11
サービス・ポリシー
~リクエストの優先度の設定~
© 2012 IBM Corporation12
オートノミック要求フロー・マネージャー (ARFM)
オンデマンド・ルーター(ODR)
ARFMゲートウェイ
DWLM
ARFMコントローラー
② 取得した統計情報から流量制御のためのウェイト値を計算
① リクエスト統計情報
③ ウェイト値
④ ウェイト値に従って流量を制御
APC
Ⅱ. リクエストの必要リソース情報
ワーク・プロファイラー
Ⅰ. リクエスト処理に必要なCPU要件を計算
動的クラスター
サービス・ポリシーに基づいてリクエストをキューイングし、流量制御を行うオートノミック・マネージャー
– オートノミック要求フロー・マネージャー(ARFM)を構成するコンポーネント• ゲートウェイ (すべてのODRで稼動)• コントローラー (セル内で1つ稼動)• ワーク・プロファイラー (セル内で1つ稼動)
© 2012 IBM Corporation13
【参考】オートノミック要求フロー・マネージャーの調整
ゲートウェイのキューの最大キュー長。キューが最大値に達すると要求はリジェクトされる
ゲートウェイがリクエストの統計情報を取得し公開する間隔
コントローラーがサービス状況を収集しキューのウェイト計算などを実行する間隔
コントローラーがゲートウェイから受け取る最後のいくつまでの統計データから計算するかを指定
管理コンソール:[ 動作ポリシー]-[オートノミック・マネージャー]-[オートノミック要求フロー・マネージャー]
ARFMゲートウェイ △ △
ARFMコントローラー
統計情報取得/配信
集約期間△
集約期間△
集約期間△
集約期間
△ △コントロール・サイクル
平滑化ウィンドウ
活動化ウェイト値計算
活動化ウェイト値計算
© 2012 IBM Corporation14
株取引
アプリケーション
カスタマー
サポートアプリケーション
アプリケーション
ワーク・クラス
トランザクション・クラス
Gold
Bronze
サービス・ポリシー
目標応答時間重要度ポリシー名
平均応答時間1秒以内
平均応答時間5秒以内
高
低
種別ルール
得意先・CS_TC
一般・CS_TC
お得意様
一般顧客
All・株取引_TC
ユーザー=得意先
ユーザー=一般
ルール
レスポンス・タ
イム
得意先・CS_TCGold目標値
All・株取引_TC
Bronze目標値
一般・CS_TC
All・マスター検索_TC
Silver平均応答時間
2秒以内 中
/CS
/CS/master
/Stock/master/Stock
サービス・ポリシー設定の概要
© 2012 IBM Corporation15
サービス・ポリシー
動作ポリシーから作成
サービス・ポリシーリクエストのXX%が
X秒以内
サービスポリシー = 応答時間目標値と重要度の組合せ–応答時間目標値: 平均値、百分位応答時間、任意(=設定しない)–重要度: 7段階(最低 < 非常に低 < 低 < 中 < 高 < 非常に高 < 最高)–サービス・ポリシーは、トランザクション・クラスを介して、アプリケーションごとのリクエストと結び付ける
動作–重要度のより高いサービス・ポリシーを満たすように以下を実施
• アプリケーションの動的配置(高優先アプリケーションをホストするAPサーバーの稼動、必要に応じてAPサーバーの停止)
• 重要度に基づくリクエストの優先度別流量制御
バックエンドの過負荷を検知した場合に流量制御
(キューイング)を行う
© 2012 IBM Corporation16
応答時間目標のないサービス・ポリシーNewv7
サービス・ポリシーの設定がより簡単に–応答時間目標を指定することなしにサービスポリシーの利用が可能
–サービス・ポリシーの重要度のみでパフォーマンスを管理
使用シナリオ–データ量の増加などにより、応答時間が変化する場合–長時間実行要求や滞留要求が不定期に発生する場合–応答時間の目標を正確に確定できない場合
サービス・ポリシー適用ロジック–処理待ち時間を計測し、サービス・ポリシーに関連付けられている重要度と照らし合わせることで係数を算出、この係数に基づいて割り振り制御を行う
設定方法– “disableResponseTimeGoals=true” のセル・レベルのカスタム・プロパティーを設
定–注意
• すべてのサービス・ポリシーに対して使用可能になる。応答時間の目標があるサービス・ポリシーと応答時間の目標がないサービス・ポリシーを混在させることはできない
© 2012 IBM Corporation17
サービス・ポリシー
トランザクション・クラスの作成
アプリケーション定義 サービス・ポリシー
条件にヒットしない場合のトランザクション・クラス条件にヒットしない場合のトランザクション・クラス
ワーク・クラスとトランザクション・クラスを
関連付け
/CustomerSupport(CS.war)
トランザクション・クラス– サービス・ポリシーの別名– 各アプリケーションのワーク・クラスにてトランザクション・
クラスを指定
トランザクション・クラスを対象に管理者はモニタリング– サービス・レベルを監視
トランザクション・クラス
© 2012 IBM Corporation18
ワーク・クラス (作業クラス)
URLを指定
トランザクション・クラスを指定 割り振り先を指定
アプリケーション設定
アプリケーション単位・各プロトコル用に作成され、そこにルールによるポリシーとのマッピング(サービス・ポリシー/ルーティング・ポリシー)を設定– サービス・ポリシー:HTTP, SOAP, SIP, IIOP, JMS / ルーティング・ポリシー:HTTP, SOAP
サービスポリシーのHTTP要求用ワーク・クラスでの設定– URLごとに作成– アプリケーション導入時にコンテキスト・ルートのURL用デフォルト・ワーク・クラスを自動作成
– ワーク種別ルールによるトランザクション・クラスへのマップを定義
© 2012 IBM Corporation19
種別ルール
種別ルールの条件
アクションを選択
トランザクション・クラスを選択
条件によりルーティング・アクションを変更
条件によりトランザクション・クラスを変更
アプリケーション設定
条件、トランザクション・クラスを指定
ルールは複数指定可能
条件にヒットしない場合のトランザクション・クラス
サービス・ポリシー、あるいはルーティング・ポリシーにおける条件別ルールの設定– サービス・ポリシー:トランザクション・クラスの選択
– ルーティング・ポリシー:アクション、アプリケーション・エディションの選択
© 2012 IBM Corporation20
複数のルールを設定可能(上から順番に適用)
適用するルール(条件)の記述は、副次式ビルダーで生成可能– 使用できるオペランド:クライアントIP、クッキー等々(詳細は次ページ)– 使用できる演算子
• AND• OR• NOT• ヌル値(IS NULL)• ヌル値でない(IS NOT NULL)• 等しい(=)• 等しくない(<>)• In• 文字値については、以下を使用可能
類似(LIKE)大小文字を区別しない類似(LIKEIGNORECASE)類似 In (LIKEIN)連結(+)
• 数値に関しては、以下演算子が使用可能
BETWEEN<>=<>=
<副次式ビルダー画面>
【参考】種別ルールの記述
© 2012 IBM Corporation21
【参考】 ルール条件に使用可能なHTTPオペランド
サーバーのIPアドレス(IPV6)サーバーIPV6
リクエストを受け付けるサーバーのポート番号を設定可能ポート
クライアントのIPアドレス(IPV4)クライアントIPV4
サーバーのFully-qualified client host nameを値に設定可能。演算子にIN,LIKEなど
は使用不可。サーバーホスト
パラメーター名およびその値を設定。またはIS NULL、IS NOT NULLを使ってパラ
メーター自体が存在するかを条件にすることも可能。要求照会パラメーター
Cookie名およびその値を設定。またはIS NULL、IS NOT NULLを使ってCookie自体
が存在するかを条件にすることも可能。
Cookieヘッダー名
値にはGET/PUT/POST/DELETEが設定可能HTTPメソッド
HTTPヘッダー名およびその値を設定。またはIS NULL、IS NOT NULLを使ってヘッ
ダー自体が存在するかを条件にすることも可能。要求ヘッダー名
リクエストのMIMEタイプと値を設定。MIMEタイプ
説明オペランド
HTTP/HTTPS/SOAP/SOAPSが選択可能プロトコル
サーバーのIPアドレス(IPV4)サーバーIPV4
クライアントのIPアドレス(IPV6)クライアントIPV6
クライアントのFully-qualified client host nameを値に設定可能。演算子にIN,LIKEなどは使用不可。
クライアントホスト
© 2012 IBM Corporation22
リクエストの流量制御
~バックエンドの過負荷防止~
© 2012 IBM Corporation23
過負荷防止機能
メモリー過負荷保護– サーバーのヒープ使用率が設定値以上になる場合にリクエストを拒否します
• サーバー・アフィニティを持つ場合は、キューイングされ、拒否はされません
CPU過負荷保護– サーバーのCPU過負荷を検知し、サービス・ポリシー違反が発生する可能性が
ある場合の対応を次の3つのポリシーから設定可能• 要求拒否せず、全てのリクエストをキューイング(デフォルト)• リクエストをキューイングせずに、即時に拒否• 設定した割合を越えるリクエストの応答時間が目標値を超える場合に拒否
– 要求拒否した場合、既定ではHTTPコード503を応答(コードは変更可能)– 過負荷の判断のしきい値となるCPU使用率を設定可能(デフォルトは90%)
© 2012 IBM Corporation24
【参考】 過負荷防止設定
CPU使用率の過負荷条件
CPU過負荷防止のための要求拒否ポリシー:- 要求拒否しない- 即時拒否- 応答時間しきい値設定
メモリー使用率の過負荷条件
[動作ポリシー]-[オートノミック・マネージャー]-[オートノミック要求フロー・マネージャー]
© 2012 IBM Corporation25
ODR カスタム・エラーページ
要求拒否などの場合にエラー・ページへ転送
エラー発生時のエラーページをカスタマイズ– ローカル・エラー・ページ処理: ローカル・ファイルを応答– リモート・エラーページ: エラーページ生成アプリケーションに転送
• エラー・ページ生成アプリケーションは、ODR自身にデプロイすることも可能• エラー・ページ・アプリケーションのサンプル: <WAS_HOME>/installableApps/HttpErrorHandler.ear
カスタム・エラー・ページの構成方法:– [サーバー]-[オンデマンド・ルーター]-[オンデマンド・ルーター名]-[カスタム・エラー・ページ・ポリシー]
© 2012 IBM Corporation26
動的ワークロード管理
~最適な負荷分散~
© 2012 IBM Corporation27
動的ワークロード・マネージャー (DWLM)DWLMコントローラーは、リクエスト割振りのDWLMウェイト値を各ノードのパフォーマンス情報(CPU使用率、スループット、同時リクエスト数など)から動的に計算
DWLMは、コントローラーからの結果に従い、動的にルーティング・テーブルのDWLMウェイト
値を更新
DWLMは、ルーティング・テーブルのDWLMウェイト値に従ってリクエストを各サーバーに割り
振る
オンデマンド・ルーター(ODR)
DWLM
DWLMコントローラーDWLM
ウェイト値
DWLMウェイト値
ルーティング情報
各アプリケーション・サーバーのパフォーマンス情報を取得し、DWLMウェイト値
を計算
© 2012 IBM Corporation28
【参考】 ODR ルーティング情報 (target.xml)
<server name="DCluster01_jupiterNode01">
<transient properties="{server=name=solarConfCCell01/jupiterNode01/DCluste
r01_jupiterNode01: weight=20 (/cellGroup/target/cell/solarConfCCell01/node/jupiterNode01/s
erver/DCluster01_jupiterNode01(com.ibm.ws.xd.dwlm.client.XDTargetServerImpl@4be04be0))}"/>
<property name="id" value="12e9dksi7"/>
<property name="type" value="APPLICATION_SERVER"/>
<property name="state" value="STARTED"/>
<property name="ODR" value="false"/>
<property name="reachable" value="true"/>
<property name="weight" value="20"/>
<property name="threadPoolMin" value="5"/>
<property name="threadPoolMax" value="20"/>
<property name="threadPoolIsGrowable" value="false"/>
<property name="sessionPersistenceMode" value="DATA_REPLICATION"/>:
サーバーのクローンID
稼動状況
DWLMウェイト値
ODRのルーティング情報はメモリー上に保持され動的に更新される
ODRのトレース設定でディスク上に書き出し可能 ⇒ target.xml– ODRのトレースに次のトレース・ストリングを設定 com.ibm.ws.odc.nd.ODCTreeImpl$Save=all– <ODR_Root>/installedFilters/wlm/<odr_name>/target.xml
© 2012 IBM Corporation29
セッション・リバランス(再平衡化)機能
動的クラスター
サーバー 1
サーバー 2
サーバー 3
サーバー 4
ODR
Cookie: JSESSIONID
= CacheID:Session24:P2:C2
DWLM
Session22Session21
Session24Session23
Session32Session31
Session34Session33
Session42Session41
Session44Session43
Cookie: JSESSIONID
= CacheID:Session24:P2:C1
DWLMはセッション数がDWLMウェイト値と比例するように
リバランスを行う
セッション移動の必要なリクエストのクローンIDを振りなおし
て転送する
特定少数ユーザーが長時間利用するようなシステムにおいて有効
セッション・アフィニティがオンで、かつ、セッション・パーシスタントを使用している場合に使用可能
動的クラスターに関して、デフォルトでオン(カスタムプロパティ HttpSessionRebalanceOffをtrueとすることでオフに設定可能)
© 2012 IBM Corporation30
動的クラスター
~負荷に応じたバックエンド・サーバーの起動/停止~
© 2012 IBM Corporation31
動的クラスター
動的クラスターとは– アプリケーションがデプロイされるサーバーのグループ– クラスター・メンバーが、自動(又は半自動)の稼動・停止の対象になる点が、静的クラスターとの相違点
– サーバーの稼動・停止操作に関するモードとして、手動・監視・自動から選択可能
メンバーシップ・ポリシー– クラスター・メンバーを作成するノードを選択する基準を定義(詳細は後述)– メンバーシップ・ポリシーに合致するノードには、動的クラスター作成時、及び、ノード追加時に、クラスター・メンバー(アプリケーション・サーバー)が自動的に作成
動的クラスター・サーバータイプ– WebSphere Application Server
• WVEが導入された、WAS NDノードによる動的クラスター– PHPなど他ミドルウェアに関しても定義可能
• WebSphere Application Serverに比較した場合、管理レベルは異なる
© 2012 IBM Corporation32
動的クラスターの作成
サーバー>動的クラスター 動的クラスターサーバー・タイプの選択
動的クラスターメンバーを定義
垂直スタッキングを使用することにより1ノードで複数インスタンス起動が可能
© 2012 IBM Corporation33
動的クラスター・メンバーの決定
and,orで複数の条件
を記述可能
ルール・ビルダー
動的クラスター作成ウィザード
動的クラスター・メンバーは、メンバーシップ・ポリシーによって自動で決定– ルール・ビルダーによりメンバーシップ・ポリシーを定義
クラスターメンバーは以下のルールから定義– ノード名、ノード・グループ、ホスト名、ノード・プロパティー
動的クラスター・メンバー作成後のノードの追加/削除– ノードの追加/削除を行うとクラスターメンバーであるアプリケーションサーバーも追加/削除
• 新規ノード追加時に、メンバーシップ・ポリシーに合致する場合、サーバー・インスタンスを作成して動的クラスターに追加
© 2012 IBM Corporation34
動的クラスターの操作モードの設定
手動 :– 静的クラスターのアプリケーション・サーバー環境と同等– アプリケーション配置、およびランタイム・タスクの候補表示はされない– オートノミック要求フロー・マネージャー(ARFM)、動的ワークロード管理(DWLM)とは連動
監視 :– ランタイム・タスクを生成することにより、必要な修正アクションに関する情報が提供される
• 管理コンソールの[システム管理]-[タスク管理]-[ランタイム・タスク]のパネルで、管理者が
オートノミック・マネージャーの推奨を受け入れるか、拒否する
自動 :– WVEは自動的に修正処置を実行
© 2012 IBM Corporation35
アプリケーション配置コントローラー (APC)
オートノミック要求フロー・マネージャー(ARFM)コントローラーの必要リソース情報に従い、アプリケーション・サーバー・インスタンスを動的に起動/停止
ノードの負荷状況(メモリーやCPU負荷など)から、どのインスタンスを起動するかを決定
APC
ARFMコントローラー
リクエストの必要リソース情報
動的クラスターA
動的クラスターB
動的クラスターC
起動
停止起動
© 2012 IBM Corporation36
【参考】アプリケーション配置コントローラー設定
[動作ポリシー]-[オートノミック・マネージャー]-[アプリケーション配置コントローラー]
監視モード時、この時間を過ぎても承認が得られない場合、ランタイム・タスクは期限切れとなる
サーバーの起動(停止)を指示し、この時間を過ぎても起動(停止)しない場合その操作を失敗とみなす
前回のサーバー操作あるいはタイムアウト後、次の操作を開始するまでの待機時間
APC機能を使用(チェック)を外した場合は、全ての動的クラスターは静的クラスターと同等になる
© 2012 IBM Corporation37
動的クラスターのカスタム・プロパティー< numVerticalInstances.node_name>
垂直スタッキング
同一ノードにおいて、動的クラスター・メンバーを複数構成することで、より効率的にノードのリソースを利用できるケースへの対応
– 動的クラスターごとに、垂直スタッキングの許可とインスタンス数を指定– 水平クラスターで限界に達すると垂直クラスターを構成
ノード上の個別設定– 動的クラスター単位の設定のため、異なるスペックのノードが存在する場合は、ノード単位での上書き設定を行う
動的クラスター
STSTASSTAS
© 2012 IBM Corporation38
動的クラスターの分離 (Isolation)
動的クラスターを分離し、他のクラスター・メンバーは同一ノード上で稼動しないよう制限する【利用例】– 社内向けアプリケーションは社外向けアプリケーションと異なるノードで稼動したい– クリティカル・アプリケーションをノードを占有させて稼動したい– Webホスティング・サービスにおいて異なる顧客のアプリケーションは異なるノードで稼動
したい
設定方法[サーバー]-[動的クラスター]-[動的クラスター名]の「分離設定」– 厳密な分離: 他の動的クラスターのクラスター・メンバーとは同じノードでクラスター・メン
バーを稼動しない– 分離グループ: 異なる分離グループの動的クラスターのインスタンスは同じノードで稼動し
ない
アプリケーション分離ポリシー:- 分離なし(デフォルト)- 厳密な分離- 分離グループ
分離グループの場合、既存の分離グループのリストから選択可能
© 2012 IBM Corporation39
動的クラスターの分離
ノード 1
ノード 2
ノード 3
ノード 4
ノード 5
ノード 6
動的クラスターB
(分離なし)
動的クラスターC
(厳密な分離)
動的クラスターD
(分離グループ)
動的クラスターE
(分離グループ)
動的クラスターA
(分離なし)
分離グループ 1
© 2012 IBM Corporation40
時間指定によるサーバ停止準備とリクエストによる自動スタートの仕組み–管理コンソールの動的クラスターの設定
–待機時間を経過し、別の動的クラスターでリソースが必要になった時点で全クラスター・メンバーを停止
• クラスター・メンバーを個別停止するより、効率的にリソースを解放• カスタム・プロパティー(proactiveIdleStop)を設定することで、リソース要求の有無に関わら
ず待機時間経過後停止することも可能
–停止時にリクエストを受けた場合に、少なくとも1つのクラスター・メンバーを開始• サーバーが開始するまでに受信したリクエストに対してはHTTPコード503を応答
アプリケーションの遅延(lazy)スタート
© 2012 IBM Corporation41
ODRの動的クラスター
ODRの動的クラスターが構成可能になり、より自律的な管理が可能に– これまで
• ODRクラスターは静的クラスター構成のみ可能であり、管理者が起動・停止のオペレーショ
ンを実施– V7から
• ODRの動的クラスター構成が可能• 最低稼動数をポリシーとして設定することで、自動的に最低稼動数を維持するようにODRを自動で起動させることが可能
Newv7
© 2012 IBM Corporation42
高可用性環境でのプラグイン構成の自動生成
各ODRは、プラグイン構成ファイルに変更があった場合(ルーティング情報に変更があった場合)、プラグイン構成ファイルを自動生成
常に、セル内の稼動している1つのJVMプロセスで、プラグイン構成ファイルの生成を行う– 生成時に実行するスクリプトを指定することで、リモートのWebサーバーへの伝搬も可能
設定: 下記のような一連のカスタム・プロパティーをセルレベルで設定– ODCPluginCfgOdrList_1 = myCell:*:*– ODCPluginCfgOutputPath_1 = /tmp/plugin-cfg1.xml– ODCPluginCfgUpdateScript_1 = /root/bin/pluginCfgUpdate1
ただし、起動していないODRは、プラグイン構成を生成できない
←出力に含めるODRをセル:ノード:ODRサーバーの形式で指定
[ランタイム操作]-[拡張デプロイメント]-[コア・コンポーネント]の「HAPluginCfgGenerator」の項目で、サービスの稼動しているJVMを確認可能
© 2012 IBM Corporation43
Elasticity (伸縮性) モード
アプリケーション配置コントローラー(APC)による起動/停止の対象が、JVMのみから、ノードの単位
まで拡張– 特定の動的クラスターがサービス・ポリシーを満たしていないことをAPCが認識し、 かつ使用可能なすべてのサーバーが開始済みである場合に、Elasticity モードを使用して、ノードを追加
するようにロジックを追加できる– APCが、サービス・ポリシーの目標を満たしながら、 使用されるノード数を最小にし、不要な
ノードを削除するロジックを追加できる
Newv7
追加プロパティーでアクションのスクリプトを指定
IWDのIMP (Intelligent Management Pack) において、使用されている
© 2012 IBM Corporation44
まとめ
© 2012 IBM Corporation45
優先度制御と動的クラスターの連携
国内顧客管理
国内顧客管理
国内顧客管理
サーバー#1
サーバー#2
サーバー#3
国内顧客管理クラスター
①ODR(ARFM)は、バックエンド・サーバーの負荷と、リクエスト毎のバックエンド・サーバーへの負荷の影響をモニタリングし、高負荷の予兆を検知
コールセンター
海外一般ユーザー
リクエストの増加傾向を検知し、クラスター・メンバーを増減、一時的なピーク時にも、キューイングして、優先度の高いリクエストを優先
待機社内一般ユーザー(特定の顧客処理)
高
優先度
中
中
高
中
中海外
顧客管理
海外顧客管理クラスター
サーバー#4
海外顧客管理
100%
0%50
%
CPU
100%
0%50
%
CPU
100%
0%50
%
CPU
100%
0%50
%
CPU
②追加のクラスター・メンバーが起動するまで、ARFMは優先度の低いリクエストをキューイングし、優先度の高いリクエストを優先的に処理
②APCは、処理の少ないクラスターのメンバーを停止し、処理の多いクラスター・メンバーを起動
ODRODR
© 2012 IBM Corporation46
参考資料
WVE V7 Information Center– http://pic.dhe.ibm.com/infocenter/wveinfo/v7r0/index.jsp
WebSphere Virtual Enterprise Wiki - Japan– https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/Web
Sphere%20Virtual%20Enterprise%20Wiki%20-%20Japan
DeveloperWorks-Japan「WebSphere Virtual Enterprise」– http://www.ibm.com/developerworks/jp/websphere/category/wxd/wve.html
© 2012 IBM Corporation47
•無断転載・転記・転写を禁ず•IBMおよびIBMロゴは、International Business Machines Corporationの米国およびその他の国における商標です
•他の会社名、製品名およびサービス名等はそれぞれ各社の商標です
•ありがとうございました。
47