Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP-UX   >  Knowledge-on-Demand

仮想化のその先に〜コスト削減と可用性を求めて〜

HP-UX 11i Knowledge-on-Demand 特別企画
HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
仮想化のその先に〜コスト削減と可用性を求めて〜

TiCAP+vParを使ったHAシステムの検証

検証したシステムは、1台の稼働サーバに2つのvParが設定され、待機サーバにも2つのvParが設定されている。稼働サーバの1つのvParが停止、Serviceguardによって待機サーバのvParにフェイルオーバーさせ、その時間などをテストした。待機サーバのvParは、通常時は最小のリソースでホットスタンバイした状態にあり、フェイルオーバーと同時にTiCAPを使ってCPUを追加する。
仮想化のその先に〜コスト削減と可用性を求めて〜
進化するHP-UX、仮想化のその先に
TiCAP+vParを使ったHAシステムの検証

まず、Serviceguard Extension for Faster Failover(SGeFF)を用いた場合と、用いない場合を比較した結果を示そう。ご存じの読者が多いと思うが、SGeFFは高速なフェイルオーバーを実現するオプションで、先の松のようなシステムであれば数秒にまでフェイルオーバーを短縮することができる。

検証したシステム
図2:検証したシステム

表2:SGeFFを有効にした場合と無効にした場合の検証結果
FO時間[s]
1回目 2回目 3回目 平均
SGeFF有効 23 23 22 23
SGeFF無効 47 45 46 46

結果が示すように、SGeFFにより約23秒の短縮が可能になっている。竹システムでもSGeFFは有効であることがわかるだろう。では、この23秒のうちCPUの増加には、どの程度の時間がかかるのだろうか。

表3:CPUを増加させた場合の速度計測結果
  CPUコア数 Memory容量[MB] コマンド実行時間[s]
FO前 FO後 1回目 2回目 3回目 平均
CPUの増加 1 4 4096 2.45 2.33 2.24 2.34
CPUの増加 1 8 4096 2.46 2.46 2.27 2.40
CPUの増加 1 12 4096 4.04 3.45 3.38 3.62
CPUの増加 1 15 4096 4.35 4.36 4.27 4.33
CPUの増加 1 4 11264 2.31 2.30 2.29 2.30
CPUの増加 1 8 11264 2.47 2.50 2.35 2.44
CPUの増加 1 12 11264 3.59 3.44 3.47 3.50
CPUの増加 1 15 11264 4.83 4.51 4.16 4.50

結果は上の通り。CPUの追加はCPU数が増えるほど時間がかかるものの、数秒程度におさまっている。CPUがサーバのCellをまたぐような場合、かかる時間はやや増加するが、それでも数秒以内で終了する。

最後に、vParにメモリを追加する例を掲載しておこう。以前のvParではCPUのみ動的な追加・削除が可能だったが、最新のvPar 5.0ではメモリの動的な追加・削除が可能になっている。これにより、待機系のvParの柔軟な運用が可能になる。

表4:vParによるメモリ追加時の計測結果
  CPUコア数 Memory容量[MB] コマンド実行時間[s]
FO前 FO後 FO前 FO後 1回目 2回目 3回目 平均
メモリの増加 1 - 4096 6144 2.61 2.25 2.30 2.39
メモリの増加 1 - 4096 11264 3.74 3.98 4.03 3.92
メモリの増加 15 - 4096 6144 1.50 1.37 1.36 1.41
メモリの増加 15 - 4096 11264 2.54 2.52 2.56 2.54

vPar 5.0を用いて仮想環境のメモリを動的に増加させた結果は上の通りだ。追加するメモリの容量が大きいほど時間がかかるが、それでも数秒以内に終了する。メモリに関しては増加させればOSが自動的に使用するので、CPUのような再配分も必要はない。

ただし、メモリの削除にはケースバイケースで時間がかかることに注意が必要だろう。メモリを削除してもすぐにはメモリの返却は行われず、プロセスが終了するなどしてメモリをOSに返したタイミングでメモリが削減されていくためだ。

要求される可用性とのバランスが重要

以上、TiCAP+vParを用いた簡易クラスタの検証例を紹介した。正道のServiceguardクラスタに比べればフェイルオーバーに時間がかかるのはやむをえないが、検証例で見た程度の遅延が許容できるシステムであれば魅力的な選択肢になるだろう。TiCAPは30日単位のプリペイドとなっており、障害発生時のみ稼働する待機系で利用するのであればプリペイドを使い切るという心配はほとんどないはずだ。TiCAP+vParを用いたHAクラスタはすでにいくつかの企業に導入されており、実績も十分にある。

ただし、迅速なフェイルオーバーが要求されるHAシステムには適しているとは言えないのも、また確かなことだ。システムに要求されている可用性のレベルとの兼ね合いが重要だろう。コストと可用性のバランスを十分に考えて検討する必要がある。

今回のケースは実際に顧客へのシステム提供にあたり、HPの製品技術者と構築技術者が共同で、システムの重要度から求められる可用性とコストを念頭に最適化を行った事例である。HP-UXの仮想化技術により、可用性を保ちながらコストメリットのある柔軟な構成が組める様になったと言える。


トップへ 戻る  

特別企画:バックナンバー

 
HP-UX11i v3 新世代ミッションクリティカルOSへ
第6回:サーバを止めずに増強できるDynamic nParの離れ業
第5回:ソフトウェア・パッチの管理コストを削減する柔軟な管理ツール群
第4回:Oracle環境向け高速化ツール“ODM”で「rawデバイスの悩み」を解消しよう
第3回:次世代大容量ストレージに対応した新I/Oスタック
第2回:仮想パーティションとユーティリティの強化ポイント
第1回:柔軟性、信頼性、管理性を強化したHP-UX11i v3の全貌
 
 
 
 
NECが語る「HP-UXによる高可用システム構築」
 

 その他の連載記事


本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。

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