事業を展開する企業が抱える問題として，新サービスのリリースを優先した結果，システムが乱立しTCOが増大していることに気が付かない企業などもあるかと思います。とくに，企業に体力があり勢いに乗る事業などを展開する場合，次々と新しいサービスを提供することに衆目が集まり，基盤やインフラまでなかなか目が行き届かず，結果としてSIerなどが仕切っていたり，外部ASPなどに任せてしまったり，思いつきでサーバやデータセンターなどを増やして対応しようなどといったこともあるようです。

今回は，これらの問題点への対応として，今業界を賑わせている「サーバ仮想化」を利用した場合，どの程度解決，貢献できるのか？ ─その可能性も含めてですが─ 実際に企業が初めて利用する場合のメリット／デメリットについて説明できればと思います。

数年前から徐々に注目を集めてきたサーバ仮想化ですが，CPUがマルチコア化した昨今，一気に採用企業が増えてきたのかと感じています。筆者も随分昔にIBMの汎用機にてPR/SM（LPER）の技術に心を打たれ，感動した覚えがあります。あれから十数年経って，ようやくエントリー向けの技術者でも気軽に仮想化の技術に触れることができるのかと思うと感慨深いものがあり，案件に仮想化がマッチングできるようであれば，積極的に検討しようと決めていました。

サーバ仮想化の選択肢

ハイパーバイザー型の仮想化技術を採用する場合，VMware，Xen，Hyper-V，KVMあたりが比較的簡単に資料を入手することができ るかと思います。これらの中からユーザ系企業で採用する場合の心理として，極力「メーカお墨付きの技術」であるか「圧倒的なシェアを持っている」ものを採用したいと考えます。

Xenの場合は多くのディストリビューションからリリースされていることや，Linux関連の知識が必要なこと。KVMに関しては，今後のトレンドとなる可能性を感じつつも，現時点での実績なども考慮して深い検証なくして採用をすることに関してはまだまだ敷居が高いイメージが拭えないよう感じてしまいます。

一方，Hyper-Vに関してはその姿は目新しさがあるものの，Microsoft Windows Server 2008に標準搭載され，Microsoftからサポートを受けることができることと，コストなどの面から検討しても非常に魅力的な技術であるかと思います。未だ他の技術と比べた際に，見劣りする部分もあるようですが，これらに関しては日進月歩で埋まっていくものと思われるので，ますます目が離せないものとなるでしょう。但し，Windows Server 2008を利用しなければならないという制約があり，筆者の環境では実現させることができませんでした。

最後にVMwareシリーズですが，ヴイエムウェア（⁠株⁠）が販売，保守元となっている点に関しては安心できますが，ライセンスの種類，バージョンと機能の違いなどで障壁を感じる部分もあるかと思います。無償版が用意されていることは大変うれしいことですが，できること，できないこと，できないことの代替などを検討する必要があり，よりきちんと機能を理解して設計，実装を行う必要があります。

今回は，若干消去法的となりますが，無償版でもあるVMware ESXiを利用して行きたいと思います。

事業形態（サーバの構成）に応じた仮想化の選択

VMware ESXiを利用する場合，それ相応のリスクもあることは十分認識して望む必要があります。まず，よく挙げられるのがvSphere（Serverなども含む有償の製品）との機能比較ですが，サービスコンソール，VMotion，VMware HA，などの大まかな機能からネットワーク周りの小さな設定まで，全機能を列挙する方が手間となるため，これらの善し悪しを比較するよりも，ESXiを利用する前提でポリシーを制定したほうが効率的です。

1．VMwareを採用するシステム

ローコストで結果が出るとわかっているのであれば，全てをVMwareにてまとめてしまいたいという考え方もありますが，実際に検討してみたところ，上位ミドルウェアによっては正式なサポートが受けることができない可能性があることがわかりました。今回の連載では，データベースサーバにてOracleプロダクトを利用していますが，「⁠VMware＋Linux＋Oracle」という構成が，Oracle社から正式なサポートを受けることができないことがわかったのです。

しかし，実際には稼動させることができたり，ベンチマークなどさまざまなレポートが出ていたりしているので，あくまでもユーザ側の責任において採用することは可能です。ただ，問い合わせや障害時における切り分けについて，完全にVMwareが関係ないことを証明しなければならず，これらの手間などを考えると，今回はデータベース系にVMwareを採用することは見合わせることとし，もともとオープンソースのみで検討を行っていたWebサーバ側にVMwareを採用することとしました。

また，仮想化を実装するための設計として，最初に実マシンと仮想ホストの割り当てを行い，次に実マシンのローカルディスクの割り当てを検討するかと思います。この検討が比較的重要で，ここで極力ホストに影響されないディスク設計をすることをお勧めします。

たとえば，仮想ではなく物理マシンのイメージから移行する場合などで，ローカルディスク障害で影響を受けるホストを極力減らしたいなどといった際，単純に考えてしまえば，物理的なディスクの数を実行ホストで分断する等といった考慮が必要となりますが，これらはあまり汎用的でないと考える人も多いかと思います。逆に、筐体に搭載されるディスクを全て共有（RAID0など）とする場合は，ディスク障害によって複数のホストに影響がある可能性も考慮する必要もあります。

このような点もあって仮想環境を実現する上でのディスク設計は後々の展開までも影響することから，それぞれの事業形態などに合わせたポリシーを制定し選択いただければと思います。

今回は，ディスクも含めたハードウェアの障害はスタンバイマシンで対応している間に修理を行い，外部ディスクに格納されるシステムバックアップから一括コピーで対応するという形としたため，RAID0のみといったシステムを設計しました。

2．スケールに対応したシステムとし，＋ｎ台構成で不測の事態に備える

VMotion，VMware HAなどの機能を利用しない前提とするため，不測の事態に対しては極力スケールで担保できるようにしました。そのため，もともとの台数から極限まで集約させる醍醐味を犠牲にしてしまう部分もありますが，スタンバイ機と位置づけることにより運用を軽減させることができます。逆に，サーバ台数が＋ｎ台となるため初期投資が増加することに関しては，VMware商用版のライセンス（ランニング）コストと相殺してもメリットがでることをシミュレーションできれば，ハードウェアなどで解決することが望ましいでしょう。

おそらく，ある台数で損益分岐が存在するのかと思うのが，筆者の経験上，集約後に15台程度（ホスト数は30程度）であれば1，2名で運用する事ができ，運用負担はあまり感じないと考えます。