This article describes the installation, configuration, and usage of the vADC Package for VMWare vRealize Orchestrator (vRO).
The package contains a number of workflows which can communicate with both the Brocade VTM, and the Brocade Services Director via REST APIs. The workflows support licensing and registration of newly deployed vTMs, and also pushing configuration to the vTMs themselves (either directly or via the Services Director).
To install the vADC package, you will need to start the vRO client application and then switch to the “Administer” or “Design” view.
When in the correct view, navigate to the “Package” tab and click the import button.
Select the “com.brocade.vadc.package” file and click open.
vRO packages are signed by the certificate of the server on which they were created, so it’s likely that you will see a prompt to import/accept the certificate of my lab server “vro.vmware.lan”. Click “import” to continue.
You will then see a list of the workflows which are included in the package. All of the workflows should be selected by default. Once you have confirmed that to be the case, simply click on the “import selected elements” button.
When the import completes, you should have com.brocade.vadc listed in you packages list. Navigate to the “Design” view, and you should now see a “Brocade.vADC” folder in the workflows listing.
If you are using Brocade Services Director to license your vTMs, then the first thing you will want to do is register the Services Director REST API end-point. If however you don’t use Services Director, then you will want to start registering vTM REST end-points directly.
The next steps are slightly different in each scenario:
Execute the “vRO: Register Services Director” workflow first. Then run the “vRO: Register vTM via Services Director” for each of your licensed vTMs. The vTM must be known to Services Director before you attempt to register it with vRO.
If you have a vTM which is not yet licensed through Services Director, then you will have to do one of the following:
If you don’t use Services Director, then the REST API end-points must be set up directly with each vTM using the “vRO Register vTM” workflow.
The registration workflows are quite simple. They install the certificate from the Services Director or the vTM into vROs key store, and then they register the API end-point as a REST Host. In this example, we’re registering the Services Director, but the vTM direct screen is very similar.
Fill out the form by providing a friendly name for the Services Director, the REST end-point < hostnameort> of the API, along with the username and password for accessing it.
When the workflow completes, the newly registered host should appear in the HTTP-REST section of your inventory.
You can now use this REST Host in the “SD:*” workflows.
Once you have your Services Director registered as a HTTP-REST object in your inventory, you can use it to license vTM instances.
Start up the “SD: License vTM” workflow and select your Services Director as the REST Host. The rest of the form can be completed by providing a “tag” or hostname for the vTM, with Feature Pack, Bandwidth Limit, and Owner.
If you are registering a “legacy” vTM (older than 10.1), then you will need to supply the vTM instances hostname in the address box. If it’s a “universal” licensed vTM (10.1 and newer), then it can be an IP address.
On the next screen you will need to flag the vTM if it is a “legacy” version.
Obviously, if you intend to use the “vTM: *” configuration workflows with this vTM, then the REST API should be enabled.
Now that you have a Services Director registered with vRO, and the vTM is licensed through the Services Director. We can register the vTM end-point with vRO.
Kick of the “vRO: Register vTM via Services Director” workflow. There are only two parameters. The first if the Services Director (from your inventory), and the second needs to be the instanceID or tag that you gave the vTM when it was licensed.
Once the vTM is registered it will appear in your REST-HTTP inventory also.
In order to configure a vTM, it needs to be registered as a REST Host with vRO. This can be a direct registration, where vRO communicates with the vTM API directly, or an indirect one, where the communication goes via the Services Director.
The vADC package includes a number of workflows. See the workflows section for a complete list. We’re not going to go into great detail on each one, but rather go through a couple of examples.
This is an example of adding a pool to a vTM using the “vTM: Add Pool” workflow.
This workflow needs a Rest Host as its first parameter. This should be the vTM which you have previously registered with vRO. You also need to supply:
Click “Submit” to start the workflow. If all is well, it should complete successfully, and you should have a new pool on your vTM.
Here ends example one.
vRO workflows can be combined into larger workflow chains, and an example of such is provided with the package. Take a look at the “Service: Deploy HTTP Service”, and “Service: Remove HTTP Service” to see how these work. Below is the scema for the deploy workflow:
This workflow executes a chain of actions to create the following:
If any of the steps in the chain fail, then the exception is caught and a roll back begins.
The workflow when used interactively paginates its inputs. The first section takes an “application ID” which is then used as a prefix for all related resources. A Rest Host (your vTM) obviously, a Traffic IP Group and service port on which to listen.
The second page is dedicated to SSL. If SSL Offload is enabled, then you must also provide a private key and certificate in PEM format.
The final page takes configuration for the pool. This include the nodes, persistence method if required, and options for SSL Encryption. You must also supply a Host Header, and path for use in the services HTTP Health Monitor.
When executed successfully, this workflow will create all the objects necessary to deliver the service through vTM.
Here ends example two.
The work flows included can be split into several functional groups: vRO Registration, vTM Licensing, vTM Configuration, and Service Examples.
The following workflows are used to register vTM and Service Director REST API end-points with vRO. The end-points are then used in SD Licensing, and vTM Configuration workflows.
Register a REST API end-point for a Services Director. This can then be used in the vTM Licensing workflows below.
Register the REST API end-point of a vTM directly. You should use this if you do not have a Brocade Services Director or if you want to call the vTMs API directly.
Register a REST API end-point of a vTM, which is licensed and available via the Brocade Services Director.
The following workflows are used to assign and remove vTM licenses with the Brocade Services Director. vTMs which are configured to self-register on deployment (vTM 10.4 and above on supported platforms) can be approved/licensed with the “Register vTM” workflow. Other vTMs which have been deployed without self-registration should be licensed using the “License vTM” workflow.
License a vTM with the Services Director.
Approve a self-registered vTM (10.4 and above) with the Service Director .
Mark a vTM as “deleted” in the Services Director inventory.
The workflows listed below all perform add/delete/modify operations on a vTMs configuration. Each workflow requires a “Rest Host” resource, which is a vTM registered by either of the vRO vTM registration workflows above.
Workflows which add resources:
All of the “add” workflows above have a corresponding “delete” workflow:
The Add and Delete workflows above don’t output anything on success, but will raise an Exception if they encounter a problem or an error. The following “listing” workflows all return an array of the elements which are being listed. For example the “vTM: List Pools” workflow will return a list of pools in an array/string.
There are also some “Get” workflows which retrieve the state of Nodes in a pool, and also the rules applied to a Virtual Server:
This returns a JSON string of the nodes_table from the API, and also three Array/String lists of the Active, Disabled, and Draining nodes.
This returns three Array/String lists of the rules applied to a Virtual Server: Request rules, Response rules, and Completion Rules.
Finally, there are some rules which modify the state of existing configuration objects:
The “Sd: License vTM” rule applies a license to the vTM as part of the instance creation process. The license name is taken from the “licence” attribute for 10.1 and newer vTMs, and from the “fla” attribute for legacy vTMs.
The defaults for these keys are: "universal_v3" and "legacy_9.3"
If you are using Services Director 2.5 or newer, then you should change the license key to use universal_v4.
Also if your legacy FLA is named differently, then you will want to update this to match.
The API Version used by default when registering REST Hosts, is set for compatibility with Brocade Services Director 2.4 and newer, and vTM 9.9 and newer. To that end, the “vRO: Register Services Director” API version is set at 2.2, and the “vRO: Register vTM” workflows are set to version 3.3