ストレージ

Everpure(旧:Pure Storage)FlashArray ActiveDRの仕様

Everpure(旧:Pure Storage)FlashArray(FA)製品のActiveDRについて、動作仕様をご紹介します。

データのバックアップ

FA製品のバックアップは、単純で簡単に操作でき、サービスや運用への負荷なく、安全にデータを保護することが可能です。FAのバックアップの手段としては、下記の種類があります。

Snapshotやそれらを管理・運用できるProtection Group、バックアップ手段のうち、Async Replication、ActiveClusterについてご説明したブログはこちらとなります。

参考:Pure Storage FlashArrayのSnapshotについて

参考:Pure Storage FlashArrayのProtection Group

参考:Pure Storage FlashArray Async Replication(非同期レプリケーション)の仕様と設定方法

参考:Pure Storage FlashArray ActiveClusterの動作仕様

今回はこのうちActiveDRに焦点を当てて記載します。

ActiveDR

ActiveDRは、FAの2アレイ間を半同期することで、Active/Standbyのクラスタを構成し、ゼロに近いRPO(目標復旧時点:Recovery Point Objective)を実現できるソリューションです。ActiveDRは、Volumeを半同期的に別のFAに常に送信し続け、送信先のFAでそのままVolumeとして利用できるレプリケーション機能です。これまでにご紹介した、Volumeを完全同期するActiveClusterと、VolumeのSnapshotを定期的に送信するAsync Replicationの、中間のようなDR(災害復旧:Disaster Recovery)対策となります。

ActiveDRは、データのRead/Writeを実施するFA側のVolumeの書き込みをトラッキングし、必要なデータをRead OnlyとなるFA側のVolumeに送信し続けることで、データの同期が実施されるしくみです。データのRead/Writeを実施するSource Array側に障害が発生した場合には、即時的にRead Onlyだったデータ送信先のTarget Array側をRead/Writeが可能な状態に切り替えることで、ゼロに近いRPOが実現できます。

ActiveClusterでは、両アレイ間のRTT(Round Trip Time)が11ms以内という要件がありますが、ActiveDRではRTTの要件がなく、例えば北海道と沖縄間など、FA間の物理的な距離が遠くても運用できるDR対策となります。通常のVolumeからActiveDRへの移行もオンラインで実施でき、ライセンスフリーで利用可能な機能となります。

ActiveDRの動作仕様

ActiveDRの動作仕様を図に示します。

2台のFAのうち、ホストとのRead/Writeが可能なPod(Purity Operation Domain)を持つFAをSource Array、データ送信先のFAをTarget Arrayと表現します。

ActiveDRは、2つのFAを、レプリケーション用のネットワークで接続し、Podと呼ばれるVolumeを管理するコンテナドメインを使用します。Source Array上のPodの中にあるVolumeを、Target Arrayにレプリケーションすることで、Target Array側にも同一データのVolumeを持つことができます。なお、このレプリケーションでは、圧縮されたデータが転送されるため、データ転送量を軽減できます。

データの送信方向は、Podの設定で決めることができます。送り元となるPodを「Promoted」、送り先となるPodを「Demoted」と設定することで、Promoted → Demoted方向にデータが送付されます。設定はGUI(Graphical User Interface)やCLI(Command Line Interface)で簡単に実施できます。PromotedのPodのVolumeは、Read/Writeが可能ですが、DemotedのPodのVolumeはRead Onlyとなります。仮に、Source Array側に障害が発生して、もともとPromotedだったPodのVolumeでデータのやり取りができなくなった時は、Target Array側で、もともとDemotedだったPodをPromotedに設定変更することで、もともとRead Onlyで書き込みできなかったPodのVolumeに対して、書き込みができるようになります。

ネットワーク設定

ActiveDRに必要なネットワーク設定は、管理ネットワークの設定とレプリケーションネットワークの設定です。FlashArrayのレプリケーションには、専用のポートを使用します。X、Cモデルでは、標準で搭載されている、各CTのETH2と3ポートが利用可能です。ポート構成については、下記のブログをご確認ください。

参考:Pure Storage FlashArray XR5シリーズの詳細

それぞれのポートにIPアドレスを設定します。そのため、レプリケーションを使用する場合には、1アレイ当たり4つのIPアドレスが必要です。ポートのMTU(Maximum Transmission Unit)はデフォルトの1500が推奨です。また、ETHスイッチを介して接続することが必要となります(アレイ間を直接接続する構成は非サポートとなります)。通信要件として必要となるポート番号は、管理ポートが443、レプリケーションポートが8117です。なお、仕様上、レプリケーション通信そのものはFAのPrimary CT(コントローラ:Controller)のみで行われます。これは、他のレプリケーション機能であるActiveClusterやAsync Replicationでも同様です。

下記に、ActiveDR構成での、ネットワークの構成例を記載します。

レプリケーションのLAG

ActiveDRは、冒頭に触れたように、遠距離に設置されているFA間でDR対策を実施するようなユースケースで使用されます。ActiveDRにおいて、アレイ間でデータ送信にかかる時間をLAGと表現しますが、このLAGが数秒程度であることが理想的です。データ転送量が多い場合や、FA自身の負荷が大きい場合、ネットワークの障害が発生すると、このLAGが大きくなり、その分RPOの時間としても長くなってしまいます。

※FAのレプリケーションはバックグラウンドで動作し、Source Array側のHostとの通信を優先して処理するため、FA自身の負荷が高いとその分レプリケーションに割く労力が減るしくみになります

ですが、LAGについてもFAのOS(Operating System)である、Purity OSにて管理されており、LAGが大きくなると、これまで半同期的にPodを転送(Continuous Replication)していた形から、自動的にSnapshotベースの転送(Periodic Replication)に切り替えます。データ量の少ないSnapshotを使用して、一気に差分ブロックのデータ転送を行い、LAGを縮めることで、通常の運用に戻すように動作します。

その他の仕様や注意点

・ アレイ間でのPurityの互換性がある必要性があり、ActiveDRでは同一Purityバージョンでの稼働を推奨します。

・ FAのホスト設定にて、接続先のホストのOS(Operating System)にそれぞれ一致するPersonalityを設定する必要があります。(Windows OSなど一部Personality設定項目のないOSがありますが、その場合は設定不要です)

最後に

今回はFA製品のActiveDRについて概要と設定方法を記載しました。今回のご紹介にて、既存で利用中のFAをActiveDRで構築したい、とご検討いただける場合、当社へお問い合わせください。今後のブログにて、CloudSnapと呼ばれるバックアップ機能や、ActiveDRの障害時の動作などについて記載予定です。

 

※ Everpure、Pure Storage、および本ページに記載されている製品名・サービス名は、Everpure, Inc. の商標または登録商標です。

この記事に関連する製品・サービス

この記事に関連する記事