第5回：仮想化環境の可用性 ～2～
インフラのプロが語る！仮想化のススメ
This is my first blog post
皆さま、こんにちは。株式会社システムエグゼ インフラソリューション部の土谷と申します。
ゴールデンウィークもあっという間に過ぎ去り、いよいよ梅雨のシーズンも近づいてきましたね。
通勤電車の中の温度も湿度も上がってきて、汗がにじみ出る嫌な季節になりました。汗っかきの私にはツライ季節になってきました・・・
夏が徐々に近づくにつれ、日増しに大きく聞こえてくる言葉が「節電」ですね。
以前から「でんこちゃん」を中心とした節電への呼びかけがありましたが、昨年の震災以降、社会全体の節電への意識レベルが大きく向上し、 節電への取り組みは従来以上に積極的なものとなりました。
弊社でも昨年度、節電は会社を上げて取り組んだテーマであり、エアコン温度設定からパソコンの省電力モードのススメまで、 「小さなことからコツコツと」作戦が功を奏し、大幅な消費電力削減を実現することができました。
今夏も全国的な節電対応は避けられず、本コラムの執筆時点で、特に関西方面では深刻な状況であることが報道されています。
今後は原子力発電に依存せず、かつ、日々の経済活動を止めないような安定した電力供給の仕組みが求められていますが、 なかなか一足飛びにはいかない部分なのかなと個人的に考えています。
当面の電力は火力発電の安定稼働で賄い、今後は、太陽光や地熱などのクリーンエネルギー活用のための 発電技術力向上と実用化の拡大が待たれる形になるのではないかと思います。
弊社としても、こうした、エネルギーの技術革新が生まれてくるまでは、お客様業務システムの仮想化環境への移行、 クラウド化へのご支援などを通じ、「節電対策」というキーワードで少しでも社会貢献ができればと考えている次第です。
物理サーバ環境における高可用性確保
さて、今回は前回テーマの続きで「仮想化環境の高可用性」についてお話したいと思います。
前回からのおさらいですが、サーバ機器の高可用性を維持するための仕組みは、物理サーバの構成においては、 商用クラスターウェア製品を使用することが一般的です。
OS上に、クラスター構成とするサーバ全てに対し、上述の製品を導入することで、サーバのクラスター化を実現させることが可能となります。
物理サーバ環境におけるクラスター構成は、基本的には「Active – Standby 構成」であり、 Standby機器は電源だけ投入され、Active機に障害が起きた際にサービスを受け付ける為の待機サーバとして利用されます。
仮想サーバ環境の高可用性確保
仮想環境におけるサーバのクラスター化は、一般的には仮想化製品の機能だけで実現することができます。
今回はVMware製品の「HA(High Availabirity)機能にフォーカスを当て、お話したいと思います。
VMware HAは実は以前の呼称で、最近ではvSphere HAと呼びます。昨年のバージョンアップでvSphere HAは、大きく機能が刷新されるとともに、名前も変わりました。
まず、必要なライセンスですが、vSphere Essentials kit を除く全てのvSphereエディションが使用可能で、かつ、vCenter（VM管理サーバ）が必要となります。
ライセンス的には以前のコラムでご紹介しましたData Recoveryと同じ構成です。
また、システム構成としてはクラスター構成を組む全ての仮想サーバ(ESXi)からアクセス可能な外部ストレージ装置が基本的には必要です。
外部ストレージ上のデータストアにゲストOSを配置する設計である必要があります。さらに、仮想サーバ(間で通信可能なネットワークセグメントを用意する必要があります。
vSphere HA を使うメリット
大まかですが上記の要件を揃えることができれば、vSpherer HA環境を構成することが可能です。
物理環境のクラスター環境と比べ、商用クラスターウェア製品を使用しないで構成できる点が大きな特徴といえます。
商用クラスターウェアのライセンスコストも保守費用も発生しないことは大きなメリットですね。
もう一つの大きな特徴として、vShpere HAでは必ずしも専用のStandby 機を持つ必要がないことが挙げられます。
物理サーバ環境では、クラスター構成を組む為には、必ず１ノード以上のStandby機を設けることが必須の要件でした。
１ノード分の空きホストを作っておかなければ、障害時に系切り替えができない為です。
一方、仮想環境においては、上述のような構成が求められません。
仮想サーバ(ESXi)の物理的なCPU、メモリリソースに余裕さえあれば、障害が発生した際には、障害が発生したゲストOSが、 起動可能な仮想サーバを各ゲストOS単位で判定し、予め定められた障害時のポリシーに従い、 ゲストOSを各仮想サーバに振り分けて（移動させて）起動させることが可能です。
もちろん、Standby機を持っておく方が、より確実な耐障害性を持たせることが可能なのですが、 CPU、メモリのリソース設計さえ疎かにしなければ、Standby機の準備は不要となります。
vShpere HAの課題
一方で、商用クラスターウェアを使い慣れたお客様にとっては、vSphere HAを使用するにあたって、機能的な部分で不満が出てくる点があるかもしれません。
多くの商用クラスターウェア製品では、各サーバ毎で動作するミドルウェアなどのプロセス状態を判断し、致命的なプロセス障害が発生した際には、 自動的に同プロセスの再起動を試みる、もしくはフェールオーバを発生させ、Standby側に業務運用を切り替える・・・といったような形で、サービス継続を計る仕組みが組み込まれています。
残念ながら、vSphere HAには、ゲストOS毎での内部プロセス監視機能が組み込まれていません。
ネットワークからの切断やサーバ筐体の停止などの障害では、高速に系切り替えを実施できる反面、 上述のようなゲストOSレベルでのプロセス障害時の検出は標準機能として備わっていないのです。
（正確にはAPIとしての機能提供はされているのですが、サードベンダー製品との連動が必要です）
ただし、こうした不得手の部分を補うための、様々なソリューションが存在することは事実です。
例えばSynmantec Application HAという製品は、様々な仮想化プラットフォームのゲストOS上で動作し、 ゲストOSの区分がWindows Server 、Linux サーバの隔てを作ることなく、プロセス障害時のフェールオーバを実行することが可能となるわけです。
これまで、vSphere HAについて述べてきましたが、仮想環境上でクラスター環境を備えることは非常にハードルが低くなってきています。
仮想サーバ（ESXi）自体のメンテナンス性も向上するメリットもありますので、今後、仮想化システムを採用されようとするお客様は是非とも仮想環境のクラスター化をご検討いただければと思います。
.
