NetApp Thin Provisioning
In this tutorial we take a look at NetApp Thin Provisioning. Thin provisioning allows you to present more logical storage to your clients than the amount of physical storage you actually have. Instead of allocating space up front, storage space is dynamically allocated to each volume, or LUN, as data is written.
GET YOUR FREE eBOOK
Step by step instructions on how to build a complete NetApp lab, all on your laptop for free.
Sign up to get the eBook and occasional newsletter updates. Your email address will never be shared.
Let’s say we have a 10 TB aggregate in which we create a 500 GB volume and then write 100 megabytes of actual data into the volume. If this was a thick provisioned volume, the system would report that the volume in the aggregate is taking up the full 500 GB worth of space.
If it’s a thin provisioned volume, it would only show 100 MB of space being taken up in the aggregate, which is the actual amount of data that was written.
Traditional provisioning pre-allocates storage, but thin provisioning provides storage on demand. This allows us to move from a “just in case” model to a “just in time” model when we’re purchasing disks.
Traditional Storage Allocation
Let’s say that I’m the storage administrator at a company and the server team come to me with a request. They’re going to be deploying a new workload and they request 200 GB worth of storage space for the server that this is going to run on…
Let’s also say that I’ve dealt with this server team before and I know that they sometimes underestimate their storage requirements. It can be a pain when that happens. It would mean having to take the workload offline to add additional space, so I want to make sure I avoid that happening. Instead, I’m going to actually provision 400 GB worth of storage for them.
Although this would be giving me a safety net, this particular storage system/disk array may not have that as an available allocation unit size. I discover the closest available allocation is 500 GB and I end up provisioning that.
This means that much of the additional 300 GB I’ve allocated (and paid for) may never be used and is therefore wasted.
Even worse, in the real world we’re not going to have only one server. We may have ten servers like you see here.
The same situation is happening on all of them. We really require 2 TB of storage space, but we’ve ended up paying for 5 TB. These are physical disks that we had to pay for. Not only did we need the capital expenditure up front to buy them, they’re also taking up rack space in our data centre as well as requiring power and cooling, so we’ve got the operational expenses as well.
How Thin Provisioning Works
This is where thin provisioning comes in. We can get some great benefits here. We’re looking at exactly the same situation again, but now rather than paying for 5TB worth of physical space, I just create a 2TB aggregate.
In there, I’m going to have ten logical volumes which are thin provisioned with a size of 500GB each. As far as the clients are concerned, they have 500GB worth of disk space available, but rather than paying for 5 TB, I’ve only paid for 2.
How Space Allocation in FlexVol Volumes Works
Let’s consider how the space allocation in our flexible volumes works. In the example below, we’ve got a single aggregate which has three flexible volumes in it.
NetApp ONTAP uses the WAFL (Write Anywhere File Layout) file system, with the ‘Write Anywhere’ meaning we don’t have any fixed blocks on disk. Whenever a client write request comes in for any volume, it can be written to the next available block. We don’t have fixed blocks for the different volumes. Writes are written sequentially in a first come, first served manner.
Combining Thin and Thick Provisioning
Thin and thick provisioning are not mutually exclusive with each other on the same aggregate.
If we go back to the example with ten servers from earlier, maybe two of those servers are mission critical and we want to make sure that they’re definitely going to have the full 500GB available to them. In that case we can make two 500 GB thick provision volumes for those mission critical workloads in the same aggregate. Our other eight volumes are each going to be 500GB thin provisioned. One TB’s worth of space will be reserved for the two 500GB thick provision volumes. The 1 TB that I have left will be available on a first come, first serve basis for the remaining eight thin provisioned volumes.
The Importance of Monitoring Capacity
Using thin provisioning puts more onus on you, the storage administrator, to monitor your capacity usage. The thin provisioned clients in our example will see that they’ve got 500GB worth of disk space, but it’s possible that we can run out of physical space in the aggregate before they actually get there.
The users are not going to be warning you that they’re running out of space ahead of time. You’re going to need to monitor this more carefully yourself.
Thin Provisioning for LUNs
As well as volumes, we can also enable thin provisioning for LUNs. There’s a potential issue with this, caused because hosts manage the file system themselves on their LUNs. As a result, the host and the storage system may report the used space differently.
Let’s see how it works. We’ve got a LUN in the example below.
The client writes two files to the LUN and each file consumes 25% of the LUN space. The client will report that 50% of the space is used. The storage will also report 50% of the space is used.
Then, the client writes a third file to the LUN.
It consumes 25% of the LUN space as well. The client now reports 75% of the space is used. The storage also reports 75% of the space is used. Now, you’re probably thinking, “Well, duh. Of course!” but this is where things get a little bit more complicated.
The client then deletes files one and two, but it doesn’t actually delete the blocks on the storage. It just marks them as being available to be overwritten, so the storage system doesn’t know they’ve been deleted.
The client would now report 25% of the space is used, but the storage would still report 75% of the space as being used. Then, the client writes a fourth file to the LUN. It’s also 25% of the LUN space (bear with me here, we’re nearly there!).
The client will report that 50% of the space is used but the storage will now report 100% of the space is used. Most hosts will end up using all of the space in the LUN like this. At this point, it’s no different to having it thick provisioned. You’re not going to get any space savings.
To resolve this problem, NetApp has reclamation technology. Client side software such as SnapDrive and SnapManager can free up the blocks they’re not using on the storage system, leading to space savings from thin provisioning again.
See my next tutorial to learn about the space efficiency techniques Deduplication and Compression.
Understanding Thin Provisioning from NetApp
Text by Alex Papas.
Alex Papas has been working with Data Center technologies for the last 20 years. His first job was in local government, since then he has worked in areas such as the Building sector, Finance, Education and IT Consulting. Currently he is the Network Lead for Costa, one of the largest agricultural companies in Australia. The project he’s working on right now involves upgrading a VMware environment running on NetApp storage with migration to a hybrid cloud DR solution. When he’s not knee deep in technology you can find Alex performing with his band 2am