When integrating with Cloudflare, please consider the following for best practices when utilizing load balancers within your website's host environment:
- Cloudflare's DNS Load Balancing
- HTTP keep-alive
- Session cookies
DNS Load Balancing
Cloudflare's Load Balancing feature supports DNS-based load balancing with active health checks against your origin servers. It expands on Cloudflare's existing Anycast DNS network to provide DDoS-resilient failover (steering around unhealthy origins) and geo-steering (directing users to specific pools of origins).
HTTP keep-alive (HTTP persistent connection)
Cloudflare maintains keep-alive connections to improve performance and reduce cost of recurring TCP connects in the request transaction as Cloudflare proxies customer traffic from its edge network to the site's origin.
As such, it is strongly encouraged to ensure that HTTP Keep-Alive connections are enabled on the load balancer and set the keep-alive timeout to at least 300 seconds to match the default settings from Cloudflare.
This will avoid the connections for requests proxied by Cloudflare being reset prematurely, or experiencing timeouts from the load balancer.
If using HTTP cookies to track and bind user sessions to a specific application server at the load balancer, it is best is to configure the load balancer to parse HTTP requests by cookie headers and directing each request to the correct application server even if HTTP requests share the same TCP connection due to keep-alive.
For example: F5 BIG-IP load balancers will set a session cookie (if none exists) at the beginning of a TCP connection and then ignore all cookies passed on subsequent HTTP requests made on the same TCP socket. This tends to break session affinity because Cloudflare will send multiple different HTTP sessions on the same TCP connection. (HTTP cookie-based session affinity).
Railgun (WAN Optimization)
The ideal setup when using Railgun and a load balancer is to place the Railgun listener in front of the load balancer. Placing the listener in front is the ideal setup, as that allows the LB to handle the HTTP/S connections as normal, as it is difficult to load balance the long-lived TLS connection between the sender/listener.
Since Railgun is working as an HTTP reverse proxy, load balancer settings should match those enabled if Railgun was not in place (i.e. HTTP keep-alive connections should be enabled and set to a 90 second timeout).
If Railgun is placed behind the load balancer, this setup will still work, but requires additional steps to avoid any interruptions with site traffic:
- Configure the railgun-nat.conf file to set the internal address of the hosts Railgun will be optimizing (to avoid looping the request outbound to the internet and back to LB to be forwarded to origin).
- Confirm no Firewall rules are in place that will impede or rate-limit the traffic between the listener and the origin server.
- Confirm port 2408 is open and passed through the LB without any hinderance for the TLS connection between the listener and sender.