前回の第 4 回では、ホストが ActiveCluster にアクセスした時の挙動についてご紹介しました。今回は、ActiveCluster 環境で障害が発生した時の挙動と、そこから復旧した時の挙動をご紹介します。
まずは、ActiveCluster の障害時の挙動です。どちらか一方のアレイまたはインターコネクト（レプリケーションネットワーク）で障害が発生した場合は、一定時間の経過後に、各アレイは Mediator との通信を開始し、どちらのアレイを正（オンライン）としてサービスを継続するか判断します。ActiveCluster では、この仕組みを「Mediator レース」と言います。Mediator レースの結果、先に通信が成立したアレイをオンライン、後から通信が成立した、または通信が成立しなかったアレイをオフラインとします。また、Mediator レースはアレイ単位ではなく、Pod 単位で行われます。そのため、Mediator レースの結果は別 Pod や Pod 外のローカルなボリュームに全く影響しません。
Mediator は、障害時のアレイからの通信を待つだけです。Mediator 自身は、アレイを監視したり、スプリットブレイン時にオンラインとするアレイを判断したりしません。Mediator との通信や、スプリットブレイン時にオンラインとするアレイの判断は、あくまでもアレイ自身に委ねられます。Mediator は「パッシブ（passive）」という種類の仕組みであるため、ActiveCluster 構成であっても、通常のシングル構成と比較した運用監視の追加工数が最小化されます。特に、Pure1 Cloud Mediator（CloudAssist 上のMediator）選択時は、Mediator 自身の構築、運用、可用性の担保の全てがピュア・ストレージの CloudAssist で行われます。On-Premises Mediator（vSphere 上の Mediator VM）選択時は、その VM は vSphere HA 等で Mediator の可用性を担保することが強く推奨されています。
ActiveCluster の各コンポーネントの障害時における、ホストからのアクセス可否を以下に示します。
次に、ActiveCluster の復旧時の挙動です。ActiveCluster のシンプルさは復旧時も同様で、アレイが復旧を検知すると全自動でアクティブ/アクティブの構成までリカバリします。ストレージ管理者による GUI/CLI によるオペレーションは一切不要です。復旧を検知した時点では、両アレイ間でデータの差分が発生している状態です。差分を解消してデータを完全に同期させるために、オンラインのアレイからオフラインのアレイに非同期レプリケーションを実行し、差分の解消を開始します。この非同期レプリケーションの実行中に、いくつかのチェックポイントを作ります（下図の snap）。そして、最後のチェックポイントにおける差分データをオフラインのアレイに適用開始すると同時に、リアルタイムでホストから要求されている書き込みも開始します。そして、全ての差分データを適用し終えたタイミングで、オフラインのアレイはオンラインとなり、ActiveCluster 構成にリカバリされます。驚くべきは、全て全自動でリカバリが行われる点です。その間、非同期レプリケーションから ActiveCluster に移行するタイミングであっても、I/O 待機すらありません。
ActiveCluster に負荷生成ツール「vdbench」を使用して 10 万 IOPs の I/O ワークロードを生成し、障害から復旧までを検証した結果を以下に示します。
 |
 |
