第 1 回 〜 第 3 回では、ActiveCluster 環境の構築についてご紹介しました。第 4 回となる今回は、ホストが ActiveCluster にアクセスした時の挙動についてご紹介します。
ActiveCluster 内部アーキテクチャ
ActiveCluster として Pod 内にボリュームを作成することで、その Pod を構成する両アレイにボリュームが作成され、それらの両ボリュームには同じシリアル番号が付与されます。これにより、ホストのマルチパスドライバから見れば両ボリュームに区別はなく、1 つのボリュームとして見えます。また、Pod 内のボリュームは、どちらのアレイの GUI/CLI から見ても 1 つのボリュームとして見えます。ストレージ管理者ですら、運用(バックアップ等)の際に、両アレイでそれぞれボリュームを持つことを意識する必要はありません。更に、両アレイのボリューム間の整合性は ActiveCluster が担保し、同期レプリケーションによりデータは完全に同期します。
![](https://blog.purestorage.com/wp-content/uploads/2018/04/iwamoto_activecluster_4_1-1024x494.jpg)
ユーザーは上記手順を意識する必要はありません。第3回の内容のとおり、GUI/CLI(例:purevol create –size 1t pod::vol)のいずれからでもワンクリックで Pod 内にボリュームを作成するだけで、ActiveCluster が全自動で上記手順を実行します。
書き込み処理
次に、ActiveCluster(Pod 内のボリューム)にホストが書き込みをした時の流れを見ていきましょう。
- ホストから Pod 内のある 1 つのボリュームに書き込みが発生
- そのボリュームにアクセスするための、ホスト〜アレイ間の FC/iSCSI 経路は等価であり、ホストのマルチパスドライバは両アレイの FC/iSCSI ポートをラウンドロビンで均一に使用
- アレイ A の FC/iSCSI ポート経由でアクセスとなった場合:ローカル(アレイ A)の NVRAM への書き込み要求と同時に、リモート(アレイ B)の NVRAM への書き込み要求を転送
アレイ B の FC/iSCSI ポート経由でアクセスとなった場合:ローカル(アレイ B)の NVRAM への書き込み要求と同時に、リモート(アレイ A)の NVRAM への書き込み要求を転送
- 両アレイの NVRAM に書き込みが完了した時点でホストに ACK を返す
- NVRAM 上の “dirty” なデータをインラインで重複排除、圧縮、暗号化して SSD に書き込み
― この処理は両アレイで独立して実行される(通常の非 ActiveCluster 構 成と同様)
![](https://blog.purestorage.com/wp-content/uploads/2018/04/iwamoto_activecluster_4_2-1024x540.jpg)
読み込み処理
次に、ActiveCluster にホストから読み込みをした時の流れを見てましょう。
- ホストから Pod 内のある 1 つのボリュームに読み込みが発生
- 読み込み時も書き込み時と同様、ホスト〜アレイ間の FC/iSCSI 経路は等価であり、ホストのマルチパスドライバは両アレイの FC/iSCSI ポートをラウンドロビンで均一に使用
- アレイ A の FC/iSCSI ポート経由でアクセスとなった場合:ローカル(アレイ A)の SSD からデータを読み込み
アレイ B の FC/iSCSI ポート経由でアクセスとなった場合:ローカル(アレイ B)の SSD からデータを読み込み
上記の流れのように、読み込み時は両アレイ間の通信は発生せず、ローカルのアレイで独立して完結します。そのため、アレイ 2 台分の読み込み性能を提供しながら、ActiveCluster による極めて高い可用性を実現することが可能となります。
![](https://blog.purestorage.com/wp-content/uploads/2018/04/iwamoto_activecluster_4_3-1024x540.jpg)
検証結果
ActiveCluster で負荷生成ツール “vdbench” を使用して 2 つの I/O ワークロードを同時に生成した時の GUI/CLI 出力を以下に示します。
ワークロード 1
- 対象ボリューム:Pod に属さない片アレイのボリューム
- I/O サイズ:8 KB
- 20,000 IOPS(読み込み 60%、書き込み 40%)
ワークロード 2
- 対象ボリューム:クラスタ化された Pod 内のボリューム
- I/O サイズ:8 KB
- 60,000 IOPS(読み込み 60%、書き込み 40%)
ActiveCluster は全てのボリュームをアクティブ/アクティブでクラスタ化するのではなく、Pod 単位で設定が可能です。そのため、今までの”Write” に対して “Mirrored Write” という性能情報が追加されました。”Mirrored Write” はその名のとおり、クラスタ化された Pod 内のボリュームに対する書き込みです。以下の図は、GUI から確認したアレイ A とアレイ B の性能情報(レイテンシ、IOPS)です。
![](https://blog.purestorage.com/wp-content/uploads/2018/04/iwamoto_activecluster_4_4-1024x478.png)
- Read IOPS:33,000 IOPS
- Write IOPS:8,000 IOPS
- Mirrored Write IOPS:24,000 IOPS
![](https://blog.purestorage.com/wp-content/uploads/2018/04/iwamoto_activecluster_4_5-1024x478.png)
- Read IOPS:15,000 IOPS
- Write IOPS: 0 IOPS
- Mirrored Write IOPS:24,000 IOPS
ワークロード 1 の Pod に属さない片アレイのボリュームへの読み書きは当然、担当するアレイ A のみ性能情報が表示されます。また、書き込みは “Write” として表示されます。一方、ワークロード 2 のクラスタ化された Pod 内のボリュームへの読み書きは両アレイで表示されます。ホストからの 24,000 IOPS 分(60,000 IOPS x 50%)の書き込みは両アレイに分散されますが、インターコネクト(レプリケーションネットワーク)を介してもう一方のアレイに同期して書き込む必要があります。その結果、両アレイそれぞれ 24,000 IOPS の “Mirrored Write” として表示されます。読み込みは前述のとおり、両アレイ間で通信することなく、ローカルのアレイで独立して完結します。そのため、通常の構成(Pod に属さない片アレイのボリューム)と同様に “read” として表示されます。