Expected Load Balancer Behavior

Edit online

A load balancer monitors the health of each Shares nodes and redirects the traffic accordingly, balancing the load between all healthy nodes.

This topic describes how the load balancer should function when handling HTTPS traffic and FASP transfers.

Note: This topic does not describe how to set up and configure a load balancer. For instructions on configuring a load balancer, refer to the documentation of your load balancer.

HTTPS Traffic

The load balancer must monitor the health of the HTTPS service running on each node. To do this, it can either use a method based on an HTTPS request, or simply check whether TCP port 443 is responding, that is, whether a SYN ACK packet is received after a SYN packet is sent by the monitoring service. If an RST packet is received instead, or if no packet is received at all, then the monitoring feature must consider the monitored service to be down and discard the related node (take it offline).

The load balancer can redirect any HTTPS request to any of the healthy nodes. Because the Shares web application uses a database shared by both nodes, any healthy node can respond to any request.

FASP Transfers

Once the FASP transfer is initiated by a successful SSH connection (typically using TCP/33001 on the server side), the FASP protocol uses UDP packets for data transfer (typically using a port range of 33001-33100).

When a client establishes a SSH connection, the load balancer has to choose which node will handle this connection. Once it has done so, and the SSH connection is established with one node, the load balancer must make sure that the following is true:
  • The TCP connection related to the SSH session stays with the chosen node.
  • Any subsequent UDP traffic coming from the same client is directed to the same node. This behavior is generally known as a sticky/persistent session, depending on the source IP address of the client.

In other words, if an SSH connection is established between a client with a particular IP address and node A, then all subsequent UDP packets sent from that IP address must be redirected to node A.

If a node is declared unavailable by the load balancer (by checking the HTTPS service or the SSH service), the load balancer needs to redirect all the traffic to the remaining healthy node.

The different types of traffic (SSH/TCP/33001 and FASP/UDP/33001-33100) may need to be joined together in a pool of services on the load balancer side. The exact settings vary depending on the load balancer model.

HTTP Redirection

The Shares application uses HTTPS by default, and it sets an automatic redirection from HTTP/TCP/80 to HTTPS/TCP/443 to force users to use a secure connection.

The load balancer can forward HTTP requests to the nodes, which then handle the redirection. Alternatively, the load balancer itself can handle the redirection; this prevents any insecure connections from being established with a node.