阿里云SLB最佳实践

一、SLB概念

Server Load Balancer通过智能分配策略将网络流量均匀分布至ECS集群中的多台服务器上

该服务系统具备自动健康监控功能并能动态识别可用资源

组成部分

负载均衡实例

虚拟地址池

监听机制

后端服务器集合体

负载均衡实例配置管理

负载均衡服务特性

二、使用限制

2.1 在 4 层（TCP 协议）服务中，不支持添加进后端云服务器池的 ECS 既作为 Real Server，又作为客户端向所在的 SLB 实例发送请求。因为，返回的数据包只在云服务器内部转发，不经过负载均衡，所以通过配置在 SLB 后端的 ECS 去访问其 VIP 是不通的。
2.2 仅支持 TCP/UDP（4 层） 和 HTTP/HTTPS（7 层） 这 4 种协议。
2.3 后端服务器仅支持 ECS，不支持第三方云服务器。
2.4 仅支持轮询（RR）、加权轮询（WRR）和最小加权连接数（WLC）这 3 中调度算法。
2.5 不支持 7 层 SSL Session 超时时间的调整。当前全局统一为 300s。
2.6 不支持 7 层 HTTP Keep-alive 超时时间的调整。当前配置为 15s。
说明：如果客户端访问 SLB HTTP 监听时使用长连接, 那么这条连接最长的空闲时间为 15 秒, 即如果超过 15 秒没有发送任何 HTTP 请求, 这条连接将会被 SLB 主动断开。如果您的业务可能会出现超过 15 秒的空闲, 需要从业务层面检测连接的断开并重新发起连接。
2.7 不支持转发超时时间的调整：
当前配置： TCP 900s，UDP 300s，HTTP 60s，HTTPS 60s
上述配置是指 SLB 服务端从后端接收数据并进行转发的超时时间，并非健康检查超时时间间隔。如果超时，通常会向客户端返回 504 错误码。
2.8 金融云 SLB 基于安全性考虑，仅允许开放特定的端口：80，443，2800-3300，6000-10000，13000-14000

三、SLB使用误区

3.1 SLB后端只添加一台ECS

当在SLB后端仅增加一台服务器时

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

用户使用 SLB 接口访问业务时出现了故障。
然而，在 host 环境下绑定到 ECS 后端服务的公网 IP 地址能够正常通信。
因此, 用户推断后端服务看似正常但实际上是由 SLB 服务层的问题导致整体访问出现问题。
实际上, 在负载均衡层的数据转发以及健康检查机制均基于内部网络运行。
因此, 在尝试基于 ECS 后台服务器的公网地址进行性能测试时缺乏依据。
建议在遇到问题时, 在 backend ECS 之间切换IP地址进行性能评估。

3.3 SLB 的 VIP 能 ping 通就说明配置是正常的

该系统通过向SLB的VIP地址发起ping请求来评估其服务的有效性。然而实际上这种方法存在明显的局限性。其中ping响应由SLB服务端直接处理与后端ECS无关。因此在常规情况下只要配置了任意一个监听节点即使相应的节点处于异常状态该节点的VIP地址ping测试仍能正常响应。相反如果目标SLB没有任何监听配置则其VIP地址将无法实现有效的ping连接。基于此建议针对四层架构的服务采用telnet方式探测其可用性；而针对七层架构的服务则应当通过实际业务访问来进行验证。

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

用户反馈已经反映并调高了健康检查的最大间隔时间设置。然而，在实际访问情况中发现，在某些场景下仍然会因请求超时而触发504错误。具体来说, 虽然健康检查功能以及业务转发逻辑都是由SLB服务端相同的服务器负责处理,但这两者属于完全不同的处理维度。例如, 来自客户端的请求通过SLB转发给后端ECS服务后,SLB服务端会针对接收到的数据建立一个超时窗口;同时,SLB服务端还会持续地根据配置中的检查间隔值对后端ECS进行健康的实时检测。需要注意的是,这两者之间并没有直接关联性,唯一的联系在于当后端ECS发生健康问题时,SLB不会继续进行数据转发操作。因此，在建议部分中提到:当客户端出现访问超时时应对比分析当前配置下的业务默认超时时间和当前配置下的SLB默认超时时间;而对于后端ECS的健康检查失败情况，则应对比分析当前配置下的健康检查间隔时间和业务相关的超时参数设置。

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

用户反馈通过SLB后端ECS的业务日志进行了数据分析，并观察到健康检查的时间间隔较短与之前配置的间隔存在差异

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

通过健康的配置，在SLB集群中部署了超过几十台服务器。然而，在任何情况下进行频繁的健康检查都不会达到DDoS攻击的程度。具体来说，在这种架构下

在配置合理的参数下，在每个服务监听端口上每隔O秒就会触发一次健康的实时监控。例如，在TCP协议下执行的健康发展查连接建立数量计算如下：

每秒由健康的_ health_check 产生的TCP连接建立数为：M×N/O。最终分析显示...

建议：如果出现业务被频繁 healthy_check 的情况，请参阅知识点 健康检查导致大量日志的处理 进行处理

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

该配置可能导致后端ECS出现异常时负载均衡需要较长时间才能完成检测并发现异常状态。特别地当后端ECS间歇性不可用时由于需要【连续多次

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

当配置SLB进行监听时, 可以指定最大允许传输速率, 但用户通过单一客户端进行测试时, 发现无论怎样都无法达到预期的最大带宽值

3.10 阿里云web应用防火墙（WAF）+SLB回话保持不生效

在防护网址流量入口部署WAF服务器时，在SLB上设置四层TCP/UDP端口监听可能导致后端Web应用之间的会话保持功能失效；为了解决此问题可采用七层 cookies 机制来实现会话保持；然而因业务环境限制必须依赖于四层TCP/UDP端口配置，则需要通过阿里云后台系统提交工单申请开启WAF的会话保持缓存功能以解决该问题

四、SLB最佳实践

4.1 业务架构

SLB 在公网环境中的主要应用场景如上图所示。通过多可用区特性，在主可用区出现故障时，SLB 会自动切换至备可用区提供服务。然而，在实际设计业务架构时，请特别关注以下几点：
为了减少网络延迟，在选择 SLB 部署地域时，请优先考虑与客户所在地 geospatial 接近的区域。
并非所有可用区域都具备多可用区功能（具体支持情况请参考控制台信息），因此在进行相关设计时，请结合业务需求合理选择主备可用区配置。
当采用多可用区策略时，请确保后端 ECS 服务也在对应的主备可用区进行部署，并根据具体情况动态平衡各区域的服务承载能力

4.2 监听配置

如上图所示，在SLB服务中可以创建多种协议监听，并根据转发策略将前端业务请求分配到后端多种逻辑服务器集合中进行处理。在SLB服务配置的各项关键步骤中，请特别关注以下内容。
选择监听协议
并非所有Web网站都需要必须使用HTTP协议。大部分无需特殊HTTP要求的Web网站只需配置TCP监听80端口即可满足基本业务需求。
SLB集群采用LVS和Tengine实现负载均衡功能。其中4层监听（基于TCP/UDP协议）经过LVS直接连接到后端服务器；而7层监听（基于HTTP/HTTPS协议）经过LVS后还需再经Tengine转发才能到达后端服务器。由于后者比前者多了一个转发环节的原因导致性能相对较低。
集合模式配置权重指定服务端口及服务器数量限制等参数
其他特性包括支持或不支持创建默认映射时的服务器集配置等设置。
虚拟服务器组支持无限制创建默认映射时的服务器集
主备服务器组最多支持2台且仅限于TCP/UDP监听场景下使用
根据业务需求可分别为不同的虚拟服务器组创建相应的负载均衡策略。
无论选择何种服务集合组合均需充分利用SLB多可用区特性并在不同可用区部署多台服务器以确保系统容灾能力。
建议避免过度增加转发规则以简化业务维护流程
选择转发策略
权重参数代表相应服务器所承载业务量的相对占比而非绝对数值当前SLB支持3种不同的转发策略每种策略都有其适用场景及操作要点：
加权轮询算法会按权重比例轮流分配新增连接请求以便平衡各服务节点的负载但这种做法可能导致老式服务节点连接数持续偏高而新加入节点的负载却相对较少从而造成明显的负载不平衡现象。
加权最小连接数算法则实时统计各服务节点已建立ESTABLISHED状态下的连接数并按权重比例将新增连接分配给当前负载较轻的服务节点最终使各节点的ESTABLISHED连接数与其权重呈正相关关系然而目前该算法尚未考虑新增节点过载保护机制因此当业务并发量过高时新增节点可能会出现过快增加的情况影响整体系统性能建议逐步提高新增节点的权重值以缓解这一问题。
轮询算法按照顺序依次将新增连接分配给各个服务节点这种做法虽然简单但必须确保后端服务具备足够的承载能力以避免潜在的问题。

五、建议

将所有可用区的服务器整合到同一个集中，并同步接入不同区域的服务实例，在确保同城区域高可用性的前提下实现同城容灾备份功能。
依据其硬件性能设置与其规模相匹配的负载分配系数，在保证业务稳定性的基础之上实现资源最优调度。
为了防止单一实例故障影响整体服务运行，在SLB后端至少配备两台及以上ECS实例。
建议采用同源镜像或定制化镜像构建后端ECS集群，并采取无需考虑数据同步问题的设计方案以简化管理流程。
通过统一规划和管理策略优化选择基于相同基础架构构建后端ECS集群的方式。
将SLB的服务入口地址开放至安全组和内部防火墙。