Hyper-V のハイパーバイザーでは MTBF は低くないのか？

　Hyper-V の MTBF は低すぎる、と思いませんか？私には良くわかりません。

　これは、微妙、というより大きな数字として、コストパフォーマンスに影響します。

　Windows の MTBF が低すぎる要因として想像できるのは

- 頻繁な Windows Update -> 再起動
- 何か役割でもインストールすれば -> ほぼ確実に再起動
- アンチウィルスが必要でバージョン更新があれば -> 再起動

そして、「修正プログラムを構成中｡｡｡｡」長いこの間はトイレタイム、 MTTR 値が上がります。

　これでプライベートクラウドを構築したら、身が持ちません。まず、確実にライブマイグレーション環境が必要なわけですね。何しろハイパーバイザーが再起動したら、上に載っているシステム全部停止しますからね。だから、ライブマイグレーションは必須の必要悪。当然、導入コスト、運用コストも倍以上に跳ね上がります。

　少なくともＣ：ドライブのウィルススキャンは最低限、マナーと常識として必要ですから、アンチウィルスソフトウェアのプログラム本体の更新も合わせると、月に２度くらいは再起動が必要なケースが訪れます。このわずかな MTTR に対して二重化が必要なのです。

　算数が全くダメな私でも 24 × 30 日 = 720 時間のうち、下手をすれば２度、２時間程度のサービス停止があるわけですから、99.8% 程度の稼働率という事になります。この数字が妥当かどうかは、そうじゃないだろというご意見があれば、ご指摘ください。貴重なご意見です。

100% と言わなくても 99.99% 程度の稼働率ならかなりのものですが、99.9% を切る稼働率だとしたらあまりに低い。

　これは現代のコンピュータシステムのＭＴＢＦとしては「異常とも思える」低稼働率です。99.99% で 1,000 時間に１時間の停止時間です。（数字合っているかな）ほぼ３年に一度程度の稼働停止です。停電などの計画停止やマザーボードの交換でもない限り、不幸に見舞われない通常の Linux サーバーでは当たり前な MTBF 値だと思います。

　Linux を使っている限り、ハードウェア丸ごと停止という事態はそうそうあるものではありません。ディスクの交換も最近はほとんどオンラインです。不幸にも精々メモリ不良が見つかったとか、明らかに管理ツールがマザー、ＣＰＵの障害を見つけたとか、ファームウェアに問題があるとか、そんな程度です。多くの場合、２４Ｈ３６５の４時間サポートで半日程度の停止があり得るでしょう。これは Windows だろうが VMware だろうが Linuxベースのハイパーバイザーでも避けて通れません。

　Windows システムの設計で面白いのは「理由があるから」、「理屈がある」のではなく「理由があるから」だから「理由を付け足す」というシステムの設計方法です。

　ライブマイグレーション自体は、あくまでも緊急で行うもので、「当たり前」にいつも実施するものであるとは考えません。安定しているなら、マイグレーションすべきではない。充分設定内容を考慮して、無停止で行える事が確実だという状況で行うべきものです。パブリッククラウドならいざ知らず、通常に動いている仮想コンピュータの負荷が、プライベートクラウドで急激に変化するものではありません。

それでも、MTBF 100% を限りなく目標とするなら、スタンバイ状態のハイパーバイザーの99.8% は遊んでいる事になります。つまり実稼働しているシステムのコストの実際には限りなく２倍のコストをかけて運用する必要があるということです。

　ベーシックモードで動かして他のサービスは全部止めればいいじゃん、というご意見はまぁ５０％くらいは尊重しましょう。でもネットワークにトラブルが出た場合だとか、リモートでうまく接続できないような場合、難解な PowerShell だけでどれだけ修復できるのか、そもそも Windows なら GUI で操作できるから、というのが選択肢の一つなら Basic モードでインストールすること自体、ネットワークのトラブルでもあれば全然無意味です。Linux の方 CUI の方がよっぽどマシ。

　ライブマイグレーションをするようなシステムの場合、当然かなり複雑な構成となります。無停止を目指すのであれば、当然ディスクストレージも二重化しますし、ＨＵＢも二重化することになります。当然、導入するハードウェエアのコストは２倍以上。

　機器の故障率は機器の構造が複雑になればなるほど、信頼性は下がります。９９％の稼働率の機器２台を組み合わせると0.99 × 0.99=0.9801 つまり９８％に下がります。さらにこれが３台、４台とつながるとますます信頼性は下がる一方です。それでもＭＴＴＲを短くするためにさらに余計で、まず使う事が年に１度もあるかないかの機器を必要とします。

　これが微妙、というより大きな金額として導入と運用コストを跳ね上げます。

　当然、運用マニュアルも難解で、顧客が自前で運用できないほどの複雑怪奇さとなります。導入したベンダーのエンジニアだって理解不能。

　ということで、まず１００万円もあれば十分なプライベートクラウドの１システムの提案書に１千万の見積もりを書いてきたベンダーが居たそうです。そりゃ、予算があれば１千万でも作るべきものは作れますが、私にはとてもじゃありませんがそんな大胆な見積もりを作る訳には行きません。そもそもそれほどの費用を要求するほどの作業はどう考えてもひねり出せません。

　これがパブリッククラウドで、巨大なホスティングサービスの一部であれば、数百台、数千台の運用マニュアルを作って、技術レベルの一般化もできるでしょう。しかしオンプレミスの数台から数十台のプライベートクラウドではそうは行きません。

　もし、ピンで利用しているのなら、

　PM22:00 誰も残業していない間にWindows Update 開始 -> 失敗 -> 原因追究 -> 再起動 -> 動作確認 -> 終電間に合うかな？ -> 翌朝は始発で出勤 -> Dom-U の動作確認 -> 始業

　現実的な出費としては、従業員の残業代という形でしか表面化しませんが、これらの一連の作業を行うことによる時間的な、そして運用担当者の心理的な損失は、コストの中では目立たないので、判らないだけの話です。

　まぁ、多いですよ、Windows Update を定期的にやっていないお客さん。やるとハマりますからね。これが Windows の信頼性を大きく下げている要因です。

- 何だか遅いなぁー
- 余分なプロセスは全部殺したンだけどなぁ
- いいや再起動してみよう
- 何故か直った

　ということでタスクスケジューラで、週に一度、リブートさせているお客様もいらっしゃいました。これがアプリケーションサーバーなら許せるけど、プライベートクラウド基盤であれば、その上に載っている全てのゲストＯＳに関係してくるとなると中々容認できない状態です。

　これが本当のクラウドＯＳの姿なのでしょうか。まだハイパーバイザー上のゲストＯＳとして動いているなら、「いつもの Windows 」で当たり前のように再起動するのでしょうが、これがホストＯＳなら重大な運用障害となります。

もっとも、ハイパーバイザーをピンで利用して、人海戦術、属人対応するというのも手段の一つです。モノがシンプルなので、修復も容易だし MTTR も下がります。

--
実際に「この程度のシステムなら２００万もかからず仮想化できるな」というシステムに１千万の見積もりを平気で出してきたＳＩベンダーが居たそうです。

「重要だから」「止められないから」ということで過剰なスペックを追い求めるのは如何なものなのでしょう。そして、システム管理者の心理的、時間的な負荷を減らすシステムというのはどのようなものなのでしょう。


お問い合わせ
islandcenter.jp

-Key Word-
クラウド 仮想化 ハイパーバイザー 信頼性 MTBF