Hi all,
Peter Smoot of Net App provides the following clarification and exposition concerning DOT LUN snapshots for your reference. I neglected to mention the "delta" functionality in my earlier post and have confused the space reservation with "mirror": even though for storage capacity consideration it's 100% like what a mirror will require, technically LUN snapshots only contain changed blocks as in the case in CIFS/NFS qtrees, not themselves a block by block copy as in a RAID 1 configuration.
Pou
************* From Peter *****************************
A LUN snapshot really is just like a NAS snapshot. The snapshot itself only grows as blocks get written to the LUN, so if you take a second, third, fifth snapshot, you don't use up five times the space of the original LUN. Essentially, as you overwrite blocks in the LUN, we move the old block into a snapshot, grab a new block from the volume free space, and write the new data in that empty block. We don't actually move anything around on the platters, it's all done with pointers so it's very fast.
The original 100% growth is something called the "space reservation". This space gets reserved so that after taking a snapshot, you can overwrite every single block in the LUN and know you've got space to hold that write. The above algorithm really is "grab a block from the volume free pool, but if that's empty, use a block from the space reservation". The trick is once the volume has no free blocks and you've started using the space reserve, you won't be allowed to create new snapshots.
...
Internally, this is refered to as "2x plus delta". The 2x is the original LUN plus it's space reserve, for a total of 2x the size of the LUN. The delta is the number of snapshots times the data churn rate, which could be greater or less than the size of the LUN, depending on many factors.
DataONTAP 7g has a volume setting called a "fractional_overwrite" which lets you reserve less than 100% of the LUN size in the space reserve. If you know most of your LUN isn't being overwritten, then a much smaller space reserve is fine. DataFabric Manager (DFM) 3.2 (available in about two weeks) has a bunch of monitoring to track how much space you've reserved and how much of the space reserve you're using, so you can tell whether you're reserving too much, too little, or just about right.
******************** End ***************************
Hi Rob,
FC/iSCSI LUN's in DataONTAP (DOT) implementation differs from CIFS/NFS qtrees in that they are block based rather than file based since LUN's need to be accessed in that manner on the client sides.
Hence LUN snapshot is a misnomer. It is actually a mirrored LUN of the original, in more conventional terms. Thus it requires 100% more storage space for each "snapshot" per LUN. The additional 20+% in my understanding is the buffer space DOT needs to cache the block IO's. I think this 20% is per volume but it will increase if there are many LUN's and much IO activity. I was advised to leave at least 30% to accommodate such IO-intensive situations.
Since the snapshot is a mirrored LUN, any block change in the original LUN is propagated to the snapshot in due time, i.e., after being cached/buffered first before written to disks. You can certainly reduce this buffer space down but at your own risk as usual since it will impact performance of the original LUN by taking away buffer/cache improvement for it not to mention that of the snapshot IO process.
I have not created 28-disk RAID-DP volumes yet but have investigated this option for one of our Engineering efforts. A special license is required since it is not normally recommended either for technical rational or business justification, i.e., to sell more disks for parity usage. From the white papers that I read, DOT LUN is still based on WAFS, thus the need for 20 - 30% disk based buffer. This could be the reason Net App PS advises of lack of significant difference in operational functionality and performance between the 28- and 14-disk RAID DP.
At the same time with more disks in a LUN, reconstruction in theory should either consume more CPU cycles or take longer for both orthogonal and diagonal (these are my own terms for the lack of official terminology that I have found so far) parity calculation since there are more spindles and blocks to go through for RAID-DP. So I will expect longer rebuild time for 28-disk set than 14-disk one. At the same time, RAID-DP plus at least a hot spare should decrease the possibility of the need for such reconstruction to practically zero short of catastrophic disasters according to Net App literature, so maybe that's why the difference here is not practically significant.
Pou
RE:
Imagine my surprise upon discovering that the space reservation for LUN snapshots is 120%, instead of 20% to 30% for a file system. I think I understand why. I wonder what the practical field experience is with trimming that figure down to something the guy who paid for the NetApp will accept.
Specifically, if what is on the LUN is a relatively stable NTFS file system, is "blocks changed" similar enough to "files changed", or are there "catastrophic events" that go out and touch many disk blocks at once, thus mandating the huge space reservation?
If you under-allocate the reservation, then all disk blocks are suddenly written to, can you configure the NetApp to release the snapshots and commit the writes, or must it look like a premature disk full condition?
It seems like a much more economical path will be to ignore the SnapDrive approach, ignore snapshots, and just use Volume Shadow Copy on the windows servers hosting the filesystem. This would get my space reservation back down to 20% to 30%. Any thoughts?
Oh, a bonus question: I had a NetApp PS guy recommend 28-disk RAID-DP over 14-disk RAID-DP, saying that there is absolutely no significant difference in re-build time or any other down side. Any thoughts on that?
Thanks!
/// Rob
Rob Winters SAIC, NASA Headquarters ISEM Contract