Enables or disables Autoscaling. When this is enabled, nodes will be added and removed from the pool using the mechanism specified by autoscale!external.

Some cloud providers have their own mechanism for performing autoscaling. In this case, a cloud provider would monitor the performance for a group of machines (those being the machines in the pool) and will add and remove machines as needed. The cloud provider will indicate to the Traffic Manager that it has added or removed a machine using its API. When the Traffic Manager has been informed of the change, it will add or remove nodes from the autoscaling pool accordingly.

If you intend to use your cloud provider's autoscaling mechanism, set this parameter to “Yes”. If you intend to use the Traffic Manager's Autoscaling mechanism, set this to “No”.

The unique identifier of the virtual machine image from which you create new node instances. The Traffic Manager adds each newly created node to the pool when it identifies the need to increase capacity. A Traffic Manager seeing instances in the cloud using this AMI assumes that those instances belong to the corresponding pool.

The unique identifier used here determines the operating system and the services running on the node. In an EC2 cloud, this parameter is called ImageId.

The identifier that indicates the size--in terms of resources--of the virtual machine required for an instance of a node that is to be added to a pool. In EC2, this parameter is called InstanceType.

Typically, more powerful machines are associated with higher costs.

An optional prefix added to the name of new nodes created during an autoscaling event.

A Traffic Manager seeing instances in the cloud starting with this name assumes those instances belong to the corresponding pool.

A security group acts as a firewall that controls the traffic for one or more node instances. When an instance is launched, EC2 can associate it with one or more security groups. To create this association, specify a list of security group IDs (do not use group names) in the Extra Arguments text box. For EC2-Classic deployments, you must use security groups created specifically for EC2-Classic. Similarly, for EC2-VPC, you must use security groups created specifically for your VPC. If you do not specify security groups here, EC2 applies the default security group.

A list of IDs of the VPC subnets where the new EC2-VPC instances are launched. Instances are evenly distributed among the subnets you specify in the Extra Arguments text box. To launch instances inside EC2-Classic, leave the list empty.

To distribute auto-scaled EC2-VPC nodes evenly across different availability zones, Ivanti recommends listing the subnets present in different availability zones.

The unique internal identifier of the virtual machine image from which you create new node instances. The Traffic Manager adds each newly created node to the pool when it identifies the need to increase capacity. The unique identifier used here determines the operating system and the services running on the node. In a Rackspace cloud, this parameter is called imageId.

You must use the internal image identifier here.

To get a list of the image identifiers available for a given set of cloud credentials, run the included rackspace.pl script manually from the command line:

$ZEUSHOME/zxtm/bin/rackspace.pl \

listimageids \

--cloudcreds=<credentials>

Replace <credentials> with your Rackspace cloud credentials.

The internal identifier that indicates the size--in terms of resources--of the virtual machine required for an instance of a node that is to be added to a pool. In Rackspace, this parameter is called FlavorId.

Typically, more powerful machines are associated with higher costs.

To get a list of the size identifiers available for a given set of cloud credentials, run the included rackspace.pl script manually from the command line:

$ZEUSHOME/zxtm/bin/rackspace.pl \

listsizeids \

--cloudcreds=<credentials>

Replace <credentials> with your Rackspace cloud credentials.

The built-in vSphere driver script creates new Virtual Machines (VMs) by deploying them from existing VM templates. These templates are pre-configured VMs which are marked as a template upon which new VMs can be based. The path of the template on a vCenter server is usually in the form:

<DatacenterName>/vm/<TemplateName>

New nodes will be created with this name prefix on the vCenter Server. If multiple pools are autoscaling on the same vSphere infrastructure, care must be taken to keep the name prefixes for each pool unique.

All ESX hosts managed by the vCenter server are arranged in logical datacenters. Autoscaling is performed on the hosts or clusters contained within this datacenter.

The data-store that will be used by the newly created virtual machines. If left blank, the default data-store used by the datacenter will be used (depending on the vCenter configuration).

If a data-store is specified here, you should ensure the VM template uses the same data-store.

(IP addresses-to-use) Instances in cloud environments typically have at least two IP addresses: one on a private network for communication with other nodes in the same cloud, and one on a public network for communication with the Internet in general. Select "private" or "public" to define whether traffic should be sent to the new node's private address, or its public address.

Instances inside Amazon EC2-VPC do not have a public IP address by default. Select "public" to assign one at creation time.

This defines the port to use when adding nodes to the pool. This port corresponds to the service listening on the back-end machine that gets spawned in the cloud environment.

This defines the minimum number of nodes that are allowed to exist in the autoscaling pool. Note that this number will also include nodes that are currently marked as failed. A node failure in these circumstances can lead to a degradation in response times, which in turn will result in a new node being auto-scaled in. This behavior is not guaranteed, however. An autoscaling pool that contains failed nodes will not auto-scale beyond the number specified by autoscale!max_nodes.

The Traffic Manager monitors the response times (in milliseconds) of the nodes in an autoscaling pool. This is measured from the time the Traffic Manager starts initiating a connection to the node until it receives the first byte of the response. A response time of less than autoscale!response_time is considered conforming and longer times are considered non-conforming. The Traffic Manager continuously measures the percentage of conforming connections.

When the percentage of conforming responses rises above this value for at least autoscale!hysteresis seconds, the pool is scaled down (in other words, a node is removed from the pool).

When the percentage of conforming responses falls below this value for at least autoscale!hysteresis seconds, the pool is scaled up (in other words, a node is added to the pool).

After a change to the pool size has been made (be it an increase or a decrease), the Traffic Manager will wait autoscale!refractory seconds before making another change. It will take some time for the new node to have its effect on the overall response times of the pool. So to prevent too many nodes from being created (or destroyed) at a time, you may want to increase this time period.

The amount of time (in seconds) that an autoscaling condition must exist before the Traffic Manager instigates a change. This corresponds to (for example) the time that the pool's percentage of conforming connections must remain below autoscale!scaleup_level before a scale-up event occurs.