|
|
 |
|
| 一般的な仮想化技術の「弱点」は、とりわけディスクI/O処理について物理サーバーの能力をフルに引き出せないケースが多いという点。しかし、そうした仮想化技術の“常識”を打ち破るのが、ミッドレンジおよびハイエンドのHP Integrityサーバーに備わる仮想化技術「Virtual Partitions（vPars）」だ。vParsではCPUやメモリ、I/Oリソースは各仮想パーティションに排他的に割り当てられる。そのため、vParsの各仮想パーティション（vPar）上で動くOSは自分に割り当てられたハードウェアリソースを独占して使うことができ、物理サーバーとほぼ同等のパフォーマンスを発揮できる。本稿では、日本HPによる実地検証を通じて、vPars＋Oracleのポテンシャルを明らかにする。 |
|
|
|
|
|
仮想化の“常識”を覆す、
vPars＋Oracleのポテンシャル |
|
|
|
|
|
| 2009年7月 |
| テクニカルライター 吉川 和巳 |
|
|
今回の検証では、以下の構成のハードウェア環境が用意された。
| ●検証サーバー |
- HP Integrity サーバー rx8640（2セル）
|
| ●ソフトウェア |
- HP-UX 11.31 (0809) VSE-OE
- vPars A.05.01
- Oracle Database 11g R1 Enterprise EditionまたはOracle Database 10g R2 Enterprise Edition
|
|
この検証環境として用意されたHP Integrityサーバーrx8640には、セルボード（マザーボード）が2枚装着されており、それぞれに8コア（4プロセッサー）のCPUおよび16GBのメモリが搭載されている。これらのサーバーリソースをvParsの2つのvParに配分し、それぞれのvParで異なるOracleインスタンスを稼働させる構成だ。
なお、Oracleインスタンス稼働中にCPUやメモリの構成変更を行う場合は、OiSCのKROWN 134239 や KROWN 133950 も参考にして頂きたい。 |
|
|
まずは、CPU負荷の高いバッチ処理に対して、vPar間でCPU移動を実施した場合の効果を見てみよう。
|
| このグラフでは、水色が「CPU移動なし」時のCPU使用率、そして茶色が「CPU移動あり」時のCPU使用率をそれぞれ示す。この両者を比較すると、CPU移動「あり」の場合は「なし」の場合に比べて1.8倍以上のCPUリソースを投入することで、バッチ処理が半分以下の時間で完了していることがわかる。よって、例えば「オンライン処理の負荷が低い夜間は、オンライン処理用のvParからバッチ処理用のvParにCPUを移動して、バッチ処理時間を短縮する」といった運用が有効であることがわかる。 |
|
|
つづいては、CPU負荷の高いオンライン処理の実行中、vParにCPUを追加した場合の振る舞いを検証しよう。
|
このグラフでは、とくに緑色のTPS（トランザクション処理スループット）に注目してほしい。このように、CPUを追加した時点からスムーズにスループットが上昇しており、サービスの中断などは発生していないことがわかる。また今回の検証では、CPUの削除時にも上記グラフと同様に、サービスを中断せずにスムーズな移行が可能なことが確かめられた。よって、例えば「オンライン処理が高負荷な状況では他のvParから一時的にCPUを追加し、負荷が落ち着いてきたらCPUを削除する」といった運用を、サービスを止めずに実施できる。
なお日本HPでは、「vParの最大CPU数は、Oracleインスタンス起動時に存在したCPU数の3倍以下に保つ」というプラクティスを推奨している。なぜなら、Oracleでは起動時に存在するCPU数を認識し、その数の3倍までは最適化が可能な設計となっているからだ。このため、後からvParにたくさんのCPUを追加しても、Oracleインスタンスの最適化がなされない可能性がでてくるのである。 |
|
|
つづいて、高負荷なオンライン処理の実行中に、vParにメモリを追加した場合の振る舞いを検証してみよう。なお、以下はOracle Database 11gを中心に説明しているが、Oracle Database 10g であればMEMORY_TARGETをSGA_TARGETに、MEMORY_MAX_TARGETをSGA_MAX_SIZEと置き換えることで、SGAに関して同様のことが実現可能である。
ここでは、2つの手順を実施する。まずはvParにメモリを動的に追加する。これによりHP-UX のカーネルは新しいメモリ ページを含むようデータ構造を更新するとともに、アプリケーションに対して利用可能になった新しいメモリの使用を許可する。つづいて、Oracleの初期化パラメーターMEMORY_TARGETを変更することにより、追加したメモリをOracleが利用可能となる。
|
この図では、メモリ追加時およびMEMORY_TARGETの変更時に一瞬のサービス停止が発生するものの、その後はスムーズにサービスを継続できていることが確認できる。
ちなみに、この例のようにMEMORY_TARGETはOracleインスタンスの稼働中に動的に変更可能だが、その最大値を設定する初期化パラメーターMEMORY_MAX_TARGETは動的な変更ができない。よって、MEMORY_MAX_TARGETにはメモリ追加後のサイズを考慮した値をあらかじめ設定しておくことが必要となる（ただしMEMORY_MAX_TARGETの大きさに比例してダンプ領域やスワップ領域も大きくなることに留意する）。
|
|
|
最後に、同じ状況下で今度はメモリを削除した場合の振る舞いを観察してみる。先ほどの逆で、まずはMEMORY_TARGETを少ない値に変更してOracleインスタンスが消費するメモリ領域をある程度解放させる。つづいて、vParからメモリを削除するという流れとなる（vParからのメモリ削除は、フローティング メモリに対してのみ可能）。
|
ここで示されるように、vParからメモリを削除した時点で、サービスが20秒程度停止することがわかる（ただし、他のvPar上のサービスには影響しない）。この停止時間は、vParからメモリを削除するために、HP-UX のカーネルが空にするメモリ ページを選択し、内容を他の空きページかディスクに移動させ、そのメモリ ページをデータ構造から削除するために発生する。よって、vParへのメモリ追加とは異なり、メモリ削除はサービスへの影響に注意しながら実施すべきことがわかる。また、メモリ削除の前にMEMORY_TARGETの縮小を実施しておかないと、メモリ削除にはより長い時間がかかることになる。
以上、今回はHP Integrityサーバーのユニークな仮想化技術vParsとOracleデータベースの組み合わせによる、サーバーリソース動的配分の実地検証結果を紹介した。ここで見たとおり、vParsは物理サーバーと同じレベルの優れたI/O性能を提供しながら、サービスを止めずに動的にCPUやメモリを追加・削除できる柔軟性を備えていることがわかる。
また、vPars＋Oracleのもうひとつのメリットは、それが日本HPによって徹底的に検証済みのミッションクリティカル環境向けソリューションである点だ。よって、「新規サーバーの導入コスト削減」、「TCOや消費電力の削減」、「ビジネス変化に応じた柔軟な構成変更」といった仮想化技術のメリットを、基幹業務を支えるOracleデータベースサーバーにも安心して適用することができる。事実、vParsは国内の大手商社や大手流通業をはじめ、数多くのミッションクリティカル環境に導入済みの、“枯れた”仮想化技術なのである。今回の検証結果をふまえて、vPars＋Oracleの可能性を新しいシステム提案に生かしてみてはいかがだろうか。
|
|
|
|
|
|
|
| 2009年6月9日より、日本オラクル社においてOracle製品のCPUライセンスポリシーが変更され、一部ベンダーのRISCベースUNIXサーバー向けライセンス料金は大幅値上げとなりました。一方、同じコア数あたりのライセンスで比較すると、HP Integrityサーバー向けのライセンス料金はおよそ1/2となり、圧倒的なコストパフォーマンスを提供しています。 |
|
|
 |
 |
1 | 2 |
|
| 本ページの内容は執筆時の情報に基づいており、異なる場合があります。 |
ご購入前のお問い合わせ
 |
|
エンタープライズ向け製品の
ご購入前のご相談
03-5749-8328
09:00-19:00 (月曜−金曜)
10:00-17:00 (土曜)
※祝祭日と5月1日は除く |
|
|
|
 |
|
製品・キャンペーンに関するお問い合わせ
|
|
|
ご購入後のお問い合わせ
オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。
ショールーム
 |
|
導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策を実体験して頂けます。
|
|
印刷用画面へ
