Managing LUN Space Requirements with NetApp Storage

If you’ve worked with Network Appliance storage before, you’re probably already familiar with the idea of snap reserve (storage space set aside to accommodate for Snapshots) and fractional reserve (used with LUNs). I’m going to hold the in-depth discussion of why you need snap reserve and fractional reserve for a different day, but I did want to pass on these commands that were shared with me by a colleague of mine. These Data ONTAP commands, available with Data ONTAP 7.2 or later (some commands are available in Data ONTAP 7.1), will help you manage the space requirements for LUNs on a NetApp storage area network (SAN).

I’ll try to explain the commands along the way, but I would recommend you review the documentation available from the NOW site for more complete information.

vol options <volname> fractional_reserve 0

This command sets the fractional reserve to zero percent, down from the default of 100 percent. Note that fractional reserve only applies to LUNs, not to NAS storage presented via CIFS or NFS.

snap autodelete <volname> trigger snap_reserve

This sets the trigger at which Data ONTAP will begin deleting Snapshots. In this case, Snapshots will start getting deleted when the snap reserve for the volume gets nearly full. The current size of the snap reserve can be viewed for a particular volume with the “snap reserve <volname>” command.

snap autodelete <volname> defer_delete none

This command instructs Data ONTAP not to exhibit any preference in the types of Snapshots that are deleted. Options for this command include “user_created” (delete user-created Snapshot copies last) or “prefix” (Snapshot copies with a specified prefix string).

snap autodelete <volname> target_free_space 10

With this setting in place, Snapshots will be deleted until there is 10% free space in the volume.

snap autodelete <volname> on

Now that the Snapshot autodelete options have been configured, this command will actually turn the functionality on.

vol options <volname> try_first snap_delete

When a FlexVol runs into an issue with space, this option tells Data ONTAP to first try to delete Snapshots in order to free up space. This command works in conjunction with the next command:

vol autosize <volname> on

This enables Data ONTAP to automatically grow the size of a FlexVol if the need arises. This command works hand-in-hand with the previous command; Data ONTAP will first try to delete Snapshots to free up space, then grow the FlexVol according to the autosize configuration options. Between these two options—Snapshot autodelete and volume autogrow—you can reduce the fractional reserve from the default of 100 and still make sure that you don’t run into problems taking Snapshots of your LUNs.

If you have a NOW login, you can get more information on Snapshot autodelete here; more information on volume autogrow is available here. Be aware that SnapDrive may require different settings in order to accommodate its functionality, as it moves LUN management out of the storage system and onto the host. Finally, the values presented here are only examples; be sure to use values that are appropriate for your environment.

Credit for compiling this list goes to my colleague Chauncey Willard. Good work!

Tags: , , , , ,

  1. Eric Watkins’s avatar

    Hiya Scott,

    Just thought I would give a quick and easy explanation for the fractional reserve (as well as why you need to be careful tuning the fractional reserve setting)

    the WAFL file system that Data OnTap uses actually writes a new block for any change. It will not modify the existing blocks. So for example you have a 100gb database in a 110gb lun and you re-index it, every change it makes results in a new block being created. That means you need 100gb of space set aside since the filesystem doesnt modify any blocks.

    With that said, you would need 220gb of space in the volume holding the 110gb lun which has the 100gb database in it just to allow you to re-index a database. (lun size + 100% of space for the new blocks to be created). If you want to take snapshots you need to add space beyond that.

    You should only reduce the fractional reserve setting is you are ABSOLUTELY sure your changes will never exceed the amount you specify. In other words if you expect you will never change more than 50% of the blocks in a volume you could set the reserve to 50%. Most database applications (such as sql and exchange) require or recommend that you leave the fractional reserve at 100% (to account for upgrades that may re-index the databases, defrags, etc)

    Hope that helps :)

  2. slowe’s avatar

    Eric,

    Thanks for the explanation. You’re mostly there… :)

    One slight correction: to my understanding, WAFL only allocates new blocks for changes when the existing blocks are locked by a Snapshot. Existing blocks can/may be overwritten if they are not locked by a Snapshot. So, fractional reserve and snap reserve are only required when Snapshots are going to be taken.

    The default setting of 100% for fractional reserve ensures that you can take a Snapshot of a LUN and then be guaranteed that you can overwrite every single block in the LUN. To maintain more than one Snapshot, you’d need more than 100% space, hence the extra 20% for snap reserve.

    Thanks for the comment!

  3. TimH’s avatar

    One note I’ll add regarding reducing fractional reserve to zero is the requirement for solid management best practices surrounding the storage appliance(s).

    It’s all good if the client has a dedicated storage admin, appropriately trained with the tools and time avialable to proactively manage the appliance. This however, is often the weak link for some smaller customer’s whose network admins wear many hats and are likely not to be looking at the thing on a regular basis. In smaller environments I’m inclined to speak with the person who manages SQL or Exchange, explain fractional reservation and let them decide, based on their knowledge of the environment and how well it is managed.

    Just a thought…

    -Tim-

  4. slowe’s avatar

    Tim,

    As with so many other areas of technology, there’s always more to it than just the technology. Being sure that the storage admin is aware of the repercussions of reducing fractional reserve and/or snap reserve is a must in any environment. Thanks for pointing that out!

    Take care!

  5. Gary Taylor’s avatar

    Here’s some more information to help folks understand Snap Reserve and Fractional Reserve when using LUNs in a FlexVol.

    Fractional Reserve should be renamed “Space to Protect the LUNs from going offline when writing changes after a snapshot has been taken”
    Okay that’s too long but it makes more sense that Fractional Reserve!

    You can quite happily work away with 0% Fractioanl Reserve without any issues as long as you have not taken a snapshot the volume.

    Also, Snap Reserve becomes a redundant parameter as soon as you create a LUN and change the Fractional Reserve from 100.

  6. Sreekanth’s avatar

    Hi Eric, your explanation on Fractional reserve had cleared my clouds….

    Thanks a Ton

    Regards
    Sree……..

  7. Ian’s avatar

    What is the best practice for fractional space reserve when LUNS are being provisioned for ESX datastores? Let’s say we’re using SnapManager for VI to backup our VMFS datastores. Hypothtically speaking, I could snapshot the VMFS datastore (technically the underlying volume) and some activity could cause all of the blocks in the VMFS datastore to change – so the underlying volume would require room to store all these changed blocks (locked by a snapshot).
    It’s odd but Ive never treated fractional reserve the same way when I provision LUNS for workloads like Exchange, SQL as compared to provisioing a LUN for ESX.

  8. Ankur Madaan’s avatar

    Ian

    The best practice would be, as I undertsnad from discussion above, and my experience, 100 %. But it wastes way too much space.

    What we have done as a policy in our organization is to ask our databases and VM administrators to let us know when they are re-indexing or re-configuring, or else face the repercussions – a LUN gone offline !

  9. Reg’s avatar

    In reference to the comment

    snap autodelete target_free_space 10

    With this setting in place, Snapshots will be deleted until there is 10% free space in the volume.

    Reading this suggests, snapshots will be deleted until 10% of free is is available in the volume

    At what stage will snapshots begin the snapshots deletion process? Is there another disk space % somewhere that determine when the process begins?

  10. Rakee’s avatar

    Can any one explain about “SNAP RESERVE” detaily

    Please it was urgent!!

    Thanks in Advance!!

    Rakee

  11. Yannick’s avatar

    Hello,

    So if we take snapshots of an exchange database which has for exemple 10 gb… we need to create a volume that has neccesary 20 go ?

    Thank you for your help.

    Yannick.

  12. Kirk’s avatar

    Hello.

    Great info thanks,

    So am i right in saying that the best practice calculation would be:

    volume = 2 x requested lun size + 20% for snap reserve?

    Many regards

    Kirk

  13. JZ’s avatar

    hi,

    How to enable the Lun Space Reserved?

    (current: disabled expected: enabled)

  14. Charles Semple’s avatar

    So am I right in thinking that if you’re not using snapshots at all that the fractional reserve can safely be set to zero?

    I’m still backup using Backup Exec to backup at the OS level so I don’t use any snapshots on my Exchange and SQL LUNs yet I’ve been too scared to reduce the fractional reserve.

    I do however use Snapmirror to copy to a DR filer. I’ve seen this uses snapshots. Am I right in presuming this too would use up the fractional reserve?

  15. dave’s avatar

    Yes if you’re not using snapshot you can turn off snap and fractional reserve, however make sure vol options nosnap is turned on and that your snapshot schedule for that volume is zeroed out.

    @JZ
    Lun Space Reserved or (fractional reserve) is disable for if volume guarantee is file or none. In fact fraction reserve only works if you allocate the entire space up front. Which kind of defeats Netapp hype about thin provisioning.

    We have begun setting fractional reserve to zero and using the snapshot options to make up for it. This way we can thin provision a LUN and not worry as much about it going off line due to snapshots, which is in and of its self quite absurd. Also we have had issues with snapdrive creating a slightly larger lun would fit in the volume with 100% fractional reserve and having the lun go off line.