| Exit Print View | |
Oracle Secure Global Desktop Administration Guide for Version 4.6 |
|
|
|
|
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
Application Session Load Balancing
How Application Load Balancing Works
How Advanced Load Management Works
Tuning Application Load Balancing
Editing Application Load Balancing Properties
SGD Web Server and Administration Console
Introducing the SGD Web Server
Using the Administration Console
Administration Console Configuration Settings
Securing Access to the Administration Console
User Sessions and Application Sessions
Using Log Filters to Troubleshoot Problems With an SGD Server
Using Log Filters for Auditing
Using Log Filters to Troubleshoot Problems With Protocol Engines
Backing Up and Restoring an SGD Installation
Troubleshooting Arrays and Load Balancing
Troubleshooting Array Resilience
Troubleshooting Clock Synchronization Issues
Troubleshooting Advanced Load Management
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
In SGD, an array is a collection of SGD servers that share configuration information.
Arrays have the following benefits:
Users and application sessions are load-balanced across the array. To scale to more users, simply add more SGD servers to the array. See 
Load Balancing for more details.
With more than one server, there is no single point of failure. You can decommission a server temporarily with the minimum of disruption to your users.
Configuration information, including all the objects in your organizational hierarchy, is replicated to all array members. All array members have access to all information.
Users see the same webtop and can resume applications, no matter which SGD server they log in to.
This section includes the following topics:
An array contains the following:
One primary server. This server is the authoritative source for global SGD information, and maintains the definitive copy of the organizational hierarchy, called the local repository.
One or more secondary servers. The primary server replicates information to these servers.
A single, standalone server is considered to be the primary server in an array with no secondary servers.
SGD servers in an array might run different operating systems. However, all the array members must run the same version of SGD.
As the SGD servers in an array share information about user sessions and application sessions, it is important to synchronize the clocks on the SGD hosts. Use Network Time Protocol (NTP) software, or the rdate command, to ensure the clocks on all SGD hosts are synchronized.
When the primary server replicates data to the secondary servers, it replicates the following data:
The local repository
Session information
Configuration information, including global configuration
Client profiles created by SGD Administrators
User preferences created by SGD users from the webtop
The application server password cache
The token cache
Resource files, such as application server login scripts
Apart from the resource files, any changes to the above data are replicated immediately.
The synchronization of resource files occurs once daily, and only while the servers are running. The resource files that are synchronized are the files from the /opt/tarantella/var/serverresources directory. Only add, modify, or delete the files in these directories on the primary server.
The time and effort that it takes to synchronize an array is directly proportional to the size of the array.
Resource synchronization can be scheduled to take place at a time of your choice. In the Administration Console, this is configured with the Daily Resource Synchronization Time attribute on the Performance tab for each SGD server.
In the array, each SGD server has a peer Domain Name System (DNS)
name and one or more external DNS names. SGD servers always use peer
DNS names to communicate with each other. You also use peer DNS names
when specifying array members in the SGD configuration tools. External DNS names are
only used by SGD Clients when connecting to SGD servers. See DNS Names more details.
Connections between the SGD servers in an array are made on Transmission Control
Protocol (TCP) port 5427. Unless explicitly enabled, this connection is not encrypted. The
connection between SGD servers in an array can be encrypted by using secure
intra-array communication. See Secure Intra-Array Communication.
Each server in the array has a record of the peer DNS names of all the SGD servers in an array. A server only accepts connections on TCP port 5427 if the following occurs:
The connection is from an array member, according to its own records.
A shared secret, known only to array members, is used to authenticate connections between array members. Secret Key Identification (SKID) authentication is used. SKID authentication does not encrypt the data.
Most connections are made from the primary server to a secondary server. These connections replicate data to keep the array synchronized. However, array members must be able to communicate directly with other array members.
In a standard installation, the data transmitted between the SGD servers in an array is not encrypted. SGD Administrators can secure the connections between array members using SSL. Using SSL for these connections ensures the integrity of the data as follows:
Communication only takes place between SGD servers that have authenticated to each other
Data is encrypted before transmission
Data can be checked to ensure that it has not changed during transmission
Using SSL in this way is known as secure intra-array communication.
Secure intra-array communication can only be enabled on an SGD server that is
not joined with other SGD servers in an array. When secure intra-array communication
is enabled for an array, an SGD server can only join the array
if it also has secure intra-array communication enabled. See How to Enable Secure Intra-Array Communication for details.
Using secure intra-array communication means that each SGD server in the array has to have a valid SSL certificate that has been signed by a trusted certificate authority (CA).
As the SSL certificates used for secure intra-array communication are used only internally by SGD, the primary SGD server in the array acts as the CA. The primary SGD server has a self-signed CA certificate and a private key. All secondary SGD servers in the array have a copy of the primary SGD server’s CA certificate in a trusted certificate store, the truststore.
All SGD servers in the array, including the primary, have an SSL certificate and a private key. The SSL certificate is signed with the primary SGD server’s CA certificate and contains a common name (CN) which is the peer DNS name of the SGD server. As the SSL certificates are created using a self-signed CA certificate, they cannot be used to secure any other SGD-related connection. These certificates are referred to as peer SSL certificates to distinguish them from other types of SSL certificates.
When one SGD server in the array connects to another, including when using an administration tool, the SGD server being connected to presents its peer SSL certificate as part of the SSL negotiation. The connecting server evaluates the peer SSL certificate and checks the following:
The CN of the certificate matches the peer DNS name of the connecting server
The expiry date of the certificate
The issuer of the certificate, which must be the CA certificate of the primary
If the peer SSL certificate is valid, a secure connection is established.
When you enable secure intra-array communication, SGD automatically generates and distributes the CA and peer SSL certificates to the members of the array. Whenever there is a change in the array structure, SGD automatically updates the CA and peer SSL certificates. The following table summarizes what happens.
|
SGD Administrators can use the tarantella security peerca --show command to view certificates in the truststore. The truststore contains the primary SGD server’s CA certificate.
By default, SGD uses the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite for secure intra-array communication. For
details on how to change the cipher suite, see How to Change the Cipher Suite for Secure Intra-Array Communication.
You add and remove SGD servers from an array using Secure Global Desktop Servers tab in the Administration Console or by using the tarantella array command. It is best to perform all array operations on the primary SGD server in the array. For details on configuring arrays, see the following:
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)
In the Administration Console, the attributes on the Global Settings tabs are the
settings that apply to the array as a whole, for example how users
authenticate to SGD. Appendix A, Global Settings and Caches has details of all the global settings. If you
click the name of an SGD server on the Secure Global Desktop Servers
tab, you display the attributes that apply only to that SGD server, for
example the server’s external DNS names. Appendix B, Secure Global Desktop Server Settings has details of all the
server-specific settings.
On the command line, you list and edit global settings or server-specific settings using the tarantella config command.
Array resilience is a feature where the loss of the primary server in an SGD array is handled automatically. The primary server can become unavailable either because of network problems, or because the SGD server goes down.
This section includes the following topics:
Array resilience consists of the following stages:
Failover stage. When the primary server becomes unavailable, the array is reconfigured automatically into one or more arrays, each with their own primary server. See Failover Stage.
Recovery stage. When the original primary server becomes available, the original array formation is recreated. This can be done automatically or manually. See Recovery Stage.
If array failover is enabled for an array, the failover stage starts automatically after the primary server has been unavailable for a user-configurable time period, called the grace period. The default grace period is 10 minutes.
The grace period is calculated from the values for the Monitor Interval (--array-monitortime) and Monitor Attempts (--array-maxmonitors) attributes, as follows:
Grace period = Monitor Interval x Monitor Attempts
Using the default settings:
Grace period = 60 seconds x 10 = 600 seconds, or 10 minutes
The failover stage uses the backup primaries list to select a secondary server to promote to be the new primary server in the array. The backup primaries list is a list of secondary servers for the array, with the priority decreasing from top to bottom. If available, the highest priority secondary server in this list is contacted and promoted to be the new primary server for the array.
The new primary server must be contacted within a time period called the find new primary timeout. If the new primary cannot be contacted during this timeout period, the next server in the backup primaries list is contacted.
The find new primary timeout period is calculated from the values for the Find Primary Interval (--array-resubmitfindprimarywait) and Find Primary Attempts (--array-resubmitfindprimarymax) attributes, as follows:
Find new primary timeout = Find Primary Interval x Find Primary Attempts
Using the default settings:
Find new primary timeout = 60 seconds x 3 = 180 seconds, or 3 minutes
Only SGD servers that are in the backup primaries list can be selected for promotion to be the new primary server.
When you build an SGD array, a backup primaries list is created for you automatically. If you add a secondary server to the array, an entry is added at the end of the list. If you remove a secondary server from the array, the entry for the server is removed from the list.
The backup primaries list is stored on each SGD server in the array. Any changes made to the list are copied to each SGD server in the array.
If the backup primaries list is empty, all SGD servers in the array become standalone servers after array failover.
When the failover stage has completed, the array is said to be in a repaired state.
The tarantella status command indicates if an array is in a repaired state. You
can use the --originalstate option of this command to list the members of
the array before it was repaired. See Showing Status Information For an SGD Array for more details about
using tarantella status to display status information for an array.
 | Caution - During the failover stage, do not change the array formation, or any array resilience settings. The original array formation might not be recreated successfully by the recovery stage if you do so. |
If the original primary server becomes available when the array is in a repaired state, the recovery stage starts automatically.
By default, the recovery stage restores the original primary server as the primary server for the array. You can use the Action When Failover Ends (--array-primaryreturnaction) attribute to determine how the array is reconfigured during the recovery stage.
In some situations after using array resilience you might have to rebuild an array manually. This is called manual recovery.
For example, if the recovery stage has failed to recreate the original array formation automatically you can rebuild the original array manually, starting from single, standalone SGD servers. You use the tarantella array clean command to do this.
| Caution - After you run tarantella array clean on the primary server in an SGD array, the secondary servers will not be able to contact the primary server. |
If an array splits into more than two arrays during the failover stage, the original array formation cannot be recreated automatically. Manual recovery must be used.
There are many possible array resilience scenarios, where the primary server becomes unavailable for one or more servers in the SGD array. This section includes examples of how array resilience works in the following scenarios:
In the following examples, the domain example.com has a four-node array of SGD servers:
Primary server – boston
Secondary servers – newyork, detroit, seattle
Original Network Configuration shows the original network configuration before using array resilience.
A typical sequence of events for array resilience when the primary server in an SGD array goes down is as follows:
The primary server, boston, goes down and is unavailable to any of the secondary servers in the array.
If boston is still unavailable after the grace period has elapsed, the failover stage begins.
The first available secondary server from the array’s backup primaries list is promoted to be the new primary server for the array.
Each of the existing secondary servers are reconfigured automatically to work with the new primary server. The array becomes a three-node array. The array is now in a repaired state.
Network Configuration After the Failover Stage When the Primary Server Goes Down shows the network configuration after the failover stage.
When boston becomes available again, the recovery stage begins. By default, boston automatically rejoins the array as the primary server.
The other servers in the array are reconfigured automatically to work with the new primary server, boston.
A typical sequence of events for array resilience when an SGD array splits into two arrays is as follows:
Because of network problems, the primary server, boston, can only contact the newyork secondary server. The remaining secondary servers in the array, seattle and detroit, cannot be contacted.
After the grace period has elapsed, if the primary server still cannot contact seattle and detroit, the failover stage begins.
The original array remains as a four-node array, but with the seattle and detroit servers reported as uncontactable in the array. The same primary server, boston, is used but the original array now has only a single contactable secondary server, newyork.
The secondary servers seattle and detroit can contact each other. These servers join to form a new two-node array. The first available secondary server from the backup primaries list is promoted to be the primary server for this array.
Network Configuration After the Failover Stage When the Array Splits into Two Arrays shows the network configuration after the failover stage.
Network problems are fixed. The recovery stage begins. By default, the two arrays join together. The original array formation is recreated automatically, with boston as the primary server.
Configuring an array involves the following steps:
Add SGD servers to the array.
Before building an array, you might want to enable secure intra-array communication, How to Enable Secure Intra-Array Communication.
How you add servers to an array depends on whether or not you are using secure intra-array communication, see the following:
Change the structure of an array.
See the following:
(Optional) Change the cipher suite used for secure intra-array communication.
See How to Change the Cipher Suite for Secure Intra-Array Communication.
Secure intra-array communication can only be enabled on an SGD server that is not joined with other SGD servers in an array.
Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.
You can only enable secure intra-array communication from the command line.
Log in as superuser (root) on the SGD server.
Stop the SGD server.
Enable secure intra-array communication.
Use the following command:
# tarantella config edit \ --tarantella-config-security-peerssl-enabled 1
Start the SGD server.
When secure intra-array communication is enabled for an array, an SGD server can only join the array if it also has secure intra-array communication enabled.
The clock on the server joining the array must be in synchronization with the clocks on the other servers in the array. If the time difference is more than one minute, the array join operation fails.
Log in to the SGD server that you want to add to the array.
Display the fingerprint of the SGD server’s CA certificate.
Use the following command:
$ tarantella security peerca --show
Make a note of the fingerprint of the SGD server’s CA certificate.
Log in to the primary SGD server in the array.
Join the SGD server to the array as a secondary server.
Use the following command to add the SGD server.
$ tarantella array join --secondary serv
It is best to use a fully-qualified DNS name for serv.
You are prompted to trust the secondary SGD server’s CA certificate, and the fingerprint of the certificate is displayed.
Check that the fingerprint is correct and complete the array join.
Check that the certificate fingerprint matches the fingerprint displayed in Step 2. This is
important as it verifies that the primary SGD server is communicating with the
genuine secondary SGD server.
If the fingerprints match, complete the array join by accepting the secondary SGD server’s CA certificate.
Check the status of the array.
Use the tarantella status command to check the status of the array.
The server joining the array must be a standalone server. In other words, the server must be in an array on its own.
Ensure that the clock on the server joining the array is in synchronization with the clocks on the other servers in the array. If the time difference is more than one minute, the add server operation fails.
Log in to the Administration Console on the primary SGD server.
Go to the Secure Global Desktop Servers tab.
In the Secure Global Desktop Server List, click the Add button.
The Add a Secure Global Desktop Server screen is displayed.
Tip - You can also use the tarantella array join command to add an SGD server to an array.
Enter the DNS name of an SGD server in the DNS Name field.
You must use a fully-qualified DNS name.
Enter the user name and password of an SGD Administrator in the User Name and Password fields.
Click Add.
The Secure Global Desktop Servers tab is displayed.
The Secure Global Desktop Servers tab shows messages advising you to wait for the server change and synchronization processes to complete.
Note - After making a change to the structure of an array, wait until SGD has copied the changes to all the SGD servers in the array before making any further changes. Run the tarantella status command on the primary SGD server to check the status of the array.
If the server you add has been load balancing application servers using Advanced
Load Management, you must do a warm restart, tarantella restart sgd --warm, of the new server
after it has joined the array. See also How Advanced Load Management Works.
Log in to the Administration Console on the primary SGD server.
Go to the Secure Global Desktop Servers tab.
In the Secure Global Desktop Server List, click the Make Primary button.
Tip - You can also use the tarantella array make_primary command to change the primary server in an array.
When prompted, click OK.
The Secure Global Desktop Servers tab shows messages advising you to wait for the server change and synchronization processes to complete.
The previous primary server becomes a secondary server.
Note - After making a change to the structure of an array, wait until SGD has copied the changes to all the SGD servers in the array before making any further changes. Run the tarantella status command on the primary SGD server to check the status of the array.
To remove the primary server from an array, you must first make another server the primary server and then remove the old primary server.
Log in to the Administration Console on the primary SGD server.
Go to the Secure Global Desktop Servers tab.
In the Secure Global Desktop Server List, click the Remove button.
Tip - You can also use the tarantella array detach command to remove an SGD server from an array.
When prompted, click OK.
The Secure Global Desktop Servers tab shows messages advising you to wait for the server change and synchronization processes to complete.
Note - After making a change to the structure of an array, wait until SGD has copied the changes to all the SGD servers in the array before making any further changes. Run the tarantella status command on the primary SGD server to check the status of the array.
Ensure that no users are logged in to the SGD servers in the array and that there are no running application sessions, including suspended application sessions.
Stop all the SGD servers in the array.
Log in as superuser (root) on the primary SGD server in the array.
Specify the cipher suite.
Use the following command:
# tarantella config edit \ --tarantella-config-security-peerssl-ciphers cipher-suite
where cipher-suite is the JSSE name of a cipher suite.
The following table lists the available cipher suites.
|
The default setting is TLS_RSA_WITH_AES_128_CBC_SHA.
Start all the SGD servers in the array.
Configuring array resilience involves the following steps:
Enable array failover for the array.
Array failover is disabled by default for an SGD array.
(Optional) Configure the array failover grace period.
Array failover starts automatically after the grace period has elapsed.
(Optional) Configure the backup primaries list.
The backup primaries list determines which secondary server is promoted to be the new primary server.
For more details, see the following:
(Optional) Configure the find new primary timeout period.
If the new primary cannot be contacted during this timeout period, the next server in the backup primaries list is contacted.
(Optional) Configure the recovery stage.
By default, the recovery stage recreates the original array formation automatically when the original primary server becomes available.
You can use manual recovery to recreate the original array formation manually.
In the Administration Console, go to the Global Settings -> Resilience tab.
Enable array failover for the SGD array.
Select the Array Failover check box.
Tip - You can also use the tarantella config edit command to enable the Array Failover (--array-failoverenabled) attribute.
In the Administration Console, go to the Global Settings -> Resilience tab.
Configure the grace period.
Type values for the Monitor Interval and Monitor Attempts attributes.
For example, to change the grace period to 120 seconds, or 2 minutes, set the Monitor Interval attribute to 60 and the Monitor Attempts attribute to 2.
The default grace period is 10 minutes.
Tip - You can also use the tarantella config edit command to configure the Monitor Interval (--array-monitortime) and Monitor Attempts (--array-maxmonitors) attributes.
In the Administration Console, go to the Global Settings -> Resilience tab.
View the entries in the backup primaries list.
The Backup Primaries table shows the backup primaries list for the array.
Tip - You can also use the tarantella array list_backup_primaries command to show the backup primaries list for an array.
In the Administration Console, go to the Global Settings -> Resilience tab.
Add an entry to the backup primaries list.
Click the New button in the Backup Primaries table.
The Available Secondaries table is displayed, showing the available secondary servers that are not in the backup primaries list.
Select a server in the Available Secondaries table and click Add.
The Backup Primaries table is updated automatically.
Tip - You can also use the tarantella array add_backup_primary command to add an entry to the backup primaries list.
In the Administration Console, go to the Global Settings -> Resilience tab.
Change the position of an entry in the backup primaries list.
Select the server in the Backup Primaries table and click Move Up or Move Down.
Tip - You can also use the tarantella array edit_backup_primary command to change the position of an entry in the backup primaries list.
In the Administration Console, go to the Global Settings -> Resilience tab.
Delete an entry in the backup primaries list.
Select the server in the Backup Primaries table and click Delete.
Tip - You can also use the tarantella array remove_backup_primary command to delete an entry from the backup primaries list.
In the Administration Console, go to the Global Settings -> Resilience tab.
Configure the find new primary timeout period.
Type values for the Find Primary Interval and Find Primary Attempts attributes.
For example, to change the find new primary timeout to 60 seconds, or 1 minute, set the Find Primary Interval attribute to 60 and the Find Primary Attempts attribute to 1.
The default find new primary timeout period is 3 minutes.
Tip - You can also use the tarantella config edit command to configure the Find Primary Interval (--array-resubmitfindprimarywait) and Find Primary Attempts (--array-resubmitfindprimarymax) attributes.
In the Administration Console, go to the Global Settings -> Resilience tab.
Configure how the array is reconfigured when the original primary server becomes available.
Select the required option for the Action When Failover Ends attribute.
To accept the original primary server back into the array as the primary server, select the Restore original primary option.
The original primary server, and any attached secondary servers, rejoin the array. The original primary server is restored as the primary server for the array. The current primary server becomes a secondary server. This is the default setting.
To exclude the original primary server from the array, select the Do not restore original array option.
The original primary server, and any attached secondary servers, do not rejoin the array. The original primary server, and any attached secondary servers, stay in the state they were in after the failover stage.
To accept the original primary server back into the array as a secondary server, select the Restore array with a new primary option.
The original primary server, and any attached secondary servers, rejoin the array as secondary servers.
Tip - You can also use the tarantella config edit command to configure the Action When Failover Ends (--array-primaryreturnaction) attribute.
Remove all array state information.
Run the following command on each SGD server in the array.
$ tarantella array clean
By default, the tarantella array clean command deletes all array information and configures the SGD server as a single, standalone server. Use the --contactmembers option of this command if you want the SGD server to remain in an array with other SGD servers that are contactable and that report the same array membership.
Rebuild the array manually.
Use the tarantella array command. See Managing Arrays and SGD Servers for details of how to do
this.
|
|
