Configure Native File Services on vSAN 7.0 !!

                                              Native File Services on vSAN 7.0

Hello Everyone,

Today, we are covering up about the new and exciting feature of vSAN 7.0 i.e. Native File Services over vSAN.

This is quite an interesting feature for File share platform which can leverage the benefit of HCI powered storage i.e. VMware vSAN.

vSAN File Services, fully integrated into vSAN 7, now has the ability to create file shares alongside block volumes on your vSAN data store. These file shares are accessible via NFS v3 and NFS v4.1 protocols. It is very simple to setup and use, as you would expect with vSAN. It is also fully integrated with vSAN Virtual Object Viewer and Health, with its own set of checks for both File Server Agents and the actual File Shares themselves.

Let’s begin with a look at how to deploy vSAN File Services. It really is very straight-forward, and is enabled in much the same way as previous vSAN services. We’ll begin with a 4-node vSAN 7 cluster, as shown below.

Next, in the vSphere Client, Click on Cluster and choose Manage tab in right side.

Navigate to the vSAN Services section.

Click on Services and you will see on right side that File Services is disabled as of now.

Click on Enable and a new wizard will open like below.

Before click on NEXT, here are some prerequisites to enable this File Service. we should have all details before proceed.

Checklist

The following information is needed to configure File Service.

• Static IP address, subnet masks and gateway for file servers
• DNS name for each IP address or allow the system to do a reverse DNS lookup.

Click NEXT and it will go for download the File Service agent appliance OVF file to create an appliance as a NFS server.

If there no option for direct internet connection and then download the VMware Virtual SAN File Services Appliance 7.0 from here (https://my.vmware.com/group/vmware/details?downloadGroup=VSAN-FILESERVICE-700&productId=974 )

How File Services is implemented on vSAN is that we implement a set of File Server Agents, managed by vSphere ESX Agent Manager. These are very lightweight, opinionated virtual appliances running Photon OS and Docker. They behave as NFS servers and provide access to the file shares.

There is Distributed File System sitting between the NFS File Shares and vSAN. This Distributed File System component is how we share the configuration state (file share names, file share redirects, etc.) across all of the File Service Agents. If any of the File Service Agents were to fail on one of the ESXi hosts in the vSAN cluster, this enables the agent to be restarted on any other host in the vSAN cluster and continue to have access to all of the metadata around its file shares, etc.

Click on Manual approach and browse the location of OVF file. it requires 6 files for this, hope you will download all these required files.

Click NEXT

 Give details for Domain. Click NEXT

Give Network details and Click NEXT

Give IP Pool details

Review your details and Click FINISH

This will lead to a number of tasks being initiated in your vSphere environment for deploy OVF template and Install agent which I’ve captured here:

Alright, when the tasks will completed successfully completed without any errors then 

you will have a new vSAN File Service Node/Agent per vSAN node (4 agents for my 4 node vSAN cluster).

And if we take a look at the vSAN File Service in vSAN Services, we now see it enabled with various additional information, most of which we provided during the setup process:

Now that we have enabled vSAN File Services, let’s go ahead and create our first file share.

A new menu item now appears in Configure  > vSAN called File Service Shares. You can see the domain (vSAN-FS) that we created in the setup, as well as the supported protocols (NFS v3 and 4.1) as well as the Primary IP. One of the File Service Agents was designated as the primary during setup, and this is the IP address used for mounting all NFS v4.1 shares. The connections are redirected internally to the actual IP address of the Agent presenting the share using NFS referral. Click on ADD to create the first share.

In this wizard, we will provide a name for the share. We will also pick a vSAN storage policy for the share. The policy can include all of the features that we associated with block storage policies for performance and availability. We also have the options of setting a warning threshold and a hard quota. Finally, you can also add labels on the file share. 

Click NEXT

Configure Net access details.

This step is to specify which networks can access the file share. You can make the share accessible from any network, or you can specify which particular networks can access the file share and what permissions they can have e.g. Read Only or Read Write. The Root squash checkbox is a security technique used heavily in NFS which ‘squashes’ the permissions of any root user who mounts and uses the file share.

Click NEXT and Review the file share and click Finish to create it.

A file share has been created and looks like as below.

So, it was a quite simply way to create the file shares with just a few clicks in the UI. And of course, all shares are deployed on the vSAN datastore, and are configured with both availability and performance through Storage Policy Based Management (SPBM).

I also want to tell you once thing as well that if you have a need to change the soft or hard quota of a file share, add some labels, or change the network access, simply select the file share, click Edit, and make your changes on the fly without any disruption to the shares.

Now that the File Share has been built, lets consume it from a Linux (Redhat 7.6) VM.

To check the mount availability, i run showmount -e command on my RHEL VM and here is the output

As we can see the file share /FS01 is on my fourth File Service Agent with the IP Address 172.16.10.13. To mount this file share as NFS v4.1 via the Primary IP and the NFSv4 referral mechanism, I need to include the root share (/vsanfs) in the mount path even though it is not shown in the showmount output. This will then refer the client request to mount the file share to the appropriate File Service Agent.

Now, Lets make a directory first on VM to mount this NFS share and then will mount this share.

I created a new directory with name /share1 and mounted the NFS share. See below.

Below mount command output shows that NFS share has been mounted successfully with NFS version 4.1.

Also, you can mount this share with NFS 3 version as well with below command.

For NFS version 3 mount option

And  if you can’t remember the correct syntax. In the vSphere UI, simply select the file share and click on ‘Copy URL‘ and then select which verison of NFS you want to mount and copy that exact URL and mount your NFS share.

So, this was really an exciting feature for NFS share purpose and we can use it for our NFS share requirements with all vSAN storage native features like Availability, Redundancy etc..

Thanks for your time and Cheers..