Logical network planning overview

The physical connections between the ports on your network switches and the NICs on the VxRail nodes enable communications for the virtual infrastructure within the VxRail cluster. The virtual infrastructure within the VxRail cluster uses the virtual distributed switch to enable communication within the cluster, and out to IT management and the application user community.

Figure 57.    VxRail Logical Network Topology

VxRail has predefined logical networks to manage and control traffic within the cluster and outside of the cluster. Certain VxRail logical networks must be made accessible to the outside community. For instance, connectivity to the VxRail management system is required by IT management. VxRail networks must be configured for end-users and application owners who need to access their applications and virtual machines running in the VxRail cluster. A network to support I/O to the vSAN datastore is required unless you plan to use Fibre Channel storage as the primary storage resource with a dynamic cluster. In addition, a network to support vMotion, which is used to dynamically migrate virtual machines between VxRail nodes to balance workload, must also be configured. Finally, an internal management network is required by VxRail for device discovery, and this network can be skipped if you plan to use manual device discovery.

All the Dell PowerEdge servers that serve as the foundation for VxRail nodes include a separate Ethernet port that enables out-of-band connectivity to the platform to perform hardware-based maintenance and troubleshooting tasks. A separate network to support management access to the Dell PowerEdge servers is recommended, but not required.

IP address considerations for VxRail networks

IP addresses must be assigned to the VxRail external management network, the vMotion network, and any guest networks. If your cluster will use vSAN as primary storage, IP addresses are required for the vSAN network. You can also choose to segment the external management network to separate subnets for the physical and logical components. Decisions must be made on the IP address ranges reserved for each VxRail network.

Figure 58.    Overview of VxRail Core Network IP Requirements

• The internal management network that is used for device discovery does not require assigned IP addresses.
• Since the external management network must be able to route upstream to network services and end users, a non-private, routable IP address range must be assigned to this network.
• By default, the external management network and vCenter management network share the same non-private, routable IP address range. The vCenter management network provides connectivity to VxRail Manager and the embedded vCenter instance. Starting with 7.0.350, if you do not want VxRail Manager and the vCenter instance to share the same subnet with the VxRail (ESXi) nodes, you can choose to assign a separate non-private, routable subnet to this network.
• The options for VxRail cluster primary storage require either Ethernet for vSAN, or another supported storage option for dynamic clusters. If your cluster will not be deployed with a vSAN datastore, VxRail will not require a vSAN network, and this task can be skipped.

• With a vSAN network, you can reserve a routable or non-routable (private) IP address range
• If your plans include a multirack cluster, and you want to use a new IP subnet range in the expansion racks, reserve a routable IP address range.
• If you plan to configure the cluster into a vSAN HCI mesh topology to share vSAN storage resources, reserve a routable IP address range.
• If you are planning a VxRail cluster only with a local vSAN datastore, a non-routable IP address range is acceptable. In this case, traffic is passed only between the VxRail nodes that form the cluster.
• If you plan to configure a dynamic cluster to use external FC-based storage as primary storage, there is no need to reserve an IP address range.

• If your requirements for virtual machine mobility are within the VxRail cluster, a non-routable IP address range can be assigned to the vMotion network. However, if you need to enable virtual machine mobility outside of the VxRail cluster, or have plans for a multirack expansion that will use a different subnet range on any expansion racks, reserve a routable IP address range.

VLAN considerations for VxRail networks

Virtual LANs (VLANs) define the VxRail logical networks within the cluster, and the method that is used to control the paths that a logical network can pass through. A VLAN, represented as a numeric ID, is assigned to a VxRail logical network. The same VLAN ID is also configured on the individual ports on your top-of-rack switches, and on the virtual ports in the virtual distributed switch during the automated implementation process. When an application or service in the VxRail cluster sends a network packet on the virtual distributed switch, the VLAN ID for the logical network is attached to the packet. The packet will only be able to pass through the ports on the top-of-rack switch and the virtual distributed switch where there is a match in VLAN IDs. Isolating the VxRail logical network traffic using separate VLANs is highly recommended, but not required. A “flat” network is recommended only for test, non-production purposes.

As a first step, the network team and virtualization team should meet in advance to plan the VxRail network architecture.

• The virtualization team must meet with the application owners to determine which specific applications and services that are planned for VxRail are to be made accessible to specific end-users. This determines the number of logical networks that are required to support traffic from nonmanagement virtual machines.
• The network team must define the pool of VLAN IDs needed to support the VxRail logical networks, and determine which VLANs will restrict traffic to the cluster, and which VLANs will be allowed to pass through the switch up to the core network.
• If you plan to have multiple, independent VxRail clusters, it is considered best practice to use different VLAN IDs across multiple VxRail clusters to reduce network traffic congestion.
• The network team must also plan to configure the VLANs on the upstream network, and on the switches attached to the VxRail nodes.
• The network team must also configure routing services to ensure connectivity for external users and applications on VxRail network VLANs passed upstream.
• The virtualization team must assign the VLAN IDs to the individual VxRail logical networks.

VxRail groups the logical networks in the following categories: External Management, Internal Management, vCenter Management Network, vSAN, vSphere vMotion, and Virtual Machine. VxRail assigns the settings that you specify for each of these logical networks during the initialization process.

Before VxRail version 4.7, both external and internal management traffic shared the external management network. Starting with VxRail version 4.7, the external and internal management networks are broken out into separate networks.

External Management network supports communications to the ESXi hosts, and also has common network settings with the vCenter Management Network. All VxRail external management traffic is untagged by default and should be able to go over the Native VLAN on your top-of-rack switches.

A tagged VLAN can be configured instead to support the VxRail external management network. This option is considered a best practice, and is especially applicable in environments where multiple VxRail clusters will be deployed on a single set of top-of-rack switches. To support using a tagged VLAN for the VxRail external management network, configure the VLAN on the top-of-rack switches, and then configure trunking for every switch port that is connected to a VxRail node to tag the external management traffic.

The vCenter Management Network hosts the VxRail Manager and the VxRail vCenter Server. By default, it also shares the same network settings as the External Management network. In this context, the physical ESXi hosts and the logical VxRail management components share the same subnet and share the same VLAN. Starting with version 7.0.350, this logical network can be assigned to a unique subnet and assigned a VLAN separate from the external management network.

The Internal Management network is used solely for device discovery by VxRail Manager during initial implementation and node expansion. This network traffic is non-routable and is isolated to the top-of-rack switches connected to the VxRail nodes. Powered-on VxRail nodes advertise themselves on the Internal Management network using multicast, and discovered by VxRail Manager. The default VLAN of 3939 is configured on each VxRail node that is shipped from the factory. This VLAN must be configured on the switches, and configured on the trunked switch ports that are connected to VxRail nodes.

If a different VLAN value is used for the Internal Management network, it not only must be configured on the switches, but must also be applied to each VxRail node on-site. Device discovery on this network by VxRail Manager will fail if these steps are not followed.

Device discovery requires multicast to be configured on this network. If there are restrictions within your data center regarding the support of multicast on your switches, you can bypass configuring this network, and instead use a manual process to select and assign the nodes that form a VxRail cluster.

Note: Using the manual node assignment method instead of node discovery for VxRail initial implementation requires version 7.0.130 or later.

If you plan to leverage vSAN for VxRail cluster storage resources, it is a best practice to configure a VLAN for the vSAN network. It is also a best practice to configure a VLAN for the vSphere vMotion network. Configure a VLAN for each network on the top-of-rack switches, and then include the VLANs on the trunked switch ports that are connected to VxRail nodes.

The Virtual Machine networks are for the virtual machines running your applications and services. These networks can be created by VxRail during the initial build process, or created afterward using the vClient after initial configuration is complete. Dedicated VLANs are preferred to divide Virtual Machine traffic, based on business and operational objectives. VxRail creates one or more VM Networks for you, based on the name and VLAN ID pairs that you specify. Then, when you create VMs in the vSphere Web Client to run your applications and services, you can easily assign the virtual machine to the VM Networks of your choice. For example, you could have one VLAN for Development, one for Production, and one for Staging.