Clustering, load-balancing and failover scenarios

This article describes three different setup scenarios for Airlock Gateway instances:

  • A single gateway instance setup.
  • A cluster of two instances using built-in Airlock Gateway functionalities.
  • A setup of a load-balanced farm of Airlock Gateway instances with a dedicated load balancer.
 
Info

Session stickiness is maintained for all scenarios in this section.

Single Airlock Gateway instance

Single Airlock Gateway setups without failover are recommended only for testing and integration environment.

 
Info

For loads that cannot be managed with one single hardware anymore, Airlock Gateway supports upstream load balancing.

Pros:

  • Lowest setup costs.
  • Disk mirroring is possible.
  • Ideal for testing and integration environment.
  • Any hardware can be used.
  • Internal process monitoring with self-healing.

Cons:

  • Not recommended for production environments (no blackout protection).
  • Single point of failure.

Airlock Gateway failover cluster

Two Airlocks Gateway instances can be operated as a failover cluster with one active and one passive instance using built-in functionalities. In this setup, the active Airlock Gateway receives and processes data and is monitored by the passive Airlock Gateway. If the passive instance detects an error on the active one, it takes over automatically. The monitoring is done on a separate channel by using the cluster talk protocol.

This kind of setup is often used in production environments.

Pros:

  • Cost-sensitive setup.
  • Recommended for production environments.
  • Easy to set up and maintain.
  • High availability through failover instance.
  • Availability even during update processes.
  • Mutual monitoring of both instances.
  • Health checks by the passive Airlock Gateway.
  • Internal process monitoring with self-healing.

Cons:

  • Only one system is active at a time.

Load balanced farm of active Airlock Gateway instances with external Redis session store

Two or more active Airlock Gateway instances can be operated as a load-balanced Airlock Gateway farm with an external Redis session store cluster to keep the session states and stickiness in sync for all gateways. In this setup, a dedicated load balancer orchestrates a number of Airlock Gateways – such a setup is typically used for high performance and redundancy requirements.

Using an external Redis session store (a cluster is recommended), active Airlock Gateway nodes can synchronize session states. With synchronized sessions, different requests of the same user session may pass different Airlock Gateway instances.

Pros:

  • Works with two or more Airlock Gateway instances.
  • Recommended for production environments if load exceeds capacity of a single instance.
  • Scalable setup for growing throughput and availability demands.
  • All systems can be active at a time.
  • Availability even during the update process is possible.
  • Application-related load balancing.
  • Health checks are managed by the load balancer.
  • Mixed hardware can be used for the Airlock Gateway instances.
  • Internal process monitoring with self-healing.
  • Sessions are synchronized between the Airlock Gateway instances.

Cons:

  • Higher setup costs.
  • Requires a dedicated load balancer.
  • Requires one or more Redis session stores.
  • Can be more complex to set up and maintain.

Load balanced farm of active Airlock Gateway instances without Redis session store

Two or more active Airlock Gateway instances can be operated as a load-balanced Airlock Gateway farm with a load balancer that handles session stickiness. In this setup, a dedicated load balancer orchestrates a number of Airlock Gateways – such a setup is typically used for high performance and redundancy requirements.

If sessions are not synchronized via an external Redis session store, the load balancer in front of the Airlock Gateway instances must take care of session stickiness, i.e., make sure that all requests from a user session are always routed through the same Airlock Gateway instance.

Pros:

  • Works with two or more Airlock Gateway instances.
  • Recommended for production environments if load exceeds capacity of a single instance.
  • Scalable setup for growing throughput and availability demands.
  • All systems can be active at a time.
  • Availability even during the update process is possible.
  • Application-related load balancing.
  • Health checks are managed by the load balancer.
  • Mixed hardware can be used for the Airlock Gateway instances.
  • Internal process monitoring with self-healing.

Cons:

  • Higher setup costs.
  • Requires a dedicated load balancer.
  • Can be more complex to set up and maintain.
  • Load balancer must take care of session stickiness between the client browser and the Airlock Gateway instances.