Can you expand upon why QSM wouldn't be a good choice for a general DR use case? We currently do not use "vfiler dr" and have no immediate plans to use it in the future.
On Thu, Feb 5, 2015 at 2:28 PM, Peter-Paul Witta paul.witta@cubit.at wrote:
Great! Just keep in mind QSM might not be the best choice for DR or vfilerDR use cases...
kind regards, Ing. Peter-Paul Witta Chief Technology Officer www.CUBiT.at Mobile +436644542287 Office +4317189880-0
Am 05.02.2015 um 21:17 schrieb Philbert Rupkins <philbertrupkins@gmail.com
:
Just a quick update. We're generally a volume snapmirror shop. I think I read somewhere that VSM is generally recommended in most cases.
However, I also read that Qtree SnapMirror is not subject to the same deswizzling process that runs on the destination when using VSM. My understanding is this is because VSM is block based whereas QSM is not. The SnapMirror TR goes through a fairly decent list of the differences between VSM and QSM. Since QSM does not require deswizzling, I think we are going to give QSM a shot for the volumes with many snapshots. Sure, we'll need to dedupe the QSM destination and figure out how to manage snapshots, but QSM sounds like something we need to consider given the high disk utilization resulting from the deswizzle process.
-Phil
On Tue, Feb 3, 2015 at 10:44 AM, Philbert Rupkins < philbertrupkins@gmail.com> wrote:
Paul,
Thanks for this tip. I cant find much about the wafl.deswizzle.enable option on the support site. I did find a document that says "This is a diagnostic mode option that should only be used as part of an action plan under NetApp Global Support supervision." I guess I'll be giving them a call.
Did you find this option mentioned in another document somewhere? Quarterly, we refresh an environment on the remote side which involves promoting a (volume) snapmirror replica to a primary copy of the data. I just want to make sure I am not going to shoot myself in the foot (from a performance perspective) with this option when we break a snapmirror replica and use the destination as a primary copy.
Thanks, Phil
On Tue, Jan 27, 2015 at 2:04 PM, Peter-Paul Witta paul.witta@cubit.at wrote:
if you do not plan to use the destination regularily tun the deswziller off. otherwise you'd deswizzle lots of snapshots you'll never use active on the destination anyway...
greets, paul
Am 27.01.15 um 20:55 schrieb Philbert Rupkins:
Hello Toasters,
We've unfortunately had to reduce the frequency of our volume snapmirror updates in order to allow for our destination aggregate to deswizzle. We highly prefer hourly volume snapmirror updates but it turns our our source volumes are large enough and/or have enough snapshots that the deswizzle process never completes on the destination aggregate. Our volume snapmirror destination aggregate is a single tray of SATA. Prior to reducing the frequency of snapmirror updates, the SATA aggregate was running at 90-100% utilization 24x7 with little to no IO to the filer from active clients. Needless to say, serving data from said aggregate was VERY SLOW despite the light IO (<300 IOPS) required by the clients sourcing their primary data from the SATA aggregate.
We've done what we can to reduce the impact of deswizzling. Namely, cutting down on snapshots and reducing the volume size. I understand reducing volume size doesnt reduce the maxfiles setting which believe ultimately impact the amount of deswizzling necessary on the destination. I'm still digging into other options we can try but reducing the frequency of snapmirror updates seems to have the most impact.
How does one plan for IOPs or disk utilization resulting from the deswizzle process? If I recall correctly, during our planning sessions with NetApp, our Netapp SE never touched on IOPs or number of spindles required to handle deswizzling while serving data from the same aggregate. In fact, I think our aggregates were size purely based on the amount of IO generated from active clients (not active clients + deswizzle).
Thanks, Phil
Toasters mailing listToasters@teaparty.nethttp://www.teaparty.net/mailman/listinfo/toasters
-- kind regards, +43-664-4542287 Ing. Peter-Paul Witta +43-1-7189880-0 CTO/techn. Geschaeftsleitung www.CUBiT.at
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters