NetApp Disaster Recoveryでレプリケーションプランを最適化する
変更を提案
PDF
レプリケーション計画は、スナップショットの頻度、ブート順序、ネットワークマッピング、およびフェイルオーバーとフェイルバックのその他の重要な詳細を定義する、災害復旧戦略の不可欠な部分です。NetApp Disaster Recoveryでレプリケーション計画を作成する前に、レプリケーション計画の仕組みとベストプラクティスを必ず理解しておいてください。
レプリケーションプランについて
単一のレプリケーションプランで、複数のVM、データストア、またはネームスペースを保護できます。Disaster Recoveryは、保護対象のデータリソースをホストするすべてのONTAPボリュームに対してONTAP整合性グループを作成します。
リソース計画
レプリケーション計画にリソースを割り当てる前に、VMまたはネームスペースを整理して、リソースの乱立を最小限に抑えてください。保護が必要なリソースはデータストアのサブセットに配置し、保護しないリソースは別のデータストアのサブセットに配置します。レプリケーション計画を作成する前にリソースグループを整理するには、"リソースグループを作成する"を参照してください。
テストフェイルオーバー
レプリケーションプランを作成する際に、固有のテストフェイルオーバーマッピングを設定するオプションがあります。
レプリケーション計画の一環としてテストフェイルオーバーを実行する予定がある場合は、フェイルオーバーテスト中に起動されたVMが本番環境のVMに干渉しないように、テストフェイルオーバーマッピングのセットを用意する必要があります。これは、テスト用VMに異なるIPアドレスを割り当てるか、テスト用VMの仮想NICを、本番環境から隔離されているもののIP構成が同じ別のネットワーク（_バブル_または_テストネットワーク_と呼ばれる）にマッピングすることで実現できます。
Snapshot 数
ディザスタ リカバリでは、ソース クラスターと宛先クラスターで同じ数のスナップショットが維持されます。デフォルトでは、サービスは 24 時間ごとにスナップショット調整プロセスを実行し、ソース クラスターと宛先クラスターのスナップショットの数が同じであることを確認します。
次の状況では、ソース クラスターと宛先クラスター間でスナップショットの数が異なる可能性があります。
-
状況によっては、ディザスタ リカバリ以外のONTAP操作によってボリュームからスナップショットが追加または削除されることがあります。
-
ソース サイトに不足しているスナップショットがある場合、関係のデフォルトのSnapMirrorポリシーに応じて、宛先サイト上の対応するスナップショットが削除される可能性があります。
-
デスティネーションサイトにスナップショットが欠落している場合、リレーションシップのデフォルトのSnapMirrorポリシーによっては、次回のスケジュールされたスナップショット調整プロセス中に、サービスがソースサイト上の対応するスナップショットを削除する可能性があります。
-
-
レプリケーション プランのスナップショット保持数を削減すると、新たに削減された保持数を満たすために、ソース サイトと宛先サイトの両方で最も古いスナップショットがサービスによって削除される可能性があります。
このような場合、ディザスタ リカバリでは、次の整合性チェック時にソース クラスターと宛先クラスターから古いスナップショットが削除されます。または、管理者は*アクション*を選択して即時スナップショットのクリーンアップを実行することもできます。
レプリケーション プランのアイコンをクリックし、[スナップショットのクリーンアップ] を選択します。
災害復旧機能は、24時間ごとにスナップショットの対称性チェックを実行します。
プラットフォーム管理バックアップ
プラットフォーム管理バックアップ（つまり、ONTAP 管理スナップショット）を使用する予定がある場合は、MirrorAll レプリケーションポリシーを使用することをお勧めします。さまざまな SnapMirror レプリケーションポリシーの影響と、MirrorAll が推奨オプションである理由を理解するために、表を確認してください。
Policy |
推奨事項 |
注記 |
MirrorAll |
推奨 |
フェイルオーバーまたはフェイルバック操作には、SnapMirror 転送スナップショットを使用しないでください。 |
MirrorVault |
代替案 |
フェイルオーバーまたはフェイルバック中に選択されたスナップショットが、ソースボリュームと宛先ボリュームの両方に存在することを確認してください。そうしないと、次のエラーが発生します：「'snapmirrored' 状態への移行に失敗しました。理由：共通のスナップショットが見つかりませんでした。」フェイルオーバーまたはフェイルバック操作には、SnapMirror 転送スナップショットを使用しないでください。 |
非同期 |
||
MirrorLatest |
推奨しません |
このポリシーでは、フェイルオーバー用の共通スナップショットが宛先側には実質的に1つしか存在せず、これはディザスタリカバリシナリオにおいては最適とは言えません。 |
Disaster Recovery管理のバックアップ
Disaster Recovery管理バックアップを使用する場合、NetApp Disaster Recoveryの外部で作成されたSnapMirror関係には、次のガイドラインが適用されます。
-
SnapMirror関係は、MirrorAll、MirrorVault、MirrorLatest、および非同期レプリケーションポリシーをサポートできます。
-
これらの関係については、更新をスケジュールしないでください。これらは Disaster Recovery サービスによって管理されます。
アプリケーションと整合性のあるレプリカ
多くの VM は、Oracle や Microsoft SQL Server などのデータベース サーバーをホストします。これらのデータベース サーバーでは、スナップショットが取得されたときにデータベースが一貫した状態であることを保証するために、アプリケーション整合性のあるスナップショットが必要です。
アプリケーション整合性スナップショットにより、スナップショットが取得されたときにデータベースが整合性のある状態であることが保証されます。これは、フェイルオーバーまたはフェイルバック操作後にデータベースを一貫した状態に復元できることを保証するため重要です。
データベース サーバが管理するデータは、データベース サーバをホストするVMと同じデータストア上にある場合と、別のデータストアにある場合があります。次の表は、NetApp Disaster Recoveryでアプリケーション整合性スナップショットに対してサポートされている構成を示しています：
| データの場所 | サポート | 注記 |
|---|---|---|
VMと同じvCenterデータストア内 |
はい |
データベース サーバーとデータベースは両方とも同じデータストアに存在するため、フェイルオーバー時にはサーバーとデータの両方が同期されます。 |
VMとは異なるvCenterデータストア内 |
いいえ |
ディザスタ リカバリでは、データベース サーバーのデータが異なる vCenter データストアにあるかどうかを識別できません。このサービスではデータを複製することはできませんが、データベース サーバー VM を複製することはできます。 データベース データは複製できませんが、このサービスにより、VM バックアップ時にデータベースが停止していることを確認するために必要なすべての手順がデータベース サーバーで実行されるようになります。 |
外部データソース内 |
いいえ |
データがゲストマウントされた LUN または NFS 共有に存在する場合、Disaster Recovery はデータを複製できませんが、データベース サーバー VM を複製できます。 データベース データは複製できませんが、このサービスにより、VM バックアップ時にデータベースが停止していることを確認するために必要なすべての手順がデータベース サーバーで実行されるようになります。 |
スケジュールされたバックアップ中に、Disaster Recovery はデータベース サーバーを静止させ、データベース サーバーをホストしている VM のスナップショットを取得します。これにより、スナップショットが取得されたときにデータベースが一貫した状態になることが保証されます。
-
Windows VM の場合、サービスは Microsoft Volume Shadow Copy Service （VSS）を使用して、どちらのデータベース サーバタイプとも連携します。
-
Linux VM の場合、サービスは一連のスクリプトを使用して Oracle サーバーをバックアップ モードにします。