使用 Cloudflare 在源站进行负载平衡的一般使用技巧

了解如何将您当前的 Load Balancing 解决方案与 Cloudflare 集成。


概述

与 Cloudflare 集成时,在网站的主机环境中使用 Load Balancer 时,请考虑以下使用技巧:

  1. Cloudflare 的 DNS Load Balancing
  2. HTTP keep-alive
  3. 会话 Cookie
  4. Railgun

DNS Load Balancing

Cloudflare 的 Load Balancing 功能支持基于 DNS 的负载均衡,并会对您的源站进行运行状况检查。它在 Cloudflare 的现有 Anycast DNS 网络上进行了扩展,以提供无惧于 DDoS 的故障转移(绕过不健康的源站)和地理转向(将用户定向到特定的源站池)。

HTTP 保持连接(HTTP 持久连接)

由于 Cloudflare 代理了从边缘网络到站点源的客户流量,Cloudflare 保持 keep-alive 连接以提升性能并降低请求交易中 TCP 重复连接的成本。

因此,我们强烈建议在 Load Balancer 上启用 HTTP Keep-Alive 连接,并将 keep-alive 超时设置为至少 300 秒,以匹配 Cloudflare 的默认设置。

这将避免过早重置 Cloudflare 代理的请求的连接,或 Load Balancer 出现超时。

会话 Cookie

如果使用 HTTP Cookie 追踪并将用户会话绑定到负载平衡器上的某个特定的应用服务器,最好对 Load Balancer 进行配置,使之按 Cooke 标头解析 HTTP 请求,并将每个请求定向到正确的应用服务器,即便由于 keep-alive,所有 HTTP 请求都共享的是同一个 TCP 连接。

例如:F5 BIG-IP Load Balancer 将在 TCP 连接开始时设置会话 Cookie(若不存在),然后忽略在同一 TCP 套接字上进行的后续 HTTP 请求中传递的所有 Cookie。由于 Cloudflare 将通过同一 TCP 连接发送多个不同的 HTTP 会话,因此这往往会破坏会话粘性。(基于 HTTP Cookie 的会话粘性)。

Railgun(WAN 优化)

使用 Railgun 和 Load Balancer 时,理想的设置是将 Railgun Listener 置于 Load Balancer 的前面。因为很难为 Sender/Listener 之间持久的 TLS 连接平衡负载,理想的设置是将 Listener 放在前面,这样 LB 即可正常处理 HTTP/S 连接。



由于 Railgun 用作 HTTP 反向代理,因此如果没有 Railgun,则 Load Balancer 设置应与已启用的设置匹配(即应启用 HTTP 保持活动连接并将其设置为 90 秒超时)。

如果将 Railgun 放在 Load Balancer 的后面,此设置仍然可以正常作用,但是需要采取其他步骤以避免站点流量中断:

  1. 配置 railgun-nat.conf 文件来设置 Railgun 将得到优化的主机的内部地址(以避免将请求向外循环到 Internet 并返回到 LB 以转发到原点。)
  2. 确认没有防火墙规则会阻止侦听器与源站之间的通信量或限速。
  3. 确认端口 2408 为打开状态并通过 LB,且监听器和发送器之间的 TLS 连接没有受到任何阻碍。

相关资源

配置 Cloudflare Load Balancing

 

 

Not finding what you need?

95% of questions can be answered using the search tool. This is the quickest way to get a response.

由 Zendesk 提供技术支持