Fractional Reservation – LUN Overwrite (Continued)

I seem to get questioned about Fractional Reservation at least once a week, and find myself explaining it over and over. I have found quite a simple way of explaining this now, unfortunately much of the documentation doesn’t make it quite so simple to understand. I’ve got a much better understanding of what it actually is now. It makes more sense as NetApp have changed it’s description in some places, in Operations Manager 3.7 and above it’s now referred to as “Overwrite Reserved Space”.
This is easiest to explain with pictures. We should have all seen a standard snapshot graphic. When we snapshot the filesystem, we take a copy of the file allocation tables and this locks the data blocks in place. Any new or changed data is written to a new location, and the changed blocks are preserved on disk.

So basically a snapshot locks the data blocks of the data referenced by it in place. This means that any new or changed blocks (D1 in the above graphic) in the active file-system are written to a different location. This concept is fundamentally the same as what Fractional Reservation is.

As the LUN gets filled up with data, we take a snapshot and that data is locked in place. Potentially all this data could change, and we need to guarantee not only this existing data, but also the potential that we need to write totally new data blocks. Any changed data gets written into the Fractional Reservation area rather than into the area that the existing LUN data is in. (I know that in reality this is spread across all the disks and these areas don’t actually exist, but it makes it easier to visual and understand explaining it this way). As changed data blocks are written, old data blocks get preserved in the snapshot reservation area. Fractional Reservation is preserving the maximum rate of change we could potentially get.

Don’t confuse this with the snapshot reservation area. The snapshot reservation includes saved data blocks from previous snapshots, where-as the Fractional Reservation is protecting your Active File System (AFS in the above graphic) from it’s own potential rate of change.

So the reason a LUN may be switched offline if the fractional reservation area is set to 0, is that the filer needs to protect the existing data that is locked between the active file system and the most recent snapshot, plus any additional changes that happen to the active file system. If the volume / LUN / frac-res and snap reserve are full, then this space is not available and the filer needs to take action to prevent these writes from failing. The filer guarantees no data loss, but with no space free and nowhere to write the new data, it has to offline the LUN to prevent the writes from failing.

So fractional reservation is in constant use by the filer as an over-write area for the LUN. Without it, you need to make sure that sufficient space is free to allow for the maximum rate of change you would expect. Defaults are good, but trimming down on these you need to monitor the rate of change and make sure the worst case scenario is within a buffer of free space that you allow. If you reduce the Fractional Reservation to 0, you need to make sure the rate of change is within the volume size, or you need to make sure the volume can auto-grow when required or even snap auto-delete to reduce the reserved blocks and free up space (although I am not a huge fan of snap auto-delete for various reasons).

And that is Fractional Reservation!

Quick last thoughts… A-SIS won’t make any difference to the Fractional Reservation area as such, but it can help as the data blocks within the LUN will get de-duped, but the Fractional Reservation area per-se would always be required as you need this LUN over-write area for changing data. If you reduce the footprint of the non-changing data with A-SIS, you reduce the potential reservation area required. Space savings aren’t apparenty when you have things thick provisioned. Reducing Fractional Reservation andthin provisioning can be a dangerous game.

This was changed when SnapManager (SnapDrive) was released. If you use SnapManager (SnapDrive) 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.

The most important rule is to monitor and understand your data. If you understand your rate of change, you can tweak a lot of areas of the storage system.