Chances are that if you're using vRealize Automation in your organization, you're looking to automate IT tasks as much as possible. Taking advantage of that oh-so-sweet automation on your network will require some sort of SDN solution, I'm talking about NSX of course. So in this post, we'll be exploring what you can and can't do by when you integrate vRealize Automation with NSX, right out of the box.
First, I'll assume you've followed one of the many guides available online to install vCenter and NSX. You should also have an installation of vRealize Automation up and running and integrated with NSX. If you haven't done all that yet, here's is a great step by step guide by theithollow.com that will help you out.
WHAT YOU CAN DO
Now, let's talk functionality. NSX by itself offers a lot of functionality, but unfortunately vRA doesn't allow you to exploit all of that functionality right out of the box. There are some parts of the NSX API that you will need to build custom Orchestrator workflows to use. The actions you get right out of the gate (with no custom Orchestrator workflows) are :
– Logical Switch creation/deletion
– Attaching Logical Switches to existing ESGs or Distributed Logical Routers (DLR)
– Edge Services Gateway creation/deletion
– Applying Security policies & Security tags to new VMs
– Creating a new Security Group/Adding VMs to an existing or new Security Group. These last two are important because they allow you to automate Firewall rules and 3rd party integration services like Guest Introspection service offerings (Antivirus, IDS/IPS) .
– Application Isolation. This is a feature that basically closes your deployment in a firewall "bubble", allows nothing in or out. This is mostly useful for Test environments.
Most of this functionality is exposed to the vRA administrator by using the concept of Network Profiles. There are 3 different types of Network Profiles in vRA 7: Routed, NAT and External. You can learn more about these by taking a look at VMware's official documentation or other blogs like this one…. Suffice to say that each of these Network Profiles allows you to fulfill different needs for different use cases. This abstraction of network services provisioning via Network Profiles is a gift and a curse. It allows you to provision an entire network stack for a 3 tier application very simply. But on the other hand, trying to automate the creation of a more complex network topologies can require A LOT of customization via Orchestrator workflows. In other words, vRA Network Profiles make things very easy to automate if you have a simple network setup, but try building something a little more complex and it will become a true test of your will!
WHAT YOU CAN'T DO
Because knowing a product's limitations is as important as knowing about its features, now here's a list of NSX actions you CANNOT do through the creation of vRealize Automation blueprints (for the moment!) :
– Create Distributed Logical Routers. You can only attach Logical Switches to an pre-existing DLR that is included in the vRA Reservation. This one's a bummer, I hope they fix it soon.
– Naming NSX objects that are created by vRA. Edges can be named to a certain extent using blueprint names, but not customized on the fly for each deployment.
– Pretty much any NSX Edge Gateway advanced configuration, such as :
– VPN configurations
– Advanced Load Balancer settings. SSL certificate configuration, SSL offloading, etc.
– Dynamic Routing protocol configuration
– L2 bridging
– etc.
Keep in mind, you'll still have access to all this functionality via the NSX / vSphere Web client, but it simply isn't automatable out of the box with vRA. Where the integration is really lacking is in Day 2 operations. For example, if you have a multi-machine deployment that uses a load balancer, there's no way to add/remove a specific Web server from the Load Balancer pool on demand, you'll need to create a workflow for that.
THE DREAM
In my opinion, the ideal way to provision NSX components in vRealize Automation blueprints would be for the Converged Blueprint Designer to allow you to drag and drop actual NSX components without abstracting them with different types of Network Profiles. For example, you could simply drag and drop a new Logical Switch, Edge Gateway, Distributed Router, and attach VMs to the Logical Switches and use Network Profiles to assign IPs to the VM from a pool. A combination of this and the current implementation of Network Profiles would be a ideal, in my opinion.
THE BOTTOM LINE
Overall, the integration between vRealize Automation and NSX is very interesting and nearly any organization can benefit from using both these products. The integration itself could definitely be better and I'm sure it will improve with time. But in the mean time, you'll have to roll up your sleeves and put your creativity to work to create some custom Orchestrator workflow to do even some basic tasks.
So if I had to be totally honest, this image is much more realistic than the one at the top of this post…
Some really interesting information, well written and broadlly speaking user genial.
Very useful stuff, thank you! I have a use case that’s really making me sweat :). A 2-tier multi-machine blueprint that’s deploying VMs in two different sites (vCenter Endpoints) and uses on-demand LBs to balance one set of VMs. At the moment it’s fails with a “The following component requests failed: NSX Edge. Infrastructure service provider error: A server error was encountered. Error requesting machine. Machine Edge-XXX: No reservation available that has all specified network profiles: NetworkProfile1 and and NetworkProfile2 assigned to any network paths.” VMs and LB in one site are using the NetworkProfile1, while VMs and LB in the 2nd site are using the NetworkProfile2. I’m definitely missing something on the way NSX is probably configured in regards to this blueprint. Any thoughts?
Hi defmania, I think the issue would be that you can only set a single Reservation Policy (therefore a single Reservation) at the blueprint level for NSX Edges. That means either you have to have a single Reservation that has both Network Profiles or just keep the deployment of each portion in its own blueprint. If you really want to take it a step further afterwards, you could create an XaaS blueprint that calls those 2 blueprints via the API.