-----Original Message----- From: alexei@mindspring.net [mailto:alexei@mindspring.net] Sent: Thursday, July 29, 1999 1:48 PM To: dmidgett@about.com Cc: toasters@mathworks.com Subject: Re: SnapMirror Very Slow
"David Midgett" dmidgett@about.com writes:
Has anyone experienced problems with the SnapMirror taking
an excessively
long time to complete the transfer. We have two F760's in a cluster configuration. The mirror is set to update every 15
minutes. There is not
that much data that is changing and the total volume is
107Gb with only 1Gb
used spanning 10 disks. The transfer takes hours for any
change to be
replicated. The 'vol snapmirror status' command shows that it is transferring. The network speed is not an issue. Also
connected the two
NetApp's directly to each other with a cross cable. This
does not speed it
up. Any insight?
Hmm. I don't know if this should work as you describe. The normal overhead for the snapmirror includes moving a constant set of data plus the deltas.
Correct, overhead is 1/1024 of the volume size. In this case a little over 100MB.
Once the initial (level 0) snapmirror finishes, how long do incrementals take?
Have you tried with larger intervals?
The implication here being that an update that does not complete due to network being down or some such will just restart at the next scheduled update time. How are you determining that updates take a long time. Have you done snap list and seen how fast the snapshot names are incrementing.
What network interface are you using to conenct the filers?
snapmirroring between cluster partners does not seem like it would/should work completely. The whole point of clustering is to have access to both sets of data with a failure, so snapmirroring it between the cluster is an unneccessary step. What occurs when:
- snapmirror source filer fails - cluster-failover kicks in - cf partner (snapmirror destination) takes over - snapmirror continues.... how? The filer talks to itself?
Exactly! The filer is running a virtual machine that actually sends the update to the original physical machine. Actually not as crazy as it first sounds. In fact we do have customers that just have a single filer and want to mirror so that they have two copies of data. [Poof! The engineer in me takes over for the Marketing dweeb that's been talking til now] Alright, maybe we don't have anybody doing it, but we've talked about it with customers. :-)
When we first set up customer demos of snapmirroring here in corporate, we did it on a cluster since that was the equipment we had in the demo room. I don't recall any special issues in using it on a cluster. It was hard to see the updates since we had a tiny volume, 30GB, and a direct gigabit connection. Every time we did a status it was idle. Trying to catch the 30MB in flight turned out to be impossible. A sysstat would show the update going once a minute. Looking at the snapshot names incrementing turned out to be the simplest way to see what was happening.
Try breaking the cluster setup, then do the snapmirror again. See if the speed improves.
This shouldn't be an issue.
Perhaps others have better ideas.
Well, have you tried contacting NetApp CS and asked them to look at your setup? You may have something different in your environment or it could be you've uncovered a bug.
HTH.
Alex
-
Norman, Paul