Load balancing

There are several ways that you can load balance your servers, typically they are

• DNS round robin
• DNS weighted records
• Load balancer with public IP for each instance
• Load balancer with no public IP for each instance

At DocEvent we use DNS weighted records in Amazon Route53 to load balance our servers.

Problem

Let's say we have 2 DocEvent servers that we have in our network, we want our customers to connect to the instances and ensure that if one server becomes unavailable the service continues to work.

Requirements

It is recommended servers will require their own routable public IP address.

If you wish to use a load balancer and instances do not have a routable IP address, then you must use a sticky IP session management on your router in order to ensure connections route to the same instance.

DNS round robin

This is by far the easiest method. Simply adding 2 A records to the same DNS entry e.g. ftp.mycompany.com, and pointing them to the public IP address of the instances ensures will ensure that users can access the servers randomly.

e.g.

Server1 started with flag -publicip 1.1.1.1
Server2 started with flag -publicip 2.2.2.2

dns records:

ftp.mycompany.com A 1.1.1.1
ftp.mycompany.com A 2.2.2.2

Ensuring availability

It is recommended to have a healthcheck on the service to ensure DNS entry is removed if the instance becomes unavailable.

DNS weighted records

This DNS record works similarly to the DNS round robin, except that it only serves one IP address to the client, rather than both IPs at the same time.

Load balancer with public IP per instance

In this example we have 2 instances with 2 public IPs attached, as below:

Server1 started with flag -publicip 1.1.1.1
Server2 started with flag -publicip 2.2.2.2

We have a load balancer that accepts connections on 21, 22 and 990. It then routes traffic to each of these instances. The load balancer IP is 3.3.3.3

Customers will connect using FTP to port 3.3.3.3, they are then routed to one of the available servers in the backend.

When a client sends a passive FTP command the server will respond with their public IP address (e.g. 1.1.1.1) - At this point the client will connect to 1.1.1.1 and continue the passive FTP connection.

Load balancer with no public IP per instance

In this example we have 2 instances, but their public IPs are set to the load balancer as below:

Server1 started with flag -publicip 3.3.3.3
Server2 started with flag -publicip 3.3.3.3

The load balancer accepts connections on 21, 22, 990, and it also accepts connections on the passive FTP ports (as defined in the options).

For each connection the load balancer must use Sticky IP in order to ensure the client always connects to the same backend server.

When a new passive FTP connection arrives the server will respond with the load balancers IP address for passive connections (3.3.3.3).

What is the recommend method?

At DocEvent we use weighted load balanced DNS, and are running instances in Alpine Docker using ECS in AWS auto scaling groups.

We use the -shutdownwindow along with sidecar containers that manage DNS when scaling down to ensure that no new connections are created on our FTP servers while they wait for existing connections to terminate.

Our customers tend to use weighted DNS as the preferred solution because it is simple, they do not run in autoscaling groups because they have consistent traffic, and their IP addresses do not change.

In the end it depends, and if you are unsure be sure you can contact us to discuss what the best solution might be.