VMware Cloud Foundation 5.1 and vSAN 8 U2 bring new enhancements to the vSAN Express Storage Architecture (ESA) that help you better understand capacity consumption in your ESA powered clusters. This post will look at recent improvements in its ability to account for capacity usage and highlight its ability to store data and metadata in a much more efficient way.
Answering the Common Questions of Storage Administration
When it comes to storage, the most basic of all questions data center architects ask themselves are “How much storage capacity did I buy?” “How much am I using?” and “How much do I have left?” While they are seemingly easy answers, storage systems often rely on multiple ways to make the data resilient, and will often use opportunistic space-efficiency techniques that sometimes can make these questions challenging to answer.
The ESA’s storage stack processes and stores data differently than the Original Storage Architecture (OSA). As a result, its overheads for storing metadata, filesystems, and the capacity needed to ensure the primary data stored is resilient against failures is also different. The post, “Capacity Overheads for the ESA in vSAN 8” describes what these overheads are, but recent improvements in vSAN 8 U2 and VMware Cloud Foundation 5.1 include an enhancement in the UI that allows for better accounting of these overheads. These improvements make understanding capacity consumption easier. Let’s see what has changed and look at an example of storage capacity utilization for ESA.
An Example of Storage Consumption in the ESA
The cluster in this example consists of 8 hosts running vSAN 8 U2. Each host is populated with a quantity of four, 1.6TB storage devices providing a bit under 6TB per host, or approximately 47TB for the cluster. This ESA cluster runs around 100 VMs, that are all assigned a cluster-specific default storage policy of RAID-6 erasure coding, courtesy of vSAN ESA’s Auto-Policy Management feature. vSAN’s TRIM/UNMAP storage reclamation feature is also enabled. For clarity, this cluster does not have the Operation’s Reserve and Host Rebuild Reserve capacity management mechanisms enabled on this cluster. While this example is using a cluster in a vSAN HCI deployment option, the results would be the same on a cluster running vSAN Max.
As described in the post: “Demystifying Capacity Reporting in vSAN,” vSAN presents cluster capacity on a summary page that is divided into two sections. The “Capacity Overview” section which conveys how much of the available capacity is used, and the “Usage breakdown” which details the type of data that is currently stored on the cluster.
Capacity Overview
In this example, the UI shows that the cluster is providing 46.57TB of formatted, raw capacity. The small vertical line on the capacity overview graph represents the “operations threshold” which reflects a recommended capacity consumption limit (in this case, 38.27TB) that helps vSAN with operational activities.
While nearly 31TB of guest VM data, resilience data object metadata and snapshots are stored on the cluster, the actual used capacity is 17.69TB, after accounting for data compression, which saves 13.70TB. Data compression is much better in the ESA than in the OSA, but of course, the compression ratios you achieve will depend entirely on the type of data stored in your environment.
Figure 1. Observing the amount of data and metadata written on the cluster, after data compression is applied.
Usage Breakdown View
The “Usage breakdown” view details the breakdown of data written after compression, excluding free capacity. New to vSAN 8 U2, and VMware Cloud Foundation is the “ESA object overhead” label in the “System usage” category. This reports the metadata written in relation to the object and replica data, as described in the post “Capacity Overheads for the ESA in vSAN 8.” In this example, it calculates out to about 11.96% of the data stored. The ESA object overhead reported is after the data is compressed, so the better the compression, the less overhead is needed.
Figure 2. A breakdown of capacity usage, after compression is applied, with the new “ESA object overhead” category shown.
Recommendation. Use the “Usage Breakdown” view only on well populated clusters. Since it is only reporting against data written, new clusters that have very little to no VM data may show percentages of overhead much higher than what is expected. This is because there is very little data other residing on the cluster other than default, global system overheads.
The Result
This specific example demonstrates that the ESA, even after incorporating the various overheads, can protect data with high levels of resilience (FTT=2) in a manner that offsets nearly all resilience and metadata overheads. In this example on a cluster that provides about 46TB of raw capacity, there was roughly 15TB of guest VM data that after overheads and compression, consumed about 17.7TB of raw storage. Assuming the same level of compression for new data, one could store another 15TB of additional data in a highly resilient way and stay well within the 38.27TB base operations threshold for the cluster.
When compared to the OSA, the ESA provides higher resilience (as most customers use the less resilient FTT=1 instead of FTT=2 on the OSA), much faster performance, and improved space efficiency to drive down costs. Intel recently published material that echoes this sentiment at: “Beyond Savings: How Server Consolidation with VMware vSAN 8 Boosts Performance by more than 7.4x!.” And unlike a traditional modular storage array, you get a fully distributed storage system that can be scaled incrementally and cost-effectively using your favorite servers.
Estimating your Storage Requirements
How can you apply this knowledge when sizing your own environment? The vSAN ReadyNode Sizer does all the sizing calculations for you. Figure 3 shows that when server specifications and compression ratios are entered to resemble this cluster, the capacity estimates are very similar.
Figure 3. Using the vSAN ReadyNode Sizer to estimate usable storage.
Summary
VMware Cloud Foundation 5.1 and vSAN 8 U2 helps platform Administrators better understand their capacity usage when powering their workloads on the vSAN Express Storage Architecture.
