You can size the capacity of a Virtual SAN datastore to accommodate the virtual machines (VMs) files in the cluster and to handle failures and maintenance operations.

Raw Capacity

To determine the raw capacity of a Virtual SAN datastore, multiply the total number of disk groups in the cluster by the size of the capacity devices in those disk groups, and subtract the overhead required by the Virtual SAN on-disk format.

Primary level of Failures to Tolerate

When you plan the capacity of the Virtual SAN datastore, not including the number of virtual machines and the size of their VMDK files, you must consider the Primary level of failures to tolerate and the Failure tolerance method attributes of the virtual machine storage policies for the cluster.

The Primary level of failures to tolerate has an important role when you plan and size storage capacity for Virtual SAN. Based on the availability requirements of a virtual machine, the setting might result in doubled consumption or more, compared with the consumption of a virtual machine and its individual devices.

For example, if the Failure tolerance method is set to RAID-1 (Mirroring) - Performance and the Primary level of failures to tolerate (PFTT) is set to 1, virtual machines can use about 50 percent of the raw capacity. If the PFTT is set to 2, the usable capacity is about 33 percent. If the PFTT is set to 3, the usable capacity is about 25 percent.

But if the Failure tolerance method is set to RAID-5/6 (Erasure Coding) - Capacity and the PFTT is set to 1, virtual machines can use about 75 percent of the raw capacity. If the PFTT is set to 2, the usable capacity is about 67 percent. For more information about RAID 5/6, see Using RAID 5 or RAID 6 Erasure Coding.

For information about the attributes in a Virtual SAN storage policy, see Using Virtual SAN Policies.

Calculating Required Capacity

Plan the capacity required for the virtual machines in a cluster with RAID 1 mirroring based on the following criteria:

  1. Calculate the storage space that the virtual machines in the Virtual SAN cluster are expected to consume. 
    expected overall consumption = number of VMs in the cluster * expected percentage of consumption per VMDK
  2. Consider the Primary level of failures to tolerate attribute configured in the storage policies for the virtual machines in the cluster. This attribute directly impacts the number of replicas of a VMDK file on hosts in the cluster. 
    datastore capacity = expected overall consumption * (PFTT + 1)
  3. Estimate the overhead requirement of the Virtual SAN on-disk format.
    • On-disk format version 3.0 and later adds an additional overhead, typically no more than 1-2 percent capacity per device. Deduplication and compression with software checksum enabled require additional overhead of approximately 6.2 percent capacity per device.
    • On-disk format version 2.0 adds an additional overhead, typically no more than 1-2 percent capacity per device.
    • On-disk format version 1.0 adds an additional overhead of approximately 1 GB per capacity device.

Capacity Sizing Guidelines

  • Keep at least 30 percent unused space to prevent Virtual SAN from rebalancing the storage load. Virtual SAN rebalances the components across the cluster whenever the consumption on a single capacity device reaches 80 percent or more. The rebalance operation might impact the performance of applications. To avoid these issues, keep storage consumption to less than 70 percent.
  • Plan extra capacity to handle potential failure or replacement of capacity devices, disk groups, and hosts. When a capacity device is not reachable, Virtual SAN recovers the components from another device in the cluster. When a flash cache device fails or is removed, Virtual SAN recovers the components from the entire disk group.
  • Reserve extra capacity to make sure that Virtual SAN recovers components after a host failure or when a host enters maintenance mode. For example, provision hosts with enough capacity so that you have sufficient free capacity left for components to successfully rebuild after a host failure or during maintenance. This is important when you have more than three hosts, so you have sufficient free capacity to rebuild the failed components. If a host fails, the rebuilding takes place on the storage available on another host, so that another failure can be tolerated. However, in a three-host cluster, Virtual SAN will not perform the rebuild operation if the Primary level of failures to tolerate is set to 1 because when one host fails, only two hosts remain in the cluster. To tolerate a rebuild after a failure, you must have at least three hosts.
  • Provide enough temporary storage space for changes in the Virtual SAN VM storage policy. When you dynamically change a VM storage policy, Virtual SAN might create a layout of the replicas that make up an object. When Virtual SAN instantiates and synchronizes those replicas with the original replica, the cluster must temporarily provide additional space.
  • If you plan to use advanced features, such as software checksum or deduplication and compression, reserve additional capacity to handle the operational overhead.

Considerations for Virtual Machine Objects

When you plan the storage capacity in the Virtual SAN datastore, consider the space required in the datastore for the VM home namespace objects, snapshots, and swap files.

  • VM Home Namespace. You can assign a storage policy specifically to the home namespace object for a virtual machine. To prevent unnecessary allocation of capacity and cache storage, Virtual SAN applies only the Primary level of failures to tolerate and the Force provisioning settings from the policy on the VM home namespace. Plan storage space to meet the requirements for a storage policy assigned to a VM Home Namespace whose Primary level of failures to tolerate is greater than 0.
  • Snapshots. Delta devices inherit the policy of the base VMDK file. Plan additional space according to the expected size and number of snapshots, and to the settings in the Virtual SAN storage policies.

    The space that is required might be different. Its size depends on how often the virtual machine changes data and how long a snapshot is attached to the virtual machine.

  • Swap files. Virtual machine swap files are mirrored, and space reserved by default, unless using the Sparse Swap setting introduced in Virtual SAN 6.2.