Dr. Toaster's Answer: It is important to first understand the concept of disk space reservation. The simplest way to explain that is to think of a regular magnetic disk drive - it has addresses that hosts can refer to in order to read or write data - and hosts can always send I/O write commands to these data block addresses again and again - that's the whole idea of an address space.
The WAFL filesystem has a different write allocation policy - when you keep snapshots - point-in-time views of the same filesystem, WAFL keeps blocks untouched, so that one can recover from snapshots that reference these blocks.
So to connect the story here - LUNs are implemented on top of WAFL - so when snapshots are being taken, if a host (that is totally unaware of this virtualization) is writing data consistently into a LUN, more and more data blocks will be held "captive" by the snapshots. This is where space reservation algorithms kick in - to protect this behaviour from causing SCSI write errors to LUNs - by default, every LUN consumes its original size plus another 100% of its size as well as a protection against this rare case of frequent writes into a LUN on a volume with many snapshots created.
The simple solution to enable the expansion of the LUN is to enlarge the size of the underlying volume - with FlexVols that would be an easy change. If there is not enough disk space in the aggregate, one can reduce the amount of space reservations per volume using a command such as:
vol options vol_name fractional_reserve 80
where 80 is a number below 100. Note that if snapshots will be taken and the rate of changes in the volume will be higher than 80% then SCSI writes to the LUNs may fail - in which case the filer will take the LUNs in the volume offline, and manual action will have to take place to clean up space (most likely by deleting some snapshots) and online the LUNs again (lun online lun_pathname).
A few other important notes:
1. Use the following commands to review the status of space reservation:
df
df -r
snap delta
2. Data ONTAP 7.2 adds another solution which is to allow volumes to automatically clean up old snapshots and/or grow:
vol options vol_name volume_grow on
vol autosize vol_name -m 1000g -i 1g on
where 1000g is the maximum size that the autosize feature will allow the volume to grow to, and 1g is the increment.
The autosize feature will try to increment the volume size by 1GB increments, and if the aggregate is full it will try to delete snapshots. It is also possible to start with deleting snapshots by using the snap_delete policy instead of the volume_grow I suggest above.
5 comments:
Initially I had to make my volumes 200% as large as my total LUN size to get Snapmirror to initialize. Now I want to reduce the volume size but was afraid to reduce the fractional reserve in case somebody copied out a huge file, etc.
So based on this, I take it an acceptable course of action would be to examine the latest delta's, determine a more reasonable reserve and reduce the volume size. At that point I can set my volume autosize to a max of 200% of the LUN size and I should be OK?
Yes, I believe you're on the right track. My assumption - you are entering an area that most people don't enter - it should all be covered, I just don't have direct experience managing a live environment with these features used.
In essence, SnapMirror updates are just consumers the same as client updates...
I don't see this option in 7.2
vol options vol_name volume_grow on
I think just the vol autosize command will do the job
You should also be aware of the df -A (yes, capital A) command. This shows the reserve on an aggregate. Not always used, you can remove the reserve on an aggregate. However, you should determine if you will be using before deleting.
I'm new to ONTAP and the SAN world, my company just got an IBM/NetAPP SAN and need good resources to learn this technology. So far, your blog has been a great!! help. Thank you very much and keep up the good blogs, especially on daily admin advise.
Post a Comment