High Availability Cluster
A GreenArrow High Availability Cluster synchronizes its data between two physical servers. This can be thought of as RAID 1 over a network.
A High Availability Cluster allows for rapid recovery (typically taking about a minute) in most failure scenarios. This is a much faster recovery time than restoring from backups. Backups should still be taken though, because like RAID, a High Availability Cluster protects you from some, but not all failure scenarios. For example, a High Availability Cluster will allow for rapid recovery from most hardware failures but does not offer any protection against human error causing the accidental deletion of data.
A High Availability Cluster consists of two servers, each of which may be either fill the “Primary” or “Secondary” role at any given moment:
- The server with the Primary role runs the services that make up GreenArrow Engine and/or Studio. Emails get sent through it, clicks are processed by it, etc. Only one server may fill the Primary role at a time.
- The server with the Secondary role. As long as the Primary is operational, the Secondary maintains a copy of the Primary’s data. If the Primary fails, the Secondary can be promoted to become the new Primary. The services that make up GreenArrow Engine and/or Studio can then be started on the new Primary.
Writes performed on the Primary get mirrored to the Secondary. This occurs in close to real time, so if there is a failure of the Primary, the Secondary will normally lose no more than a few seconds of data. Zero data is lost if a failover occurs while both servers are operating normally and the failover instructions in the High Availability Cluster Administration page are followed.
Requirements and Limitations
Having a fast, low latency network connection between the two servers is important. In most situations, we recommend maintaining one or more full-duplex 10 Gigabit Ethernet link(s) via network cable(s) run directly between the two servers. We recommend carrying other network traffic, such as outgoing emails over a separate network interface on each server.
Setting up a High Availability Cluster without a fast, low latency network connection may be possible, but the details should be discussed with GreenArrow. There may be a performance, cost, and/or additional licensing fees associated with that type of configuration.
We recommend planning ahead when installing the operating system on your servers so that a disk or partition can be dedicated to data mirroring. For example, you could ask your hosting provider to install the operating system on a 20GB root (
/) partition and leave the remaining space unallocated. GreenArrow could then allocate the remaining space to mirroring during the server setup process.
We only support running CentOS 7 or Red Hat Enterprise Linux 7 on each server being used in a High Availability Cluster.
Installation of a High Availability Cluster can only be performed by GreenArrow. There is an installation guide that you’re welcome to use, but please note that if you do, you’ll end up with a configuration which does not include a High Availability Cluster.
Restoration of High Availability Cluster functionality from backups can only be performed by GreenArrow. There is backup restoration documentation, which you’re welcome to use, but please note that if you do, what you’ll end up with is a configuration which does not include a High Availability Cluster.
GreenArrow software updates on a High Availability Cluster can only be performed by GreenArrow.
- High Availability Cluster Administration provides information on how to perform common administrative tasks on a High Availability Cluster, such as checking on its status and taking backups.
- Self Managed High Availability Clusters provides additional technical details of how GreenArrow’s High Availability Cluster works behind the scenes, which are intended to enable customers who chose to manage their own clusters to do so. GreenArrow manages most High Availability Clusters. The procedures described on this page should not be performed on a GreenArrow managed cluster without GreenArrow’s approval.