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:port> 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   ... View more

Brocade vTM, as a software ADC can be deployed on any x86 cloud platform. It's so simple to deploy on top of Linux or Solaris, that I'm sure people have been spinning up vTMs on Googles Compute Engine for a while now. But with the release of vTM 10.3 in December we now have an official Virtual Appliance available. It's probably about time some one published an Auto-Scaling driver too.   Auto-Scaling Primer   Auto-Scaling is a feature in Brocade vTM which allows the Traffic Manager to automatically scale your pool of servers on demand. The Auto-Scaler process constantly monitors the availability and responsiveness of your nodes, and ensures the pool is always “right-sized” for the current demands.   When the Auto-Scaler decides that the pool is not sized correctly for the current load, it will take an action to rectify the situation. If the Auto-Scaler determines that you have more nodes running than are needed, then it will take action to remove one of the nodes. When it determines that the pool has too few nodes to serve the current load, then it will take action to create a node.   The Auto-Scaler makes use of drivers to help it integrate with 3 rd party cloud APIs. The Auto-Scaler makes the decisions, but then uses the driver to make the required changes in the cloud. Typically a driver provides three core functions:   status - reports the current nodes deployed and their state createnode - used by the Auto-Scaler to deploy a new node into the cloud destroynode - used by the Auto-Scaler to remove a node from the cloud   Some cloud drivers provide additional functionality, which can be used by the system administrator or by other vTM sub-systems. However the Auto-Scaler itself only uses the three described above.   For more information on Auto-Scaling, please refer to the Brocade vTM User Guide.     The Google Driver     The Google driver implements the three required Auto-Scaling functions: status, createnode, and destroynode, for integration with Google Compute Engine.   It authenticates with the Google API, either with the a token retrieved from a local metadata server, or by autheticating with it's own OAUTH2 credentials. If you use the OAUTH2 authentication method, then you must run the special authclient function first to establish those credentials.   For a full list of functions and their arguments, execute the driver with no paramaters.   Instructions on using the driver and the driver itself are attached below.   Enjoy, Mark   ... View more

Overview   The libQueue TrafficScript library allows you to create and manage HTTP sessions on the Traffic Manager, and limit the number of sessions which are allowed through to the backend. With this library we can set a max number of serviceable sessions, and then the vTM will ensure that no more than that number of sessions are allowed through to the backend servers.   The library allows you to name multiple queues if you have multiple applications running through the same vTM, and use counters to keep track of the number of sessions, being created, re-used, and destroyed on the system.   Whenever the max number of users is reached the vTM will start delivering holding pages, which can be configured to include the users position in the queue. Ajax or a meta-rfresh can be used to refresh the users position periodically to keep them appraise of their position.   Please read the comments in the libQueue library for more information on its configuration.   Usage   Once the library has been imported, you will need to call the init() function to initialise the defaults for use. You can then if you wish override any of the configuration parameters as required. The do_req() function is used to determine if the user can be sent through to the application or sent to the Waiting Room.    import libQueue as queue; $config=[]; $houseKeeping=[]; $counters=[]; queue.init($config, $houseKeeping, $counters); # ===================================================================== # == Configuration Overrides for this host $config["poolName"] = "MyApplicationPool"; $config["queueName"] = "MyQueue"; $config["waitingRoomTemplatePage"] = "myApplicationWaitingRoom.html"; $config["waitingRoomTooBusyPage"] = "toobusy.html"; # ===================================================================== $pool = queue.do_req($config,$houseKeeping,$counters); if ($pool == $config["poolName"] ) { pool.use("www.demo.local"); } else { pool.use("WaitingRoom"); }   The waitingRoomTemplatePage will be parsed for template variables whenever it is delivered to a user. This allows you to brand the page, and also include information about the users queue position in the response. The current template variables available for the waiting room page are:   QUEUE_ID (Displays the PID of the vtm Child process managing this user) SESSION_ID (Displays the Session ID of the current user) QUEUE_POSITION (The users current position in their queue) All occurences of the above text will be replaced with their values, when the page is sent to the user.   More Information   The vTM software is designed to scale vertically within in a machine, and so it creates a single threaded child process per core. This library tries to scale in the same manor and so each child process creates and manages its own queue.   Each child is responsible for managing its own queue. This includes putting new user sessions into the queue, and running house keeping task on that queue to expire timedout sessions. When a queue is not empty, the child which owns the queue is also responsible for migrating users out of the queue and into the application.   The library needs to be configured with the number of cores available to the vTM, so that each child process can deQueue a proportianate number of users whenever migration occurs.   Debugging There is a debug function in the library, which can be set to any number between 0 and 5. However it is recommended that debugging only be enabled during testing, and set to 0 for production use.   User Counters The User Counters in the configuration can be used to visualise sessions being created, re-used, timed-out, and destroyed, for both the Application Pool and the Queue (Waiting Room). The default counter assignments are:   Session New (a new session has been Created) Session Update (A users session has been extended)  Session Expire (The housekeeping process has removed an expired session) Application Sessions (A session is assigned to the application pool) WaitingRoomSessions (A session which is in the queue) WaitingRoomExpire (A user in the queue has timed out) WaitingRoomMigrated (A session has migrated from the queue to the application) SessionComplete (A user hit an exit point and the session was deleted)    Timeouts There a three configuration parameters for timeouts. InitialTimeout is given to all new sessions and is there to prevent automated clients from using up real sessions. Once a session has been reused, then we switch to the standard timeout, either the sessionTimeout or the WaitingRoomTimeout depending on where the user was assigned.   Application and WaitingRoom sizes The script needs to be given the max number of application sessions allowed in the sessionLimit config value. when this limit is reached users will be sent to the WaitingRoom (queue). There is also a waitingRoomLimit, which when exceeded will cause the user to simply be given WaitingRoomTooBusy page.   ... View more