This article provides a technical overview of BinaryLane Load Balancer and basic configuration instructions for backend usage with Apache or Nginx.

BinaryLane customers can use an HTTP/HTTPS load balancer for an additional fee. The load balancer is fully redundant and configurable through our control panel.

Choose mPanel view:

• new mPanel
• Classic mPanel

A screenshot of the Load Balancer from within the mPanel

A screenshot of the Load Balancer configuration

A screenshot of the Load Balancer configuration

TABLE OF CONTENTS

• Requirements
• How it Works
• Technical Information
• Health checks and failover
• Health-check path
• Distribution and session stickiness
• HTTPS, certificates and client IP addresses
• Failover IPs, VPCs and Partner Server
• Configure Backend Networking
• Web Server Setup
• Health Checks & Troubleshooting
  
  

Requirements

• At least two servers - required for high availability
• Each VPS must be running a web server (for example, Apache or Internet Information Services)

How it Works

After you sign up for the Load Balancer service, you get a new "virtual" IP address, which becomes the new IP address of your website. From the control panel, pick the VPSs that HTTP requests will be spread over - these are known as the "real" IPs, and they correspond to the actual servers that handle the requests.

An automated health check is done every three seconds by the Load Balancer. Each real IP gets a HTTP request to see if that server is functioning correctly.

When a new HTTP request hits the virtual IP, the load balancer picks a healthy real IP and passes the request through. The real server then deals with the request and sends a response.

Technical Information

Protocol/IP version scope
BinaryLane Load Balancer currently handles IPv4 traffic only (ports 80/443).
IPv6 listener/frontend support is not currently available.

If your application requires IPv6 reachability, use a Split NIC/public IPv6 design on frontend VPS instances and retain private VPC IPv4 for backend communication.

• The Load Balancer is non-terminating: packets from each client are passed directly to the server with no changes made to the payload.
• The Load Balancer performs Layer 2 ("direct") routing: each packet from a client gets the destination MAC address altered and then is put back onto the network for the real server to grab.

• 
  

  Backend Networking Requirements

  The Load Balancer requires backends to have a public IP on their primary network interface and to sit on the same network segment as the load balancer. This means:

  • Standard VPS networking (non-VPC): Supported. Backends have a public IP on their primary interface and can receive load-balanced traffic directly.
  • VPC with Split NIC enabled: Supported. The split NIC provides a public IP on the primary interface while retaining a separate private interface for VPC traffic.
  • VPC with NAT-mode networking (no Split NIC): Not supported. NAT-mode backends sit behind the compute host's NAT gateway on a private network and cannot receive load-balanced traffic. If your backends are in NAT mode, you will need to enable Split NIC on each backend server.
• From the real server's point of view, the source IP is still the client - the load balancer is invisible.
• From the real server's point of view, the destination IP is the virtual IP. For this reason, the virtual IP must be added as a secondary address on each of the real servers. Our virtualisation stack will automatically block ARP on the real servers to prevent conflicts.
• The load balancer has a 60-second timeout on session stickiness (requests from one IP address will keep getting sent to the same real server within the 60-second window). After that point, a request could land on any server in the load-balanced pool.
• The load balancer only accepts and routes traffic on ports 80 and 443. It does not listen on or forward traffic for any other ports. Similarly, health check probes are restricted to those ports and cannot be configured to target alternatives.

Health checks and failover

• Each backend is checked with an HTTP request every 3 seconds. The interval cannot be changed.
• The check requests your load balancer's hostname with the path and protocol set under Settings > Health Check (or health_check.path and health_check.protocol in the API). A backend that answers with HTTP 200 receives traffic.
• Health checks run on ports 80 and 443 only.
• A backend that stops answering correctly is taken out of rotation about 9 to 10 seconds later.

Health-check path

The default path is /. A path must start with / and may contain only letters, digits and the characters / . ? = & + % _ -. An empty path is not accepted. A load balancer saved with an empty path before this check existed is checked as /.

If mPanel shows "Must be a valid URL path and start with '/'":

1. Open the load balancer in mPanel and go to Settings.
2. In Path, enter /, or the page you want checked, for example /health.
3. Select Save and Apply.

Through the API, send "path": "/" in health_check, or leave path out to use the default /.

Distribution and session stickiness

• Requests are shared round-robin across all backends that pass their health check.
• There is no backup or lower-priority backend setting. For an active/passive setup, have the standby backend deliberately fail its health check (for example by returning a non-200 status on the health-check path) until you promote it.
• Session stickiness keeps a client on the same backend for 60 seconds; after that, a request may go to any healthy backend.

HTTPS, certificates and client IP addresses

• The load balancer does not hold certificates or decrypt traffic. Each backend terminates its own TLS, so install your certificate on every backend.
• Backends see the real client IP address as the source of each connection, so you do not need X-Forwarded-For handling.
• Add the load balancer IP to each backend as a secondary address with a /32 prefix (see Step 1). A wider prefix such as /24 conflicts with your gateway route.
• Only IPv4 is supported; there is no IPv6 frontend.

Failover IPs, VPCs and Partner Server

• Failover IPs are assigned and reassigned in mPanel only; there is no API endpoint for assigning or reassigning them.
• VPCs are free. An existing server can be moved into a VPC after it is created, including through the API action ChangeNetwork (POST /v2/servers/{server_id}/actions). Backends in a VPC need Split NIC (see Backend Networking Requirements above).
• For a high-availability pair, enable the Partner Server setting so the two servers are not placed on the same host node.

Step 1: Configure Backend Networking

For the Load Balancer to function, your backend servers must be configured to accept traffic destined for the Load Balancer's Anycast IP. This is done by adding the Anycast IP to the loopback or primary interface.

Important
Without disabling the cloud-init network config, the netplan configuration will revert upon restarting your server. To disable the network configuration file, create a new network-config disabling configuration in `/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg` with the following content:

network: {config: disabled}

echo "network: {config: disabled}" > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

network:
    ethernets:
        eth0:
            addresses:
            - 112.213.38.164/24       # Your Server's Primary IP
            - 103.17.56.158/32        # Your Load Balancer IP (Add this line)
            gateway4: 112.213.38.1
            match:
                macaddress: 00:16:3e:f8:fc:b5
            set-name: eth0
    version: 2

sudo netplan apply

sudo apt-get update
sudo apt-get install -y apache2
sudo systemctl start apache2
sudo systemctl enable apache2

sudo mkdir -p /var/www/html/test-site

sudo nano /etc/apache2/sites-available/test-site.conf

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName yourdomain.com
    DocumentRoot /var/www/html/test-site
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

sudo a2ensite test-site.conf
sudo systemctl reload apache2

Important
Without disabling the cloud-init network config, the netplan configuration will revert upon restarting your 
To support HTTPS (port 443), you must add a <VirtualHost *:443> block with SSLEngine on and paths to your certificates.

sudo apt-get update
sudo apt-get install -y nginx
sudo systemctl start nginx
sudo systemctl enable nginx

sudo mkdir -p /var/www/html/test-site
# Create a test index file
echo "
Hello from Nginx
" | sudo tee /var/www/html/test-site/index.html

sudo nano /etc/nginx/sites-available/test-site

server {
    listen 80;
    server_name yourdomain.com;

    root /var/www/html/test-site;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo ln -s /etc/nginx/sites-available/test-site /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx