Exit Print View

Oracle Secure Global Desktop Administration Guide for Version 4.6

Document Information

Preface

1.  Networking and Security

2.  User Authentication

3.  Publishing Applications to Users

4.  Configuring Applications

5.  Client Device Support

6.  SGD Client and Webtop

7.  SGD Servers, Arrays, and Load Balancing

Arrays

The Structure of an Array

Replicating Data Across the Array

Communication Between Array Members

Secure Intra-Array Communication

Managing Arrays and SGD Servers

Array Resilience

How Array Resilience Works

Failover Stage

Recovery Stage

Examples of How Array Resilience Works

Primary Server Goes Down

Array Splits into Two Arrays

Configuring Arrays

How to Enable Secure Intra-Array Communication

How to Add a Server to an Array (Secure Intra-Array Communication Enabled)

How to Add a Server to an Array (Secure Intra-Array Communication Disabled)

How to Change the Primary Server in an Array

How to Remove a Server From an Array

How to Change the Cipher Suite for Secure Intra-Array Communication

Configuring Array Resilience

How to Enable Array Failover for an Array

How to Configure the Array Failover Grace Period

How to Show the Backup Primaries List for an Array

How to Add an Entry to the Backup Primaries List

How to Change the Position of an Entry in the Backup Primaries List

How to Delete an Entry From the Backup Primaries List

How to Configure the Find New Primary Timeout

How to Configure the Action When Failover Ends

How to Rebuild an Array Manually

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

Using an External Mechanism to Distribute User Sessions

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

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

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

The Load Balancing Service Properties File

SGD Web Server and Administration Console

Introducing the SGD Web Server

Securing the SGD Web Server

The httpd.conf.secure File

Using the Administration Console

Supported Browsers for the Administration Console

Starting the Administration Console

Deploying the Administration Console on Other Web Application Containers

Avoiding SGD Datastore Update Problems

Performing Array Operations Using the Administration Console

Administration Console Configuration Settings

Number of Search Results

Synchronization Wait Period

Searching and Displaying LDAP Data

Session Timeout

Securing Access to the Administration Console

Monitoring and Logging

The SGD Datastore

User Sessions and Application Sessions

User Sessions

Idle User Session Timeout

Application Sessions

Anonymous Users and Shared Users

Using Log Filters to Troubleshoot Problems With an SGD Server

Selecting a Component and Subcomponent

Selecting the Severity

Using Wildcards

Selecting a Destination

Using Log Files

Using Log Handlers

Examples of Using Log Filters

Viewing Log Output

Using Log Filters for Auditing

Viewing Audit Log Information

Examples of Using Log Filters for Auditing

Using Log Filters to Troubleshoot Problems With Protocol Engines

Examples of Using PE Log Filters

PE Log File Destinations

Viewing PE Log Output

Resetting a PE Log Filter

SGD Web Server Logging

Tomcat JSP Technology Container Logs

Apache Web Server Logs

SGD Client Logging

SGD Server Certificate Stores

The CA Certificate Truststore

How to Import CA Certificates or Certificate Chains into the CA Certificate Truststore

The Client Certificate Store

How to Create a Client Certificate CSR for an SGD Server

How to Install a Client Certificate for an SGD Server

SGD Installations

About Your SGD Installation

bin Directory

etc Directory

lib Directory

var Directory

webserver Directory

Backing Up and Restoring an SGD Installation

How to Make a Full Backup of an SGD Installation

Restoring a Damaged SGD Component

Binaries, Scripts, and Template Files

Login Scripts

Server Configuration

Global Configuration

The Local Repository

Automatic Log Archives

SGD Printing

SGD Web Server, Web Services, and the Webtop

How to Do a Full Restore of an SGD Installation

Troubleshooting Arrays and Load Balancing

Troubleshooting Array Resilience

Showing Status Information For an SGD Array

Enabling Array Resilience Logging

Troubleshooting Clock Synchronization Issues

Troubleshooting Advanced Load Management

The Load Balancing Service Is Not Working

SGD Ignores an Application Server Load Balancing Properties File

One of the Application Servers Is Never Picked

One of the Application Servers Is Always Picked

Two Identical Application Servers, But One Runs More Applications Than the Other

The SGD Server Log File Shows an Update Received for an Unknown ID

SGD Uses Too Much Network Bandwidth

Users Cannot Connect to an SGD Server When It Is In Firewall Traversal Mode

Users Cannot Relocate Their Sessions

A.  Global Settings and Caches

B.  Secure Global Desktop Server Settings

C.  User Profiles, Applications, and Application Servers

D.  Commands

E.  Login Scripts

F.  Third-Party Legal Notices

Glossary

Index

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

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:

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:

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 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:

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

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:

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.

  1. Log in as superuser (root) on the primary SGD server in the array.
  2. 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.


  3. 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.
  4. 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:

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:

  1. Users make HTTPS connections to the load balancer DNS name.

  2. The load balancer decrypts the SSL request and forwards it as an HTTP request to the external DNS name of the selected SGD server.

  3. 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:

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.

  1. Log in as superuser (root) on the SGD host.
  2. 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.


  3. 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.
  4. 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.

  1. Log in as superuser (root) on the SGD host.
  2. 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.


  3. 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
  4. 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.
    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:

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:

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:

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:

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:

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 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:


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:

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

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

Caution

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:

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:

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.


  6. 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:

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

This tuning is described in the following sections.


Caution

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:

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

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

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:

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.

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

    Caution

    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.


  2. Change to the /opt/tarantella/var/serverconfig/global/t3hostdata directory.
  3. 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.

  4. 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.
  5. 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

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:

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