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.
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..
Do you have any advice on backing up these file shares with CommVault?
ReplyDelete