4、负载均衡 SLB
负载均衡 SLB(Server Load Balancer)是一种对流量进行按需分发的服务,通过将流量分发到不同的后端服务器来扩展应用系统的吞吐能力,并且可以消除系统中的单点故障,提升应用系统的可用性。
4.1、产品简介
阿里云提供全托管式在线负载均衡服务,具有即开即用、超大容量、稳定可靠、弹性伸缩、按需付费等特点,适合超大规模互联网应用,如春节红包、双十一秒杀抢购、大规模在线物联网应用等高并发场景。
与传统的硬件型负载均衡自建方案相比,无需一次性大额投入,便可拥有天猫双十一级别的海量流量分发处理能力。
同时,与开源的负载均衡自建方案相比,阿里云负载均衡稳定可靠,配备专业的运维团队,免费提供 7×24 小时不间断技术支持服务,帮助您提升运维效率。
4.2、产品类型
随着网络型负载均衡NLB(Network Load Balancer )、应用型负载均衡ALB(Application Load Balancer)的加入,原负载均衡SLB(Server Load Balancer)现称为传统型负载均衡CLB(Classic Load Balancer),负载均衡SLB为负载均衡产品家族的总称。
阿里云负载均衡 SLB 支持以下类型的负载均衡:
- 应用型负载均衡 ALB(Application Load Balancer):专门面向七层,提供超强的业务处理性能,例如 HTTPS 卸载能力。单实例每秒查询数 QPS(Query Per Second)可达 100 万次。同时 ALB 提供基于内容的高级路由特性,例如基于 HTTP 报头、Cookie 和查询字符串进行转发、重定向和重写等,是阿里云官方云原生 Ingress 网关。更多信息,请参见什么是应用型负载均衡 ALB。
- 网络型负载均衡 NLB(Network Load Balancer):面向万物互联时代推出的新一代四层负载均衡,支持超高性能和自动弹性能力,单实例可以达到 1 亿并发连接,帮您轻松应对高并发业务。NLB 面向海量终端连接、高并发消息服务、音视频传输等业务场景针对性地推出了 TCPSSL 卸载、新建连接限速、全端口监听等高级特性,在物联网 MQTTS 加密卸载等场景为用户提供多种辅助手段,是适合 IoT 业务的新一代负载均衡。更多信息,请参见什么是网络型负载均衡 NLB。
- 传统型负载均衡CLB(Classic Load Balancer):支持TCP、UDP、HTTP和HTTPS协议,具备良好的四层处理能力,以及基础的七层处理能力。更多信息,请参见什么是传统型负载均衡CLB。
4.3、网络型负载均衡 NLB
网络型负载均衡 NLB(Network Load Balancer )是阿里云面向万物互联时代推出的新一代四层负载均衡,支持超高性能和自动弹性能力,单实例可以达到 1 亿并发连接,帮您轻松应对高并发业务。
4.3.1、产品特点
4.3.2、应用场景
-
物联网业务入口
在智能家居、智能停车、视频监控、车联网等业务场景中,NLB 作为业务入口可以同时处理海量并发连接,同时提供 TCPSSL 卸载、连接限速等能力保障物联网业务安全稳定运行。
-
互联网云上业务入口
NLB 作为互联网流量入口,单实例提供超高的四层处理能力,同时可以基于业务变化自动弹性伸缩,业务波动时无需手工干预,降低了运维管理成本。
-
混合云业务入口
NLB 支持挂载本地 IDC(Internet Data Center)服务器,可以搭配云企业网等产品将云上请求转发至线下服务器处理,轻松实现线下 IDC 与云上服务互通。
4.3.3、NLB 组成
概念 | 说明 |
---|---|
实例 | NLB面向四层,提供了强大的四层负载均衡能力,通过将流量分发至不同的后端服务器来扩展应用系统的服务吞吐能力。 单实例最大支持1亿并发连接。 |
监听 | 监听是NLB最小业务单元,监听上需要配置协议与端口以告知NLB需要处理什么流量,例如TCP协议,80端口。 NLB支持TCP、UDP、TCPSSL协议。每个NLB至少有一个监听,才能开始流量处理与分发。 每个NLB默认最多可以配置50个监听,用于处理不同的业务流量。 |
服务器组 | 服务器组是一个逻辑组,包含多个后端服务器用于处理NLB分发的业务请求。 NLB中的服务器组独立于NLB存在,可以将同一服务器组挂载在不同NLB内。 每个服务器组默认最多可以添加1000个后端服务器。 NLB服务器组支持: - 云服务器ECS(Elastic Compute Service) - 弹性容器实例ECI(Elastic Container Instance) - 弹性网卡ENI(Elastic Network Interface) - IP类型的后端服务器。 更多信息,请参见: - 什么是云服务器ECS - 什么是弹性容器实例ECI - 弹性网卡ENI概述 - IP类型后端服务器说明 |
健康检查 | NLB通过健康检查来判断后端服务器的业务可用性。 NLB探测服务器组中不健康的服务器,并避免将流量分发给不健康的服务器。 NLB支持丰富灵活的健康检查配置,如协议、端口、以及各种健康检查阈值。 |
4.3.4、NLB 类型
本文从网络类型和协议版本两个方面介绍 NLB 类型。下图为您展示双栈公网 NLB 和双栈私网 NLB。
4.3.5、网络类型
阿里云提供公网和私网两种网络类型的 NLB。您可以根据业务场景选择配置对外公开或对内私有的 NLB,系统会根据您的选择来决定是否使用共享带宽和弹性公网 IP。上图中半透明框中所有元素分别实现了一个面向公网(私网)的 NLB。
4.3.6、协议版本
NLB 协议版本分为 IPv4 和双栈。
4.3.7、功能特性
本文为您介绍网络型负载均衡 NLB 的主要功能以及 NLB 与传统型负载均衡 CLB 在四层负载均衡能力上的对比。
下表展示了 NLB 主要功能及 NLB 与 CLB 的功能差异。
说明 “-”代表不支持;“✔”代表支持。
4.3.8、NLB 支持的地域信息
本文为您介绍网络型负载均衡 NLB(Network Load Balancer )支持的地域(Region)信息。
4.3.8.1、地域和可用区概述
地域是指数据中心所在的物理位置,资源创建成功后不能更换地域。可用区是指在同一地域内,电力和网络互相独立的技术设施区域,即一个可用区出现基础设施故障不影响另外一个可用区。每个地域完全独立,不同地域的可用区完全隔离,但同一个地域内的可用区之间使用低时延链路相连。
为了向广大用户提供更加稳定可靠的负载均衡服务,NLB 可将流量跨可用区分发,将业务负载到您选择的可用区,不同可用区间建立实时的业务容灾,某个可用区故障不影响其它可用区的流量转发。
4.3.8.2、NLB 支持的地域
下述表格中 NLB 支持的地域仅供参考,实际支持的地域和可用区请以购买页为准。
4.4、应用型负载均衡 ALB
应用型负载均衡 ALB(Application Load Balancer)是阿里云推出的专门面向 HTTP、HTTPS 和 QUIC 等应用层负载场景的负载均衡服务,具备超强弹性及大规模应用层流量处理能力,并提供最高 99.995% 的 SLA 可用性保障。ALB 具备处理复杂业务路由的能力,与云原生相关服务深度集成,是阿里云官方提供的云原生 Ingress 网关。
4.4.1、应用型负载均衡 ALB 优势
应用型负载均衡 ALB,提供强大的应用层处理能力和丰富的高级路由功能,聚焦 HTTP、HTTPS 和 QUIC 应用层协议,是阿里云官方云原生 Ingress 网关。关于云原生网关 ALB Ingress 的介绍和使用,请参见ALB Ingress概述和ALB Ingress功能。
4.4.2、实例性能指标
ALB 的 IP 模式分为动态IP和固定IP。动态 IP 和固定 IP 的 ALB 实例的实例性能存在差异。
说明 ALB 实例性能指标仅与 ALB 的 IP 模式相关,与 ALB 功能版本无关。
说明
- 固定IP模式下,您可以使用CNAME或A记录解析对外提供访问,双可用区ALB实例可提供10万QPS的性能。动态IP模式下,如需达到100万QPS,请您使用CNAME域名解析的方式。
- ALB支持多可用区部署,若当前地域支持2个及2个以上可用区,为保障业务高可用,请至少选择2个可用区,且ALB不会额外收取可用区的费用。
4.4.3、ALB 组成
4.4.4、ALB 类型
阿里云提供公网和私网两种类型的 ALB。您可以根据业务场景选择配置对外公开或对内私有的 ALB,系统会根据您的选择来决定是否使用共享带宽和弹性公网 IP。
上图中半透明框中所有元素分别实现了一个面向公网(私网)的 ALB。
4.4.5、功能特性
应用型负载均衡 ALB 包含基础版、标准版和WAF增强版。本文为您介绍 ALB 的基础版、标准版和 WAF 增强版的功能特性和差异。
ALB 的基础版、标准版和 WAF 增强版的功能特性和差异如下:
说明 ALB实例性能指标仅与ALB的IP模式相关,与ALB功能版本无关。关于ALB实例性能指标,请参见实例性能指标。
功能 | 基础版 | 标准版 | WAF增强版 |
---|---|---|---|
监听协议 | |||
QUIC协议 | 支持 | 支持 | 支持 |
HTTP/2协议 | 支持 | 支持 | 支持 |
WEBSOCKET协议 | 支持 | 支持 | 支持 |
转发规则 | |||
基于域名或路径匹配 | 支持 | 支持 | 支持 |
基于HTTP Header匹配 | 支持 | 支持 | 支持 |
基于查询字符串匹配 | 不支持 | 支持 | 支持 |
基于Cookie匹配 | 不支持 | 支持 | 支持 |
基于HTTP请求方法匹配 | 不支持 | 支持 | 支持 |
基于源IP匹配 | 不支持 | 支持 | 支持 |
基于响应中的状态码匹配 | 不支持 | 支持 | 支持 |
基于响应中的Header匹配 | 不支持 | 支持 | 支持 |
重定向 | 支持 | 支持 | 支持 |
重写或返回固定响应 | 不支持 | 支持 | 支持 |
写入Header或删除Header | 不支持 | 支持 | 支持 |
流量镜像 | 不支持 | 支持 | 支持 |
QPS限速 | 不支持 | 支持 | 支持 |
可编程脚本AScript | 不支持 | 支持(默认不开放) | 支持 |
安全 | |||
访问控制黑白名单 | 支持 | 支持 | 支持 |
TLS加密算法套件选择 | 支持 | 支持 | 支持 |
SNI多证书支持 | 支持 | 支持 | 支持 |
RSA&ECC双证书 | 支持 | 支持 | 支持 |
ECC证书 | 支持 | 支持 | 支持 |
全链路HTTPS | 不支持 | 支持 | 支持 |
自定义TLS算法套件 | 不支持 | 支持 | 支持 |
TLS 1.3协议支持 | 支持 | 支持 | 支持 |
Web应用安全防护(WAF) | 不支持 | 不支持 | 支持 |
监控统计 | |||
访问日志 | 支持 | 支持 | 支持 |
4.4.6、案例
开心消消乐作为一款深受国民喜爱的单机游戏,经常面临大流量和高并发场景。为了更好调度流量并实现负载分担,开心消消乐通过应用型负载均衡 ALB(Application Load Balancer)转发流量,实现按需弹性的方式应对大流量和高并发场景。本文以开心消消乐为例说明 ALB 解决方案的客户需求、方案架构、以及方案优势等内容。
4.4.6.1、客户需求
开心消消乐经常会在某些节庆日、特定运营活动节点迎来流量高峰。开心消消乐大数据中心会通过分析游戏运行指标,按需调度流量升级终端用户的服务体验。但由于活动前无法预估业务高峰会达到多大的流量水平,因此常常需要根据地域、时间段、终端等数据分析临时手工增减机器。
IT 网络运维管理人员经常面临以下问题:
- 运维管理工作量大:有⾼并发流量、⾼ QPS 需求时,运维人员需要管理多组服务端进⾏业务负载分担,运维管理工作量大。
- 重要业务需要人工干预多:在业务高峰期,为保障重要请求不受影响,需要部署两组服务器端,且需要根据 URL 进行手工调度。
- 七层业务调度最佳路由能力差:部分业务需要基于 Header 调度时,由于七层路由能力有限导致业务一直在服务端运行。
4.4.6.2、方案架构
因为 ALB 单实例七层处理能力高达 100 万 QPS,能够自动根据用户访问量调度流量,从容应对大流量和高并发场景。所以推出 ALB 解决方案来确保开心消消乐在大流量和高并发场景下更好地调度流量。方案架构如下图所示。
4.4.6.3、方案优势
- 超强性能,按需弹性:单个ALB实例可提供⾼达100万QPS能⼒,运维人员无需预估业务高峰值,ALB即可根据实际业务情况,自动弹性地应对业务高峰。
- 简化运维,节约人力:DDoS直接回源ALB,将以往多个实例合并为⼀个ALB实例,降低日常运维管理难度。
- 更低时延,更优体验:部署一套服务端,通过URL转发规则实现不同优先级业务的差异化调度,满足个性化路由转发需要。
- 面向未来,可扩展:ALB可以作为容器的Ingress入口,容器化技术演进可平滑升级。
4.5、传统型负载均衡 CLB
传统型负载均衡 CLB(Classic Load Balancer)是将访问流量根据转发策略分发到后端多台云服务器的流量分发控制服务。CLB 扩展了应用的服务能力,增强了应用的可用性。
4.5.1、概述
CLB 通过设置虚拟服务地址,将添加的同一地域的多台云服务器虚拟成一个高性能和高可用的后端服务池,并根据转发规则,将来自客户端的请求分发给后端服务器池中的云服务器。
CLB 默认检查云服务器池中的云服务器的健康状态,自动隔离异常状态的云服务器,消除了单台云服务器的单点故障,提高了应用的整体服务能力。此外,CLB 还具备抗 DDoS 攻击的能力,增强了应用服务的防护能力。
4.5.2、CLB 组成
说明 上图中灰色的云服务器代表该云服务器健康检查失败,流量不会转发到该云服务器上。
CLB 由以下三个部分组成:
组成 | 说明 |
---|---|
实例 | 一个CLB实例是一个运行的负载均衡服务,用来接收流量并将其分配给后端服务器。 要使用负载均衡服务,您必须创建一个CLB实例,并至少添加一个监听和两台云服务器。 |
监听 | 监听用来检查客户端请求并将请求转发给后端服务器。 监听也会对后端服务器进行健康检查。 |
后端服务器 | 后端服务器是一组接收前端请求的云服务器,目前CLB支持添加: - 云服务器ECS(Elastic Compute Service) - 弹性容器实例ECI(Elastic Container Instance) - 弹性网卡ENI(Elastic Network Interface) 作为后端服务器。 您可以单独添加云服务器到后端服务器池,也可以通过虚拟服务器组或主备服务器组来批量添加和管理。 更多信息,请参见: - 什么是云服务器ECS - 什么是弹性容器实例ECI - 弹性网卡ENI概述 |
4.5.3、产品优势
-
高可用
采用全冗余设计,无单点,支持同城容灾。
根据流量负载进行弹性扩容,在流量波动情况下不中断对外服务。
-
可扩展
您可以根据业务的需要,随时增加或减少后端服务器的数量,扩展应用的服务能力。
-
低成本
与传统硬件负载均衡系统高投入相比,成本可下降60%。
-
安全
结合云盾,可提供5 Gbps的防DDoS攻击能力。
-
高并发
集群支持亿级并发连接,单实例最大支持100万并发。
4.5.4、访问 CLB
通过注册阿里云账号,您可以通过以下方式访问和管理 CLB:
- 传统型负载均衡CLB控制台:具有交互式操作的Web服务页面。您可登录控制台完成CLB实例的创建、使用或释放,具体操作,请参见创建和管理CLB实例。
- 阿里云SDK:提供Java、Go、PHP、Python、C#、C++等多种编程语言的SDK。
- OpenAPI开发者门户:提供快速检索接口、在线调用API和动态生成SDK示例代码等服务。
- 阿里云App:移动端类型的管理工具。
- Terraform:能够通过配置文件在阿里云以及其他支持Terraform的云商平台调用计算资源,并对其进行版本控制的开源工具。
4.5.5、功能特性
本文介绍阿里云传统型负载均衡CLB提供的功能和功能概述,CLB支持4层和7层负载均衡,并提供健康检查、会话保持、域名转发等功能,保证后端服务的高可用。
下表中,“✔”表示支持,“—”表示不支持。
功能 | 4 层CLB | 7 层CLB |
---|---|---|
调度算法CLB支持轮询、加权轮询(WRR)和一致性哈希(CH)调度算法。 | ✔ | ✔ |
健康检查CLB会检查后端服务器的运行状况。 当探测到后端服务器运行状况不佳时,会停止向其发送流量,然后将流量转发给其他正常运行的后端服务器。 |
✔ | ✔ |
会话保持CLB提供会话保持功能。在会话的生命周期内,可以将同一客户端的请求转发到同一台后端服务器上。 | ✔ | ✔ |
访问控制CLB支持添加黑名单和白名单,灵活控制客户端访问。 | ✔ | ✔ |
高可用CLB可以将流量转发给多个可用区的后端服务器。 并且,CLB已经在大部分地域支持了多可用区部署,当主可用区出现故障时,可自动切换到备可用区上提供服务。 |
✔ | ✔ |
安全防护结合云盾,可提供5 Gbps的防DDoS攻击能力。 | ✔ | ✔ |
网络类型支持CLB提供公网和私网类型的负载均衡服务。 您可以创建一个私网类型的CLB实例来均衡专有网络内的流量,或创建一个公网CLB实例来均衡来自公网的流量。 |
✔ | ✔ |
监控结合阿里云云监控服务,您可以查看CLB的连接数、流量等信息。 | ✔ | ✔ |
IPv6地址支持CLB支持转发来自IPv6客户端的请求。 | ✔ | ✔ |
记录健康检查日志CLB默认存储三天内的健康检查日志。 您可以通过开通OSS服务,将所有的健康检查日志存储到OSS中,分析后端服务器异常原因。 |
✔ | ✔ |
域名URL转发CLB7层监听支持配置域名和URL转发规则,可以将来自不同域名和URL的请求转发到不同的后端服务器上。 | — | ✔ |
证书管理针对HTTPS协议,提供统一的证书管理服务。 证书无需上传到后端服务器,解密处理在CLB上进行,降低后端服务器的CPU开销。 |
— | ✔ |
SNI支持CLB HTTPS监听支持挂载多个证书,将来自不同访问域名的请求转发至不同的后端服务器组。 | — | ✔ |
重定向CLB支持HTTP访问重定向至HTTPS。 | — | ✔ |
WS/WSS原生支持WebSocket是HTML5一种新的协议, 在客户端与服务器间提供双向通信渠道, 能更好地节省服务器资源和带宽并达到实时通讯。 |
— | ✔ |
HTTP 2.0原生支持 HTTP 2.0(Hypertext Transfer Protocol Version 2)是超文本传输协议的第二版,向下兼容 HTTP 1.X协议版本,同时带来性能的大幅提升。 |
— | ✔ |
4.5.6、产品架构
负载均衡基础架构是采用集群部署,提供四层(TCP协议和UDP协议)和七层(HTTP和HTTPS协议)的负载均衡,可实现会话同步,以消除服务器单点故障,提升冗余,保证服务的稳定性。
负载均衡作为流量转发服务,将来自客户端的请求通过负载均衡集群转发至后端服务器,后端服务器再将响应通过内网返回给负载均衡。
4.5.6.1、基础架构说明
阿里云当前提供四层和七层的负载均衡服务。
- 四层采用开源软件LVS(Linux Virtual Server)+ keepalived的方式实现负载均衡,并根据云计算需求对其进行了个性化定制。
- 七层采用Tengine实现负载均衡。Tengine是由淘宝网发起的Web服务器项目,它在Nginx的基础上,针对有大访问量的网站需求,添加了很多高级功能和特性。
如下图所示,各个地域的四层负载均衡实际上是由多台LVS机器部署成一个LVS集群来运行的。采用集群部署模式极大地保证了异常情况下负载均衡服务的可用性、稳定性与可扩展性。
LVS集群内的每台LVS都会将所有会话通过组播报文同步到该集群内的其它LVS机器上。如下图所示,当客户端向服务端传输三个数据包后,在LVS1上建立的会话A开始同步到其它LVS机器上。
图中实线表示现有的连接,图中虚线表示当LVS1出现故障或进行维护时,这部分流量会走到一台可以正常运行的机器LVS2上。因而负载均衡集群支持热升级,并且在机器故障和集群维护时最大程度对用户透明,不影响用户业务。
说明 对于连接未建立(三次握手未完成),或者已建立连接但未触发会话同步机制,热升级不保证连接不中断,需要依靠客户端重新发起连接。
4.5.6.2、入网流量路径
对于入网流量,CLB会根据用户在控制台或API上配置的转发策略,对来自前端的访问请求进行转发和处理,数据流转如下图所示。
图 1. 入网流量路径
- TCP/UDP协议和HTTP/HTTPS协议的流量都需要经过LVS集群进行转发。
- LVS集群内的每一台节点服务器均匀地分配海量访问请求,并且每一台节点服务器之间都有会话同步策略,以保证高可用。
- 如果相应的CLB实例服务端口使用的是四层协议(TCP或UDP),那么LVS集群内每个节点都会根据CLB实例的策略,将其承载的服务请求按策略直接分发到后端ECS服务器。
- 如果相应的CLB实例服务端口使用的是七层HTTP协议,那么LVS集群内每个节点会先将其承载的服务请求均分到Tengine集群,Tengine集群内的每个节点再根据CLB策略,将服务请求按策略最终分发到后端ECS服务器。
- 如果相应的CLB实例服务端口使用的是七层HTTPS协议,与上述HTTP处理过程类似,差别是在按策略将服务请求最终分发到后端ECS服务器前,先调用Key Server进行证书验证及数据包加解密等前置操作。
4.5.6.3、出网流量路径
CLB和后端ECS之间是通过内网进行通信的。
-
如果ECS仅仅处理来自CLB的请求,可以不购买公网带宽(ECS、公网IP、弹性公网IP、NAT网关等)。
说明 早期创建的一些ECS上直接分配了公网IP(在实例中执行
ipconfig
命令可以查看公网IP地址),此类ECS如果仅通过CLB对外提供服务,即便在公网接口(网卡)上看到有流量统计,也不会产生ECS的公网费用。 -
如果需要直接通过后端ECS对外提供服务,或后端ECS有访问外网的需求,那么需要相应的配置或购买ECS、公网IP、弹性公网IP、NAT网关等服务。
ECS的公网流量访问路径如下图所示。
图 2. 出网流量路径
总体原则:流量从哪里进来,就从哪里出去。
- 通过CLB进入的流量在CLB上限速或计费,仅收取出方向流量费用,入方向流量不收取(在未来可能会改变),CLB到ECS之间是阿里云内网通信,不收取流量费用。
- 来自弹性公网IP或NAT网关的流量,分别在弹性公网IP或NAT网关上进行限速或计费。如果在购买ECS时选择了公网带宽,限速/计费点在ECS上。
- CLB仅提供被动访问公网的能力,即后端ECS只能在收到通过CLB转发来的公网的请求时,才能访问公网回应该请求,如后端ECS希望主动发起公网访问,则需要配置或购买ECS公网带宽、弹性公网IP或NAT网关来实现。
- ECS公网带宽(购买ECS时配置)、弹性公网IP、NAT网关均可以实现ECS的双向公网访问(访问或被访问),但没有流量分发和负载均衡的能力。
4.5.7、应用场景
传统型负载均衡CLB(Classic Load Balancer)的应用场景为高访问量的业务,提高应用程序的可用性和可靠性。
4.5.7.1、应用于高访问量的业务
如果您的应用访问量很高,您可以通过配置监听规则将流量分发到不同的云服务器ECS(Elastic Compute Service)实例上。此外,您可以使用会话保持功能将同一客户端的请求转发到同一台后端ECS,提高访问效率。
4.5.7.2、扩展应用程序
您可以根据业务发展的需要,随时添加和移除ECS实例来扩展应用系统的服务能力,适用于各种Web服务器和App服务器。
4.5.7.3、消除单点故障
您可以在CLB实例下添加多台ECS实例。当其中一部分ECS实例发生故障后,CLB会自动屏蔽故障的ECS实例,将请求分发给正常运行的ECS实例,保证应用系统仍能正常工作。
4.5.7.4、同城容灾 (多可用区容灾)
为了提供更加稳定可靠的CLB服务,CLB已在各地域部署了多可用区以实现同地域容灾。当主可用区出现机房故障或不可用时,CLB仍然有能力在非常短的时间内(大约30s中断)切换到另外一个备可用区恢复服务能力;当主可用区恢复时,CLB同样会自动切换到主可用区提供服务。
使用CLB时,您可以将CLB实例部署在支持多可用区的地域以实现同城容灾。此外,建议您结合自身的应用需要,综合考虑后端服务器的部署。如果您的每个可用区均至少添加了一台ECS实例,那么此种部署模式下的CLB服务的效率是最高的。
如下图所示,在CLB实例下绑定不同可用区的ECS实例。正常情况下,用户访问流量将同时转发至主、备可用区内的ECS实例;当可用区A发生故障时,用户访问流量将只转发至备可用区内的ECS实例。此种部署既可以避免因为单个可用区的故障而导致对外服务的不可用,也可以通过不同产品间可用区的选择来降低延迟。
如果您采取如下图所示的部署方案,即在CLB实例的主可用区下绑定多台ECS实例,而在备可用区没有任何ECS实例。当主可用区发生故障时会造成业务中断,因为备可用区没有ECS实例来接收请求。这样的部署方式很明显是以牺牲高可用性为代价来获取低延时。
4.5.7.5、跨地域容灾
您可以在不同地域下部署CLB实例,并分别挂载相应地域内不同可用区的ECS。上层利用云解析做智能DNS,将域名解析到不同地域的CLB实例服务地址下,可实现全局CLB。当某个地域出现不可用时,暂停对应解析即可实现所有用户访问不受影响。
4.5.8、产品高可用
负载均衡高可用是从系统设计、产品配置等多个方面提供了可用性保障。此外,您可以根据业务需求,配合使用云解析DNS等产品实现跨地域容灾。多可用区高可用指标设计为99.99%,单可用区设计为99.90%。
4.5.8.1、CLB系统的高可用
负载均衡实例采用集群部署,可实现会话同步,以消除服务器单点故障,提升冗余,保证服务的稳定性。其中四层负载均衡通过LVS(Linux Virtual Server)+ keepalived的方式实现,七层负载均衡通过Tengine(淘宝网发起的Web服务器项目,在Nginx的基础上,针对有大访问量的网站需求进行了优化)实现。
来自公网的请求通过等价多路径路由(ECMP)到达LVS集群,LVS集群内的每台LVS通过组播报文将会话同步到该集群内的其它LVS机器上,从而实现LVS集群内各台机器间的会话同步。同时,LVS集群会对Tengine集群进行健康检查,将异常机器从Tengine集群移除,保证七层负载均衡的可用性。
最佳实践:
会话同步可以保证长连接不受集群内服务器故障的影响,但是对于短连接或连接未触发会话同步规则时(未完成三次握手),集群内的服务器故障仍可能会影响用户请求。为了防止集群中某台机器故障导致的会话中断,您可以在业务逻辑中加入重试机制,降低对用户访问造成的影响。
4.5.8.2、单CLB实例的高可用
为了向广大用户提供更稳定可靠的负载均衡服务,阿里云负载均衡已在大部分地域部署了多可用区以实现同地域下的跨机房容灾。当主可用区出现故障或不可用时,负载均衡有能力在非常短的时间内(约30秒)切换到备可用区并恢复服务;当主可用区恢复时,负载均衡同样会自动切换到主可用区提供服务。
说明 负载均衡的主备可用区是可用区级别的容灾。只有当主可用区整体不可用时,如机房整体断电或者机房出口光缆中断等,负载均衡才会切换到备可用区。而并非某个实例出现故障,就切换到备可用区。
最佳实践:
-
为了更好的利用负载均衡的主备可用区机制,建议您在支持主备可用区的地域创建负载均衡实例,即在购买负载均衡实例时选择可用区类型为多可用区的地域。
-
当您选择CLB的主备可用区时,可以根据ECS实例的可用区分布进行选择。大部分ECS实例位于哪个可用区,就将哪个可用区选择为CLB的主可用区,以获取最小的访问延迟。
但是并不建议您将全部ECS实例都部署在一个可用区内,您也需要在CLB的备可用区部署少量ECS实例,以便在极端情况下(主可用区整体不可用时),切换到备可用区后仍旧可以正常处理负载均衡转发的请求。
4.5.8.3、多CLB实例的高可用
如果您对可用性的要求特别高,负载均衡实例自身的可用性保障机制可能无法满足您的需求。例如当网络攻击或配置错误等情况导致负载均衡实例不可用时,由于未出现可用区级故障,不会触发负载均衡实例的可用区切换。此时,您可以创建多个CLB实例,通过云解析DNS对访问进行调度,或通过全球负载均衡解决方案实现跨地域容灾备份。
最佳实践:
您可以在一个地域内的多个可用区或多个地域内部署负载均衡实例和后端ECS实例,然后使用云解析DNS对访问进行调度。
4.5.8.4、后端ECS实例的高可用
负载均衡通过健康检查来判断后端ECS实例的可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。
开启健康检查功能后,当后端某个ECS实例健康检查出现异常时,负载均衡会自动将新的请求分发到其他健康检查正常的ECS实例上,而当该ECS实例恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。关于健康检查的详细机制,请参见健康检查概述。
最佳实践:
为了使健康检查功能正常运作,您需要开启并正确配置健康检查。具体的操作流程请参见配置健康检查。