はじめに
2017 年 12 月 15 日に Pure Storage FlashArray（以降、FlashArray）のストレージ OS である Purity//FA 5.0.0 がリリースされました。そこで今回は、Purity//FA 5.0.0 で実装された注目の新機能である ActiveCluster ついてご紹介します。
ActiveCluster はその名のとおり、FlashArray でクラスタを構成する機能です。2 台の FlashArray を Sync Replication で同期し、アクティブ/アクティブのクラスタを構成、およびホストに対して透過的なフェイルオーバーを実現します。
図 1 – ActiveCluster とは
図 1 に示すように、追加のハードウェアとライセンスは不要なため、追加コストなしでアクティブ/アクティブのクラスタを構成できます。また、ストレージ OS「Purity//FA」を 5.0.0 以降にアップグレードするだけで、既存の FlashArray をオンラインで ActiveCluster 構成にすることも可能です。
構成するための要件は非常にシンプルで、基本的には両アレイ間のラウンドトリップタイム（RTT）が 5 ms 以内であれば構成可能です（制限事項の詳細については、ピュア・ストレージ・ジャパンにお問い合わせください）。また、FlashArray は標準でレプリケーション用の 10GbE ポートを搭載しており、そのポートにアサインした IP 間の ping が 5 ms 以内で返ってくればよいことになります。FlashArray の CLI では ping コマンドを提供しており、例えば以下のように確認することが可能です。
pureuser@Japan-Lab-AC-01> purenetwork ping –count 5 –interface eth2 10.0.0.64
PING 10.0.0.64 (10.0.0.64) from 10.0.0.60 eth2: 56(84) bytes of data.
64 bytes from 10.0.0.64: icmp_seq=1 ttl=64 time=0.104 ms
64 bytes from 10.0.0.64: icmp_seq=2 ttl=64 time=0.148 ms
64 bytes from 10.0.0.64: icmp_seq=3 ttl=64 time=0.113 ms
64 bytes from 10.0.0.64: icmp_seq=4 ttl=64 time=0.110 ms
64 bytes from 10.0.0.64: icmp_seq=5 ttl=64 time=0.100 ms
アレイ A（Japan-Lab-AC-01）のレプリケーションポート（eth2）からアレイ B のレプリケーション IP（10.0.0.64）にping した結果、約 0.1 ms で返ってきているため、RTT 5 ms 以内の要件を満たしていることがわかります。
次に、ActiveCluster を構成するコンポーネントを見てみましょう。ActiveCluster は、クラスタ化されたアクティブ/アクティブ構成のアレイ（ハードウェア）の他、大きく分けて 2 つのコンポーネントから構成されています。
図2 – ActiveCluster を構成するコンポーネント
Pod
ActiveCluter では Pod という単位でオブジェクト（ボリューム等）を管理します。Pod 内のボリューム（以降、LUN）は自動的に両アレイに同期され、ホストに対してアクティブ/アクティブで提供されます。
例えば、ホストから ActiveCluter の LUN に書き込みが発生した場合の流れを見てみましょう。ホストから見ると、特定の LUN ID で 1 つの LUN が見ているだけで、アレイの位置は関係ありません。この LUN に書き込みをすると、ホストの MPIO は両アレイの FC / iSCSI ポートに対して均等に IO します。その後、アレイ A に届いた書き込みは、インターコネクト（レプリケーションネットワーク）を介してアレイ B の書き込みキャッシュ（NVRAM）にも書き込んだ後、ホストに書き込み完了の ACK を返します。同様に、アレイ B に届いた書き込みは、インターコネクトを介してアレイ A の書き込みキャッシュ（NVRAM）に書き込んだ後、ホストに書き込み完了の ACK を返します。
Mediator
ActiveCluster では、クラスタ特有の問題となるスプリットブレイン（インターコネクト障害によりノード間でデータの同期が不可能になり、結果的にデータ不整合が発生する可能性がある状況）を防止するために Mediator という仕組みを使用します。クラスタ機能を提供する各社によるスプリットブレイン防止の仕組みは複雑なプロセスなものが多いため、クラスタ機能の構築や運用の難易度が高く、多くの工数を必要とします。また、その仕組みの目的が「スプリットブレインの防止」であるため、クラスタを構成するコンポーネントとは別の障害グループ上（第3のサイト）に構築する必要がある点も頭を悩ませます。
Pure Storage では、製品をより高い品質でサポートするために CloudAssist という仕組みを提供しています。Pure Storage の製品にはログを定期的にサポート環境（CloudAssist）に送信する設定があり、サポートエンジニアはリアルタイムでアレイの状況を把握できるため、プロアクティブな対応が可能です。また、CloudAssist に接続された数千のアレイから送信されるログを機械学習により解析することで、予測型サポートを提供しています。予測型サポートは、潜在的な問題の事前解決や、予防的な保守を実現します。
ActiveCluster では、スプリットブレインをシンプルな仕組みで防止するために CloudAssist 上に Mediator を配置します（その他、CloudAssist に接続できない環境向けに、VMware ESXi 上で稼働する Mediator を OVF ファイルとして提供しています）。ユーザーは、ActiveCluster で使用する FlashArray を通常どおり CloudAssist に接続するだけです。CloudAssist 上の Mediator は Pure Storage により運用されるため、ユーザーは、その仕組みおよび第3のサイトの構築と運用から完全に解放されます。
次回のブログでは、ActiveCluster 構築の流れや、より詳細な動作についてご紹介していきます。
