VMware Virtual SAN 6.2 is released as part of vSphere 6.0 Update 2 on 15th March 2016. It’s been almost 2 years from now from the initial release of Virtual SAN as part of vSphere 5.5 Update 1 on March 2014. Within this 2 years, Virtual SAN has improved a lot better and added with great new features in each releases. Virtual SAN is the foundation of VMware’s Hyper-Converged Software (HCS) that enables customers to experience industry leading hyper-converged infrastructure. Customers are finding VMware HCS key in adopting a Software Defined Data Center (SDDC) approach of streamlining and automating storage, networking and compute.
History of VMware Virtual SAN:
- March 2014 – VMware VSAN is released as part of vSphere 5.5 Update 1
- Feb 2015 – VSAN 6.0 released as part of vSphere 6. which includes the enhancements like All-flash deployment model, increased scalability to 64 hosts, new on disk format, JBOD support, new vsanSparse snapshot disk type, improved fault domains and improved health monitoring.
- August 2015 – VSAN 6.1 is released with vSphere 6 Update 1. which includes the enhancements like stretched cluster support, vSMP support, enhanced replication and support for 2-node VSAN clusters
- March 2016 – VSAN 6.2 is released with vSphere 6 Update 2. Which includes the enhancements like Deduplication and Compression, RAID-5/RAID-6 – Erasure Coding, Software Checksum, IPV6 and Performance Monitoring Service. we will discuss in detail about new enhancements with Virtual SAN 6.2.
What’s New with Virtual SAN 6.2 ?
Virtual SAN 6.2 adds greater abilities around lower cost and improving management and monitoring for the most demanding customer storage environments. In this new release, VMware continues to focus on providing a reliable and consistent storage environment for the biggest business critical applications. VMware is expanding the capabilities of Virtual SAN as a platform and is introducing better data efficiency features by delivering deduplication and compression of data as well as providing RAID-5/RAID-6 support for all flash Virtual SAN environment.
Deduplication and Compression
Deduplication should be enabled at VSAN cluster level. Dedupe and compression happens during de-staging from the caching tier to the capacity tier i.e it occurs after data is written to the write cache and before it is moved to the capacity tier, compression happens right after de-dupe. This feature only available with All flash type of VSAN deployment model. The de-dupe block size is fixed at 4KB. The deduplication is done for all the data from the caching tier which goes to the capacity tier with 4k fixed blocks.
Compression occurs after de-dupe. Deduplication and compression are tied together with VSAN. Enabling deduplication and compression is a CPU intensive operations for ESXi host. VMware claims it is minimal (around 5%) as they are using LZ4 compression which is designed to be extremely fast with minimal CPU overhead. With the combination of Deduplication and compression, the results achieved can be up to 7x space reduction, of course fully dependent on the workload and type of VMs.
RAID5/RAID6 Erasure coding
In the previous version of VSAN, Datasore deployed were either as a RAID-0 (stripe) or a RAID-1 (mirror) or a combination of both. This is an overhead in terms of capacity perspective because if you want you VM to tolerate 1 failure, you need 2 copies of data. similarly, If you want VM to tolerate number of failures to 2, you need 4 copies of data stored on VSAN datastore.In VSAN 6.2, some new configurations, namely RAID-5 and RAID-6 are introduced to help reduce the overhead when configuring virtual machines to tolerate failures on VSAN. This feature is also termed “erasure coding”.
For RAID-5, a minimum of 4 hosts are required; for RAID-6, a minimum of 6 hosts are required. The objects are then deployed across the storage on each of the hosts, along with a parity calculation. The configuration uses distributed parity, so there is no dedicated parity disk. When a failure occurs in the cluster, and it impacts the objects that were deployed using RAID-5 or RAID-6, the data is still available and can be calculated using the remaining data and parity if necessary. RAID-5/6 (Erasure Coding) is configured as a storage policy rule and can be applied to individual virtual disks or an entire virtual machine.
RAID 5 Erasure Coding
- Number of failure to Tolerate = 1
- Failure Tolerance Method = Capacity
- Uses x1.33 rather than x2 capacity when compared to RAID-1 (Using RAID-5, the parity data only requires 1.33 times.RAID-1 always consumed double additional space (2x). As a result a VM that is 20GB in size will only consume an additional 7GB on other hosts with RAID-5, with RAID-1 it would consume 20GB as you are writing an entire copy of the entire VM to other hosts.)
- Requires a minimum of 4 hosts in the VSAN cluster
RAID 6 Erasure Coding
- Number of failure to Tolerate = 2
- Failure Tolerance Method = Capacity
- Uses x1.5 rather than x3 capacity when compared to RAID-1 (Using RAID-6 a 20GB VM would only consume an additional 10GB of disk on other hosts, if you did this with RAID-1 it would consume an additional 40GB as you are writing two copies of the entire VM to other hosts.)
- Requires a minimum of 6 hosts in the VSAN cluster
Below is the comparison Table beween RAID-1 & RAID-5/6 Erasure coding.
Sparse VM Swap
Virtual swap files are created when virtual machines are powered on. A virtual machine with 4GB of RAM allocated,Consume 4 GB in VSAN datastore. 100 virtual machines with the same configuration will consume 400GB of capacity. With VSAN 6.2, We have option to deploy VM swap as thin. “SwapThickProvisionDisabled” advanced host setting for additional space savings. This need to configured on each ESXi host in VSAN using the following command:
esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled
Enabling this setting creates virtual swap files as a sparse object on the Virtual SAN datastore. Sparse virtual swap files will only consume capacity on Virtual SAN as they are accessed. The result can be significantly less space consumed on the Virtual SAN datastore.
Sofware Checksum and Scrubbing
Software Checksum will enable customers to detect the corruptions that could be caused by hardware/software components including memory, drives, etc. during the read or write operations.This is completely new software checksums which will perform the following checks:
- Write failures to disks
- Network copy failures
- Checksum failures – will fetch data from another copy.
- Disk Scrubbing will run in the background
- Enables additional level of data integrity
- Automatically detects and solve silent disk errors
Quality of Service (QOS)
VSAN has some new QoS controls designed to regulate storage performance within a host to protect against noisy neighbors or for anyone looking to set and manage performance SLAs on a per VM basis. The new QoS controls work via vSphere Storage Policies and allow you to set IOPS limits on VMs and virtual disks.
IPV6 Support
Virtual SAN can now support IPv4-only, IPv6-only, and also IPv4/IPv6-both enabled. This addresses requirements for customers moving to IPv6 and, additionally, supports mixed mode for migrations.
Improved Application Support
VSAN already has pretty good application support with key apps such as Oracle and Exchange, they have extended that in 6.2 with new support for SAP and tighter integration with Horizon View. VMware is working hard to make VSAN capable of running just about any application workload.
Enhanced Performance and Capacity Monitoring
Prior to VSAN 6.2, you had to leverage external tools such as vSAN Observer or vRealize Operations Manager to get detailed health, capacity and performance metrics.In VSAN 6.2, it becomes very easy to manage and Monitor VSAN from directly within vCenter Server.This new performance management capability is built directly into vCenter but it’s separate from the traditional performance metrics that vCenter collects and stores in it’s database. The new VSAN performance service will have it’s own separate database contained with the VSAN object store. The size of this database will be around 255GB and you can choose to protect it with either traditional mirroring (RAID 1) or using the new erasure coding methods (RAID-5 or RAID-6). By default this is not enabled to conserve host space but can be enabled if needed in the settings for VSAN.
Native Health Check
Virtual SAN 6.2 features an improved health service. The health service actively tests and monitors a number of items such as hardware compatibility, network connectivity, cluster health, and capacity consumption. The performance service provides various metrics such as throughput, IOPs, and latency. The health service is enabled by default and configured to check the health of the Virtual SAN environment every 60 minutes.
Client Cache
Write through read memory cache which is “local” to a VM. Brings only very low overhead but has a big impact on performance (especially for VDI). A dynamic memory, taking up to 1Gb from each host. Compared to VSAN 6.1, the client cache will use 4% of host memory up to 1GB of host memory.Note that this in-memory cache is a client side cache, meaning that the blocks of a VM are cached on the host where the VM is located.
I am extremely excited to evaluate all the new features of Virtual SAN 6.2. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it in social media, if you feel worth sharing it.