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 Section 7.2.1, “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 Section 7.2.2, “Application Session Load Balancing” for details.
Application load balancing – Determines which application server runs an application for a user
See Section 7.2.3, “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 Section 7.2.4, “Load Balancing Groups” for details.
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
Allocate different SGD servers to different departments and give one 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 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. The supported mechanism for this is to use the SGD Gateway. The Gateway contains an Apache web server that manages the load balancing of HTTP connections to SGD.
The Gateway provides the best solution for load balancing user sessions. Instructions on how to install, configure, and use the Gateway are included in the Oracle Secure Global Desktop Gateway Administration Guide.
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 Section 1.2.3, “Configuring External DNS Name Connection Filters”.
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 hostname 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 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 Section 1.5.2, “Firewall Traversal”.
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 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 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.
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.
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 Section 7.2.5, “How Application Load Balancing Works” for details on how the load balancing method and other factors affect load balancing.
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.
To use load balancing groups, ensure that the Application Session Load Balancing attribute on the Global Settings, Performance tab is not set to Server Hosting the User Session. This is the default setting for the attribute.
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.
If a dynamic application server is configured for the application, the normal SGD mechanisms for application load balancing can be overridden. This is because some virtual server brokers (VSBs) allow users to choose where to run an application. See Section 4.5.1, “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 Section 7.2.5.2, “Application Server Availability” for detailsUser Assignment (
--userassign) – See Section 7.2.5.3, “Application Server Filters” for detailsMaximum Count (
--maxcount) – See Section 7.2.5.3, “Application Server Filters” for details
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 for an application server object 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 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
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 Section C.2.116, “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 |
The application server can only run
|
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 |
The application server can only run
|
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 |
The application server can only run
|
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 Section 7.2.4, “Load Balancing Groups” for more detail.
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.
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
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.
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 Section 7.2.7, “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 Section 7.2.5.7, “The Application Server With the Least Load”.
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.
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 Section 7.2.6, “How Advanced Load Management Works” for more details.
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
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).
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
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.
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
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.
Advanced Load Management enables you to load balance applications based on either the amount of free virtual 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.
NoteThe 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.
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 Section 7.2.8, “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:
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.
With the exception of tuning an application server's relative power, this tuning only applies if you are using Advanced Load Management.
The weighting property allows you to factor
in the relative power of the application servers to the
decision SGD takes as to where to run an
application. This is discussed in
Section 7.2.5.6, “The Relative Power of the Application Servers”.
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.
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.
The probe.samplerate and
probe.windowsize properties control how
often the load balancing service measures the application
server's average load.
For example, the probe.samplerate is 10
seconds and the probe.windowsize is 5.
After 50 seconds (5 x 10), the 5 measurements needed to
calculate the average have been taken. After a further 10
seconds, the load balancing service takes a new measurement,
discards the oldest measurement and then calculates a new
average load.
You can increase and decrease the frequency of the calculation depending on how often you expect the application server load to change. For example, if users start applications at the start of the day and then close them at the end of the day, you might want to decrease the frequency of the load calculation. However, if users repeatedly start and stop applications, you might want to increase the frequency of the load calculation.
The replyfrequency property controls the
interval at which the load balancing service send updates to
the primary SGD server.
The percentagechange property controls the
minimum percentage change in CPU 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.
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.
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.
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.
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 Section 7.2.7, “Tuning Application Load Balancing”.
Edit these properties with care as it can cause applications to fail to start.
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.
CautionOnly 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/t3hostdatadirectory.Create the load balancing properties file.
Copy the
template.propertiesfile to a file calledhostname.propertieshostnameis the name of the application server, for example,paris.example.com.properties.Edit the load balancing properties file.
Open the properties file in a text editor.
Add the fully qualified name of the application server.
Find the line containing the
tarantella.config.tier3hostdata.nameproperty.After the
=, enter the fully qualified name of the application server.Enclose the name in quotes and escape each part of the hostname with a backslash. For example:
".../_ens/o\=Example/cn\=paris"Configure the server-specific properties.
Uncomment the lines, by deleting the
#character, 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.
TipThe
template.propertiesfile contains comments to help you create a server-specific file.Save the changes and close the file.
Do a warm restart of the primary SGD server.
# tarantella restart sgd --warm
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.
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 |
|---|---|---|
|
| The number of times the SGD server tries to connect to the application server to request CPU and memory usage updates. |
|
| The UDP port the SGD server uses to listen for data sent by the load balancing service. |
|
| The pause in seconds between groups of attempts by the SGD server to connect to the application server. |
|
| The number of missed samples used to calculate whether the CPU and memory data for the application server is too unreliable to be used. |
|
| The TCP port the load balancing service uses to listen for requests from SGD servers, for example, when to start sending updates. |
|
| The minimum percentage increase or decrease in CPU and memory use that must be reported to the SGD server. |
|
| 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. |
|
| The interval in seconds between CPU and memory measurements. The minimum value for this property is 1. |
|
| The number of CPU and memory measurements used to calculate the CPU and memory average. The minimum value for this property is 1. |
|
| The interval in seconds between scans of the SGD server's list of load-balanced application servers. |
|
| The interval in seconds between attempts by the SGD server to connect to the application server. |
|
| The socket timeout in seconds. |
|
| The limit used to calculate when the load balancing service has stopped sending updates. |
|
| 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
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 Section 7.2.8.1, “How to Create an Application Server Load Balancing Properties File”.
The global properties you can override are the following:
probe.listeningportprobe.percentchangeprobe.replyfrequencyprobe.samplerateprobe.windowsizeweighting
In the server-specific properties file, the properties are
prefixed with
tarantella.config.tier3hostdata, for
example
tarantella.config.tier3hostdata.weighting.
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.
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.
See Section 7.7.3.7, “Tuning Memory Settings For UNIX and Linux Platform Application Servers”.
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 global properties you can override are the following:
probe.listeningportprobe.percentchangeprobe.replyfrequencyprobe.samplerateprobe.windowsizeweighting
In the load balancing service properties file, the properties
are prefixed with
tarantella.config.tier3loadbalancing, for
example
tarantella.config.tier3loadbalancing.weighting.