VMware Cloud Foundation and VMware vSphere environments powered by vSAN Express Storage Architecture (ESA) can be an incredibly powerful combination. Customers can run their entire private cloud environment using a revolutionary storage platform integrated into the hypervisor. But the ESA is not limited to running in only a hyperconverged deployment, where storage and compute resources are aggregated into the same hosts that comprise a cluster. Thanks to the introduction of vSAN Max (now called “vSAN Storage Clusters”), which is built using the ESA, customers can provide centralized shared storage for their VMware Cloud Foundation (VCF) and VMware vSphere Foundation (VVF) environments using nothing more than commodity servers from your favorite server vendor.
Figure 1. Using aggregated vSAN HCI clusters and disaggregated vSAN Max clusters with VCF and VVF.
No matter what you choose, there are common characteristics with all three options that should not be overlooked.
- Single, software-only stack. Remember that vSAN is a storage solution built into the hypervisor. vSphere built its reputation from its world class management and scheduling of CPU and memory resources, so it makes sense that it can do the same for storage. You choose the hardware, and the hypervisor does the rest.
- Consistency of management. An administrator can easily manage any of the three options in the very same way, all using vCenter server.
- Incremental scalability. Distributed storage, whether it is aggregated compute resources or disaggregated using vSAN Max, allows for easy, incremental scaling of capacity and performance that cannot be achieved with modular storage arrays.
These deployment options offer incredible levels of flexibility, but with this new potential, what is the best deployment option for your environment? Aggregated vSAN HCI clusters or disaggregated vSAN Max clusters? While you can easily have both solutions running side by side in an environment and enjoy the luxury of easy and consistent management, lets sort through some environmental conditions and requirements that may help you decide on what approach will suite your needs best.
Multiple Deployment Options
vSAN provides the power of choice. Thanks to the unique capabilities of the Express Storage Architecture, VMware gives three cluster configuration types that help meet the needs of your organization, while providing a simple and consistent way to manage and monitor the solution.
- Traditional HCI. This is labeled as a “vSAN HCI” cluster, where compute and storage resources are aggregated in the same hosts that comprise the vSAN HCI cluster.
- vSAN HCI with Datastore Sharing. Also known as “cross-cluster capacity sharing,” this represents the highly flexible cross-cluster capacity sharing capabilities between vSAN HCI clusters. This feature was formerly referred to as “HCI Mesh.”
- Disaggregated Storage. This is VMware’s fully disaggregated topology where a vSAN Max storage cluster provides resources to one or more vSphere clusters. vSAN Max is incorporated as a first-class citizen in vCenter Server, where deployment, connectivity, and monitoring are all easy and intuitive throughout the vSphere client user interface.
The circumstances or requirements you have in your environment may favor one deployment option over the other, but in most cases, it does not mean that a specific deployment option should be excluded from consideration. The decision may come down to a unique set of considerations, or personal preference. Regardless, the vSAN ESA powers all deployment options, giving you the performance, resilience, scalability, and consistent management that is synonymous with the ESA.
Even though vSAN Max clusters share many characteristics to a vSAN HCI cluster, they are not the same. When vSAN Max is chosen, special tunings are automatically made that change the storage stack to accommodate for the fact that the vSAN Max cluster is going to be predominantly processing I/O and storing data, not running a substantial amount of VM instances. The tuning helps maintain more metadata in memory, which helps both read and write operations.
vSAN HCI and vSAN Max are deployment options that are a decision point at the time of cluster creation, and cannot be converted to one or the other after the deployment. The “vSAN HCI with datastore sharing” option is most useful in existing environments to use stranded capacity resources from one vSAN cluster to another, or to use specific data services or storage performance capabilities of a cluster. The “vSAN HCI with datastore sharing” deployment option is not typically targeted in greenfield design, which is why the information below compares considerations of vSAN HCI clusters to that of vSAN Max clusters.
Simplified Approach to Licensing
Licensing for storage in VMware Cloud Foundation is based on two elements, 1.) The number of CPU cores licensed, and 2.) the amount of additional capacity (per TiB) purchased. For every core licensed in VMware Cloud Foundation, a complimentary 1 TiB of vSAN capacity is provided. Any additional capacity beyond the sum capacity provided by the core count would be through a capacity add-on license.
Which deployment option you choose is entirely up to you. While one may be preferable over the other based on your environment, the new licensing model for VMware Cloud Foundation largely removes licensing as a factor for considering one deployment option for another. As shown in Figure 2, when a vSAN HCI cluster is provisioned, all cores and capacity licensing would reside on that cluster. But if a disaggregated approach was chosen, some licensing cores will reside on the vSphere clusters, while other licensing cores and capacity reside on the vSAN Max cluster.
Figure 2. How the licensing model allows you to choose the deployment option that is the best for you.
When using a disaggregated deployment option, fewer cores are needed for each respective vSphere host, since vSphere hosts are only responsible for running VM instances, and vSAN Max hosts are only responsible for processing storage.
Influencing Factors
Which configuration type is best for your environment? The answer may be a combination of the available options, or favor one type over another. It all simply depends on your circumstances. Within your basic requirements of capacity, as illustrated in Figure 3, we find three primary influencing factors that may shape which option, or combination of options is best for you:
- Asymmetry of growth with storage versus compute resources
- Storage requirements for existing vSphere clusters
- Topology requirements and constraints
Figure 3. Influencing factors in deciding between aggregated vSAN HCI, or disaggregated vSAN Max.
vSAN HCI and vSAN Max provide very similar experiences in capabilities and features. While both are centrally managed by vCenter Server to provide a simple user management experience, they do vary in their storage capacity capabilities.
vSAN HCI uses a wider selection of ReadyNode profiles and can be tailored to meet smaller capacity needs. vSAN Max can also serve up a wide range of storage capacity, with the potential to offer massive levels of capacity per cluster. The latest ReadyNodes certified for vSAN Max can range from 20TB per host up to 360TB per host. With a recommended minimum of just 4 hosts per vSAN Max cluster, customers could pair this minimum to the smallest ReadyNode profile, making for an ideal small-footprint configuration in environments that do not need large amounts of capacity. vSAN Max, which serves as a dedicated storage cluster, can achieve much higher levels of capacity, making it an ideal alternative to environments using traditional storage. Figure 4 demonstrates the relative cluster capacities provided by ReadyNodes currently available for vSAN HCI deployments and vSAN Max deployments. These capacity values represent what is currently available on the VMware Compatibility Guide for vSAN. This compares raw cluster capacity for clusters ranging between 4 and 24 hosts.
Figure 4. Comparing relative capacities of vSAN HCI and vSAN Max clusters, ranging from 4 hosts to 24 hosts.
Let us look at the most significant influencing factors that can help you determine what may work best for your environment. Regardless of what you choose, vSAN HCI clusters and vSAN Max clusters can happily coexist in a data center and serve the needs for which they are best suited.
Asymmetry of Growth with Storage versus Compute Resources
vSAN HCI
The aggregated architecture of vSAN HCI provides a simple way to incrementally scale out resources, but it will generally scale the compute and storage at the same rate. This can be ideal for some environments, but not ideal for other environments that may need much more storage capacity, but only modest amounts of additional compute resources.
vSAN Max
The disaggregated architecture of vSAN Max demonstrates supreme levels of flexibility by allowing customer to grow storage capacity and performance that is completely independent from your compute resources. In this configuration, you can easily scale compute, or storage incrementally, at different rates. This gives customers an ability to design and/or keep vSphere clusters to a host count that is best suited for the layout of data center, or meet specific application licensing requirements.
Storage Requirements for Existing vSphere Clusters
vSAN HCI
vSAN HCI clusters can be a good candidate for hardware refresh cycles of a vSphere cluster, as it could offer compute and storage all as one solution. It has less applicability for existing clusters, as the hardware may not meet requirements on the VMware Compatibility Guide (VCG) for vSAN.
vSAN Max
vSAN Max can be an ideal centralized storage solution for environments with vSphere clusters already in place. It can serve as a replacement to third-party external storage solutions while maintaining a consistent management experience and level of integration with vSphere as vSAN HCI.
vSAN Max will support vSphere clusters running on vSphere 8, and the hardware specifications for vSphere hosts can be completely different from the hosts in a vSAN Max cluster, and only need to comply with basic hardware compatibility guidelines for vSphere, not vSAN.
Since the storage resources are decoupled from the compute resources, this means that the hypervisor lifecycle management of the storage cluster running vSAN Max can be completely independent from the vSphere or vSAN HCI clusters it serves. There are no complex dependency chains with upgrades. Simply update one or the other independently, as needed.
Topology Requirements and Constraints
vSAN HCI
vSAN HCI can be ideal when security or other workload requirements demand resource isolation, since vSAN HCI treats storage as a resource of the cluster. An example of this type of resource isolation can be found at: “vSAN Powering Biotech.”
Since geography and physical constraints impact the design of a vSAN cluster, many may find that when it comes to small remote sites, and even stretched clusters, that vSAN HCI clusters may be the ideal solution for these types of conditions. This is because it can be achieved with fewer hosts since compute and storage are aggregated into the hosts that comprise the cluster. A vSAN HCI cluster can be configured for a very small 2-Node topology which can be ideal for small remote sites. For the latest on ReadyNodes certified for vSAN HCI deployments, see: “Updates to ESA Host Requirements for vSAN HCI Deployments.”
vSAN Max
vSAN Max can be ideal for those who are also looking to maximize storage resources across many clusters. Since it provides storage capacity to all clusters that consume it, vSAN Max eliminates the discrete capacity sizing exercise found when sizing multiple vSAN HCI clusters. The post: “Greater Flexibility with vSAN Max through Lower Hardware and Cluster Requirements” details the lower requirements for vSAN Max, which can make it also a great option for smaller environments while retaining the ability to scale easily and serve the needs of many vSphere clusters.
vSAN Max could certainly be an option for stretched cluster environments, but does have some limitations at this time. See the post: “Flexible Topologies with vSAN Max” for more information.
Examples
The examples below will help illustrate how one type of configuration choice may be more favorable than another, depending on the influencing factors. In many cases, both aggregated vSAN HCI cluster and disaggregated a vSAN Max cluster would serve a given situation equally as well. Choosing one over the other may include personal preference.
| Scenario | Primary Influencing Factor | Favored Deployment Option | Reason |
| Multiple vSphere clusters with unpredictable levels of storage capacity needs. | Asymmetry of growth | vSAN Max | vSAN Max can be the ideal option for unpredictable levels of storage capacity. vSAN HCI could also work but would require accounting for discrete storage requirements at a cluster level. |
| Hardware refresh has predictable set of compute and storage capacity needs, with modest growth. | Asymmetry of growth | vSAN HCI | vSAN HCI may serve as the ideal “self-contained” solution for both compute and storage resources. |
| Replacement storage for existing storage array serving existing vSphere clusters. | Existing vSphere clusters | vSAN Max | vSAN Max is a terrific option for vSphere environments undergoing a storage refresh. It can serve as the centralized shared storage solution for existing vSphere clusters with no changes to existing vSphere clusters. Shifting to vSAN HCI for existing vSphere clusters would mean a new hardware refresh for existing clusters. |
| Customer is looking to switch over to an HCI arrangement during a hardware refresh. | Existing vSphere clusters | vSAN HCI | An aggregated vSAN HCI cluster would suite the customer best since that is what they desire. |
| Prefer isolated storage resources to meet security or workload isolation requirements. | Topology Requirements & Constraints | vSAN HCI | Multiple smaller vSAN HCI clusters treat storage as a resource of the cluster, and can be ideal if you want to isolate workloads within specific security domains. |
| Want to ensure purchased capacity is used efficiently across clusters with a minimal amount of stranded capacity. | Topology Requirements & Constraints | vSAN Max | vSAN Max will provide centralized storage resources for many compute clusters, which means that storage can be sized for the aggregate of all compute resources, rather than individual clusters. |
| Remote office/Edge environment that requires a minimal hardware footprint. | Topology Requirements & Constraints | vSAN HCI | vSAN HCI would be the preferred option here as vSAN HCI supports 2-Node configurations that are ideal for these environments. Although, definitions of “edge” vary, and for some customers, vSAN Max paired with its recently announced lower minimums, may also be a good fit for their edge environments. |
| No sizing limits on the number of hosts in an environment. | Topology Requirements & Constraints | vSAN Max | vSAN Max could be the ideal option here, consisting of between 4 and 24 hosts. |
| Environment powering a lot of cloud native application (CNA). Stateful or stateless applications with potential for significant growth in persistent volumes. | Topology Requirements & Constraints | vSAN Max | vSAN Max can be a great storage solution for clusters powering cloud native applications. While vSAN HCI could fit as well, the scalability potential of vSAN Max makes this a great fit. |
| vSphere clusters optimized to minimize application licensing costs. | Topology Requirements & Constraints | vSAN Max | vSAN Max can be ideal for applications with licensing that prevents larger cluster sizes from being cost effective. These applications can run on extremely small vSphere clusters to reduce licensing costs, yet still take advantage of high levels of storage resilience (FTT=2). |
Summary
VMware Cloud Foundation allows you to run any kind of workload, anywhere. Storage by vSAN provides even more flexibility by allowing you to choose whether the storage is aggregated into the hosts that comprise the cluster, or disaggregated into a dedicated, centralized storage solution for all your vSphere clusters. The preferrable choice depends on what you wish to achieve in your environment.
