1. The Issue
When using perpetual licensing on a Traffic Manager, it is restricted to a throughput licensing limitation as per the license. If this limitation is reached, traffic will be queued and in extreme situations, if the throughput reaches much higher than expected levels, some traffic could be dropped because of the limitation.
2. The Solution
Automatically increase the allocated bandwidth for the Traffic Manager!!
3. A Brief Overview of the Solution
An SSC holds the licensed bandwidth configuration for the Traffic Manager instance.
The Traffic Manager is configured to execute a script on an event being raised, the bwlimited event.
The script makes REST calls to the SSC in order to obtain and then increment if necessary, the Traffic Manager's bandwidth allocation.
I have written the script used here, to only increment if the resulting bandwidth allocation is 5Mbps or under, but this restriction could be removed if it's not required. The idea behind this was to allow the Traffic Manager to increment it's allocation, but to only let it have a certain maximum amount of bandwidth from the SSC bandwidth "bucket".
4. The Solution in a Little More Detail
4.1. Move to an SSC Licensing Model
If you're currently running Traffic Managers with perpetual licenses, then you'll need to move from the perpetual licensing model to the SSC licensing model. This effectively allows you to allocate bandwidth and features across multiple Traffic Managers within your estate. The SSC has a "bucket" of bandwidth along with configured feature sets which can be allocated and distributed across the estate as required, allowing for right-sizing of instances, features and also allowing multi-tenant access to various instances as required throughout the organisation.
Instance Hosts and Instance resources are configured on the SSC, after which a Flexible License is uploaded on each of the Traffic Manager instances which you wish to be licensed by the SSC, and those instances "call home" to the SSC regularly in order to assess their licensing state and to obtain their feature set.
For more information on SSC, visit the Riverbed website pages covering this product, here - SteelCentral Services Controller for SteelApp Software.
There's also a Brochure attached to this article which covers the basics of the SSC.
4.2. Traffic Manager Configuration and a Bit of Bash Scripting!
The SSC has a REST API that can be accessed from external platforms able to send and receive REST calls. This includes the Traffic Manager itself.
To carry out the automated bandwidth allocation increase on the Traffic Manager, we'll need to carry out the following;
- a. Create a script which can be executed on the Traffic Manager, which will issue REST calls in order to change the SSC configuration for the instance in the event of a bandwidth limitation event firing.
- b. Upload the script to be used, on to the Traffic Manager.
- c. Create a new event and action on the Traffic Manager which will be initiated when the bandwidth limitation is hit, calling the script mentioned in point a above.
4.2.a. The Script to increment the Traffic Manager Bandwidth Allocation
This script, called and attached, is shown below.
Script Function:
- Obtain the Traffic Manager instance configuration from the SSC.
- Extract the current bandwidth allocation for the Traffic Manager instance from the information obtained.
- If the current bandwidth is less then 5Mbps, then increment the allocation by 1Mbps and issue the REST call to the SSC to make the changes to the instance configuration as required. If the bandwidth is currently 5Mbps, then do nothing, as we've hit the limit for this particular Traffic Manager instance.
#!/bin/bash
#
# Bandwidth_Increment
# -------------------
# Called on event: bwlimited
#
# Request the current instance information
requested_instance_info=$(curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" \
-X GET -u admin
assword https://ssc.example.com:8000/api/tmcm/1.1/instance/demo-1.example.com-00002)
# Extract the current bandwidth figure for the instance
current_instance_bandwidth=$(echo $requested_instance_info | sed -e 's/.*"bandwidth": \(\S*\).*/\1/g' | tr -d \,)
# Add 1 to the original bandwidth figure, imposing a 5Mbps limitation on this instance bandwidth entry
if [ $current_instance_bandwidth -lt 5 ]
then
new_instance_bandwidth=$(expr $current_instance_bandwidth + 1)
# Set the instance bandwidth figure to the new bandwidth figure (original + 1)
curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u adminuser:adminpassword -d \
'{"bandwidth":'"${new_instance_bandwidth}"'}' \
https://ssc.example.com:8000/api/tmcm/1.1/instance/demo-1.example.com-00002
fi
There are some obvious parts to the script that will need to be changed to fit your own environment. The admin username and password in the REST calls and the SSC name, port and path used in the curl statements. Hopefully from this you will be able to see just how easy the process is, and how the SSC can be manipulated to contain the configuration that you require.
This script can be considered a skeleton which you can use to carry out whatever configuration is required on the SSC for a particular Traffic Manager. Events and actions can be set up on the Traffic Manager which can then be used to execute scripts which can access the SSC and make the changes necessary based on any logic you see fit.
4.2.b. Upload the Bash Scripts to be Used
On the Traffic Manager, upload the bash script that will be needed for the solution to work. The scripts are uploaded in the Catalogs > Extra Files > Action Programs section of the Traffic Manager, and can then be referenced from the Actions when they are created later.
4.2.c. Create a New Event and Action for the Bandwidth Limitation Hit
On the Traffic Manager, create a new event type as shown in the screenshot below - I've created Bandwidth_Increment, but this event could be called anything relevant. The important factor here is that the event is raised from the bwlimited event.
Once this event has been created, an action must be associated with it.
Create a new external program action as shown in the screenshot below - I've created one called Bandwidth_Increment, but again this could be called anything relevant. The important factor for the action is that it's an external program action and that it calls the correct bash script, in my case called SSC_Bandwidth_Increment.
5. Testing
In order to test the solution, on the SSC, set the initial bandwidth for the Traffic Manager instance to 1Mbps.
Generate some traffic through to a service on the Traffic Manager that will force the Traffic Manager to hit it's 1Mbps limitation for a succession of time. This will cause the bwlimited event to fire and for the Bandwidth_Increment action to be executed, running the SSC_Bandwidth_Increment script.
The script will increment the Traffic Manager bandwidth by 1Mbps.
Check and confirm this on the SSC.
Once confirmed, stop the traffic generation.
Note: As the Flexible License on the Traffic Manager polls the SSC every 3 minutes for an update on it's licensed state, you may not see an immediate change to the bandwidth allocation of the Traffic Manager.
You can force the Traffic Manager to poll the SSC by removing the Flexible License and re-adding the license again - the re-configuration of the Flexible License will then force the Traffic Manager to re-poll the SSC and you should then see the updated bandwidth in the System > Licenses (after expanding the license information) page of the Traffic Manager as shown in the screenshot below;
6. Summary
Please feel free to use the information contained within this post to experiment!!!
If you do not yet have an SSC deployment, then an Evaluation can be arranged by contacting your Partner or Riverbed Salesman. They will be able to arrange for the Evaluation, and will be there to support you if required.
