Unsolved
This post is more than 5 years old
8 Posts
0
1059
Should we still use Timefinder Clones
Typically we put a Timefinder Clone between the source and the Timefinder VP Snaps. Now with Timefinder VP Snap and ACOFW is there really a benefit to doing this?
Example 1:
Source -> Timefinder Clone A -> Timefinder VP Snap A
Source -> Timefinder Clone A -> Timefinder VP Snap B
Example 2:
Source -> Timefinder VP Snap A
Source -> Timefinder VP Snap B
rawstorage
419 Posts
0
March 28th, 2015 04:00
Depends on you use case, many customers do this to keep a gold copy which they will use for recovery operations and use the vp snap copy for testing. You can modify and refresh your VP snap from your clone without affecting the "Gold Copy".
Both ways of doing things are valid depending on your needs.
cschverigs
8 Posts
0
March 31st, 2015 10:00
Assuming we don't need the "golden copy" are there other concerns with Timefinder VP Snaps directly off the source? ACOFW has removed the write concerns and reads are coming from the thin pools (FAST will move as necessary). Thoughts?
PedalHarder
465 Posts
0
March 31st, 2015 14:00
After reading your initial post, I immediately thought VP SNAP. Use the -consistent option and you will get a goot PIT directly off the source devices. You already have the space to create a SAVE pool that is 100% the size of the source device, so no issues there. Your considerations for implementing VP SNAP are :
- How 'heavy' is the change rate? ACOFW works really well, provided the array isn't under heavy stress. e.g. system write pending value is good (low) and back-end is not over-utilised
- The metadata (track table) overhead for VDEV devices is higher than TDEVS. If you are looking to create a significant capacity of VDEVS, you should have a chat with your local account team around getting a verification that you won't run into any cache issues by the creation of the VDEVS.
rawstorage
419 Posts
0
April 1st, 2015 01:00
Jason,
I think you've mixed VP Snap with Regulare Timefinder SNAP. VP Snap uses the existing Thin Pools to store the delta's and uses TDEV so we don't have the same cache overhead restrictions as with VDEVs and we don't have the added hassle of managing a separate SAVE pool. We use the symclone -vse command set to create and activate.
But you make some great points here..
Cshverigs, I would get your local VMAX performance team to have a look at your VMAX and just ensure that you are not stressed on cache and back end as Jason has pointed out. If you have no requirements for maintaining the gold copy as you have stated then this could be a good opportunity to take advantage of the space savings of the VP Snap. Have them model the number of copies of each group you plan to take and see what they come back with. I suspect they will give it the thumbs up.
Since you're exploring the newer snap technologies you may want to have a look at what we're doing in VMAX3 with SnapVX, it's even more space efficient and is targetless so it's very cache efficient too.
Hope this helps
PedalHarder
465 Posts
0
April 1st, 2015 02:00
Aah yes, thanks for the correction Paul.