Its time to think about deploying our networks through vRA. Deploying servers are cool, but deploying three tiered applications in different networks is cooler. So lets add VMware NSX to our cloud portal and get cracking.
The first step is to have NSX up and running in your vSphere environment. Once this simple task is complete, a Distributed Logical Router should be deployed with an Uplink interface configured. The diagram below explains what needs to be setup in vSphere prior to doing any configurations in vRealize Automation. A Distributed Logical Router with a single uplink to an Edge Services Gateway should be configured first, then any new networks will be built through the vRealize Automation integration. While the section of the diagram that is manual, will remain roughly the same throughout, the section handled by vRealize Automation will change often, based on the workloads that are deployed. Note: be sure to setup some routing between your Provider Edge and the DLR so that you can reach the new networks that vRA creates.
Below, you can also see my NSX DLR prior to any vRealize Automation configurations being done.
Now, make sure that your vRealize Orchestrator endpoint is setup correctly and configured. Before we do anything with NSX we need to make sure that the NSX plugin is installed on your vRO endpoint. NSX will utilize this plugin to setup new networks, switches etc. Be sure to do this before continuing.
The first configuration that needs to happen in vRealize Automation is to re-configure your vCenter endpoint to add your NSX connection. Find the vCenter endpoint and add a URL and set of credentials that connect to the NSX manager.
Now we need to setup some network profiles. For the purposes of this demonstration, I’ve setup four network profiles. My Transit network profile which is external and three routed network profiles. The transit network profile will be used in the reservations to show which uplink is used to get to the physical network. In this case it goes through our DLR to our Edge Services Gateway.
The transit network setup looks something like the example below where my gateway is the next hop route to our Edge Services Gateway.
In the IP Ranges tab, I’ve added some IP Addresses that are available on my transit network
Now if we look at the Routed Network Profiles, here we’re added some networking information that probably doesn’t even exist yet in your networks. These networks will be automatically created by vRA by leveraging NSX. There are a couple of important things to review here, The first is the external network profile. This profile should be the external Transit profile that we created just a moment ago. This tells vRA which uplink will be used as a gateway network to the rest of the environment. The next thing is to determine the subnet mask for the whole profile, and then a range subnet mask which is a segment of that range.
Once you’ve setup the details, click on the IP Ranges tab where you should be able to click “Generate Ranges.” This will create each of the subnets that can be used by vRA for your segmented applications.
Now that we’ve setup the network profiles, we can create or modify our vRA reservation. The first step here is to map the external network profile we created earlier, to the port group that it belongs with. Next, under the advanced settings section, select the transport zone that was created in NSX. Below this you can add security groups to the reservation automatically if you would like. Lastly, under routed gateways, select the Distributed Logical Router that as created and then in the drop downs, select the interface and the network profile that corresponds with your external network.
If your routed gateways don’t show up, make sure you’ve run a discovery on your compute cluster for “Networking and Security”. Also, make sure that you’ve created a Distributed Logical Router and not an Edge.
In this post, we setup our basic configurations in vRealize Automation and connected it to our NSX manager. The reservations and network profiles are now ready for us to build some blueprints with on-demand networks, which we’ll discuss in the next post.