API 文档

文档中心 > 负载均衡 > 常见问题 > 负载均衡配置相关

负载均衡配置相关

最近更新时间:2021-07-08 10:54:42

概念相关问题

健康检查相关问题

访问相关问题

四层负载均衡和七层负载均衡有什么区别?

  • 四层均衡能力,是基于 IP + 端口的负载均衡。
  • 七层是基于应用层信息(如 HTTP 头部、URL 等)的负载均衡。

四到七层负载均衡,就是在对后台的服务器进行负载均衡时,依据四层的信息或七层的信息来决定怎么样转发流量。
例如,四层的负载均衡,就是通过发布三层的IP地址(VIP),然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行 NAT 处理,转发至后台服务器,并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。

七层的负载均衡,就是在四层的基础上,再考虑应用层的特征。
例如,同一个 Web 服务器的负载均衡,除了根据 VIP 和80端口辨别是否需要处理的流量,还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。
七层负载均衡,也称为“内容交换”,也就是主要通过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。

七层负载均衡要根据真正的应用层内容选择服务器,只能先代理最终的服务器和客户端建立连接(三次握手)后,才可能接受到客户端发送的真正应用层内容的报文,然后再根据该报文中的特定字段,以及负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。负载均衡设备在这种情况下,更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立 TCP 连接。

[回到顶部]

UDP 协议与 TCP 协议有什么区别?

TCP 是面向连接的协议,在正式收发数据前,必须和对方建立可靠的连接。UDP 是面向非连接的协议,它在数据发送前不与对方先进行三次握手,而是直接进行数据包发送传送。UDP 协议主要适用于关注实时性而相对不注重可靠性的场景,如视频聊天、金融实时行情推送、DNS、物联网等。

[回到顶部]

负载均衡 Cookies 会话保持方式的原理是什么?

在 Cookie 插入模式下,CLB 将负责插入 Cookie,后端服务器无需作出任何修改。当客户进行第一次请求时,客户 HTTP 请求(不带 Cookie)进入 CLB, CLB 根据负载平衡算法策略选择后端一台服务器,并将请求发送至该服务器,后端服务器进行 HTTP 回复(不带 Cookie)被发回 CLB,然后 CLB 插入 Cookie,将 HTTP 回复(带 Cookie)返回到客户端。

当客户请求再次发生时,客户 HTTP 请求(带有上次 CLB 插入的 Cookie)进入 CLB,然后 CLB 读出 Cookie 里的会话保持数值,将HTTP请求(带有与上面同样的 Cookie)发到指定的服务器,然后后端服务器进行请求回复,由于服务器并不写入 Cookie,HTTP 回复将不带有 Cookie,回复流量再次经过进入 CLB 时,CLB 再次写入更新后的会话保持 Cookie。

[回到顶部]

什么是后端服务器权重?

用户可以指定后端服务器池内各 CVM 的转发权重,权重比越高的 CVM 将被分配到更多的访问请求,用户可以根据后端 CVM 的对外服务能力和情况来区别设定。

如果您同时开启了会话保持功能,那可能会造成对后端应用服务器的访问并不是完全相同的,建议您可以暂时关闭会话保持功能观察一下是否依然存在这种情况。

[回到顶部]

健康检查提示 CVM 实例异常该如何处理?

请按如下步骤进行排查:

  • 确保您直接通过云服务器访问到您的应用服务。
  • 确保后端服务器已开启了相应的端口。
  • 检查后端服务器内部是否有防火墙之类的防护软件,可能导致负载均衡系统无法与后端服务器通讯。
  • 检查负载均衡检查参数设置是否正确。
  • 建议使用静态页面来健康检查。
  • 检查后端的云服务器是否有高负载导致云服务器对外响应慢。
  • 确保云服务器子机没有做 iptables 限制。

[回到顶部]

为什么健康检查探测频率过高?

健康检查探测包频率过高,控制台设置接受探测包5秒1次,实际后端 RS 发现1秒内收到1次甚至多次健康检查请求,原因如下:

当前,健康检查频率过高的问题,主要跟负载均衡后端健康探测实现机制有关。假设100万的 client 端请求,会分散在4台 CLB 后端物理机上,再转给云服务器。 健康检查探测是在 CLB 的后端物理机上各自探测的。因此,CLB 实例设置5秒1次的探测请求,实际上 CLB 后端的每台物理机都会每5s发送一次探测。因此在后端云服务器上,会收到多次探测请求。假设 CLB 实例所在集群有8台物理机,那么每台机器5s发送一次请求,后端主机可能会在5s中收到8次探测。

该实现方案的优势是:效率高,探测精准,避免误剔除。例如,CLB 实例集群的8台物理机中,其中1台判断失败,仅那1台机器不再转发流量,另外7台的流量是正常的。

因此,如果您后端云服务器的探测频率过高,可以通过设置更长的探测间隔时间来解决( 如设置为15s探测一次)。

[回到顶部]

负载转发中的 HTTP 重定向问题

当浏览器访问网站 http://example.com 时,对服务器而言需要进行一次重定向,判断需要定向至根目录。而当浏览器访问网站 http://example.com/ 时服务器会直接返回网站设置的根目录默认页面。同样的,假设 http://cloud.tencent.com/movie 被 URL 重写跳转到 http://cloud.tencent.com/movie/ 上的话,则输入 http://cloud.tencent.com/movie 就会多一次 URL 重写的过程,在性能和时间上都有微小的损耗,但在结果上没有差别。若 http://cloud.tencent.com/product 被 URL 重写转跳到非 http://cloud.tencent.com/product/ 同一页面上,则需要考虑是否在二级页面后添加/

在腾讯云负载均衡中,如果前后端端口号不一致时,为了避免 HTTP 重定向后导致端口号更改,访问二级页面需要加/保证页面的正常访问。

假设七层转发下,负载均衡实例监听80端口,后端服务器监听 8081 端口。此时客户端访问 http://www.example.com/movie ,经由负载均衡转发至后端服务器,服务器收到发往 http://www.example.com/movie 的请求并会重定向到 http://www.example.com:8081/movie/(监听端口为8081),此时客户端访问失败(端口错误)。

因此,建议用户将访问请求改写为带/的二级页面如 http://www.example.com/movie/,这样可以避免 HTTP 重定向,减少一次不必要的判断,降低不必要的负载。如果必须使用 HTTP 重定向时,请保证负载均衡的监听端口和后端服务器的监听端口相同。

[回到顶部]

可以为哪些 TCP 端口执行负载均衡?

您可以为如下 TCP 端口执行负载均衡:21(FTP)、25(SMTP)、80(HTTP)、443(HTTPS),以及1024 - 65535等端口。

[回到顶部]

发送 843 的 policy 请求(即 flash server 请求)时,没有返回策略文件,连接直接断掉,该如何处理?

负载均衡收到 843 的 policy 请求,会主动回复通用的 crossdomain 策略配置文件,如果出现没有返回策略文件,连接直接断掉的情况,可能是 flash server 请求不正确。

请确认发送正确的 flash server 的请求:\0 。

注意:

这里需要以\0结尾,一共23个字节。\0是指一个 ASCII 码为 0 的符号,只占用一个字节。

正常的 843 返回结果如下图所示:

[回到顶部]

负载均衡是否可以直接获取 Client 端 IP?

  • IPv6 NAT64 负载均衡不支持获取 Client IP。
  • 公网七层 IPv4 和 IPv6 负载均衡提供 X-Forwarded-For 的方式获取访问者真实 IP,负载均衡侧默认开启,需要后端服务做相应配置来获取 Client IP。详情请见 如何获取客户端真实 IP
  • 公网四层 IPv4 和 IPv6 负载均衡(TCP 协议)服务可以直接在后端 CVM 上获取来访者真实 IP 地址,无需进行额外的配置;内网四层负载均衡自从2016年10月24日起,新购的实例不再进行 SNAT 处理,支持直接从 server 端获取真实的 client IP,无需额外配置。

[回到顶部]

CVM 可通过配置内网型负载均衡,将流量从端口A转发回同一台服务器的其他端口吗?

不可以。对服务器 A(10.66.*.101)端口 a 的访问可通过内网型负载均衡将请求转发至服务器 B(10.66.*.102)的端口 b。但无法将流量转发至同一台服务器 A(10.66.*.101)的另一端口 b。

[回到顶部]

后端 CVM 需要公网带宽吗?是否会影响负载均衡的服务?

  • 标准账户类型的负载均衡绑定的后端 CVM 无需配置公网带宽。
  • 传统账户类型的负载均衡不收取任何的流量或带宽费用。负载均衡服务产生的公网流量费用,由绑定的后端的 CVM 收取,建议购买后端 CVM 时,公网带宽选择按使用流量计费,并设定合理的最高的带宽峰值上限,这样就无需关注 CLB 出口的总流量的涨跌。互联网 Web 业务的流量起伏较大,无法准确预测。若按带宽计费,带宽买多了不划算,买得太少,业务高峰期会出现丢包的情况。

[回到顶部]

客户端、服务器端 HTTP 版本不一致时,兼容版本说明

转发兼容性

  • 前端(client 端),当前支持 HTTP1.0/1.1,向下兼容。
  • 后端(server 端), 当前腾讯云使用 HTTP1.0 协议,支持 HTTP1.0/1.1,向下兼容。
注意:

HTTP/2 只在 HTTPS 中支持,且 client 及 server 端可以向下兼容。当前不支持 HTTP 协议。

支持 Gzip 兼容性

  • 前端(client 端),当前支持 HTTP1.0/1.1 向下兼容。(用户无需配置,主流浏览器都支持 Gzip)
  • 后端(server 端),在云服务器端,由于腾讯云内部全网支持 HTTP/1.1 协议,因此用户也无需配置,使用 Nginx 默认配置(HTTP/1.1)即可兼容。
注意:

HTTP/2 只在 HTTPS 中支持,但 Gzip 可以用在腾讯云所支持的任意 HTTP 版本中。

[回到顶部]

负载均衡后端服务器的安全组应该怎么设置?怎样设置访问黑名单?

负载均衡安全组配置

若后端服务器设置了安全组规则,可能会出现负载均衡实例无法与其通信的状况。因此,在四层转发和七层转发下,建议后端服务器安全组均设置为全放通。若打开了安全组,并默认允许拒绝全协议全ip段的地址访问时,需要配置所有客户端 IP 到本机 IP 的安全组规则。
对于某些恶意 IP,可以设置把恶意IP加在安全组前排规则,禁止其访问后端服务器;再放通所有 IP(0.0.0.0)到本机服务端口,让正常客户端可以访问。 (安全组规则是有顺序的,自顶而下进行匹配)

私有网络内的七层负载转发若设置了健康检查,必须把负载均衡 VIP 加入到后端服务器的安全组放通规则,否则健康检查可能失效。

设置访问黑名单

如用户需要给某些 Client IP 设置黑名单,拒绝其访问,可以通过配置云服务关联的安全组实现。安全组的规则需要按照如下步骤进行配置:

注意:

如下配置步骤有顺序要求,顺序相反会导致黑名单配置失效。

  • 将需要拒绝访问的 client IP + 端口添加至安全组中,并在策略栏中选取拒绝该 IP 的访问。
  • 设置完毕后,再添加一条安全组规则,默认开放该端口全部 IP 的访问。
    配置完成后,安全组规则如下:
    clientA ip+port drop
    clientB ip+port drop
    0.0.0.0/0+port accept

关于安全组的更多说明,请参见 后端云服务器安全组配置说明

[回到顶部]

负载均衡与后端服务器之间的通讯是走的内网还是外网?

负载均衡与后端服务器的通讯始终走内网,绑定的 CVM 有外网 IP 的情况下也一样。

[回到顶部]

关于 Ping 负载均衡的 VIP 说明

Ping 负载均衡的 VIP :由负载均衡集群响应,不会转发到后端的服务器。

  • 公网负载均衡的 VIP 支持 Ping。
  • 内网负载均衡的 VIP 仅支持来自本 VPC 的客户端 Ping,不支持其他 VPC、本地 IDC 的客户端 Ping(如使用云联网、对等连接等打通 VPC 的场景,建议您使用 telnet 来探测)。

[回到顶部]

关于 Telnet 负载均衡监听端口的说明

  • 创建四层(TCP、UDP、TCP SSL) 监听器后,如果不绑定后端服务器,则无法 Telnet 通监听端口;绑定后端服务器后,可以 Telnet 通监听端口。
  • 创建七层(HTTP、HTTPS)监听器后,即使不绑定后端服务器,也可以 Telnet 通监听端口,由 CLB 代答。

[回到顶部]

关于内网回环问题的说明

内网负载均衡不支持同一个 CVM 既作为客户端又作为服务器,此时 CLB 看到的 Client IP 和 Server IP 是一样的,会导致访问不通。
当您的客户端需要同时作为服务器时,请至少绑定两个后端服务器。CLB 有自动避免回环的策略,当 Client A 访问负载均衡时,负载均衡会自动调度到非 Client A 的后端服务器上。

[回到顶部]

关于同一个客户端通过不同的中间节点访问同一个后端 RS 的同一个端口时串流问题的说明

问题现象
同一个客户端在同一时刻,通过不同的中间节点访问同一个 RS 的同一个端口会出现串流现象。具体场景如下:

  • 同一个客户端,同时通过同一个 CLB 的四层、七层监听器,访问同一个 RS 的同一个端口。
  • 同一个客户端,同时通过不同 CLB 的不同监听器,访问同一个 RS 的同一个端口。
  • 访问内网 CLB 的客户端比较集中,且后端服务相同时,有较大概率会出现串流。(访问公网 CLB 的客户端来源较广,很少出现串流。)

问题原因
当前 CLB 会透传客户端 IP 到后端 RS,因此会导致 client_ip:client_port -> vip:vport -> rs_ip:rs_port 最终变为 client_ip:client_port --> rs_ip:rs_port

解决方案

  • 分散客户端:使用多个客户端发起访问。
  • 收敛 CLB:在满足业务功能和容灾需求的前提下,减少 CLB 的实例、监听器个数。
  • 分散后端服务端口:后端服务使用多个端口提供服务,避免后端端口集中。
  • 分散部署:不同 CLB 绑定不同的后端服务端口,如 CLB1 绑定一组 CVM,CLB2 绑定另一组 CVM,两个 CLB 同时提供访问。

[回到顶部]

为什么后端 CVM 配置安全组禁止公网访问,仅允许负载均衡访问,但却未生效?

若需要通过 CLB 访问后端 CVM,需要后端 CVM 和 CLB 两个安全组均放通公网访问,建议先把后端 CVM 的安全组仅放通 CLB 的 VIP 公网访问,CLB 的安全组按需放通公网访问 IP。

[回到顶部]

为什么负载均衡已配置监听器并绑定后端 CVM,当配置域名解析至后端 CVM 的 IP 并访问域名时,负载均衡的监控没有具体的信息?

需通过负载均衡进行访问,才有具体的监控信息,可配置域名解析至负载均衡的 VIP 并访问域名,即可在负载均衡的监控中查看具体的信息。

[回到顶部]

为什么没有创建843监听器,却可以 Telnet 通?

为满足部分用户重置访问 Flash 的需求,CLB 默认放通了843端口。若您想关闭该端口,请配置 TCP:843 监听器后,不绑定后端服务器即可。

[回到顶部]

目录