2016-03-23 04:04 AM
I'm quiet new with the concept of deswizzling so i'm comming here to find some generous help from the community.
We have a 4 nodes FAS6250 with flashcache whish his running snapmirror in cascaded mode with another 4 node FAS6250 which is running snapmirror in cascaded mode with a 2 nodes FAS3220.
All those arrays are in CDOT 8.2.1.
I would like to know how to monitor the deswizzler status on those arrays ?
Is it really important to have the deswizzler activte on the second FAS6250 which is a spare for distater recovery and on the FAS3220 which is used for backup ?
How to check if some snapmirror relations are concurent and consequently delay the time of launch ?
How to check quickly if the folder tree and the files size do not have some negative behaviour on our snapmirror relations ?
Thank you very muche for your help.
2016-03-23 09:37 PM
Please refer a similar discussion http://community.netapp.com/t5/Data-ONTAP-Discussions/Deswizzling-amp-SnapMirror/td-p/22857
2016-03-24 02:56 AM
Thank you for your answer.
I saw that post already and that does not answer to my questions.
I'm really in need for best practices for deswizzling.
2016-03-24 06:19 AM
you dont schedule deswizzling, it starts automatically after the snapmirror occurs. What you need to be aware of is if deswizzling is running and a new mirror kicks off then you need increase the time between mirros to allow deswizzling to complete.
2016-03-28 05:39 PM
What version of Data ONTAP are you using? 7-mode or clustered Data ONTAP? Note that the linked communities post is just shy of 3 years old and refers specifically to 7-mode....meaning it's probably targeted at later versions of the 8.1 code line.
What is your concern with deswizzling? This is something that is, for the most part, completely transparent, and has been for the last 5-ish years in most situations. Are there particular problems you're encountering or that you believe you will encounter?
TR-4075 has deswizzle best practices in section 8.1. The only thing to be aware of is that read-intensive workloads running against the destination volume before the deswizzle process finishes may cause the process to take a little longer than normal because of the extra IO.