If you are looking to use CloudFlare Railgun to optimise the load times of dynamic (non-cached) content and you currently utilise a load balancer, a firewall or a NAT scheme in front of your application, please review the following configurations and best practices associated with each setup.
Single origin, multiple web servers, single Railgun listener.
(This is our recommended configuration)
We strongly encourage the installation of the Railgun client (rg-listener) “in front of” the load balancer/firewall/NAT scheme as per the illustration above.
Upon activation of the Railgun client you must specify in the railgun.conf file the public IP address of the server it is installed on (3.3.3.3) for the “activation.railgun_host” setting. This will tell CloudFlare to forward all requests via the rg-sender, for content that can’t be served from our edge servers, to this server instead of your origin (1.1.1.1).
Each request received by the server at 3.3.3.3 on port 2408 will then be processed by the rg-listener, have its host header checked and gets forwarded (by default) to the IP address of your origin server for the hostname according to your CloudFlare DNS configuration. The IP address gets sent with the request from rg-sender as an HTTP header - “CF-ORIGIN-IP”. The rg-listener strips out this header when forwarding requests to your origin over HTTP/S.
The reason we recommend this setup is because Railgun, by design, keeps a persistent and encrypted connection open on port 2408. Placing the Railgun in front of other network equipment:
- Allows load balancers to correctly distribute web requests to the web servers in the same way as it would without Railgun being used for the domain.
- Allows a firewall to analyze the unencrypted traffic for threats in the same way as it would without Railgun being used for the domain.
- Allows a NAT device to handle web requests in the same way as it would without Railgun being used for the domain.
If connectivity to the rg-listener can not be established from the CloudFlare edge servers we will automatically fallback to sending the request directly to your origin (1.1.1.1) over HTTP 1.1 and dynamic content compression will be disabled.
Single origin, multiple web servers, multiple Railgun listeners.
It is also possible to put multiple rg-listeners behind the load balancer and have Railgun accelerate dynamic content, this setup provides additional fault tolerance for the Railgun service.
For this configuration to work you need to create a single “Railgun Server” in your CloudFlare dashboard, install the rg-listener on all three of your web servers (2.2.2.1, 2.2.2.2, 2.2.2.3) and activate them all using the SAME Railgun activation token.
Within each of the railgun.conf files, you will also need to specify the public IP address of the load balancer (1.1.1.1) as the “activation.railgun_host”.
We advise experienced systems administrators and engineers to use this setup when the benefits of maintaining content compression when running in a degraded state (due to server or rg-listener failure) is important. Please consider the following, running Railgun behind a Load Balancer/Firewall/NAT could:
- Add complexity to the network device configuration as traffic inbound on port 2408 needs to be distributed across the rg-listeners.
- Prevent a Load Balancer from distributing requests correctly as all requests will be routed from the Load Balancer to the Railgun listeners in layer 4 (TCP) mode.
The traffic can not be decrypted until it reaches the servers.
- Prevent the firewall from analyzing incoming traffic as all inbound traffic from Cloudflare is encrypted with the Railgun's certificate.
- Mean the web servers need more resources to accommodate running the Railgun listener clients.
Also note that the server firewalls will need to be modified to allow traffic inbound on port 2408 as well as ensure connectivity with an instance of memcached can be established.
Having Railgun installed behind a load balancer requires that the “railgun-nat.conf” file (found in the Railgun directory) is modified to ensure that each of the rg-listeners knows where to forward requests to. By default each client will forward the request to the “CF-ORIGIN-IP” (1.1.1.1) which may work, but it is more likely you will want the request to be processed by the web server on the same server as the rg-listener that received the request.
The railgun-nat.conf file overrides the default behavior. You can either add each of your hostnames with an appropriate IP address (in our example the localhost IP) or simply uncomment “default=127.0.0.1”. The “default” value here tells rg-listener that any request for a hostname not defined in the file should be forwarded to this IP.
It is also recommended that a single centralised memcached instance is used by all of the servers running the rg-listener - ideally in an H/A clustered configuration for maximum uptime. Many hosting providers offer their own high-availability in-memory caching services that support memcached so you don’t have to build and maintain your own cluster. This will help to improve cache hit rates when rg-listener queries for a previously compressed version of an object to create deltas from.
Whilst separate memcached instances for each rg-listener will work the effectiveness of compression will be impacted.
If you need additional help in setting up Railgun with a Load Balancer/Firewall/NAT scheme, please contact support by opening up a ticket.
For more advanced configurations please contact our Enterprise Sales team for more details.