Secure Global Desktop 4.40 Administration Guide > SGD Servers, Arrays, and Load Balancing > Understanding Load Balancing

Understanding 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. With SGD you can use the following load balancing mechanisms:

The load balancing mechanisms are described in more detail in the following sections.

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:

• Round-robin or Dynamic DNS
• An external hardware load balancer
• Use the SGD load-balancing JavaServer page
• Allocate different SGD servers to different departments and give one URL to each department

See Load Balancing User Sessions for details on how to use the SGD load-balancing JavaServer page and how to use SGD with an external hardware load balancer.

Application Session Load Balancing

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

An application session requires a protocol engine. The protocol engine communicates with the user's client device and with the application server running the application. A protocol engine can run on any SGD server in the array and this is not necessarily the same server that hosts the user session.

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 SGD 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. This is the default.
• Least CPU Load - the SGD server that has the least CPU load.
• Fewest Application Sessions - the SGD server that is hosting the fewest application sessions.

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 the launch of applications so that the application servers achieve a similar relative workload.

Secure Global Desktop Administrators manage application load balancing centrally from the array as follows:

• Define the set of application servers that can run an application by assigning application servers to the application.

  In the SGD 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.

  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 SGD Administration Console, you can select and deselect the Application Start check box on the General tab for an application server. 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.

• Select the load balancing method that SGD uses to determine the most suitable application server for the user.

  In the SGD Administration Console, you configure a default load balancing method on the Global Settings » Performance tab which you can override for an individual application.

  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 launches an application. This is called Advanced Load Management and is described in detail in the following section.

See Configuring Application Load Balancing for details on how to load balance applications.

Using Advanced Load Management

The Advanced Load Management methods allow 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 launched. You can only load balance X applications, Windows applications and character applications using these methods.

To use Advanced Load Management, you must install a Sun Secure Global Desktop 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 whether an application server is available, 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 load balanced. 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 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 launch applications on the basis of the load information they receive in the updates.

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 the Adaptive Internet Protocol (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 runs on a Secure Global Desktop 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 SGD 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.

Copyright © 1997-2007 Sun Microsystems, Inc. All rights reserved.