- VMware vSAN Automatic Rebalance vs. Proactive Rebalance - Fri, Oct 15 2021
- VMware Tanzu Services overview - Fri, Oct 8 2021
- New features in VMware vSphere 7 Update 3 - Fri, Oct 1 2021
I have detailed vSAN file services in this post: VMware vSAN 7 now with native file services and quotas. All other new vSAN 7 features have been detailed in this post: VMware vSphere 7 U1 and vSAN Improvements.
The vSAN file service is provided via PhotonOS VMs, also called Agent VMs, which are very lightweight, virtual appliances running Photon OS and Docker. The Agent VMs run NFS servers and provide access to file shares. Administrators do not have to worry about those VMs. No patching, no VM Tools management, etc. If such a VM is accidentally deleted, the system will automatically recreate it.
vSAN 7 File Services—The Requirements: ^
CPU requirements—vSAN file nodes require 4 vCPU, so your host's CPU must have a CPU with at least 4 cores to support this; otherwise, you'll get a message that the "virtual machine requires 4 CPUs to operate, but the host hardware only provides 2," and another message saying that "No host is compatible with the virtual machine" as the system can't find a host on which to deploy the Agent VMs.
Static IP and DNS records—You'll need to create forward and reverse DNS records for the vSAN file services nodes. A static IP address, subnet masks, and a gateway for file servers are also needed.
AD domain—For SMB share and NFS share with Kerberos security, you'll also need to provide information about your AD domain and organizational unit (optional). In addition, a user account with sufficient delegated permissions is required.
VSAN File Services—Configuration ^
After logging in to your vCenter Server via the vSphere web client, simply select the vSAN cluster > Configure > vSAN > Services.
There, under vSAN services, you'll see an Enable button. Click that button to start the configuration wizard.
The Introduction page shows you how it works. The system will create a fileshare (NFS or SMB) that can be consumed by modern apps or servers and apps executed outside of the vSAN cluster.
On the first page, we have a choice between the automatic approach and the manual approach. The manual approach is useful for environments that do not have direct internet access (for offline environments).
In our case, we'll leave the default automatic approach, and the system will download the OVF agent VMs directly from VMware by itself. We don't have to go and do that manually.
Many customers have asked for this option, as there are environments that reside behind firewalls or are completely offline due to security compliance. The only way is to manually deploy the OVFs to those clusters.
The next page is the Domain page, where you'll need to enter some of your local AD information. Here is what's needed:
File service domain—Restricted to a minimum of two characters, the vSAN file service domain is a unique namespace that is valid for managing a list of file shares from the network and security perspectives.
DNS servers—Here, you just enter the IP address of the DNS server(s). The IP address is needed for forward and reverse resolution. Hence, you need to go to your DNS server and create those records manually BEFORE starting the assistant.
DNS suffixes—Here, you just enter the DNS suffixes that will be resolved within your environment by the DNS servers.
Note: If you are planning to create an SMB file share or an NFSv4.1 file share with Kerberos authentication, then you must configure an AD domain for vSAN file services.
The next page is a networking page where you need to specify networks, the subnet mask, and gateway information.
Note: It is highly recommended to create a dedicated port group for the vSAN file service. During the configuration, forged transmits and promiscuous mode or MAC learning are enabled by default on the selected port group. In my lab example, I haven't done this, as you can see. I picked up my existing default "VM network."
On the next screen, the wizard is asking for IP pool information. This is why we needed to create our records on the DNS server before starting this wizard. If your cluster has, say, 12 hosts, you must create 12 records. The number of IP addresses must be equal to the number of hosts in the vSAN cluster.
You can click the "lookup DNS" link to auto-fill and test the DNS resolution to make sure that your records are working correctly.
This is the final recap page of the whole configuration. Now we need only click the Finish button and the assistant will start the configuration.
It takes three to five minutes to deploy the VMs, so you have time to relax.
The system will start to provision any ESX agent VMs that are responsible for vSAN file services. A new resource pool is created, and those VMs will be there.
After you have entered all the necessary information, the process is fully automated. You can go back to vSAN > file services and check the details of the environment there.
Note the Upgrade option that enables launching future upgrades, where the old agent VMs will be replaced via rolling upgrade by new ones while preserving files and configuration.
Well, we have successfully installed and activated vSAN file services on our vSAN cluster. This is only the first part of the configuration. The second part will teach us how to configure and manage SMB shares on vSAN 7 U1.