サーバー仮想化の問題点: ハイパーバイザーが高価である ?

サーバー仮想化で「導入済み企業」が押さえるべき点、「未導入企業」が理解すべき点(全文を読むには登録が必要です)

 上記の結果をみると、「サーバー仮想化を実現するために必要なハイパーバイザーが高価である」という回答が21.0%と最も多く挙げられている

 そんなにハイパーバイザーは高価なのでしょうか。

仮想化のお値段:無制限インスタンスに払うお値段比較

 という記事を1年前に書きました。実際、この春に、導入されたお客様は、ハイパーバイザーに SUSE Linux Enterprise Server 11(年間約4万) 、1Uラックマウントの2ウェイサーバーに約90万円、これで、8つの仮想サーバーを導入しました。

 確かに1台のハードウェアとしては高価なものですが、10G baseTでのSAN構成でこの値段です。これが私がご提案する「サーバー仮想化」のお値段です。この中には仮想OSのライセンスは含まれていませんが、既にお客様はエンタープライズライセンスをお持ちです。わずか10分でSysprep イメージから、新しい Windows 2008 サーバーを構築することができるようになっています。一番困るのは Windows Update にかかる時間だけです。

 また SUSE Linux Enterprise Server (SLES11) は仮想化インスタンスは無制限です。この1台のハイパーバイザーの中で8台のWindows と Linux のエンタープライズシステムが稼働しています。

 私がご提案する「サーバー仮想化」はハードウェア込みで約100万円。これは従業員150名程度のネットワークインフラ基盤を整えるためにはそれでも贅沢な構成です。

 しかし Windows の Datacenter Edition であれば、ハイパーバイザーだけで119万円、プラス、100万円では収まらないハードウェア費用が掛かるでしょう。

 私がSI事業者のセールスマンの立場だったら、間違えなく300万から400万の売上が上がるシステムを、鼻息荒くして提案します。

 ちょっとした興奮モノの案件になります。

バックアップをどうするか

 私がご提案する仮想化サーバーのバックアップは単純です。業務が止まっている深夜に仮想マシンを  cron でシャットダウンして、バックアップコピーを作って再スタートさせる。それだけです。8GbのLinux 仮想化システムであれば40秒以内でシャットダウン、バックアップコピー、リスタートします。実質1分程度の遮断時間はありますが、実務(と言っても深夜)に影響などはありません。もっとも、ファイルサーバーなど、日々変更があるデータは一般的な方法でバックアップします。

 この一連の流れが終わるとバックアップコピーされた仮想システムはNASやテープなどの外部メディアにとコピーされます。

 実際、サーバーがロストした状態でも、仮想システムイメージがあれば、ハイパーバイザーを入れ直して起動してしまえば、問題ありません。

 幸いな事に、このお客様の場合、既に仮想化システムを導入してから5年。ハードウェアの故障は、せいぜいRaidディスクのアラート程度でした。ハイパーバイザーのトラブルもなく5年の減価償却を終えようとしています。今回ご提案したシステムは、5年前のシステムのリプレースです。

 リプレース自体も恐ろしく簡単でした。何しろ仮想システムのイメージコピーを新機材にコピーして、一方を停止し、一方を起動するだけです。

--
 仮想化する上で「共有ファイルシステムと二重化したCPU装置、HUB,ストレージが必要」と説く方もいらっしゃいます。

 しかし、仮想化しない時点でシンプレックスな構成、ホットスタンバイな構成を取っていないシステムを仮想化移行すると考えてみましょう。特にシンプレックスな単サーバ構成で厳重なバックアップを作っておけば、問題ないはずです。そもそもがシンプレックス構成であっても、アタリが良いサーバーであれば、償却期間内にハードウェア故障によるトラブルはほとんどないはずです。

しかも、ハイパーバイザーの上で動作しているのは、ハイパーバイザーと管理用のソフトウェアだけです。まず、ハイパーバイザーだけなので、トラブルも起きようがありません。もっとも Windows サーバーをハイパーバイザーとして選択した場合、「例の毎月」のパッチによる再起動が必要なので、SI事業者側はシステムの二重化は提案してくるでしょう。

 余った予算で24H4時間対応のオンサイト保守に入っておくのがベストなのです。MTTRはわずか4時間以内なのですね。

 また、エンジニアとしての経験から、

 「単純なシステムほどトラブルは少ない」

 と考えています。エンジニアとしてはどうしても複雑で高度な技術にチャレンジしたいと考えてしまいます。しかしお客様の立場で運用することを考えてみると、できるだけ単純な方が問題がないのです。

 またトラブルが発生した際のMTTR(復旧時間)も少なくて済むものなのです。実際に複雑なバックアップ、リカバリ体制を検討した場合、想定した障害と復旧プランはほとんど役に立たないでしょう。

 もっとも、24H無停止を目標とするサーバーであれば、どのみちディュプレクスしなければなりません。しかし、単純なCPU二重化、ディスクコントローラの二重化では終わらない問題があります。それはお互いの死活監視の制御です。これは仮想化以前の問題です。

 また、システムの二重化はオペレータの負荷が重要となります。

 よくある話ですが、Raidが壊れた、という事に気が付かず、全てのデータを損失したというケース。システムが二重化されている場合、障害によりシステムが切り替わっても、利用者は気が付かずに運用を続けてしまいます。オペレータのセンスが良ければ、何等かのアラートを見つけて異常事態に気が付くでしょうけど、普通の中小事業者のシステムでは、そこまで目が行きづらいものです。

 しかもシステムを無停止運用したいという、中小事業者がその様な余剰で優秀な要員を24時間体制で確保できるわけはないのです。

 そこで、実はシステムに障害が発生すると、誰もが「おかしい」と気が付くように、「壊れてしまっている」状況を作り出した方が良いのです。極論かもしれませんが、実用的な障害アラートなんですね。本当に「ご臨終」になる前に、何らかの「おかしな現象」を出した方が、施術の手段があります。

 例え、システムの停止が数時間でも、あるいは完全修復に数日かかっても、データを完全にロストしてしまうよりはよほどマシなのです。

 その時のためのバックアップは重要ですし、毎日の運用管理者(大抵は兼任)がバックアップの確保だけはルーティンジョブとして目視確認すべきでしょう。

 それほど重要なシステムであれば、レスポンス、従量課金費用を考慮した上で、大手のクラウドサービスを考慮すべきです。

 パブリッククラウドサービスは、基本的なハードウェア、ミドルウェアなどの、提供しているサービスの障害は、利用者側が忘れてもいいことです。しかし、オペレータのミスオペレーションは許容していません。

 勿論、サービス事業者の提供するサービス内容に、データのバックアップがあったとしても、それなりのオプション費用がかかります。オンラインで手元にバックアップするのであれば、従量課金での費用が莫大になりそうです。

islandcenter.jp
[PR]
トラックバックURL : http://islandcnt.exblog.jp/tb/19934731
トラックバックする(会員専用) [ヘルプ]
※このブログはトラックバック承認制を適用しています。 ブログの持ち主が承認するまでトラックバックは表示されません。
by islandcenter | 2014-06-25 12:57 | プライベートクラウド | Trackback | Comments(0)