(this article was originally posted on virtualjad.com)
Networking and security automation — and specifically the use of on-demand services — will continue to play a more significant role as NSX (and network virtualization in general) continues to become more and more prominent. Customers are still trying to understand the impacts of app-centric networking and whether or not they’re ready to hand these critical services to automation tools. There’s a perception that automation reduces control and/or visibility into networking and security services that traditionally involve a ton of ownership, red tape, and several siloed personalities that love to hear their own voice (I used to be one!). Plus, there are personal domains and certifications to protect!
Once these folks realize vRA + NSX will provide greater control, more governance, and better visibility than they’ve ever had before, heads tend to deflate a bit. NSX adoption is on a rocketship and its benefits are resonating with traditional network silos and modern shops alike. As adoption (and resulting trust) continues to grow within an enterprise, the second part of the equation — automation — become the obvious next step for streamlining network and security services, often getting kicked off with two wonderful words: now what? Enter vRealize Automation.
For its part, vRA is designed to bridge the gap between a pure consumption model and on-demand everything. It does this by natively supporting both concepts (plus everything in between) to appease those who are just getting their feet wet and those who ready to rumble. This post will cover vRA’s networking constructs and configuration elements, specifically when NSX is in the mix. It is intended to help you grasp the concepts that will be covered in much more detail in the subsequent vRA and NSX Integration Series.
Network Services in vRA
vRA and NSX can be configured to simply consume existing networking and security services managed by the endpoint (Existing), or set to dynamically deploy application-centric services during machine provisioning (On-Demand) using native platform integration to automate otherwise manual tasks. You can also opt for combining the two options in a single blueprint.
Once all the prerequisite configurations are done, these services are available for use from the Converged Blueprint (CBP) unified canvas…
Each of these services can be dragged and dropped onto the unified canvas to be incorporated into the blueprint design. Once properly bound to the machine components and configured, the corresponding service will be automatically deployed per the blueprint’s policy. The available On-Demand services include On-Demand Load Balancer, On-Demand NAT Networks, On-Demand Routed Networks, and On-Demand Security Groups:
- On-Demand Load Balancer (ODLB) – Deploys a dedicated* NSX Edge Services Gateway (ESG) and logical switch; automatically configures the appropriate load balancing policy (one-arm and inline load balancing policies are supported).
- On-Demand NAT Network (ODNAT) – Deploys a dedicated* NSX ESG and logical switch; automatically configures the appropriate NAT policy based on the corresponding network profile. ODNAT supports both 1:1 and 1:Many configurations.
- On-Demand Routed Network (ODRTD) – Adds a dedicated interface on the upstream distributed logical router; creates a new logical switch for the router interface and machine vnics; applies IP policy as defined in the corresponding network profile.
- On-Demand Security Group (ODSG) – Creates a new Security Group and binds one or more existing Security Policies. The desired security policies are added to the ODSG during blueprint configuration.*if a blueprint is configured with both an ODLB and ODNAT, only one ESG will be deployed and configured for both services accordingly
In contrast, the Existing services are purely consumption-based. These services are collected during endpoint inventory (in this case, vSphere and NSX Manager) and may include a combination of traditional and NSX-backed services:
- Existing Network – Endpoint networks that are presented as network paths once they are collected by vRA. These may include traditional vSphere port groups, dvport groups, or logical networks (switches) backed by NSX.
- Existing Security Group – Pre-created Security Groups made available by the security admins, for example. Once collected by vRA, these security groups can be simply dragged onto the canvas and bound to one or more component machines. Using existing security groups will provide options for security admins that prefer a little more control vs. automation.
- Existing Security Tag – Pre-created NSX Security Tags collected during endpoint inventory. Security Tags are used to tag machines with specific metadata, which results in those machines being dynamically added to an existing Security Group and the associated policy. One or more tags can be dragged to the unified canvas and will apply to all machine components on the canvas.
Once the prerequisite configurations are done, network and security automation is a matter of dragging and dropping the desired services onto CBP’s unified canvas and binding them to the appropriate component machines. The rest of the automation euphoria happens during provisioning…and again at decommissioning, when deployed services are rolled back.
Network Profiles
Network Profiles are created in vRA to define the settings and details for a particular network, including the name, subnet mask and gateway address of the network. They also define the DNS and IP range information — a pool of IP addresses used to assign IP’s to associate machines — and additional details, depending on the type of profile created. The network profile also determines the type of network — External, NAT, Routed — that is being configured (based on desired use cases)…
- External Network Profile – Applied to pre-created (existing) external networks collected by endpoint inventory. These profiles are also used as the external path (uplink) for NAT and Routed networks as well as the DLR.
- NAT Network Profile – Enables the use of On-Demand NAT Networks and supports 1:1 or 1:Many network topologies. When a machine is assigned a 1:1 NAT profile, it is assigned an internal IP address from the profile’s IP range and also an external IP address from the associated External Profiles (the external profile is a required configuration element of the NAT profile). With 1:Many NAT profiles, the machine is assigned a internal IP address from the profile’s IP range while ALL machines using that profiles share a single external IP address. During provisioning time, NSX automatically creates the needed SNAT and DNAT policies to support the configuration.
- Routed Network Profile – Enables the use of On-Demand Routed Networks. Routed network profiles define the IP subnets and a series of subnetted network segments that will be allocated to deployed machines. Routing between these segments upstream networks is performed by the DLR.
Once configured, the profiles are applied to Network Paths within vRA’s Reservations. When adding networks to a converged blueprint, it is the network profile that is wired to each machine’s vnic, not the network path itself:
There are many other uses and considerations when using Network Profiles — those details will be covered in a separate post focussing on this topic.
Converged Blueprint Deployment Models
vRA’s Converged Blueprint Designer (CBP) provides several options for designing and authoring an application with networking and security. For those just getting their feet wet, Existing services can be quickly dragged to the canvas for consumption. Boring. On the other end of the automation, on-demand services can be leveraged. Awesome. And of course there’s the balance of existing and on-demand services. The use and benefits for each of these have been covered already. Below are a number of popular deployment models in CBP.
Existing Network and Security Services
Networking: Pre-created logical switches and routers are defined by the network/NSX admins and collected by vRA during endpoint inventory collection. External Network Profiles are created to define the network details for each unique network segment — extAppTier, extWebTier, extDBTier in this example.
Security: Security Groups and Policies are pre-created by the security/NSX admins and collected by vRA during endpoint inventory collection — vraAppTier, vraWebTier, vraDBTier in this example. Machine components are individually wired to each of the services on the canvas.
What Happens:
- At request time, vRA provisions each machine to the appropriate network and automatically adds each to the appropriate [existing] Security Group
- The attached External Network Profiles provide the IP details for each network
- No new services are created by NSX
On-Demand Network and Security
Networking: Logical switches and routers (depending on use case) are created on demand by vRA and NSX at request time. Corresponding Routed or NAT Network Profiles define the network details for each unique network segment. In this case, two on-demand routed networks are used, one for each tier.
An On-Demand Load Balancer — OD-LB-WebTier — is used to load-balance the web tier when more than 1 web tier machine is requested.
Security: An On-Demand Security Group is used for each tier — vraWebTier and vraDBTier. The ODSG requires an existing Security Policy for configuration (security policies do not support on-demand provisioning for good reason). In this case, an existing security policy — https443-http80 (not shown) — is used for the web tier. A separate ODSG and security policy is used for the DB tier.
What Happens:
- NSX creates and configures dedicated interfaces on the upstream DLR and wires each to a new logical switch (one per tier)
- The vnic on each machine is wired to the appropriate network during provisioning
- The attached Routed Network Profiles provide the IP details for each network
- A new Security Group is created for each defined ODSG and bound to the appropriate [existing] Security Policy, provisioned machines are added to the appropriate group
- NSX Deploys a dedicated Edge Services Gateway and configures a load balancing policy for the web tier
- The Load Balancer’s uplink interface is wired to the web tier’s OD Routed Network
App Isolation
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). For example, assume the machine components of a multi-tier blueprint — Web and DB — are wired to the same existing network, each bound to their own unique security groups. Once deployed, the Web and DB tiers will share the same external network and be protected from each other thanks to their security groups and associated security policies. However, with each subsequent deployment, you’ll be adding additional Web and DB components to the same network…and while the SG protects the tiers from each other, there is no guaranteed protection between the Web machines provisioned in deployment 2, 3, 4…100. App Isolation addresses this by dynamically adding the need security later at the component level to automatically block the cross-deployment traffic. Only a component-level security group or policy can override the block.
App Isolation is enabled in Blueprint Properties and configured per-blueprint. It supports a combination of Existing and On-Demand services
What Happens:
- NSX dynamically creates Security Groups and associated Security Policies to block all inbound and outbound network traffic while allowing inter-application traffic to flow.
- A new Security Group is created for each component in the deployment
- A Security Policies applied to the Security Group(s)
- The use of component-level security groups, policies, or tags take precedence and can be configured to allow specific traffic.
Take some time to absorb these concepts and you’ll realize there’s really nothing complex about it. The vRA and NSX Integration Series will dig deeper and walk you through the configuration details of each of these concepts.
Enjoy!
