vSAN File Services adds a critical service to VMware Cloud Foundation. Layering a distributed protocol access layer on top of vSANs existing shared nothing distributed object store that can serve the NFS needs of Kubernetes as well as traditional services.
New shares setup in vSAN file services are balanced across the cluster. To find the IP address of which container you should connect to for a given share the interface offers this information for NFSv3.
Note NFSv4 is different. a NFSv4 referral enables a multi-server namespace to exist and seamlessly handle redirecting the client to the server that hosts a given directory or share. While it may appear as one namespace, All IO will not have to hairpin through the container owning the primary IP. Similar to iSCSI login Redirects, this simplifies setup, avoids the need for the client to attempt to connect to every node in the cluster.
What does this look like in the interface? This short 1 minute video may help:
VMware Cloud Foundation 4 is a powerful virtual machine and container platform. vSAN file services is critical to meeting the needs of modern applications and container workloads.
If your looking for more information on NFS Redirection the following may be useful:
vSAN File Services adds a critical service to VMware Cloud Foundation. Layering a distributed protocol access layer on top of vSANs existing shared nothing distributed object store. Simplify operations and remove complexity by integrating File workloads into the infrastructure itself. For more information on how to use this with Kubernetes check out Myles Grey’s blog on the CSI integration.
I wanted to capture a few operational tasks withing vSAN File Services to show just how simple it is to setup and manage.
Setting up vSAN File Services
First off setting up vSAN is easy. You will need to setup 3-8 of the containers used for file services. each of these will need:
A unique IP address
DNS (forward and reverse)
subnet and gateway settings
In addition for the cluster you will need:
File Services Domain – This is a unique namespace for the cluster that will be used across the shares.
DNS servers – You can add multiple DNS servers for redundancy.
DNS Suffix – Note you can add multiple of these also.
Configuring a share on vSAN File Services
For each share you will need to configure:
A share name – This will be the path set after the namespace in NFSv4 or directly off the shares primary IP in NFSv3.
A Storage policy – Adjusting the RAID level here can help optimize capacity or resilience.
Share Warning threshold – This is a soft quota that will generate a vSAN health alarm when reached.
Share Hard quota – This is a hard quota. At the point this is reached writes will fail until data is deleted or this quota is raised.
Labels – These can be useful for categorizing a share (adding what department) data classification (compliance or security level) or other organizational methods. These can also be auto-generated when being created by Kubernetes making it easier to identify the MongoDB share the developers are having issues with etc.
Network access controls – These are IP based access control lists for who has read or write access to the shares (along with the usual root_squash ability for systems that need it and can only connect as root, but do be aware of the security implications of using this).
Upgrading vSAN File Services
This one is pretty Simple. vSAN will phone home and look for new versions of the file services OVF package. If the environment lacks internet connectivity from the vCenter a proxy can be used, or the file can be manually downloaded and uploaded to the vCenter.