• 关于

    系统响应时间不可用

    的搜索结果

回答

性能:系统的吞吐能力,指系统在某 一时间可以处理的数据总量,通常可以用系统每秒处理的总的数据量来衡量;系统的响应延迟,指 系统完成某一功能需要使用的时间;系统的并发能力,指系统可以同时完成某一功能的能力,通常 也用QPS(query per second)来衡量。上述三个性能指标往往会相互制约,追求高吞吐的系统,往往 很难做到低延迟;系统平均响应时间较长时,也很难提高QPS。 可用性:系统的可用性(availability)指系统在面对各种异常时可以正确提供服务的能力。系统的可用性可 以用系统停服务的时间与正常服务的时间的比例来衡量,也可以用某功能的失败次数与成功次数的 比例来衡量。可用性是分布式的重要指标,衡量了系统的鲁棒性,是系统容错能力的体现。 可扩展性: 系统的可扩展性(scalability)指分布式系统通过扩展集群机器规模提高系统性能(吞吐、延迟、 并发)、存储容量、计算能力的特性。 好的分布式系统总在追求“线性扩 展性”,也就是使得系统的某一指标可以随着集群中的机器数量线性增长。 一致性: 分布式系统为了提高可用性,总是不可避免的使用副本的机制,从而引发副本一致性的问题。 越是强的一致的性模型,对于用户使用来说使用起来越简单。
kun坤 2020-04-24 15:25:08 0 浏览量 回答数 0

回答

最终一致性BASE Basically Available:基本可用,系统遇到不可预知的故障时,允许损失部分可用性,但不是不可用,响应时间增加,服务降级Soft State:软状态,允许不同节点的数据副本同步存在延时Eventually Consistant:最终一致性 系统中的所有数据副本在一段时间同步后,最终能够达到数据一致性
1658458755422780 2020-03-31 15:30:34 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。更多详细信息参见健康检查配置。 以下是TCP/HTTP/HTTPS监听建议使用的健康检查配置。 配置 推荐值 响应超时时间 5秒 健康检查间隔 2秒 不健康阈值 3 以下是UDP监听建议使用的健康检查配置。 配置 推荐值 响应超时时间 10秒 健康检查间隔 5秒 不健康阈值 3 健康阈值 3
吴子 2019-12-02 01:29:14 0 浏览量 回答数 0

回答

问题现象 云服务器 ECS Linux 系统出现系统没有响应。 在/var/log/message 日志中出现大量的类似如下错误信息: echo 0 > /proc/sys/kernel/hung_task_timeout_secs disables this message. blocked for more than 120 seconds 如下图所示: 问题原因 默认情况下, Linux 会最多使用 40% 的可用内存作为文件系统缓存。当超过这个阈值后,文件系统会把将缓存中的内存全部写入磁盘, 导致后续的 IO 请求都是同步的。 将缓存写入磁盘时,有一个默认120 秒的超时时间。 出现上面的问题的原因是 IO 子系统的处理速度不够快,不能在 120 秒将缓存中的数据全部写入磁盘。 IO 系统响应缓慢,导致越来越多的请求堆积,最终系统内存全部被占用,导致系统失去响应。 处理方法 根据应用程序情况,对 vm.dirty_ratio,vm.dirty_background_ratio 两个参数进行调优设置。 例如,推荐如下设置: # sysctl -w vm.dirty_ratio=10 # sysctl -w vm.dirty_background_ratio=5 # sysctl -p 如果系统永久生效,修改 /etc/sysctl.conf 文件。加入如下两行: #vi /etc/sysctl.conf vm.dirty_background_ratio = 5 vm.dirty_ratio = 10 重启系统生效。
KB小秘书 2019-12-02 02:06:42 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 如果实例所在可用区出现满负载或者其它影响实例性能的情况,您可以将该实例迁移到同一地域内的其它可用区。在迁移可用区时,RDS服务会出现闪断及部分操作不能执行的状况,所以您可以根据需求选择在业务低谷期迁移可用区。RDS现已支持设置迁移可用区操作的执行时间,详情请参见本文的操作步骤。 说明 目前支持迁移可用区的实例为MySQL 5.5、MySQL 5.6、MySQL 5.7 (本地盘版)、SQL Server 2008 R2、PostgreSQL 9.4、PPAS 9.3、PPAS 10。 背景信息 RDS实例支持单可用区和多可用区的选择。多可用区是在单可用区的级别上,将同一地域的多个单可用区组合成的物理区域,如多可用区1(可用区B+可用区C)。相对于单可用区实例,多可用区实例可以承受更高级别的灾难。例如,单可用区实例可以承受服务器和机架级别的故障,而多可用区实例可以承受机房级别的故障。 目前,支持多可用区的地域有华东1、华东2、华北2、华南1、香港和新加坡(若有更新,请以实际界面为准),选择多可用区时不会额外收取任何费用。 当实例所在可用区出现满负载或其它影响实例性能的状况时,您可以将该实例迁移到同一地域内的其它可用区。实例迁移可用区,是将实例数据复制到新可用区的过程,所以是实例级别的迁移,迁移可用区后,实例的所有属性、配置和域名地址都不会发生改变。迁移可用区所需要的时间,跟实例大小有关,通常需要几个小时。当数据全部复制到新可用区后,原可用区的实例就会被删除。 迁移可用区时,您可以做出如下选择: 将实例从单可用区迁移至另一个单可用区。 将实例从单可用区迁移至一个多可用区。在该情况下,若实例有主备库,则主备库将会被分别随机分配在多可用区中。例如,将一个具有主备库的实例从可用区A迁移至多可用区1(可用区B+可用区C)时,若主库被随机分配到B可用区,则备库将会被分配至C可用区。 将实例从多可用区迁移至一个单可用区。在该情况下,实例的主备库都会被迁移至同一可用区内,实例承受灾难的级别会降低。 说明 多可用区之间存在一定的网络延迟,所以多可用区实例在采用半同步数据的复制方案的时,对于单个更新的响应时间会比单可用区实例长。在这种情况,请通过提高并发量的方式来实现整体吞吐量的提高。 注意事项 实例所在地域有多个可用区时,才能迁移可用区。 在迁移可用区时,与数据库、账号、网络等相关的大部分管理操作都无法执行,请选择合适的时间迁移可用区。下表列出了一些常用操作的受阻情况: 功能 是否可操作 修改白名单 是 开启SQL审计 是 设置可维护时间段 是 添加只读实例 否 添加灾备实例 否 释放实例 否 转包年包月 否 变更配置 否 创建账号/高权限账号 否 重置账号密码 否 修改账号权限 否 创建和删除数据库 否 切换网络类型 否 切换访问模式 否 修改连接地址 否 申请外网地址 否 切换主备库 否 修改数据备份方式 否 恢复实例数据 否 修改参数 否 在迁移可用区的过程中,会有30秒的连接闪断,请确认您的应用程序具有重连机制。 操作步骤 登录 RDS管理控制台。 选择目标实例所在地域。 单击目标实例ID,进入基本信息页面。 单击基本信息模块中的迁移可用区,如下图所示。 在实例迁移至其他可用区将页面中选择目标可用区和切换时间,如下图所示。 参数说明: 迁移至:选择实例需要迁移到的可用区。 切换时间:选择迁移可用区的时间。您可以选择立即切换,但在变配时有很多操作无法执行,例如管理数据库和账号、切换网络类型,您也可以选择在设置可维护时间段内执行切换可用区的操作。 若您要修改可维护时间,请执行如下操作。若不需要,请跳过。 单击修改,如下图所示,系统会新打开一个网页并跳转至实例的基本信息页面。 在配置信息栏中,选择可维护时间段,单击保存。 返回设置迁移可用区的网页。 在将实例迁移至其他可用区页面中,单击确定。
2019-12-01 22:57:20 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 如果实例所在可用区出现满负载或者其它影响实例性能的情况,您可以将该实例迁移到同一地域内的其它可用区。在迁移可用区时,RDS服务会出现闪断及部分操作不能执行的状况,所以您可以根据需求选择在业务低谷期迁移可用区。RDS现已支持设置迁移可用区操作的执行时间,详情请参见本文的操作步骤。 说明 目前支持迁移可用区的实例为MySQL 5.5、MySQL 5.6、MySQL 5.7 (本地盘版)、SQL Server 2008 R2、PostgreSQL 9.4、PPAS 9.3、PPAS 10。 背景信息 RDS实例支持单可用区和多可用区的选择。多可用区是在单可用区的级别上,将同一地域的多个单可用区组合成的物理区域,如多可用区1(可用区B+可用区C)。相对于单可用区实例,多可用区实例可以承受更高级别的灾难。例如,单可用区实例可以承受服务器和机架级别的故障,而多可用区实例可以承受机房级别的故障。 目前,支持多可用区的地域有华东1、华东2、华北2、华南1、香港和新加坡(若有更新,请以实际界面为准),选择多可用区时不会额外收取任何费用。 当实例所在可用区出现满负载或其它影响实例性能的状况时,您可以将该实例迁移到同一地域内的其它可用区。实例迁移可用区,是将实例数据复制到新可用区的过程,所以是实例级别的迁移,迁移可用区后,实例的所有属性、配置和域名地址都不会发生改变。迁移可用区所需要的时间,跟实例大小有关,通常需要几个小时。当数据全部复制到新可用区后,原可用区的实例就会被删除。 迁移可用区时,您可以做出如下选择: 将实例从单可用区迁移至另一个单可用区。 将实例从单可用区迁移至一个多可用区。在该情况下,若实例有主备库,则主备库将会被分别随机分配在多可用区中。例如,将一个具有主备库的实例从可用区A迁移至多可用区1(可用区B+可用区C)时,若主库被随机分配到B可用区,则备库将会被分配至C可用区。 将实例从多可用区迁移至一个单可用区。在该情况下,实例的主备库都会被迁移至同一可用区内,实例承受灾难的级别会降低。 说明 多可用区之间存在一定的网络延迟,所以多可用区实例在采用半同步数据的复制方案的时,对于单个更新的响应时间会比单可用区实例长。在这种情况,请通过提高并发量的方式来实现整体吞吐量的提高。 注意事项 实例所在地域有多个可用区时,才能迁移可用区。 在迁移可用区时,与数据库、账号、网络等相关的大部分管理操作都无法执行,请选择合适的时间迁移可用区。下表列出了一些常用操作的受阻情况: 功能 是否可操作 修改白名单 是 开启SQL审计 是 设置可维护时间段 是 添加只读实例 否 添加灾备实例 否 释放实例 否 转包年包月 否 变更配置 否 创建账号/高权限账号 否 重置账号密码 否 修改账号权限 否 创建和删除数据库 否 切换网络类型 否 切换访问模式 否 修改连接地址 否 申请外网地址 否 切换主备库 否 修改数据备份方式 否 恢复实例数据 否 修改参数 否 在迁移可用区的过程中,会有30秒的连接闪断,请确认您的应用程序具有重连机制。 操作步骤 登录 RDS管理控制台。 选择目标实例所在地域。 单击目标实例ID,进入基本信息页面。 单击基本信息模块中的迁移可用区,如下图所示。 在实例迁移至其他可用区将页面中选择目标可用区和切换时间,如下图所示。 参数说明: 迁移至:选择实例需要迁移到的可用区。 切换时间:选择迁移可用区的时间。您可以选择立即切换,但在变配时有很多操作无法执行,例如管理数据库和账号、切换网络类型,您也可以选择在设置可维护时间段内执行切换可用区的操作。 若您要修改可维护时间,请执行如下操作。若不需要,请跳过。 单击修改,如下图所示,系统会新打开一个网页并跳转至实例的基本信息页面。 在配置信息栏中,选择可维护时间段,单击保存。 返回设置迁移可用区的网页。 在将实例迁移至其他可用区页面中,单击确定。
2019-12-01 22:57:20 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 如果实例所在可用区出现满负载或者其它影响实例性能的情况,您可以将该实例迁移到同一地域内的其它可用区。在迁移可用区时,RDS服务会出现闪断及部分操作不能执行的状况,所以您可以根据需求选择在业务低谷期迁移可用区。RDS现已支持设置迁移可用区操作的执行时间,详情请参见本文的操作步骤。 说明 目前支持迁移可用区的实例为MySQL 5.5、MySQL 5.6、MySQL 5.7 (本地盘版)、SQL Server 2008 R2、PostgreSQL 9.4、PPAS 9.3、PPAS 10。 背景信息 RDS实例支持单可用区和多可用区的选择。多可用区是在单可用区的级别上,将同一地域的多个单可用区组合成的物理区域,如多可用区1(可用区B+可用区C)。相对于单可用区实例,多可用区实例可以承受更高级别的灾难。例如,单可用区实例可以承受服务器和机架级别的故障,而多可用区实例可以承受机房级别的故障。 目前,支持多可用区的地域有华东1、华东2、华北2、华南1、香港和新加坡(若有更新,请以实际界面为准),选择多可用区时不会额外收取任何费用。 当实例所在可用区出现满负载或其它影响实例性能的状况时,您可以将该实例迁移到同一地域内的其它可用区。实例迁移可用区,是将实例数据复制到新可用区的过程,所以是实例级别的迁移,迁移可用区后,实例的所有属性、配置和域名地址都不会发生改变。迁移可用区所需要的时间,跟实例大小有关,通常需要几个小时。当数据全部复制到新可用区后,原可用区的实例就会被删除。 迁移可用区时,您可以做出如下选择: 将实例从单可用区迁移至另一个单可用区。 将实例从单可用区迁移至一个多可用区。在该情况下,若实例有主备库,则主备库将会被分别随机分配在多可用区中。例如,将一个具有主备库的实例从可用区A迁移至多可用区1(可用区B+可用区C)时,若主库被随机分配到B可用区,则备库将会被分配至C可用区。 将实例从多可用区迁移至一个单可用区。在该情况下,实例的主备库都会被迁移至同一可用区内,实例承受灾难的级别会降低。 说明 多可用区之间存在一定的网络延迟,所以多可用区实例在采用半同步数据的复制方案的时,对于单个更新的响应时间会比单可用区实例长。在这种情况,请通过提高并发量的方式来实现整体吞吐量的提高。 注意事项 实例所在地域有多个可用区时,才能迁移可用区。 在迁移可用区时,与数据库、账号、网络等相关的大部分管理操作都无法执行,请选择合适的时间迁移可用区。下表列出了一些常用操作的受阻情况: 功能 是否可操作 修改白名单 是 开启SQL审计 是 设置可维护时间段 是 添加只读实例 否 添加灾备实例 否 释放实例 否 转包年包月 否 变更配置 否 创建账号/高权限账号 否 重置账号密码 否 修改账号权限 否 创建和删除数据库 否 切换网络类型 否 切换访问模式 否 修改连接地址 否 申请外网地址 否 切换主备库 否 修改数据备份方式 否 恢复实例数据 否 修改参数 否 在迁移可用区的过程中,会有30秒的连接闪断,请确认您的应用程序具有重连机制。 操作步骤 登录 RDS管理控制台。 选择目标实例所在地域。 单击目标实例ID,进入基本信息页面。 单击基本信息模块中的迁移可用区,如下图所示。 在实例迁移至其他可用区将页面中选择目标可用区和切换时间,如下图所示。 参数说明: 迁移至:选择实例需要迁移到的可用区。 切换时间:选择迁移可用区的时间。您可以选择立即切换,但在变配时有很多操作无法执行,例如管理数据库和账号、切换网络类型,您也可以选择在设置可维护时间段内执行切换可用区的操作。 若您要修改可维护时间,请执行如下操作。若不需要,请跳过。 单击修改,如下图所示,系统会新打开一个网页并跳转至实例的基本信息页面。 在配置信息栏中,选择可维护时间段,单击保存。 返回设置迁移可用区的网页。 在将实例迁移至其他可用区页面中,单击确定。
2019-12-01 22:57:19 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 如果实例所在可用区出现满负载或者其它影响实例性能的情况,您可以将该实例迁移到同一地域内的其它可用区。在迁移可用区时,RDS服务会出现闪断及部分操作不能执行的状况,所以您可以根据需求选择在业务低谷期迁移可用区。RDS现已支持设置迁移可用区操作的执行时间,详情请参见本文的操作步骤。 说明 目前支持迁移可用区的实例为MySQL 5.5、MySQL 5.6、MySQL 5.7 (本地盘版)、SQL Server 2008 R2、PostgreSQL 9.4、PPAS 9.3、PPAS 10。 背景信息 RDS实例支持单可用区和多可用区的选择。多可用区是在单可用区的级别上,将同一地域的多个单可用区组合成的物理区域,如多可用区1(可用区B+可用区C)。相对于单可用区实例,多可用区实例可以承受更高级别的灾难。例如,单可用区实例可以承受服务器和机架级别的故障,而多可用区实例可以承受机房级别的故障。 目前,支持多可用区的地域有华东1、华东2、华北2、华南1、香港和新加坡(若有更新,请以实际界面为准),选择多可用区时不会额外收取任何费用。 当实例所在可用区出现满负载或其它影响实例性能的状况时,您可以将该实例迁移到同一地域内的其它可用区。实例迁移可用区,是将实例数据复制到新可用区的过程,所以是实例级别的迁移,迁移可用区后,实例的所有属性、配置和域名地址都不会发生改变。迁移可用区所需要的时间,跟实例大小有关,通常需要几个小时。当数据全部复制到新可用区后,原可用区的实例就会被删除。 迁移可用区时,您可以做出如下选择: 将实例从单可用区迁移至另一个单可用区。 将实例从单可用区迁移至一个多可用区。在该情况下,若实例有主备库,则主备库将会被分别随机分配在多可用区中。例如,将一个具有主备库的实例从可用区A迁移至多可用区1(可用区B+可用区C)时,若主库被随机分配到B可用区,则备库将会被分配至C可用区。 将实例从多可用区迁移至一个单可用区。在该情况下,实例的主备库都会被迁移至同一可用区内,实例承受灾难的级别会降低。 说明 多可用区之间存在一定的网络延迟,所以多可用区实例在采用半同步数据的复制方案的时,对于单个更新的响应时间会比单可用区实例长。在这种情况,请通过提高并发量的方式来实现整体吞吐量的提高。 注意事项 实例所在地域有多个可用区时,才能迁移可用区。 在迁移可用区时,与数据库、账号、网络等相关的大部分管理操作都无法执行,请选择合适的时间迁移可用区。下表列出了一些常用操作的受阻情况: 功能 是否可操作 修改白名单 是 开启SQL审计 是 设置可维护时间段 是 添加只读实例 否 添加灾备实例 否 释放实例 否 转包年包月 否 变更配置 否 创建账号/高权限账号 否 重置账号密码 否 修改账号权限 否 创建和删除数据库 否 切换网络类型 否 切换访问模式 否 修改连接地址 否 申请外网地址 否 切换主备库 否 修改数据备份方式 否 恢复实例数据 否 修改参数 否 在迁移可用区的过程中,会有30秒的连接闪断,请确认您的应用程序具有重连机制。 操作步骤 登录 RDS管理控制台。 选择目标实例所在地域。 单击目标实例ID,进入基本信息页面。 单击基本信息模块中的迁移可用区,如下图所示。 在实例迁移至其他可用区将页面中选择目标可用区和切换时间,如下图所示。 参数说明: 迁移至:选择实例需要迁移到的可用区。 切换时间:选择迁移可用区的时间。您可以选择立即切换,但在变配时有很多操作无法执行,例如管理数据库和账号、切换网络类型,您也可以选择在设置可维护时间段内执行切换可用区的操作。 若您要修改可维护时间,请执行如下操作。若不需要,请跳过。 单击修改,如下图所示,系统会新打开一个网页并跳转至实例的基本信息页面。 在配置信息栏中,选择可维护时间段,单击保存。 返回设置迁移可用区的网页。 在将实例迁移至其他可用区页面中,单击确定。
2019-12-01 22:57:20 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 如果实例所在可用区出现满负载或者其它影响实例性能的情况,您可以将该实例迁移到同一地域内的其它可用区。在迁移可用区时,RDS服务会出现闪断及部分操作不能执行的状况,所以您可以根据需求选择在业务低谷期迁移可用区。RDS现已支持设置迁移可用区操作的执行时间,详情请参见本文的操作步骤。 说明 目前支持迁移可用区的实例为MySQL 5.5、MySQL 5.6、MySQL 5.7 (本地盘版)、SQL Server 2008 R2、PostgreSQL 9.4、PPAS 9.3、PPAS 10。 背景信息 RDS实例支持单可用区和多可用区的选择。多可用区是在单可用区的级别上,将同一地域的多个单可用区组合成的物理区域,如多可用区1(可用区B+可用区C)。相对于单可用区实例,多可用区实例可以承受更高级别的灾难。例如,单可用区实例可以承受服务器和机架级别的故障,而多可用区实例可以承受机房级别的故障。 目前,支持多可用区的地域有华东1、华东2、华北2、华南1、香港和新加坡(若有更新,请以实际界面为准),选择多可用区时不会额外收取任何费用。 当实例所在可用区出现满负载或其它影响实例性能的状况时,您可以将该实例迁移到同一地域内的其它可用区。实例迁移可用区,是将实例数据复制到新可用区的过程,所以是实例级别的迁移,迁移可用区后,实例的所有属性、配置和域名地址都不会发生改变。迁移可用区所需要的时间,跟实例大小有关,通常需要几个小时。当数据全部复制到新可用区后,原可用区的实例就会被删除。 迁移可用区时,您可以做出如下选择: 将实例从单可用区迁移至另一个单可用区。 将实例从单可用区迁移至一个多可用区。在该情况下,若实例有主备库,则主备库将会被分别随机分配在多可用区中。例如,将一个具有主备库的实例从可用区A迁移至多可用区1(可用区B+可用区C)时,若主库被随机分配到B可用区,则备库将会被分配至C可用区。 将实例从多可用区迁移至一个单可用区。在该情况下,实例的主备库都会被迁移至同一可用区内,实例承受灾难的级别会降低。 说明 多可用区之间存在一定的网络延迟,所以多可用区实例在采用半同步数据的复制方案的时,对于单个更新的响应时间会比单可用区实例长。在这种情况,请通过提高并发量的方式来实现整体吞吐量的提高。 注意事项 实例所在地域有多个可用区时,才能迁移可用区。 在迁移可用区时,与数据库、账号、网络等相关的大部分管理操作都无法执行,请选择合适的时间迁移可用区。下表列出了一些常用操作的受阻情况: 功能 是否可操作 修改白名单 是 开启SQL审计 是 设置可维护时间段 是 添加只读实例 否 添加灾备实例 否 释放实例 否 转包年包月 否 变更配置 否 创建账号/高权限账号 否 重置账号密码 否 修改账号权限 否 创建和删除数据库 否 切换网络类型 否 切换访问模式 否 修改连接地址 否 申请外网地址 否 切换主备库 否 修改数据备份方式 否 恢复实例数据 否 修改参数 否 在迁移可用区的过程中,会有30秒的连接闪断,请确认您的应用程序具有重连机制。 操作步骤 登录 RDS管理控制台。 选择目标实例所在地域。 单击目标实例ID,进入基本信息页面。 单击基本信息模块中的迁移可用区,如下图所示。 在实例迁移至其他可用区将页面中选择目标可用区和切换时间,如下图所示。 参数说明: 迁移至:选择实例需要迁移到的可用区。 切换时间:选择迁移可用区的时间。您可以选择立即切换,但在变配时有很多操作无法执行,例如管理数据库和账号、切换网络类型,您也可以选择在设置可维护时间段内执行切换可用区的操作。 若您要修改可维护时间,请执行如下操作。若不需要,请跳过。 单击修改,如下图所示,系统会新打开一个网页并跳转至实例的基本信息页面。 在配置信息栏中,选择可维护时间段,单击保存。 返回设置迁移可用区的网页。 在将实例迁移至其他可用区页面中,单击确定。
2019-12-01 22:57:19 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 如果实例所在可用区出现满负载或者其它影响实例性能的情况,您可以将该实例迁移到同一地域内的其它可用区。在迁移可用区时,RDS服务会出现闪断及部分操作不能执行的状况,所以您可以根据需求选择在业务低谷期迁移可用区。RDS现已支持设置迁移可用区操作的执行时间,详情请参见本文的操作步骤。 说明 目前支持迁移可用区的实例为MySQL 5.5、MySQL 5.6、MySQL 5.7 (本地盘版)、SQL Server 2008 R2、PostgreSQL 9.4、PPAS 9.3、PPAS 10。 背景信息 RDS实例支持单可用区和多可用区的选择。多可用区是在单可用区的级别上,将同一地域的多个单可用区组合成的物理区域,如多可用区1(可用区B+可用区C)。相对于单可用区实例,多可用区实例可以承受更高级别的灾难。例如,单可用区实例可以承受服务器和机架级别的故障,而多可用区实例可以承受机房级别的故障。 目前,支持多可用区的地域有华东1、华东2、华北2、华南1、香港和新加坡(若有更新,请以实际界面为准),选择多可用区时不会额外收取任何费用。 当实例所在可用区出现满负载或其它影响实例性能的状况时,您可以将该实例迁移到同一地域内的其它可用区。实例迁移可用区,是将实例数据复制到新可用区的过程,所以是实例级别的迁移,迁移可用区后,实例的所有属性、配置和域名地址都不会发生改变。迁移可用区所需要的时间,跟实例大小有关,通常需要几个小时。当数据全部复制到新可用区后,原可用区的实例就会被删除。 迁移可用区时,您可以做出如下选择: 将实例从单可用区迁移至另一个单可用区。 将实例从单可用区迁移至一个多可用区。在该情况下,若实例有主备库,则主备库将会被分别随机分配在多可用区中。例如,将一个具有主备库的实例从可用区A迁移至多可用区1(可用区B+可用区C)时,若主库被随机分配到B可用区,则备库将会被分配至C可用区。 将实例从多可用区迁移至一个单可用区。在该情况下,实例的主备库都会被迁移至同一可用区内,实例承受灾难的级别会降低。 说明 多可用区之间存在一定的网络延迟,所以多可用区实例在采用半同步数据的复制方案的时,对于单个更新的响应时间会比单可用区实例长。在这种情况,请通过提高并发量的方式来实现整体吞吐量的提高。 注意事项 实例所在地域有多个可用区时,才能迁移可用区。 在迁移可用区时,与数据库、账号、网络等相关的大部分管理操作都无法执行,请选择合适的时间迁移可用区。下表列出了一些常用操作的受阻情况: 功能 是否可操作 修改白名单 是 开启SQL审计 是 设置可维护时间段 是 添加只读实例 否 添加灾备实例 否 释放实例 否 转包年包月 否 变更配置 否 创建账号/高权限账号 否 重置账号密码 否 修改账号权限 否 创建和删除数据库 否 切换网络类型 否 切换访问模式 否 修改连接地址 否 申请外网地址 否 切换主备库 否 修改数据备份方式 否 恢复实例数据 否 修改参数 否 在迁移可用区的过程中,会有30秒的连接闪断,请确认您的应用程序具有重连机制。 操作步骤 登录 RDS管理控制台。 选择目标实例所在地域。 单击目标实例ID,进入基本信息页面。 单击基本信息模块中的迁移可用区,如下图所示。 在实例迁移至其他可用区将页面中选择目标可用区和切换时间,如下图所示。 参数说明: 迁移至:选择实例需要迁移到的可用区。 切换时间:选择迁移可用区的时间。您可以选择立即切换,但在变配时有很多操作无法执行,例如管理数据库和账号、切换网络类型,您也可以选择在设置可维护时间段内执行切换可用区的操作。 若您要修改可维护时间,请执行如下操作。若不需要,请跳过。 单击修改,如下图所示,系统会新打开一个网页并跳转至实例的基本信息页面。 在配置信息栏中,选择可维护时间段,单击保存。 返回设置迁移可用区的网页。 在将实例迁移至其他可用区页面中,单击确定。
2019-12-01 22:57:20 0 浏览量 回答数 0

问题

ECS Linux 系统日志出现 hung_task_timeout_secs 和 blocked for more than 120 seconds

问题现象 云服务器 ECS Linux 系统出现系统没有响应。 在/var/log/message 日志中出现大量的类似如下错误信息: echo 0 > /proc/sys/kernel/hung_task_t...
boxti 2019-12-01 22:04:20 1311 浏览量 回答数 0

回答

一张图说明CDN网络的原理2013年07月25日 14:55:25阅读数:528731.用户向浏览器输入www.web.com这个域名,浏览器第一次发现本地没有dns缓存,则向网站的DNS服务器请求;2.网站的DNS域名解析器设置了CNAME,指向了www.web.51cdn.com,请求指向了CDN网络中的智能DNS负载均衡系统;3.智能DNS负载均衡系统解析域名,把对用户响应速度最快的IP节点返回给用户;4.用户向该IP节点(CDN服务器)发出请求;5.由于是第一次访问,CDN服务器会向原web站点请求,并缓存内容;6.请求结果发给用户。CDN网络是在用户和服务器之间增加Cache层,如何将用户的请求引导到Cache上获得源服务器的数据,主要是通过接管DNS实现,这就是CDN的最基本的原理,当然很多细节没有涉及到,比如第1步,首先向本地的DNS服务器请求。第5步,内容淘汰机制(根据TTL)等。但原理大体如此。当用户访问加入CDN服务的网站时,域名解析请求将最终交给全局负载均衡DNS进行处理。全局负载均衡DNS通过一组预先定义好的策略,将当时最接近用 户的节点地址提供给用户,使用户能够得到快速的服务。同时,它还与分布在世界各地的所有CDNC节点保持通信,搜集各节点的通信状态,确保不将用户的请求 分配到不可用的CDN节点上,实际上是通过DNS做全局负载均衡。对于普通的Internet用户来讲,每个CDN节点就相当于一个放置在它周围的WEB。通过全局负载均衡DNS的控制,用户的请求被透明地指向离他最近的节点,节点中CDN服务器会像网站的原始服务器一样,响应用户的请求。由于它离用户更近,因而响应时间必然更快。每个CDN节点由两部分组成:负载均衡设备和高速缓存服务器负载均衡设备负责每个节点中各个Cache的负载均衡,保证节点的工作效率;同时,负载均衡设备还负责收集节点与周围环境的信息,保持与全局负载DNS的通信,实现整个系统的负载均衡。CDN的管理系统是整个系统能够正常运转的保证。它不仅能对系统中的各个子系统和设备进行实时监控,对各种故障产生相应的告警,还可以实时监测到系统中 总的流量和各节点的流量,并保存在系统的数据库中,使网管人员能够方便地进行进一步分析。通过完善的网管系统,用户可以对系统配置进行修改。理论上,最简单的CDN网络有一个负责全局负载均衡的DNS和各节点一台Cache,即可运行。DNS支持根据用户源IP地址解析不同的IP,实现 就近访问。为了保证高可用性等,需要监视各节点的流量、健康状况等。一个节点的单台Cache承载数量不够时,才需要多台Cache,多台Cache同时 工作,才需要负载均衡器,使Cache群协同工作。
xuning715 2019-12-02 01:11:44 0 浏览量 回答数 0

问题

健康检查原理

概述 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台E...
行者武松 2019-12-01 21:36:16 1626 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT