quick-resyncパラメータを使用すると、どのような影響がありますか。
環境
- ONTAP 9
- SnapMirror
- Data Warehouse （DW）
- Data Warehouseには、ソースボリュームでの重複排除による削減を維持するうえで重要なメタデータが含まれています。
- ストレージ効率（SIS）
回答
を使用した場合の潜在的な影響の大まかな例を次に示し
quick-resyncます。- SnapMirror関係でA -> B（本番-> DR）が開始されます。
- ONTAP SISは、上のブロックを検出して重複排除します。
- これらのブロックと削減効果がBにレプリケートされます。
- 既存の共有ブロックに重複排除された新しいブロックがに書き込まれた場合、このブロックをBに転送する必要はありません。これは、DWファイルがそのブロックにすでに重複排除されたブロックのエントリがあることを認識するためです。
- これにより、転送時間が短縮されます。
- SnapMirror が解除され、新しいデータがBに追加されました。
- キヤクサイトウキノシツコウ
quick-resync
::> snapmirror resync -source-path B -destination-path A -quick-resync true- Bに書き込まれたデルタのみがAにレプリケートされる
- 重複排除されたブロックがBに書き込まれた場合でも 、
quick-resyncが使用されているために（A）にマッピングされるDWファイルはありません。 - つまり、ブロック全体をに転送する必要があります（通常はそこで重複排除されます）。
- これは 、snapmirror resyncのコマンドドキュメントに 記載されている内容です。「このパラメータを指定すると、再同期によって、ネットワーク上およびデスティネーション上の既存データの新しいデータのストレージ効率が維持されません。」
- このブロックが複製されると、新しいエントリがB -> A DWファイルに追加されます。したがって、重複排除された同じブロックが再度発生しても、 SnapMirrorは そのブロックを再度転送する必要はありません。
- 上記の内容は 、KBの SnapMirror関係から 「Preparing」関係のステータスが報告され、「クイック再同期を使用した場合のパフォーマンスやスペースのペナルティは、再同期後に通常のSnapMirror更新が進むにつれて低下します」と記載されています。
追加情報
- SnapMirrorの再同期
[-quick-resync <true>]-クイック再同期このパラメータは、XDP関係でのみサポートされます。このパラメータは、エンドポイントがData ONTAP以外の関係ではサポートされません。ポリシータイプ
strict-sync-mirrorがおよびの関係ではサポートされませんsync-mirror。このオプション パラメータを指定すると、再同期の際、新しいデータの転送前にストレージ効率化によるオーバーヘッドが発生しないため、再同期時間が短縮されます。再同期のソースでボリュームの効率化が有効になっていない場合や、利用可能なストレージの効率化を維持するよりも再同期時間の短縮の方が重要な場合は、このパラメータを指定することを推奨します。このパラメータを指定すると、既存のデータのストレージ効率化は、ネットワークでの転送時、およびデスティネーションの新しいデータには継承されません。 - SnapMirror関係で「Preparing」関係のステータスがレポートされる
- SnapMirror関係をタイプDPからタイプXDPに変換する場合は、タイプXDP SnapMirror関係のすべての機能を利用するために必要なため、Data Warehouseの処理を完了してください。
|
- 「 -Quick-Resync 」パラメータを指定して SnapMirror の逆再同期を実行する方法
- 既存のDPタイプの関係をXDPに変換する
- テクニカルレポート TR-4015 ONTAP 9 SnapMirrorの設定およびベストプラクティスガイド-
Storage Efficiencyを使用した論理レプリケーション（LRSE）
LRSEは、ブロックレベルのメタデータとファイルシステムに関する情報を使用して、間接ポインタレベルでSnapshotコピー間の差異を判断します。
LRSEは、ソースからデスティネーションへのデータ転送を2つのストリームで編成します。
− データストリームは、デスティネーションボリューム内の特定のボリュームブロック番号（vvbn#）を使用して転送されるデータブロックで構成されます。
このvvbn #は、ファイルコンテキストを指定せずに、ソースFlexVolボリューム上のデータが格納されているブロック番号を識別するのに役立ちます。
デスティネーションでは、データは、vvbn#に対応するファイルブロック番号（FBN#）を使用してData Warehouse（DW）ファイルに書き込まれます。
− ユーザファイルは、ユーザファイルのinodeを使用して参照によって転送されます。inodeはデータウェアハウスファイルとブロックを共有し、特定のオブジェクトに到達するために解析が必要なバッファツリーを使用しません。
LRSEは、レプリケーション転送の進行中に、ユーザファイル（受信者）を使用してDWブロック（ドナー）のブロック共有インフラストラクチャに明示的な要求を行います。
ミラーには、元のデータセットへの論理ブロックポインタの構造があり、ソースと比較してディスク上の物理レイアウトがまったく異なります。
タイプがXDPでSnapMirror関係が作成され、SnapMirrorポリシータイプがasync-mirror、vault、またはmirror-vaultのいずれかになります。
LRSEは、ストレージ効率に優れたソースボリュームにデータをレプリケートする際に、ネットワーク経由でもデスティネーションでもスペース効率を維持します。
ブロック共有や圧縮などの機能を使用すると、ボリュームに使用スペースよりもはるかに多くのデータを実質的に保持できるため、Storage EfficiencyはLRSEの重要な要素です。
レプリカの転送に要する時間は言うまでもなく、レプリカのサイズが耐えられないほど大きくなるのを避けるために、レプリケーション中にこの効率性を維持する必要があります。
LRSEでは、プライマリストレージの設定に関係なく、セカンダリでStorage Efficiency機能を有効にすることもできます。
詳細については、「重複排除、データ圧縮、データコンパクションを使用したストレージ効率の向上–概要」を参照してください。
https://docs.netapp.com/us-en/ontap/...y-concept.html