Hi, Just wanted to throw in that we discussed with David Midgett (while waiting for the next SnapMirror schedule to be triggered) how he was using SnapMirror. And heard (correct me if I'm wrong David) that his copy of data was being accessed by other clients in read-only fashion effectively balancing the client load across the CFO pair. So not only does David have a (local) disaster recovery copy of his data, but its also accessible (in read-only mode) at all times (after the baseline transfer has completed).
Cheers, Grant
-----Original Message----- From: alexei@mindspring.net [mailto:alexei@mindspring.net] Sent: Thursday, July 29, 1999 3:35 PM To: Sam Schorr Cc: toasters@mathworks.com Subject: Re: SnapMirror Very Slow
Sam Schorr sschorr@homestead.com writes:
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.
I am not arguing that doing both is not (potentially) good, but doing both on the same set of filers is troublesome. Individually, each solution addresses a set of problems, and each has its own set of problems.
With CF (cluster failover), you get transparent (or close to) failover such that a client does not percieve a failure, just a pause. The cluster partner is then serving both sets of data (its own and that of its partner). If you do not size the filer correctly, you are going to be in trouble, especially if you loose a disk during failover. Snapshots are an additional overhead.
With snapmirror, you have a copy of the data N minutes old (where N is a function based on the network latency, the size of the volume (clustermap overhead), size of the network pipe and ammount of deltas). In order to make that copy "live", you will need to update mount points across your clients in order to point at the now-read-write snapmirror volume on the other filer.
So, doing snapmirror between cluster members is not a clear win. You are better off snapmirroring to a filer that is not part of the cluster. That way you can isolate your disaster backup copy from any potential problems the cluster might experience.
Alex
That is essentially accurate.
David
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Melvin, Grant Sent: Thursday, July 29, 1999 6:54 PM To: 'alexei@mindspring.net'; Sam Schorr Cc: toasters@mathworks.com Subject: RE: SnapMirror Very Slow
Hi, Just wanted to throw in that we discussed with David Midgett (while waiting for the next SnapMirror schedule to be triggered) how he was using SnapMirror. And heard (correct me if I'm wrong David) that his copy of data was being accessed by other clients in read-only fashion effectively balancing the client load across the CFO pair. So not only does David have a (local) disaster recovery copy of his data, but its also accessible (in read-only mode) at all times (after the baseline transfer has completed).
Cheers, Grant
-----Original Message----- From: alexei@mindspring.net [mailto:alexei@mindspring.net] Sent: Thursday, July 29, 1999 3:35 PM To: Sam Schorr Cc: toasters@mathworks.com Subject: Re: SnapMirror Very Slow
Sam Schorr sschorr@homestead.com writes:
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.
I am not arguing that doing both is not (potentially) good, but doing both on the same set of filers is troublesome. Individually, each solution addresses a set of problems, and each has its own set of problems.
With CF (cluster failover), you get transparent (or close to) failover such that a client does not percieve a failure, just a pause. The cluster partner is then serving both sets of data (its own and that of its partner). If you do not size the filer correctly, you are going to be in trouble, especially if you loose a disk during failover. Snapshots are an additional overhead.
With snapmirror, you have a copy of the data N minutes old (where N is a function based on the network latency, the size of the volume (clustermap overhead), size of the network pipe and ammount of deltas). In order to make that copy "live", you will need to update mount points across your clients in order to point at the now-read-write snapmirror volume on the other filer.
So, doing snapmirror between cluster members is not a clear win. You are better off snapmirroring to a filer that is not part of the cluster. That way you can isolate your disaster backup copy from any potential problems the cluster might experience.
Alex
-
David Midgett -
Melvin, Grant