こんにちは。SB C&Sでプリセールスエンジニアをしている笠原です。

データを安全に保管/管理するストレージにおいても、あらゆる故障や災害から筐体内のデータを保護することには限界があります。そのため、データ保護の考え方として筐体外にデータを複製して保管することも重要となっています。

今回の記事では、ONTAPのレプリケーション機能である"SnapMirror"について紹介します。

レプリケーションについて

レプリケーションとは、「データの複製」を意味する言葉で、バックアップと同じくデータを保護するための機能として一般的に利用されています。同一ネットワーク内または、遠隔地に本番機と同等のストレージを用意してデータを複製することで、バックアップ目的や災害対策として利用することが可能です。

本記事では、NetApp社の用語に沿って複製元となるストレージをソース、複製先となるストレージをデスティネーションと呼びます。 

一般的なバックアップとの違いとして、バックアップでは本番機が故障した場合、バックアップデータを本番機へリストアしてから運用を再開しますが、レプリケーションではデスティネーション側のストレージにソース側と同じ設定をすることで、2つのストレージシステムを全く同じ状態にすることが可能なため、デスティネーション側のストレージによって運用を再開することも可能です。

そのため、復旧にかかる時間を最小限に抑えたい場合に利用されます。

ソースとデスティネーションで同じデータを持つといっても、ソースのデータが更新されるたびにデスティネーション側へ同期する場合と、一定時間ごとに複製する場合があります。前者を同期レプリケーション、後者を非同期レプリケーションと呼びます。

同期レプリケーションは故障時にも最新の状態で復旧できるというメリットがあり、非同期レプリケーションはネットワーク要件が比較的緩く、ストレージ処理の負荷が軽くなるというメリットがあります。

SnapMirrorとは

レプリケーションの仕組みにも様々ありますが、ONTAPではSnapMirrorという技術を利用してレプリケーションを実現しています。

SnapMirrorはONTAPのSnapshotの技術を利用したレプリケーションで、前回複製した時と比べて変更があったデータのみを転送することによって利用するネットワーク帯域を抑え、高速にレプリケーションすることができます。

SnapMirrorによるレプリケーションは同期または非同期で行うことができます。SnapMirrorの同期レプリケーションにはデスティネーション側への複製が完了してからクライアントにAckを返すモードとデスティネーション側へ複製が完了しなくてもAckを返すモードがあります。

また、NetAppがリリースしている各ONTAPアプライアンスへレプリケーションすることができるため、データ保護として利用するだけではなく、オンプレミスで稼働しているFAS/AFFから既存のVMware環境に構築したONTAP selectへレプリケーションすることにより、レプリケーション先のストレージコストを抑えることや、Cloud Volumes ONTAPへレプリケーションすることにより、クラウド上にデータを移行してワークロードのクラウドシフトに活用することができます。

SnapMirrorの構成

SnapMirrorを構成する上でONTAPのクラスタ(1つのストレージシステムとしての単位)をまずはピアリングします。

ONTAP内にクラスタ間LIFという役割のLIF(論理インターフェース)を作成し、ピアリングしたい2つのクラスタをネットワーク接続します。

次に双方のクラスタで作成したSVM(仮想ストレージ)をピアリング設定し、ソースボリュームをデスティネーションボリュームへ複製します。

ボリューム単位で転送設定をするため、ストレージシステム自体がソースやデスティネーションと決められるわけではありません。そのため、クラスタＢで作成したボリュームをクラスタＡへ転送することもでき、クラスタＢのデスティネーションボリュームをソースとしてまた別のデスティネーションボリュームへ転送することもできます。

なお、通常のSnapMirrorでレプリケーションできるのはボリュームのみであり、QtreeやLIF、クライアントへの接続はソース、デスティネーションにてそれぞれ設定します。

SnapMirrorのデータ転送方法

SnapMirrorの優れた転送方法を紹介する前に、その元となっているSnapshotについておさらいします。

SnapshotはONTAPのデータ保護機能の1つで、ONTAPのファイルシステムであるWAFL（Write Anywhere File Layout）により、高速スナップショットを可能にした独自アーキテクチャとなっています。

WAFLによってストレージに書き込まれるデータには大きく分けて「実データ」と、実データの位置情報となる「メタデータ」の2種類が存在しています。実データは上書きされることがなく、ボリューム内のデータを更新する際は変更された実データが新規ブロックに書き込まれ、メタデータが保有するブロックの位置情報を更新します。更新が完了すると変更元の実データブロックは消去されます。

Snapshotを取得した場合、取得する時点でのメタデータをSnapshotとして保持し、そのメタデータがポイントするブロックを消去しないようにします。Snapshot取得後も本体ボリュームの挙動は変わらず、変更されたデータは新規ブロックに書き込まれ、メタデータの情報が更新されます。

 

SnapMirrorでは、転送する時点でのSnapshotを取得し、そのデータをデスティネーションボリュームへ転送します。初回はすべてのデータを転送しますが、2回目以降は既に転送したブロックは転送せず、新規で追加されたブロックのみを転送します。

これにより、利用する帯域幅を最小限に抑え、高速にレプリケーションを完了することができます。

デスティネーションボリュームは書き込み不可で、運用する際にはSnapMirror関係を解除します。

障害時のデータ復旧方法

本番機にあったソースボリュームが損失し、デスティネーションボリュームの状態を本番機へリストアしたい場合は、本番機からリストアしたい時点のスナップショットを指定し、リストアを実行することができます。

災害などによりソースボリュームのあるメインサイトのクラスタ自体が損失した場合には、デスティネーションボリュームをソースとして復旧したクラスタへ再度SnapMirrorを行い、元の状態へとリストアすることができます。

メインサイトのデータ損失時にDRサイト側のクラスタを本番機として運用することもできます。

流れとしては、ソースボリュームとデスティネーションボリュームのSnapMirror関係を解除し、デスティネーションボリュームだったボリュームを書き込み可能にします。その後、クライアントへの共有設定を行います。ストレージ間でデータ転送を伴わないため、即時復旧することができます。

メインサイトのサーバーなどがダウンしてDR側でシステムを運用することになった際、双方のONTAPストレージが正常であればソースボリュームとデスティネーションボリュームのSnapMirror関係を逆にして運用することができます。運用再開の際はストレージ間でデータ転送を伴わないため、即時復旧することができ、既に双方にあるデータブロックは再送信されないため、データの同期もすぐに完了します。

SnapMirrorのポリシー設定

SnapMirrorはボリューム関係を設定する際に保護ポリシーを選択します。デフォルトのポリシーを利用することもできますが、手動で設定することもできます。

保護ポリシーの設定では、タイプ、転送スケジュール、ルール(保持する世代数など)を設定することができます。

・タイプ

同期レプリケーションにするか、非同期レプリケーションにするかという設定ができます。以前はレプリケーション目的でソースに存在するスナップショットのみをデスティネーションで保持するSnapMirrorと、アーカイブ目的でソースよりも多くのスナップショットをデスティネーションで保持するSnapVaultにタイプが分かれていましたが、ONTAP 9.12.1現在では保持設定はルールの項目で設定します。

・転送スケジュール

非同期レプリケーションでは転送するスケジュールについてポリシーを設定します。Intervalという設定方法で間隔として○○分、○○時間ごとのように設定するか、Cronという設定方法で定期的に転送する時間や曜日を指定して行います。(最小1分間隔で取得可能)

・ルール

ソース側で取得したどのスナップショットを送信し、何世代分保持するか、また、デスティネーション側でのみ追加でスナップショットを取得するかという設定ができます。(保持できるスナップショットの最大はソース1023個、デスティネーション1019個)

バージョン制限について

SnapMirrorはソースとデスティネーションでONTAPのバージョンが異なっていても利用することができます。

9.6以降で互換性のマトリックスを抜粋して掲載しますが、それ以前の情報はドキュメントをご確認ください。

https://docs.netapp.com/ja-jp/ontap/data-protection/compatible-ontap-versions-snapmirror-concept.html

SnapMirrorのタイプとして以前はDPタイプ(ONTAPのバージョン互換が厳しい)とXDP(ONTAPのバージョン互換が緩い)タイプがありましたが、ONTAP 9.12.1にてDPタイプは廃止されています。

まとめ

• レプリケーションはデータ保護を目的として、復旧にかかる時間を最小限にしたい場合に有効
• ONTAPストレージ間ではSnapMirrorを利用してレプリケーションを実現
• SnapMirrorではボリューム単位でレプリケーション
• SnapMirrorは前回レプリケーションした時からの増分のブロックのみを転送することで効率よくレプリケーションを実現
• 復旧の際にはデスティネーション側で運用することや逆方向へのレプリケーションをすることが可能
• ポリシーを設定してレプリケーションしたいボリュームに適用
• ソースとデスティネーションのONTAPバージョンが異なっていてもレプリケーション可能

昨年行われたNetApp Insight 2022にて、NetApp社はONTAPによってオンプレミスとクラウドで同じようにデータを管理し、移動も簡単に行えるインフラを実現することができると強調していました。SnapMirrorはデータ保護のためのレプリケーションにとどまらず、このビジョンを実現させるための中核技術となっています。

次回はSnapMirrorの設定手順を紹介したいと思います。