VMware 等の HA 冗長構成では、障害件数を減らせない
»
VMware 等の Hyper Visor の HA 冗長構成では MTBFを改善できない
僕の周りにちょっと誤解をされている人々がいたので、VMware vSphere などのハイパーバイザー層での冗長構成による稼働率向上について整理してみる。知っている人には当然のことだと思いますが、この先を読んで”誤り”があればご指摘いただきたい。
まず、システムの稼働率を高めるためには、（1）システムダウンを起こりにくくし、また（2）システムダウンした際の再稼働までのダウンタイムを最小化することが必要である。
システムダウンの起こりにくさのの指標は、MTBF（平均故障間隔 / Mean Time Between Failures) や AFR（年間故障率 / Annualized Failure Rate）などがある。要はどのくらいの頻度で故障するかという指標である。
ダウンタイムの指標は、MTTR（平均修復時間 / mean time to recovery）がある。ダウンしてから復旧するまでの平均所要時間である。
多くのエンドユーザーは、アプリケーションシステムがダウンした影響を最小化するために大変な苦労をして信頼性向上を図っている。 その取り組みの中で、よく使われる指標に”稼働率”があるが、”稼働率”は稼働していなければならない総時間に対してどれだけ稼働していたか？（ダウンしていなかったか？）の率であり、MTTR / (MTBF + MTTR) などと説明されるが、本質的にはMTBF がどれほど短くても（＝故障頻度がいくら多くても）、MTTRが一瞬にま短縮できれば、数値上の稼働率は向上するのである。
VMware vSphere の HA（High Availability ）などの仮想化ソフトウェア（ハイパーバイザー）による冗長化機能は、このMTTR短縮による稼働率向上を目指しているものである。
VMware vSphere の HA の機能の概要は以下の通りである。
ESXiホスト上で稼働している仮想マシンは、そのホストが障害で止まってしまった場合、稼働停止を余儀なくされる。vSphere HAは、ホスト障害により止まってしまった仮想マシンを他の正常なホスト上で再稼働する機能を提供する。つまり、物理マシンが故障で止まってしまったことを検知して、その物理マシンで稼働していた仮想マシンを予備機（スタンバイ機）など他の物理マシン上で再起動を行う機能である。
仮想化していないマシンのイメージで言えば、マシン故障したらすぐにコビトさんがでてきて復旧のためのマシンを用意してくれてOSをブートしてくれるようなものだ。これによって故障から復旧までの大幅な時間短縮が期待できる。まさにMTTRの短縮である。
これは典型的なフェイルオーバーシステムであり、アクティブ・スタンバイ（アクティブ・パッシブ）システムである。 ダウンしたら、とにかくできるだけ早く復旧させようというアプローチだ。
ということで、これらの機能によって MTTR（修復時間）の短縮は期待できても、MTBF（平均故障間隔）の改善は期待できないのである。 頻繁に落ちては困るシステムであれば、FT（フォールトトレラント / Fault tolerant ）〜その構成部品の一部が故障しても正常に処理を続行するシステム〜 のための方策をアプリケーション、ミドルウェアなどで検討する必要がある。
ちなみに従来のレガシーなオンプレミス環境においては、故障した場合に調査・交換部品手配、交換作業など復旧までのプロセスが長く、長時間要していたために、MTBF改善（長期化）による稼働率向上を図ることが多かった。同様に、我々クラウド事業者、ホスティング事業者にとっては、当然のことながら今でもMTBFは使用製品選定の重要要素であり、カタログスペックや机上計算ではなく実稼働における実績値を日々管理しているので、一部を以下に紹介する。
A社 サーバーa 月間故障率 2.4% / MTBF 42ヶ月
B社 サーバーb 月間故障率 0.9% / MTBF 111ヶ月
A社 サーバーc 月間故障率 0.6% / MTBF 167ヶ月
A社 サーバーd 月間故障率 0.42% / MTBF 238ヶ月
A社のサーバーa などは、42か月に一度は故障する、または42台あると月に1台は故障することを意味しており、たとえ HA によるフェイルオーバー構成となっていても、故障頻度の観点から ”故障率” 改善の対策が必要な機種であり、メーカーに対して強い改善要求を行うなどの対応を実施している。
SpecialPR