Technical Notes

Overview of Load Balancing in Reflection for the Web
Technical Note 1510
Last Reviewed 28-Sep-2007
Applies To
Reflection for the Web version 7.0 through 9.01
Summary

This technical note outlines some of the factors to consider when you want to provide load balancing support in your Reflection for the Web environment. The information provided is a general overview; the specifics for your environment may vary.

Note: Beginning in version 9.5, use server replication for load balancing. For more information, see Technical Note 2174.

Overview

This technical note covers the following topics:

• Sample configuration designed to support load balancing support.
• General steps for installing Reflection for the Web to support load balancing.
• Maintenance tips.
• Basic overview of how Reflection for the Web connects to a host with and without a security proxy server.

Load Balancing Support Sample Configuration

In our example, providing load balancing support requires that a front-end device (for example, a load balancer, domain name server, proxy server, firewall, router, or switch) be added to the network. This device (named MyFrontEndDevice in this example) determines to which server a client will connect (named MyServerNameA and MyServerNameB in this example.) The servers below represent either web servers or security proxy servers. Either server or both can be load balanced.

1. Client computer connects to MyFrontEndDevice.
2. Front-end device determines with which identical server, MyServerName A or MyServerName B, a client will communicate based on load balancing rules. (For specific configuration options, refer to the front-end device's documentation.)
3. MyServerName A and MyServerName B are configured identically to provide load balancing. The common name in the certificate on each server must match the name of the front-end device. The name of the front-end device can be the fully qualified name, the NetBIOS name, or the ip address of the device, depending on how the device is being accessed.

Note: For details about how Reflection for the Web connects to a host and how certificates are used, see subsequent sections, Connecting to a Host and Connecting to a Host through a Security Proxy Server.

Installing the Components to the Servers

To provide load balancing among Reflection for the Web servers, you need to install Reflection for the Web on each server and configure it the same way on each server.

Note: These steps describe the process that you follow when Reflection for the Web is installed using defaults.

1. Use the method supported for your environment to install the desired components* of Reflection for the Web on each server. Use the same paths and the same contexts for each server. Note: When using a front-end device, use the name of that device for the common name in the certificates on all servers configured.

2. Complete any additional configuration required. For example, if it's applicable to your environment, integrate Tomcat/IIS.
3. Designate one web server as the "primary" server. Run the Administrative WebStation from only the primary server. (If you are using NTFS file permissions on the web server as the access control method, see Special Considerations.)
4. If applicable, install and configure the security proxy servers to the same or different machines from the web servers. (If installing on the same machine, the installation will have occurred in step 1.) Make sure the common name entered in the security proxy certificate matches the name of the front-end device.
5. Designate one of the security proxy servers as the "primary security proxy server."
6. To exchange certificates, follow the directions below that match your installation:

• If the security proxy and management server are installed on the same machine and the installation was an automated installation, the exchange of the management server and proxy server certificates is complete. Proceed to the next step.
• If the security proxy and management server are installed on the same machine and the installation method was manual, the certificates need to be exchanged. See the Reflection for the Web Technical Note 9988 and consult the technical note on installation that is specific to your platform.
• If the security proxy is installed on a separate machine and an automated installation method was used, run the security proxy wizard from the primary security proxy server. (See the product installation guide for information about how to launch the wizard.)

1. Launch the security proxy wizard.
2. Go to the Proxies tab and click the Export button near the bottom of the screen.
3. Export the security proxy server certificate to the primary management server using the direct ip address for the primary management server.
4. Go to the Trusted Certificates tab and import the management server certificate from the primary web server.
5. Exit the security proxy wizard. If you have made any changes other importing and exporting the security proxy and management server certificates, stop and restart the security proxy server.
7. Launch the Administrative WebStation from the primary server. Configure Access Control, if needed. Create, configure, and map sessions.
8. Confirm that everything is working on the primary server.
9. Copy the \ReflectionData folder (and its subfolders) from the primary web server to the other servers, overwriting all of the existing files, except for the following:

• Do not copy the \log and \db subfolders.
• Do not copy the \AccessControl\TSessions.mdb file.

10. Copy the \Securityproxy folder (and its subfolders) from the primary security proxy server to the other servers, overwriting all of the existing files.

Maintenance Tips

1. If you make any changes using the Administrative WebStation, for example, session configurations, access control or mappings, or other settings, copy the \ReflectionData folder to the other servers, except for the following:

• Do not copy the \log and \db subfolders.
• Do not copy the \AccessControl\TSessions.mdb file.

2. If there are any changes to the security proxy server configuration, copy the \Securityproxy\conf folder to the other servers. If there are any changes to the security proxy certificates or trusted certificate store, copy the \Securityproxy\keystores folder.

Special Considerations

Note the following considerations when you configure load balancing:

• Load balancing the metering server is not recommended. When metering is configured, the emulator applet on the client sends a periodic heartbeat to the metering server. If the metering server is load balanced, the heartbeats may be directed to different servers, causing failure of metering for the session. A sticky rule on the load balancer may work around this issue, although a sticky rule may have negative consequences for the other servers. Also, note that metering reports would be created on each server, so their data would need to be manually combined to provide accurate information on usage.
• Load balancing is not recommended for FTP connections going through the security proxy. An FTP session opens three connections: data channel, control channel and notification channel. All three connections must be routed through the same security proxy server. A sticky rule may work around this issue, but may have negative consequences. Contact Technical Support (http://support.attachmate.com/contact/?prod=reflection) for more information on configuring secure FTP session with load-balanced security proxy servers.
• The Administrative WebStation should not be load balanced. Use the direct ip address of one of the servers when accessing the Administrative WebStation.
• It is not possible to load balance web servers if Single Sign-on (SSO) macros are being used. The credentials store associated with SSO macros cannot be synchronized among multiple management servers. SSO macros were introduced in Reflection for the Web version 8.5. (For more information about this feature, see Technical Note 1876.)
• If the web server's access control method is NTFS file permissions, when you initially configure the management servers, configure access control on each server. Do not copy the Tsessions.mdb file from one server to another, either during initial configuration or for maintenance purposes. If you make changes to sessions on the primary management server, copy the modified .asp files from the \ReflectionData\AccessControl\dynamic and \ReflectionData\AccessControl\static folders to the other server. Then set the file permissions on .asp files.

Optional Background Information

The following topics provide information about how Reflection for the Web makes host connections. This basic overview of Reflection's host connection process may help you understand the factors to consider when you configure load balancing support.

Connecting to a Host

Reflection for the Web uses a three-step process to connect to a host.

1. The client computer uses a browser to communicate with the web server. If the connection to the web server is HTTPS, the client browser will attempt to authenticate the SSL server certificate of the web server. A certificate warning message will occur if the certificate is not trusted by the browser, if the certificate has expired, or if the common name of the certificate does not match the server name in the URL.
2. The web server downloads the Reflection for the Web applet to the client.
3. The Reflection for the Web applet connects to the host.

Connecting to a Host through a Security Proxy Server

Connecting to a host through a security proxy server is a multi-step process:

1. When the Reflection management server on the web server and the security proxy server are configured, they exchange certificates so that each server has the certificate information of the other. After the exchange, the security proxy certificate is stored in the Emulator Applet Trusted Certificate Store on the management server. The management server certificate is stored in the Trusted Certificate Store of the security proxy server.
2. The browser makes an HTTP or HTTPS connection to the web server which hosts the management server. If an access control (other than None or NTFS file permissions) method is configured, the management server checks the credentials of the client. When the credentials are verified, the management server allows access to sessions authorized for this client.
3. A session is selected in one of two ways: the client makes a selection from the Links List or the URL launched by the client contains the session parameters.

4. When connecting through the Reflection security proxy server, two different authentications are performed. One authentication uses the security proxy server certificate and the other uses the Reflection management server certificate.
   1. Security Proxy Server Certificate: The emulator applet initiates the SSL handshake with the security proxy. The security proxy server sends its certificate to the applet on the client machine. To verify that the security proxy’s certificate is trusted, the applet checks its cached trusted certificate store (the one that has been downloaded from the management server). If "server identity verification check" is enabled (in the Administrative WebStation, Security Settings > Security tab—in versions earlier than 8.5, Settings > Security), the applet will also check the common name of the certificate against the name/ip address used to contact the security proxy. If the security proxy certificate and common name are verified, the applet successfully authenticates the proxy server and the process proceeds to the second authentication.
   2. Management Server Certificate: This authentication uses the authorization token downloaded from the management server. This step occurs only if "Client Authorization" is enabled in the security proxy server (the default—configured on the Advanced Tab of the Security Proxy Wizard). The emulator applet forwards the token to the security proxy server. The security proxy server verifies the signature against its trusted certificate store, which contains the management server’s certificate. Once the security proxy server authenticates the management server as the source of the authorization token, the security proxy server knows that the management server authorized this client to connect to the destination host and port identified within the token.
5. When the authentications are successfully completed, the security proxy server connects to the host and the terminal session can begin.

Related Technical Notes

1876	Creating Reflection for the Web Single Sign-On Macros
2174	Configuring Replication in Reflection for the Web 9.5 or Higher
9988	Reflection for the Web Technical Notes