*

誤解しがちなVMware等のHyper VisorのHAの期待効果

公開日: : 最終更新日:2014/07/14 クラウド , ,

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 月間故障率 41.6% / MTBF 25ヶ月
B社 サーバーb 月間故障率 0.9% / MTBF 111ヶ月
A社 サーバーc 月間故障率 0.6% / MTBF 167ヶ月
A社 サーバーd 月間故障率 0.42% / MTBF 238ヶ月

A社のサーバーa などは、2年に一度は故障する、または50台あると月に1台は故障することを意味しており、たとえ HA によるフェイルオーバー構成となっていても、故障頻度の観点から ”故障率” 改善の対策が必要な機種であり、メーカーに対して強い改善要求を行うなどの対応を実施している。

クラウド・ITソリューション本部 成迫

関連記事

cloud-mon

改善していける監視を目指して 第二回

ネットワークG 平(ひら)です。 第一回では、主にクラウドサービスの状態監視(イベント監視)に

記事を読む

cloud-mon

改善していける監視を目指して 第一回

ネットワークG 平(ひら)です。 Bit-isle promptに記事を寄稿するにあたり、新し

記事を読む

awssummt

新入社員がAWSサミットに参加してきました。

こんばんは、最近配属が決まったばかりのビットアイル新入社員です。 先週7/17、18に品川で開

記事を読む

techops

システム運用サービスで必要なこと

こんにちは。ビットアイルの 大野 です。 本日は ITシステムにおける一連のライフサイクルの中

記事を読む

構成図

Softlayer Direct Link を smokeping で測ってみた ~その2 インスタンスの作成~

こんにちは。 ネットワークGの藤岡です。 前回に引き続き Softlayer についての記事

記事を読む

ispっぽく

Juniper FireFlyでJUNOSと仲良し その2

ネットワークG 南部です。 前回は2台のubuntu間でpingが届くところまで確認しましたが

記事を読む

構成図

Softlayer Direct Link を smokeping で測ってみた ~その1 構成~

こんにちは。 ネットワークGの藤岡です。 昨年 IBM が Softlayer を買収したニ

記事を読む

kousei

Juniper FireFlyでJUNOSと仲良し

ネットワークG 南部です。 普段からネットワークに触れていることを楽しんでいるのですが、最近の

記事を読む

no image

ビットアイル・エクイニクスのエンジニアブログです。データセンターの最前線から様々な情報をお伝え致します。

構成図
Softlayer Direct Link を smokeping で測ってみた ~その2 インスタンスの作成~

こんにちは。 ネットワークGの藤岡です。 前回に引き続き So

構成図
Softlayer Direct Link を smokeping で測ってみた ~その1 構成~

こんにちは。 ネットワークGの藤岡です。 昨年 IBM が S

cloud-mon
改善していける監視を目指して 第二回

ネットワークG 平(ひら)です。 第一回では、主にクラウドサービ

cloud-mon
改善していける監視を目指して 第一回

ネットワークG 平(ひら)です。 Bit-isle prompt

ispっぽく
Juniper FireFlyでJUNOSと仲良し その2

ネットワークG 南部です。 前回は2台のubuntu間でping

→もっと見る

PAGE TOP ↑