Network Load Balancer as a service

What is it?

A Load Balancer (LB) can transparently distribute network data traffic to multiple servers.

LBs on Warren platform run in high availability mode, i.e. for each LB there are two instances running on different hypervisor hosts in active-passive configuration.

Connections to the LB address will be routed to configured Virtual Machines in a round-robin fashion. If a VM acting as a target is not running or not accepting connections, it will be left out of the load distribution. The target VM state will be checked periodically by Load Balancer, and once VM becomes reachable it will participate as an active target for routing once again.

Creating and configuring LB from the end-users standpoint

Creating new load balancer

 

LB is defined by one or more forwarding rules and a group of Virtual Machines or targets:

  • For each forwarding rule, the LB will listen for connections and proxy them to one of the target servers.

  • A forwarding rule is described with a “source” port for external connections to be accepted on, and a target port, where the traffic will be forwarded to one of the targets.

  • There may be an arbitrary number of target VMs configured, but they must all share the same private network.

  • While the forwarding rule also specifies a forwarding mode (Protocol), currently only TCP is available on the platform.

When a Load Balancer is initially set up, it is required for at least one rule and one target to be specified. These options can be added or removed later, forwarding rules can also be modified. The private network where LB operates is fixated on creation.

The Load Balancer itself can be assigned a public IP address, while the target servers are not required to have a public address.  

Configuration example

For instance, suppose we have a Load Balancer configured as follows:

Target servers and forwarding rules

 

The traffic coming from client C to LB’s port 8080 will be handled by either Server A on port 80 or Server B on port 80. The LB also employs a session persistence method to keep routing traffic from client C to the target that was chosen for the first connection from that client (see also note below). 

Note that the Status of target servers shows a general status of server instance, it does not account for the availability of service on the specified target port (80 in this case).

 

Technical details and limitations

For each configured Load Balancer, the warren platform creates two processes, which run on different nodes that operate in active + standby mode. 

For each forwarding rule, there is a limit on simultaneous connections handled by the LB. At present, the limit is fixed at 10,000 connections.

Note on client sessions

Currently, each LB is configured with a session persistence option in place, which is based on the incoming IP address. This means client connections coming with the same IP address are routed to a particular target server. This can result in uneven load distribution in scenarios where the service behind Load Balancer is mostly used by a single client or by clients coming from the same IP address.

Limitations

  • Load Balancer and all the target servers must reside in the same private network.

  • Proxying is done over the TCP protocol (layer 4).

  • SSL/TLS offloading by the Load Balancer is not supported at the moment, but HTTPS can still be routed if the following conditions are met:

    • When using SSL/TLS then all target servers must support SSL/TLS and have correct certificates installed. For example to use regular HTTPS a forwarding rule of 443 => 443 should be used.

 

Service charges

The Load Balancer service is charged by the hour with a fixed price. This may be changed in the future to allow more flexible pricing, e.g. higher maximum number of connections for an extra charge.

 

Administration Web UI

Listing all non-deleted Load Balancers

Go to Admin → Load Balancers