Configuring HTTP access: Single URL

HTTP Access Services provide load balancing and failover for multiple application servers, and different applications over the same service definition (or TCP listen port).

In a single URL configuration, external users can access an application that is hosted on multiple application servers from one common URL. The HTTP access service distributes server requests to the application servers without the need for an administrator to specify a unique port mapping for each application server.

You can use several formats to specify the URLs of the application servers to which the HTTP Access Service directs incoming connection requests:

Basic server URLs

The HTTP access service routes traffic to several servers that run the same application, such as HCL Traveler. The SafeLinx Server balances the load (or provides failover) across the application servers. The SafeLinx Server assigns users to one of the servers according to the load balancing configuration.

Note: The SafeLinx Server persists the assignment in the user record for iNotes and Traveler, always directing traffic for these user sessions to the same application server URL.

You specify application server URLs in a comma-separated list, in the following format:

[ <KEYWORD> | <Map> ] URL,[ <KEYWORD> | <Map> ] URL …

URLs with keyword designations

The HTTP access service routes traffic to multiple application servers that are running different applications. You can pair certain keywords with a URL to specify the application server to which the HTTP access service routes traffic. You can use the following keywords:

INOTES: iNotes® application handler
TRAVELER: Traveler application handler
SAMETIME: Sametime® mobile chat application handler
CONNECTIONS: Connections mobile application handler
MEETINGS: Sametime® meetings application handler

This following image shows how to configure one service to support a single iNotes® server, two Traveler instances, and a Sametime® proxy instance.

Configuring multiple application servers

Affinity identifiers or URI paths to map requests to specific servers

You can use affinity identifiers or URI paths to route requests to specific servers. Specify combinations of affinity identifiers and server URLs to route traffic that is sent to URLs that contain the identifier string to the specified server. Specify a URI path that extends beyond the root path to restrict clients to connecting to URLs that have that path prefix.

For example, suppose that the Application server URL field includes the following entry:

/apps/ https://appserver01.myco.com

If the HTTP access services receives a request for https://safelinx.renovations.com/apps/index.htm, the SafeLinx Server detects the affinity identifier /apps/ in the URL string. As a result, the request is routed to the specified internal server at https://appserver01.myco.com/index.htm.

If you add the entry https://media.myco.com/mediafiles/, the HTTP access service does not accept requests sent to https://media.myco.com/documents/

Include a default URL in the list to handle requests that don't match an affinity ID. Request that don't include strings that match an affinity identifier are specified

Apps and Archive URLs affiliated with two distinct servers

Note: The SafeLinx Server will strip the affinity ID from the target request. In the example, for the first definition, the SafeLinx Server would leave the request unchanged because the affinity ID and the URL have the same string /apps/. In the second definition, the string /archive/ would be removed from the target URL before the request is sent to the archiveserver.myco.com instance.

All requests not matching an affinity identifier would result in a 404 Not Found response unless the list includes a default URL (one without an affinity ID or the affinity ID set to '/').

Application server pool

An application server pool is made up of one or more Traveler high-availability clusters, each containing one or more server nodes. Server pools support Traveler only. For information about adding application server pools, see Adding an application server pool.

After a user is assigned to a pool, the SafeLinx Server persists both the pool and node assignments in the user's SafeLinx record. Subsequent connections are always directed to the same application server, unless you modify the assignment in the SafeLinx Administrator.

When you set up an HTTP access service for a single application, you can choose from among the following scheduling algorithms to distribute traffic among the available application servers:

Round-robin: The SafeLinx Server assigns incoming requests to the list of application servers sequentially.

Balanced: The SafeLinx Server assigns incoming request to the application server that has the lowest number of current user assignments or current connections. For Traveler, incoming requests are assigned to the Traveler server or pool that has the least number of assigned users.
Note: If the HTTP access service distributes traffic to multiple standalone Traveler servers or to a Traveler pool, you must choose the balanced scheduling algorithm.

Active / Passive: Designed to be a fail over, the Active / Passive option uses one server or the other.