Secure Global Desktop 4.40 Administration Guide
> SGD Servers, Arrays, and Load Balancing
> Tuning Application Load BalancingSecure Global Desktop 4.40 Administration Guide
> SGD Servers, Arrays, and Load Balancing
> Tuning Application Load Balancing
Administrators can tune application load balancing by editing application load balancing properties. These properties affect how the load balancing service used for Advanced Load Management operates, and how SGD calculates the application server load.
This page describes how you can tune load balancing and assumes you understand how SGD load balancing works. With the exception of tuning an application server's relative power, the following tuning only applies if you are using the Least CPU Usage and Most Free Memory methods of application load balancing (Advanced Load Management):
The weighting property allows you to factor in the relative power of the application
servers to the decision SGD takes as to where to launch an application.
This is discussed in Configuring load balancing.
The primary SGD server in the array contacts the load
balancing service on an application server on TCP port 3579.
This is controlled by the listeningport property.
The load balancing service sends updates to the primary SGD server
on UDP port 3579. This is controlled by the probe.listeningport
property.
These ports are registered with the Internet Assigned Numbers Authority (IANA) and are reserved for use only by SGD. Only change these properties if Support asks you to. You must open these ports if you have a firewall between the primary SGD server and the application servers.
The connectretries property is the number of times the
primary SGD server tries to connect to an application server to
request load updates.
The interval between each attempt is controlled by the shorttimeout property.
If the attempts to connect fail, the SGD server waits for the period of time
controlled by the longtimeout property before trying again.
For example, using the defaults for these properties, the SGD server makes 5 attempts
(connectretries) to contact the application server at 20 second intervals (shorttimeout).
If all 5 fail, SGD waits 600 seconds (longtimeout) before making 5 more
attempts at 20 second intervals.
You might want to change the timeout properties, for example, if your application server takes a long time to reboot.
The scaninterval property controls the period of time
between scans of the SGD server's list of load-balanced application servers.
The scan checks for the application servers that need to be contacted to
request a load update (connectretries).
The sockettimeout property controls how long it is before
an SGD server gets an error by trying to contact the load balancing
service when there is no data available.
The probe.samplerate and probe.windowsize properties
control how often the load balancing service measures the application server's
average load.
For example, the probe.samplerate is 10 seconds and the
probe.windowsize is 5. After 50 seconds (5 x 10), the 5 measurements
needed to calculate the average have been taken. After a further 10 seconds,
the load balancing service takes a new measurement, discards the oldest measurement
and then calculates a new average load.
You can increase and decrease the frequency of the calculation depending on how often you expect the application server load to change. For example, if users start applications at the start of the day and then close them at the end of the day, you might want to decrease the frequency of the load calculation. However, if users repeatedly start and stop applications, you might want to increase the frequency of the load calculation.
The replyfrequency property controls the interval at which
the load balancing service send updates to the primary SGD server.
The percentagechange property controls the minimum
percentage change in CPU/memory use that must be reported
to the primary SGD server. The load balancing service sends
these updates as soon as the percentage change occurs. For example if an
application server is running at 30% CPU load and the
percentchange value is 10, an update occurs
when the load is either 20% or 40%. The load balancing service takes into account sudden
'spikes' of activity and also makes adjustments when, for example a server reaches
81% CPU load and the percentagechange value is 20%.
The replyfrequency updates are sent even if the load does not change
and even if there has been a percentagechange update.
The basis for the percentagechange calculation is reset every time
there is a replyfrequency update.
If there is no update from an application server for
updatelimit x replyfrequency seconds,
SGD considers the application server to be 'out of contact'.
This means the application server is marked as unavailable to launch
applications until the SGD server can re-establish contact with it.
SGD considers the CPU and memory data it receives to be
too unreliable if there has been no update from the application server for
updatelimit x replyfrequency seconds.
Note The load balancing service sends updates even if the load does not change.
If the data is unreliable, the data is ignored when making the decision on where to launch an application. The net effect of this is to make the application server the last in the queue so that it can only be used to launch applications if no other server is available or suitable.
The primary SGD server sends CPU and memory load updates to the other
members of the array every
maxmissedsamples x replyfrequency/2 seconds. This update takes
place even if the load does not change.
If a secondary SGD server misses an update, it considers the load data it has to be unreliable and reverts to the Fewest application sessions method of load balancing. It uses this method until it receives a new update.
Copyright © 1997-2007 Sun Microsystems, Inc. All rights reserved.