Jump to content 日本-日本語
日本HPホーム 製品 & サービス サポート & ドライバー ソリューション ご購入方法
≫  お問い合わせ

製品とサービス  >  ソフトウェアとOS  >  HP-UX   >  Knowledge-on-Demand

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

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

「基幹業務向けの信頼性のあるUNIX」を追求し続けたHP-UX の25年。Serviceguardという強力なHAシステムを擁することがHP-UXの大きな強みであることは、今さら言うまでもないだろう。最新のHP-UX 11i v3にはHAシステムの構築を支援するさまざまなソリューションが用意されており、可用性とコスト削減の両立を実現している。今後、HP-UXがどこに向かおうとしているのか、今回はHP内部で行われたテストの結果などをも交えつつ、コストを抑えたHAシステムを探ることにしたい。
仮想化のその先に〜コスト削減と可用性を求めて〜
進化するHP-UX、仮想化のその先に
TiCAP+vParを使ったHAシステムの検証
2008年12月
テクニカルライター 米田 聡

進化するHP-UX、仮想化のその先に

今年9月にIntegrity Virtual Machineバージョン4.0 (以下、Integrity VM)がリリースされたのは以前の特集でお知らせした通り。ホストOSとしてHP-UX 11i v3がサポートされ、Integrityの可用性や拡張性を最大限に生かし、HP-UXの仮想は着実な進化を遂げている。また、2010年にはHP-UXの次のメジャーバージョンであるHP-UX 11i v4の投入も予定されており、可用性と仮想化の融合のさらなる進化が待っている。

そもそもHPの目指す可用性と仮想化の融合とは何なのだろうか。また、現在HP-UXはどこまで進化しているのだろうか。

HP-UX 11iソフトウェア ロードマップ
図1:HP-UX 11iソフトウェア ロードマップ

コスト削減と可用性の両立とは

HAシステムと一口に言っても、要求される信頼性の程度はシステムによって異なる。わずかな間のサービス停止も社業の命運に関わるシステムであれば十分なコストをかけた堅牢なHAシステムが求められるだろう。だが、すべてのシステムにそこまでの信頼性が必要かと言えば、そうではないのも確かだ。たとえば、2基のサーバを運用しているとしよう。待機系にも2基のサーバを用意すれば万全ではある。だが、ハードウェアやOSの信頼性が向上により、2基のサーバが同時に障害を発生させることは極めて稀になってきた。となれば、待機系には仮想化技術を用いて2台分のバックアップを1台のサーバでまかなうという方法も、選択肢として候補に挙がってくる。ここに、コスト削減と可用性の両立への解答がある。

HP-UXでは、他のOSと異なる特長のひとつ、Firmwareを用いたソフトウェアレベルのパーティショニング技術vParが利用できる。vPar間ではCPUリソースの(また後にふれるが、最新バージョンではメモリリソースも)柔軟な再配分が可能だ。仮に2台のサーバに障害が生じるという万が一の事態が発生しても、vParを用いればサービス品質の低下を最小限に抑えながらサービスの継続が可能になる。さらに、プリペイド制によるCPUの拡張サービスTiCAPを組み合わせれば、さらなるコスト抑制が可能だ。待機系のCPUを最小限に抑えておき、障害発生時にはTiCAPのCPUを使うことで待機系にかかるコストを抑えると同時に、サービス品質の低下も抑えられるわけだ。

このように、HPの柔軟なソリューションを活用することでコストを抑えたHAシステムの構築が可能だが、もちろん万全なHAシステムに比較すればデメリットも生じうる。システムを構築する際にしっかりと押えておかなければならないのは、コストを抑えたことと引き替えに生じるデメリットが許容できる範囲であるかどうかだろう。以降で、この点にさらに踏み込んで検討していくことにしたい。

待機系にvPar+TiCAPを活用する

まず、HAシステムを一般的に検討されるシステム構成に、更にHPの仮想化技術を取り入れ、3つのソリューションパターンに分けてそのメリットとデメリットを考えてみた。

表1:コスト順に3段階で分けたHPのソリューション
ソリューション メリット デメリット
Active-Standby間で同じリソースを用意する従来型のSGクラスタ
  • フェイルオーバー時にリソースの変更処理が入らないので、安定した迅速なフェイルオーバーが可能
  • 通常運用時稼動しない余分なリソースを用意する必要がある

(今回の
検証)
TiCAP+vParを使用し、Active-Standby間で通常稼動時のリソースが異なるSGクラスタ
  • 通常運用時に稼動しない余分なリソースが比較的少なくてすむ
  • オンラインでのリソース追加によってフェイルオーバー時にはActiveと同等のリソースを確保できる
  • フェイルオーバー時にリソース追加処理を行なうことでフェイルオーバー速度が遅くなる懸念点がある(検証項目)
SAN Boot 構成を使用し、サーバの障害時に複数のActiveに対して1台以上のCold Standbyのサーバを用意するN+1構成
  • 通常運用時に稼動しないリソースが最小限ですむ
  • Cold Standbyであるのでフェイルオーバーに時間がかかる
  • 同時障害に耐えられない可能性がある

最上位の「松」は、待機系にも稼働しているサーバと同じリソースを持たせるという、Serviceguardを用いたHAクラスタの基本的な構成だ。障害発生時にはアクティブな状態を維持する待機系へと迅速にフェイルオーバーが可能であり、また同じリソースを持つ待機系によりサービス品質の低下も発生しない。

一方、もっともコストを抑えた構成である「梅」は、SAN Bootを使って1台のサーバをコールドな状態で待機させておく、というもの。障害発生時にはコールド状態からブートさせ、フェイルオーバーを行うわけだ。待機サーバを1台に押え、コールドスタンバイさせればコストは最小にすむ。ただしフェイルオーバーには時間がかかり、サービスは一時的に停止するだろう。また、待機サーバが1台しかなければ複数のサーバに同時に障害が起こったときに対応できない可能性が高い。停止することが許されないようなサービスには利用しづらいだろう。

「竹」は、松と梅との間を取ったHAシステムだ。待機系は稼働しているサーバよりもリソースを抑えた構成にし、ホットスタンバイさせておく。また、前節でふれたようにvPar+TiCAPを使う前提で通常は最小のCPUで稼働させる。障害が発生したら待機系にフェイルオーバーすると同時に、TiCAPを使ってvParにリソースを追加、稼働しているサーバと同じ程度のリソースを与えることでサービスを継続する、というものだ。待機系にかかるコストが、うまく構築すれば梅+α程度ですみ、なおかつ障害発生時にもサービスの品質の低下は抑えられるということで魅力的な選択肢だろう。

もちろん懸念すべきことはある。フェイルオーバーの速度が松に比べてどの程度、遅くなるのか、という点だ。最小のCPUに抑えている状態から、フェイルオーバーと同時にTiCAPを用いて増加させるのだから、松に比べればフェイルオーバーに時間がかかるはずである。そこで後半では、実際の検証結果をお目にかけることにしたい。なお、この検証はHPが実際に顧客へシステム構築を行うにあたって、製品部隊の技術者と構築部隊の技術者が、顧客のシステムを想定して行ったフィジビリティスタディの一部となっている。

トップへ     次のページへ

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

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

ショールーム

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

印刷用画面へ
プライバシー ご利用条件・免責事項 ウェブマスターに連絡