Last week, I blogged about discussions I’ve recently had with NetApp and NetApp customers about the company’s messaging and products. One of the focal points of the debate was what users understood about best practices for overhead on FC LUN snapshots. A couple of users I’d talked to prior to reporting on NetApp’s analyst day event said NetApp best practices dictate at least 100% overhead on FC LUNs, but that NetApp salespeople tell them a different story before the sale.
However, when I followed up with NetApp, officials told me in no uncertain terms that their most current best practices for FC LUNs dictate the same snapshot overhead as any other type of data: 20%.
After posting on this, I got another response from a NetApp customer disputing those statements that seems worthy of adding to the discussion. Here’s the message verbatim:
Netapp is being a little disingenuous. The overhead for SNAP shots is recommended to start at 20% but for LUNs Netapp’s best practices recommends an additional 100% (Fractional Reserve) be available for overwrites after the snapshot is taken.
So 100GB LUN needs 20% for snap (changed data) + 100% for overwrites. If Fractional Reserve is set at 100% (according to Netapp best practices) the first snapshot of a 100GB LUN will reserve 100GB of free space in the volume for future overwrites. This space is reserved until all the snapshots are deleted. Note that Netapp LUNs are files that reside on volumes with a growth/size limit and not partitions like traditional storage arrays from HDS or EMC.
Here is what Netapp says in their Thin Provisioning White Paper. For LUNs used by applications like Databases Netapp recommends that the Fractional Reserve be set at 100%. A lot of the Netapp sales people don’t understand how it work or avoid the subject.
Fractional reserve is a volume option available in Data ONTAP 6.5 and later that determines how much space Data ONTAP will reserve for Snapshot overwrite data for LUNs and space-reserved files. The default value is 100%. Data ONTAP removes or reserves this space from the volume as soon as the first Snapshot copy is created. For example, as shown in Figure 4 on the left-hand side, a 100GB volume is shown with two 20GB LUNs. Assuming the LUNs are full and a Snapshot copy is created, Data ONTAP by default will reserve 40GB (2 x 20GB) of space in the volume to assure that there is always enough space for both the LUNs and all the Snapshot data, even if the LUNs are completely overwritten. This is depicted in the middle of Figure 4. As depicted on the right-hand side, if fractional_reserve is set to 60% when the Snapshot is created, instead of reserving 40GB in the volume, Data ONTAP will reserve only 24GB (60% * [2 x 20GB])
NetApp has not yet responded to my requests for comment.
NetApp has responded with the following comment:
The best practice for Snapshot overhead (for LUNs) has been changed based on the availability of a feature called Snapshot autodelete. This feature, available since the introduction of Data ONTAP 7.1, is a volume setting that allows policy based deletion of Snapshot copies. With autodelete turned on, there is no longer a requirement for 100% overhead. Actual Snapshot overhead requirements should be based on the data change rate, the number of snapshots taken and the duration of time that the Snapshots are required. Based on these parameters, the actual Snapshot overhead will vary. Since Data ONTAP writes changes in 4KB increments, Snapshot space utilization is very efficient.
Peanut gallery, feel free to weigh in.