When determining the vSAN deployment specification for a VI workload domain in VMware Cloud Foundation, you decide on the datastore size, тхе number of ESXi hosts per cluster, тхе number of disk groups per ESXi host, and the vSAN policy.

Sizing vSAN Storage

You size your vSAN datastore according to the requirements of the your organization. This sizing is calculated according to a certain node configuration according to your hardware specifications.

Note:

Although vSAN is using thin provisioning to conserve the capacity consumption, in your calculations consider the full disk space, that is, thick provisioning. This approach prevents unexpected exhaustion of the vSAN capacity in the VI workload domain.

Disk space usage distribution consists of the following components:

Component

Description

Effective Raw Capacity

Space available for the vSAN datastore

Slack Space

Space reserved for vSAN specific operations such as resync and rebuilds

Dedupe Overhead

Space reserved for deduplication and compression metadata such as hash, translation, and allocations maps.

Disk Formatting Overhead

Reservation for file system metadata

Checksum Overhead

Space used for checksum information

Physical Reservation

How much physical space or raw capacity do we consume as part of the overheads

Sizing vSAN Datastore

When sizing your vSAN datastore, consider the required storage capacity for the workloads you plan to run and the number of NSX Edge nodes providing networking services to the workloads. Consider also the additional capacity needed for file system and any third-party management components you want to add. Consider also cost against availability to provide the appropriate sizing.

This design applies the shared edge and compute architecture to the vSphere clusters of a VI workload domain. In this architecture, the NSX Edge nodes and customer workloads share the resources of the same cluster, using resource pools to allocate CPU and memory to the NSX Edge appliances with high priority and to customer workloads according to their SLA. See High Availability Design for the NSX Edge Nodes for a Virtual Infrastructure Workload Domain.
Table 1. Design Decisions on the vSAN Datastore

Decision ID

Design Decision

Design Justification

Design Implication

VCF-WLD-vSAN-CFG-003

On all vSAN datastores, ensure that at least 30% of free space is always available.

When vSAN reaches 80% usage, a rebalance task is started which can be resource-intensive.

Increases the amount of available storage needed.

Number of vSAN-Enabled ESXi Hosts Per Cluster

The number of ESXi hosts in the cluster depends on these factors:

  • The amount of available space on the vSAN datastore

  • The number of failures you can tolerate in the cluster

For example, if the vSAN cluster has only 3 ESXi hosts, only a single failure is supported. If a higher level of availability is required, you must add more hosts.

Table 2. Design Decisions on the vSAN Cluster Size in a VI Workload Domain with a Single Availability Zone

Decision ID

Design Decision

Design Justification

Design Implication

VCF-WLD-vSAN-CFG-004
The VI workload domain cluster requires a minimum of 4 ESXi hosts to support vSAN.

  • Having 4 ESXi hosts addresses the availability and sizing requirements.

  • You can take an ESXi host offline for maintenance or upgrades without impacting the overall vSAN cluster health.

The availability requirements for the VI Workload Domain cluster might cause underutilization of the cluster's ESXi hosts.
Table 3. Design Decisions on the vSAN Cluster Size in a VI Workload Domain with Multiple Availability Zones

Decision ID

Design Decision

Design Justification

Design Implication

VCF-WLD-vSAN-CFG-005

The VI workload domain cluster requires a minimum of 8 ESXi hosts (4 in each availability zone) to support a stretched vSAN configuration.

  • Having 8 ESXi hosts addresses the availability and sizing requirements.

  • You can take an availability zone offline for maintenance or upgrades without impacting the overall vSAN cluster health.

The capacity of the additional 4 hosts is not added to capacity of the cluster. They are only used to provide additional availability.

Number of vSAN Disk Groups per ESXi Host

Disk group sizing is an important factor during volume design. The number of disk groups can affect availability and performance. If more ESXi hosts are available in the cluster, more failures are tolerated in the cluster. This capability adds cost because additional hardware for the disk groups is required. More available disk groups can increase the recoverability of vSAN during a failure. Consider these data points when deciding on the number of disk groups per ESXi host:

  • The amount of available space on the vSAN datastore.

  • The number of failures you can tolerate in the cluster.

  • The performance required when recovering vSAN objects.

The optimal number of disk groups is a balance between hardware and space requirements for the vSAN datastore. More disk groups increase space and provide higher availability. However, adding disk groups can be restricted by cost.

Table 4. Design Decision on the Disk Groups per ESXi Host

Decision ID

Design Decision

Design Justification

Design Implication

VCF-WLD-vSAN-CFG-006

Configure vSAN with a minimum of two disk groups per ESXi host.

Reduces the size of the fault domain and spreads the I/O load over more disks for better performance.

Multiple disks groups require more disks in each ESXi host.

Sizing vSAN Disks Per ESXi Host

The size of the vSAN disks depends on the requirements for the datastore, the number of ESXi hosts in the vSAN cluster and the number of disk groups per host.

For sizing the vSAN caching tier, see the Considerations for Flash Caching Devices in vSAN post on VMware Blogs. For vSAN memory consumption by the ESXi hosts in the VI workload domain, see VMware Knowledge Base article 2113954.

Table 5. Design Decisions on the vSAN Disk Configuration

Decision ID

Design Decision

Design Justification

Design Implication

VCF-WLD-vSAN-CFG-007

Use a 600 GB or greater flash-based drive for the cache tier in each disk group.

Provides enough cache for both hybrid or all-flash vSAN configurations to buffer I/O and ensure disk group performance.

Larger flash disks can increase initial host cost