Configuring VSAN networking on an existing switch
Networking is the glue that holds the VSAN distributed storage nodes together. To permit redundancy, storage delivery, policy management, and so on, a robust and properly-configured network is key. From within vSphere, VSAN is enabled on a network interface as a service. If you are familiar with creating and enabling vMotion, management, and fault tolerance interfaces, you are already familiar with this process!
This recipe will cover the creation of a new VMkernel network interface in an existing vSwitch or dvPortGroup.
Getting ready
- You should be logged in to the vSphere Web Client as an administrator or user, authorized to alter cluster-level settings and networking
- There should be physical 1GbE or 10GbE interfaces available for use by VSAN
- You should have a unique IP subnet available for application to VSAN interfaces
- A separate VLAN for VSAN traffic is optional
- Your upstream physical switch should be able to handle multicast traffic on the interfaces used by VSAN
How to do it…
- Navigate to Home | Hosts and Clusters | Datacenter | Cluster | Host | Manage | Networking:
- Click on Add host networking:
- Under Select connection type, choose vmkernel, and then click on Next:
- Under Select target device, choose your existing vSwitch or distributed port group, and then click on Next. This example uses a dvPortGroup called VSAN:
- Under Port properties, enter a network label (if applicable), and then check the Virtual SAN traffic checkbox, and then on click Next:
- Under IPv4 settings, assign an address in a subnet unique to VSAN, or choose automatic configuration if you use DHCP. Then, click on Next:
- Finish the wizard.
- Complete this recipe on all hosts in the VSAN cluster.
How it works…
As VSAN is a unique service at the hypervisor level, the service is bound to a specific VMkernel interface. This is similar behavior to vMotion and fault tolerance tagging. There is no best-effort networking with VSAN. If there are no tagged interfaces, the host will not be able to join the VSAN cluster and will be network-isolated. Subsequently, HA configuration will also fail.
There's more…
The VSAN network should be in its own unique IP subnet to help avoid potential network irregularities related to default routes (for example, to prevent routed traffic from using VSAN VMkernel network interfaces to access the gateway). While VSAN interfaces can function in existing subnets, and traffic will be restricted to the tagged interface, it is the best practice to give it its own subnet for maximum compatibility and reliability across the entire virtual and physical infrastructures.
VSAN traffic can be shared with other VMkernel interfaces, such as those used for vMotion. This is not ideal, however, as service separation across VMkernel interfaces is preferred. There is no harm with sharing VSAN traffic and non-VSAN traffic across physical 10GbE interfaces (for example, the VSAN VMkernel interface can exist in the same vSwitch/uplink set with non-VSAN interfaces). If you are using 1GbE physical interfaces, those interfaces should be dedicated to VSAN as per VMware best practices.
See also
- For more information about physical networking requirements, multicast, LACP/link-aggregation, and so on, please see the Appendix B, Additional VSAN Information specifically, if desired.