技術資料・ベストプラクティス

次の図に、SRMとSRAでサポートされるSnapMirror関係のレイアウトシナリオを示します。レプリケートされたボリューム内の各VMは、各サイトの1つのSRMアレイ（SVM）上のデータのみを所有します。

SRMでアレイベースレプリケーション（ABR）を使用すると、次のスクリーンショットに示すように、保護グループが単一のアレイペアに分離されます。このシナリオでは、SVM1 および SVM2 は、リカバリーサイトで SVM3 および SVM4 とのペア関係が設定されています。ただし、保護グループを作成するときは、2つのアレイペアのうちの1つだけを選択できます。

サポート対象外の構成では、個 々 のVMが所有する複数のSVMにデータ（VMDKまたはRDM）が含まれます。次の図の例 VM1 で VM1 は、は2つのSVM上にデータを格納しているため、SRMで保護するようには設定できません。

個 々 のボリュームを1つのソースSVMから同じSVMまたは異なるSVM内の複数のデスティネーションにレプリケートするレプリケーション関係は、SnapMirrorファンアウトと呼ばれます。SRMではファンアウトはサポートされていません。次の図の例では、 VM1 はSnapMirrorを使用して2つの異なる場所にレプリケートされるため、SRMで保護を設定できません。

SRMは、SnapMirror関係のカスケードをサポートしていません。このカスケードでは、ソースボリュームがデスティネーションボリュームにレプリケートされ、そのデスティネーションボリュームもSnapMirrorを使用して別のデスティネーションボリュームにレプリケートされます。次の図のシナリオでは、SRMを使用してサイト間のフェイルオーバーを実行することはできません。

アーキテクチャーの重要な変更点として、ONTAP 9のSnapVaultは、7-Mode SnapVaultのように、qtreeレベルではなくボリュームレベルでレプリケートされる点が挙げられます。この設定では、SnapVault関係のソースがボリュームである必要があり、そのボリュームはSnapVaultセカンダリーシステム上の自身のボリュームにレプリケートする必要があります。

SnapVaultを使用する環境では、プライマリーストレージシステム上に、特に名前が付けられたSnapshotコピーが作成されます。実装する構成に応じて、SnapVaultスケジュールまたは Active IQ Unified Managerなどのアプリケーションを使用して、指定したSnapshotコピーをプライマリーシステムに作成できます。プライマリーシステムで作成された名前付きSnapshotコピーがSnapMirrorデスティネーションにレプリケートされ、そこからSnapVaultデスティネーションに保存されます。

ソースボリュームはカスケード構成で作成できます。カスケード構成では、ボリュームがDRサイトのSnapMirrorデスティネーションにレプリケートされ、そこからSnapVaultデスティネーションに保存されます。ファンアウト関係でソースボリュームを作成することもできます。ファンアウト関係では、一方がSnapMirrorデスティネーションで、もう一方がSnapVaultデスティネーションです。ただし、SRMフェイルオーバーまたはレプリケーションの反転時に、SRAがSnapMirrorデスティネーションボリュームをバックアップのソースとして使用するようにSnapVault関係を自動的に再設定することはありません。

SnapMirrorとSnapVault for ONTAP 9の最新情報については 、TR-4015『SnapMirror Configuration Best Practice Guide for ONTAP 9』を参照してください。

VMware環境では、各データストアにUniversal Unique Identifier（UUID）が割り当てられ、各VMには一意のManaged Object ID（MOID；管理オブジェクトID）が割り当てられます。SRMは、フェイルオーバーまたはフェイルバックの際にこれらのIDを維持しません。SRMはフェイルオーバー時にデータストアUUIDとVM MOIDを維持しないため、これらのIDに依存するアプリケーションはSRMフェイルオーバー後に再設定する必要があります。たとえば、 Active IQ Unified Managerでは、SnapVaultレプリケーションをvSphere環境と調整します。

次の図に、SnapMirrorからSnapVaultへのカスケード構成を示します。SnapVaultデスティネーションがDRサイトまたはプライマリーサイトの停止の影響を受けない3番目のサイトにある場合は、フェイルオーバー後もバックアップを継続できるように環境を再設定できます。

次の図は、SRMを使用してSnapMirrorレプリケーションをプライマリーサイトに反転したあとの設定を示しています。また、現在のSnapMirrorソースからSnapVaultバックアップが実行されるように環境を再設定しました。このセットアップはSnapMirror SnapVaultのファンアウト構成です。

SRMがフェイルバックを実行し、SnapMirror関係が再度反転されると、本番環境のデータがプライマリーサイトに戻ります。このデータは、DRサイトへのフェイルオーバー前と同じ方法で、SnapMirrorとSnapVaultのバックアップを通じて保護されます。

qtreeは、NASのファイルシステムクォータを適用できる特別なディレクトリです。ONTAP 9ではqtreeを作成でき、SnapMirrorでレプリケートされたボリュームにqtreeを配置できます。ただし、SnapMirrorでは、個 々 のqtreeのレプリケーションやqtreeレベルのレプリケーションは実行できません。SnapMirrorレプリケーションはすべてボリュームレベルでのみ実行されます。このため、SRMでqtreeを使用することを推奨していません。

サポート対象のSANプロトコル（FC、FCoE、iSCSI）の場合、ONTAP 9はLUNサービスを提供します。LUNサービスとは、LUNを作成して接続されたホストにマッピングする機能です。クラスタは複数のコントローラーで構成されるため、個 々 のLUNへの複数の論理パスがマルチパスI/Oで管理されます。ホストでAsymmetric Logical Unit Access（ALUA；非対称論理ユニットアクセス）が使用されるため、LUNへの最適パスが選択され、データ転送用にアクティブになります。LUNへの最適パスが変更された場合（LUNを含むボリュームが移動された場合など）、ONTAP 9はこの変更を自動的に認識し、無停止で調整します。最適パスが使用できなくなった場合、ONTAPは使用可能な他のパスに無停止で切り替えることができます。

VMware SRMと SRAでは、一方のサイトでFCプロトコルを使用し、もう一方のサイトでiSCSIプロトコルを使用できます。ただし、FC接続のデータストアとiSCSI接続のデータストアを、同じESXiホストまたは同じクラスタ内の別のホストに混在させることはサポートされていません。SRMフェイルオーバーまたはテストフェイルオーバーでは、SRMの要求にESXiホストのすべてのFCイニシエータとiSCSIイニシエータが含まれるため、この構成はSRMではサポートされません。