Clustering, HA, and Containerization

• Table of Contents
• Does GreenArrow offer a reference architecture for deployment in cloud environments?
• How can I achieve High Availability using GreenArrow?
• What is the failover process for moving queue data from one instance to another?
• When in a cluster configuration, is there an awareness of the number of open connections per IP across multiple MTAs?
• Is GreenArrow compatible with container orchestration platforms?

Does GreenArrow offer a reference architecture for deployment in cloud environments?

Yes. See our Kubernetes Reference Architecture.

Deploying a redundant MTA in the cloud is described in the GreenArrow Cluster documentation.

How can I achieve High Availability using GreenArrow?

GreenArrow itself is incredibly reliable and robust, and can be used to build a robust cluster.

For a High Availability cluster, see our Cluster Architecture or Kubernetes Reference Architecture for how to build a no-single-point-of-failure, horizontally scalable cluster.

This Cluster Architecture includes Cooperative Throttling so that all of the MTAs in the cluster work together to achieve the cluster-wide throttle limits for max messages per hour and maximum concurrent connections. Because of this, the cluster can be auto-scaled, saving on costs.

The An interview with Klaviyo’s MTA team blog post describes how Klaviyo built a no-single-point of failure cluster on top of EC2, EBS, and Persistence Path Mode. This pre-dates the Cluster Architecture, Cooperative Throttling, and the Kubernetes Reference Architecture.

What is the failover process for moving queue data from one instance to another?

GreenArrow’s Instance Drain Feature can move queued messages to another instance. It can be pointed to a particular instance or to a load balancer in front of all of the MTA instances. This is used by the Cluster Architecture and Kubernetes Reference Architecture to remove nodes from the cluster.

GreenArrow’s Persistence Path Mode feature allows you to easily re-mount data from one instance into a new one. Many customers running GreenArrow in the cloud have the Persistence Path on an EBS volume (or similar), so that if the instance fails, it can be restarted and pick up where the last instance left off with all of the same configuration and queued data.

When in a cluster configuration, is there an awareness of the number of open connections per IP across multiple MTAs?

Cluster-aware throttling is accomplished using our own reverse proxy which does the throttling decision making, without using a centralized service (that could become a performance bottleneck or be a single point of failure)

It’s also possible to grow and shrink clusters by draining the queue of one node to another node.

Is GreenArrow compatible with container orchestration platforms?

Yes, and we have online documentation that covers deploying GreenArrow in a Docker container.

A Kubernetes Reference Architecture is also available.

Alternatively, you can get many of the advantages of containerization in a Virtual Machine environment if you use:

• Something like Terraform with build scripts to create the Virtual Machines, and
• The GreenArrow Persistence Path Mode to isolate all of the state into a remote block device (like EBS on AWS).

A deployment of this kind of architecture is described in this interview with Klaviyo’s MTA team in the “What is the high-level architecture of your GreenArrow deployment?” section: