VMware vSAN 7 now with native file services and quotas

With the recent announcement and release of VMware vSphere 7, a new version of vSAN 7 has also made its appearance. We talked briefly about new file services in vSAN in our detailed post. Today, we'll have a look into its deployment and configuration through the user interface via the vSphere web client.

vSAN 7 services ^

Why is it interesting that vSAN provides file services such as NFS 3 or 4.1? Those file services can be used by Kubernetes directly from within the same vSphere user interface. File shares via vSAN are not meant to replace your existing filer; rather, vSAN should be used as a complementary file share service for modern applications within vSphere.

While you might think it is a good idea to run VMs on top of the NFS share, VMware does not recommend that the NFS share be consumed by other VMware products.

VMware vSAN file services are implemented via file service agents, which are managed via the vSphere ESX Agent Manager.

The file service agents are small VMs that run Photon OS and Docker. They have the NFS service installed and activated to provide the file sharing service. The agent image OVF is downloaded directly from the Internet during the configuration steps via a wizard. However, the image can also be downloaded separately for sites that do not have Internet access.

Configuration ^

Let's assume you have your vSphere 7 up and running and that you have already activated your vSAN.

Connect via vSphere client and select your vSAN cluster. Then select Configure > vSAN > Services > File Service > Enable.

Enable vSAN file services

Enable vSAN file services

This starts a new, web-based wizard. Click the Next button to continue.

Configure File Service wizard

Configure File Service wizard

 

Select the "Trust the certificate" option to download the file service OVF from the Internet, or choose the "Manual approach" option if you don't have Internet access. You must, however, download this OVF from another computer.

Select the Trust the certificate option

Select the Trust the certificate option

There are some steps you'll have to carry out for each share. But first, we need to configure a namespace, which is a unique cluster identifier.

You must also fill in your DNS server IP address and your DNS suffix.

Create a vSAN namespace domain

Create a vSAN namespace domain

Pick the network used for the file services, IP protocol, subnet mask, and gateway.

Fill in the networking details

Fill in the networking details

Then go to your DNS server and create some static records, according to the number of hosts you have in your vSAN cluster. (In my case, I have three hosts.)

Create forward and reverse DNS records

Create forward and reverse DNS records

Once done, continue on to the next screen, where you'll create an IP pool. In my case, I entered the first IP address and clicked the Autofill link, which populated both my other IP addresses automatically.

On the right, click Lookup DNS so that the system will populate the fully qualified domain names (FQDN) from your DNS server.

Create an IP pool

Create an IP pool

The final screen of the assistant shows all the details. There's nothing to do here, just click the Finish button to close the window.

Review the details and click Finish

Review the details and click Finish

The vSAN cluster will start to work and deploy some agents' VMs and create a unique resource pool where those agents reside.

vSAN will create three agent VMs and a new resource pool

vSAN will create three agent VMs and a new resource pool

 You can monitor the agents' deployment via the Recent Tasks pane at the bottom of your vSphere web client.

In my case, I noticed an error because my ESXi hosts had only two CPUs, but the system needs four CPUs. It seems that your hosts need four CPUs to be able to leverage vSAN file services. This is something to keep in mind.

Make sure your hosts have four CPUs each

Make sure your hosts have four CPUs each

In the nested lab I'm running, I was able to reconfigure my ESXi hosts each with four CPUs so that at the end I was able to see this screen with three agents up and running.

Nodes deployed in a new resource pool

Nodes deployed in a new resource pool

And finally, we're able to add some file shares. For each new file share, we'll need to provide:

  • A share name
  • A storage policy: You can adjust the RAID level and optimize capacity or resilience.
  • Share warning threshold: A soft quota; this will create a vSAN alarm if reached by your users.
  • Share hard quota: This is a hard quota. There will be no more writes until data is deleted or this quota is raised.
  • Labels: You can categorize a share when created by Kubernetes.
  • Network access controls: IP-based access control lists for who has read or write access to the NFS shares.
Add a new file share

Add a new file share

Give your share a meaningful name, choose a storage policy, and enter soft and hard space quotas.

Chose vSAN file share options

Chose vSAN file share options

The next step is to restrict or allow access to your new share. There are three options here to choose from. It's pretty straightforward.

Customize access to the file share

Customize access to the file share

Then, the final screen allows you to see your options. Validate here or go back and change a value if necessary.

Recap of the file share creation

Recap of the file share creation

This is the final screen, showing the first share. We're done.

We have successfully created a new vSAN file share

We have successfully created a new vSAN file share

Conclusion ^

VMware vSAN native file services provide NFS only in this release so far. I think there is more to come, and we'll see other file services in next release. The process is very straightforward and easy to follow via those two assistants. VMware vSAN file services offer a great experience for cloud–native services and infrastructure shares.

The system is fully resilient and by using the virtual namespace it mitigates the failures of a host. The NFS consumer won't realize that the underlying host has a hardware problem because the virtual namespace spans multiple hosts and is able to redirect connections automatically.

The performance scales with the nodes in a linear way. More nodes add more performance. The shares are balanced across clusters (one node per host) while still maintaining the same unique IP address for connection.

1+
avatar

Poll: Does your organization plan to introduce Artifical Intelligence?

Read 4sysops without ads and for free by becoming a member!

0 Comments

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2020

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account