Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP- UX Developer Edge

「サーバ仮想化によるスケールアウト」の新潮流・後編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
「サーバ仮想化によるスケールアウト」の新潮流・後編
「サーバ仮想化によるスケールアウト」の新潮流・後編
リソース・パーティションを実現するpsetとPRM
vPar・pset・PRMを操るSLO管理ツールWLM

vPars・pset・PRMを操るSLO管理ツールWLM


さて、これまで取り上げてきたvParsやpset、PRMでは、いずれも管理者のマニュアル操作によってパーティション構成を指定する必要がある。もちろん、これだけでも「物理的なサーバ」に比べれば柔軟性は格段に高いといえるが、たとえば昼休みのWebアクセス集中や夜間のバッチ処理など、日々の負荷変動のたびにマニュアル操作で構成変更するのは現実的ではない。そこでHPでは、vParsとpset、PRMの構成変更を自動化するツールWorkLoad Manager(WLM)を有償ソフトウェアとして提供している。

WLMのユニークな点は、それがサービスレベル目標(SLO)に基づいて動作することだ。WLMでは、アプリケーションのレスポンス時間やスループットなどの「サービスレベル」をリアルタイムに計測する。そして、負荷の変動に応じて一定のサービスレベルを維持するため、PRMにプロセッサー・リソースの割り当て変更を指示するという役割を担うのである。

図4は、WLMの動作メカニズムを図示したものだ。

図4:WLMの動作メカニズム
図4:WLMの動作メカニズム

図4が示すように、WLMでは、Data Collectorと呼ばれるコンポーネントを通じて、アプリケーションのサービスレベルをリアルタイムに計測する。具体的には、以下の種類のData Collectorが用意されている。

Data Collectorおよびツールキットの種類 サービスレベル取得の対象
Glance HP-UXのリソースモニタツールGlanceの計測結果
Apache TK Apache Webサーバ
ODBTK Oracleデータベース
SASTK SASソフトウェア
SNMPTK SNMP対応デバイス/ソフトウェア
WebLogicTK WebLogicアプリケーション・サーバ
ライブラリAPI 任意のアプリケーション
EMS Monitor HP EMS(イベント管理ソフトウェア)
標準出力 シェルスクリプトやPerlなどによる標準出力

このようにWLMでは、ほぼあらゆる種類のアプリケーションのサービスレベルを、Data Collectorにて計測することができる。これらのデータを受け取ったWLMのControllerは、あらかじめ用意されたSLO設定と比較し、個々のアプリケーション・グループが必要とするプロセッサー・リソースを算出する。

WLMのSLO設定では、アプリケーション・グループごとに、それぞれの優先度やプロセッサー使用権を定義できる。加えて、SLO設定を適用する期間や時間帯、プロセスの状態といった条件指定が可能だ。たとえば、「毎月20〜25日の間だけ月末処理用アプリケーションにリソースを確保する」、「バックアップ処理プロセスの起動中のみリソースを確保する」、「HAクラスタのフェイルオーバー時のみリソースを確保する」といった使い方ができる。

Controllerからのリクエストは、WLMのArbiterに集約される。Arbiterは、各グループに割り当てるプロセッサー・リソース配分を決定し、それに基づいてPRMの設定をリアルタイムに調節する。また、PRMだけでは負荷上昇に対応しきれない状況では、vParの構成変更によって対処する仕組みになっている。すなわち、各vParのWLMが互いに連携し、vPar間でリアルタイムにプロセッサーを融通し合うのだ。これにより、サーバの動作中にプロセッサーを挿したり抜いたりするような運用が、現実に可能になるのである。


WLMによるリソース管理の例


では、WLMによるリアルタイムのリソース管理とは実際にどのようなものなのか、具体例を紹介しよう。ここでは、FinanceとSales、Bachという3つのアプリケーション・グループを想定し、それぞれに一定のSLO目標を設定した場合のWLMの動作を見てみたい。

図5:Financeグループの負荷とレスポンス
図5:Financeグループの負荷とレスポンス

図5は、Financeグループの負荷とレスポンスの推移を表したグラフだ。同図において、赤色はFinaceグループの負荷、水色はSLO目標、そして黄色はレスポンス時間を表している。図5を見ると、負荷の急激に上昇した時点で、レスポンスがSLO目標を一時的にオーバーしているものの、やがてSLO目標を満たす状態に落ち着いているのがわかる。ここで、プロセッサー・リソースの割り当てがどのように変化しているのかに注目しよう。

図6:プロセッサー割り当ての変化
図6:プロセッサー割り当ての変化

図6において、Financeグループに割り当てられたプロセッサー・リソースの大きさは黄色のグラフで示されている。このように、FinanceグループのSLO目標をオーバーした直後から段階的に割り当てが大きくなり、やがて一定のレベルに収束する。

このように、WLMを用いることで、サービスレベルというエンドユーザーに近い指標に基づいて、リソースの動的な配分を自動的にコントロールすることができる。また一連の調整プロセスに際して、他のグループが大きく影響を受けることもない。これらのメリットは、まさしく「論理的なサーバ」によってのみ得られるメリットと言えるだろう。


National Semiconductorの事例


以上のようなサーバ仮想化は、すでに国内外で導入され始めており、システム構築で要求される仕様となっている。そうしたサーバ仮想化の導入事例の1つとして、ここでは米国National Semiconductor(以下、NS)のケースを紹介したい。

NSでは、5台のSAPサーバについて、それぞれを物理的に独立したマシンで運用するスケールアウト構成を採用していた。しかし同社では、あるサーバが過負荷の状態となる場合でも他のサーバは空き状態のままというアンバランスさに悩まされていた。また、SAPの機能拡張にともないサーバの負荷が上昇した際にも、柔軟な負荷分散が行えない状態であった。

こうした状況で同社が選んだのは、5台のサーバを仮想化技術を利用した2台のHP rp8400サーバにリプレースするという「サーバ統合」である。2台のHP rp8400サーバでは、それぞれに3つのvParを設定し、合計で6つのSAPサーバとして運用する構成とした。うち2つはプロダクション用で、残る4つはテスト用である。ここでWLMを導入し、プロダクション用SAPサーバのプロセッサー利用率が80%を超えた場合、テスト用SAPサーバのプロセッサーを自動的に借用する設定とした。これにより、NSでは、5台のサーバを運用管理するコストを削減できただけでなく、リソースの共有によって負荷の不均衡の悩みを解消することができたという。

以上、サーバ仮想化による仮想スケールアウトに注目し、それを支えるパーティショニング技術のメカニズムを解説した。もちろん、通常のスケールアウトにするか仮想スケールアウトとするかは、導入時のシステム構成・コスト、運用コスト、将来的なシステム構成・コストに留意して選択する必要がある。 仮想スケールアウトがさらに浸透すれば、ITエンジニアはやがて「形のないサーバ」だけを扱うようになり、データセンターに出向く機会は皆無となるかもしれない。

関連リンク

 
HP-UX WorkLoad Manager (WLM)
HP-UX Processor Sets (pset)
National Semiconductor 導入事例 (US)
 
トップへ 戻る  


記事の内容に関するご意見・ご質問・お問い合わせ

  日本ITフォーラムにて承っております(別途、会員登録が必要です)。

日本ITフォーラム
 

その他のコラム(特集)もお読み下さい

 
 
印刷用画面へ
プライバシー ご利用条件・免責事項