3. Publishing Applications to Users
7. SGD Servers, Arrays, and Load Balancing
Replicating Data Across the Array
Communication Between Array Members
Secure Intra-Array Communication
Managing Arrays and SGD Servers
Examples of How Array Resilience Works
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
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
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
Application Session Load Balancing
Defining the Application Servers to Run the Application
Selecting the Load Balancing Method
How Application Load Balancing Works
Dynamic Application Servers and Load Balancing
Application Server Availability
The Relative Power of the Application Servers
Example Relative Power Calculation 1
Example Relative Power Calculation 2
The Application Server With the Least Load
Example Load Calculation Using Fewest Application Sessions
Example Load Calculation Using Least CPU Usage
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
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
User Sessions and Application Sessions
Anonymous Users and Shared Users
Using Log Filters to Troubleshoot Problems With an SGD Server
Selecting a Component and Subcomponent
Using Log Filters for Auditing
Examples of Using Log Filters for Auditing
Using Log Filters to Troubleshoot Problems With Protocol Engines
Examples of Using PE Log Filters
Tomcat JSP Technology Container Logs
How to Import CA Certificates or Certificate Chains into the CA Certificate Truststore
How to Create a Client Certificate CSR for an SGD Server
How to Install a Client Certificate for an SGD Server
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
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
B. Secure Global Desktop Server Settings
This section contains information about the web server that is included with SGD and the SGD Administration Console..
This section includes the following topics:
When you install SGD, the SGD web server is also installed. The SGD web server is preconfigured for use with SGD. The components included with the SGD web server are listed in the Oracle Secure Global Desktop 4.6 Platform Support and Release Notes available at http://docs.sun.com/app/docs/doc/821-1928.
If you have an existing web server on the SGD host, this is not affected by the SGD web server, as the SGD web server listens on a different port.
You can configure the SGD web server using standard Apache directives. See the Apache documentation for details.
You can control the SGD web server independently of the SGD server, using the tarantella start webserver, tarantella stop webserver, and tarantella restart webserver commands.
By default, the SGD web server is configured to be a secure HTTPS web server and to share the SGD server SSL certificate used for SGD security services.
Directory indexes are disabled by default for the SGD web server. This means that users cannot browse the directories on the SGD web server.
If you require enhanced security, a more secure version of the httpd.conf Apache
configuration file used by the SGD web server is supplied. See The httpd.conf.secure File for
more details about this file.
The httpd.conf.secure file is an Apache server configuration file that configures the SGD web server for enhanced security. The file is included with the SGD distribution, at /opt/tarantella/webserver/apache/apache-version/conf/httpd.conf.secure on the SGD host.
The httpd.conf.secure file provides the following additional security features, compared to the standard httpd.conf file used by the SGD web server:
Apache modules that are not used by SGD are disabled
Access to the /cgi-bin directory on the SGD web server is not allowed
To use httpd.conf.secure on an SGD server that has previously been secured, you
must first disable security on the SGD server, before installing the httpd.conf.secure file. You
can then enable security services for the SGD server, as described in Secure Connections to SGD Servers.
![]() | Caution - Do not use httpd.conf.secure if you have used the tarantella security enable command to configure security automatically on the SGD server. |
This section describes how to run the Administration Console. It also includes details of how to avoid some common problems when using the Administration Console.
To display the Administration Console, you can use a supported browser. The browser must have the JavaScript programming language enabled. The supported browsers are listed in the Oracle Secure Global Desktop 4.6 Platform Support and Release Notes available at http://docs.sun.com/app/docs/doc/821-1928.
![]() | Caution - When using the Administration Console, do not use the browser’s Back button. Instead, use the Jump to Object View and Jump to Navigation View links, or the Object History list, to navigate through the Administration Console pages. |
The Administration Console works best when you run it on the primary SGD server in the array.
You can start the Administration Console in the following ways:
Click the Administration Console link on the webtop of an SGD Administrator.
Click the Launch the Oracle Secure Global Desktop Administration Console link on the SGD web server Welcome Page at http://server.example.com, where server.example.com is the name of an SGD server.
Go to the http://server.example.com/sgdadmin URL.
Note - The Administration Console is for SGD Administrators only. To use the Administration Console you must log in as, or be logged in as, an SGD Administrator.
The Administration Console is only supported when used with the SGD web server.
The Administration Console ships with a web application archive (WAR) file, sgdadmin.war. Using this file to redeploy the Administration Console on another web application server is not supported.
You can perform operations on the SGD datastore, such as creating new objects and editing object attributes, using the Administration Console from any SGD server in the array.
When you edit the SGD datastore, the changes you make are sent to the primary SGD server. The primary SGD server then replicates these changes to all secondary servers in the array.
By running the Administration Console from the primary SGD server, you can avoid problems due to the following:
Slow network. If the network is slow, “Object not found” or “Object not created” errors can be returned. Also, problems with stale data can occur, where configuration changes are not shown correctly.
Primary down. If the primary server is down, or unavailable, SGD datastore changes are not applied.
The following limitations apply when using the Administration Console to perform array operations, such as array joining or array detaching:
Use the primary SGD server. Running the Administration Console on the primary server avoids data replication problems. See also Avoiding SGD Datastore Update Problems.
All servers involved in an array operation must be up. For example, you cannot use the Administration Console to detach a secondary server that is down. Instead, use the tarantella array detach command.
Clocks must be synchronized on all servers involved in an array operation. For example, you cannot add a secondary server if its clock is out of synchronization by more than a minute. You can use NTP software or the rdate command to ensure the clocks on all SGD hosts are synchronized.
The deployment descriptor for the Administration Console web application contains settings that control the operation of the Administration Console. The deployment descriptor is the following file:
/opt/tarantella/webserver/tomcat/tomcat-version/sgdadmin/WEB-INF/web.xml
This section describes the settings in the deployment descriptor that you might want to configure. Most of the settings are context parameters, contained in <context-param> elements. You must not change any other settings in the web.xml file.
When working with deployment descriptor settings, note the following:
Only change web.xml if you understand what you are doing.
Always create and keep a backup of the original web.xml, in case you need to revert to a previous version. See Backing Up and Restoring an SGD Installation for advice on how to do this.
After changing web.xml, you must always restart the SGD web server for the changes to take effect.
Changes to web.xml only apply for the server that is hosting the Administration Console.
You must not change the order of the Extensible Markup Language (XML) elements contained in web.xml.
The com.sun.tta.confmgr.DisplayLimit context parameter enables you to configure the maximum number of search results you can display in the Administration Console. The default is 150. If there are more results than the display limit, the Administration Console displays a message. Increasing the display limit can have an effect on performance. Set the display limit to 0 to see unlimited search results.
The com.sun.tta.confmgr.ArraySyncPeriod context parameter is only used if you are running the Administration Console from a secondary server, and you create or edit objects in the SGD datastore. This parameter enables you to configure the period of time, in milliseconds, that the Administration Console waits for changes to be copied across the array before proceeding. The default value is 250. The Administration Console waits for twice this setting, a default of 0.5 seconds, before proceeding.
The com.sun.tta.confmgr.LdapSearchTimeLimit context parameter enables you to configure the maximum time, in milliseconds, to allow for a search of a Lightweight Directory Access Protocol (LDAP) directory. The default is 0, which means the search time is unlimited. Only change this context parameter if you have particularly slow LDAP directory servers.
The following context parameters are used to filter the display of LDAP data, when you select Local + LDAP in the Repository list in the Administration Console:
Filters used by the navigation tree. These are the following context parameters:
com.sun.tta.confmgr.LdapContainerFilter
com.sun.tta.confmgr.LdapUserFilter
com.sun.tta.confmgr.LdapGroupFilter
Filters used when you search an LDAP directory. These are the following context parameters:
com.sun.tta.confmgr.LdapContainerSearchFilter
com.sun.tta.confmgr.LdapUserSearchFilter
com.sun.tta.confmgr.LdapGroupSearchFilter
Filters used when you load the LDAP assignments on the Assigned Applications tab for a user profile. This is the com.sun.tta.confmgr.LdapMemberFilter context parameter.
These context parameters contain the definitions of what the Administration Console considers as LDAP containers, users, and groups. You might want to change these filters to improve performance, or to change the definition of these LDAP object types to match those used in your LDAP directory. To avoid inconsistencies, if you change a filter for the navigation tree, you must also change the filter used for the LDAP search.
The session-timeout setting defines the period of time after which the user is logged out if there is no activity, meaning no HTTP requests, in the Administration Console. The default setting is 30 minutes, to ensure unattended Administration Console sessions are not left open indefinitely.
Note - The session-timeout setting is independent of the timeout attribute for inactive user sessions, tarantella-config-array-webtopsessionidletimeout.
Because the Administration Console is a web application, you can control which client devices are allowed to access it.For example, you can do this by configuring the SGD web server to use the Apache <Location> directive, as in the following example:
<Location /sgdadmin> Order Deny,Allow Deny from all Allow from 129.156.4.240 </Location>
In this example, only client devices with an IP address of 129.156.4.240 are allowed to access the /sgdadmin directory on the SGD web server. The /sgdadmin directory contains the home page of the Administration Console.
For more information on how to configure the <Location> directive, check the Apache documentation.