Book Image

VMware Virtual SAN Cookbook

By : Jeffrey M Ransom Taylor, Patrick Carmichael, Simon Gallagher, Jeffrey Taylor
Book Image

VMware Virtual SAN Cookbook

By: Jeffrey M Ransom Taylor, Patrick Carmichael, Simon Gallagher, Jeffrey Taylor

Overview of this book

Table of Contents (18 chapters)
VMware Virtual SAN Cookbook
About the Author
About the Reviewers

Chapter 1 – VSAN Capacity Planning

As VSAN is a policy-driven storage solution, there is no RAID configuration at the datastore level. All reliability/availability decisions, performance reservations, and so on, are made on a per-VM basis.

Because there is no datastore-level RAID decision being made, VSAN capacity and calculations are based on raw capacity. If you build a VSAN configuration of four nodes with three 2TB HDDs each, the raw capacity of the VSAN datastore will be approximately 24TB.

Capacity will be consumed according to the availability policy specified for each VM. The most typical case is a per-VM mirror. This means that, for the vast majority of all VMs running on VSAN, the datastore usage will be double that of the VM's capacity requirement.

By default, VMs on VSAN are thin-provisioned. You can choose thick-provisioning on a sliding-scale basis (from 0 percent thick to 100 percent thick), and your policy decisions here will also affect the datastore consumption.

Best-practice limits to space consumption

  1. You should not plan on consuming 100 percent of the available capacity in the VSAN datastore. It is strongly recommended that you maintain 20 percent free space in the cluster. This is important as VSAN rebalancing and placement decisions need some capacity available to move objects around to optimize space distribution. To determine the ideal raw capacity, you should calculate it as <required capacity>/0.80. If your needs project that you will need 10TB of storage, consider sizing your VSAN cluster accordingly:

  2. 10TB of VM usage, where VMs are protected against disk or node failure, will mean that those VMs are mirrored, so the actual raw capacity need is 20TB.

  3. To comply with the 80 percent rule, take 20/0.80 = 25.

  4. You should size your VSAN to cluster to be about 25 TB.

Data working set size and capacity-tier sizing

While the arithmetic outlined in the previous section is needed to determine the raw capacity target for your VSAN cluster, the surplus capacity mandated by the 80 percent rule needn't necessarily be included in your SSD sizing decision. As the SSD is used for write buffering (and for read caching in hybrid VSAN implementations), it can be sized according to the expected size of your data set. You can calculate your SSD requirement by finding 10 percent of your expected working set as <working set size>*0.10.

In the context of the preceding example, the expected working set is 20TB, so the SSD sizing for the cluster is 20TB*0.10 = 2TB.

On a gross-capacity basis, that means the SSD is only 8 percent of the raw capacity of the cluster, which is lower than the recommended 10 percent. This is okay, however, because it is 10 percent of the size of the working set.

Cluster symmetry

The previous examples are for the cluster as a whole. Cluster nodes should be symmetrical (for example, the same raw capacity for each node) and the SSD should be sized appropriately on a per disk-group basis.

Continuing with the example of a 20TB raw capacity need, if you were to build a four-node VSAN cluster, one possible distribution would be as follows:

  • Four nodes with one disk group each

  • Three 2 TB HDDs per disk group

  • One 600 GB SSD per disk group

That leaves the cluster with 24TB raw capacity (3*2*4). In most cases (especially with some degree of thin-provisioning), this will comply with the 80 percent rule and the SSD will be 10 percent of the gross raw capacity of the cluster. This means the SSD is slightly oversized (>10 percent of the anticipated working set), but the next most common size (500GB) would be only 7.5 percent of the working set, which is too low.

In addition, such a configuration is perfectly symmetrical across nodes and this is ideal for VSAN object distribution. This configuration will also scale well, as an additional disk group could be added to each host in the future, growing capacity while maintaining symmetry, and without running out of available disk positions on most SAS controllers.

Other considerations

Most SAS controllers have eight available disk positions, discounting the use of SAS expanders. Carefully planning your disk count and capacity can make future expansion easier by enabling the simple addition of an additional, identically-scaled disk group in each host.