As VMware vSAN continues to be an important storage solution for many of our VMware customers, scheduled hardware replacements, or “refreshes” are inevitable. Introducing new hardware to a vSAN-powered environment is easy, but there is one step in the process that can create a bit of confusion, and lead to potentially buying more storage capacity than you may need.
This post is for those who have workloads on one or more vSAN clusters that are up for a hardware refresh, and wish to size it to the desired capacity requirements.
Capacity Sizing for a new vSAN cluster
VMware provides the vSAN Sizer to provide an easy and effective way to build out a vSAN cluster based on your various requirements. When sizing for capacity, the sizer requests capacity inputs such as the average capacity needed per VM, or the total capacity needed for the cluster. This can be found when creating a new workload profile in the vSAN Sizer, as shown in Figure 1.
Figure 1. Entering in capacity requirements in the vSAN Sizer.
When gathering this data for a cluster using a storage array, the effort can be fairly straightforward. Some may simply estimate the actual usage through views in vCenter Server or vRealize Operations or use PowerCLI to provide usage statistics. Others may use tools such as Live Optics, OneIQ, or RvTools to import the data into the vSAN Sizer. While these options can be used to successfully collect usage metrics from traditional storage, performing the same step for workloads on an existing vSAN cluster may report a higher capacity consumption than the number that should be used in the vSAN Sizer. Let’s see why this happens.
Recommendation: Don’t overlook the “vSAN Quick Sizer” option in the upper right-hand corner of the vSAN Sizer page. Unlike the primary sizer that builds a cluster based on workload inputs (performance, capacity, etc.), this offers a way to do a “reverse sizing” exercise where you can easily determine how much capacity you would have by specifying a given amount of servers.
How Capacity Reporting Can be Different when using a vSAN Cluster
The vSAN Sizer was designed to enter the capacity consumed as the VM would see it, as shown in Figure 1. The vSAN Sizer will factor in the additional capacity needed for the specified resilience levels. But vSAN will report “Provisioned Space” and “Used Space” differently than a traditional storage array – as described in the post: “Demystifying Capacity Reporting in vSAN.” With vSAN, those capacity metrics incorporate not just the data of the VM(s), but the space needed for the level of resilience prescribed by the storage policies. For example, Figure 2 shows a VM that has a 100GB volume and is using approximately 14GB of that volume, but because this VM is using a FTT=1 mirror storage policy, it reports values that are twice the capacity as what is seen by the VM.
Figure 2. Capacity reporting in the vCenter Server UI for a VM on a vSAN datastore.
We can also see this at the cluster level as shown in Figure 3, where the capacity consumption is broken down into the primary data versus replica data. The primary data reports the consumption as seen by the VM(s), and the Replica usage represents the data stored to ensure the resilience of the primary data.
Figure 3. Capacity reporting in the vCenter Server UI for an entire vSAN cluster.
If the incorrect values are accidentally entered into the vSAN Sizer – such as the total data instead of the primary data reported in the Usage Breakdown view – this already includes the data storage needed for resilience. The vSAN Sizer would then add additional capacity on top of this to accommodate for resilience requirements, which would lead to an oversized cluster.
Gathering Accurate Consumption Information for Sizing a New vSAN Cluster
When sizing a new vSAN cluster for workloads that already live on an existing vSAN cluster, how you gather the correct consumption information depends on the method used.
- Using the vCenter Server UI: Simple open the Usage Breakdown in the Capacity View of the vSAN cluster, and use the values associated with “Primary Data” next to the category types. This will omit the capacity used for “Replica Usage” and be a more accurate reflection of what the guest VMs perceive as being used, which is what the vSAN Sizer Expects.
- Tools used for importing: Test your preferred tool of choice used for the sizing exercise, and see if it pulls the values as seen by the guest VM, or if it includes the data for the prescribed level of resilience. What it reports will be based on what type of API call the tool is using to report capacity consumption. For example, RvTools will pull the correct consumption values that can be used to enter in the vSAN Sizer.
If the method used to report capacity consumption is including the data consumption for resilience, then you can switch to another method, or perhaps manually reduce the data estimates. See the table on space consumption ratios for the common levels of resilience in vSAN in the vSAN Space Efficiency Technologies documentation.
Note that with any tool used, there may be some discrepancies if TRIM/UNMAP is not enabled on the vSAN cluster. See the blog post: “The Importance of Space Reclamation for Data Usage Reporting in vSAN” for more information.
Summary
VMware vSAN has continued to help customers drive down costs and improve their total cost of ownership. The vSAN Sizer tool is an excellent resource for sizing your clusters accurately and cost-efficiently. For those existing vSAN clusters that are up for a hardware refresh, make sure you gather the correct capacity information to ensure you are not oversizing the capacity of your new vSAN cluster.
