vSAN Clusters - Considerations when Sizing and Scaling
Advancements in the data center introduce new and innovative ways for administrators to deliver capabilities that were unheard of just a few short years ago. We've seen this with new ways of rendering services through containers, new layers of abstraction with network encapsulation through NSX, and new hybrid-cloud integration through VMware Cloud on AWS. These are the types of advancements that allow data center administrators to rethink architectures, practices, and how to best deliver services to meet the demands of their organization. Operation and design practices should evolve with the data center to take the best advantage of these new capabilities.
VMware vSAN introduces the opportunity to rethink traditional design and operational practices. It brings a different architecture that provides new capabilities that were previously not possible. Unlike legacy architectures, vSAN treats storage as a cluster resource. This provides a massive shift in capabilities and introduces considerations in cluster sizing that didn't exist using when using external shared storage. With vSAN, treating storage as a cluster resource takes vSphere clustering to the next level, and allows for agility with management and growth unfamiliar to legacy architectures. As vSAN users have discovered, it creates a more modular approach to design, management, and growth.
Understanding tradeoffs of Large Clusters and Small Clusters
Once vSAN users recognize these capabilities stemming from this new architecture, a common question arises. It is usually something to the effect of "Given my x number of hosts, should I create fewer vSAN clusters with a larger number of hosts, or a larger number of vSAN clusters with a fewer number of hosts?" It is a great question. The new levels of flexibility and capabilities provided by vSAN invites the need for proper understanding and guidance. vSAN Cluster Design - Large Clusters Versus Small Clusters explains the design and operational tradeoffs of having a smaller boundary of shared resources, versus a larger boundary of shared resources: otherwise known as a cluster. It serves as a referenceable resource to run through the decision process for your own environment and examines operational and design considerations not always accounted for.
Figure 1. Providing a flexible, end-to-end, boundary of resources with vSAN clusters
Cluster sizes for standard vSAN clusters can range from 3 hosts to 64 hosts. What administrators may discover is that the right choice for cluster sizing is whatever best suits the needs of the business, and may result in a mix of different sizes.
For small and medium-sized organizations, the document lays out elements to consider as demands grow, and new hosts are added to an environment. For large organizations who often standardize on a single strict cluster size, this practice may no longer fit the technology or their organization. This document reviews the opportunities for improvement for those managing a large quantity of vSAN hosts. Perhaps their new standard might evolve into a range of cluster sizes that aligns with the needs of departments, business drivers, or geographical boundaries. This can make for a more logical allocation of resources and more agile management boundaries. The key for any organization is to clearly understand the design and operational tradeoffs when determining cluster size and decide what suits the organization best.
Flexibility Aligning with Scalability
This flexibility aligns perfectly with vSAN's capability to provide a scalable infrastructure. Cluster size is somewhat analogous to resource pools in that it simply offers a controllable collection of resources to run applications. Aside from the capabilities in resources the cluster provides, applications are largely unaware of the hosts or clusters in which they live: One of the initial benefits of virtualization. With vSAN, since storage is treated as an exclusive resource of the cluster, (similar to compute and memory) this boundary is one way that organizations with hundreds or thousands of hosts can scale reliably, and predictably.
Conclusion
Innovation in your own data center comes from not only the introduction of new technology, but reviewing and perhaps challenging previously held practices that were a carryover from legacy architectures. This can be the catalyst to discovering new opportunities to use these capabilities to the benefit the organization, and those who maintain it.