NetApp Tech OnTap
     

NetAppの統合データプロテクション
最適なデータ保護ソリューションを選択する方法

NetApp®ストレージの優れたメリットは、お客様の重要なデータを保護する機能のすべてが、NetAppのハードウェアとData ONTAP®によって緊密に統合されているという点にあります。多くの場合、ライセンスキーを1つ取得するだけで利用でき、 機能を追加するために、専用のアプライアンスを購入したり複雑なソフトウェア・インストールを実施する必要はありません。また、組み込みの管理機能を、NetAppのすべてのデータ保護ソリューションで活用できます。

従来のデータ保護アプローチは、複雑化とコストの増大を招きます。

図1) 従来のデータ保護アプローチは、複雑化とコストの増大を招きます。

NetAppの統合データプロテクションの基礎については、過去のTech OnTapの記事で詳しく紹介していますので、ぜひご参照ください。本稿では、NetAppの複製テクノロジについて、深く掘り下げてご説明していきます。NetAppデータ保護の重要な要素であるVolume SnapMirror®、qtree SnapMirror、SnapVault®、MetroClusterといったソリューションのほとんどは、ミラーリング技術か複製技術を使用しています。こうした技術の仕組みと相違点を把握すれば、最適なデータ保護戦略を、はるかに簡単に選択できるようになるでしょう。この記事では、最初に各種テクノロジについて説明します。その後、御社のニーズに合った最適な選択肢を選ぶ方法について、いくつかアドバイスを紹介します。

NetAppの複製オプション

Tech OnTapでは、これまでSnapMirror、SnapVault、MetroClusterについて、何年にもわたり、非常に多くの特集記事を掲載してきました。しかし、私が知る限り、こうした製品の主要機能や、重要な相違点の一部は、まだ特集記事のテーマとして取り上げられていないようです。ではまずSnapMirrorについて、続いてほかの2つのテクノロジをSnapMirrorに関連づけて説明します (SnapMirrorの説明が少々長くなりますので驚かれるかと思いますが、 SnapVaultとMetroClusterの説明は手短にまとめますので、ご心配は無用です)。また、比較参照用の表もいくつか掲載しますので、疑問点の解消にぜひお役立てください。

SnapMirror
SnapMirrorは、元々ディザスタリカバリー(災害復旧)用のミラーをリモートサイトで作成することを目的とした機能です。これについては、おそらく皆さんがご存知でしょう。しかし、SnapMirrorに2つの機能モードがあることは、あまり知られていません。

Volume SnapMirrorは、物理ブロックレベルで動作し、 ボリューム全体のコンテンツとボリュームの全属性を、ソース(プライマリ)ボリュームからターゲット(セカンダリ)ボリュームへ丸ごと複製する機能です。そのため、ターゲット側のストレージシステムでは、ソース側と同じバージョンか、それ以降のバージョンのData ONTAPを使用しなければなりません。また、プライマリシステムで重複排除機能やNetAppデータ圧縮機能(Data ONTAP 8.0.1にて追加)を実行している場合は、受信側のボリュームでも重複排除の効果がそのまま継承されます。これは、ボリュームがまったく同様の状態で複製されるためです。そのため、WANで使用される帯域幅も同様に削減されます。

qtree SnapMirrorは、個々のqtreeを複製する機能です。qtreeはボリュームのサブセットであり、qtree SnapMirrorは論理レベルで動作します。しかし、qtreeを丸ごと複製することはできません。ボリュームレベルのqtree用のブックキーピング情報の一部が、ターゲットシステムで無効となってしまうためです。

qtree SnapMirrorでは、複製が論理レベルで行われるため、Volume SnapMirrorと比べると、若干ながら重要な違いがあります。まず、qtree SnapMirrorでは重複排除の効果が継承されません。ここでも、ソースとターゲットの関係を思い浮かべながら考えていただくと、分かりやすいと思います。ソース側のqtreeには、重複排除済みのブロックを含めることができます。この重複排除済みブロックとは、実際にはqtreeの外部にあるブロックポインタのことなので、 このブロックは、当然ながらターゲット側には複製されません。したがって、ブロックはポインタとしてでなく、qtreeと一緒に複製する必要があります。このように使用した場合、qtree SnapMirrorは、Volume SnapMirrorに比べて、ネットワークと容量の効率が低いといえます。

qtree SnapMirrorのデフォルト設定では、最新のSnapshotコピーのみが複製されます。そのため、保管されるSnapshotコピーの数は、ソースサイト、ターゲットサイトで異なります (Volume SnapMirrorでは、ソースとターゲットに同じSnapshotコピーが保管されます)。qtree SnapMirrorは、複製の更新を行うのに必要な、共通のSnapshotコピーを一組のみ保管します。言い換えれば、qtree SnapMirrorには、スナップショット保持機能がないということです。

SnapMirrorでは、どちらの機能モードでも、まずベースラインコピーが作成されます。ベースラインコピーとは、ボリューム内、qtree内のすべてのデータをソースからターゲットへと複製したものです。ベースラインコピーが作成された後は、定期的に複製処理が行われます。Volume SnapMirrorは、非同期、半同期、同期の複製をサポートしていますが、qtree SnapMirrorでサポートされているのは、非同期複製のみです。

非同期モードでは、ボリュームやqtreeのSnapshotコピーがソースシステムで定期的に作成されます。前回の複製処理後に変更 / 新規作成されたブロックのみが、ターゲットに転送されるため、ストレージシステムのオーバーヘッドとネットワークの帯域幅の観点から見ると、非常に効率的です。

同期モードでは、ソースのデータが更新された瞬間に、新しいデータがターゲットに転送されます。スケジュールも事前に設定しません。そのため、ソースシステム全体に障害が発生した場合でも、ソースシステム書き込まれたデータがターゲットシステムで保護されます。また、NVLOG転送、整合ポイント(CP)転送によって、ターゲットシステムが最新の状態に保たれます。NVLOG転送機能を使用すると、NetAppストレージ上の、通常NVRAMにキャッシュされる書き込みログのデータを、ターゲットと同期できます。整合ポイント転送を使用すると、ディスク上のファイルシステム・イメージを常に同期された状態に保つことができます。

半同期モードは、2つの点において同期モードと異なっています。ソースシステムにデータが書き込まれた場合、ターゲットからの確認応答を待機せずにデータをコミットし、確認応答を得ることができます。また、NVLOG転送は使用されません。この2つの相違点により、アプリケーションの応答時間が短縮され、実現可能なRecovery Point Objective(RPO;目標復旧時点)の観点から見ても、影響はわずかで済みます。

上記すべてのモードについては、TR-3446:『SnapMirror Async Overview and BestPractices GuideTR-3326:『SnapMirror Sync and SnapMirror Semi-Sync Overview and Design Considerations』(英語)に詳しい説明を掲載しておりますので、ぜひご参照ください。

SnapMirror

図2) SnapMirror

最後に、SnapMirrorに関する重要なポイントを1つご紹介します。それは、Volume SnapMirrorとqtree SnapMirrorでは、ターゲットを書き込み可能にできるということです。つまり、ソース(プライマリ)システムに影響を及ぼす障害が生じた場合に、業務をターゲットシステムにフェイルオーバーし、ターゲットシステムへの書き込みを開始できます。障害が解消されたら、コピーデータの差分を再同期してソースシステムにフェイルバックし、通常の業務を再開できます。これは、SnapVaultと最も大きく異なっている機能といえます。

SnapVault
SnapVaultはディスクツーディスク・バックアップを目的とした機能です。非同期SnapMirrorと同様に、SnapVaultはNetApp Snapshotテクノロジを使用し、システムのバックアップとリストアをブロックレベルで行います。また、SnapVaultはシステム上の変更されたブロックのみを特定し、セカンダリストレージにコピーします(ファイル単位のバックアップは行いません)。そのため、バックアップ処理、リストア処理中に転送されるデータの量が削減されてパフォーマンスが向上するだけでなく、バックアップを保管するのに必要な容量も少なく済み、必要に応じてバックアップの頻度を増やすことができます。

SnapVaultの機能は、基本的にはqtree SnapMirrorと非常によく似ています。つまり、qtreeレベルで論理的な複製を行います。そのため、qtree SnapMirrorと同様に、ソースボリュームがそっくりそのまま複製されるわけではなく、ソースシステムで行われた重複排除とデータ圧縮の効果も継承されません (ただし、ほかのNetAppボリュームに対して行うのと同様に、ターゲットシステムの重複排除やデータ圧縮を行うことができます)。

また、SnapMirrorのようにSnapVaultボリュームを書き込み可能にして、瞬時のリカバリを行うことも不可能です。そのため、ネットワークで大量のデータを転送する場合は、SnapVaultのリカバリ時間はSnapMirrorに比べてかなり長くなる可能性があります。SnapMirrorも所有していらっしゃる場合は、SnapVaultボリュームを書き込み可能にできます。ただし、SnapVaultは一方通行の複製しかできないため、再同期によってフェイルバックし、ソースシステムを最新の状態にすることはできません。

SnapVault Open Systems SnapVault(当記事では紹介していません)を使用すると、サードパーティ製ストレージをバックアップ・フレームワークに組み込むことができます。

図3)SnapVault Open Systems SnapVault(当記事では紹介していません)を使用すると、サードパーティ製ストレージをバックアップ・フレームワークに組み込むことができます。

SnapVaultの機能の中で、最も強力なメリットを発揮するのは、スナップショットの保持とスナップショットの結合でしょう。これは、論理レベルで動作するSnapVaultならではの利点です。SnapVaultボリューム上に、必要な分だけSnapshotコピーを作成し(ボリューム当たり最大255個)、設定したスケジュールに基づいてSnapshotコピーを自動的に期限切れにすることができます。また、スナップショット結合機能により、複数のソースシステムから単一のターゲットシステムに対して、複数のSnapVault処理を実行し、さまざまなソースシステムをすべて含んだ1つのSnapshotコピーをターゲットに作成できます。これにより、保管されるSnapshotコピーの数が削減されます。ターゲットシステムで重複排除を実行すれば、バックアップ内にあるすべてのqtreeに含まれる同一ブロックの重複を排除できます。

SnapVaultの全般的な詳細情報は、SnapVaultベスト・プラクティス・ガイドに記載しています。ぜひご参照ください。

表1)SnapMirrorとSnapVaultの比較

機能

Volume SnapMirror

qtree SnapMirror

SnapVault

複製の種類

物理

論理

論理

複製ネットワーク

FCまたはIP

FCまたはIP

IPのみ

複数パスの使用(複製時)

不可

Data ONTAPのバージョンによる影響

あり

なし

なし

ネットワーク圧縮機能

対応

対応(ただし承認が必要)

非対応

RPO(損失しても構わないデータ量)

1分1

1分2

1時間

フェイルオーバー機能

対応

対応

対応(ただしSnapMirrorの併用が必要)

スナップショットの保持(バックアップ用)

不可

可(ただし所要時間は長い)

スナップショットの結合

N/A

不可

フェイルバック用の再同期

不可

重複排除機能

ターゲットシステムには重複排除の効果が継承され、ネットワーク帯域幅も削減されます

ターゲットシステムには、重複排除の効果が継承されません

SnapVaultと重複排除機能が統合されており、ターゲットシステムには重複排除の効果が継承されません

 

11分間隔での更新は可能ですが、NetAppでは推奨していません。RPOの短縮(3分未満)には、SnapMirrorの半同期モードをお勧めします。<3 minutes).

21分間隔での更新は可能ですが、NetAppでは推奨していません。SnapMirror半同期は、単独のqtreeには使用できません。

MetroCluster
継続的なデータ可用性を実現するNetAppソリューションが、MetroClusterです。このソリューションはSnapMirrorやSnapVaultとは動作が全く異なり、両者の遠い親戚になりますが、概念上は理解しやすい製品です。名称から分かるように、MetroClusterは「長距離」クラスタリング機能を提供します。標準のNetApp HAペアを使って、ノード間を最長100 kmまで延長することが可能です。MetroClusterではフルミラーのアクティブ / アクティブ構成を利用し、ミラーリングされた全データの完全なコピーをクラスタの両サイドに1つずつ、合計2つ保持します。このコピーはプレックスといい、Data ONTAPがデータをディスクに書き込むたびに同期して、継続的に更新されます。

各コントローラは、両方のノードにそれぞれのストレージボリューム(プレックス)を保持しています。このため両方のノードで重複排除を実行できるだけでなく、読み取り処理を両方のディスクセット間でスプリットして、読み取りパフォーマンスを最大80%高めることもできます。MetroClusterに関する詳細は、最近のTech OnTapユーザ事例(英語)をお読みいただくか、ビデオによる詳細解説(英語)をご覧ください。

表2)MetroClusterとSnapMirror同期の比較

 

SnapMirror同期

MetroCluster

複製ネットワーク

IPまたはFC

FC

同時転送の制限

あり

なし

最大距離

200 km
(半同期では200 km超)

100 km

HAペア間の複製

不可

フェイルオーバー

CLI

CLI(シングルコマンド)、System Center

レプリカの使用

 

プライマリデータの重複排除サポート

 

あり



選択すべきオプション

前のセクションの表1と表2は、お客様個々のニーズに最適な複製オプションを選択する際に、1つの目安となるよう作成したものです。前述の各種のテクノロジから選択するにあたって、参考となる考慮事項がいくつかあります。非常に明らかな質問として、お客様がまずご自身に尋ねるべきは、「必要なのはバックアップなのかDRなのか」ということです。

バックアップ
バックアップを選択する場合、大抵のお客様は、プライマリストレージに通常のSnapshotスケジュール(一般的に毎時)を設定することで、バックアップのニーズを満たせることに気付きます。場合によっては、セカンダリストレージへの夜間のSnapVaultコピー(ローカルまたはリモート)を組み合わせることもあります。ファイルのリストアはほとんどが、プライマリストレージ上のSnapshotコピーで十分対応でき、また、SnapVaultを使ってさらに以前のバックアップを取得することも可能です。加えて、深刻な障害発生時に大規模なリストアを実行することもできます。

サイドバーで、ビデオ「NetApp Syncsort Integrated Backup」を紹介しておりますのでぜひご覧ください。このバックアップ機能は、Syncsortのデータ管理とNetAppの複製機能のメリットを兼ね備えたもので、各種の重要なアプリケーション環境に対応します。

DR
サイト全体の災害からデータを保護し、ビジネスの継続性を実現する場合は、おそらく、MetroClusterかSnapMirrorのいずれかを選択する必要があるでしょう。導入する環境の数という点でもっとも広く採用されているのが、非同期複製機能を備えたVolume SnapMirrorです。このソリューションがお客様によく選ばれるのは、ストレージとネットワークのリソースが効率よく利用されるため、経済性に優れており、しかもシンプルだからです。NetAppでは、SnapMirrorのさまざまな開発に投資することで、帯域幅制限機能やネットワーク圧縮(英語)、アプリケーション統合に対応したSnapManager製品スイートとの統合といった価値ある機能を生み出しています。

qtree SnapMirrorもVolume SnapMirrorも、Recovery Time Objective(RTO;目標復旧時間)を秒単位から分単位で達成可能です。また、Recovery Point Objective(RPO;目標復旧時点)は最短で1分前が可能(この場合は1分ごとのデータレプリケーションが必要)ですが、NetAppでは通常、1分ごとの非同期複製は推奨していません。RTOを1~3分で達成したい場合は、半同期モードのSnapMirrorを選択するとより最適です (RPOやRTOに詳しくないという方は、サイドバーをご覧ください)。

非同期SnapMirrorで達成できるRPOよりも、さらに厳しいRPOが求められる場合は、MetroClusterか同期SnapMirrorのいずれかを選択します。同期ソリューションでは一般に、より大容量のネットワーク帯域幅と専用のネットワーク機器を実装する必要があるため、非常に高コストになる点に注意してください。

MetroClusterは最大100 kmの距離に対応し、継続的なデータ可用性、自動フェイルオーバー、自動リカバリを提供することから最適なソリューションと言えます。SnapMirror同期を利用すると、サポートする距離が倍の200 kmになります。また、さらに長距離間で可能な限り短いRPOを達成する必要がある場合は、SnapMirror半同期を利用すると距離が拡大します。

特殊な例
上記で概要を説明したアプローチは、世間のほとんどの状況に対応するものでなければなりませんが、そこには当然、常に例外が存在します。SnapMirrorをバックアップに利用しているお客様もいますが、そのようにしているのは、必要になった場合に備えて、バックアップボリュームを素早く簡単に書き込み可能なボリュームにできる機能が必要だから、というのが一般的な理由です。反対に、SnapVaultをDRに利用しているお客様もおり、こちらは、任意の時点のデータをリカバリできるというのが理由です。SnapVaultボリュームはSnapVaultだけでは書き込み可能にできませんが、前述したように(方法は説明していませんが)、SnapVaultとSnapMirrorを使うことで可能になります。

ソリューションの導入に当たって

言うまでもありませんが、NetAppユーザの多くは、本稿で解説したソリューションを組み合わせて実装し、バックアップとDR両方のニーズを満たしています。ごく一般的なシナリオは、重要なボリュームをSnapMirrorでリモートサイトにミラーリングし、併せてリモートサイトでは、SnapVaultをスケジューリングして定期的に実行し、バックアップの目的を果たすというものです。サイトによってはさらに、MetroCluster、SnapMirror、SnapVaultを組み合わせて導入し、データ保護のニーズに対応しています。

図4)NetApp統合データプロテクションのポートフォリオ(本稿で説明していない機能も含む)

高度な構成、この記事で取り上げた全ての話題、データ保護計画など今回紙面を割けなかった話題についての詳細は、『NetApp Data Protection Handbook』(英語)をご覧ください。本稿で触れたその他の資料でも、詳細をご確認いただけます。NetAppは、全てのタイプのデータ保護ソリューションに関して数多くのノウハウを生み出しています。正しい選択のためのアドバイスが必要な場合は、ぜひオンラインのNetAppコミュニティに参加して、NetAppチームにご質問ください。

NetAppコミュニティ
 統合データプロテクションに関するご意見をお寄せください。

ご質問、意見交換、情報提供は、NetAppのコミュニティサイトまでお願いいたします。

Jason Blosil

Srinath Alapati
テクニカル・マーケティング・エンジニア
NetApp

Srinathは2004年にNetAppに入社して以来、4年以上にわたってデータ保護グループの一員を務めています。IT業界でのキャリアは10年以上に及び、サーバやストレージインフラの管理に携わってきました。SnapMirror、MetroCluster、VMware®、Exchangeに関して複数のテクニカルレポートを単独または共同で執筆しており、また、さまざまな技術カンファレンスで講演も行っています。NetApp ITのディザスタリカバリ実装にも、主要なチームメンバーとして関わっています。

 
関連情報
 
TRUSTe
お問い合わせ  |  購入方法  |  フィードバック  |  採用情報  |  登録  |  プライバシーポリシー  |  © 2011 NetApp