Table of Contents
vSAN Express Storage Architecture (ESA) was announced at VMware Explore last year (2022) and while it’s been available for our on-premise customers for nearly a year it hasn’t been available in VMC until now…. With the release of the M24 version of VMC. It is now an option for newly provisioned SDDC’s
So why is this such an important change? to answer that we need a history lesson on vSAN
vSAN first came to market in 2014, and the typical hardware of the day from a storage perspective was dominated by spindles. Flash had arrived on the scene but was VERY expensive and datacenter networking was in the transition from 1Gb/s to 10Gb/s. As a result of this and other factors design decisions were made in the original vSAN (referred to here as OSA) to implement a tiered storage architecture. This was made up of flash-based cache drives and flash or hard disk-based capacity drives. These were then combined into something called a disk group. This decision led to several consequences.
The first is that the cache drive cannot be used for storing data it is only a transient write buffer. As all writes go to the cache drive in a disk group in some circumstances this could limit the peak I/O available.
It also meant that the endurance of this drive was paramount. This was a challenge in the early days of flash drives.
To improve performance and reduce failure domains it’s possible to have multiple disk groups within a host. This is something that we implement in VMC using vSAN OSA this further compounds the reduction in usable storage. as multiple drives are allocated to the cache role.
As All-Flash has now become the normality it was worth revisiting the architecture.
To understand more about the under-the-hood architecture of vSAN see the official overview
vSAN ESA – Benefits
Putting all of the above changes together brings significant benefits to VMC customers when using the ESA version of vSAN.
- Significant increase in available IOPS ( all drives are used for reading and writing)
- Adaptive write path for maximum throughput (Especially relevant for customers that require high throughput on a single or low number of VMDK’s)
- Improved snapshot mechanisms reduce the impact on the guest workload (Snapshot deletion is up to 100x faster combined with much reduced primary latency when running workloads from snapshots. As business demands lower RPO’s any improvement in snapshot mechanisms reduce the overhead to the guest workload.
- Improved compression algorithms for better data reduction
- More efficient compression algorithms free up the Host CPU for Guest OS processing
- Reduced storage network traffic (compression happens on the source host and then all replication is already compressed)
- further enhancements reduce the CPU overhead when using vSAN Encryption (This is always used in VMC)
- Always on UNMAP/Trim (This helps to free up unused blocks at the Nand block level)
- The ability to deploy a parity-based (RAID5) with 3 Nodes. (OSA requires a minimum of 4)
- The performance of the parity-based (RAID5/6) of the ESA implementation now exceeds the RAID1 performance of OSA. Customers can get increase savings by changing the storage policy.
- less rewrites in the event of a device replacement – Although this is a significant benefit for on-premise customers with VMC if we have a drive failure we will replace the entire node.
vSAN will only be available on the i4.metal-based VMC hosts at launch. It is also not currently available in a 2-node or Stretched SDDC configuration
As part of my job in VMware Cloud Pre-Sales a critical aspect is sizing VMC solutions for customers. This is usually done as a first pass with RVtools inputs into our sizing tools.
But what does that mean to a customer?
My colleague Nikolay put together this handy table. This is assuming a conservative compression ratio of 1.25% for ESA. The reality is we expect this to be higher.
|OSA (Compression 1.25)
Policy In use
Policy In use
*As ESA has a dynamic parity-based mechanism it can either use 2+1 or 4+1 however OSA has the capability of using 3+1. This is why the 4 and 5 node has a lower usable space.
The above table is the usable capacity for workloads including the management objects. Additional clusters would have more space.