An Overview on Thin Provisioning

Whether it be at work or in my personal life, I like to plan ahead and be readily prepared. Specifically, when it comes to allocating storage, you definitely need to strategically plan your allocation. This is where Thin Provisioning comes in—organizations can adopt this strategy to avoid costly problems and increase storage efficiency.

Efficiently optimizing available space in storage area networks (SAN) is known as Thin Provisioning. Thin Provisioning allocates disk storage space between multiple users based on the requirement by each user at a given time.

Days before Thin Provisioning:           

Traditionally, admins allocated additional storage beyond their current need—anticipating future growth. In turn, admins would have a significant amount of unused space, directly resulting in a loss on capital spent on purchasing disks and storage arrays.

Applications require storage to function properly. In traditional provisioning, a Logical Unit Number (LUN) is created and each application is assigned to a LUN. Creating a LUN with the traditional method meant a portion of empty physical storage space from the array is allocated. For the application to operate, space is then allocated to the application. At first, the application will not occupy the whole storage space allocated, however gradually the storage space will be utilized. 

How Thin Provisioning Works:

In Thin Provisioning, a LUN is created from a common pool of storage. A LUN in Thin Provisioning will be larger than the actual physical storage assigned to the LUN. For example, if an application needs 50GB of storage to start working.  50GB of virtual storage is assigned to the application so that the application can become operational. The application uses LUN in the normal procedure. Initially, the assigned LUN will only have a portion of the actual needed storage (say 15GB) and the rest—35GB will be virtual storage. As the actual utilization of storage grows, additional storage is automatically taken from the common pool of physical storage. The user can then add more physical storage (based on requirement) without disturbing the application or altering the LUN. This helps admins eliminate the initial physical disc capacity that goes unused.

A use case:

Consider an organization that has 3 servers running different applications—a database, a file processing system, and email. All these applications need storage space to work and the organization has to consider storage space for future growth.

While using traditional provisioning, and say each application needs 1 TB each to operate. But out of 1 TB only 250 GB (25 %) will be used initially and the rest will be utilized gradually. With the whole 3 TB already allocated to the existing 3 applications, what happens if you need a new server/application in the organization? In this case, you will need more storage and unfortunately, it won’t be cheap—you will need to search for budget.

Now let’s look to see how thin provisioning can help with the aforementioned situation.  For example, in this scenario each server/application is provided with a virtual storage of 1 TB, but the actual storage space provided is just 250 GB. The space from the storage is only allocated when needed. When a new server/application is added, you can assign 250 GB from the physical storage space, but the server/application will have a total 1 TB of virtual storage. The organization can add the new server/application without purchasing additional storage. Also, increase the physical storage as a whole when needed.

Thin provisioning has 2 advantages in this use case:

• Adding a new server/application is no longer an issue.
• Avoid provisioning a total of 3 TB while setting up the servers. The organization can start with 1 TB and add more storage space as and when needed without disturbing the setup. 

When to use thin provisioning:

This type of provisioning used is more related to the use case and not technology. Thin provisioning is beneficial in the following situations:

• Where the amount of resources used is much smaller than allocated.
• When the administrator is not sure about the size of the database that needs to be allocated.
• Situations when more servers/ applications often get added to the network.
• When the organization wants to reduce the initial investment. 
• When the DB administrator wants get maximum utilization from their storage.

Thin provisioning is not the silver bullet in the virtualization world. It too has its limitations. For example:

• In regards to performance, this becomes a major factor—thin provisioned storage becomes fragmented very easily, in turn decreasing performance.
• Storage over allocation—the actual storage during thin provisioning can result in over allocation. Further, any write operation can bring a terrible failure (which cannot be repaired) on one or several drives.

Even though thin provisioning has drawbacks all these can be overcome by continuous storage monitoring. Now what you need to do is transform your ‘fat’ volumes to thin ones. But there are issues that can arise while doing so. Have you experienced any issues while moving your storage? If so, how did you resolve your issues?