4.3 Clustering Access Gateways

A cluster of Access Gateways must reside behind a Layer 4 (L4) switch. Clients access the virtual IP on the L4, and the L4 alleviates server load by balancing traffic across the cluster of Access Gateways. Whenever a user enters the URL for an Access Gateway resource, the request is routed to the L4 switch, and the switch routes the user to one of the Access Gateways in the cluster, as traffic necessitates.

Figure 4-2 illustrates the flow of a user request when the Access Gateways are clustered behind an L4 switch.

Figure 4-2 Grouping Access Gateways

  1. The user requests access to a protected resource by sending a request to the L4 switch. The request is sent to one of the Access Gateway servers in the cluster.

  2. The Access Gateway redirects the request to the Identity Server for authentication. The Identity Server presents the user with a login page, requesting a user name and a password.

  3. The Identity Server verifies the user’s credentials with the directory.

  4. The validated credentials are sent through the L4 switch to the same Access Gateway that first received the request.

  5. The Access Gateway verifies the user credentials with the Identity Server.

  6. If the credentials are valid, the Access Gateway forwards the request to the Web server.

If the Access Gateway where the user is assigned goes down, the user’s request is sent to another Access Gateway in the cluster. This Access Gateway pulls the user’s session information from the Identity Server. This allows the user to continue accessing resources, without having to reauthenticate.

IMPORTANT:Using a DNS round robin setup instead of an L4 switch for load balancing is not recommended. The DNS solution works only as long as all members of the cluster are working and in a good state. If one of them goes down and traffic is still sent to that member, the entire cluster is compromised and starts generating errors.

The following sections describe how to set up and manage a cluster of Access Gateways.

4.3.1 Prerequisites

  • An L4 switch installed. You can use the same switch for an Identity Server cluster and an Access Gateway cluster, provided that you use different virtual IPs.

  • One or more Access Gateways installed. They must all be of the same type: either Linux Access Gateways or NetWare® Access Gateways. You cannot mix these two types in the same cluster.

    When you install each new Access Gateway, configure it to use the same Administration Console.

  • Your DNS server must to be configured to resolve the published DNS names that you specify for your proxy services to the L4 switch.

  • Enabling persistent (sticky) sessions on the L4 switch is highly recommended, but not required.

IMPORTANT:If you have created a configuration for one or more of the Access Gateways you are going to put in a cluster, you need to carefully select the primary cluster server. The current configuration of the primary cluster server is pushed to the other servers in the cluster. If you have created configurations for the other servers in the cluster, these configurations are overwritten.

4.3.2 Configuring a Cluster

  1. In the Administration Console, click Access Manager > New Cluster.

  2. Fill in the following fields:

    • Cluster Name: Specify a display name for the cluster.

    • Type: Select whether the cluster contains NetWare Access Gateways or Linux Access Gateways. A cluster cannot contain a mixture of these two types.

  3. In the Server Name list, select the servers that you want to be members of the cluster.

    You can create a cluster of one, and add additional servers later.

    Each server you add to the cluster adds about 30 seconds to the time it takes to configure the cluster because certificates must be synchronized and configuration options must be sent to that server. If you create a very large cluster of twenty servers, it can take up to ten minutes to configure and create the cluster.

  4. In the Primary Cluster Server field, select the server that is to be the primary server in the cluster.

    The list is empty until you select the servers for the cluster. The configuration of the primary server is pushed to the other servers in the cluster. If any of the selected servers have been configured, their configurations are lost.

  5. Click OK.

  6. After the cluster has been created, each server in the cluster needs be restarted. On the Access Gateways page, click Update All by the name of the cluster.

  7. (Conditional) If the Access Gateways in the cluster have multiple network adapters or IP addresses, you need to configure the listening address for each reverse proxy.

    When creating the cluster configuration for newly added servers, the listening address is always the IP address of eth0. If this is not the address you want the reverse proxy to listen for requests, click Access Gateways > Edit > [Name of Reverse Proxy], select the Access Gateway as the Cluster Member, then enable the Listening Address you want to use.

  8. To configure the cluster, click Access Gateways > Edit.

    A cluster of Access Gateways has the same configuration options as a single Access Gateway. The only difference is that for some options you need to select the Access Gateway to configure. For example, the Date & Time option allows you to set the time separately for each member of the cluster.

    Applying the configuration to a cluster is slightly different. You have the option to apply the changes to all servers in the cluster by selecting the Update All option, or to apply them to one server at a time by selecting the Update option for each server.

    If you prefer to apply changes to the servers one at time, you should save the changes to the configuration datastore. To do this, click OK on the Server Configuration page. The OK buttons on the other configuration pages save the changes to browser cache. If your session times out before you update all servers in the cluster, the changes are lost and are not applied to the servers that are still in an Update status.

    WARNING:If you reboot too many machines at the same time, some of the machines might report a configuration store error and not start. This problem resolves itself eventually, but it can take several hours.

    To prevent this problem, reboot the cluster members individually, waiting until a rebooted machine has started before issuing the next reboot command.