vRealize Orchestrator (vCO) Multi-node Plug-in use case: Remote Site Selection and Execution
Sam McGeown
One of the use cases I’ve been working on with a customer is based on the vRO/vCO multi-node plug-in and involves the master vRO/vCO node calling proxy workflows based on a parameter - in this case the target site. As you can see from this very simple diagram, a Cloud Management System (CMS) calls a workflow on the Master node, which then executes a proxy workflow on the correct site. The trick is getting the Master Orchestrator node to pick the right proxy workflow.
In my previous post I covered creating and improving on proxy workflows, if you’ve not read that or are not familiar with the process, I’d recommend doing that before continuing here.
The remote workflow that ends up being called is not actually important here - it’s the ability to execute a workflow on a remote site based on a user’s choice in the CMS. I’m going to use a workflow I’ve written (“vCenter:Add-PortGroup”) to add a dvPortGroup to a dvSwitch as an example, because it’s easy to replicate and is fairly generic.
First, I generate the standard, out-of-the-box proxy workflow for the test workflow on SiteA, using the “Create a proxy workflow” workflow from the Master node.
Next, I edited the workflow along the lines of my example in that previous post.
I removed the “remoteVCOServer” attribute, as it’s no longer required. I then added an attribute called “SiteAWorkflow” which holds a VCO:RemoteWorkflow object, and set it’s value to be the Workflow on the Slave vRO/vCO server in Site A. I also added a SiteBWorkflow, and you would continue for each of the remote sites.
Next I added a string Input parameter called “Site”. Notice there are 3 other parameters from my workflow, dvPortGroupName, dvPortGroupVLANID and dvSwitchName - these are imported from the remote workflow when the proxy workflow is initially created.
As the list of sites is a set of known values, I also went to the Presentation tab and entered some predefined answers for the input parameter:
Next, I went to the Schema tab and edited the first “Scripting” element of the workflow. I added the an IN parameter for the Site parameter, and the three RemoteWorkflow attributes.
On the Scripting tab I used very similar code to before, but added a switch statement to select the correct workflow based on the “Site” input parameter, or throw an exception if the Site wasn’t known. The correct site RemoteWorkflow object is assigned to a new variable “remoteWorkflow” and the workflow is executed as before:
When I test the workflow I can now select which site I wish to execute the workflow on, and the corresponding Slave Orchestrator node actually executes it for me.
The workflow has returned an object of type VC:DistributedVirtualPortGroup as expected:
The dvPortGroup has been created, as expected:
And the remote Orchestrator node has a new successful execution:
While this is a very simple way of doing such a site selection, it does have problems - for example, it’s not very manageable in case of dozens of sites. There is potential to develop this using a CMDB that holds “Site” data and retrieve the ID of the remote vRO server and remote workflow from there, allowing a much more flexible and manageable solution (you could even write a workflow to grab those IDs and add them to the CMDB automatically whenever a new Site is commissioned).
I hope that this gives you some ideas as to what you could use the multi-node plugin for - and if you’ve got a good use case for it I’d love to hear from you via my Twitter @sammcgeown