日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。
SnapMirrorアクティブ同期優先サイト
共同作成者
変更を提案
SnapMirrorのアクティブな同期の動作は対称ですが、重要な例外が1つあります(推奨サイト構成)。
SnapMirrorアクティブ同期では、一方のサイトが「ソース」で、もう一方が「デスティネーション」と見なされます。これは一方向のレプリケーション関係を意味しますが、IO動作には適用されません。レプリケーションは双方向であり、対称であり、IO応答時間はミラーの両側で同じです。
`source`指定は、優先サイトを制御します。レプリケーションリンクが失われた場合、ソースコピー上のLUNパスは引き続きデータを提供しますが、デスティネーションコピー上のLUNパスは、レプリケーションが再確立されてSnapMirrorが同期状態に戻るまで使用できなくなります。その後、パスでデータの提供が再開されます。
ソース/デスティネーションの設定はSystemManagerで確認できます。
または、CLIで次の操作を行います。
Cluster2::> snapmirror show -destination-path jfs_as2:/cg/jfsAA Source Path: jfs_as1:/cg/jfsAA Destination Path: jfs_as2:/cg/jfsAA Relationship Type: XDP Relationship Group Type: consistencygroup SnapMirror Schedule: - SnapMirror Policy Type: automated-failover-duplex SnapMirror Policy: AutomatedFailOverDuplex Tries Limit: - Throttle (KB/sec): - Mirror State: Snapmirrored Relationship Status: InSync
重要なのは、ソースがcluster1のSVMであることです。前述のように、「ソース」と「デスティネーション」という用語は、レプリケートされたデータのフローを表していません。両方のサイトが書き込みを処理し、反対側のサイトにレプリケートできます。実際には、両方のクラスタがソースとデスティネーションです。1つのクラスタをソースとして指定すると、レプリケーションリンクが失われた場合に、どのクラスタが読み取り/書き込みストレージシステムとして残っているかが制御されます。