vSAN 7 Update 2 File Services

vSAN 7 Update 2 File Services

vSAN native file services draw attention for many reasons. Its flexibility, integration, and capabilities make it a good fit for a variety of use cases. The initial version provided a key element to serving up cloud-native applications in vSAN: Persistent, read-write many (RWM) volumes. vSAN 7 Update 1 improved on the capabilities of file services even further with support for SMB v2.1 and v3, Active Directory integration, and Kerberos Support. vSAN 7 Update 2 extends the capabilities of vSAN file services in new and interesting ways, including support for stretched clusters, data-in-transit encryption, snapshots, and improved scale, performance, and efficiency.

vSAN 7 Update 2 file services

Support for vSAN Stretched Clusters and 2-node Topologies

File services can now be used in vSAN stretched clusters as well as vSAN 2-node topologies, which can make it ideal for those edge locations also in need of a file server.

Creating file shares with site affinity

vSAN Stretched Cluster

Stretched clusters extend the vSAN cluster from a single site to two sites for a higher level of availability and intersite load balancing. Stretched clusters are typically deployed in environments where the distance between data centers is limited, such as metropolitan or campus environments. Each stretched cluster consists of two sites (Preferred and Secondary) and one witness host. The virtual witness host appliance resides at a third site and contains the witness components of virtual machine objects. It contains only metadata and does not participate in storage operations. The witness host serves as a tiebreaker when a decision must be made regarding the availability of datastore components when the network connection between the two sites is lost.

You can use stretched clusters to manage planned maintenance and avoid disaster scenarios because maintenance or loss of one site does not affect the overall operation of the cluster. In a stretched cluster configuration, both sites are active sites. If either site fails, vSAN uses the storage on the other site. vSphere HA restarts any VM that must be restarted on the remaining active site.

vSAN File Services on Stretched Clusters

The site affinity setting for a file share is defining where the presentation layer (NFS or SMB services) reside. It does not relate to if (or how) the data is placed across sites. This is defined by the storage policy associated with the share. The storage policy settings protect the share data in the same manner as any other type of object data, such as no site-level mirroring, site-level mirroring, and site-level mirroring with secondary levels of protection at each site including RAID-1 and RAID-5/6.

Setting site affinity on file shares

Support of Data-in-Transit Encryption

Data-at-rest encryption was introduced in vSAN 6.6 making it the industry’s first native HCI security solution. vSphere 6.7 and vSAN 6.7 cryptographic modules achieved FIPS 140-2 validation by the National Institute of Standards and Technology (NIST), which specifies the security requirements for cryptographic modules.

vSAN 7 Update 1 further improved its security stance with the addition of data-in-transit encryption using the same FIPS 140-2 validated encryption module to secure vSAN data as it traverses the vSAN backend network. Data-in transit encryption can be used independently or in conjunction with data-at-rest encryption to achieve the desired level of protection.

File services in vSAN 7 Update 2 now also support Data-in-Transit encryption. In addition, for 2-node environments using a shared witness host appliance vSAN 7 Update 2 will support DiT encryption for the shared witness.

Space Reclamation for File Shares Using UNMAP

In an attempt to be more efficient with storage space, modern guest OS filesystems have had the ability to reclaim no longer used space using what are known as TRIM/UNMAP commands for the respective ATA and SCSI protocols. Since vSAN has had full awareness of the TRIM/UNMAP commands since 6.7 U1. This is an opportunistic space efficiency feature that can deliver much better storage capacity utilization in vSAN environments. Now in vSAN 7 Update 2 VDFS reclaims or shrinks file shares as files are deleted and returns space to be used elsewhere on vSAN.

Snapshots for File Services Volumes

File services for vSAN 7 Update 2 also introduce a new snapshotting mechanism for point-in-time recovery of files. This mechanism, available through API, allows our backup partners to build applications to protect file shares in new and interesting ways. 

Improved Scale, Performance, and Efficiency

And finally, vSAN 7 Update 2 optimizes some of the metadata handling and data path for more efficient transactions, especially with small files. In this release, the maximum number of shares per cluster has been increased from 32 to 100. Additional optimizations to the underlying file system proxies help reduce context switching, minimizing overheads, and improving latency for file handling.


vSAN 7 Update 2 modernizes hyperconverged infrastructure by providing administrators a unified storage control plane for both block and file protocols and provides significant enhancements that make it a great solution for traditional virtual machines as well as cloud-native applications. Native file services for vSAN helps ease the burden of management when vSAN environments require file-level services. Instead of using legacy physical storage arrays, or deploying VMs to provide file services, an administrator can simply enable this cluster-level service on a vSAN cluster.

VMware took a very careful approach in how best to provide file services that can easily scale, and support a broad variety of conditions. The file services provided in vSAN 7 were an exciting step in that direction. vSAN 7 Update 2 extends the file services capabilities making it the platform of choice for both traditional applications and evolving modern applications. For more information on vSAN File Services, be sure to check out the vSAN File Services TechNote.