「HPE SimpliVity」とサイオステクノロジー「LifeKeeper」検証レポート

HCIをリードする「HPE SimpliVity」で極めて高い可用性を実現
横河レンタ・リースが実機検証した「LifeKeeper」との組み合わせ

5つの「障害シナリオ」を想定したLifeKeeperの実機検証

　その実機テストの検証環境は下図に示すとおり。2ノードのHPE SimpliVityを接続した環境を用意し、各ノードのハイパーバイザー上でCentOSを稼働させ、さらにその上で2つのPostgreSQLを動かしている。1つのPostgreSQLは、共有ディスクとなる仮想ディスク（VMDK）にアクセス。もう1つは個別のVMDKにアクセスし、待機系ノードとDataKeeperで内容を同期させている。この2種類の環境を用意することで、共有ディスク構成とデータレプリケーション構成の両方の検証が行われたのである。
なお共有ディスク構成で通信障害が発生した場合には、稼働系ノードが正常稼働しているのにもかかわらず待機系ノードが立ち上がってしまう「スプリットブレイン」という現象が生じる可能性があるため、これを防止するために「Quorumチェック/Witnessサーバー」も動かしている。

検証項目（障害シナリオ）と結果は以下の通りである。

１．コミュニケーションパス切断

稼働系ノードで稼働中のアプリケーションに障害が発生し、クライアントからのリクエストに応答しなくなったという障害シナリオ。LifeKeeperはまず稼働系ノードでのアプリケーション再起動を試み、それができなかった場合には待機系ノードへとフェイルオーバーする。

検証結果：問題なく動作。

２．IPリソース障害

稼働系ノードでネットワーク障害が発生し、IPでの通信が行えなくなったという障害シナリオ。待機系ノードから稼働系ノードの状態はチェックできるため、自動的に待機系ノードへとフェイルオーバーされる。

検証結果：問題なく動作。

「漏れのない」対策を検討する上で意義のある検証結果

３．アプリケーション障害

稼働系ノードで稼働中のアプリケーションに障害が発生し、クライアントからのリクエストに応答しなくなったという障害シナリオ。LifeKeeperはまず稼働系ノードでのアプリケーション再起動を試み、それができなかった場合には待機系ノードへとフェイルオーバーする。

検証結果：問題なく動作。

４．ノード障害

稼働系ノードのゲストOSがシャットダウンされるという障害シナリオ。自動的に待機系ノードへとフェイルオーバーされる。

検証結果：問題なく動作。

５．ESXiホスト障害

稼働系ノードのVMware ESXi（ハイパーバイザー）が停止するという障害シナリオ。この場合も自動的に待機系ノードへとフェイルオーバーされる。

検証結果：問題なく動作。

　「いずれの障害シナリオでも、クライアントはサーバー側の障害を意識することなく、業務を継続できました」と高橋。また共有ディスク型、データレプリケーション型のいずれでも、期待通りに動作したという。
この検証内容を受け、國政氏は次のように語っている。
「仮想環境で高可用性を実現するための鍵は、大きく3点あります。第1は『漏れのない』対策を実施すること。仮想化環境ではサーバーハードウェア、ハイパーバイザー、ゲストOS、ミドルウェア、アプリケーションなど、物理環境に比べてシステム構成要素が多くなるため、漏れが発生しやすくなるからです。第2は『迅速性』であり、サービス復旧までにかかる時間をできる限り短縮することです。そして第3が、実際の対策が『適切であるか』を評価することです。横河レンタ・リースが実施した今回の検証は、多様な障害シナリオを想定した網羅的なものであり、いずれも自動的なフェイルオーバーによって迅速なサービス復旧が可能なことを示しているという点で、大きな意義を持つものだと考えています」。
HPE SimpliVityのようなHCIインフラは多数の仮想マシンを手軽に動かせるため、多様なサービスがその上に乗る可能性が高くなる。停止することが許されないサービスが動くことも珍しくなくなっていくだろう。このようなサービスを安全に動かし続けるには、インフラレベルだけではなく、アプリケーションレベルの高可用性確保も不可欠だ。すでにHCIを導入しているケースはもちろんのこと、現在HCI導入を検討している場合でも、サービス停止で痛い目を見る前で、LifeKeeperのような仕組みの導入を検討すべきだといえるだろう。