ActiveCluster の挙動

第 1 回 〜 第 3 回では、ActiveCluster 環境の構築についてご紹介しました。第 4 回となる今回は、ホストが ActiveCluster にアクセスした時の挙動についてご紹介します。


第 1 回 〜 第 3 回では、ActiveCluster 環境の構築についてご紹介しました。第 4 回となる今回は、ホストが ActiveCluster にアクセスした時の挙動についてご紹介します。

ActiveCluster 内部アーキテクチャ

ActiveCluster として Pod 内にボリュームを作成することで、その Pod を構成する両アレイにボリュームが作成され、それらの両ボリュームには同じシリアル番号が付与されます。これにより、ホストのマルチパスドライバから見れば両ボリュームに区別はなく、1 つのボリュームとして見えます。また、Pod 内のボリュームは、どちらのアレイの GUI/CLI から見ても 1 つのボリュームとして見えます。ストレージ管理者ですら、運用(バックアップ等)の際に、両アレイでそれぞれボリュームを持つことを意識する必要はありません。更に、両アレイのボリューム間の整合性は ActiveCluster が担保し、同期レプリケーションによりデータは完全に同期します。

図1 – ActiveCluster の内部アーキテクチャ

ユーザーは上記手順を意識する必要はありません。第3回の内容のとおり、GUI/CLI(例:purevol create –size 1t pod::vol)のいずれからでもワンクリックで Pod 内にボリュームを作成するだけで、ActiveCluster が全自動で上記手順を実行します。

書き込み処理

次に、ActiveCluster(Pod 内のボリューム)にホストが書き込みをした時の流れを見ていきましょう。

  1. ホストから Pod 内のある 1 つのボリュームに書き込みが発生
  2. そのボリュームにアクセスするための、ホスト〜アレイ間の FC/iSCSI 経路は等価であり、ホストのマルチパスドライバは両アレイの FC/iSCSI ポートをラウンドロビンで均一に使用
  3. アレイ A の FC/iSCSI ポート経由でアクセスとなった場合:ローカル(アレイ A)の NVRAM への書き込み要求と同時に、リモート(アレイ B)の NVRAM への書き込み要求を転送
    アレイ B の FC/iSCSI ポート経由でアクセスとなった場合:ローカル(アレイ B)の NVRAM への書き込み要求と同時に、リモート(アレイ A)の NVRAM への書き込み要求を転送
  1. 両アレイの NVRAM に書き込みが完了した時点でホストに ACK を返す
  2. NVRAM 上の “dirty” なデータをインラインで重複排除、圧縮、暗号化して SSD に書き込み
    ― この処理は両アレイで独立して実行される(通常の非 ActiveCluster 構 成と同様)
図2 – 書き込み処理の流れ

読み込み処理

次に、ActiveCluster にホストから読み込みをした時の流れを見てましょう。

  1. ホストから Pod 内のある 1 つのボリュームに読み込みが発生
  2. 読み込み時も書き込み時と同様、ホスト〜アレイ間の FC/iSCSI 経路は等価であり、ホストのマルチパスドライバは両アレイの FC/iSCSI ポートをラウンドロビンで均一に使用
  3. アレイ A の FC/iSCSI ポート経由でアクセスとなった場合:ローカル(アレイ A)の SSD からデータを読み込み
    アレイ B の FC/iSCSI ポート経由でアクセスとなった場合:ローカル(アレイ B)の SSD からデータを読み込み

上記の流れのように、読み込み時は両アレイ間の通信は発生せず、ローカルのアレイで独立して完結します。そのため、アレイ 2 台分の読み込み性能を提供しながら、ActiveCluster による極めて高い可用性を実現することが可能となります。

図3 – 読み込み処理の流れ

検証結果

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)です。

図4 – アレイ A の性能情報
  • Read IOPS:33,000 IOPS
  • Write IOPS:8,000 IOPS
  • Mirrored Write IOPS:24,000 IOPS
図5 – アレイ B の性能情報
  • 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” として表示されます。

参考情報