This pack is designed to manage vTMs via a Brocade Services Director.
You can also manage individual vTMs directly, if you don't use Services Director, but you will need to set brcd_sd_proxy to false and supply appropriate brcd_vtm_* config keys. See Configuration section below.
You must create a configuration file: /opt/stackstorm/configs/vadc.yaml
It should look like this:
---
brcd_sd_proxy: true
brcd_sd_host: "https://sd1.management.local:8100/"
brcd_sd_user: "admin"
brcd_sd_pass: "password"
brcd_vtm_host: ""
brcd_vtm_user: ""
brcd_vtm_pass: ""
You only need to provide the brcd_vtm_* values if you plan on calling the vTMs directly.
The values can be static as above, or dynamic values as below:
brcd_sd_proxy: "{{system.brcd_sd_proxy}}"
brcd_sd_host: "{{user.brcd_sd_host}}"
brcd_sd_pass: "{{user.brcd_sd_pass}}"
Note: You can't use "user" scoped keys with sensors
Sensors can only access system level keys. So if you want to use the
BSD Status Sensor below, then you'll need to use static keys or
Dynamic Keys in the system scope.
See: StackStorm/st2#2678
Dynamic user values can be set with (for example):
st2 key set --scope=user brcd_sd_host "https://sd1.brcd.local:8100/"
st2 key set --scope=user brcd_sd_user "admin"
st2 key set --scope=user brcd_sd_pass "password" --encrypt
This pack includes a sensor to monitor errors reported by the Services Director.
The Sensor monitors your vTM status through the monitor/instance API. Any errors which appear in the status of a vTM trigger alerts which can then be processed by a rule.
This sensor triggers vadc.bsd_failure_event
Enable the sensor with:
st2 sensor enable vadc.BrcdSdSensor
####Rules
bsd_chatops
If you have ChatOps enabled, then take a look at the rule and modify it
to suit your needs. Then enable the rule with:
st2 rule enable vadc.bsd_chatops
vtm_fail_maintenance
This rule can be used to enable a "maintenance" TS automatically when
all nodes have failed in a pool. It gets triggered by the BSD Sensor
when the error_level is error, and the failed_nodes is not empty.
It only enabled the maintenance rule on vservers which use the failed pool as their default.
Enable rule with:
st2 rule enable vadc.vtm_fail_maintenance
This sensor checks the current throughput of the vTMs registered in your Services Director, and can alert you when they get close to their assigned bandwidth or automatically assign bandwidth according to utilization.
Alerts will be generated when a VTM comes within 10 or brcd\_bw\_warn
Mbps
of their currently assigned bandwidth.
If you set brcd_bw_manage to "all", or a CSV list of instances or tags,
then the sensor tracks those instances. The sensor tracks the last 10 or
brcd\_bw\_track
throughput measurements, rounded up to the nearest 10 or
brcd\_bw\_roundup
Mbps, and adds a headroom of 10 or brcd\_bw\_headroom
Mbps above this value.
When vTMs get close to the assignment, an update event will be triggered,
which can be consumed by the bsd\_bandwidth\_modify
rule.
When in use, a minimum assigned bandwidth of (brcd_bw_minimum) Mbps will be applied.
To change the defaults, add the following static/dynamic keys to the pack configuration file:
brcd_bw_minimum: "{{system.brcd_bw_minimum}}"
brcd_bw_headroom: "{{system.brcd_bw_headroom}}"
brcd_bw_roundup: "{{system.brcd_bw_roundup}}"
brcd_bw_track: "{{system.brcd_bw_track}}"
brcd_bw_warn: "{{system.brcd_bw_vtm_warn}}"
brcd_bw_manage: "{{system.brcd_bw_manage}}"
This sensor triggers vadc.bsd_bandwidth_event
Enable the sensor with:
st2 sensor enable vadc.BrcdBwSensor
####Rules
bsd_bandwidth_modify This rule takes the bsd_bandwidth_event trigger and updates the bandwidth of the given vTM instance using the action: vadc.bsd_set_vtm_bandwidth
bsd_bandwidth_notify Posts the parameters from the vadc.bsd_set_vtm_bandwidth event to a chatops channel. Notifies of Bandwidth Change Trigger
bsd_bandwidth_Alert Posts the parameters from the vadc.bsd_set_vtm_bandwidth event to a chatops channel. Notifies of Bandwidth Alert
Enable rules with:
st2 rule enable vadc.<rulename>
Actions in the pack have required and optional paramaters. To get more information about a specific action, you can use --help. For example:
st2 run vadc.bsd_list_vtms --help
The pack includes actions which manipulate or retrieve data from the Services Director and also actions which configure the vTM itself. A brief overview of the actions follow, but please use the --help system for full details of an Action.
BSD Actions
-
bsd_get_errors
Retrieve errors from the Services Director.
Returns a dictionary of failures -
bsd_get_status
retrieve status from the Services Director. You can optionally supply the instanceID/Tag of a specific vTM to get status of only that instance.
Returns a list of Status for all vTMs (or just one). -
bsd_license_vtm
Create an instance in the Services Director to license a vTM
You must provide vtm= and bw= -
bsd\ unlicense_vtm
Mark a vTM instance as Deleted in the Services Director.
You must provide a vtm=<tag|ID> parameter. -
bsd_list_vtms
Retrieve the licensed vTMs from the Service Director. This returns a limited amount of information by default, but can provide more with full=true. -
bsd_get_vtm_bandwidth Retrieve the bandwidth assignments and usage from one or all of your vTMs.
-
bsd_set_vtm_bandwidth Set the bandwidth (bw) assigned to the given instance (vtm)
vTM Actions
All of these actions are designed to proxy through the Services Director, so a vtm parameter is always required. However it isn't used if brcd_sd_proxy is set to false.
Configuration
-
vtm_add_pool
Create a pool on a vTM. You must provide the vtm, nodes, and name -
vtm_add_tip
Create a Traffic Ip Group on the vTM. You must provide the vtm,
name, a list of IP addresses, and a list of vTMs -
vtm_add_vserver
Create a Virtual Server on the vTM. You must provide the vtm, name, pool, and TIP Group. -
There is also a delete action for all of the add actions above.
Operations
-
vtm_drain_nodes
Mark a list of nodes as draining, or undrain the nodes in a pool.
You must provide the vtm, name, and a list of nodes. By default we drain nodes, but you can pass drain=false to undrain them. -
vtm_set_pool_nodes Set nodes in pool by providing lists of active, draining, and disabled nodes.
-
vtm_enable_ssl_offload Enable SSL Offload on a VTM Virtual Server. You must provide the vserver, and certificate name, and optionally whether to inject the X-Forwarded-Protocol, and additional SSL Headers. There is also a disable action.
-
vtm_enable_ssl_encryption Enable SSL Encryption on a pool. You must provide the name of the pool. If you want vTM to verify the certificate chain of the server, then set verify to true. There is also a disable action.
-
vtm_add_webhook_action Uploads the webhook action script to the vTM. You must provide the st2 API Key, and WebHook URI for the action to call. The action can be associated with an existing event on the vTM, if you provide its name.
-
vtm_get_pool_nodes
Retrieve a list of nodes from the given pool. You must provide the vtm and the name of the pool. -
vtm_maintenance_mode
Enabled or disable a Maintenance mode TrafficScript rule.
You must provide the vtm and vserver name, default is to enable the maintenance rule, and the default rule name is maintenance.
Backups
-
vtm_list_backups Get a list of Backups from the provided vTM
-
vtm_create_backup Create a new BackUp on the vTM.
-
vtm_delete_backup Remove a backup from the vTM.
-
vtm_add_backup Upload a Backup to the vTM ready for restoration. You must provide the filename in the
tarball
parameter. -
vtm_get_backup Download a backup from the vTM. This will be downloaded to the local file system in
outdir
. The name of the file will be returned in the result. -
vtm_restore_backup Restore a backup to the vTM.
Chains and workflows
A couple of example workflows and chains are provided in the pack. They both create and delete a service comprised of a pool, vserver and tip.
Aliases are used to present command aliases to ChatOps, a number are included for ChatOps integration
TODO List Aliases