Chapter 16. Managing Networks and Traffic
164

Runtime Considerations

• An administrator should not assign a VM to a load balancing rule which is configured for AutoScale.
• Before a VM provisioning is completed if NetScaler is shutdown or restarted, the provisioned VM
cannot be a part of the load balancing rule though the intent was to assign it to a load balancing
rule. To workaround, rename the AutoScale provisioned VMs based on the rule name or ID so at
any point of time the VMs can be reconciled to its load balancing rule.
• Making API calls outside the context of AutoScale, such as destroyVM, on an autoscaled VM leaves
the load balancing configuration in an inconsistent state. Though VM is destroyed from the load
balancer rule, NetScaler continues to show the VM as a service assigned to a rule.
16.8.3. Sticky Session Policies for Load Balancer Rules
Sticky sessions are used in Web-based applications to ensure continued availability of information
across the multiple requests in a user's session. For example, if a shopper is filling a cart, you need
to remember what has been purchased so far. The concept of “stickiness” is also referred to as
persistence or maintaining state.
Any load balancer rule defined in CloudPlatform can have a stickiness policy. The policy consists of a
name, stickiness method, and parameters. The parameters are name-value pairs or flags, which are
defined by the load balancer vendor. The stickiness method could be load balancer-generated cookie,
application-generated cookie, or source-based. In the source-based method, the source IP address
is used to identify the user and locate the user’s stored data. In the other methods, cookies are used.
The cookie generated by the load balancer or application is included in request and response URLs to
create persistence. The cookie name can be specified by the administrator or automatically generated.
A variety of options are provided to control the exact behavior of cookies, such as how they are
generated and whether they are cached.
For the most up to date list of available stickiness methods, see the CloudPlatform UI or call
listNetworks and check the SupportedStickinessMethods capability.
For details on how to set a stickiness policy using the UI, see Section 16.8.1, “Adding a Load Balancer
Rule”.
16.8.4. Health Checks for Load Balancer Rules
(NetScaler load balancer only; requires NetScaler version 10.0)
Health checks are used in load-balanced applications to ensure that requests are forwarded only to
running, available services. When creating a load balancer rule, you can specify a health check policy.
This is in addition to specifying the stickiness policy, algorithm, and other load balancer rule options.
You can configure one health check policy per load balancer rule.
Any load balancer rule defined on a NetScaler load balancer in CloudPlatform can have a health
check policy. The policy consists of a ping path, thresholds to define "healthy" and "unhealthy" states,
health check frequency, and timeout wait interval.
When a health check policy is in effect, the load balancer will stop forwarding requests to any
resources that are found to be unhealthy. If the resource later becomes available again, the periodic
health check will discover it, and the resource will once again be added to the pool of resources that
can receive requests from the load balancer. At any given time, the most recent result of the health
check is displayed in the UI. For any VM that is attached to a load balancer rule with a health check
configured, the state will be shown as UP or DOWN in the UI depending on the result of the most
recent health check.