Multi-server Applications

Applications protected by IBM Application Gateway (IAG) may use multiple replicated servers for high availability. A resource server definition in IAG can specify multiple replicated servers to protect a single application.

Specifying Multiple Servers

For example, consider the following configuration where the /accounting resource server is a legacy application available on two replicated servers:

resource_servers:
  - path: /accounting
    servers:
      - server: acc1.demo.com
        port:   9443
        # ...
      - server: acc2.demo.com
        port:   9443
        # ...
    # ...

When handling requests to the /accounting resource, IAG will distribute requests between the two replica servers.

If the protected application requires that client requests are always directed to the same replica server during a session to maintain state, see the Stateful Applications topic to learn more.

Understanding how IAG Selects Servers

IAG uses a least-busy algorithm to determine which of the available servers is currently handling the fewest request connections and forwards the request to that server.

Server Availability

IAG also performs regular health checks of each server to determine if the server is available. If a server is not available, IAG will stop forwarding requests to that server until it is available again. This health check is referred to as a ping in the configuration YAML.

In the following example, IAG will:

While the server is available:
- Send a HEAD request (ping/method = HEAD)
- To the URL /health (ping/url = /health)
- Every 10 minutes (ping/policy/frequency = 600)
- The request will be considered to have failed if:
  - It is not completed within 10 seconds (ping/policy/timeout = 10)
  - It returns a response code of 500-509, but will succeed for any others (ping/policy/rule = [ -50*, +* ])
- If the request fails two consecutive times, the server will be considered unavailable (ping/policy/threshold = 2)
While the server is unavailable:
- It will retry the ping every 10 seconds (ping/policy/recovery/frequency = 10)
- If the request succeeds three consecutive times, the server will be considered available again (ping/policy/recovery/threshold = 3)

resource_servers:
  - path: "/example"
    # ...
    health:
      ping:
        method: HEAD
        url:    /health
        policy:
          frequency: 600
          threshold: 2
          recovery:
              frequency: 10
              threshold: 3
          timeout: 10
          rule:
              - -50?
              - +*

Grouping Servers

IAG can also prioritize servers, this is achieved by grouping the servers based on priority. When grouped by priority, IAG will always send requests to the server(s) with the highest available priority.

In the following example, the /hr application has four servers. hr-primary-1.demo.com and hr-primary-2.demo.com both have the priority of 9 and hr-secondary-1.demo.com and hr-secondary-2.demo.com are priority 8.

resource_servers:
  - path: /hr
    servers:
      - server:   hr-primary-1.demo.com
        port:     443
        priority: 9
        # ...
      - server:   hr-primary-2.demo.com
        port:     443
        priority: 9
        # ...
      - server:   hr-secondary-1.demo.com
        port:     443
        priority: 8
        # ...
      - server:   hr-secondary-2.demo.com
        port:     443
        priority: 8
        # ...
    # ...

While any server(s) with priority 9 are available, IAG will exclusively distribute requests to them. If all servers with priority 9 are unavailable, IAG will then start distributing requests to the next highest priority level, which in this case are the two servers with priority 8. Whilst in this state, if any servers with priority 9 become available, IAG will then resume distributing requests only to the server(s) with priority 9.