The vADC Package
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).
Installing the Package
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.
Registering your REST Hosts
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:
With Brocade Services Director
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:
- Use the “SD: License vTM” or “SD: Register vTM” workflows to license the vTM with Services Director, and then run the “vRO: Register vTM via Services Director” to register the end-point for the vTM.
- If the vTM is not to be licensed with Services Director, then you can use the “vTO Register vTM” workflow to register it’s API end-point directly.
Without Brocade Services Director
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.
Service Director Registration Walkthrough
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 < hostname
ort> 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.
Licensing a vTM using the SD: License vTM workflow
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.
vTM Registration Walkthrough
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.
Configuring the vTM
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.
vTM Configuration Example: Adding a Pool
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:
- A name
- A list of nodes
- The name of an existing persistence class (if needed)
- The Load Balancing Algorithm
- Whether to use Passive Monitoring
- An Array of Health monitors
- Whether to do SSL Encryption with the nodes
- Should we do strict SSL Checking on the nodes certificate
- There’s also a verbose flag
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.
vTM Configuration Example: Service Deploy
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:
- Adds a HTTP Health Monitor
- Adds SSL Certificates (if SSL Ofload is required)
- Adds a Session Persistence Class (if Persistence is required)
- Adds a Pool
- Adds a Traffic IP Group
- Adds a Virtual Server
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 Workflows
The work flows included can be split into several functional groups: vRO Registration, vTM Licensing, vTM Configuration, and Service Examples.
vRO Registration
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.
vRO: Register Services Director
Register a REST API end-point for a Services Director. This can then be used in the vTM Licensing workflows below.
vRO: Register vTM
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.
vRO: Register vTM via Services Director
Register a REST API end-point of a vTM, which is licensed and available via the Brocade Services Director.
vTM Licensing
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.
SD: License vTM
License a vTM with the Services Director.
SD: Register vTM
Approve a self-registered vTM (10.4 and above) with the Service Director .
SD: Remove vTM
Mark a vTM as “deleted” in the Services Director inventory.
vTM Configuration
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:
- vTM: Add HTTP Monitor – Add a HTTP Monitor on the vTM.
- vTM: Add Pool – Add a Server Pool on the vTM.
- vTM: Add Rule – Add a TrafficScript Rule on the vTM.
- vTM: Add Server Certificate – Add a SSL Server Certificate key pair on the vTM.
- vTM: Add Session Persistence – Add a Session Persistence class on the vTM.
- vTM: Add Traffic IP Group – Add a Traffic IP Group on the vTM.
- vTM: Add VServer – Add a Virtual Server on the vTM
All of the “add” workflows above have a corresponding “delete” workflow:
- vTM: Del HTTP Monitor
- vTM: Del Pool
- vTM: Del Rule
- vTM: Del Server Certificate
- vTM: Del Session Persistence
- vTM: Del Traffic IP Group
- vTM: Del VServer
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.
- vTM: List Health Monitors
- vTM: List Pools
- vTM: List Rules
- vTM: List Server Certificates
- vTM: List Session Persistence
- vTM: List Traffic IP Groups
- vTM: List VServers
There are also some “Get” workflows which retrieve the state of Nodes in a pool, and also the rules applied to a Virtual Server:
vTM: Get Pool Nodes
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.
vTM: Get VServer Rules
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:
- vTM: Mod Pool Nodes – Set the Nodes in a Pool, both active and draining
- vTM: Mod Pool Draining Nodes – Drains or undrains the given nodes.
- vTM: Mod VServer Rules – Set the list of request, response and completion rule
- vTM: Mod VServer Status – Mark a VServer as enabled or disabled.
Advanced Configuration Options
Service Director License Selection
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.
REST API Versions
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
