Because no vCO can be left behind…
In many cases we need more than one vCO to manage different infrastructures with similar means (for example one vCO per datacenter). However this brings additional overhead in using different vCOs and keeping them up to date. The answer to these problems is the newly released vCO Multi-Node plug-in. It covers the following use cases:
- Remote vCO Management – In order to remotely deploy and delete packages or workflows.
- Remote Workflow Execution – To execute workflows on the remote vCOs.
vCO Servers Configurations
Add vCO Server
Before start working with a vCO server you need to add it to the local vCO. This is done using the Add a vCO server workflow. Hit start workflow and you will see the following workflow presentation:
Here you need to add ip/host, port (standard is being selected) and optionally user and poassword (if using the vCO server in shared mode).
The difference between shared and not shared mode is which user credentials are used to connect to the other vCO
- Shared Mode – in this mode all users are using the same credentials to connect to the remote vCO
- Session Per User – in this mode the currently logged user credentials are used to connect to the remote vCO
When add a vCO server the vCO Multi-Node plug-in generates proxy workflows for the entrie set of workflows residing on the remote vCO. These workflows can be found under the folder with name VCO@HOST:PORT Note: Because of workflow generation it can take up to 1 minute to add a vCO server.
Update vCO Server
If there is a need to reconfigure a vCO Server the Update a vCO server workflow can be used. Here is how it looks:
Delete vCO Server
To delete a vCO Server start Delete a vCO server workflow.
Here only server to delete needs to be selected Note: When delete a vCO server the vCO Multi-Node plug-in deletes also the generated remote workflows
Remote vCO Management
vCO has functionality to import/export packages from one vCO server to another. This functionality currently is available through vCO client, but it is limited to single vCO server. There are certain scenarios when it is needed to update multiple vCO servers with the same package. Example of such a scenario is moving from development to production environment. Using functionality available the user will need to repeat package import step for each individual production servers. vCO Multi-Node plug-in provides a set of workflows to automate the process of deploying packages/workflows from one vCO to another. Those workflows can be found in Library/Orchestrator/Remote Management.
Deploy package on remote vCO server
The vCO Multi-Node plug-in provides following workflows for automation of package deployment
- Deploy package from local server – used to deploy package from master vCO server to remote one;
- Deploy package’s from local server – used to deploy multiple packages at once.
What follows is example of package deployment using Deploy package from local server. Parameters that must be provided are:
- Package – package which will be deployed. The package must be available on the master vCO server;
- Remote vCO servers – list of servers where the package will be deployed;
- Override – if the package already exists on the target server and this parameter has been set to “Yes”, the old content of the package will be deleted before to start deploying the package.
Result of deployment can be checked in workflow’s log.
After successful deployment package will appear in remote vCO server inventory tree under System/Packages node.
Delete a package
The easiest way to delete package from remote vCO server is to locate it in the inventory tree and execute workflow Delete a package.
Delete package, installed on multiple remote vCO servers
Workflow Delete a package by name is used to delete package that is installed on more than one remote vCO servers. This workflow expects as parameter the name of the package to be deleted and list of remote vCO servers to be processed.
Manage Remote Workflows
In addition there are two workflows available for managing workflows separately from the package.
- Deploy workflow from local server
- Delete Remote Workflow
Remote Workflow Execution
The challenge in execution of remote workflows is in dealing with their input and output parameters. These are generally speaking of types that the local vCO server does not know of and can not handle. The way in which the vCO Multi-Node plug-in addresses this challenge is to generate locally so called “proxy workflows” for remote workflows. A proxy workflow takes input parameters from the inventory of the vCO Multi-Node plug-in and when executed, converts these to the types required by the remote workflow and invokes the remote workflow.
Proxy Workflow Creation
A proxy for individual remote workflow is created by the workflow Library/Orchestrator/Remote Execution/Create a proxy workflow. When this worfklow is executed it displays the following dialog:
When the workflow is executed, it creates a local proxy workflow with the same name as the selected remote workflow. The proxy is located under a local folder named VCO@ – e.g. VCO@10.23.164.98:8230. The path of the generated proxy relative to this server specific folder is the same as the path of the remote workflow relative to the root of the remote workflow tree.
Creation of Proxies for a Remote Workflow Folder and Server
Generation of proxy workflows for a big number of remote workflows by the procedure described above is doable but tedious. Therefore the vCO Multi-Node plug-in provides means to generate proxies for a whole remote workflow folder and for all workflows on a remote vCO server. Generation of proxies for a remote folder is done by the workflow Create Proxy Worfklows from Folder as seen below
The “Include subfolders” checkbox determines whether the selected folder will be processed recursively (default) or not.
Proxy Workflow Execution
When a proxy workflow is executed, its input parameter objects must be selected from the same server where the correspondent remote workflow resides. For example a virtual machine parameter must be selected from the local representation of the inventory of a vSphere plug-in installed on the said remote vCO server. Type checking of input parameters during selection is somewhat limited by the fact that all objects from the inventories of remote plugins have the same local type. So it is possible for example to select a cluster object instead of a virtual machine object. Types are however checked more rigorously when the proxy workflow is started and if a mismatch is found then the proxy will fail before starting the remote workflow.
Remote and Proxy Workflows Maintenance
If/when remote workflows change, there may be need to bring local proxies up to date or to entirely discard them if/when not needed any more. For the purposes of such maintenance the vCO Multi-Node plug-in provides some utility workflows in the already mentioned folder Library/Orchestrator/Remote Execution/Server Proxies, namely :
- Refresh Proxy Workflows for VCO Server – Ensures that local proxy workflows for the selected server are up to date with the remote workflows that they represent.
- Cleanup Proxy Workflows for VCO Server – Deletes all local proxies for workflows residing on the selected server.
- Delete All Finished Worfklow Runs – Delete all finished workflow tokens for a remote workflow.
Multi Workflow Execution
As part of vCO Multi-Node plug-in there is a possibility to execute a workflow on many vCO servers. Due its complexity this task is separated in two steps
Step 1 – Generate a multi proxy action
In order to execute a workflow on many vCO servers first we need to generate a proxy action which can do this. Select Create a multi-proxy action workflow and run it:
The parameters of this workflow are:
- Action Name – the name of the action to be created NOTE: The action name must contains only alpha-numeric characters whithout separators NOTE: Always a new actions is generated, even if action with the same name already exists
- Action Module – the module where the action should be put
- Is remote workflow? – should the workflow which is source of the proxy action should be retrieved from the local vCO or from remote
- Remote workflow – the workflow for which the proxy will be generated
The action generated accepts the same parameters as the source workflow, but promoted to arrays (multi-selection). The values in this array should go by index. (For example in case of Rename VM – the new name of the first selected VM is the first selected name, etc) The vCO server on which the actual execution happens is deduced by the values of the parameters.
Step 2 – Use the generated action as part of bigger block (workflow)
The action generated will be something like:
This action can be now embedded directly to a local workflow.