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.

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

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

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.

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.

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 to ;

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.

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.

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.

good to know. Thank you

In my environment we have multiple SRP comprised of multiple type of disks . Still all data is written to SSD disk. I don't see any movement of data from SSD to FC disk . Is it normal behaviour in VMAX3 ?