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

A screenshot of the Load Balancer configuration

Requirements:

  • At least two servers - required for high availability

  • Each VPS must be running a web server (for example, Apache or Internet Information Services)

  • Each VPS must serve basically the same content



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.



Load Balancer technical information:

  • 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.

  • 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.


Health Check Requirement:

Protocol:


  • Load Balancer sends an HTTP request to each server in the pool.

  • Servers need to respond with a 200 HTTP status code to show they're operational and ready to handle traffic.

  • The health check can be done over both HTTP and HTTPS, depending on the configuration of the Load Balancer.

Troubleshooting:


  • If a server doesn't respond with a 200 HTTP status code during a health check, it's seen as unhealthy, and the Load Balancer won’t send traffic to it until it passes the next health check.

  • Ensure there are no redirects from HTTP to HTTPS on the health check page that will return a 301 HTTP status


  • Review your web server setup and logs to fix issues with health check responses.