Understanding the connection dependencies between the applications planned for Cloud Foundation on VxRail will streamline the high-level network design process and improve its effectiveness. It will also simplify the final decisions to be made on the placement of application sets on specific VI workload domains. To reduce the routing workload at the physical network layer and optimize the efficiency of the virtual networks, an assessment of the routing maps and dependencies for the sets of applications targeted for Cloud Foundation on VxRail is necessary.

When applications running on different subnets need to connect with each other, the network traffic is directed to a router, which then decides the path the network traffic takes to communicate. For environments that do not use VMware NSX, this means the virtual machine network traffic must travel upstream out of the virtual layer, where the routing decisions are made at the physical network layer.

Cloud Foundation on VxRail leverages NSX to enable support for routing in the virtual networks on the VI workload domains. This means the defined network paths can be in different locations:

• Between applications within a Cloud Foundation VI workload domain
• Between applications in different Cloud Foundation VI workload domains
• Connected to external applications outside of a Cloud Foundation VI workload domain

Your sets of applications are likely separated by factors such as function or end-user accessibility (such as web tiers and database tiers). Within Cloud Foundation on VxRail VI workload domains, you might want to segment those application sets for network isolation, so that end-users can only access, for instance, the web tier network. You might also want flexibility so that the applications in each isolated network are not tied to a static pool of resources, or a static location.

Figure 19            Three-tier application on separate virtual networks connected with virtual routers

Virtual machines deployed in a Cloud Foundation VI workload domain connect to port groups on a virtual switch in their Cloud Foundation VI workload domain. Each port group on a virtual switch is assigned a unique identifier called a ‘virtual LAN’ (VLAN), and the traffic on a VLAN is logically isolated from the network traffic on another VLAN. If a virtual machine needs to connect with another virtual machine on the same VLAN but not on the same virtual switch, an extended network is deployed. VXLAN for NSX-V or GENEVE for NSX-T supports extending the non-routable VLAN-based network over a routable network. The traffic from one virtual machine flows through the virtual switch on a host and up a Tunnel Endpoint, over the physical network, and down through the Tunnel Endpoint on the second host, and is delivered to the second virtual machine. An extended physical network supports accessibility between the virtual networks in the VI workload domains. This configuration forms an extended logical switch across the individual virtual switches in the VxRail clusters.

NSX uses logical routers or gateways placed at ascending tiers in the virtual network to enable connectivity. A logical router at ‘Tier 1’ is deployed for the applications on one logical switch that need to access an application on another logical switch, such as connecting from the web tier application to the app tier. Another set of logical routers or gateways is positioned at ‘Tier 0’, and serves as the pathway to the upstream external network through uplinks. This logical gateway at ‘Tier 0’ serves as the border between the physical network and the virtual network, and also has a peering relationship with the logical gateways on ‘Tier 1’. The set of gateways in ‘Tier 0’ on the edge synchronizes with upstream physical routers, and also share routing information with downstream logical gateways on ‘Tier 1’.

Figure 20            Overview of Physical and Logical Network Routing Relationships

Documenting the interdependencies between the applications will guide the high-level network design to support the application connectivity dependencies, and serve as the basis for the planning process of the placement of the virtual machines into VI workload domains.