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 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 these instances, you can use Access Gateway's built-in internal load balancing and third-party load balancers to distribute load.

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

Typical Access Gateway Load Balancer Architecture

Topics

Load balancer configuration

Load balancers:

  • Sticky sessions or session affinity: Load balancers use session persistence to ensure that requests from a single session are always routed to the server on which they started. Persistence is also known as stickiness or sticky sessions. Any load balancer used with Access Gateway must support session affinity. Session affinity is used by Access Gateway to ensure that second and subsequent requests 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.

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

For example:

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

See Status monitoring.

Cluster upgrades and load balancers

To upgrade Access Gateway:

  1. Backup the configuration. See Backup and restore operations
  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.