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 recommended.

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-T, this means that the virtual machine network traffic must travel upstream out of the virtual network layer, where the routing decisions are made at the physical network layer.

Cloud Foundation on VxRail leverages NSX-T to enable support for routing in the virtual networks on the VI workload domains. This means that 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 35.    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 ‘virtual LAN’ (VLAN) identifier, 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 used. Using 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, or segment within NSX-T, across the individual virtual switches in the VxRail clusters. A virtual router, known as a Tier-1 gateway, is deployed within NSX-T for the applications on one segment that need to access an application on another segment, such as connecting from the web tier application to the app tier.

The Tier-1 gateways are positioned in the NSX-T network adjacent to edge devices, or Tier-0 gateways, which serve as the ingress and egress point with the external network. The Tier-1 gateways peer with the Tier-0 gateways in the NSX-T network using BGP for sharing routing information. The Tier-0 gateway, represented by NSX-T edge-virtual devices, peer with upstream external routers for the purposes of sharing routing information. This enables a pathway for traffic from a virtual machine to connect to an application on an external host, or connect to external networking services. These peering relationships form a seamless barrier between the physical network and the NSX-T virtual networks.

Figure 36.    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.