This post is more than 5 years old
130 Posts
0
1464
Snap volumes in DMX
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.
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.
xe2sdc
2.8K Posts
0
October 3rd, 2008 06:00
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.
AranH1
2.2K Posts
1
October 2nd, 2008 12:00
xe2sdc
2.8K Posts
0
October 2nd, 2008 14:00
julieg1
305 Posts
0
October 2nd, 2008 16:00
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
srichev
130 Posts
0
October 3rd, 2008 05:00
Secondly what is the bedt way to size Savvol,while creating the snaps?
srichev
130 Posts
0
October 4th, 2008 05:00
xe2sdc
2.8K Posts
0
October 4th, 2008 10:00
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.
xe2sdc
2.8K Posts
0
October 8th, 2008 12:00
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
srichev
130 Posts
0
October 8th, 2008 12:00
https://powerlink.emc.com/nsepn/webapps/btg548664833igtcuup4826/km/live1/en_US/Offering_Technical/Technical_Documentation/300-000-876_a07_elccnt_0.pdf
Refer to the section:Page 4-24
srichev
130 Posts
0
October 9th, 2008 05:00
I couldn't locate the Primus or the guide mentioned.When i was looking for primus it's taking me back to this chain.
Message was edited by:
srichev
xe2sdc
2.8K Posts
0
October 9th, 2008 06:00
for.He wants SRDF/A between primary and secondary
site.In secondary site he would like to have hourly
snaps.In case of any corruption with data,failover to
R2 side and they woud like to restore it back from
the snaps.Advise,If it is possible with SRDF/A.
You need a BCV to decouple SRDF/A writes against R2 devices and SNAP devices. But you need to terminate snaps before establishing BCV again .. Why don't you use clones ?? Hourly clones instead of hourly snaps ..
mentioned.When i was looking for primus it's taking
me back to this chain.
Probably a temporary issue .. or a browser issue .. Unfortunatly we can't paste primuses (since they may change at any time)
I usually search primuses dropping their name in the "quick knowledgebase search" applet, choosing to limit search in Support Solutions ...
You can find manuals following this "path" ..
Home > Support > Technical Documentation and Advisories > Software ~ S ~ Documentation > Solutions Enabler > General Reference
Message was edited by:
Stefano Del Corno
srichev
130 Posts
0
October 9th, 2008 06:00
Also you answered my other question.Snaping to the BCVs needs to be terminated so it's of no use and it seems there is no way to keep hourly snaps on R2 except making additional BCV/clones.If i understand correctly since there is a lag of time between R1 and R2 we couldn't get a consistent PIT on R2 so no snaps.
Thank you for your help.
xe2sdc
2.8K Posts
0
October 9th, 2008 07:00
it?
You have options .. however it's hard to give directions from behind my LCD display ..
You can use "slow" RAID5 7+1 devices as clone target (thus "wasting" less space). However note that slow clones may keep tracks locked in cache (waiting to be copied from SRC to TGT) thus slowing down SRDF/A cycles (and putting more pressure on R2 and R1 cache). Use "slow" 7+1 devices only if your application on R1 side isn't writing heavily. As a rule of thumb, if you have RAID5 R2 devices, you can use similar target devices.
correctly since there is a lag of time between R1 and
R2 we couldn't get a consistent PIT on R2 so no
snaps.
I suspect it's something very different .. The main issue here is that R2 is updated in "bursts" (when the R2 side receives a complete "cycle"). But when you receive a complete cycle, you need to apply it to R2 devices ASAP. Snaps forces the storage to move tracks from SRC to TGT before staging writes and I suspect that's the point that hurts SRDF/A