Determine your vSphere storage needs – Part 1: Capacity

Currently I’m working on a project where I have been asked to determine the storage requirements for a new storage solution. The customer is going to run a VMware vSphere 6 environment in a active-passive twin datacenter setup.

As I was gathering the customer requirements I thought to write a blog post how this process goes will I’m working on it.

When designing a vSphere storage setup you have to design the following sections.

1. Capacity
2. Performance
3. Availability
4. Security
5. Connectivity

Let’s start with the first one, capacity.

Capacity is the easiest part of the design and with most storage solutions it’s easy to extend. You can use the following formula to determine your total RAW capacity storage need:

^{((TotalVMs * (OSDriveCapacityGB + AvgMemSizeVMNotReserved)) + TotalDataGB) * (RestoreCapacity% + SnapshotReserveCapacity%) = TotalGB}

For example:

• You have 1000 VMs.
• Every VM has a C-Drive (or root) of 50GB.
• The average memory size of a VM is 8 GB where nothing of is reserved.
• You want to reserve 10% for backup restores.
• You want to reserve 5% for snapshots.
• Total data capacity is 50TB

This makes:

^{((1000 * (50GB + 8GB)) + 50TB) * (10% + 5%) = 88,14 TB}

This is the RAW capacity available to the VMware vSphere hosts, and doesn’t take RAID overhead, and storage features like thin provisioning, deduplication and compression into account. These storage features are most of the time reasons for a discussion whether if you want to use these features and what the impact on the performance is.

Using features like compression and deduplication depend on the use case.

I can imaging that you want to use compression and deduplication for archiving purposes, and not for production virtual machine like MS SQL or SAP because of the potential performance impact.

The type of RAID level used by the storage solution implicates the RAID overhead and how you size the storage solution. Do you configure 1 large container containing all disks? Or do you create multiple containers? This again depends on the type of storage solution, and the capacity and performance requirements you have. The performance part I will cover in a later blog post. For now we focus on the storage capacity.

VMware has 3 type of VMDKs.

• Thin
• Thick (Lazy)
• Eager Zero Thick

I’m not going to explain in-depth the VMDK type because this I well covered in Death to false myths: The type of virtual disk used determines your performance, Thin or thick disks? – it’s about management not performance, and http://www.vmware.com/pdf/vsp_4_thinprov_perf.pdf blog post.

If you’re going to use thin provisioned VMDKs in you environment you can subtract the free space from your RAW capacity needs. Do take into account that thin VMDKs will grow and you have to monitor the free capacity of your storage solution to make sure that it won’t fill-up. This will result in virtual machines who will be unavailable.

So how your (new) storage solution is going to provide your RAW capacity depends on the type of storage solution. In my opinion you have to talk with your storage vendor what is the best configuration based on your company needs.

What you do need to take into account is how easy it is to extend the capacity of your storage solution. The new storage solution probably will run for the next 5 years. No way that you can determine the capacity need for the next 5 years. And when you have to add capacity, do you have to reconfigure storage pools, LUNs and/or RAID groups? Can this be done on the fly without impacting production workloads?

Of course performance definitely will impact the setup and configuration of your storage solution. This I will cover in a later blog post.