VCAP-CMA Deploy – Objective 1.5

Disclaimer: These are my notes from studying for the 3V0-31.18 exam. If something doesn’t make sense, please feel free to reach out.

The main goal for the whole of section 1 is to understand blueprint creation and modification in depth.

Objective 1.5 – Consume NSX components of a complex blueprint

References

• Configuring vRealize Automation

For this objective, have a think about everything you may need to put in place to consume an NSX element within a blueprint.

First lets start with a list of NSX components that can add to a blueprint:

• Existing Security Group
• Existing Security Tag
• On-Demand Load Balancer
• On-Demand NAT Network
• On-Demand Routed Network
• On-Demand Security Group

Existing Security Groups/Tags

Fairly simplistic this one – drag the appropriate component onto the canvas, then select it. Click on the ellipsis button to select the pre-existing component (as the name suggests this should already be created within NSX).

Once the security group/tag is defined, select the VM object you want to associate with the group/tag. Go to the security tab and put a tick in the approriate box(es).

Once you’ve done this, you’ll see the security group/tag link up on the main canvas.

On-Demand Security Group

This one involves a bit more work, but it will create/delete security groups as part of the deployment/destruction of a blueprint.

First you’ll need to create a Security Policy within NSX Service Composer. This is the policy that will apply to the on-demand group, otherwise NSX doesn’t know what you want from the security group!

I kept mine simple, just clicked through the wizard without adding anything in. You can quite easily create rules here, but I chose to leave it as this is just for a lab environment.

Once the policy is created, go back to your blueprint and drag the On-Demand Security Group component on to the canvas. From here give the component a meaningful name, and click on the add button underneath security policies. Then select the policy you created earlier.

Once you’ve got the right security group on the canvas, you can link it under the security tab just like earlier.

On-Demand Routed Network

This is an on-demand network created at the provisioning stage connected to an existing Logical NSX Router. I’m making an assumption that in the exam you’ll already have the appropriate parts of NSX configured for you. After all, they’re not testing on that product. Briefly though, you’ll need:

• Edge Services Gateway
• Distributed Logical Router
• Dynamic Routing
• Subnet to allocate within vRA

Within vRA, we need things in place before we can consume a routed network on a blueprint:

• External network profile
• Routed network profile
• Access to these profiles through the appropriate reservation

On the network profiles page, click New, External. Once you’ve entered a name, you’re done for the routed network requirements. The remaining items are if you want to use the network profile for other things as well. If you choose to fill in the DNS page, the spawned profiles (routed & NAT) will use these values to complete the same page. However it’s not necessary, your call!

Back on the network profiles page, click New, Routed. Complete the page, entering a name, the external network profile you created earlier and fill in the network details:

• Subnet mask: This is the network prefix for the master block of IPs you’re allocating to this profile.
• Range subnet mask: The network prefix for each network that will get created. Think about how many VMs you might have in a single deployment.
• Base IP: Network address for the master block

The DNS page will either be filled in or you can complete it manually, depending on the settings you chose in the external network profile earlier. On network ranges, if you’ve truly allocated the whole subnet, you can select Generate Ranges. This will populate all the subnets based on the Base IP, Subnet mask & Range subnet mask from the General tab. Of course you can also complete this manually.

Now you’ve got the profiles created, you’ll need to link these profiles up in the reservation. The only change you’ll need to make is on the reservation, Network tab. Allocate the appropriate external network to the pre-existing DLR.

This is enough to make the routed network available to the users of that reservation.

Every time you deploy a blueprint that has machines allocated to this profile, it will use a different range. The already deployed DLR will be the gateway, in conjunction with dynamic routing, you’ll be able to route to these VMs.

On-Demand NAT Network

Very similar to the On-Demand Routed Network, key differences are:

• Need to complete all the configuration within the External profile. This is because when you provision a NAT network, vRA will request a new ESG from NSX. The IP settings within this profile are what the ESG will use to talk to the outside world.
• Still need a subnet to allocate, but this doesn’t need to be routable as it will be NAT’d behind the NSX ESG. In fact, if you deploy multiple times from the same blueprint, you’ll end up with multiple items using the same IP address.

So lets assume you’ve already got an external network profile in place and we’re going to create the NAT network profile. Go to the network profiles page and click New, NAT.

Key points on this main page:

• External network profile: External network profile that will be used to house the NSX ESG.
• NAT Type: 1:1 or 1:Many, very much depends on the use case. In this instance I’ll be using 1:1.
• Subnet/Gateway: Network details for the NAT’d network. The Gateway will be on the ESG.

As before, if it’s configured in the external profile, the DNS tab will already be populated. The network ranges tab is where you add in the ranges that will be allocated to VMs on this network. Multiple deployments can overlap as these aren’t exposed to the rest of the network.

Once the profiles are configured, the external network profile needs to be linked up on the appropriate reservation. It needs to be configured on whichever logical switch is the transit network.

Once this is complete they can be added to the canvas like any other network.

On-Demand Load Balancer

Exactly what it says on the tin, a load balancer that is deployed in NSX, on-demand. This is a configuration item on the ESG that is deployed with the deployment. If you’re not deploying one for anything else, this will deploy one for you.

The initial configuration is pretty straightforward.

• ID: Name of the load balancer on the blueprint
• Member: The object on the blueprint the load balancer is going to forward traffic to
• Member Network: The network card on the object to forward traffic to
• VIP Network: The network that the Virtual IP is going to be on
• IP Address: The static IP that you want to be the VIP. This would make the blueprint single use, so not used often

Further down, create the virtual server. This is where there is more configuration options. Initially you can choose the protocol, port & description. There’s then an option to choose the default settings or to customise. If you select customise it opens up the other tabs on the option box.

There are options for:

• Distribution
  • Algorithm
  • Persistence
• Health Check
  • Health Check URL
  • Interval etc.
• Advanced
  • Connection limits
  • Transparency
  • Acceleration (L4 vs L7)

If you hover over the information symbol for each option it will tell you what each option will give you.

Transport Zone

Key point with NSX, which I frequently forget, is to select the correct transport zone on both the blueprint & the reservation. If these aren’t present, deployment will fail!