Gateway Architecture


Appian engines.png

To reduce the memory used by queued transaction messages, application Gateway processes serialize all calls made to the real-time databases.

Multiple Gateways

One approach to managing high transaction volumes is to add application gateways. When configured in this manner, the application gateways also perform the following roles.

  • Managing the load-balanced chain of engine servers
  • Detecting and Managing engine-failover

Multiple gateway configuration is only available when running on a Linux system. It is not available for Windows systems.

See: Creating a Distributed Environment on Linux, or Creating a Dual Gateway Topology for additional details.

With dual or triple gateways for an engine, each engine server's gateway process communicates with other configured gateway process (or processes). In this manner, a self-maintaining load-balanced chain of servers can handle extremely high transaction volumes.

Database transactions can be of two types – data manipulation or data retrieval.

  • Most of the transactions require retrieval of data (read calls) whereas far fewer transactions manipulate data (write calls).
  • Load balancing is achieved by directing write calls to one single engine server designated as the primary engine server and read calls to all engine servers in the load-balanced chain formed by the gateways.
  • A write transaction on the primary server is always followed by the replication of the write transaction onto other engine servers in the chain. This ensures data consistency across all distributed engine servers.
  • The connection manager is responsible for distributing read and write calls between the primary and secondary servers. The gateways are always aware of their position in the chain and refuse write calls if they are not serving in the primary database.

Gateway States

Gateway chain.png

Gateways communicate asynchronously among each other to reach an agreement on the proper configuration of the server chain. This configuration is a combination of gateway processes in different states. State changes in the chain occur either when failure conditions are detected by a gateway or when state-specific commands are issued (such as asynchronous communication at startup). A pre-configured list defines the engine servers in the whole chain.

The following gateway states before, during, and after a chain is formed.

Disconnected
A gateway is in the Disconnected state when a connection to the database server is unavailable. The gateway process issues a set of OS-level commands to start the instance of the engine server connected to this gateway. Any transition from this state can occur only when the engine server has started and has notified the gateway of this fact. When the gateway receives a notification that the engine server has started, it transitions to Active Join state.
Active Join
When a gateway process enters the Active Join state, a broadcast request is sent asynchronously to all configured servers available in the chain. This request includes a conflict resolution parameter. If this request is received by another gateway in the chain in Active Join state, this parameter is used to decide which gateway has precedence. If this gateway does not have precedence, it enters the Passive Join state and stays in that state for a configurable amount of time or until its state is forcibly changed. If the state of the Active Join gateway does not change after a specified number of retries, the gateway assumes it is the primary. The conflict resolution strategy ensures that no two gateways will attempt a synchronous connection to each other at the same time, and that no two gateways ever both assume the role of the primary gateway.
Passive Join
As mentioned earlier, a gateway process enters this state when a request comes in from another gateway and the conflict resolution parameter assigns a lower precedence to this gateway. After entering the Passive Join state, this gateway sends a notification to the gateway with higher precedence and awaits acknowledgment for a specified period of time. If the acknowledgement does not arrive in this time period, this gateway will assume failure of the other gateway and re-enter the Active Join state. An improperly configured delay (too short) might cause gateways to switch back and forth between the two Join states for some amount of time.

Gateways in the Disconnected and Active/Passive Join states refuse all client requests.

Standalone and Primary
This gateway server is the primary engine server. In the Standalone state, there are no other gateway processes in the chain, whereas in the Primary state there is at least one more engine server in the chain. There are two possible transitions for gateways into these states:
  • Transitions between these two states when a new gateway joins or disconnects.
  • Transition to the Disconnected state when the server engine server fails.

Gateways in Standalone and Primary state accepts all write/read requests from clients.

Spare and Next
This gateway directly follows a gateway in Primary state. In the Spare state, no other engine severs are available in the chain whereas in the Next state there is at least one more. The following is a list of the possible transitions from this state:
  • Transitions are possible between these two states when a new gateway joins or disconnects.
  • Transition to the Primary state whenever the primary engine server fails.

The Spare and Next states ensure smooth transition for fast engine-failover.

Chained and Tail
Gateways in the Chained state are followed by another gateway, while Tail gateways are not followed by any gateway. The following is the list of possible transitions:
  • Transitions to Spare or Next if the antecedent in the chain fails.
  • Transition from Tail to Chained if another gateway joins the chain.
  • Transition from Chained to Tail if the follower fails.

Gateways in the Spare, Next, Chained and Tail states accept read requests only.

Communication with Application Servers

The primary responsibility of distributing read and write calls lies with the Appian Connection manager. It uses a pooling mechanism that:

  • Provides separate write/read ports that can be distinguished by the gateway.
  • Automatically switches all the write ports to the next primary server in case of failure, if additional gateways are configured.
  • Updates the pool whenever there is a change in states of the gateway-enabled engine servers.
FEEDBACK