FR and space guaruntee on a SnapMirror volume

[marcconeley]

Hi,

Is it possible to set space guarantee to NONE on a snapmirror destination volume which has Fractional Reserve set to less than 100%??

Originally we had an SQL vol with FR set to 100% which we snapmirrored. The destination vol was not thin provisioned, and therefore every time we resize the source vol we have to also resize the destination.

However, now we have reduced the FR to 50% and enabled snap autodelete and vol autogrow - sounds good and works fine. But the problem is that if the vol autogrows, the source will be bigger than the target and snapmirror fails. My way around this was to set space guarantee to NONE on the target volume and thin provision it (so if the source autogrows, the target won't care as long as there is space in the agg).

I am having trouble configuring this though as I see that space guarantee apparently cannot be set to NONE if the FR is less than 100%??? (and when I try and do this on the destination volume it gives an error). Also, it seems that the FR setting gets copied from the source and has to be the same at both ends - so I can't change FR on the target to 100% without also changing it on the source?!

Anyone got any suggestions on the best way to manage this?

Or does the vol autogrow setting that we enabled on the source also mean that the snapmirror target will also autogrow automatically and therefore I don't have to worry about thin provisioning it? (I can't believe this would happen).

Help as always much appreciated!

Marc

[sourav]

Hi Marc,

I will have someone from the SnapMirror team answer this shortly. Please stay tuned.

Regards,

Sourav.

[marcconeley]

Great.

Just to clarify, I guess the question is: if we set FR on a SnapInfo vol to 0%, enable auto-grow and snap auto-delete, then what impact does this have if it's a SnapMirrored volume? In particular, if it autogrows, will the SnapMirror target also autogrow or will SnapMirror fail because the source is now larger than the target?

I look forward to your feedback.

Marc

[radek_kubka]

 In particular, if it autogrows, will the SnapMirror target also autogrow or will SnapMirror fail because the source is now larger than the target?

Good question. According to my best knowledge SM will just fail.

So ideally thin provision SM targets giving them really large sizes (say twice the source). When you actually need to break the mirror, the target will automatically accommodate all characteristics of the source, including size & space guarantee settings (in particular if the source volume wasn't thinly provisioned, so will become the target)

Regards,
Radek

[marcconeley]

Just to be clear here; when you say "thin provision the SM targets" this means create the volume as large as my aggregate for example, and set the space guaruntee to none??

(or is there something more I need to do?).

Also, what happens if my target volume already exists? Will I need to create a new target volume and re-create my mirror?

As I mentioned earlier, I don't seem to be able to change my existing SM target volume to be thin provisioned because FR is set to less than 100% (it copied this setting from my source SM vol) - and when I try to change it I get an error.

I guess I need to create a new vol and re-initialise my SM to use this new thin provisioned target vol?

//Marc

[tanmoy]

Yes create volumes as large as aggregate size and set the guarantee as NONE.

As I said earlier if you are willing to upgrade to ONTAP 7.3.3, then you can set the FR=0 also for such volumes.

[radek_kubka]

"thin provision the SM targets" this means create the volume as large as my aggregate for example, and set the space guaruntee to none??

yes, exactly this & nothing more.

Also, what happens if my target volume already exists? Will I need to create a new target volume and re-create my mirror?

Don't hold your breath for it, but I think that following will work:

- break the mirror

- un-restrict the target vol

- change space guarantee to none & resize accordingly

- restrict the vol

- re-initialize the mirror

And I think all should work without the need for doing the baseline transfer, as SM should still see the original baseline snapshot.

Regards,
Radek

[marcconeley]

Hi Radek,

OK - this i understand so far, but if the source vol has FR = 50%, and I now change the target vol so FR = 100% (so that I can then change the space guaruntee to none & thin provision it) - won't this mean that my target vol actually has to be considerably larger than my source vol?

Therefore in reducing the FR% to get better disk utilization on my filers, I am actually only saving space on my source filer but taking up more space on my destination filer? (if i want to thin provision the destination targets).

Am I making sense?

[radek_kubka · Accepted solution]

Therefore in reducing the FR% to get better disk utilization on my filers, I am actually only saving space on my source filer but taking up more space on my destination filer?

Don't worry, it won't happen.

SnapMirror is block-for-block, so when you replicate your destination won't get bigger than the source. Again, two facts:

- when you break the mirror, the destination will automatically inherit all the settings from the source

- when you set vol guaratee to none, FR is nominally fixed to 100%, but in reality everything behaves like FR is set to 0% (odd, but this is how it looks like)

Regards,

Radek

[marcconeley]

Hi Radek,

Ahh all becomes clear!

Thanks for all of the useful input everyone - yes its a little complicated how this works in practice (especially with FR not been shown correctly), but i seem to have it working.

You're right - the SM targets don't care what space guarantee or FR settings I have on the source - I simply done as you said and broke the mirror, set FR back to 100% & space guarantee to none, and re-synced the mirror. It worked fine.

Now my SM target vols are thin provisioned and its no longer an issue if my source vols autogrow (and yes I am keeping an eye on the aggregate utilization ;-).

Thanks everyone for the help.

Marc

[tanmoy]

From IC.3 onwards you can set FR to any value for NONE guaranteed volumes, rather now the default is 0% for NONE guaranteed volumes. This sould solve your problem.

Provision a NONE guaranteed volume of autogrow size of source volume for your mirror node, if it's IC.3 the FR will be 0% by default. You might need to upgrade to IC.3 which is due in

December/January. If I am not wrong this has been implemented in BR.1 also.

[marcconeley]

I am not entirely sure what you mean with this.

I don't know what IC.3 is, and therefore I would guess I am not using it?

I am snapmirroring between a pair of FAS2020s which are running OnTap 7.3.1.1 - and in this case it's SMSQL which is initiating the snapmirror. We are not using any other NetApp products - just what's licensed on the boxes (ASIS, SnapDrive, SnapMirror, etc).

[tanmoy]

Hi Marc,

I am extremely sorry that I have used the terminology IC.3. This refers to ONTAP version 7.3.3 which is going to be released in December or January time frame. From 7.3.3 onwards you would be able to set the FR to 0 also for NONE guaranteed volumes. The default value of FR is 0 for NONE guaranteed volumes in 7.3.3.

I hope this clarifies your doubt.

Thanks

Tanmoy

[marcconeley]

Hi Tanmoy,

So the summary of all this is: with my OnTap 7.3.1.1 it is not possible to set the space guaruntee to none and the FR to anything less than 100%?. This will only be possible in the new 7.3.3 release.

Therefore with my current setup I will need to either:

- manually grow the SM target every time an auto-grow event occurs on the source vol.

- or, create a new thin provisioned vol as my target, keeping in mind that FR on the source = 0%, but FR on the target has to be 100% (because the guaruntee = none on the target).

Would this be correct?

//Marc

[radek_kubka]

Hi Marc,

So the summary of all this is: with my OnTap 7.3.1.1 it is not possible to set the space guaruntee to none and the FR to anything less than 100%?. This will only be possible in the new 7.3.3 release.

Actually that is NOT the case:

- pre 7.3.3 - a volume when set to space guarantee none displays FR=100%, but in fact FR does not kick in in this case, so the vol behaves like FR would be set to 0%

- 7.3.3 - this confusing thing will be fixed, so in vol properties you'll actually see FR=0%

Does it make sense?

Regards,

Radek

[druddle00]

Hi all,

As per Radeks (and others) advice, in the past I have set SM destination vols to either be huge (2Tb) or the size of the containing aggregate so that you dont have to worry about the source growing.

Dave