Over Committing of Storage Space

In my previous blogs, I provided an overview of thin provisioning and discussed moving from fat to thin with thin provisioning. Now, I’d like to talk about over allocation or over committing of storage space. When you over commit storage it helps enhance application uptime. Further, it makes storage capacity management simple.

What is the over committing of storage?

When VM’s are assigned with storage more than what is actually available, it is known as over-allocation. By this mechanism, applications start their operation viewing more storage than what was actually assigned. For example, say 3 applications need 50 GB each to start operation. With over committing, all 3 can start their operation with just a total 50 GB of physical storage. The remaining 100 GB or more can be added to the storage array when the existing 50 GB’s utilization is increasing.  This way available storage arrays are utilized appropriately.

Some advantages of over committing storage are: 

• It cuts down capital expenditures (capex): Capex will be cut down since storage space that goes unused is very minimal.
• It allows you to dedicate more storage to VM’s than the actual available storage.
• Flexibility of storage: there is no storage limit, more volume can be added as and when needed.
• No trouble of forecasting storage growth: Helps you avoid the trouble of having to predict the accurate growth of volume.

Some disadvantages include:

• Applications halt or crash: When the disk group/groups run into overcommit state (when the physical storage gets utilized 100%), applications will not have free disk to store the processed/collected data, causing the application to crash.
• Adding free capacity can be time consuming: Manual interventions, like adding disk drives are needed to increase free capacity in the disk group/groups. And manual interventions are time consuming.
• Chances for errors: There is a high chance for errors—like when freeing storage by deleting unwanted files or VM’s that are no longer needed, which can cause the loss of a file that had required data.
• Rogue application:  A rogue application can completely bring down the storage as it might rapidly consume the free storage. Just imagine the rouge application sharing the same disk group as a business critical application, such as CRM, ERP, etc.

To get the best out of over committing in thin provisioning and avoid any risk, it’s important to be readily prepared. So always remember to keep a close eye on your storage. By monitoring your storage, it makes over committing and thin provisioning much easier. Furthermore, you should manage your storage or datastore by setting alerts for over allocation, so you quickly receive an SMS or email before something goes wrong. Finally, be sure to set your alerts at a decent %, so you have the necessary time to add more disk to existing storage volume.

  I hope this 3 piece blog series provided you with some helpful tips and information. If anyone has questions regarding thin provisioning, feel free to ask me in the comments section.