ONTAP Discussions

LUN Space Reservation - needed?

seno
9,013 Views

Hi,

I'm looking for some recommendations on space reservation for LUNs. We've run into a situation on some LUNs created some time ago (before I got here) where the space reservation is set to 100% but there isn't enough room on the volume for the overwrite protection to match the LUN size. So while the exchange folks see plenty of disk space on their end, I'm getting alerts for volumes running out of room. From the stuff I've read the water's a bit murky on if this overwrite protection is needed or not for a LUN. Am I going to have to grow all the volumes big enough to contain the overwrite reserve, or can I limit the reserve to 10 or 20 percent and not impact the space exchange sees and can write to in the LUN? Can I turn off Space Reservation on the LUN and not impact the LUN's performance?

10 REPLIES 10

adamfox
8,973 Views

Hi Scott:

Here's the deal with space reservations or more precisely, the problem they try to fix and more importantly other ways of addressing the same problem. Bottom line, space reservations are never needed unless you choose to use them as a way to solve this problem.

The problem, which is not unique to NetApp SAN, but any SAN product that allows snapshot technology is that when you take a snapshot, you have to save blocks as they are deleted or changed. You have to store those blocks somewhere and that space can run out. Let's say you delete a bunch of blocks inside of a LUN. The host believes those blocks are free, but in reality, those blocks must be kept somewhere as long as a snapshot points to them. So if you run out of physical space in the storage when the host thinks there is space in the LUN, that's a problem.

The way most SAN vendors deal with this issue is through a choice or combiination of 2 features. One is auto-grow. As the space to store the blocks get low (in the case of NetApp, it's thecontaining FlexVol, others may use a separate area, but the concept is the same), you automatically grow that space. Of course you set policies around that growth (thesholds, grow by how much, and to what ulimate size). This simply adds more blocks to the pool. One of the neat things that NetApp brings to the table here that many SAN vendors do not is that if you fix the situation (a snap falls off or you choose to delete it) and blocks become free, NetApp gives you the ability to shrink the volume back down to where it was while keeping all the other snapshots around. Many vendors cannot do this without deleting all snapshots.

The second method is snapshot autodelete. So as space fills up, you delete older snapshots until you have sufficient space again. NetApp also has this option. Most storage systems, NetApp included allow you to use these methods together, (say grow first, then start deleteing). But the important thing to know is you can use either or both of these methods with NO space reservations. You'll want to keep an eye on your volume usage just in case, but the storage system will handle the vast majority of the cases just fine.

Now, NetApp offers you a third option. Many years ago, this was the only option but that hasn't been true since 7.1 was released and introduced autogrow and auto delete. This 3rd option is using space reservations. By reserving space up front in the volume that is only used once the rest of the volume is filled up, you can always have free blocks because once you start using the reserved space, new snapshots are failed so all blocks that are used in the reserved space will never be in a snapshot thus they can be freed if the host frees the corresponding block in the LUN (this assumes 100% reserved, you can set this value lower if you know your environment and choose to do so). Space reservations don't really impact performance, they just give you a cushion against this condition.

So, many customers don't use space reservations at all. And if you don't take snapshots in that volume, you don't need to do any of these things.

Anyway, I hope this helps.

ianaforbes
8,972 Views

Great explanation Adam. Space reservations is probably one of the most misunderstood things with Netapp. I've been using Netapps since 1999 and I still sometimes struggle to wrap my head around it 🙂

Great explanation Adam. Space reservations is probably one of the most misunderstood things with Netapp. I've been using Netapps since 1999 and I still sometimes struggle to wrap my head around it 🙂

An important thing to take away (that Adam mentions) is that space reservation is never used unless the available space is the volume has been completely used. So, if you have a 300GB lun and every block in that lun changes you'd better have enough room in the volume to account for the changed blocks. This can be accomplished either by growin the volume, deleting snapshots, a combination of the two, or space reservation.

I personally think that while fractional space reservations less than 100% is handy in order to grab more available space in the volume it's difficult for new Netapp customers to understand that they have to be more leary in tracking their space usage. Setting aside the "old" best practice of 100% size of the lun guarantees that if the worst case scenerio of every block changing happens, the lun won't go offline.

While auto-growing the volume is great, there might not be extra space in the aggregate to accomodate the request. Deleting snapshots might not free up enough space. Having a 100% space guarantee will guarantee that writes are successful. At this point you're only concerned with available space in the volume for snapshots (assuming snapshot reserve is 0%).

Don't get me wrong. I love the options to autogrow and delete snapshots and set space reservation to anything < 100. It's just that I've found that customers getting used to Netapp technology don't need additional stuff to worry about. That's why I recommend 100% space reserve during sizing exercises. Once they get used to WAFL and Netapp technology AND how their applications actually utilize the storage they can make modifications to fractional reserve (maybe even setting it to 0%) and recapture space back into the aggregate from the volume(s)

Adam - one thing I didn't quite understand from your statement was, 'new snapshots are failed so all blocks that are used in the reserved space will never be in a snapshot thus they can be freed if the host frees the corresponding block in the LUN (this assumes 100% reserved, you can set this value lower if you know your environment and choose to do so).'

So, I have a 300GB lun and set fract reserve to 100%. I write 300GB to that lun and take a snapshot - the snapshot locks those same 300GB blocks in the active filesystem AND sets aside 300GB for space reserve. Now, every block in that lun changes. Those changed blocks get stored (assuming no free space in the volume) in the space reserved area. At this point there is no space in the volume. If I were to grow the volume by 400GB would I be able to take a snapshot of that changed data? I ask because you said that blocks used in the space reserved area will never be in a snapshot. If that's the case how do I protect that new data?

ianaforbes
8,972 Views

I think I answered my own question 🙂 I assume that if I grow the volume that I'll be able to store the snapshot in the available space. I guess you're just saying that the space reserved area will never allow those blocks to be captured by a snapshot (unlike the active file system). So, the take away would be that snapshots will NEVER be stored in space reserved space - just have enough room in the volume for snapshots.

adamfox
8,971 Views

Hi Ian:

I think you get it well. If you used up all 300GB of space (you have 150GB LUN with 100% reservation, for example), you cannot take any new snapshots because you are using your reservations space. If you then add 400GB of space, now you've got at least 150GB of free space in the volume (i.e. your reserve space) so you can continue to take snapshots because you've got space to store the snapshot data.

seno
8,973 Views

Thank you Adam! That was the information I needed to put it all together.

tomas_netherlands
8,973 Views

Currently i am diving in this LUN Space Reservation, because a customer asked me about it.

From my point of view LUN Space reservation has nothing to do with snapshots in the first place.

LUN Space reservation which you can set to off, enables thin provisioning.

When you set LUN reservation to on at a new 20 GB LUN it will claim that 20 GB immediately. If you do not set the LUN reservation, it only claims as much data from the Volume in which the LUN resides as data is written to it.

Let's say you have a Volume of 100GB and a 20 GB LUN. In the 20 GB LUN with no space reservation, 5 GB of data is written. The volume will show 95 GB of free space

When setting space reservation to on, the volume will show 80 GB of free space eq it will claim 20 gb immediately even when there is no data on it..

In fact this is used to use over-subscription on your storage, because maybe people demand more storage then they actually need or use.

When you do not set the LUN reservation, it is called Thin provisioning. Netapp wrote an excellent Technical Report on this. You can find it here:

http://media.netapp.com/documents/tr-3483.pdf

In the case of snapshot overwrite data the term must be "fractional reserve". When set to on, it claims 50% of the volume to be sure a complete LUN can be recovered from a snapshot.

Please correct me if I am wrong I know there is a lot of misunderstanding about these terms!

adamfox
8,971 Views

Just be sure that you don't confuse volume gurantees with lun space reservations. Thin provisioning is typically done at the volume level and is done with volume gurantees. So, for example, if you set gurantee to 'none' you will only chew up space in the underlying aggregate as you consume it in the volume as opposed to the default where the space in the aggregate is allocated at volume creation time (or resize as the case may be).

With lun space reservations (fractional or otherwise), this is your snapshot overwrite protection. I suppose you could call this thin provisoning of LUNs, however, it's only thin if you assume that all LUNs must have a reservation space, which techically isn't the case.

I hope I haven't confused the issue here. 🙂

ianaforbes
8,971 Views

I think the biggest misconception/confusion lies around terminology. Space reservations actually means different things depending on what you're talking about. There's the space reservation when we're talking about thin provisioing either the volume or the lun. There's also space reservation when talking about guaranteeing writes to LUNS.

A lun space reservation to me could also mean that I'm talking about thin provisioing my lun (reservation = none), or it could mean I'm setting my reserve to some value of 100% or lower to guarantee writes.

There's definitley a lot of confusion around that terminology. Techniacally, all luns don't need to have a reserve, but that's only a recent enhancement. I personally feel that there needs to be clarity when talking about space reservations.

tomas_netherlands
8,971 Views

Ian,

Thanks for clearing this out for me. I was about to contact a shrink for going nuts about this terminology.

Hopefully someone is going to write a whitepaper about the confusion. Or Netapp has to change the terminolgy to make things more clear.

Tomas

ianaforbes
5,679 Views

Hehe...I used to have a full head of hair before dealing with space reservations 🙂

Public