Jump to content 日本-日本語
≫  お問い合わせ

製品とサービス  >  ソフトウェアとOS  >  HP- UX Developer Edge

gWLMが描く仮想データセンターの理想像・後編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
サーバを増やす「打ち出の小づち」──vParsを使いこなす
gWLMが描く仮想データセンターの理想像・後編
gWLMによるプロビジョニングの実際
ポリシーはどのようなメカニズムで働くか

ポリシーはどのようなメカニズムで働くか


では、gWLMのポリシーはどのようなメカニズムで働くのか、もう少し詳しく見ていこう。図5は、ポリシーを新規登録する例である。

  図5:ポリシーの新規登録
図5:ポリシーの新規登録
 

この画面が示すように、ポリシー・タイプ(Policy Type)を以下の3種類から選択できる。

  • Fixed
  • Utilization
  • OwnBorrow

「Fixed」とは、ワークロードに割り当てるCPUリソースを固定する設定である。ワークロードを収容するコンテナがvParsおよびpsetであれば「CPUの個数」を指定し、FSSグループであれば「CPU使用率」を指定する。ポリシー・タイプがFixedの場合、gWLMは動的な自動配分を実施せず、決められたCPUリソースをワークロードに常時占有させるという動作になる。

次の「Utilization」とは、ワークロードのCPU使用率を一定範囲内に保つようにCPUリソースを自動配分する設定である。たとえばワークロードFinanceに「最大CPU使用率=80%、最小CPU使用率=50%」と指定したケースを考えよう。ワークロードFinanceの負荷が上昇し、CPU使用率が80%を超えると、gWLMは同ワークロードへのCPU割り当てを1個増やす。逆に50%を下回れば、CPU割り当てを1個減らす。こうした調節によって、最適なCPU利用効率を維持するわけである。

3つめの「OwnBorrow」は、個々のワークロードが“所有”するCPUリソース(Owned CPU)を明示できるポリシー・タイプだ。図5の例では、以下の内容でOwnBorrowタイプのポリシーを定義している。

  • 最小CPU数:1
  • Owned CPU数:4
  • 最大CPU数:6

Owned CPU数とは、ワークロードが高負荷状態のときに「最低限保証するCPU数」である。つまり上記例では、少なくとも4個のCPUを占有させ、他のワークロードの負荷に余裕があれば最大6個まで割り当てるという動作になる。一方、ワークロードの負荷が低くければ、CPU数を1個まで減らし、高負荷状態の他のワークロードに“貸し出す”。つまりSRD全体に余裕があるときはCPUを柔軟に融通し合いつつ、SRD全体が高負荷のときでも一定のパフォーマンスを保証できる仕組みだ。

なおgWLMでは、FixedとUtilization、OwnBorrowの3種類の他にも、Customと呼ばれるポリシー・タイプも用意している。この場合、ユーザがgwlmsendコマンドを通じてgWLMに通知する任意の計測データをもとに自動配分を実施する。よって、作り込みさえ行えば、Webサーバやデータベースのレスポンス時間といったサービス・レベルに基づくCPUリソース管理も可能だ。


ワークロード管理の実例


では、gWLMによるワークロード管理の実際の例を見ていこう。前編で説明したように、gWLMはリアルタイム監視機能を備えており、ワークロード状況をGUI上でグラフ表示することができる。

図6:gWLMのリアルタイム監視グラフ
図6:gWLMのリアルタイム監視グラフ
  ここで、上述のFinanceワークロードに設定したOwnBorrowタイプのポリシーの動作例をグラフ表示で見てみよう。
  図7:負荷上昇に応じてCPU数が増加
図7:負荷上昇に応じてCPU数が増加
  図7で注目していただきたい点は、青線が示すCPU使用率(右側目盛)と、黄線が示すCPU数(左側目盛)の変化である。CPU使用率が100%に近づくたびに、CPU数が1個から2個、2個から4個へと増加しているのがわかる。CPU数が増えた後は、CPU使用率は80%程度に落ち着いている。ちなみに水色の線は、CPU使用率をCPU数ベースで表したものだ。

一方、ワークロードのCPU使用率が減少すると、gWLMは割り当てるCPU数を段階的に減らしていく。

  図8:負荷低下に応じてCPU数が減少
図8:負荷低下に応じてCPU数が減少
  以上、後編ではgWLMによるプロビジョニングと運用の具体例を紹介した。

ちなみにHPが以前より提供しているWLM(Workload Manager)とgWLMの異なる点は、前者が部門レベルのワークロード管理に特化しているのに対し、後者はデータセンター規模のプロビジョニングや運用管理を支援することを念頭に設計されていることだ。たとえばWLMでは管理対象サーバごとに個別の設定作業が不可欠であるのに対し、gWLMでは多数のサーバへのポリシー配信をGUI操作で実施できる。一方、WLMにはデータベースやWebサーバなどのサービス・レベルに基づくワークロード管理をはじめ、iCAP(Instant Capacity)およびTiCAP(Temporary iCAP)のサポートなど、gWLMにはない特徴がある。
2005年1月よりブランド名が「iCOD」から「iCAP:(instant Capacity)」に変更となりました。

いまや「手の届くソリューション」になりつつある仮想データセンター構築。ユーザを唸らせるすばやい対応と低コストを実現するための強力な武器になるはずだ。

関連リンク

 
HP Global Workload Manager デモ USサイト
HP Global Workload Manager ダウンロード USサイト
HP Global Workload Manager その他の技術資料 USサイト
 
トップへ 戻る    

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

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

日本ITフォーラム
 

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

 
 

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