This document describes three possibilities for EMG multi-node setups.
The main reason for having more than one EMG node is to add redundancy to be able to handle a situation where one EMG node fails.
To handle IP address failover in a multi-node setup the utility keepalived can be very useful.
EMG uses two different data stores: Indexed files for message queues, open delivery reports etc and MySQL for user authentication, connector configuration and more. Previously we also recommended using MongoDB instead of indexed files for the active-active case, but that turned out to have too many disadvantages.
EMG needs to be licensed for each node in the multi-node setup. However, licenses for second and following nodes in a redundant setup is subject to a discount.
1. Active-passive with MySQL replication
If you have a primary standalone EMG node you can quite easily add a secondary node ready to take over if primary node fails.
The secondary node would be configured identically to the primary node with the difference that MySQL on the secondary server would be configured as a replication slave, replicating the “emg” database from the primary server.
Pros
- It is relatively easy to add a secondary node to an existing primary node.
- No additional components are needed (only MySQL built-in replication is used).
- Can be suitable even when latency between primary and secondary node is substantial (geographic redundancy).
Cons
- Queues and open delivery reports (in indexed files) will not be available on secondary node (unless they are made available on shared disk storage).
- Once primary node has failed and failover to secondary node has occured the secondary node would be considered primary and a new secondary node needs to be set up.
2. Active-active using standalone nodes and dlr failover
To achieve the performance of a stand-alone node yet handling multiple active nodes.
Two or more nodes can operate standalone but connect to operators using same account credentials on each node. In the case when delivery reports are received by the “wrong” node it will be forwarded to next node for lookup.
Pros
- Highest performance.
- Simple setup.
Cons
- Nodes are not equivalent and message information will be stored on a specific node.
- MO messages may need some special handling.