ハイパーコンバージドインフラ(HCI)や仮想環境ではHAクラスターは不要でしょうか?

アプリケーション障害検知から復旧までの所要時間
Pocket

こんにちは
サイオステクノロジー國政です。LifeKeeperのプリセールスを担当しています。

今回はタイトルに掲示しているテーマでお伝えしたいと思います。
近年、NutanixVxRAILSimpliVityNetApp HCIなど各種ベンダーから様々なHCI製品がリリースされています。

市場をリードする企業はMagic Quadrant for HyperConverged Infrastructureからもある程度読み解く事ができます。

Gartner社 Magic Quadrant for HCI 2018

< 図:Gartner社 Magic Quadrant for HCI 2018 >

次に実際どのくらいHCIが導入されているかの点については下記の調査結果を一つの目安として参照して下さい。

参照先:ノークリサーチ社PressReLease(PDFファイル)

これらの資料から、700社に対しての調査で、HCI導入済となっている企業は全体でも10%程度と読みとれます。

これから伸びる市場ではあるかと感じますが、まだ高価であったり、少実績であったり不安と感じるマイナスの要素と従来の3Tire構成からの自由度が大きい、統合管理ができるなどプラス要素のある事はその通りかと思います。

HCIを提供しているベンダーの多くはVMware ESXiをHypervisor環境として用意しています。

この点をフォーカスすると、実はまだ多くのお客様環境で採用されているVMwareによる仮想環境と考える点は同じである事に気づきます。

VMware HAはどのような目的に有効か

さて、ここからが本ブログの本質になります。

HCIも従来の仮想環境も「同じVMwareによる仮想化」という事は、標準機能で実施できるクラスター機能の呼称である「VMware HA」がどのような目的に有益な物か考えたいと思います。

キャプチャ

 

そもそもなぜHA(High Availability)構成が必要か考えてみましょう。

答えはシンプルで「稼働率を上げる」=システムを落とさない事が重要です。

とは言うものの、障害は発生するものとして考え、発生した時に素早く復旧させる事により「稼働率を上げる」という目的を少しでも達成に近づける事ができます。

HA構成の分類

この稼働率の向上については、二重化と言われる言葉がよく用いられますが、この二重化の組み方も費用のかけ方次第で年間のダウンタイムを短くする事は可能です。

費用は十分かける事ができるので、とにかくダウンタイムを限りなくゼロに近づける要件や、同じサーバーを用意し瞬間的に切り替えを終了したいもの(フォールトトレラント)、

あらかじめ用意しておいた待機系サーバーへ切り替え(Fail Over)させる物(High Availability)など費用許容されるダウンタイムなど求める要件によって選択頂く事になります。

当社製HAクラスターソフトウェアのLifeKeeperは、フォールトレジリエントクラスに準じた99.99%の可用性を目標とした製品であり、一般的な商用Availability製品よりも高い可用性を提供します。

Availabilityクラス Availabilityレベル 年間ダウンタイム コスト

連続処理
(Continuous Processing)

100% 0分

フォールトトレラント
(Fault Tolerant)

99.999% 5分  

フォールトレジリエント
(Fault Resilient)

99.99% 53分  
一般の商用Availability 99-99.5% 44-87時間

< 表:可用性の分類、赤の部分はLifeKeeperの分類される箇所>

稼働率を上げるには

さて、話を元に戻しましょう。「稼働率を上げる」には、障害を早く検知して、早く復旧させる事が大事です。

早く復旧させるという点においては可用性の話題の際には出てくるRTO(Recovery Point Object):目標復旧時間の短縮が考えるべきポイントです。

仮想環境において標準で準備できるVMwere HAについて”障害を早く検知する事”と”早く復旧させる点”について考えてみましょう。

VMware HAはHAと名前が付いていますが、その役割はホスト障害で停止した場合に他の正常なホスト上で稼働させる機能となっています。

一見するとこれで大丈夫かと見えますが、実は大きな見落としポイントが存在します。

それは….“標準のVMwere HAではゲストOS上のアプリケーションの状態までは監視する事ができません。

VMwere HAにてアプリケーションまで見るには”対象毎にSDKを入手しハートビートをカスタマイズする”手法しかありません。

参考:仮想マシンとアプリケーションの監視

アプリケーションの監視までVMwere HAで行うには敷居が少々高く、一般的には何か別の手法でのアプリケーション監視を必要とします。 

これはHCI環境においても同じことが言えます。

なぜなら前記した通り、HCIの環境を提供するHypervisor部分において多くのベンダーがVMwere vSphere Hypervisor(ESXi)の環境を提供しており、VMwere HAの利用が可能となっているからです。

これら仮想環境、HCI環境でも、ホスト監視、アプリケーション監視、異常時には待機系へ切り替える(Fail Over)手法のHAクラスター製品であるLifeKeeperがVMwere HAより早く障害を検知し、サービス継続が不可と判断した場合に素早く待機系サーバーへ切り替える事で復旧時間の短縮が見込めます。

アプリケーション障害からの復旧

下の図をご覧ください。

アプリケーション障害に着目した場合の、VMwere HA、VMSDK+VMwere toolsでカスタマイズを行った場合、LifeKeeperの場合で復旧までにかかる目安を示しています。

ただし、真ん中のカスタマイズの項はその仕組みが作成できれば良いですが、作成できない場合は一番上のVMwere HA状態となり標準状態では障害からの復旧はありません。

アプリケーション障害検知から復旧までの所要時間

< 図:アプリケーション障害検知から復旧までの所要時間 >

私どもでは、仮想環境における可用性を高める手法として「網羅性」「即時性」「適応性」の観点からどのように対策を行うべきかの指標を公開しております。

また、冒頭に書いてあります新仮想環境(HCI)上においてもLifeKeeper動作検証済の物もあります。

参照先:LifeKeeper for Linux on Nutanix 動作検証レポート(PDFファイル)

仮想環境だから、HCIだからサービスレベルを落としてよいとはなりません。

VMware仮想環境でも、HCI環境でも可用性を高め障害からの迅速な復旧を行う為にもHAクラスターの仕組みは有益でありLifeKeeperは必要なのです。

>>HCIに関するブログ記事はこちら

ご案内

「もっと詳しい話を聞いてみたい。」「自分の持っている案件は対応できそうか?」といった場合は、下記までお気軽にお問い合わせください。
>>お問い合わせはこちら

SNSでもご購読できます。