About load balancers

In version 2022.2.3 Access Gateway introduced internal load balancing. Access Gateway as load balancer is the preferred load balancing method.  See About Access Gateway load balancing.

Access Gateway is often deployed in a high availability scenario using a load balancers. Load balancers exist to:

  • Distribute load across multiple instances of Access Gateway. Amazon Web Services, Microsoft Azure, Oracle Cloud Infrastructure all support pre-Access Gateway load balancers. In such scenarios the load balancer must know the health of each worker instance.
  • Distribute load to multiple instances of a back end protected web resource.
    In such instances Access Gateway's built-in load balancer support as well as third-party load balancers can be used to distribute load.

See Reference architectures for additional examples of architectures that include load balancers.

Typical Access Gateway Load Balancer Architecture


Load balancer configuration

Load balancers:

  • Sticky sessions or session affinity: Persistence, often known as stickiness or sticky sessions, is a technique implemented by application load balancers to ensure requests from a single session are always routed to the server on which they started. Any load balancer used with Access Gateway must support session affinity. Session affinity for a particular session is required by Access Gateway to ensure that second and subsequent requires for a given session are routed to the same Access Gateway node.
    How session affinity is specified varies by load balancer type, including cookie based or other mechanisms such as hashed source IP and port.
  • Load balancer strategy: The preferred strategy for an Access Gateway load balancer is round-robin or weighted round-robin.

When configuring a load balancer, the Access Gateway admin node is typically not included as part of the worker pool.

Worker node up check

Load balancers must be able to determine if Access Gateway cluster members are up. Access Gateway provides the /status REST endpoint which can be used to determine whether a node is up or down.

This check ONLY determines if the worker node itself is up and functioning. It does NOT determine if down stream resources are up and available.

For example:

curl -X GET -v -k https://{node.ip}/status -H 'Host:{gw.yourhost.tld}'

See Status monitoring for details.

Cluster upgrades and load balancers

To upgrade Access Gateway:

  1. Backup the configuration. See About backup and restore
  2. For the admin instance, secure shell (ssh oag-mgmt@gw.gateway.tld) into the Command Line Management Console.
  3. Follow the process for upgrading the Access Gateway appliance. See Upgrade Access Gateway .
  4. For each worker node in the Access Gateway high availability cluster.
    1. Take the worker node out of the load balancer rotation.
    2. Update the worker node.
    3. Return the worker node to the load balancer rotation.