MetroCluster構成は、物理的に分離された2つのミラークラスタを実装することでデータを保護します。各クラスタが、もう一方のクラスタのデータおよびSVM設定を同期的にレプリケートします。一方のサイトで災害が発生したときは、管理者はミラーリングされたSVMをアクティブ化し、ミラーリングされたデータをセカンダリーサイトから提供できます。

ファブリック接続MetroCluster 構成は、メトロポリタン規模のクラスタをサポートします。
ストレッチMetroCluster 構成は、キャンパス規模のクラスタをサポートします。

いずれの場合も、クラスタ間でピア関係を確立する必要があります。

MetroClusterでは、SyncMirror と呼ばれるONTAPの機能を使用して、各クラスタのアグリゲートデータがもう一方のクラスタのストレージにあるコピー（プレックス）との間で同期的にミラーリングされます。スイッチオーバーが発生すると、サバイバークラスタ上のリモートプレックスがオンラインになり、セカンダリーSVMがデータの提供を開始します。

MetroCluster以外の実装でのSyncMirrorの使用
MetroCluster以外の実装では、必要に応じてSyncMirrorを使用することで、RAIDタイプで保護されるドライブ数よりも多くのドライブで障害が発生した場合やRAIDグループのドライブへの接続が切断された場合のデータ損失を防ぐことができます。この機能はHAペアに対してのみ使用できます。

アグリゲートデータは、別々のドライブシェルフに格納されたプレックス間でミラーリングされます。一方のシェルフが使用できなくなった場合、影響を受けていないプレックスが障害からの復旧作業中も引き続きデータを提供します。

SyncMirrorを使用してミラーリングされたアグリゲートは、ミラーリングされていないアグリゲートの2倍のストレージを必要とすることに注意してください。各プレックスに、ミラーリングするプレックスと同じ数のドライブが必要です。たとえば、1,440GBのアグリゲートをミラーリングするには、プレックス1つにつき1,440GB、合計で2,880GBのドライブスペースが必要です。

SyncMirrorでは、ストレージのパフォーマンスと可用性を最適化するために、ミラーアグリゲート用に少なくとも20%の空きスペースを確保することを推奨します。ミラーされていないアグリゲートでは10%が推奨されますが、追加の10%のスペースはファイルシステムで増分変更に対応するために使用できます。増分変更を行うと、ONTAPのcopy-on-write Snapshotベースのアーキテクチャーにより、ミラーされたアグリゲートのスペース使用率が向上します。これらのベストプラクティスに従わないと、SyncMirrorの再同期のパフォーマンスが低下し、非共有クラウド環境のNDUやMetroCluster環境のスイッチバックなどの運用ワークフローに間接的に影響します。