2009-10-20 06:56 AM
I have noticed in NetApp documentation that they recommend making the snap reserve 0 on SAN and iSCSI volumes? Why is that? I see that recommendation a lot, but no explanition as to why. I would think that it makes sense to have space reserved for SnapShots? Why does it only make sense to reserve space for SnapShots on CIFS volumes but not iSCSI and SAN volumes?
I'm getting ready to implement NetApp SnapMgr for VI, so I want to make sure I have my volumes set correctly.
Solved! SEE THE SOLUTION
2009-10-20 07:58 AM
see the below post wriiten by NetApp expert chris which will explain about SAN LUN's in iscsi & FCP on volumes.
2009-10-20 08:05 AM
This was changed when System Manager was released. If you use System Manager to create volumes etc then it will automatically apply the best practices to that volume when it is created, for SAN the best practice is to have 0% snap reserve for that volume.
When using CIFS or NFS the snapshot reserve is needed because the filer manages the share, it presents it out to the users. For example if you have a share of 100Gb on CIFS with a 10% SS reserve then the space actually available for writing to by the users is 90Gb (as 10% is reserved).
However, this is different when creating a volume which has a LUN inside of it. You create the volume and then place the LUN inside of the volume, the LUN is now managed via iSCSI (in this case) by a server with the filer only taking care of the presenting of the LUN. In this case you must size your LUN accordingly to leave enough space in your volume for a snapshot, you reserve the space.
If you were to have a space reserve on this volume then you would actually be reserving 2 blocks of space, think of it this way.
One thing to note btw is when you create a LUN using SnapDrive, it will ask you how large you want the LUN to be and how many snapshots you wish to keep. It will then create the volume with the LUN inside for you. Looking at this volume on the filer you will see that the volume size is equal to the LUN size + however manay snapshots you wish to retain but it has 0% snap reserve.
Hope this helps
2009-10-20 09:14 AM
Yep, very good point (and very good reading as well)
I'd add only one thing to that - an immediate take away before any extensive studies:
Please do not confuse snap reserve with fractional reserve, as these are two different things!
2009-10-20 10:54 AM
In reality, snap reserve exists for one real reason and that reason is very NAS-focused. That reason is that when people delete space, they like to see the free space go up.
With snapshots that doesn't necessarily happen (or at least the amount isn't typically equal) since WAFL is holding blocks back to keep the snapshots.
Enter snap reserve. By blocking off space in the volume that doesn't count for the active filesystem, you can account for those held blocks in the snap reserve (not move them, just account for them there..this space is virtual, not specific physical blocks). Now you can "free" the blocks in the active filesystem and your space goes up and everyone is happy as long as the snap reserve doesn't hit or exceed 100%.
Now, in the SAN/blocks space, users don't see volume free space as free space. They see free space inside their LUN. So what is snap reserve winning for you? Not much. Especially when you have features like autogrow and autodelete to help manage the volume space. Using these features are far more space efficient as you're just dealing with volume space at the end of the day anyway, so why reserve the space up front and let much of it sit unused and inactive?
Anyway, that's my simplest explanation for it. Hope it helps.