负载均衡（SLB）使用常见误区
发布时间：2017-05-16 18:03

负载均衡（Server Load Balancer，下文简称 SLB）的引入，可以降低单台云服务器 ECS（下文简称 ECS）出现异常时对业务的冲击，提升业务的可用性。同时，结合弹性伸缩服务，通过动态调整后端服务器，可以快速对业务进行弹性调整（扩容或缩容），以快速应对业务的发展。

SLB 常见误区

从历史案例看，用户在 SLB 的规划和使用过程中有很多常见误区。接下来逐一说明。

误区：SLB 后端只需添加一台 ECS ，确保链路能跑通即可

用户在 SLB 后端只添加一台服务器时，虽然链路能跑通，客户端也能正常访问。但却失去了 SLB 消除 ECS 单点的基本能力。如果这台仅有的 ECS 出现异常，那边整个业务访问也会出现异常。

建议：至少在 SLB 后端加入两台以上 ECS。以便单一服务器出现异常时，业务还能持续正常访问。

误区：后端 ECS 能正常访问，但 SLB 无法访问，则说明 SLB 出现了异常

用户通过 SLB 访问业务出现异常。但 hosts 绑定后端 ECS 的公网 IP 能正常访问。用户据此推断后端业务是正常的，是 SLB 服务端出现异常导致业务访问异常。

其实，由于负载均衡的数据转发和健康检查都是通过内网进行的。所以，从后端 ECS 的公网 IP 进行对比访问测试，并没有可比性，并不能反应真实访问情况。

建议：出现异常时，在后端 ECS 之间，通过内网 IP 做对比访问测试。

误区： SLB 的 VIP 能 ping 通就说明配置是正常的

用户通过 ping SLB 的 VIP 地址来判断 SLB 服务的有效性。

其实，这种测试非常不可靠。因为 ping 响应是由 SLB 服务端直接完成的，与后端 ECS 无关。所以，正常情况下：

• 只要配置了任意监听，即便相应监听处于异常状态，SLB VIP ping 也是正常的。
• 相反，如果 SLB 没有配置任何监听，其 VIP 是 ping 不通的。

建议：对于 4 层服务，通过 telnet 监听端口进行业务可用性测试；对于 7 层服务，通过实际的业务访问进行可用性测试。

误区：已经调整了健康检查间隔，结果还会出现访问超时

用户反馈已经调大了健康检查的最大间隔时间，但客户端访还是由于访问超时收到 504 错误。

其实，虽然健康检查及业务转发都是由 SLB 服务端相同的服务器承载，但却是完全不同维度的处理逻辑。来自客户端的请求，经由 SLB 转发给后端 ECS 后，SLB 服务端会有接收数据的超时窗口。而另一方面，SLB 服务端持续的对后端 ECS 根据检查间隔配置进行健康检查。这两者之间没有直接关系，唯一的影响是在后端 ECS 健康检查失败后，SLB 不会再对其进行数据转发。

建议：客户端访问超时时，结合业务与 SLB 默认超时时间进行比对分析；健康检查超时时，结合健康检查与业务超时时间进行比对分析。

误区：从后端日志看，健康检查间隔与监听配置的间隔时间不一致

用户反馈通过 SLB 后端 ECS 的业务日志进行统计分析，发现健康检查的间隔非常短，与之前在创建监听时配置的健康检查间隔时间不一致。

这个问题在文档 负载均衡健康检查原理浅析 有相关说明：LVS 集群内所有节点，都会独立、并行的遵循该属性去对后端 ECS 进行定期健康检查。由于各 LVS 节点的检查时间并不同步，所以，如果从后端某一 ECS 上进行单独统计，会发现来自负载均衡的健康检查请求在时间上并不会遵循上述时间间隔。

建议：如果健康检查频率过高对业务造成影响，可以参阅知识点 健康检查导致大量日志的处理 进行处理。

误区：大量健康检查形成 DDoS 攻击，导致服务器性能下降

用户认为 SLB 服务端使用上百台机器进行健康检查，大量健康检查请求会形成 DDoS 攻击，造成后端 ECS 性能降低。

实际上，无论何种模式的健康检查，其规模均不足以达到类似于 DDoS 攻击的量级：SLB 集群会利用多台机器（假定为 M 个，个位数级别），对后端 ECS 的每个服务监听端口 （假定为 N 个） ，按照配置的健康检查间隔（假定为 O 秒，一般建议最少 2 秒）进行健康检查。以 TCP 协议健康检查为例，那么每秒由健康检查产生的 TCP 连接建立数为：M*N/O。

从该公式可以看出，M 和 N 都是固定的，而且值很小。所以，最终健康检查带来的每秒 TCP 并发请求数，主要取决于创建的监听端口数量。所以，除非有巨量的监听端口，否则由健康检查产生的连接请求，根本无法达到 SYN Flood 的攻击级别，实际对后端 ECS 的网络压力也极低。

建议： 如果健康检查频率过高对业务造成影响，可以参阅知识点 健康检查导致大量日志的处理 进行处理。

误区：用户为了降低健康检查的影响，将健康检查间隔设置得很长

用户为了降低健康检查对业务的影响，将检查间隔时间设置得很长。

这样配置会导致当后端 ECS 出现异常时，负载均衡需要经过较长时间才能侦测到后端 ECS 出现不可用。尤其是当后端 ECS 间歇性不可用时，由于需要【连续多次】检测失败时才会移除异常 ECS。所以，检查间隔过长，会导致负载均衡集群可能根本无法发现后端 ECS 不可用。

建议： 如果健康检查频率过高对业务造成影响，可以参阅知识点 健康检查导致大量日志的处理 进行处理。

误区：移除服务器与权重置零的效果是一样的

用户在进行业务调整时，认为直接将服务器从 SLB 后端移除，或将其权重置零即可，两者效果是一样的。

其实，两者有很大区别，相关操作对业务的影响也不一致：

• 移除服务器：已经建立的连接会一并中断，新建连接也不会再转发到该 ECS。
• 权重置零：已经建立的连接不会中断，直至超时或主动断开。新连接不会转到该 ECS。

建议：在业务调整或服务器维护时，提前将相应服务器的权重置零，直至连接持续衰减至零。操作完成后，再恢复权重配置，以降低对业务的影响。

误区：单个连接就能达到监听配置的带宽峰值

SLB 在创建监听时可以指定带宽峰值。但用户通过单一客户端进行测试时，发现始终无法达到该峰值。

由于 SLB 是基于集群方式部署和提供服务的。所以，所有前端请求会被均分到集群内不同的 SLB 服务器上进行转发。相应的，在监听上设定的带宽峰值也会被平分后设定到各服务器。因此，单个连接下载的流量上限公式为：

单个连接下载峰值=设置的负载均衡总带宽/(N-1) 
*注：N 为流量转发分组个数，当前值一般为 4 

示例：
假设在控制台上设置的带宽峰值为 10Mb，那么单个客户端可下载的最大流量为： 10/(4-1)≈3.33Mb

建议：建议在配置单个监听的带宽峰值时，根据实际的业务情况并结合上述实现方式设定一个较为合理的值，从而确保业务的正常对外服务不会受到影响和限制。