Load Balancing

Load balancing helps you scale up to support more users so that they receive a reliable and high-performance service without any single point of failure.

SGD supports the following load balancing mechanisms:

User session load balancing – Determines which SGD server in the array a user logs in to

See User Session Load Balancing for details.
Application session load balancing – Determines which SGD server in the array manages an application session for a user

See Application Session Load Balancing for details.
Application load balancing – Determines which application server runs an application for a user

See Application Load Balancing for details.
Load balancing groups – Tries to deliver the best possible user experience by choosing SGD servers and application servers linked by a fast network

See Load Balancing Groups for details.

User Session Load Balancing

User session load balancing is concerned with choosing a SGD server to log in to. Users can log in to any SGD server in an array and access the same applications.

User session load balancing happens before the first connection is made to SGD. You can use a number of mechanisms to choose an appropriate SGD server, for example:

The SGD Gateway
Round-robin or Dynamic DNS
An external hardware load balancer
The SGD load-balancing JavaServer Pages (JSP) technology page
Allocate different SGD servers to different departments and give one Uniform Resource Locator (URL) to each department

When load balancing user sessions, the most important factor is session persistence. A user session begins when a user logs in to an SGD server and the session is owned by that server. As the user interacts with SGD, further requests are sent over the Hypertext Transfer Protocol (HTTP) connection to the SGD server. If network connections are load-balanced, HTTP requests might be directed to any SGD server in the array. If an HTTP request goes to an SGD server that does not own the user session, the following can occur:

The user session is transferred to that SGD server and the windows of any running applications might disappear. This is sometimes called session grabbing.
The visible state of the user’s session is displayed incorrectly.

To load balance user sessions successfully, HTTP requests must persist so that they always go to the correct SGD server.

In a default SGD installation, additional configuration is required to make HTTP connections persistent. SGD supports the following mechanisms:

The SGD Gateway. The SGD Gateway contains an Apache web server that manages the load balancing of HTTP connections to SGD.
The load-balancing JSP technology page. The load-balancing JSP technology page contains a JavaScript technology script that sets a cookie, and that cookie is used to redirect HTTP requests to the correct server.

The Gateway provides the best solution for load balancing user sessions. The load-balancing JSP technology page might not be available in future releases of SGD.

Instructions on how to install, configure, and use the SGD Gateway are included in the Oracle Secure Global Desktop 4.6 Gateway Administration Guide.

The load-balancing JSP technology page can only be used if the following conditions are met:

Browsers must have cookies enabled and JavaScript technology enabled
The SGD Client must not be in Integrated mode

The load-balancing JSP technology page can be used in the following ways:

The JSP technology page selects an SGD server from a list using a round-robin mechanism.

To use the JSP technology page in this way, you configure the load-balancing JSP technology page on one member of the array. See Using The Load-Balancing JSP Technology Page to Distribute User Sessions.
The JSP technology page supports an external mechanism for selecting an SGD server.

To use the JSP technology page in this way, you configure the load-balancing JSP technology page on every member of the array. See Using an External Mechanism to Distribute User Sessions.

Using The Load-Balancing JSP Technology Page to Distribute User Sessions

To use the load-balancing JSP technology page to distribute user sessions, one member of the array acts as the load distribution server. Typically this is the primary SGD server in the array. On the load distribution server, you configure the load-balancing JSP technology page with a list of SGD servers that can host user sessions. Users connect to the load distribution server and the load-balancing JSP technology page redirects them to an SGD server in the list using a round-robin mechanism.

Users must connect to the load distribution server using a URL that connects to the load-balancing JSP technology page, usually this is http://server.example.com/sgd, where server.example.com is the name of an SGD server.

To use Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) connections, you configure SGD as follows:

Use an HTTP connection to the load distribution server.
Configure HTTPS URLs for the SGD servers in the load-balancing JSP technology page.

How to Configure the Load-Balancing JSP Technology Page to Distribute User Sessions

Before You Begin

Select one member of the array to act as the load distribution server. The following procedure uses the primary SGD server in the array.

Log in as superuser (root) on the primary SGD server in the array.
Copy the load-balancing JSP technology pages to the /sgd web application directory.
For example:
```
# cd /opt/tarantella/webserver/tomcat/tomcat-version/webapps/sgd/
# cp -rp admin/loaddist/ swcd/
```
Note - When you copy the files, use the -p option to preserve the file permissions.
Edit the load-balancing JSP technology page.
The load-balancing JSP technology page is swcd.jsp.
1. Add the external DNS names of the SGD servers to be load balanced.
  See Configuring External DNS Names for details.
  Amend the hosts = new Array section, for example:
```
hosts[0] = "http://www1.example.com"
hosts[1] = "http://www2.example.com"
...
hosts[4] = "http://www5.example.com"
```
  If you are using secure connections, ensure the URLs begin with https://.
  Only include the primary SGD server in the list if you want the primary server to host user sessions.
2. Set the LBHOST variable.
  Remove the first comment marks (//) as follows:
```
var LBHOST = null // Not in Load Balancer/Round Robin DNS mode
```
3. Save the changes.
Configure the SGD entry point JSP technology page to use the load-balancing JSP technology page.
The entry point JSP technology page is index.jsp.
1. Change the first line to the following:
```
<%@ include file="swcd/swcd.jsp" %>
```
2. Save the change.

Using an External Mechanism to Distribute User Sessions

When using an external mechanism, such as a hardware load balancer or round-robin DNS, for load balancing user sessions, the following factors are important:

External DNS names. The SGD servers in the array must be directly accessible using their external DNS names. If an external load balancer is acting as a firewall, a switch, or a router, it must be configured to allow access using the external DNS names. See Configuring External DNS Names.
Adaptive Internet Protocol (AIP) connections. AIP connections must go to the SGD server that is hosting the application session. An external load balancer must not distribute the connections to different SGD servers in the array.
AIP is not HTTP. If you enable SGD security services, AIP connections are encrypted using Secure Sockets Layer (SSL). If an external load balancer decrypts the SSL for an AIP request, it cannot handle the remaining contents.
URL rewriting. An external load balancer can be configured to rewrite URLs. The impact of a connection to SGD using a URL containing a host name that does not match the external DNS name of the SGD server is undefined.
Virtual hosting multiple HTTPS connections. To use HTTPS connections to an external load balancer and the SGD web server requires two SSL certificates: one for the load balancer DNS name and one for the external DNS name of the SGD server. You can only do this by using virtual hosting to create two web servers on the same host, each with a different DNS name. However, the web servers must use either different TCP ports or different Internet Protocol (IP) addresses.

To use an external mechanism to distribute user sessions, you configure the load-balancing JSP technology page on every SGD server in the array.

If you are using a hardware load balancer, the load balancer must be configured to allow access to the SGD servers using their external DNS names. Typically the load balancer is also an SSL accelerator. With this configuration, the connection to SGD is processed as follows:

Users make HTTPS connections to the load balancer DNS name.
The load balancer decrypts the SSL request and forwards it as an HTTP request to the external DNS name of the selected SGD server.
The load-balancing JSP technology page on the SGD server checks for the load-balancing cookie and redirects the HTTP request to the correct SGD server as needed.

Users must connect to SGD using a URL that contains the DNS name of the load balancer, for example https://loadbalancer.indigo-insurance.com/sgd.

If SGD security services are enabled, and the external load balancer is configured to decrypt SSL connections and forward them as unencrypted connections, you must configure each SGD server in the array to accept plain text connections on the secure port. See Using External SSL Accelerators for details.

To use HTTPS connections between the load balancer and the SGD servers, ensure that the URLs in the load-balancing JSP technology page begin with https://. Then perform either of the following configurations:

Configure the external load balancer to terminate the load-balanced HTTPS connection and then regenerate the connection as an HTTPS connection to the external DNS name of the SGD server.
Assign an additional IP address to the SGD host and configure the host to use this address. Configure the SGD web server to listen on the additional IP address and associate the SSL certificate for the load balancer with this address. Configure the SGD web server to associate the external DNS name of the SGD server with the original IP address of the server. Configure the load balancer to use the additional IP addresses.

Using SGD in firewall traversal mode can also help to simplify the configuration needed when using an external load balancer. With firewall traversal, the HTTP and AIP connections to SGD are made over a single port, usually TCP port 443. See Firewall Traversal.

How to Configure the Load-Balancing JSP Technology Page for an External Load Balancing Mechanism

Before You Begin

The following procedure is an example of how to configure the load-balancing JSP technology page on an SGD server when using an external load balancing mechanism.

All the SGD servers in the array must be configured in the same way.

Log in as superuser (root) on the SGD host.
Copy the load-balancing JSP technology page files to the /sgd web application directory.
For example:
```
# cd /opt/tarantella/webserver/tomcat/tomcat-version/webapps/sgd/
# cp -rp admin/loaddist/ swcd/
```
Note - When you copy the files, use the -p option to preserve the file permissions.
Edit the load-balancing JSP technology page.
The load-balancing JSP technology page is swcd.jsp.
1. Add the external DNS names of the SGD servers to be load balanced.
  See Configuring External DNS Names for details.
  Amend the hosts = new Array section, for example:
```
hosts[0] = "http://www1.example.com"
hosts[1] = "http://www2.example.com"
...
hosts[4] = "http://www5.example.com"
```
2. Set the LBHOST variable.
  Remove the first comment marks (//) and enter the external DNS name of the SGD server, for example:
```
var LBHOST = "http://www1.example.com" // LB mode
```
3. Save the changes.
Configure the SGD entry point JSP technology page to use the load-balancing JSP technology page.
The entry point JSP technology page is index.jsp.
1. Change the first line to the following:
```
<%@ include file="swcd/swcd.jsp" %>
```
2. Save the change

How to Configure the Load-Balancing JSP Technology Page for Use With My Desktop

Before You Begin

See Using My Desktop for details of the My Desktop features.

All the SGD servers in the array must be configured in the same way.

Log in as superuser (root) on the SGD host.
Copy the load-balancing JSP technology page files to the /sgd/mydesktop web application directory.
For example:
```
# cd /opt/tarantella/webserver/tomcat/tomcat-version/webapps/sgd/
# cp -rp admin/loaddist/ mydesktop/swcd/
```
Note - When you copy the files, use the -p option to preserve the file permissions.
Configure My Desktop to use the load-balancing JSP technology page.
1. Rename the My Desktop entry point JSP technology page.
  The entry point JSP technology page is mydesktop/index.jsp.
  For example:
```
# mv mydesktop/index.jsp mydesktop/mydesktop.jsp
```
2. Create a new entry point JSP technology page for My Desktop.
  Create a new JSP technology page file, mydesktop/index.jsp, with the following content:
```
<%@ include file="/mydesktop/swcd/swcd.jsp" %>
```
3. Check the file permissions for the My Desktop JSP technology page files.
```
# chmod root:ttaserv mydesktop/index.jsp mydesktop/mydesktop.jsp
```
Edit the load-balancing JSP technology page.
The load-balancing JSP technology page is mydesktop/swcd/swcd.jsp.
1. Add the external DNS names of the SGD servers to be load balanced and set the LBHOST variable.
  - To use the loadbalancing JSP technology page to distribute user sessions, follow the instructions in Step 3 of How to Configure the Load-Balancing JSP Technology Page to Distribute User Sessions.
  - To use an external mechanism to distribute user sessions, follow the instructions in Step 3 of How to Configure the Load-Balancing JSP Technology Page for an External Load Balancing Mechanism.
2. Set the TARGET variable.
  You must change the TARGET variable so that it directs users to My Desktop instead of the webtop.
```
var TARGET="/sgd/mydesktop/mydesktop.jsp"
```
3. Save the changes.

Additional Load-Balancing JSP Technology Page Configuration

This section describes the additional configuration that is available for the load-balancing JSP technology page.

Using Another Webtop

The load-balancing JSP technology page connects users to the standard webtop. To use another webtop, for example a customized webtop, amend the following line:

var TARGET="/sgd/standard.jsp"

Localized Splash Screen

The load-balancing JSP technology page displays a splash screen in English using the images in the /sgd/swcd/ directory. To display a localized splash screen, change the default location of the splash screen images in the following lines:

// ** Location of gif files
<%
// If the gifs are located in the locale dependent resource use the Path below
String path = getContextPath(request) + "/resources/images/splash/locale=" +
getBestSupportedLocale(request) + "/";
// Default location
//String path = "swcd/";
%>

Other Variables

The following are the other variables used by the load-balancing JSP technology page:

SGDLDCOOKIE

The name of the cookie used for load balancing purposes.

The default is SGD_SWCDCOOKIE.
TIMEOUT

The time in milliseconds the load-balancing JSP technology page waits for a response from the SGD web server on the selected host. If the timeout period elapses, the next host in the list is tried.

The default is 10000 milliseconds.
TESTGIF

The file the load-balancing JSP technology page attempts to get from the SGD web server on the selected host. This is used to check whether the host is available.

The default is /sgd/resources/images/webtop/secure.gif.

Application Session Load Balancing

Application session load balancing is concerned with choosing an SGD server to manage an application session.

An application session consists of a set of data about the session, for example the user identity of the user that started the session, and a Protocol Engine process. The Protocol Engine process runs on an SGD server and performs the following tasks:

Maintains the connection to the application on the application server
Stores the display data for the application
Sends and receives data over the AIP connection to the client device

A Protocol Engine process can run on any SGD server in the array. This is not necessarily the same server that hosts the user session, which is the SGD server the user logged in to.

SGD can load balance application sessions across all the SGD servers in the array. The more servers you have, the less the load on each. In the Administration Console, you configure application session load balancing on the Global Settings -> Performance tab. You can configure SGD to use one of the following methods for selecting the SGD server to host the application session:

Server Hosting the User Session – The SGD server that is hosting the user session
Least CPU Usage – The SGD server with the most central processing unit (CPU) idle time
Fewest Application Sessions – The SGD server that is hosting the fewest application sessions

By default, SGD load balances application sessions using the server that hosts the user session.

Application Load Balancing

Application load balancing is concerned with the following:

Choosing an application server to run an application so that users get the best performance
Distributing application starts so that the application servers achieve a similar relative workload

SGD Administrators manage application load balancing by defining the application servers that can run an application, and by selecting the load balancing method to use.

Defining the Application Servers to Run the Application

You define the application servers that can run an application by assigning application server objects to the application object.

In the Administration Console, you do this on the Hosting Application Servers tab for the application. Alternatively, you can assign an application to an application server. You do this on the Hosted Applications tab for the application server object.

You can also assign groups of applications to an application server, or groups of application servers to an application. Groups are useful for creating pools of application servers, sometimes called application server farms, or applications.

In the Administration Console, you can also select and deselect the Application Start check box on the General tab for an application server object. This marks an application server as available or unavailable to run applications. This is useful, for example, to make a server temporarily unavailable during maintenance work.

Selecting the Load Balancing Method

You can select the load balancing method that SGD uses to determine the most suitable application server for the user.

In the Administration Console, you configure a default load balancing method on the Global Settings -> Performance tab. You can override the global load balancing method for an individual application by selecting a different method on the Performance tab for the application object.

By default, SGD uses a method that load balances applications by counting the number of application sessions each server is hosting through SGD and then selecting the server with the fewest sessions. SGD also provides methods for load balancing applications based on the true load of the application server when a user starts an application. This is called Advanced Load Management. To use Advanced Load Management, you must install the SGD Enhancement Module on every application server.

See How Application Load Balancing Works for details on how the load balancing method and other factors affect load balancing.

Load Balancing Groups

SGD uses load balancing groups to ensure that connections between SGD servers and application servers take place over high-speed links.

SGD’s Protocol Engines convert the native protocol, such as X11, which is used between the application server and the SGD server, into AIP, which is used between the SGD server and the client device. AIP is optimized for lower bandwidths, but native protocols are not.

If your network includes slow links, you can improve the performance of applications by using load balancing groups. You use load balancing groups to group SGD servers and application servers together. When a user runs an application, SGD tries to ensure that the Protocol Engine process runs on an SGD server in the same group as the application server. This works best when all the application servers and SGD servers in a group are connected by high-speed links.

In the Administration Console, you define the load balancing groups on the Performance tab for an SGD server or an application server. The load balancing group name is simply a string or a comma-separated list of strings. The name can be anything, for example the location in the world or a building code.

How Application Load Balancing Works

The purpose of application load balancing is to select the application server that gives the user the best performance for a particular application. When starting an application, SGD builds a list of candidate application servers using the application servers listed on the Hosting Application Servers tab for the application object. SGD then has to determine which of the candidates is the best one for the user. The decision takes into account the following factors:

Dynamic application servers
Application server availability
Application server filters
Load balancing groups
Server affinity
The relative power of the application servers
The application server with the least load

The following sections describe how these factors, and your SGD configuration, affect the choice of application server.

Dynamic Application Servers and Load Balancing

If a dynamic application server is configured for the application, the normal SGD mechanisms for application load balancing are overridden because users can choose where to run an application. See Dynamic Application Servers for more details.

When dynamic application servers are used, only the following application server attributes have an effect on the list of application servers presented to a user:

Application Start (--available) – See Application Server Availability for details
User Assignment (--userassign) – See Application Server Filters for details
Maximum Count (--maxcount) – See Application Server Filters for details

Application Server Availability

When starting an application, SGD checks its list of candidate application servers to see if any of them are currently unavailable. If an application server is unavailable, it is removed from the list.

You can use the Application Start (--available false) attribute on an application server objects to mark an application server as being unavailable. You can do this, for example, to make an application server unavailable during maintenance work.

If you are using SGD Advanced Load Management, the load balancing service sends regular keep alive packets to SGD. If these packets stop, SGD considers the application server to be “out of contact” and treats the server as unavailable until the load balancing service makes contact again.

Application Server Filters

Application server objects have a Maximum Count (--maxcount) and a User Assignment (--userassign) attribute that can be used to filter the application servers that run an application for a user.

The Maximum Count attribute is used to limit the number of applications that can run on an application server. Once the limit is reached, SGD does not select the application server to run any more applications. For example, if you assign a group of application servers to an application, and the Maximum Count setting for each application server object is 1, SGD runs each instance of the application on a different application server, and each application server is only used once.

The User Assignment attribute is used to filter application servers based on the user identity (the fully-qualified user name) of the user. It restricts the usage of an application server to particular users or members of LDAP groups. The search filter can be any of the following:

An RFC2254-compliant LDAP search filter
An RFC1959-compliant LDAP URL
A scottasessionowner= filter

Note - SGD applies the LDAP-based search filters even if the user identity is not an LDAP identity.

For more information on how to configure User Assignment search filters, see User Assignment.

The Maximum Count and User Assignment attributes can be used individually or together to control the application servers that can run an application for a user. The following table shows the effect of using these attributes on the choice of application server.

User Assignment	Maximum Count	Effect
None	Not set	The application server can run an unlimited number of applications for all users.
None	Set to `N`	The application server can only run `N` application instances for all users.
User search filter	Not set	The application server can run an unlimited number of applications only for the users that match the search filter.
User search filter	Set to `N`	The application server can only run `N` application instances only for users that match the search filter.
LDAP group search filter	Not set	The application server can run an unlimited number of applications only for members of the LDAP group.
LDAP group search filter	Set to `N`	The application server can only run `N` application instances only for members of the LDAP group.

Load Balancing Groups

Load balancing groups are used to group SGD servers and application servers together. When a user runs an application, SGD tries to ensure that the Protocol Engine process runs on an SGD server in the same load balancing group as the application server. This works best when all the application servers and SGD servers in a group are connected by high-speed links.

See Load Balancing Groups for more detail.

Server Affinity

When starting an application, SGD takes into account whether the user is already running any applications on an application server. This is known as server affinity. Server affinity means that, if possible, SGD runs an application on the same application server as the last application started by the user.

Note - For server affinity to work efficiently, the applications must be associated with the same set of application servers.

Server affinity is expressed as a percentage. Currently only the following two values are allowed:

0 – Any running applications do not affect the choice of application server.
100 – Any existing application servers must be reused if they can run the selected application. This is the default value.

You change the server affinity value by running the following command:

$ tarantella config edit \
--tarantella-config-applaunch-appserveraffinity 0|100

Caution - If you are using Windows applications, it is best not to change this value, as using multiple application servers causes problems, especially with roaming profiles. There might also be licensing implications for running different applications in a suite of applications on different servers.

The Relative Power of the Application Servers

SGD allows you to factor in the relative power of the application servers to the decision as to where to start an application.

The relative power is expressed as a percentage and by default all servers have a value of 100. By editing the weighting load balancing property for your servers, you can increase or decrease these weightings to increase or decrease the likelihood of SGD choosing an application server. For more details about weightings, see Tuning Application Load Balancing.

You can use the relative power of application servers to do the following:

Reduce the number of application sessions that are started on a particular server, for example, because it is used for other processes outside of SGD
Increase the number of application sessions that are started on a particular server, for example, because, although it has less CPU capacity, it has better Input/Output (I/O) capabilities

For more details on how the weighting is used, see the load calculations in The Application Server With the Least Load.

Example Relative Power Calculation 1

You have two application servers, london and paris. Paris has a weighting of 50 and london has a weighting of 100. If all the other conditions for starting applications are met and the servers currently have the same load, london is more likely to be chosen to run the application.

Example Relative Power Calculation 2

You have 100 application servers and you want to make just one of them “more powerful” than the others. Increase the weighting of that server to 200.

The Application Server With the Least Load

SGD supports several methods for selecting the application server with the least load.

You set a default method on the Global Settings -> Performance tab in the Administration Console. You can override the default by specifying a different method on the Performance tab for the application object. This allows you to load balance applications in different ways.

The following are the supported application load balancing methods:

Fewest Application Sessions
Least CPU Usage
Most Free Memory

The Least CPU Usage and Most Free Memory methods calculate the true load of the application server when a user starts an application. This is called Advanced Load Management. See How Advanced Load Management Works for more details.

Fewest Application Sessions

The Fewest Application Sessions method allows SGD to choose the application server which is currently running the fewest number of application sessions. It is based on a simple count of the number of application sessions hosted through SGD.

This method is the default.

If you use Advanced Load Management, the Fewest Application Sessions method is used as a fallback whenever there is a problem, for example if the application server load information is not available to the array when the application is started. This might happen, for example, if the primary SGD server is being restarted.

The application server load is calculated using the following formula:

number of application sessions x 100 /server weighting

Example Load Calculation Using Fewest Application Sessions

The following is an example of how SGD calculates the load using the Fewest Application Sessions method of application load balancing.

The application server london is currently hosting 10 application sessions and has a server weighting value of 100.

The application server paris is currently hosting 12 application sessions, and has a server weighting value of 100.

The load value for london is:

10 x 100/100 = 10

The load value for paris is:

12 x 100/100 = 12

Assuming the other conditions for starting an application are met, SGD chooses london to run the next two application sessions. If the server weighting value for london was decreased to 50, SGD chooses paris to run the next 8 application sessions, because london’s load is now 20 (10 x 100/50).

Least CPU Usage

The Least CPU Usage method allows SGD to choose the application server with the most CPU idle and is suitable for applications that require many processor cycles.

The method measures the application server’s load in terms of its CPU capabilities, measured in BogoMips, and by how much of its CPU is being used. These measurements are taken by the load balancing service.

The spare capacity is calculated using the following formula:

(BogoMips x CPU idle %) x weighting /100

Example Load Calculation Using Least CPU Usage

The following is an example of how SGD calculates the load using the Least CPU Usage method of application load balancing.

The application server london has a BogoMips measurement of 500, a server weighting value of 75 and has 25% CPU idle.

The application server paris has a BogoMips measurement of 100, a server weighting value of 100 and has 50% CPU idle.

The spare capacity for london is:

(500 x 25) x 75/100 = 9375

The spare capacity for paris is:

(100 x 50) x 100/100 = 5000

Assuming the other conditions for starting an application are met, london is chosen as the application server, even though paris is using less of its CPU and has a higher server weighting value.

Most Free Memory

The Most Free Memory method allows SGD to choose the application server with most free virtual memory and is suitable for applications that require a lot of memory.

The method measures the application server’s load by comparing the application server’s actual virtual memory with the amount of memory that is currently being used. These measurements are taken by the load balancing service.

The spare capacity is calculated using the following formula:

virtual memory free x weighting /100

Example Load Calculation Using Most Free Memory

The following is an example of how SGD calculates the load using the Most Free Memory method of application load balancing.

The application server london has a server weighting value of 100 and has 250 megabytes virtual memory free.

The application server paris has a server weighting value of 75 and has 500 megabytes virtual memory free.

The spare capacity value for london is:

250 x 100/100 = 250

The spare capacity value for paris is:

500 x 75/100 = 375

Assuming the other conditions for starting an application are met, paris is the chosen application server.

How Advanced Load Management Works

Advanced Load Management enables you to load balance applications based on either the amount of free memory, or the amount of free CPU, the application server has when the application is started. You can only load balance X applications, Windows applications, and character applications using these methods.

To use Advanced Load Management, you must install the SGD Enhancement Module on every application server. This installs a load balancing service which provides SGD with real-time information about the application server’s CPU and memory load. It also helps SGD to detect if an application server is unavailable, for example because it is being rebooted.

The following is an overview of how the load balancing service works:

Whenever the primary SGD server is started, it builds a list of application servers that need to be considered for load balancing. The list is updated whenever a host is assigned to, or removed from, an application.
The primary SGD server contacts each of the load-balanced application servers and requests initial load information. It does this by contacting the load balancing service on TCP port 3579 on each application server. Establishing contact also confirms that the application server is available to run applications.
The primary SGD server sends an update to the secondary servers in the array. The update contains capacity values for each of the methods and information about the application servers that are not available.
The load balancing service sends regular updates to the primary SGD server on User Datagram Protocol (UDP) port 3579. The updates take place even if the load does not change. The absence of a regular update helps SGD to detect whether an application server is available to run applications.
The primary SGD server sends regular updates to the secondary servers in the array. The update contains capacity values for each of the methods and information about the application servers that are not available. The updates take place even if the load does not change.

Note - The load balancing service always sends application server load data to the primary SGD server. If the primary server is not available, Advanced Load Management is not available and the secondary servers revert to the default session-based load balancing instead.
The primary or secondary SGD servers starts applications on the basis of the load information they receive in the updates.

Tuning Application Load Balancing

SGD 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. You can tune application load balancing globally and for individual application servers. See Editing Application Load Balancing Properties for details on how to edit the load balancing properties.

Before you tune application load balancing, make sure you have read and understood the following:

How Application Load Balancing Works
How Advanced Load Management Works

You can tune the following aspects of how application load balancing works:

Application server’s relative power
Load balancing listening ports
SGD server requests updates from an application server
Frequency of the load calculation
Frequency of updates to the primary SGD server
Reliability of CPU and memory data
Frequency of updates to array members

This tuning is described in the following sections.

Caution - With the exception of tuning an application server’s relative power, this tuning only applies if you are using Advanced Load Management.

Application Server’s Relative Power

The weighting property allows you to factor in the relative power of the application servers to the decision SGD takes as to where to run an application. This is discussed in The Relative Power of the Application Servers.

Load Balancing Listening Ports

The primary SGD server in the array contacts the SGD 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 Oracle Support asks you to. You must open these ports if you have a firewall between the primary SGD server and the application servers.

SGD Requests Updates From an Application Server

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 primary SGD server makes 5 attempts (connectretries) to contact the application server at 20 second intervals (shorttimeout). If all 5 attempts 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 an 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.

Frequency of the Load Calculation

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.

Frequency of Updates to the Primary SGD Server

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 or 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 percentage change 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 run applications until the SGD server can re-establish contact with it.

Reliability of CPU and Memory Data

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 run 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 run applications if no other server is available or suitable.

Frequency of Updates to Array Members

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.

Editing Application Load Balancing Properties

You tune SGD application load balancing by editing application server load balancing properties. The properties are stored in a properties file, which you can edit with a text editor. There are three properties files, as follows:

Global properties file – This file contains the default settings for all the SGD servers in an array
Application server properties file – This file allows you to override some of the default settings in the global properties file for a particular application server
Load balancing service properties file – This file contains the settings the load balancing service uses when it is first started or restarted on a UNIX or Linux platform application server

This section describes how you edit the properties files and what properties are available. For detailed information on how to use the properties, see Tuning Application Load Balancing.

Caution - Edit these properties with care as it can cause applications to fail to start.

The Global Load Balancing Properties File

The global load balancing properties file contains the default load balancing properties for all the SGD servers in an array.

The file is /opt/tarantella/var/serverconfig/global/tier3lb.properties.

Caution - Only edit these properties on the primary SGD server in the array. The primary copies the amended properties file to the secondary servers.

In the tier3lb.properties properties file, the properties are prefixed with tarantella.config.tier3lb, for example tarantella.config.tier3lb.weighting.

The following table lists the properties you can change, and gives the default value of the property when SGD is first installed. The table also explains what each property is used for.

Property	Default Value	Purpose
`connectretries`	`3`	The number of times the SGD server tries to connect to the application server to request CPU and memory usage updates.
`listeningport`	`3579`	The UDP port the SGD server uses to listen for data sent by the load balancing service.
`longtimeout`	`900`	The pause in seconds between groups of attempts by the SGD server to connect to the application server.
`maxmissedsamples`	`20`	The number of missed samples used to calculate whether the CPU and memory data for the application server is too unreliable to be used.
`probe.listeningport`	`3579`	The TCP port the load balancing service uses to listen for requests from SGD servers, for example, when to start sending updates.
`probe.percentchange`	`10`	The minimum percentage increase or decrease in CPU and memory use that must be reported to the SGD server.
`probe.replyfrequency`	`30`	The interval in seconds at which the load balancing service sends CPU and memory measurements to the SGD server. The minimum value for this property is 2.
`probe.samplerate`	`15`	The interval in seconds between CPU and memory measurements. The minimum value for this property is 1.
`probe.windowsize`	`3`	The number of CPU and memory measurements used to calculate the CPU and memory average. The minimum value for this property is 1.
`scaninterval`	`60`	The interval in seconds between scans of the SGD server’s list of load-balanced application servers.
`shorttimeout`	`60`	The interval in seconds between attempts by the SGD server to connect to the application server.
`sockettimeout`	`5`	The socket timeout in seconds.
`updatelimit`	`5`	The limit used to calculate when the load balancing service has stopped sending updates.
`weighting`	`100`	The weighting of load measurements relative to the other application servers.

The following properties also appear in the tier3lb.properties properties file, but they must not be changed:

tarantella.config.type=server
tarantella.config.name=tier3lb

The Application Server Load Balancing Properties File

You can override some of the global load balancing properties by creating a load balancing properties file for a particular application server. You have to manually create this file as described in How to Create an Application Server Load Balancing Properties File.

The global properties you can override are the following:

probe.listeningport
probe.percentchange
probe.replyfrequency
probe.samplerate
probe.windowsize
weighting

In the server-specific properties file, the properties are prefixed with tarantella.config.tier3hostdata, for example tarantella.config.tier3hostdata.weighting.

How to Create an Application Server Load Balancing Properties File

Before You Begin

Ensure that no users are logged in to the SGD server, and that there are no application sessions, including suspended application sessions, running on the SGD server.

Log in as superuser (root) on the primary SGD server.

Caution - Only create the load balancing properties file on the primary SGD server in the array. The primary copies the file to the secondary servers.
Change to the /opt/tarantella/var/serverconfig/global/t3hostdata directory.
Create the load balancing properties file.
Copy the template.properties file to a file called hostname.properties in the same directory, where hostname is the name of the application server, for example, paris.indigo-insurance.com.properties.
Edit the load balancing properties file.
1. Open the properties file in a text editor.
2. Add the fully qualified name of the application server.
  Find the line containing the tarantella.config.tier3hostdata.name property.
  After the “=”, type the fully qualified name of the application server.
  Enclose the name in quotes and escape each part of the host name with a backslash. For example:
  ".../_ens/o\=Indigo Insurance/cn\=paris"
3. Configure the server-specific properties.
  Uncomment the lines, by deleting the “#”, that contain the properties you want to be override.
  Only uncomment the properties that you want to be different from the global defaults.
  Change the values of the properties you want to override.
  
  Tip - The template.properties file contains comments to help you create a server-specific file.
4. Save the changes and close the file.
Do a warm restart of the primary SGD server.
```
# tarantella restart sgd --warm
```

The Load Balancing Service Properties File

The load balancing service properties file contains the settings that are used when the load balancing service is first started, or whenever the service is restarted, on a UNIX or Linux platform application server.

Caution - Only make changes to these properties if you have been asked to by Oracle Support, or if you change the physical or virtual memory of the application server and you have not reinstalled the SGD Enhancement Module.

The load balancing services properties file is: /opt/tta_tem/var/serverconfig/local/tier3loadbalancing.properties.

If you change these properties, you must manually stop and restart the load balancing service.

The properties you can override are the following:

probe.listeningport
probe.percentchange
probe.replyfrequency
probe.samplerate
probe.windowsize
weighting

In the load balancing service properties file, the properties are prefixed with tarantella.config.tier3loadbalancing, for example tarantella.config.tier3loadbalancing.weighting.

Exit Print View
Oracle Secure Global Desktop Administration Guide for Version 4.6

Oracle Secure Global Desktop Administration Guide for Version 4.6

Load Balancing

User Session Load Balancing

Using The Load-Balancing JSP Technology Page to Distribute User Sessions

How to Configure the Load-Balancing JSP Technology Page to Distribute User Sessions

Before You Begin

Using an External Mechanism to Distribute User Sessions

How to Configure the Load-Balancing JSP Technology Page for an External Load Balancing Mechanism

Before You Begin

How to Configure the Load-Balancing JSP Technology Page for Use With My Desktop

Before You Begin

Additional Load-Balancing JSP Technology Page Configuration

Using Another Webtop

Localized Splash Screen

Other Variables

Application Session Load Balancing

Application Load Balancing

Defining the Application Servers to Run the Application

Selecting the Load Balancing Method

Load Balancing Groups

How Application Load Balancing Works

Dynamic Application Servers and Load Balancing

Application Server Availability

Application Server Filters

Load Balancing Groups

Server Affinity

The Relative Power of the Application Servers

Example Relative Power Calculation 1

Example Relative Power Calculation 2

The Application Server With the Least Load

Fewest Application Sessions

Example Load Calculation Using Fewest Application Sessions

Least CPU Usage

Example Load Calculation Using Least CPU Usage

Most Free Memory

Example Load Calculation Using Most Free Memory

How Advanced Load Management Works

Tuning Application Load Balancing

Application Server’s Relative Power

Load Balancing Listening Ports

SGD Requests Updates From an Application Server

Frequency of the Load Calculation

Frequency of Updates to the Primary SGD Server

Reliability of CPU and Memory Data

Frequency of Updates to Array Members

Editing Application Load Balancing Properties

The Global Load Balancing Properties File

The Application Server Load Balancing Properties File

How to Create an Application Server Load Balancing Properties File

Before You Begin

The Load Balancing Service Properties File