Load Balancing

The goals of load balancing are to provide high availability and scalability.

Multiple appliances can be configured in a load-balanced group by using the load balancing service. The goals of load balancing are to provide high availability and scalability. Load balancing maximizes the availability of the virtual IP address, which provides a more reliable network endpoint for message receipt and processing.

Additionally, load balancing uses all units in the group, increasing potential throughput. All appliances in a load-balanced group must:

• Run the same software version.
• Have their primary network interfaces (eth0) on the same subnet.

One appliance is configured as the primary, and the others as secondaries. The director is the node currently providing the virtual IP address to the network and distributing all incoming traffic to itself and the other members of the group. The secondaries monitor the periodic heartbeats sent by the director. Normally, the primary is the director unless something is wrong: either something wrong with Mirth® Connect or some other hardware, software, or network problem that has caused it to fail or lose connectivity to the network.

If a secondary appliance notices three missed heartbeats from the primary, it becomes the director and begins to provide the virtual IP address to the network and handle distributing the incoming traffic. When the primary becomes active again, it takes back control of the virtual IP address and becomes the director.

Load balancing also provides a synchronization mechanism to help keep the appliances running the same Mirth® Connect channels. When you start load balancing, or whenever you deploy one or more channels while load balancing is running, the synchronization service copies over the Mirth® Connect configuration from the primary to the secondaries. For this reason, all channel administration should be performed on the primary.

Remember that if you stop the Mirth® Connect server on the director, a failover occurs. If a failover occurs from the primary to a secondary, do not restart the primary until you are ready for a fail-back. To prevent premature fail-back, stop the load balancing service on the primary node when it is in a failed state.