事業を展開する企業が抱える問題として、新サービスのリリースを優先した結果、システムが乱立し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名で運用する事ができ、運用負担はあまり感じないと考えます。
3．スタンバイ機の利用
運用局面において、ハードウェア障害やリージョン不足などによるスローダウン、その他一般障害に関しては、スタンバイ機をアクティブにすることにより対応することとしました。普段から電源は投入され、バック側（運用管理LANなど）は本番機器同様とすることにより、業務アプリケーションのプログラムリソースなどは常に最新となるように構成し、障害時に対象機器を本番ネットワークから切り離し、スタンバイ機を本番ネットワークに参加させる運用を確立しました。このプランは、通常商いが右肩上がりの際のシステム増強などに関しても柔軟かつ即時に対応することもでき、比較的経営側を（楽に？）説得することが可能なプランでもあります。
4．バックアップ運用の変更
これまでの運用では、システムバックアップ用にそれぞれテープドライブを用意したり、場合によってはバックアップサーバなどを準備して対応していました。これらに関しては、サーバやテープドライブ、メディアなどを準備しなければならず、その管理など含め専用の運用やルールを設けていました。また、バックアップ用のソフトウェアなどがある場合も同様に運用や保守料などが必要な場合もあります。
今回VMware ESXiを複数台本番運用で採用することでテープ関連の運用は全てディスクに移行するべく、「 ローカル、スタンドアロンでの利用イメージ」を念頭に置くこととしました。そのため、少々面倒な構成ではありますが、全てのホストはiSCSIなどで外部ディスクと接続し、システムバックアップ領域は全て外部筐体に格納することとしました（筐体は単体だが、ホストごとにマウントさせるイメージ） 。
これによりテープ関連の運用から切り離すことが可能となりました。
図1 構成イメージこれによりテープ関連の運用から切り離すことが可能となりました。
たとえば図1の構成で本番運用が行われていた場合、さらに、スタンバイ機「マシン3」に「SystemE」「 SystemF」を準備しておくことで、仮にSystemCに無応答などの障害が発生し復旧に時間がかかる見込みの場合、マシン1自体がダウンしてしまった場合、あるいは別途サーバ増強が必要となった場合に、マシン3の両システムを本番稼動させることにより対応することができます。
また、マシン1自体がダウンしてしまった場合や、RAID0などで構成されているシステムではディスクに障害が発生した際に問題箇所のパーツを交換するなど対応をした際に、システム的な設定（フォーマットやスライスの定義）を行い、後はハイパーバイザからiSCSIを認識させてシステム的なリストアを実施することができます。容量（対応時間）などにもよりますが、ddコマンド一発でリストアできる運用も可能です。
iSCSI側の機能にもよりますが、筐体に即効性などを持たせなくてもよい場合、RAID1やRAID5構成とし、ボリューム・スナップショットなどと併せてバックアップ運用に関する要件をまかなうことを可能とします。また、シン・プロビジョニング機能なども搭載されていていれば、比較的容量を気にすることなく運用を続けることが可能になります。これにより、システム（場合によってはデータ部分）に関しては、テープにコピーするための装置、プロダクト、運用などから開放され、その集約効果も期待できます。
図1 運用イメージ5．運用局面
VMware ESXiを利用した運用局面に関する注意事項としては、前記のようにスケールに対応したサーバのポリシーと、通常の運用のほかに、リソースの利用状況について一層注視しておく必要があります。とはいっても、一般的なインフラ（サーバなど）の稼働状況レポートを決められた期間ごとに推移を見定め、増強の可否を検討する程度で良いと思いますが、サービスを提供するアプリケーション部門に関しては、新技術を採用することにより若干抵抗がある可能性もありますので、インフラ、サーバ基盤担当として「論理部分」と「物理部分」に分け、仮想化による悪影響が出ていないことが確認できれば良いと思います。
［論理部分］
無応答などの死活確認、セッション数やコネクションプールなどの推移、パフォーマンスなどを注視し、特段問題ないことが証明されていれば、後は時間が過ぎれば慣れていくものかと思います。
［物理部分］
・CPU／メモリ使用量
これらはハイパーバイザ側からある程度明示的な定義ができるため、それらについて問題が無いこと確認する。
・ディスクパフォーマンス
OSのバージョンをあげたらswapアクセスが増えたなどといった些細なことでも仮想にしたから？と疑われてしまわないよう、普段のヘルス、動向をきちんと把握し、不測の事態でも切り分けができるようチェックする。
・ネットワーク状況
場合によっては、複数ホストにて共有する可能性がありますので、帯域など問題ないかなどが確認します。 おおよその場合は、外部（インターネット側）の専用回線が1Gbpsかと思われますので、内部セグメントに関してもクリティカルな部分で無い限り同様に近い形で問題ないかと思われます。
図3 運用イメージ
