Jump to content 日本-日本語

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

Virtualization Managerは
「サーバ仮想化のポータル」をめざす・後編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
Virtualization Managerは「サーバ仮想化のポータル」をめざす・後編
Virtualization Managerは「サーバ仮想化のポータル」をめざす・後編
Capacity Advisorによるサーバ仮想化シミュレーション
VSE活用のベストプラクティス

VSE活用のベストプラクティス

つづいて、こうして使いやすくなったVSEを活用するためのベスト・プラクティスをいくつか紹介する。

負荷の予測が難しいときはvParsを使う

多くのサーバでCPUの平均利用率を引き上げられない理由の多くは、負荷の予測が難しいことにある。例えばこれまで1時間に100件程度の処理を扱ってきたサービスに対し、広報活動などにより、今後は最大で1000件の処理が集中するとマーケティング部門が予測したとしよう。そうしたビジネス・レベルの予測は往々にして外れるとわかっていても、IT部門としては1000件の処理に耐えるリソースを事前に配分せざるを得ない。こうして、いわゆるオーバー・プロビジョニング(過剰配分)が生じてしまう。

vParsは、こうした悩みの解決に最適なソリューションだ。vParsを使えばリアルタイムにCPUリソースを増強できるため、実際の負荷を処理するに十分なだけのリソースを配分しておけばよい。余ったリソースは開発環境やテスト環境、もしくは他のサービスに割り当てできる。これにより、負荷の予測が難しいビジネスであっても、オーバー・プロビジョニングの問題を回避可能だ。

サーバの代わりにvParsを購入する

ミッドレンジのHP Integrityサーバを必要とする2つのアプリケーションがあるとき、2台のサーバを購入してそれぞれにアプリケーションを占有させるケースが一般的だ。しかし、それぞれのサーバをフル構成で導入することはめったにないだろう。2台とも拡張性に余裕を残したまま運用されることになる。

こうしたケースでは、vParsにより2つのアプリケーションを1台にコンソリデーションすることも可能だ。個々のアプリケーションにぴったりフィットするCPUパワーを配分できるほか、データセンターのハウジングコストや電源容量も1/2に抑えられる。なにより、HP Integrityサーバ2台分の運用コストより、1台分+vParsライセンス方で運用した方が格段に安くつくのである。

負荷ピーク時のすばやい対応にはgWLMを使う

vParsではCPUリソースの配分をリアルタイムに変更できるものの、そのためには管理者によるコマンド操作が必要だ。しかし管理者はサーバに常時張り付いているわけにはいかない。よって現実的には、数日〜数10日単位の負荷変動への対応が限度だろう。

しかしgWLMを使えば、管理者の手を借りずに、負荷状況に応じてリアルタイムにCPUリソースの割り当てを自動変更できる。したがって、負荷ピーク時にすばやい対応が必要なアプリケーションについては、gWLMの導入によって大きな効果が得られる。

gWLMを利用する際には、各vParsのアプリケーション用途に応じて適切なポリシーを選択することが肝要となる。例えばパフォーマンスを一定に維持する必要のあるプロダクション環境については、最低限のCPUリソースを保証する設定が不可欠だ。一方、開発やテスト環境については、プロダクション環境の負荷に余裕があるときのみCPUを借り受けるような設定にしておく。

アプリとDB間でCPUリソースを共有する

OLTPを扱うアプリケーション・サーバと、そのOLTPおよびバッチ処理を扱うデータベース・サーバからなる典型的なn階層システムでは、アプリケーション・サーバとデータベース・サーバのそれぞれをvParsで収容し、1台のHP IntegrityサーバのCPUリソースを共有させる構成が推奨される。これにより、OLTP負荷が高い日中にはアプリケーション・サーバにCPUを多く割り当て、バッチ負荷が高くなる夜間にはデータベースにCPUを配分するといったリソース共有が可能になる。とりわけ、SAPなどのERPアプリケーションではこうした使い方がマッチするはずだ。もちろん、こうした頻繁なCPU配分変更にはgWLMの利用が適している。
 
図5:アプリとDB間のCPU共有
図4:アプリとDB間のCPU共有

HAクラスタでiCAPを活用する

iCAP(インスタント・キャパシティ) とは、未購入のCPUをあらかじめHP Integrityサーバに搭載しておくサービスである。負荷上昇やトラブル発生などでCPU追加が必要になったときに瞬時にCPUリソースを増強できる一方で、必要になるまではCPUのコストを支払わなくてもよいというメリットがある。

このiCAPは、HP Serviceguardによる高可用性クラスタ(HAクラスタ)構成と組み合わせることでコスト削減に役立てることができる。図5は、ある顧客におけるiCAPの導入例である。
 
図6:iCAP導入例
図5:iCAP導入例
  この構成で注目していただきたいのは、2台のrx8640のうち「A」の方にはiCAPのCPUが4個搭載されている点だ。ここで、「B」のvPar上で動作するプロダクション環境がダウンすると、HP Serviceguardのフェイルオーバーが発生し、「A」のスタンバイ環境が起動することになる。しかし、同環境のvParには2 CPUしか割り当てられておらず、もともと10 CPU分を消費していた負荷の肩代わりは難しい。

こうしたとき、iCAPによるCPU増強が威力を発揮する。iCAP分としてあらかじめ装着されていた4 CPU分を追加し、さらに開発環境の3 CPU分も合わせて移動することで、合計で9 CPU分を瞬時に確保することができる。このように、HAクラスタの構成にiCAPを導入することで、スタンバイ側の設備コストを最小限に抑えることが可能になる。

以上、今回はVirtualization ManagerによるVSE統合管理について説明した。ここまで見てきたとおり、Virtualization Managerという統合管理ツールを得たことで、VSEのポートフォリオの豊富さが一段と魅力を増したことがご理解いただけるだろう。

VSE管理ツールを始めとする主要コンポーネントは VSE Suite として提供されている。また、HP-UXの環境さえあれば、これらを無償で試すことができる。

トライアル版ダウンロードはこちら
トップへ 戻る    


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

 
 

本ページの内容は執筆時の情報に基づいており、異なる場合があります。
印刷用画面へ
プライバシー ご利用条件・免責事項