vSAN File Services considerations

http://www.yellow-bricks.com/2020/04/15/vsan-file-services-considerations/

• Targeted use case: Cloud Native Applications and file services for traditional apps
• NFS v3 and NFS v4.1 are both supported
• A minimum of 3 hosts within a cluster
• A maximum of 64 hosts within a cluster
• Not supported today on 2-node
• Not supported today on a stretched cluster
• Not supported in combination with vLCM (Lifecycle Manager)
• It is not supported to mount the NFS share from your ESXi host
• Maximum of 8 active FS containers/protocol stacks and 8 FS VMs are provisioned
• FS VMs are provisioned by vSphere ESX Agent Manager
  • You will have one FS VM for each host up to 8 hosts
• FS VMs are tied to a specific host from a compute and storage perspective, and they align of course!
• FS VMs are not integrated with vSAN Fault Domains
• FS VMs are powered off and deleted when going into maintenance mode
• FS VMs are provisioned and powered on when exiting maintenance mode
• On a standard vSwitch, the following settings are enabled on the port group automatically: Forged Transmits, Promiscuous Mode
• On a Distributed Switch the following settings are enabled on the port group automatically: Forged Transmits, MAC Learning
• vSAN automatically downloads the OVF for the appliance, if vCenter Server cannot connect to the internet you can manually download it
  • The ovf is stored on the vCenter Appliance here, if you ever want to delete it: /storage/updatemgr/vsan/fileService/
• The FS VM has its own policy (FSVM_Profile_DO_NOT_MODIFY), which should not be modified!
  • The appliance is not protected across hosts, it is RAID-0 as resiliency is handled by the container layer!