Setting up vSAN File Services
vSAN File Services adds a critical service to VMware Cloud Foundation. Layering a distributed protocol access layer on top of vSAN’s 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 within vSAN File Services to show just how simple it is to setup and manage.
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 setting – Routing of NFS is supported.
I would recommend allocating a sequential block of IP addresses, as this will make it easier in setup to use the "Autofill" functionality.
These file server containers will float across hosts, and failover between hosts in event of maintence or host failure.
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. These can serve as a key organizational tool.
- Network access controls – These are IP based access control lists for who has read or write access to the NFS shares (along with the usual NFS 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). Note you can use CIDR notation (10.0.0.0/8) or individual ip addresses or ranges.
Upgrading vSAN File Services
After deployment you may notice there is an updated version of vSAN File Services. This process is 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.
