How to Right Size your VMFS Datastores in vSphere?

As of time of writing this article we have lots of information on the datastore sizing especially for VMFS. This hasn’t changed too much with new versions of VMFS and if you have taken into account a good buffer of slack space (Usually vary between 20%-30% per VMFS) you should be good with your old calculations.

Let’s revisit some of the parameters you use when you do calculate your VMFS Datastore size.

Total No Of VMs per Lun : The general recommendation for this in server workloads is to have around 40-45 vms , however this is not a final number and this is affected by few of the things mentioned below

  • SCSI Reservations: SCSI Reservation conflicts can happen, if you have lots of parallel power on operations, vMotion, sVMotion etc.  However with VAAI on the new arrays this is much better handled.
  • Recovery considerations: you also need to plan keeping in mind your recovery plans (RTO) , you don’t want to end up in a situation where you are not able to restore VMs within the specified RTO.

Size of the VM Disk: This is driven by what type of function the VM is going to do , however having a standard template does help in these situations. Make sure that you don’t over provision the disk space.

VM Memory Size: We very well know that there is an equal amount of .vswp (swap) file created on the VMFS datastore as the assigned memory of the VM. However if you do have reservations the .vswp file size will be calculated as

.vswp size = (Total assigned VM Memory – Total Reserved Memory)

For Example .vswp size= (4GB-2GB) for a VM with 4 GB assigned memory and 2 GB Memory reservation will be 2 GB.

Other parameters that you look at from the VMFS datastore size perspective is the use of snapshots and some space reserved for bursts , this usually is recommended to be around the 30% mark combining both.

There are few important considerations that you need to take from storage characteristic perspective such as IOPS, Read write ratios, RAID Type, Disk RPM speeds.

To simplify these considerations I have created a VMware VMFS Datastore Sizing Calculator which will take all these values into consideration and give you a figure which you can use in your design and also to speak with your storage architect. One of the important considerations to take when using this calculator is that the calculator is based on some industry standards and your Array vendor may have some variations with the data, in that case please discuss this with the storage vendor and arrive at a proper sizing.

IOPS Considerations for Calculator:

RAID Write Penalty Considerations for Calculator:

Please do take your time and provide feedback for further improvement of the Calculator.

9 thoughts on “How to Right Size your VMFS Datastores in vSphere?

  1. Very good article ….useful info about sizing the Datastore.I believe the snapshot usage and .vswap file are the most critical factors.But snapshot file consumes most of the space if you keep it for longer and affects overall utilization.

    Another factor to be considered is the type of storage : Like HP iSCSI has pros n cons related to thin provisionig. It does not release the space from LUN even your data store is cleaned up.

    I would say situation is worst in case of Cloud environment where you have 1 datastore for each customer. manageability and capacity planning of datastore has a bigger role here

    • Sabyasachi,

      The space reclaim is no more an issue , we introduced a new VAAI primitive called VAAI UNMAP this allows the ESXi host to inform the storage array that files or VMs had be moved or deleted from a Thin Provisioned VMFS datastore. This allowed the array to reclaim the freed blocks. We had no way of doing this previously, so many customers ended up with a considerable amount of stranded space on their Thin Provisioned VMFS datastores.
      Your storage array must support the VAAI to get the benefit.

      Thanks,
      Samir

  2. My general recommendations are to size your volumes based on the following criteria (listed in order of importance):
    1. RTO. (if you lose an entire LUN can you restore it within the required timeframe)
    2. IOPS.
    3. Capacity

    Actual capacity requirements are by far the least important consideration but, unfortunately, most architects consider it a high priority.

    • Agreed, this is how it should happen.One of the other considerations that should also be given is to engage the storage architect early in the design phase so that these factors are given importance in the overall design.

  3. Pingback: Newsletter: June 21, 2015 | Notes from MWhite

Leave a Reply

Your email address will not be published. Required fields are marked *

*


− seven = 1