FAQ: Understanding Group Remote Policies in Forum Sentry

As an XML Security Gateway, Forum Sentry sits in front of your SOAP/XML/REST Web services protecting your back-end services. For externally facing services (traffic comes in from outside your network), Sentry is responsible for handling all incoming XML traffic sent from your trading partner's client applications and destined for your services. Sentry processes these incoming requests and then sends them along to the back-end service (the remote server).

Often times the Forum Sentry gateway resides behind network load balancers which distribute the incoming requests among multiple Forum Sentry appliances. The load balancers ahead of Sentry allow for redundancy and increased throughput.

Forum Sentry, through the use of Group Remote Policies, also includes support for load balancing requests to multiple remote servers.

A Group Remote policy is a collection of Remote network policies that provides failover for redundancy in the case of a remote server failure and can optionally use one of several strategies for remote load balancing. A Group Remote Policy can be associated with a WSDL or XML policy.

There are several Load Balancing strategies available with the Group Remote Policies. The strategies are broken into two categories: Passive Load Balancing Strategies and Adaptive Load Balancing Strategies. Below is a quick summary of each.

Passive Load Balancing Strategies

Passive strategies choose a Remote policy without reference to the traffic passing through the system.

  • Failover - Uses the order of the configured Remote policies in the group to signify priority. Always chooses the first Remote policy from the list of eligible Remote policies unless it is disabled or inaccessible, in which case it moves to the second, etc.
  • Round Robin - Initially chooses an eligible Remote policy at random and then rotates through the list of eligible Remote policies in order, choosing the next eligible Remote policy for each new client request.
  • Random - Chooses an eligible Remote policy at random for each new client request.
  • Weighted Random - Chooses an eligible Remote policy at random for each new client
    request, using the relative weights configured for each Remote policy. The configured weights set the relative odds that each Remote policy will be selected if eligible.

Adaptive Load Balancing Strategies

Adaptive strategies gather statistics about current and past traffic passing through the system and choose a remote server based on the traffic patterns.

  • Transfer Throughput - Chooses the highest performing eligible Remote policy. Performance is measured by the average transfer throughput of the last 100 requests, in bits per second.
  • Active Requests - Chooses the eligible Remote policy which is the least busy, based on the
    number of concurrent requests the Remote policy is servicing.
  • Response Time - Chooses the highest performing eligible Remote policy, measuring
    performance by the average response time of the last 100 requests. The Response Time strategy chooses the Remote policy with the lowest average response time.

Summary of Group Remote Failover Behavior

All Group Remote policies, regardless of the load balancing strategy selected, includes failover functionality that works as follows:

The list of policies available for a Group Remote policy to use initially includes all the Remote policies configured for the Group Remote policy. Removed from this list are all Remote policies which have been manually disabled via the WebAdmin and any Remote policies which are known to be inaccessible.

The Group Remote Policy discovers that a Remote policy is inaccessible only after the policy is chosen for use by a client request and cannot be reached. If the Remote policy is reachable but returns an error, it is still considered to be accessible - only an unreachable Remote policy is removed from consideration. Once a Remote policy is discovered to be inaccessible and removed from the list, the Group Remote policy will begin trying to connect to the remote server of the Remote policy in the background, with a retry delay as configured in the Group Remote policy. The Remote policy will be returned to the list once it can be reached to process requests.

For more information on the Group Remote policies please refer to the latest HTTP Network Policies Guide available in the Help section of the WebAdmin interface.


Article is closed for comments.