|
Home > Archive > Data Storage > January 2006 > EMC SANCopy, Clone, Snapshot question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
EMC SANCopy, Clone, Snapshot question
|
|
| Clayton Sutton 2006-01-02, 2:47 am |
| I am new to this SAN stuff as we just got a CX500 and CX300 installed by
Dell. I am trying to get my arms around the SANCopy, Clone and Snapshot
concepts. I know that they are different but I don't know how. Can someone
explain them to me?
The way I understand it is if I did a "Clone" of a source LUN from the CX500
to the CX300 at a DR site I would have an exact copy of the source LUN.
(i.e. If the source LUN had 500GB of data so would the "clone" LUN).
So what happens if I did a SANCopy of that same LUN to that same remote LUN?
Wouldn't it still be 500GB?
So what's the differance? And what will Snapshots do for me?
We also have a mount host at the DR site. We have two Exchange 2003
clusters on the SAN and two Windows 2000 file server hosts connected to the
SAN right now.
Thanks for any input,
Clayton
| |
| madhu.joshi@gmail.com 2006-01-03, 2:47 am |
| Clayton,
Clone is within the same array. You can't "clone" to a different array.
You
use MirrorView for that purpose. SANCopy is (typically a one-time
operation)
used to copy bulk data from a Clariion to another storage array (target
doesn't have to be a Clariion).
Snapshots are point in time copy of the source lun. Once you take a
snapshot and activate it, any changes made to the original source
lun are tracked in a special lun called cache or reserve lun. The cache
lun is typically 10-15% of the source lun and holds the blocks that
have been
changed in the original lun.
HTH
| |
| Clayton Sutton 2006-01-03, 8:54 pm |
| Thanks for your reply Madhu,
Okay, I think I understand the Clone (and MirrorView) concept. You would
use it when you wanted another copy of you data on-site. But if you want to
push a copy off-site (maybe to a DR site) then your would have to use
SANCopy. Do I have that right? But what do you mean the SANCopy is
"typically" a one time operation? If you are using SANCopy don't/can't you
use it to schedule a SANCopy nightly if you want?
SnapShots - Okay, I can relate to most of that. But, if the original sourse
LUN changes and the changes are tracked in the cache LUN when is it written
to the source or Snapshot?
Thnaks for all of your help,
Clayton
<madhu.joshi@gmail.com> wrote in message
news:1136257495.035504.47800@z14g2000cwz.googlegroups.com...
> Clayton,
> Clone is within the same array. You can't "clone" to a different array.
> You
> use MirrorView for that purpose. SANCopy is (typically a one-time
> operation)
> used to copy bulk data from a Clariion to another storage array (target
>
> doesn't have to be a Clariion).
> Snapshots are point in time copy of the source lun. Once you take a
> snapshot and activate it, any changes made to the original source
> lun are tracked in a special lun called cache or reserve lun. The cache
> lun is typically 10-15% of the source lun and holds the blocks that
> have been
> changed in the original lun.
>
> HTH
>
| |
|
| On Wed, 04 Jan 2006 00:54:56 GMT, "Clayton Sutton" wrote:
>Okay, I think I understand the Clone (and MirrorView) concept. You would
>use it when you wanted another copy of you data on-site.
That's what MirrorView does, yes. A clone is like MirrorView, in that
it's a complete copy of the source LUN, but the data is copied to a
new LUN within the same array.
>But if you want to
>push a copy off-site (maybe to a DR site) then your would have to use
>SANCopy. Do I have that right?
Maybe...
>But what do you mean the SANCopy is
>"typically" a one time operation? If you are using SANCopy don't/can't you
>use it to schedule a SANCopy nightly if you want?
Typically you'd use SANCopy to push data off an (old) array onto a
(new) EMC Clariion. The idea generally being that you'd stop using
the old array.
Note that with SAN Copy you can move data from selected non-EMC arrays
to a Clariion and vice-versa.
You'd only use this regularly if you wanted to push data to/from a
non-EMC array. This could be scheduled if you wanted. To relate back
to your example, you *could* use SAN Copy to push data to a non-EMC
array at a remote location (like a DR centre).
If you have two similar EMC arrays (i.e. two Clariions) we'd expect to
use MirrorView to push the data between the arrays.
The exception to this is if you're using EMC Replication Manager/SE to
create application-level (Exchange or SQL) replication groups - in
that case you *might* use SAN Copy. <== note this is fairly unusual
and there are other (EMC) ways of doing Exchange/SQL replication.
>SnapShots - Okay, I can relate to most of that. But, if the original sourse
>LUN changes and the changes are tracked in the cache LUN when is it written
>to the source or Snapshot?
With SnapShots changes are always written to the source LUN. The old
data from the source is written into the 'cache' LUN, really known as
the 'reserved LUN pool'
Rather than beat about the bush with the possible merits of various
functions, can you tell us what you're trying to do with your storage?
HVB
| |
| Clayton Sutton 2006-01-05, 2:47 am |
| Hey HVB,
Thanks for your input.
> Rather than beat about the bush with the possible merits of various
> functions, can you tell us what you're trying to do with your storage?
Here is what we are trying to do. In our data center we have a CX500 and a
Disk Array Enclosure fully populated with disk. We have two Exchange 2003
clusters and two file servers on this SAN for now. We have EMC Replication
Manager/SE , SANCopy and SnapView. At our DR site we have another SAN that
has an CX300 with a Disk Array Enclosure fully populated with disk (same
amount of disk space that's on the data center SAN).
The idea when we bought all of this was to "push" in some fashion, our
production data to the DR site. Dell came in and set all of this up but
didn't do a knowledge transfer so we are kinda left to figure out how all of
this works. We are trying to understand and figure the best way to get the
data to the DR site (EMC Replication Manager/SE , SANCopy, SnapView or
MirrorView) However, we didn't buy "MirrorView" so that's not really an
options for us I guess.
Dell set up "Replication" jobs for all of the data transfer and ran the jobs
as a test once. After that they said we could setup what ever schedule we
wanted. We also have a "Mount Host" at the DR site. It is part of the AD
domain and just has Windows 2003 and EMC Replication Manager/SE on it. It
is also connected into the SAN.
So I just need some "ideas" on how to do what we want to do. I am trying to
understand the difference between SANCopy, SnapView and MirrorView and when
I should use which.
Thanks a bunch for all of your help,
Clayton
"HVB" <hvbnntp@googlemail.com> wrote in message
news:rqenr15mamv4n1tor2bk2btut0q66onig3@
4ax.com...
> On Wed, 04 Jan 2006 00:54:56 GMT, "Clayton Sutton" wrote:
>
>
> That's what MirrorView does, yes. A clone is like MirrorView, in that
> it's a complete copy of the source LUN, but the data is copied to a
> new LUN within the same array.
>
>
> Maybe...
>
>
> Typically you'd use SANCopy to push data off an (old) array onto a
> (new) EMC Clariion. The idea generally being that you'd stop using
> the old array.
>
> Note that with SAN Copy you can move data from selected non-EMC arrays
> to a Clariion and vice-versa.
>
> You'd only use this regularly if you wanted to push data to/from a
> non-EMC array. This could be scheduled if you wanted. To relate back
> to your example, you *could* use SAN Copy to push data to a non-EMC
> array at a remote location (like a DR centre).
>
> If you have two similar EMC arrays (i.e. two Clariions) we'd expect to
> use MirrorView to push the data between the arrays.
>
> The exception to this is if you're using EMC Replication Manager/SE to
> create application-level (Exchange or SQL) replication groups - in
> that case you *might* use SAN Copy. <== note this is fairly unusual
> and there are other (EMC) ways of doing Exchange/SQL replication.
>
>
> With SnapShots changes are always written to the source LUN. The old
> data from the source is written into the 'cache' LUN, really known as
> the 'reserved LUN pool'
>
>
> HVB
| |
|
| Hi Clayton,
On Thu, 05 Jan 2006 06:33:44 GMT, "Clayton Sutton" wrote:
[config snipped]
>The idea when we bought all of this was to "push" in some fashion, our
>production data to the DR site. Dell came in and set all of this up but
>didn't do a knowledge transfer so we are kinda left to figure out how all of
>this works. We are trying to understand and figure the best way to get the
>data to the DR site (EMC Replication Manager/SE , SANCopy, SnapView or
>MirrorView) However, we didn't buy "MirrorView" so that's not really an
>options for us I guess.
Ok, I see what you're trying to do now and it does make sense.
The CX500 is the mid-range Clariion array, while the CX300 is it's
baby brother. The CX300 has less CPU power and memory available and
because of this it does not support MirrorView. The advantage is that
the CX300 is a lot cheaper than a CX500.
SANCopy works with the CX300 because it pushes the data from the CX500
and it doesn't matter that the '300 is effectively 'dumb'.
Without seeing the deal you got from Dell, it looks very much like
they have sold you a DR replication solution and tried to make it as
cheap as possible for you.
The alternative configuration would have been a CX500 at both of your
sites with MirrorView. MV software isn't especially cheap, but I
confess I don't know how much SANCopy usually sells for.
Did you not get any training??? It certainly sounds that way and I'm
very surprised, because:
A - you need it
B - Dell could have sold it to you
I say you need it because data replication, especially for DR, is the
kind of thing that if you get it wrong, you might as well not bother
to do it in the first place. Finding out that it didn't work properly
when things have gone wrong and you need it most is often the way that
these things come to light. Trust me - this is *BAD*. You don't want
to do that.
>Dell set up "Replication" jobs for all of the data transfer and ran the jobs
>as a test once. After that they said we could setup what ever schedule we
>wanted. We also have a "Mount Host" at the DR site. It is part of the AD
>domain and just has Windows 2003 and EMC Replication Manager/SE on it. It
>is also connected into the SAN.
You can use Replication Manager/SE to set up scheduled 'jobs' to
create or update remote copies of your data.
The EMC manuals are usually pretty good at explaining how to use the
software functions. If your system isn't in production yet, you could
use the time to experiment and try different things without too much
risk.
If it is in production, I strongly recommend you attend some training.
EMC run these courses all the time, your Dell sales rep should have
access to them.
>So I just need some "ideas" on how to do what we want to do. I am trying to
>understand the difference between SANCopy, SnapView and MirrorView and when
>I should use which.
In a nutshell...
SnapView = creates local clones or snapshots on a Clariion array
Clone = complete block level copy of your source volume/LUN. The size
of a clone is the same as the size of the source.
SnapShot = *virtual* point-in-time copy of your source volume/LUN. The
size overhead for a snapshot depends on the rate of change of data in
your source volume/LUN. A high change rate will consume more disk
space than a low change rate.
MirrorView = essentially is a remote version of the SnapView Clone
function. It creates (and updates) a block level copy of the source
volume/LUN on Array #1 to another volume/LUN on Array #2. MirrorView
is required on both arrays and works on CX400/500 and above.
SANCopy = In your case, allows you to push data from the source
volume/LUN on your CX500 to your CX300. It will also allow you run
incremental updates from the CX500 to the CX300. Think of it like a
backup copy to a remote disk. SANcopy only needs to run at the 'push'
end of the link, in your case on the CX500.
There is a version of SANcopy, known as SANcopy/E that is light enough
to run on the CX300 and would allow you to push data back to the
CX500, if you ever wanted to do that.
Hope this was useful.
HVB.
| |
| Dave Sheehy 2006-01-14, 2:46 am |
| HVB (hvbnntp@googlemail.com) wrote:
: SnapShot = *virtual* point-in-time copy of your source volume/LUN. The
: size overhead for a snapshot depends on the rate of change of data in
: your source volume/LUN. A high change rate will consume more disk
: space than a low change rate.
When snapshots are made is any effort made to ensure that the snapshot is
started at a point where the file system on that LU is in a consistent state?
If not, it seems like the snapshots carry a risk associated with them that
when a problem is detected the file system may not guaranteed to be in a
consisten state on some (and worst case all) of the snapshots. If it does
ensure the file system is in a consistent state then how does it detect this?
Dave
| |
| Maxim S. Shatskih 2006-01-14, 2:46 am |
| Microsoft's VSS (Volume Shadow Service) solves this by notifying the VSS
aware apps (MSSQLServer, Exchange, some Windows-embedded database engines) that
the snapshot is about to be created. For instance, SQL server can do the
checkpoint and stall all disk writes before snapping, and continue normal work
after snapping.
Without the VSS-aware snapshot engine (and VSS-aware apps), the write
inactivity timeout is the only way.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
"Dave Sheehy" <dbs@rtl.rose.agilent.com> wrote in message
news:1137095084.310031@newsreg.cos.agilent.com...
> HVB (hvbnntp@googlemail.com) wrote:
> : SnapShot = *virtual* point-in-time copy of your source volume/LUN. The
> : size overhead for a snapshot depends on the rate of change of data in
> : your source volume/LUN. A high change rate will consume more disk
> : space than a low change rate.
>
> When snapshots are made is any effort made to ensure that the snapshot is
> started at a point where the file system on that LU is in a consistent state?
> If not, it seems like the snapshots carry a risk associated with them that
> when a problem is detected the file system may not guaranteed to be in a
> consisten state on some (and worst case all) of the snapshots. If it does
> ensure the file system is in a consistent state then how does it detect this?
>
> Dave
>
|
|
|
|
|