1 负载均衡特性FAQ

1.1  服务器负载均衡

1.1.1  SLB虚服务器、实服务组、实服务器的概念？

·     虚服务器：虚服务器是负载均衡设备上提供的一种虚拟服务，是为了判断是否需要对到达负载均衡设备的报文进行负载均衡而引入的概念。只有与虚服务器IP地址匹配的报文才会进行负载均衡处理。

·     实服务器：实服务器用来在负载均衡设备上模拟用户的业务服务器，用于指导报文转发。一台实服务器只能属于一个实服务组，而一个实服务组可以包含多台实服务器。

·     实服务器组：为了便于对多台服务器进行管理，可以依据这些服务器的共有属性划分成不同的组，称为实服务组。比如，可按照存储内容的不同划分为歌曲服务器组，视频服务器组或图片服务器组等。

1.1.2  如何排查SLB业务不通的问题？

(1)     display real-server brief查看虚服务、实服务的状态，状态是否处于Active状态；

(2)     display virtual-server statistics查看对应虚服务统计信息是否有变化，有变化说明报文已经匹配到虚服务，应从匹配的虚服务找问题原因。否则，查看为何没有命中虚服务；

(3)     查看Debug调试信息。

1.1.3  SLB的http类型下，设置规则为cookie，如果一个报文中包含多个请求，只检查第一个请求的cookie吗？

如果一个报文中包含多个请求，默认只处理第一个请求，按照第一个请求进行负载分担，要处理每个请求需要配置http parameter:rebalance per-request。

1.1.4  SLB负载均衡动作中，删除头部，如果一个报文中包含多个请求，只删除第一个请求的头部吗？

如果一个报文中包含多个请求，默认只处理第一个请求，要处理每个请求需要配置http parameter:header per-reques。

1.1.5  SLB的参数模板中的set ip tos 命令与action中的set ip tos命令有什么区别？

set ip tos在参数模板中设置改变的是发向客户端的报文的tos值，在action中设置改变的是发向服务器的报文的tos值。

1.1.6  为什么已经在实服务组下使能就近性功能了，却仍然没有生成就近性表项？

可以先检查就近性下有没有配置就近性探测方法。

因为就近性表项的产生依赖于就近性探测，因此如果此处没有配置有效的就近性探测方法，则不会生成就近性表项。

1.1.7  七层虚服务下负载均衡策略和默认实服务组同时引用时业务怎么处理的？

虚服务器引用策略后策略的优先级比默认实服务器组优先级高。

根据虚服务器引用策略到引用默认实服务器组上的配置差异，划分下虚服务器的转发方式。如下：

·     动作配置了实服务器组，根据实服务器组下实服务器指导转发。

·     动作没有配置实服务器组或配置实服务器组不存在，转发方式为丢弃。

·     策略下没有配置动作，或虚服务器引用策略不存在，按默认实服务器组转发。

1.1.8  HTTP NAT64功能怎么实现的？

HTTP类型虚服务器支持NAT64功能，具体实现如下：

Client------------(IPv4)--------->LB----------(IPv6)-------->Server

Client------------(IPv6)--------->LB----------(IPv4)-------->Server

注意：

·     HTTP服务器尽可能的使用和客户端协议一致的类型进行负载分担，即客户端是IPv4，选择的服务器在既支持IPv4也支持IPv6的情况下，会使用IPv4地址和服务器进行连接。如果配置的服务器的IPv4地址如果路由不可达，接收到客户端的IPv4请求时也会继续使用IPv4和后台服务器进行连接。这种情况下建议用户配置实服务器下配置健康检测来进行规避。

·     NAT64转换的实现依赖于对应的SNAT地址池，即如果实现IPv4转成IPv6和服务器链接，那么实服务器组必须配置IPv6的SNAT，否则无法转换。

1.1.9  虚服务配置有哪些注意事项？

虚服务器可用条件是配置IP地址和开启服务。因为虚服务如配置为重定向是不需要配置实服务器组和策略的。如配置可用虚服务器且被报文命中，转发流程就进入LB流程处理。

虚服务器传输层类型（TCP/UDP/任意）、VPN、IP地址、端口、掩码唯一确定一个服务，五者的组合在虚服务器的配置中要满足唯一性。

任意两个类型为TCP、HTTP或快速HTTP的虚服务器不可以进行VPN、IP地址、端口、掩码均相同的配置操作，命令行会提示错误。因为基于的四层协议都是TCP，这种相同配置会影响到报文对虚服务器的匹配和流量的转发。除此外，IP或UDP类型的虚服务器如配置和其他类型虚服务器的IP地址、端口、掩码相同，虽然不会提示错误，但匹配虚服务的报文，会走哪个虚服务处理，是不确定的，不建议用户做此类配置动作。总结来说，对于快速HTTP、HTTP、IP和TCP这四种类型，请避免配置VPN、VSIP和端口号都相同、但类型不同的虚服务器，否则将无法预知负载均衡设备处理报文的方法。

1.1.10  负载均衡策略和持续性配置有哪些注意事项？

通用类型的负载均衡策略只能引用通用类型的负载均衡类和负载均衡动作，HTTP类型的负载均衡策略则无此限制。

四层虚服务器无法引用七层持续性方法、七层策略及七层参数。如用户进行此类错误配置，配置将不生效。

1.1.11  HTTPS卸载组网流量不通怎么排查？

·     如果虚服务器引用了SSL策略，则必须为其配置一个非缺省端口号（通常用443），如不配置，将不能正常处理。

·     修改SSL的配置，虚服务器目前无法感知，要想让SSL的配置在虚服务器上生效，请主动在虚服务器下执行undo service enable和service enable。

·     实服务器端口号配置是否与真实服务器开放的端口一致。

1.1.12  Cookie插入和Cookie重写持续性有什么区别？

Cookie插入持续性与Cookie重写持续性区别在于，Cookie重写需要服务器应答报文携带指定name的Set-cookie或Set-cookie2头域，LB设备改写对应的value值，并发给客户端。而Cookie插入持续性不需要服务器端提供此配合。

1.1.13  Cookie插入和Cookie重写如何生效？

Cookie插入持续性方法被虚服务器或者负载均衡策略引用后，LB会插入set-cookie字段给客户端，客户端请求中携带此字段的请求报文会匹配持续性表项，转发给相应的服务器处理。

Cookie重写持续性方法被虚服务器或者负载均衡策略引用后，LB会重写服务器应答报文的set-cookie字段给客户端，客户端请求中携带此字段的请求报文会匹配持续性表项，转发给相应的服务器处理。

1.1.14  配置参与算法调度的最小与最大实服务器数量有哪些注意事项？

配置了最小与最大参与算法调度的实服务器数量后，参与算法调度的实服务器不能少于最小值，除非实服务器组下的实服务器总数少于配置的最小值，那么所有的实服务器都参与调度，否则按优先级选取参与算法调度的实服务器且不能大于最大值。

1.1.15  实服务器权值对哪些调度算法有效？

实服务的权值对加权轮转算法，带宽算法，加权最小连接算法，基于成员的加权最小连接算法有效。

1.1.16  故障处理方式为断开已有连接时，对于UDP和ICMP流量需要辅佐开启什么命令？

系统视图下需要开启ip unreachables enable，否则无法向客户端发出断开连接的报文。

1.1.17  IRF组网中如何配置会话备份？

LB IRF组网中，主备框的会话同步，必须要同时配置session sync和connection-sync这两个命令。一般情况，客户肯定需要主备框会话同步的，那就是这两条命令是必须配置的。

七层虚服务VS类型不支持该热备命令。

1.1.18  SLB、outbound 和 inbound 的健康检查方法，以及动态就近性探测方法，分别都有哪些？

SLB的对于实服务组和实服务器的健康检查方法，都支持哪些？

支持全部nqa探测模板类型

Outbound对于实服务组和实服务器的健康检查方法，都支持哪些？

支持全部nqa探测模板类型。

Outbound的动态就近性探测，都支持哪些？

支持负载均衡探测模板。

Inbound的链路的健康检查方法，都支持哪些？

支持全部nqa探测模板类型。

1.2  出链路负载均衡

1.2.1  OutBound链路负载虚服务和静态路由、策略路由的关系是什么？

OutBound链路负载均衡虚服务优先级高于静态路由和策略路由，因此如果报文匹配到OutBound链路负载均衡的虚服务，则负载均衡模块优先处理；如果报文没有匹配到虚服务，则会依次匹配策略路由、静态路由。

1.2.2  流量匹配上就近性表项，可是为什么就近性表项仍然会老化呢？

LB只是转发中间的业务处理之一，LLB是处于慢转预处理和查fib之后的处理阶段。

某一会话的首报文到到达LB，LB会为其选路，选择好RS后，会话会有快转表项生成，此会话的后续报文就不用再次选择RS了，就直接按照快转表项中的进行转发。因此如果开启就近性，也不会匹配就近性表项，而是直接走快转了。

因为就近性表项的刷新，是靠流量匹配来刷新的。此时，因为没有流量来匹配就近性，所以就近性表项可能会老化掉。

1.2.3  就近性计算时的参数影响是什么样的？

在就近性计算时是根据各参数来计算各链路的。某一参数的权值增大，就说明其影响力变大。比如TTL和COST：

RS1: TTL(3) COST(99) COST优；

RS2: TTL(2) COST(100) TTL优；

就近性下TTL权值1 COST权值50；那么最终应该是RS1比较优；

如果就近性下TTL权值100，COST权值50，那么最终应该是RS2比较优。

1.2.4  就近性表项已经存在时，修改就近性探测方法，会怎么样？

已经存在就近性表项时，修改就近性探测方法，则会立即清空就近性表项，然后再由报文触发，利用新的探测方法进行就近性探测。

1.2.5  为什么修改Link的cost会清除就近性表项，而修改带宽不会呢？

在就近性计算中，cost是其中一个计算参考值，所以在修改Link的cost时，会立即清除已有的就近性表项，以便将来有流量触发时重新计算就近性；

虽然就近性计算中，带宽也是计算参考值，但是这里的带宽指的是剩余带宽，剩余带宽会根据网络状况实时变化，就近性计算不可能实时去响应其变化。在修改Link的rate-limit band 时，修改的是Link的总带宽，并不是剩余带宽。

1.2.6  为什么Link没有被引用，却也是active的呢？

Link如果被link-group引用了，受outbound配置的限制。如果outbound配置不完全就会显示该Link为inactive的。

Link如果没有被link-group引用，只要有IP且触发了探测，按照探测决定状态。若没有探测就直接Active。

1.2.7  为什么nqa的debug中总打印一些abandon的error信息呢？

*Jun 11 16:44:48:264 2015 H3C NQA/7/Error: -Context=1; NQA entry (t1-instance12d
9e7090?) abandon the unknown packet

协议栈对icmp报文全局上送，每个rawip icmp socket，都会收到其他模块icmp报文或者本模块其他icmp socket报文，对于这些报文会丢弃。

1.2.8  Link1是持续性表项，同时Link1配置带宽保护，为什么有时带宽保护不生效呢？

持续性组下有个功能 override-limit enable，开启该功能后，如果该连接匹配了已有的持续性表项，将不受Link上的带宽（指的带宽保护bandwidth busy-rate和max-bandwidth，以及带宽速率rate-limit bandwidth）及连接参数(rate-limit connection和connection-limit max ) 以及虚服务器上的连接数限制（指的lb-limit-policy）影响。

1.2.9  虚服务上同时配置连接限制，和连接数限制策略limit-policy，是怎么生效的？

是虚服务下直接配置的连接限制先过滤一次，然后再通过limit-policy过滤一次，两重过滤。

1.2.10  负载均衡动作中配置fallback-action continue，查找链路失败时继续匹配策略中下一条引用规则？

这个是指动作中查找链路失败时，继续匹配策略中的下一条引用规则。

1.2.11  在负载均衡策略中转发报文时会按照配置顺序来匹配流量特征和动作，匹配成功则执行相应动作，否则继续匹配下一条负载均均衡流量特征？

这个是指策略中的流量特征如果第一条匹配不上默认继续向下匹配。

1.2.12  带宽繁忙如何测试？

带宽繁忙生效依据：当前流量带宽大于通过命令max-bandwidth配置的链路最大期望带宽。

当前流量的带宽获取方式有两种：

链路自己统计的带宽；从接口获取的带宽，这个需要在虚服务下使能从接口获取带宽，同时注意接口获取带宽默认是300s,如果链路对应的是物理口则可以使用flow-interval设置获取统计的时间。如果link对应的是物理口外的其他端口则只能是默认300s。如果接口的带宽值大于这个值则达到了链路繁忙状态，如果链路一直繁忙那么此时该链路不分发新建连接，已有连接不受影响，新建速率为0，直到恢复不繁忙状态会有新建连接。

首先vs下要开启繁忙保护及从接口获取带宽的功能，链路中设置最大带宽max-bandwidth和带宽繁忙比bandwidth busy-rate，当前流量的带宽大于最大带宽*带宽繁忙比则链路繁忙。

注意以下几点：

·     链路繁忙需要设置链路中的max-bandwidth。

·     如果链路下设置带宽限制rate-limit bandwidth，当前流量的带宽如果大于最大带宽*繁忙比，即链路繁忙，如果所有链路都繁忙的情况下，链路设置了rate-limit，此时接口最多转发rate-limit值，大于这个值会丢包。

·     繁忙保护仅对出接口output生效，对input不做限制。只负载client往外的请求。

·     Outbound链路繁忙无debug信息。

·     链路里面设置带宽繁忙inbound方向、outbound方向或者inbound+outbound方向，只要有一个达到了繁忙保护值，link就处于受限状态不再有新建连接。

测试过程中可能遇到的现象：

·     繁忙生效后，出接口output方向统计为0 ，本来应该是至少有max*busy 的值，可能因为测试仪器对原有连接后续没有流量

·     链路下配置max-bandwidth、bandwidth busy-rate有inbound、outbound 只是对出接口input、output 进行统计，对于output值会限定在max*busy-rate值内，对于input统计不限制。

1.2.13  链路组中，如果链路设置了优先级最高，当这个链路带宽达到了繁忙保护的值或者连接的最大值后，会切换到其他链路？

当优先级高的链路达到最大连接数后，vs 丢包，不会将连接发到低优先级链路上。如果链路组中设置了参与调度的链路也不重新选择其他链路。

1.2.14  链路组中，如果链路设置了优先级最高，同时设置了参与调度的链路？

当高优先级链路down或者探测失败会选择低优先级链路。

1.2.15  带宽算法和最大带宽算法解释？

·     带宽算法

bandwidth：带宽算法，即报文根据实服务器的权值与剩余带宽比例分发到各实服务器上。

进入虚服务器视图virtual-server vritual-server-name；配置链路的带宽由接口统计：bandwidth interface statistics enable

缺省情况下，链路的带宽由负载均衡模块自行统计。

剩余带宽 = 链路的最大带宽 - 当前带宽

如果要测试带宽，一般都配置link的最大带宽

rate-limit bandwidth [ inbound | outbound ] bandwidth-value

是配置RS的最大带宽，和接口带宽没有关系

只有VS下打开了bandwidth interface statistics enable，RS的当前带宽不再使用LB自行统计的带宽，而是使用RS IP地址所在的接口的带宽作为RS的当前带宽。

LB自行统计带宽，是指的LB分发给该链路的报文，每秒做一次，然后下一秒分配连接时，就根据前一秒的这个值来确定链路带宽。

加入rs1的weight是3，剩余带宽100M；rs2的weight是2，剩余带宽200M；rs3的weight是1，剩余带宽是300M，那么三个实服务器怎么分配？

大致比例：大致：3*100 ： 2*200 ： 1* 300

但是具体实现不是这么做的。可以这样理解

·     最大带宽算法

max-bandwidth：最大带宽算法，即报文总是分发给当前空闲带宽最大的实服务器。

不论是否配置接口下获取带宽，总带宽都是根据rs下配置的rate-limit band。

而如果虚服务下配置了从接口获取带宽，那么当前使用的带宽就从接口的Last来获取；如果没有配置从接口获取带宽，就从display real-server statist 的Throughput来获取。

如果在虚服务下配置从接口统计带宽，那么LB是从接口的Last统计中来获取带宽的。

接口的Last统计间隔，根据在接口上配置flow-interval来配置，比如flow-interval 5 就是每5秒统计一次；

LB则是固定的每一秒都向接口Last获取一次值，得到当前使用带宽，再用配置在实服务器下的rate-limit band 总带宽，来减去当前使用带宽，得到当前空闲带宽，进行比较。

接口最小统计间隔是5秒，这5秒内都只有同一个接口的流量是最小的，所以这5秒内LB分配也只有这个实服务器rs1被选中。下一个5秒时，实服务器rs1的流量就会统计为较大，那么就会在剩下的实服务器里选择一个最大剩余带宽的，选中后就再次开始这个过程的循环。总之，接口统计5秒时间内，都只会选择同一个实服务器；下一个5秒时间内，再次选择剩余带宽最小的实服务器。

可能会出现多个链路中，只有某几个链路有流量，其他几个链路一直没有流量的情况？

最大带宽算法就是会选择一个SF中剩余带宽最大的RS，如果有多个RS剩余带宽一样大，就会把排在前边的选出来（可能和你创建RS的顺序有关），之前被选过的RS的剩余带宽会在其他RS被选期间再次变大，从而再次被选，导致有几个一直没有机会被选。

1.2.16  如果使能了动态就近性，且设置了链路的优先级，如果动态就近行探测到的链路优先级低应该如何处理？

就近性选择优先级高的链路为最优链路。

1.2.17  保持上一跳和静态路由、策略路由的优先级顺序是什么？

保持上一跳优先级高于静态路由和策略路由，策略路由优先级高于静态路由；如果没有保持上一跳，则会依次匹配策略路由、静态路由。

1.2.18  就近性和持续性都存在，流量先是去匹配哪个呢？

先匹配持续性，如果持续性表项不匹配，再去匹配就近性表项，如果就近性表项也不匹配，就按照算法来选择链路。

既使能持续性又使能就近性时，如果持续表项和就近性表项都不存在的情况下，是先根据算法生成持续表项。然后根据探测结果生成就近性表项。

持续性表项和就近性表项同时存在的情况下，持续表项优先。

1.2.19  就近性与链路带宽限制在选择链路时有什么样的相互影响？

如果链路配置了带宽速率限制，即使就近性表项中该链路为最优，也会因为带宽限制而不走它，而是选择次优。等这个链路的带宽低于限制后，则再次被选择。

1.2.20  就近性表项已经存在时，修改就近性探测方法，会怎么样？

已经存在就近性表项时，修改就近性探测方法，则会立即清空就近性表项，然后再由报文触发，利用新的探测方法进行就近性探测。

1.2.21  为什么已经在链路组下使能就近性功能了，却仍然没有生成就近性表项？

可以先检查就近性下有没有配置就近性探测方法。

因为就近性表项的产生依赖于就近性探测，因此如果此处没有配置有效的就近性探测方法，则不会生成就近性表项。

1.2.22  修改链路的COST、RTT、带宽等参数对就近性表项有什么影响？

当就近性参数变化时，如果对选择链路优先级产生影响会更新就近性表项，产生新的最优链路。当手工清除就近性表项或者就近性表项自然老化，就近性表项会删除。

1.2.23  为什么所有link-group都去使能就近性，就近性表项仍然存在呢？

就近性表项是针对全局的，针对所有link-group的。当所有link-group都去使能就近性时，表项不会立即删除，也不会进行就近性探测，表项不会生效。而是继续保留直到老化删除，或者手工删除。

1.2.24  SIP流量时，为什么有时不能产生就近性表项呢？

如果此时会话里已经有会话了，则会直接按照会话转发，不再触发就近性探测。

如果没有会话，但是已经有会话关联表了，则首包会匹配会话关联表，而建立会话，以后的报文直接走会话。

子会话会根据关联表建立会话，然后走非首包流程。

1.2.25  为什么链路没有被引用，是什么状态？

链路如果被link-group引用了，受llb outbound配置的限制。如果llb outbound配置不完全就会显示该链路为inactive。

链路如果没有被link-group引用，只要有IP且触发了探测，按照探测决定状态。若没有探测状态为unknown。

1.2.26  带宽繁忙保护对算法对选路的影响？

link-group中配置最大带宽算法，链路link1配置带宽繁忙比，并且剩余带宽最大：

根据最大带宽算法，先分配给link1，当link1的带宽超过保护带宽后，此时link1停止分配连接，连接分配给link2；当link1的带宽下降至保护带宽以下时，因为剩余带宽最大，再次因为最大带宽算法而分配连接。

link-group下使能就近性功能，当link1带宽超过保护带宽后，将不参与算法，也将不参与就近性探测。当带宽小于保护带宽后，重新加入算法，重新被就近性探测。

link-group下配置持续性，link1配置带宽保护，若持续性表项为link1，则将不受带宽保护的影响，而继续按照持续性向link1分配连接。

当链路使用带宽超过设置的繁忙比例即认为链路繁忙，默认繁忙比为70%，如果所有链路都超过繁忙比，那链路保护失效，算法重新回到最初配置的算法。当link1的当前带宽下降至最大带宽繁忙比以下后不会重新分发，要等到下降到新版本中支持的最大带宽繁忙恢复比，才会再重新分配。

1.2.27  关于链路负载均衡健康检测的参数有什么设置建议？

参数建议：

(1)     Frequency > “probe timeout”

(2)     故障切换时间=(“reaction trigger probe-fail” – 1 ) * frequency + “probe timeout”

(3)     Max（恢复时间）= frequency * “reaction trigger probe-pass”

(4)     Frequency、probe timeout、 reaction trigger probe-fail过小可能导致网络震荡。

1.2.28  测试时发现就近性表项空或无预期链路，怎样排查错误？

请排查如下几项：

(1)     流量匹配的链路组下是否已使能就近性

(2)     就近性视图下是否已配置探测方法

(3)     链路状态是否为active

(4)     链路是否配置各种限制，且已到限（带宽，连接数，繁忙阈值等）

1.2.29  测试时发现就近性表项最优链路发生变化，怎样排查错误？

请排查如下几项：

(1)     原最优链路不在优先级链表里了，请看就近性表项空或无预期链路的相关排查项

(2)     大流量导致链路的剩余带宽发生改变，从而影响优先级。可将就近性视图下带宽的权值设置为0，排查是否是受其影响

1.3  DNS透明代理

1.3.1  使用DNS透明代理时，客户端DNS地址可以设置为LB设备的接口地址吗？

DNS透明代理默认全部为0.0.0.0的话，客户端DNS地址设置为LB设备的接口地址，这样就不会进行DNS代理，因此不建议配置为设备接口地址

如果客户端DNS地址设置为LB设备接口的地址，需要将DNS proxy视图下的地址同样设置为该地址才会处理（32位掩码），但目前建议是DNS proxy地址为0.0.0.0，web也是默认0.0.0.0

1.4  本地智能DNS

1.4.1  智能DNS（LLB Inbound）就近性有哪几种？

目前的新版本上关于就近性算法有两种，静态就近性算法选择topology；动态就近性算法选择proximity。

1.4.2  虚服务池（virtual-server-pool）中调度算法的优先级如何选择？

配置虚服务器池的调度算法时，可以分别指定首选调度算法、备选调度算法和次选调度算法。其中，首选调度算法优先级最高，当采用首选算法不能选出可用的虚服务器时，采用次选调度算法，备选调度算法优先级最低。

1.4.3  智能DNS（LLB Inbound）开启会话备份功能，而智能DNS报文的未会话备份？

系统视图下已开启session synchronization dns http和session synchronization enable，而智能DNS未对会话进行备份？

统计是各板独立的，会话备份请查看会话表项，UDP DNS流量会话备份意义不大，一般一个请求+一个应答。

1.4.4  虚服务池中如果指定首选调度算法为拓扑，未指定备选和次选，首选vs 达到链路繁忙保护后，接下来的请求如何处理？

如果虚服务池中某个vs对应的link达到链路繁忙保护后，继续根据报文源ip匹配的topo下在其他未达繁忙保护的vs里面选择。vsp中使用优选调度算法是拓扑，如果拓扑中没有匹配的vs,没有指定次选和备选调度算法，这时候选不出vs失败了，因此需要配置次选和备选的调度算法。

1.4.5  当首选算法为动态就近性时，有丢包怎么办？

动态就近性算法，由报文触发，立刻生成就近性表项，十秒后生成可用的就近性表项，期间DNS请求会被拒绝，所以要填写备选和次选算法，如加权轮转算法，保证业务的正常处理，待生成可用的就近性表项后，首选调度算法可用。