Consider networking features that can provide availability, security, and bandwidth guarantee in a Virtual SAN cluster.
For details about the Virtual SAN network configuration, see the VMware Virtual SAN Design and Sizing Guide and Virtual SAN Network Design Guide.
Networking Failover and Load Balancing
Virtual SAN uses the teaming and failover policy that is configured on the backing virtual switch for network redundancy only. Virtual SAN does not use NIC teaming for load balancing.
If you plan to configure a NIC team for availability, consider these failover configurations.
|Teaming Algorithm||Failover Configuration of the Adapters in the Team|
|Route based on originating virtual port||Active/Passive|
|Route based on IP hash||Active/Active with static EtherChannel for standard switch and LACP port channel for distributed switch|
|Route based on physical network adapter load||Active/Active|
Virtual SAN supports IP-hash load balancing, but cannot guarantee improvement in performance for all configurations. You can benefit from IP hash when Virtual SAN is among its many consumers. In this case, IP hash performs load balancing. If Virtual SAN is the only consumer, you might notice no improvement. This behavior specifically applies to 1-GbE environments. For example, if you use four 1-GbE physical adapters with IP hash for Virtual SAN, you might not be able to use more than 1 Gbps. This behavior also applies to all NIC teaming policies that VMware supports.
Virtual SAN does not support multiple VMkernel adapters on the same subnet. You can use multiple VMkernel adapters on different subnets, such as another VLAN or separate physical fabric. Providing availability by using several VMkernel adapters has configuration costs including vSphere and the network infrastructure. Network availability by teaming physical network adapters is easier to achieve with less setup.
Using Unicast in Virtual SAN Network
In Virtual SAN 6.6 and later releases, multicast is not required on the physical switches that support the Virtual SAN cluster. You can design a simple unicast network for Virtual SAN. Earlier releases of Virtual SAN rely on multicast to enable heartbeat and to exchange metadata between hosts in the cluster. If some hosts in your Virtual SAN cluster are running earlier versions of software, a multicast network is still required. For more information about using multicast in a Virtual SAN cluster, refer to an earlier version of Administering VMware Virtual SAN.
Allocating Bandwidth for Virtual SAN by Using Network I/O Control
If Virtual SAN traffic uses 10-GbE physical network adapters that are shared with other system traffic types, such as vSphere vMotion traffic, vSphere HA traffic, virtual machine traffic, and so on, you can use the vSphere Network I/O Control in vSphere Distributed Switch to guarantee the amount of bandwidth that is required for Virtual SAN.
In vSphere Network I/O Control, you can configure reservation and shares for the Virtual SAN outgoing traffic.
- Set a reservation so that Network I/O Control guarantees that minimum bandwidth is available on the physical adapter for Virtual SAN.
- Set shares so that when the physical adapter assigned for Virtual SAN becomes saturated, certain bandwidth is available to Virtual SAN and to prevent Virtual SAN from consuming the entire capacity of the physical adapter during rebuild and synchronization operations. For example, the physical adapter might become saturated when another physical adapter in the team fails and all traffic in the port group is transferred to the other adapters in the team.
For example, on a 10-GbE physical adapter that handles traffic for Virtual SAN, vSphere vMotion, and virtual machines, you can configure certain bandwidth and shares.
|Traffic Type||Reservation, Gbps||Shares|
If the 10-GbE adapter becomes saturated, Network I/O Control allocates 5 Gbps to Virtual SAN on the physical adapter.
For information about using vSphere Network I/O Control to configure bandwidth allocation for Virtual SAN traffic, see the vSphere Networking documentation.
Marking Virtual SAN Traffic
Priority tagging is a mechanism to indicate to the connected network devices that Virtual SAN traffic has high Quality of Service (QoS) demands. You can assign Virtual SAN traffic to a certain class and mark the traffic accordingly with a Class of Service (CoS) value from 0 (low priority) to 7 (high priority), using the traffic filtering and marking policy of vSphere Distributed Switch.
Segmenting Virtual SAN Traffic in a VLAN
Consider isolating Virtual SAN traffic in a VLAN for enhanced security and performance, especially if you share the capacity of the backing physical adapter among several traffic types.
If you plan to use jumbo frames with Virtual SAN to improve CPU performance, verify that jumbo frames are enabled on all network devices and hosts in the cluster.
By default, the TCP segmentation offload (TSO) and large receive offload (LRO) features are enabled on ESXi. Consider whether using jumbo frames improves the performance enough to justify the cost of enabling them on all nodes on the network.