Product Documentation

Ensuring High Availability of the Secure Gateway

May 06, 2015

You can design a Secure Gateway deployment to ensure high availability by deploying multiple servers running the Secure Gateway.

This configuration does not make Secure Gateway sessions fault tolerant, but provides an alternative server if one server fails.

When the number of concurrent sessions exceeds the capacity of a single server running the Secure Gateway, multiple servers running the Secure Gateway must be deployed to support the load. There is no practical limit to the number of servers running the Secure Gateway that can be deployed to service large server farms.

To deploy multiple servers running the Secure Gateway, a load balancer is required. The function of the load balancer is to distribute client sessions to one of a number of servers offering a service. This is normally done by implementing a virtual address on the load balancer for a particular service and maintaining a list of servers offering the service. When a client connects to a service, the load balancer uses one of a number of algorithms to select a server from the list and directs the client to the selected server.

The algorithm can be as simple as a “round robin” where each client connect request is assigned to the next server in a circular list of servers, or a more elaborate algorithm based on server load and response times.

The client response to a server failure depends on which server fails and at what point in the session the server fails. Types of server failure include:

Web Interface
The server running the Web Interface is involved during user sign on, application launch, or application relaunch. Failure of the Web Interface requires you to reconnect to the logon page and sign on again when you want to launch a new application or relaunch an existing application.
STA
The STA is involved in the launch or relaunch of an application. Failure of the STA during application launch requires that you return to the published applications page on the Web Interface to relaunch the application.
Secure Gateway
The Secure Gateway is involved during application launch and the time an application remains active. If a session fails, the client connection goes to another server and the session automatically reconnects without having to log on again.

Intelligent load balancers can detect the failure of a server through server polling, temporarily remove the failed server from the list of available servers, and restore them to the list when they come back online.

Load Balancing Multiple Secure Gateway Servers

The benefits of load balancing across multiple servers running the Secure Gateway include:

Scalability
Optimize the Secure Gateway performance by distributing its client requests across multiple servers within the array. As traffic increases, additional servers are added to the array. The load balancing solution used imposes the only restriction to the maximum number of servers running the Secure Gateway in such an array.
High availability
Load balancing provides high availability by automatically detecting the failure of a server running the Secure Gateway and redistributing client traffic among the remaining servers within a matter of seconds.

Load balancing an array of servers running the Secure Gateway is accomplished using a virtual IP address that is dynamically mapped to one of the real IP addresses (for example, 10.4.13.10, 10.4.13.11 and 10.4.13.12) of a server running the Secure Gateway. If you use a virtual IP address such as 10.4.13.15, all your requests are directed to the virtual IP address and then routed to one of the servers. You can set up the virtual IP address through software, such as Windows NT Load Balancing Service, or hardware solutions, such as a Cisco CSS 11000 Series Content Services switch. If you use hardware in a production environment, make sure to use two such devices to avoid a single point of failure.

Load Balancing an Array of the Secure Gateway Proxy

You can load balance an array of servers running the Secure Gateway Proxy in the same way as the Secure Gateway. Instead of using an external load balancer, the Secure Gateway Proxy has built-in support for load balancing.

This is useful in situations where you experience extremely high loads on the Secure Gateway array. In this case, it might help to deploy a second Secure Gateway Proxy and load balance the two servers.

In addition, if the communications link between the Secure Gateway and the Secure Gateway Proxy is secured, you can use a single certificate for the Secure Gateway Proxy array.

Certificate Requirements for Load Balancing Secure Gateway Servers

Load balancing relies on the use of a virtual IP address. The virtual IP address is bound to an FQDN and all clients request connections from the virtual IP address rather than the individual servers running the Secure Gateway behind it. A single IP address, the virtual IP, acts as an entry point to your servers running the Secure Gateway, simplifying the way clients access Web content, published applications, and services on computers running Citrix XenApp.

If you are using a load balancing solution, all servers running the Secure Gateway can be accessed using a common FQDN; for example, csgwy.company.com.

In conclusion, you need a single server certificate, issued to the FQDN (mapped to the virtual IP or DNS name) of the load balancing server. The certificate must be installed on every server running the Secure Gateway in the server array that is being load balanced.

Using Load Balancers and SSL Accelerator Cards with Secure Gateway Servers

Load balancing solutions available in the market today may feature built-in SSL accelerator cards. If you are using such a solution to load balance an array of servers running the Secure Gateway, disable the SSL acceleration for traffic directed at the servers running the Secure Gateway. Consult the load balancer documentation for details about how to do this.

Presence of SSL accelerator cards in the network path before the server running the Secure Gateway means the data arriving at the Secure Gateway is decrypted. This conflicts with a basic function of the Secure Gateway, which is to decrypt SSL data before sending it to a Citrix XenApp server. The Secure Gateway does not expect non–SSL traffic and drops the connection.