Cheers for the feedback Chris,

Another point you reminded me to make is with the SMAI auto-delete stuff. The  triggers can sometimes be a bit too slow for it to successfully free-up enough  space. Snap auto-delete from within SMAI requires deleting not only snapshots,  but also backup records and saved logs files. This process could be seconds to  minutes, and during this time the extra space could be essential (depending on  your limits set).

I'd always set vol auto-grow to give you some padding in there, and I'd agree  with keeping frac-res to 10% in SMAI environments.

Also if you change the fractional reservation, yes you can't change the  volume guarantee (at all), so it's best to shrink the volume in actual size, and  use vol auto-grow as needed.

Although the documentation does a good job of explaining technically what  Fractional Reservation does, I get a lot of questions about it still. Frac-Res  still seems to be a bit of a dark art, and most people just accept it as a given  overhead, but the more we encourage people to reduce it, the more I think you  need to fully understand what it is, and how it affects the storage  system. Hence why I came up with the above description. Hopefully it adds some  clarity for people.

Cheers...

The FR area is a safety net to prevent your active filesystem not having anywhere to write it's data. In your example if you have marked the snap reserve area as 100g (20% of the 500g volume), then no, FR would not overwrite to that area, but may in some cases reserve all the spare space in the volume. If you are using something like SnapDrive and you have reduced your snap reserve to 0% and leave SnapDrive to sort it, then yes, it will use the calculated extra space for the FR. But then that simply means you haven't sized your volume correctly. If you have 50% rate of change, then you need to size the volume accordingly. But through your example, at no point has the filer put your data at risk. Your existing snapshots are protected, and your Active Filesystem is also protected and has a guaranteed area to make new writes. If a new snapshot was allowed, then both these areas could be in danger, at which point the filer would protect against any data loss by offlining the LUN (drastic, but the only way if you have no auto-del / auto-size policies in place).

Moving onto your next comment around SnapManager monitoring. As Chris Holloway mentioned, it's best to drop your FR down to 10% and then enable monitoring within SnapDrive and SnapManager. You need to make sure you have the correct versions of both SnapDrive / SnapManager and OnTap to support this (I'll have to look it up if you want to know). But basically this will monitor the rate of change within the volume, which can be taken from FR (which is why it needs to still exist and not be 0%). If you have a very high rate of change, then 10% may not be enough to trigger an auto-size or auto-delete, so size accordingly (in your example, 50% rate of change is very high!).

I am told that the SnapManager Snap Auto-Delete feature can be a little slow in processing, so if you do have a higher rate of change, then in may not kick in quick enough to allow you the required free space. Really these tools should be used as a get out of jail card though, and not a daily routine. The volumes should be sized to accomodate all the snaps you want to store online at any time.

Personally I am not a big fan of the snap auto-delete feature. If you have an unexpected high-rate of change, what are the chances that this was caused by something abnormal in the system? If it is abnormal in a bad way, then the one thing you want most of all is as many online backups as possible, so for me, snap auto-delete could be slightly counter productive. But that is just my personal opinion

I like volume auto-grow and you can use this outside of any SMAI integration and use it direct either with SnapDrive or on the command line. This is much more reliable and is a great get out of jail free card on those odd occasions where something unexpected happens, but gives you head room to keep your systems online and stable. If you are looking to start playing with reducing FR and using these features, this is where I'd start.

On the volume options on the command line you can tell it whether to try vol auto-size or snap auto-delete first, and it will try both if it needs to. You can also tell it to defer deleting user created snapshots too, but that can be counter productive if you have a snapshot that you've forgotten about and is causing the volume to grow!

I would agree that the whole process can be quite confusing though. It's taken me awhile, and on some technical sides the above description may not be 100% technically accurate, but I have found that it is the easiest way to visualise and understand what the FR process is all about. Ultimately I think you need to understand that before you can start modifying the levels and policies.

I may well work on a follow up blog entry to this that goes over the finer points of space monitoring and the vol auto-size / snap auto-del policies. This is a hot topic at the moment! I went through with a customer the other day and we saved them 6TB simply by dropping the FR on their filer estate!

Okay cool!

So yes, you are right, it doesn't make entire sense! Chris Holloway followed up with a comment to highlight the point you are making. The FR is a safety net. So when all else has failed, we can still guarantee writes to your LUN volume. So yes, it will write to the free space (even if you have reserved this in your head for snapshots) for writing data to. In reality we don't need to guarantee 100%, so we can tweak this setting, and it has always seemed a little bizarre the way this works, but it is the best way for the filer to guarantee your data and backups.

Back to your example, yes you are completely right, you would run out of space before being able to take the next snapshot. It would probably be more likely to do this if you have snapshots already, but yes, ultimately you will run out of space. Which is why traditionally sizing with FR at 100% can seem very wasteful, and is sometimes a bit of effort to justify. Consider the cost savings of having online backups is usually a good one, but now this is becoming a harder sell, so by reducing the FR, and having dedupe, thin provisioning and everything else, we have a fantastic message and we can really tweek every byte out of the system.

Hope this helps? But feel free to post some more

Totally understand you! I had a very unfortunate experience with a customer who didn't listen to any of our recommendations and just dropped everything to 0% and left it. Sure enough it all went offline! But they quickly learnt.

And I agree totally, it is very difficult to guage rates of change with new customers. Especially with Exchange as it does online defrags all the time!!! I would generally ask a customer to run a system at 100% for atleast a month and then we'd come back and review the setup and make the adjustments as necessary. Sometimes it can highlight poor system design. I still have customers insisting that they need to do entire SQL database reloads every week as that's how their application was coded!!! Crazy!!!

FR is sometimes a difficult concept to come in on new, especially if the customer has never used a NetApp system before as it is very different in many of its concepts. So the learning curve tends to be very high, and so tweaking these settings aren't necessarily recommended for the first timer. But that is the main reason for the above blog post!

No problem at all buddy, I'm always happy to have like-minded techies around, and the questions help us both learn. I actually have to think about stuff for a change!

Okay, quick example of enabling volume autosize

Firstly the syntax for you...

No I have my Exchange database volume, currently it is 500g, but I want to enable volume autogrow to increment in 10g chunks to a maximum of 500g.

I also want to make sure that the filer will try the autosize first and not the snap autodelete (if anyone in NetApp is reading this, it'd be nice to use the same naming conventions through-out autosize here, volume_grow there )

And we can see that "try_first" is by default set to volume_grow. Then finally we can verify the setting.

And just to be clear, this process is totally independent of SnapDrive or SnapManager. Ultimately they are goign to trigger a snapshot on the filer, and the above mechanism is based on snapshots, so we are all good, and it should work fine. The best thing, is it should be transparent to SnapDrive, SnapManager and the end user!

So if you have a new customer that doesn't really get it, set up some policies with enough headroom to cover the unexpected, and make sure the customer is monitoring things atleast a little bit. Even if you are keeping FR at 100%, this mechanism really wouldn't hurt. What is more important to the customer, free space on the disks or Exchange / SQL being completely happy?

Setting the trigger is a very good question, and I'm going to have to look into it. I believe that the trigger is when a snapshot would fail, and so it triggers the mechanism. I'm not sure if you can define that you want your volume kept to 85%, although you can with snap autodelete funnily enough! The following article - https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb6973 - shows that the setting is defined by "wafl_reclaim_threshold", and I'm just trying to find what/where that actually is!

Sizing SnapInfo is fairly straight forward once you know how much logs data they generate. The Windows volume: Logs DB size * num logs online to keep + a bit for system databases and a bit more headroom. The NetApp FlexVol gets sized in a similar way, taking into account how many snapshots you'll be keeping online as opposed to how many logs you will be keeping, the default is 7 days worth of snaps I believe.

It shouldn't be too tricky to calculate a customers rate of logging, although remember SQL logs are a database, so they may change when you stick SMSQL in there as you may truncate them more often. In many cases, when you start taking snapshots, you'll want to do a db-shrink the first time to get it down to size. This needs a bit of thinking about and calculating, the way SQL does it's logging is sometimes totally lost on customers (and some engineers I've found )

What version of SnapDrive are you using?

Matt Robinson has posted a great blog article which is probably a good follow on from anyone reading through this - http://communities.netapp.com/blogs/ServiceBytes/2009/03/23/fsr-in-action

That's a decent high level view of FR, but not sure if it's too technically accurate.

The AFS is protected by fact of it being a LUN, but if your snapshots get out of hand, they can indeed inpeed on the available space that the AFS has to write into. That's a key area where fractional reserve gives you some head room. Snapshots can, and do regularly grow into the Fractional Reserve space.

Fractional Reservation is really space for the AFS to over-write existing data, which is why Operations Manager terms it as the LUN Over-write sapce.

There is a pre-assigned place for it, but as with all things NetApp, this is just an area of space that could exist anywhere on the disk. Disk space assignment is always extrapolated from physical placement on the disks, so in NetApp terms the space for FR and Snaps are definitely pre-assigned, just not physically. Similar memory / CPU reservations in VMware where space is reserved, but not physical blocks, just the assumption that a certain quantity is not used by other areas.

Sorry to get granual with that, I think I'm splittin hairs a little. I've gotten wrapped up in FR a lot the past year or so, and I tend to get stuck on the detail!

Definitely agree with your description of events. I've seen it happen on a few other odd cases, but generally you're right, it's be caused by the AFS growing quicker than expected and as such using up extra space, or causing the FR to reserve more space than expected.

I agree the simpler you can explain FR, the better and easier it is to understand. But a lot of the rules around FR and snapshots tend to be a little flexible, and tend to be at the whim of the AFS. Ultimately the Active File System is the most important thing to the filer, and the filer gives this ultimate priority.