Archive for

vSAN File Services – How to find the connection URL

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:

The RFC – https://tools.ietf.org/html/rfc7530

vSAN File Services – A First Look at File Services for VCF

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.

https://youtu.be/poJ2ArGmHEg

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).

https://youtu.be/q2jRd2RBIaw

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.

https://youtu.be/1L9IxcispAY

If you have any other vSAN File Services questions be sure to checkout the FAQ or ask on twitter @Lost_signal.