Generally, for a good design, VMware highly recommends that each node contained within a vSphere cluster is enabled for vSAN, and has the exact same configuration. When designing a vSAN cluster, use similarly configured and sized hosts. This allows for an evenly balanced vSAN cluster configuration. Otherwise, the performance and capacity expectations will be compromised.

Most VMware Cloud Providers have a preferred server vendor and, more than likely, they have a preconfigured and validated server (Ready Node) architecture for vSAN. If not, providers can also build their own vSAN nodes using the information provided by the compatibility guide. From an operational standpoint, the Ready Nodes have been the preferred choice of infrastructure for vSAN.

vCloud Director management clusters have different requirements than a resource cluster. Traditionally, providers would allocate dedicated storage for management-only clusters, which would ultimately increase the infrastructure costs. Deployment of a management cluster would normally entail the purchase of an additional storage array to provide the expected performance and availability for what is typically a high I/O throughput and highly available virtual environment. These costs, in turn, would inherently be passed on to the consumer. With vSAN, these costs are significantly reduced, making it an ideal solution for a dedicated management environment. Using vSAN for the management cluster provides an entire integrated stack that is automated by vCenter Server. The storage is locally attached and backed by SSD-based cache. Take the following best practices into consideration when designing a management cluster backed by vSAN:

In addition, as a good practice, enable vSphere High Availability (HA) on the vSAN cluster to protect it from host and virtual machine failure.

A single vSAN cluster can contain up to 64 nodes. As a starting point, it is a commonly defined configuration for service providers to implement 20 to 24 node clusters, with each node configured with two disk groups to provide flexibility of growth. This approach also provides flexibility over Fault Domain design, for improved data availability and protection.