Alexei,
Actually, there is a very good reason to do both. Clustering only protects filer head failures. If a volume on a filer loses 2 disks in 1 RAID group, the volume built on that RAID group is useless and needs to be rebuilt upon disk repair. So, by using SNAPMIRROR to "almost realtime" copy data to a read-only volume on another filer, upon disk failure that volume can be made "live" or the master volume. This is a strategy we are employing to fully protect our users' data and insure the highest availability of that data.
Regards,
Sam
-----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.
Once the initial (level 0) snapmirror finishes, how long do incrementals take?
Have you tried with larger intervals?
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?
Try breaking the cluster setup, then do the snapmirror again. See if the speed improves.
Perhaps others have better ideas.
HTH.
Alex