Getty Images/iStockphoto
VMware vSAN file service introduces NFS, SMB file shares
VMware introduced NFS and SMB file shares with the vSAN file service. This service lets VMs access any stored data in the vSAN datastore as long as you configure access rights.
VSAN File Service's initial release only supported network file systems; but the vSphere 7 Update 1 introduced SMB file sharing for Windows. With both NFS and SMB support, you can efficiently transfer data through a VM to a vSAN data store and access stored data in vSAN on any VMs or devices.
VMware's vSAN File Service functions as a file server to store data. VSAN provides reliable shared storage for vSphere hosts, but doesn't rely on dedicated external storage from a storage vendor. VSAN uses host local storage -- flash or magnetic disks -- to create a centralized vSAN datastore for vSphere clusters. This enables you to replace your storage products with vSAN.
In vSAN's initial 2013 release, physical workloads couldn't access vSAN storage in the vSphere cluster. VMware solved this with Internet Small Computer System Interface access into the vSAN cluster. This enables a Windows or Linux server to connect and store data on vSAN storage. But this isn't an answer for all storage needs.
The vSAN file service provides access to both NFS and SMB file shares and lets you store data in a vSAN data store that's accessible to any VM, client or device as long as you configure access rights.
VSphere 7 Update 2 enhances vSAN file service capabilities
VMware first introduced the vSAN file service in vSphere 7, which means you must upgrade from any previous versions of vSphere to use this product. VSphere 7 Update 1 implemented Windows file share support.
VSphere 7 Update 2 introduces two-node and stretched cluster support, snapshot support per share and enabled 100 file shares. The vSAN file service also has a maximum number of 64 file servers in a cluster and vSAN file service nodes are no longer deleted -- they power off when a host enters maintenance mode.
VSAN file service use cases include NFS file share
You could originally store files on a Windows file share through either a physical or virtual Windows server. That server stores data on a virtual disk within a virtual server, such as vSAN. The vSAN file service eliminates the middleman and provides direct Windows file share access with NFS. This improves performance and removes the Windows Server license requirement.
An NFS file share is also required when you run VMware vCloud Director, which normally needs a Linux server or a NAS product. With the vSAN file service, a vSAN cluster can provide an NFS file share without any other servers. This saves resources and eliminates the need for a Linux server.
You can use an NSF file share for files that you plan to store and products that rely on a Windows file share. VMware's Dynamic Environment Manager stores its configuration and user profiles on a file share that can live on a reliable vSAN cluster.
Dive into vSAN file service architecture
The vSAN file service feature doesn't run directly on an ESXi host OS. Instead, vSAN implements the vSAN file service in one VM per host. Those VMs run VMware's Photon Linux distribution, which vSAN implements in Docker containers. The Photon OS has its own high-availability implementation because it's distributed among those containers.
VMs normally must go through the network stack in the VMkernel to access their VMDK files. The vSAN file service uses a Virtual Machine Communication Interface (VMCI) device -- the vSocket interface -- that enables each VM to communicate directly with the host through the VM's VMCI interface. This efficiently transfers data through the VM where it's inbound to the vSAN datastore.
The containers implement the Virtual Distributed File System (VDFS), which vSAN stores within its underlying datastore. Figure 1 shows four vSAN file service nodes that vSAN maintains automatically, such as VM creation and deletion. But in vSphere 7 Update 2, vSAN no longer deletes these VMs when a host enters maintenance mode -- they are instead powered off.
VSAN configures the VMs with four virtual CPUs and each vSphere host requires an additional 10 GB of memory.
How to setup the vSAN file service
You can enable vSAN file service on a vSAN cluster like any other feature you add to the cluster. When you begin configurations, you must specify the port group where the vSAN file service VMs attach. This includes the subnet mask, gateway and DNS information.
Because there's a VM on each host, you must specify an IP address for each VM. In Figure 2, it's possible to use the autofill feature to increase the address for each host based on the first specified address. You must configure a DNS lookup and reversed lookup entry for each entry.
If you use Windows file shares or an NFS 4.1 share with Kerberos, you must configure details for an Active Directory domain through vCenter Server via the vSphere web client. Once you enable the vSAN configuration wizard, provide all necessary configuration details and click Finish. The VMs then deploy on all hosts and you can now use the vSAN file service. The option to create a file share also becomes available in the vSAN configuration menu.
Create file shares with the vSAN file service
The vSAN file service offers two types of file shares: NFS or SMB. Both NFS and SMB file shares contain common values such as a name, the storage policy for redundantly storing data and a storage quota. Figure 3 demonstrates how you must provide this information when you configure SMB file shares.
You must choose a vSAN version when you configure NFS file shares. When you select version 3 vSAN adds a page in the configuration wizard to setup access restrictions and root squash on a per host basis. For version 4.1, you configure access control with Kerberos.
After you create an SMB file share, there are two menu options available: Copy the file share path into the clipboard or copy the command to the clipboard. If you copy the file share path into the clipboard, vSAN creates a Universal Naming Convention path to the server and a share name that clients can use to connect.
If you copy the command to the clipboard, vSAN launches the Microsoft Management Console (MMC) to configure the file share with specific Windows settings. In Figure 4, the file share named Data1 is open in MMC. This creates OS permission for that file share.
You can access the file shares after the configuration finishes. However, there's a constraint with failover times. When a VM that runs a container node servicing the file share fails, such as when the host fails, it incurs failover time.
