NSX-T is VMware’s software defined networking platform, it is a critical component of VMware Software Defined Data Center (SDDC) strategy. NSX-T is gaining industry momentum due to innovations in container networking, security, performance, and scalability. Integrating network services along with your application is a critical piece of delivering services faster to your application developers, and application consumers. vRealize Automation (vRA) supports NSX deployment topologies to align with business, and IT needs. Network topology can be based on access requirements, security constraints, type of application, or consumption-only in the form of external networks. My colleague Jad wrote an excellent blog about the benefits of vRA with NSX. I encourage everyone to take a look.
VMware’s Cloud Management Business Unit (CMBU) proudly announced the support of NSX-T as part of vRA 7.5. With vRA 7.5, you will be able to provision NSX-T resources in the same way as with NSX-v resources using the application blueprint designer. Features of NSX-T integration with vRA 7.5 are:
- On-demand routed, NAT and load balancer (LB)
- Consumption of existing logical switches and network security groups (NSGroups)
- One-click Application Isolation
- Day 2 modification of NAT and security policies
- Native consumption of NSX-T services such as DHCP and route propagation
To demonstrate NSX-T integration from the lenses of the vRA, we will take a deep dive into each area.
NSX-T Overview:
It is critical to start with an understanding of NSX-T architecture and its components. There are tons of blog posts that review the architecture in detail (routing pt-1 and routing pt2). A quick recap for those not familiar with NSX-T:
Tier-0 Router– Tier-0 router provides connectivity to the outside world using static or BGP routing. Tier-0 router maps to two transport zones (TZ), VLAN and overlay. VLAN TZ maps to a set of uplink(s) to the physical domain, while overlay TZ communicates with Tier-1 routers using routed link ports. As part of NSX-T integration with vRA, a Tier-0 instance must be pre-provisioned and included as part of a network reservation.
Tier-1 Router– Tier-1 router connects upstream to the Tier-0 router via router link port and downstream to L2 logical switch(es). Based on the blueprint definition, vRA will provision or associate an existing Tier-1 router for on-demand service(s) based on the request. A newly provisioned Tier-1 router will associate with a logical switch and a Tier-0 router.
Existing Networking and Security:
Existing Network – Also known as external networks in vRA. External Networks are pre-provisioned by the network administrator and discovered by vRA as part of the onboarding process. External Networks can be traditional vDS port groups (virtual distributed switch) or logical switches backed by NSX-T (VLAN or Overlay). It is possible to place both VM workloads and on-demand load balancers (LB) on an external network. While VM workload binding is independent of the type of port group backing (vDS or NSX-T), NSX-T LB can only bind to an External Network that is backed by NSX-T.
Existing NS Group – Pre-created in the NSX-T, NSGroups are made available by the security administrator in order to implement micro-segmentation. Once discovered by vRA, these security groups can be dragged (drag-n-drop) onto the blueprint canvas and applied to one or more virtual machines. Once applied, you can view the active NSGroup applied, modify the existing NSGroup applied to an instance, or disassociate the NSGroup applied by the vRA. vRA does not manage NSGroup applied outside of the vRA.
NSX On-Demand Services:
NSX-T on-demand services are new NSX-T resources provisioned to support application deployment. Depending on access or application requirements, vRA 7.5 supports consumption of the following type of on-demand resources with the NSX-T.
On-Demand NAT Network:
On-Demand NAT Network – On demand NAT network are networks that require NAT for North-South (N-S) traffic. Typically, use on-demand NAT networks to support overlapping IP subnet scenarios, RFC 1918 address block instead of globally routable subnets. A network administrator can reuse the same or unique RFC 1918 blocks across many L2 domains. East to West (E-W) Traffic within the L2 segment will leverage the private IP address block defined by the network administrator. NSX-T Tier-1 router will NAT all N-S traffic.
For an on-demand NAT network, vRA provisions a dedicated Tier-1 router per blueprint and will configure it to advertise all NAT IP addresses to the Tier-0 router. NSX-T Tier-0 router must be configured outside of vRA to advertise this NAT IP addresses into the physical domain. Tier-1 NAT router will run in Active & Standby mode for redundancy. vRA supports both Source and Destination N:1 NAT.
A network administrator also has the option to enable DHCP services within a NAT network. If enabled, vRA will provision a DHCP server instance per logical subnet using the NSX-T DHCP service. Leveraging native DHCP service simplifies IP address management. DHCP enabled NAT network does not require an external IPAM or leverages vRealize Automation native IPAM.
On-Demand Routed Network:
On-Demand Routed Network – On demand routed network are networks that are globally routable within an enterprise domain (No-NAT). Since IP blocks associated with a routable network are unique within an enterprise, vRA assumes external IPAM for IP address assignments. Therefore, we do not support enabling DHCP against an on-demand routed network. Network administrators can leverage the Sovlab IPAM plugin or 3rd party plugin to maintain IP address allocation and configuration. Similar to the on-demand NAT network, vRA provisions a dedicated NSX-T tier-1 router and a logical switch for the on-demand routed network. Unlike the on-demand NAT network, the vRA provisions the Tier-1 router to advertise the directly connected subnet instead of specific NAT IP.
On-Demand Load Balancer:
On-Demand Load balancer– Load Balancers (LB) are a critical part of a three-tier enterprise application. Just like in NSX-v, a network administrator can drag and drop on-demand load balancers onto the blueprint design canvas. An on-demand LB can be one or two arm mode, depending on use case. The model to use is strictly based on your application access requirements. Both the one and two arm load-balancer can apply to an existing or on-demand network. vRA requires LB deployment model binding at the time of blueprinting. Service health checks are on by default or but application owners can customize (if required) based on application needs.
Application Isolation:
Application Isolation– Application Isolation fences an application from the external world. Applications within a deployment can freely communicate with each other. However, external access to an application is not allowed (including deployments from the same blueprint) unless explicitly permitted by the NSX-T distributed firewall. From a vRA deployment perspective, app isolation provides an additional layer of security that protects the entire application deployment from all other deployments (e.g. those provisioned from the same blueprint).
Application Isolation addresses this by dynamically adding the needed security layer at the component level to automatically block the cross-deployment traffic. Add a Component-level NSGroup allowing application traffic comes in and out of the blueprint to ensure cross deployment communication.
Call To Action:
If you are attending VMworld Barcelona, I encourage you to attend the following sessions on NSX infrastructure automation with the vRA:
NET1723BE – Day 2 Automation of NSX Data Center Using vRealize Suite
MGT1652BE – Application Networking and Security with vRealize Automation and NSX-T
