ブレードサーバによる仮想化テクノロジーの活用第2回

ベンチマークテストによる比較考察

   古いアプリケーションサーバを集約する1つの例として、CitrixのMetaFrameでベンチマークのデータを元にしたサポートユーザ数で考えてみよう。このベンチマークの結果で、1999年当時にMetaFrameの1000ユーザ構成をサポートするには、Pentium Xeon 500MHzで4CPU構成のサーバが16台必要となる。

   当時、もっとも小型の4CPUサーバが4U程度と考えれば、2メートルのラック（42Uラック）を1本半使うシステムということになる。ブレードサーバで構築した場合は、どのような構成になるだろうか。

   同じベンチマークから1000ユーザに対応できる構成を現行CPUの結果で考えると、デュアルコアOpteron 2.2GHzの2CPUのサーバであれば6台で構成できる。

   例えば、このCPUを搭載可能なHPのブレードサーバBL35pでは、1つのエンクロージャに16台搭載可能である。したがって、2メートルのラックを1本半使っていた構成が、エンクロージャの半分（6Uの半分）を埋める程度で構成できるようになるのだ。

システムとしてのブレードサーバ

   パフォーマンスが必要となった場合、スケールアウト構成でサーバの増設が必要な際にはサーバブレードをエンクロージャに差し込むだけの簡単な作業でハードウェアを設置できる。

   そしてプロビジョニングツールによりサーバにセットアップされる環境構築を自動化することで、最小限の作業でサーバを追加できる。他にもSANストレージとディスクレス構成のブレードサーバとを組み合わせ、SANブートの環境を構築してSANの機能を使った構成の複製も可能だ。

   サーバ自体の深刻な障害に対してもスケールアウトの構成の場合、ちょうどRAID構成のハードディスクのように、サーバを自律的に復元するような機能をプロビジョニングツールやSANブートなどで実現できる。

   例えばHPのブレードサーバの場合には、リップアンドリプレースという機能がサポートされ、事前に設定されたプロビジョニングの条件がエンクロージャのスロットに割り振られている。これにより障害が発生した場合に、サーバブレード自体を交換しても以前のプロビジョニング環境へ自動的に戻すことができる。

   ブレードサーバを利用したサーバの統合は、単純にサーバを集約するだけではなく、プロビジョニングツールやSANブートを活用して、サーバの障害や負荷の状況に応じて予備機を使うなどの自動化された環境が一般的になるだろう。

   またこのようなニーズに対して、アプリケーションやサービスなどの対応も非常に重要となる。例えば、アプリケーションのライセンス価格が予備機を利用した時点で課金されるような仕組みである。

   HPでは納品設置されるブレードサーバのうち、一部のブレードサーバを従量課金対象とすることができる。このような従量課金対象サーバなどを活用することで、使用料を日割りで課金されるため、システム負荷の増減や臨時の要件に応じ柔軟にシステムリソースとして活用できる。

まとめ

これまで述べてきたように、サーバの統合プラットフォームとしてブレードサーバは有効なソリューションになるということがおわかりいただけたと思う。

ただしブレードサーバは、ベンダーごとにユニークな部分が多い。従ってブレードサーバの検討の際には、ハードウェアスペックだけではなく、各社が提供している機能や管理ツール、サービス面からの検討も非常に重要となる。