8 Krypton

Snap volumes in DMX

Jump to solution
Hi,
While creating snaps it was asking me to create the vdev with the same size as original volumes.Is n't snap uses the very less space and uses Savvol for all the data to store? am i doing something incorrect?Please advise.
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
8 Krypton

Re: Snap volumes in DMX

Jump to solution
If you need 4 different snaps for a single "real" device, you need 4 vdevs. You guessed right ;-)

When it comes to savedev size .. We have guidelines that request a little analysis of your actual environment.

You need to know the "change rate" of your devices .. % of data that changes in a single day. You can use our symchg (deltamark) tool to find how many tracks changes on your DMX devices.
Now, having already found what's the % of data that changes in a day, do a simple math ...

SAVEpool-size=REAL-data-size * %changerate * number-of-sessions * expected-life-of-snaps

If you have 1 Tb of data and your changerate is 5% (low change rate) and want to keep 2 different snaps for at least 4 days, your SAVEpool size is

SAVEpool-size = 1024 * 0.05 * 2 * 4 = 409.6 Gb

Obviously you can always add more space, just to have room in case of errors or unpredictable changes on your devices.

Now you have the total size of your SAVE pool. Simply divide by the number of devices you can create (and this is the hardest part of the task). Try to create as less savedevs as possible. If possible, create as many savedevs as your DA boards. However prefer a single big SAVE device against many small devices on the same drive in the backend (just to avoid head contention). SAVE devices tend to be as write intensive as your application .. 2-way-mirror gives you good write performances even on save devices. If your workload isn't that write intensive, you can choose RAID5 3+1 SAVE devices.
0 Kudos
13 Replies
8 Krypton

Re: Snap volumes in DMX

Jump to solution
VDEVs are virtual, they don't actually consume disk space. You need to create the same size and number of hypers that you will be snap'ing, and if you are using metas you create metas out of your VDEV hypers that match the source.
8 Krypton

Re: Snap volumes in DMX

Jump to solution
As Aran already said you create VDEVs with the same size as original volumes .. The code will translate your request in correct vdev size (about 1/600 of real size) but will always report vdev size as original size. This allows you to easily create them (you don't need to do your math before creating vdevs) and easily match them when you want to create snaps of your data.
0 Kudos
8 Krypton

Re: Snap volumes in DMX

Jump to solution
Dear srichev,
I've moved this thread from the Powerlink Lite users forum into the Symmetrix one since you are now registered as a customer and have full access.
Julie Gibson
Forums Admin
0 Kudos
8 Krypton

Re: Snap volumes in DMX

Jump to solution
Thank you Aran and Stefanno for the response.That helps.One more question addition to this.If i am planning to create 4 snaps then i need to create 4 vdevs.Is this correct?
Secondly what is the bedt way to size Savvol,while creating the snaps?
0 Kudos
8 Krypton

Re: Snap volumes in DMX

Jump to solution
If you need 4 different snaps for a single "real" device, you need 4 vdevs. You guessed right ;-)

When it comes to savedev size .. We have guidelines that request a little analysis of your actual environment.

You need to know the "change rate" of your devices .. % of data that changes in a single day. You can use our symchg (deltamark) tool to find how many tracks changes on your DMX devices.
Now, having already found what's the % of data that changes in a day, do a simple math ...

SAVEpool-size=REAL-data-size * %changerate * number-of-sessions * expected-life-of-snaps

If you have 1 Tb of data and your changerate is 5% (low change rate) and want to keep 2 different snaps for at least 4 days, your SAVEpool size is

SAVEpool-size = 1024 * 0.05 * 2 * 4 = 409.6 Gb

Obviously you can always add more space, just to have room in case of errors or unpredictable changes on your devices.

Now you have the total size of your SAVE pool. Simply divide by the number of devices you can create (and this is the hardest part of the task). Try to create as less savedevs as possible. If possible, create as many savedevs as your DA boards. However prefer a single big SAVE device against many small devices on the same drive in the backend (just to avoid head contention). SAVE devices tend to be as write intensive as your application .. 2-way-mirror gives you good write performances even on save devices. If your workload isn't that write intensive, you can choose RAID5 3+1 SAVE devices.
0 Kudos
8 Krypton

Re: Snap volumes in DMX

Jump to solution
Can the same Savpool calculation be used while creating an SRDF/A except number of snaps? On the snap side,Is it allowed to have snaps on the R2 volume or do i need to create a BCV for R2 and then perform the Snaps?
0 Kudos
Highlighted
8 Krypton

Re: Snap volumes in DMX

Jump to solution
SRDF/A have little if nothing in common with snaps .. You can use symchg to have a rough idea of needed link throughput .. But SRDF/A is a lot far from snaps, IMHO :D

You can't take snaps on the R2 side of SRDF/A replica. As you mentioned, you need to take a PIT copy of your R2 devices (and that's why we have BCV devices) and then take snaps of the BCV device.
8 Krypton

Re: Snap volumes in DMX

Jump to solution
Refer to this document.This says snapcopy can be created for R2 volume by using an option -rdf -vdev
https://powerlink.emc.com/nsepn/webapps/btg548664833igtcuup4826/km/live1/en_US/Offering_Technical/Te...

Refer to the section:Page 4-24
0 Kudos
8 Krypton

Re: Snap volumes in DMX

Jump to solution
S.E. 6.2 isn't really "brand new" ;-)

However as per primus emc175656, as of 07/23/2008 you can't take snaps of SRDF/A R2 devices.

While it's perfectly legal and supported to take snaps of R2 SRDF/S devices, you can't take snaps of R2 SRDF/A devices.

If you look at table 30, S.E. manual P/N 300-000-877 rev A10, you'll quickly find that "Consistent" isn't listed as an allowed SRDF state while talking about Snaps.

Hope it's clear as mud ;-)
0 Kudos