dynamox
7 Thorium

Questions about all Flash VMAX3 and SLO/SRP

Hello guys/gals,

I have an all flash VMAX3 (2 engines) and will be migrating onto it from VMAX20K. I have been going through a lot of VMAX3 documentation and have the following questions:

1) If my plan is to continue using EFD only disks, should i even bother with configuring SLO ? If i am reading correctly with only one SRP my storage group will be associated with it and managed under the default "Optimized" SLO. ?  Any negatives that my storage group will not be "FAST managed"  even though there is only one tier of storage ?  There is no "FAST movement" withing SRP if it is comprised of the same disk type/protection ?

2) In the past we have always fully allocated thin devices, i can see it's still an option when i create new devices. On VMAX20K i have always created fully allocated devices and dropped them into a storage group and done. I don't think anything would change from that perspective on VMAX3 ?

3) Do folks typically rename their SRPs ?  Default SRP is named SRP_1, no harm in me renaming it to SRP1 for example ?

Are there other questions i should be asking ?

Thank you

Labels (1)
10 Replies
KW160
3 Argentum

Re: Questions about all Flash VMAX3 and SLO/SRP

1)  From a data placement perspective, you're correct. It won't matter which SLO is applied since the all the data must lie in the only pool available. From a management perspective, you may still want to apply the Diamond SLO so that the Unisphere workload planner will be able to tell you if the array can handle additional workload.

2) Yes, you can still create fully allocated volumes in the same manner as you did in the previous generation. The performance difference should be negligible on VMAX3.

3) No, I am seeing most people keeping the default SRP name. In fact, it is actually not possible to change the SRP name with Solutions Enabler or Unisphere. You can only change the SRP description. It may be possible via BIN change, but it might be disruptive.

If you're planning on using Timefinder, make sure you read up on SnapVX. It is very flexible and negates the need for full clones in most situations.

dynamox
7 Thorium

Re: Questions about all Flash VMAX3 and SLO/SRP

Thank you KW160

KW160 wrote:

3) No, I am seeing most people keeping the default SRP name. In fact, it is actually not possible to change the SRP name with Solutions Enabler or Unisphere. You can only change the SRP description. It may be possible via BIN change, but it might be disruptive.

I am running symcli 8.1.0.8 and this is what i see in man pages for symconfigure, typo ?

Renaming a Storage Resource Pool (SRP):

     rename SRP <SRP Name> to <New SRP Name>;

KW160 wrote:

If you're planning on using Timefinder, make sure you read up on SnapVX. It is very flexible and negates the need for full clones in most situations.

Good timing, i just finished reading "VMAX3 Local Replication TimeFinder SnapVX and Timefinder Emulation"

Since i have your attention i will go ahead and ask a couple of questions regarding that.

1) Currently our "Prod" R1 is SRDF/S to another VMAX,  R1 also has TimeFinder/Clone relationship and the Clone is also R1 to another set of devices on the same VMAX. "Prod R1" is always synching, where "Clone R1" is synched once a week and then suspended.  So in order to provide the same functionality on VMAX3 i will need to use SnapVX in copy mode, so that my "Clone R1" can be an SRDF/S source. "Clone R1" will be re-linked every week and essentially perform incremental establish. Then "Clone R1" will perform incremental sync via SRDF/S.   See any issues, suggestions ?

2) Let's say i have two storage groups, one is used for masking and another one is used for TimeFinder operations. I can see how i can use -sg parameter to create my snapshot but how can i link them to targets ?  Do i still have to rely on device group/file to create that "link" relationship. Target device names have to be "consistent" i assume because they are also my R1.  Thoughs ?

Thank you so much for your time.

0 Kudos
KW160
3 Argentum

Re: Questions about all Flash VMAX3 and SLO/SRP

Sorry about that, you're correct. I didn't scroll down far enough in the Solutions Enabler PDF. I haven't actually seen anyone make this change yet.

1) You have the right idea. Except I don't believe your linked clone of the R1 needs to be in -copy mode. I think it should work fine in normal nocopy mode, although I'm having some trouble finding that specifically stated.

2) You can create a separate target SG used specifically for linking. The criteria is that SG must contain the same quantity and sized TDEVs as the SG used to create the snapshots. Timefinder will automatically link TDEV-for-TDEV based on sizes. If you have multiple devices of the same size you may need to query the session to determining exactly how it performed the links. It will then stay consistent across relink operations.

0 Kudos
dynamox
7 Thorium

Re: Questions about all Flash VMAX3 and SLO/SRP

KW160 wrote:

1) You have the right idea. Except I don't believe your linked clone of the R1 needs to be in -copy mode. I think it should work fine in normal nocopy mode, although I'm having some trouble finding that specifically stated.

this is what i see in the paper

2-2-2016 12-39-37 PM.png

KW160 wrote:

2) You can create a separate target SG used specifically for linking. The criteria is that SG must contain the same quantity and sized TDEVs as the SG used to create the snapshots. Timefinder will automatically link TDEV-for-TDEV based on sizes. If you have multiple devices of the same size you may need to query the session to determining exactly how it performed the links. It will then stay consistent across relink operations.

oh nice, so i can use -lnsg parameter to specify storage group that contains my target devices. It will be interesting to see that if between relink it will continue to pick the same source<>target devices. I don't see an option -exact or anything like that. I need that "pairing" consistency just from documentation/sysadmin perspective.  If it picks source<>target pairing randomly i may have to revert to using device groups/device files. Do you know the answer to this question ?

Thank you

0 Kudos
KW160
3 Argentum

Re: Questions about all Flash VMAX3 and SLO/SRP

OK, I agree with you then on the copy mode needed.

In the past when I've done a "relink" of a target SG, the pairing stayed the same.

0 Kudos
EvgenyM1
3 Silver

Re: Questions about all Flash VMAX3 and SLO/SRP

Hello!

1)Actually you dont have to create the SLO policy, but there is two thing:

  - FAST algorithm has one of the function as pool re balancing for best SRP pool utilization, actually it could be done by Optimized policy, but could not guarantee the best data placement (of course for your all flash drives it is not so important, but I'm not sure if even EMC staff can answer how FAST mechanism works for utilization in case of all Flash approach)

  - second idea is to have better overview of the response time for overall array and storage groups into Unisphere

2)Why are you going to use fully allocated thin devices? in this case one of the idea of thin provisioning (capacity utilization) will not work for you. From another hand you can get some ZERO space from old array. But OR should understand them and remove from portion of data before they will be written to the SRP on VMAX3. in case of host migration you will get some space as ZERO but anyway written to the SRP. If you think that fully allocated device will avoid the problems with performance (you need some time to allocate new track), new arrays are able to write data almost with 0ms response time in case of new track is came to pool. (at your case you have even all-flash array). So actually you can create fully allocated device, cause the same idea, but I dont see the reason for that.

3) As I know EMC doesn't recommend to do anything with default SRP pool (that is strange, but I dont think so that renaming will affect on something (I didn't do that before))

----------------------------------------------------------------------------------------------

About SRDF and Links on SG KW160 is right. Even you dont have to create devices VMAX3 should create them for you as the consistent (by default it is always consistent for VMAX3) clones

0 Kudos
dynamox
7 Thorium

Re: Questions about all Flash VMAX3 and SLO/SRP

1) In an all flash storage array there is nothing for FAST to do, unless it does horizontal movement like VNX where it moves chunks within the same tier to address "hot" spots.  I see the point of still using an SLO if that provides more visibility as far as Unisphere Reporting is concerned.

2) Entire VMAX is dedicated to one huge oracle DB, knowing how Oracle does ASM i expect little to no savings as far as thin provisioning is concerned. It is also a comfort/political decision.

3) If the command is provided in the symcli I think it's safe bet that it's supported and can be used if desired.

Regarding SRDF - i am not using Unisphere for provisioning, everything is done using symcli. So yes, you have to create target link devices, they are just regular TDEVs. I tested snapvx yesterday and there is a "-exact" flag that can be used with storage groups.

0 Kudos
KW160
3 Argentum

Re: Questions about all Flash VMAX3 and SLO/SRP

Regarding #1, yes, the array will move data around within a pool to eliminate hot spots. However that doesn't require any specific SLO, it will happen even if you don't associate one.

dynamox
7 Thorium

Re: Questions about all Flash VMAX3 and SLO/SRP

good to know. Thank you

0 Kudos