vRA: Developing a NSX-T Blueprint – Part2

In the previous post, I discussed how to setup a development environment, configuration settings made to the virtual machines and converting virtual machines to templates. This post assumes vRA is operational as I’ll be discussing the following topics as it relates to creating/publishing the NSX-T Blueprint that will be used to deploy PKS:

Network Profiles & Reservation

Software Component

Designing a blueprint

vRO PowerShell Host / Event Subscription

Publishing a blueprint

Results

Network Profiles & Reservation

Network profiles contain pre-defined IP information like gateway, subnet, DNS, and IP address ranges. When a virtual machine is provisioned vRA will assign an IP address based on the information in the network profile. There are three types of Network Profiles as depicted in Figure1. I have opted for NAT network profile (One-to-Many) in order to support multiple deployments. In Figure2 are the network profiles I created for the blueprint. Next, we have to tie the external network profile with our existing port group as shown in Figure3.

Figure1 – vRA Network Profiles

 

Figure2 – Network Profiles
Figure3 – Apply Network Profile to Network Adapter

Go to the Top

Software Component

Custom specification will destroy any user profile (tsc\administrator) custom configurations we make like MTputty, WinSCP, Chrome/Firefox bookmarks, desktop image, etc. So in order to access the ControlCenter, we need a way to assign the IP address of the external interface.

During a Livefire training event for Hybrid Cloud in Boston a couple weeks ago I struck up a conversation with classmate Chris Smith who focuses on the Cloud Automation. I explained the situation above to him and wanted to get his perspective. He mentioned the easiest way is to use Software Components with bindings. After the completing our session for the day I went back to the hotel and began playing with Software Components/bindings and to my surprise, it just worked! So a huge thank you to Chris for sharing the knowledge. Please check out his site here as he has excellent content around vRA.

SetExternalIP

The first software component I created was SetExternalIP and created a property called “cc_ip”. We will use this property later when we configure binding. Then proceeded to Actions where I created a basic script that sets the IP address of the External interface. I take the IP address based on the cc_ip property and assign it to [string]$IP. Line 1 of the code below ensure the variable is a string then passes it to the -IPAddress property of  New-NetIPAddress cmdlet. The -InterfaceAlias property references the network adapter “External” that was changed in the previous post.

Figure4 – SetExternalIP Software Component: Properties

Figure5 – SetExternalIP Software Component: Action

SetStaticRouteThe SetStaticRoute software component is simpler only having an action that references the External interface again. I increased the metric to ensure traffic goes through the internal interface. During the Blueprint Design phase, we will attach both software components to the nsxt-controlcenter machine.

Figure6 – SetStaticRoute Software Component: Action

Go to the Top

Blueprint Design

With the networking and software component portion complete we can now start working on the blueprint design. To ensure our vSphere templates are imported into vRA lets perform an inventory sync as shown in Figure7. Now click on “Design” tab > Blueprints > New give the blueprint a name shown in Figure8. Select the transport zone and reservation policy Figure9.

Figure7 – Sync Inventory
Figure8 – New Blueprint
Figure9 – Select Transport Zone and Reserveration

We’ll start with a blank canvas shown in figure10.

Figure10 – Blank canvas

The first thing to do is drag some network constructs to the canvas Figure11:

  • 1 x Existing Network
  • 2 x On-Demand NAT Network
Figure11 – Add Networks

Next up is the virtual machines we will focus on the vPodRouter and the ControlCenter VMs (Figure12 – Figure16) as all other VMs will be attached to the vSphereTransitNAT network. We drag over a vSphere (vCenter) Machine then configure the machine to use the vPodRouter template we created in the previous post and attach it to the required networks. We have two virtual machines attached to their corresponding networks (Figure17). Now to attach the software components we created earlier to nsxt-controlcenter machine (Figure18) and then bind property “cc_ip” to “_resource~nsxt-controlcenter~ip_address” (Figure19). This will pass the IP address from the nsxt-controlcenter

vPodRouter

Figure12 – Create a vSphere (vCenter) Machine
Figure13 – Assign vSphere template nsxt-vPodRouter
Figure14 – Assign Networks to vPodRouter

ControlCenter

Figure15 – Assign vSphere template nsxt-ControlCenter
Figure 16 – Assign Networks to ControlCenter
Figure17 – Design canvas with 3 networks and 2 virtual machines
Figure18 – Attach SetExternalIP and SetStaticRoute to nsxt-controlcenter machine
Figure19 – Software Component Binding

Rinse and Repeat

Simply repeat the process for the remaining virtual machines that make up the NSX-T blueprint. Your design canvas should look similar to Figure20 once finished.

Figure20 – Design Canvas with all required networks, virtual machines and software components

Below is a breakdown of the dependency order for the virtual machines inside the blueprint:

  1. nsxt-vPodRouter
  2. nsxt-dc
    1. nsxt-esxi-01
    2. nsxt-esxi-02
    3. nsxt-esxi-03
    4. nsxt-esxi-04
    5. nsxt-esxi-05
    6. nsxt-esxi-06
  3. nsxt-vcsa-01
  4. nsxt
    1. nsxt-ctrl-01
    2. nsxt-ctrl-02
    3. nsxt-ctrl-03
      1. nsxt-edge-01
      2. nsxt-edge-02
  5. nsxt-controlcenter
    1. SetExternalIP
    2. SetStaticRoute

Go to the Top

vRO PowerShell Host / Event Subscription

Since this is a nested environment we will need to enable the following security policies; Promiscuous Mode, Forged Transits, and MAC Address Changes in order for the virtual machines to communicate. To accomplish we will leverage Event Subscription to initiate a PowerCLI script via a Powershell host in VRO due to my lack of javascript experience but is something I’m working on it  ;).

  1. Add PowerShell Host
  2. Invoke an External Script
    In our case, it’s just a simple .ps1 file with Write-Output “Testing ;)” to validate things work. You can see in the screenshot above Invoke an external script ran successfully.
    Important: In order to get the scripts to execute successfully I had to update the PowerShell plugin from 1.0.11 to 1.0.13 after doing so the scripts ran without issue.

    Figure22 – Simple script to test functionality
  3. Create a vRO workflow that will process the vRA payload looking for the two on-demand networks by finding the port group ids then passing that information to the PowerCLI script that will enable Promiscuous Mode, Forged Transits, and MAC Address Change.
    Figure23 – SetSecurityPolicyOnPortGroups Workflow – Attributes
    Figure24 – SetSecurityPolicyOnPortGroups Workflow – Script to extract port group ids created by vRA
    Figure25 – SetSecurityPolicyOnPortGroups Workflow – Visual Bindings from script to external script

    Figure26 – SetSecurityPolicyOnPortGroups Workflow – PowerCLI script used to change security policy settings on discovered port groups.
  4. Create an Event Subscription making sure to define conditions, select workflow (SetSecurityPolicyOnPortGroups) and enable blocking.
    Figure27 – Event Subscription conditions. Only need to affect the vPodRouter logical switches (port groups) as all virtual traffic flows on these two networks.
    Figure28 – Select vRO workflows to execute

    Figure29 – Set blocking and define priority
  5. Confirm workflow executed successfully and settings have been changed.
    Figure30 – vRO workflow success
    Figure31 – Validate via PowerCLI

    Go to the Top

Publishing Time

Our blueprint is ready to be published simply click Finish and click Publish (Figure21).

In order to be selectable from the catalog, we need to associate the blueprint with a service assuming Service and Entitlements have already been set up. Navigate to Administration > Catalog Items > Select NSX-T Environment > Configure > Service. In my case, the service is called “VMware [Nested]”.

Note: You can also add an icon here for your blueprint. 😉

If we go to our catalog > VMware [Nested]  we should see our new shiny blueprint (Figure22). In our environment, this blueprint takes an hour to deploy (Figure23).

FYI the Blueprint name is “[NAT] NSX-T Environment” is the original blueprint. The “NSX-T Environment” blueprint was created for this post as you can see it’s a popular one (Figure24). 😉

To access the environment I simply get the IP address for the nsxt-controlcenter from the Items tab (Figure25).

Figure32 – NSX-T Environment blueprint published
Figure33 – Published NSX-T Blueprint
Figure34 – Deployment Time
Figure35 – Popular Blueprint
Figure36 – Get IP Address

Go to the Top

Results

Below are screenshots of various components vSphere, NSX-T, and PKS (Figure37 -Figure41). This has been an awesome learning experience I hope you enjoyed the two posts series on developing an NSX-T blueprint in vRealize Automation.

If your interested in seeing a video demonstration of the vRA/NSX-T environment just leave a comment below and I’d be happy to put something together.

Figure37 – ControlCenter Desktop
Figure38 – NSX-T Dashboard
Figure39 – NSX-T Routers
Figure40 – NSX-T Switches
Figure41 – vCenter and PKS components deployed with a functional application

Go to the Top

Leave a reply:

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Site Footer

Sliding Sidebar

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.