Loading
|
@IT > サーバ仮想化は開発環境を救う |
開発環境を充実させることは、システムの導入をスムーズに行うための第一歩といえる。開発環境に仮想化の技術を取り入れることで、物理的な開発マシンを用意するよりも優位な点がたくさんあるのだ。一般的に仮想化による開発時のメリットとしては、サーバの物理的な構造に依存しない環境を柔軟に提供できることが挙げられる。そして、開発環境の基盤部分を仮想化で一度構築してしまえば、要求に応じて新たな開発プラットフォームを迅速に提供できる。 コスト面からも開発環境に仮想化技術を取り入れるメリットは大きい。システムを開発する際に、本番環境を利用して少人数で作業を進められるならば、別途開発用のサーバを購入する費用は発生しないかもしれない。しかし実際はこういったケースはまれで、開発は複数のチームに分かれ、同時並行的に作業が進められる。そのため、複数のチームごとにサーバが用意され、他のチームの作業に影響しないようにするのが普通だ。それぞれに相当なスペックのサーバを複数用意することになるので、開発に入る時点で大きな費用が発生することになる。 こういった大規模なシステム開発に仮想化技術を採用すれば、効率的に開発プラットフォームを用意できる。ある程度パフォーマンスのある物理サーバを1台用意し、その上に仮想化環境を構築する。仮想化を使って複数のバーチャルマシンを作り、各チームの開発プラットフォームとして利用するのだ。 開発時には、作業の内容によって開発環境に要求される処理性能にばらつきが発生する。仮に、あるチームの作業負荷が高くリソースが足りなくなったならば、ほかの余裕のあるバーチャルマシンからリソースを借りて再配置することも可能だ。この方法ならばリソースの無駄もなく、必要最低限のサーバを導入するだけで済む。 本番環境のサーバやOS環境が異なれば、新たなシステムの開発時に前回用意した開発マシンが転用できるとは限らない。当然開発現場では、新しい開発サーバをその都度要求することになるが、経営者層はその必要性を容易に理解できるとは限らない。CIOの立場にあれば、開発環境を充実させて現場の士気を下げずに効率的に作業を進めたいところだが、だからといってむやみに物理的なマシンを購入するわけにもいかず板挟み状態になるだろう。仮想化環境であれば、こういった新たな開発環境の要求にも十分に応えることができる。
もう少し具体的な開発シーンを想定して、開発環境における仮想化技術のメリットを説明しよう。ここでは、大規模なシステムの代表ともいえるSAPの導入を例に考えてみる。 一般に、SAPシステム開発では、開発、検証、本番の「3システム・ランドスケープ環境」を用いることが推奨されている。これには、それぞれに専用のサーバを導入するのが一般的だ。さらに、プロトタイプ用のサーバを別途先行導入し、自社の要求がSAPのパッケージ上で実現できるかを判断するために用いることもある。また、通常は開発機、検証機は導入するSAPのプロダクト単位で準備するのが普通だ。SAPを導入する際に単一のプロダクトで済むことはほとんどない。 このように、SAPの導入には、本番環境以外にも多くのサーバが必要になる。当たり前のことだが、プロトタイプ開発機、開発機、検証機は、それぞれの作業が終了すれば、その後の稼働率は極端に低下するかゼロになる。また、開発のフェイズや対象のプロダクトごとにサーバ利用頻度にはばらつきがあり、常にどのサーバも稼働率が高く負荷が高いわけではない。つまり、どのサーバもリソースには余裕があるのが普通だ。 これらのサーバの利用効率を向上させる方法として、サーバ仮想化技術の導入がある。仮想化を導入すれば、「必要なリソースを持ったシステム=最適な構成の物理サーバ」である必要はなくなる。用意した物理サーバ上に、必要なリソースを持った仮想サーバをその都度構築すればいいからだ。仮想サーバでは、必要に応じて割り当てられたCPUやメモリのなどのリソース量を変更できる。このハードウェアの共有で、物理サーバの利用率が向上するのだ。 通常、プロトタイプ機には、将来的に必要となる開発機と共用することを考慮してサーバ・モデルを選択する。例えば、HP Integrity Serverのrx3600、rx4640などの高速なCPUを搭載したサーバを導入する。このクラスのサーバであれば、複数のプロジェクトの開発サーバとして利用できる拡張性、可用性を備えている。 用意したサーバのホストOSの上に、Integrity Virtual Machine(Integrity VM)を使って、必要なリソースを持った仮想サーバを構築する。仮想サーバだからといって、特に物理サーバと操作が異なるということはない。もちろん、サーバの起動、停止などは物理的に行うのではなく、ホストOSの管理者がソフトウェア的に実行することになる。起動してしまえば、通常の物理サーバと同様に利用できる。 例えば、プロトタイプ評価時に4つのSAPプロダクトを検証するために、4つの仮想サーバを用意する。プロトタイプ評価が終了したならば、そのままその物理サーバを開発環境に移行する。プロトタイプの4つの仮想サーバ環境は保存したまま、新たに4つの開発環境を仮想サーバで構築すればいい。開発中に、あるSAPプロダクトの開発コンポーネントが増加し負荷が上がれば、その時点でその仮想サーバにCPUリソースを追加することで対応できる。
稼働率が全体的に上がってしまい、物理サーバのリソースだけでは対処できない状況になった場合には、新たな物理サーバを追加し負荷の高い仮想サーバをそこへ移動する方法もある。Integrity VMであれば、仮想サーバをほかのホストOSに移動することも簡単に行える。本番用にrx8640やSuperdomeなどの高性能なサーバを用意しているならば、その一部のリソースを仮想化し、開発環境に割り当てるといったことも可能だ。 このように複数のSAPのインスタンスを起動し、同時並行的に仮想サーバで開発作業が行える。各仮想サーバの負荷の状況に合わせ、リソースを配分することで開発者はストレスなく作業を続けることができるだろう。これを物理サーバで行っていた場合には、開発作業が滞ることもあるかもしれない。 例えば、ある開発チームが、最近の作業で負荷が上昇しリソースが足りなくなってきたとする。その場合、週に1度のプロジェクトミーティングでリソース不足を訴え、サーバの増強を申し出ることになるだろう。仮に会議で緊急性が理解され、リソース増強のゴーサインが出たとしても、そこから追加CPUやメモリの購入申請を行い、承認をとって購入、入荷、セットアップという作業となるのだ。その間の数週間はリソースの足りないサーバを、だましだまし利用することになるかもしれない。追加のメモリが届いたころには、負荷の高い作業は終了してしまい、せっかく増強したリソースはその後遊んでしまうかもしれないのだ。
仮想化環境であれば、こういったことを事前に予測して対処することも可能だ。仮想化により物理サーバの管理は減少するが、その上の複数の仮想サーバを効率よく管理するには、仮想化環境を効率的に管理するツール群を活用するといい。ホストOS環境については、SAM(System Administration Manager)やSMH(System Management Homepage)といった管理コマンドで十分な管理ができるが、たくさんの仮想サーバが稼働するような場合にはSIM(Systems Insight Manager)を利用する。これにより物理サーバのリソースと仮想サーバのリソースを関連付けながら、開発環境全体を容易に管理することが可能だ。
SIMには、仮想環境をより簡単に管理するためのプラグインが用意されている。Virtualization ManagerにはSIMの管理画面に物理サーバと仮想サーバのリソースの関係を表示したり、仮想サーバの作成や削除をGUIで簡単に行う機能がある。さらにSIMのプラグインであるCapacity Advisorがあれば、システムの稼働状況をあらかじめ取得しておき、複数のインスタンスをどのように組み合わせて物理サーバに統合していくかを、問題が発生する前に検討することができる。これならば、前述の物理サーバでリソースを増やす際の苦労もなく、事前に適切なリソース配分の管理が可能だ。 HPの仮想化環境をを活用すれば、SAPのプロトタイプ機、開発機の統合は、導入時に大規模なサーバを購入するといったことなく、スモールスタートで実行できる。Integrity VMならば、細かい粒度でダイナミックにリソース配分ができるため、開発環境が要求する柔軟性にも十分に対応できる。SAPのような大規模な開発環境を必要とする際には、Integrity VMによる仮想化は最適な選択となるだろう。また、将来的にほかの開発環境への転用の可能性もあり、中長期的な資産の有効活用を考慮した際には、開発環境に仮想化技術の採用は今後必須のこととなるに違いない。
提供:日本ヒューレット・パッカード株式会社
企画:アイティメディア 営業局 制作:@IT 編集部 掲載内容有効期限:2007年5月25日 |
|