H3C 负载均衡设备用户FAQ

1  链路负载均衡

inbound

llb vip和dns监听的ip地址是否可以相同？

最好不要重叠，可能出现只走了inbound的业务而后续业务没走。（地址重叠之后业务应该是先走LLB VIP的，虚服务器的匹配优先级是高于dns监听地址的。）

inbound就近性如何实现？

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

vsp中调度算法的优先级如何选择？

按照配置的优先级顺序，优选、次选和备选。

inbound过程中如何看dns监听到并且回复某个vip这个过程的debug

注意lb的debug看不出来，需要开启dns-server和glb debug。

新版本上的debug调试信息命令开关已改为，用户视图下：

debugging glb all

debugging local-dns-server all

为什么SLB ftp流量 出接口做了nat outbound后，报文载荷中地址未进行地址的转换

SLB alg如果配合nat模块使用，nat模块优先，LB载荷中地址不会转为vip地址。

Inbound不支持慢宕功能

Inbound方向dns统计为啥不备份，系统视图下已开启session synchronization dns http和session synchronization enable。

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

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

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

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

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

为何Inbound方向link没有统计信息？

Inbound虚服务下关联的是实服务，而不是链路组，link统计信息无意义。

Inbound vs必须配置32位掩码

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

当所有链路都达到最大带宽繁忙保护后，实际认为所有VS均可调度。

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

链路繁忙保护如何验证生效？

开启lb的event debug可以有如下信息：

The related link exceeded inbound bandwidth busy rate.

The related link exceeded outbound bandwidth busy rate.

The related link exceeded bandwidth busy rate.

LLB和SLB哪些使用Tcp proxy

SLB的L7使用tcp proxy。

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

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

Outbound

带宽繁忙如何测试？

带宽繁忙生效依据：当前流量带宽> max-bandwidth*bandwidth busy-rate

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

Link自己统计的带宽；

从接口获取的带宽，这个需要在虚服务下使能从接口获取带宽，同时注意接口获取带宽默认是300s,如果link对应的是物理口则可以使用flow-interval设置获取统计的时间。如果link对应的是物理口外的其他端口则只能是默认300s。

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

注意以下几点：

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

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

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

·     Outbound链路繁忙无debug信息。

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

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

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

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

如果看到链路繁忙生效了？

Link下设置的最带带宽*繁忙比，这个值与接口获取的300s（默认）的值对比，如果接口的带宽值大于这个值则达到了链路繁忙状态，如果链路一直繁忙那么此时该链路不分发新建连接，已有连接不受影响，新建速率为0，直到恢复不繁忙状态会有新建连接。

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

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

链路组中使能重定向，如果link设置了优先级最高，同时设置了参与调度的链路？

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

带宽和最大带宽调度算法解释如下：

(1)     带宽算法

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

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

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

剩余带宽 = link的最大带宽 - 当前带宽

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

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

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

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

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

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

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

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

(2)     最大带宽算法

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被选期间再次变大，从而再次被选，导致有几个一直没有机会被选。

Isp文件下载到双机设备后，改变irf主，加载isp文件为何失败？

Isp不支持跨设备获取，双机环境只能加载到主上。

如果备份链路组中设置温暖上线，那么当由主链路组切换到备份链路组的时候，温暖上线是否生效？

验证结果：切换到备份链路组后，温暖上线不生效，只有新加入该链路组的链路温暖上线生效。

如果使能了动态就近性，且设置了链路的优先级，如果动态就近行探测到的链路优先级低应该如何处理，就近性选择优先级高的链路为最优链路。

reset loadbalance connections断开LB的连接？

注意只能断开七层的连接，对于四层无效，断开连接后统计也就没有了。

SSL健康检查和HTTPS健康检查区别是什么

(1)     配置SSL类型的NQA模板：

SSL类型的NQA模板为外部特性提供SSL类型测试，外部特性通过引用该模板，测试NQA客户端是否可以与指定的SSL服务器建立SSL连接，从而通过SSL连接建立的时间判断服务器的连通性及性能。

(2)     配置HTTPS类型的NQA模板：

HTTPS（Hypertext Transfer Protocol Secure，超文本传输协议的安全版本）是支持SSL（Secure Sockets Layer，安全套接字层）协议的HTTP协议，通过SSL为HTTP协议提供安全保证。

HTTPS类型的NQA模板为外部特性提供HTTPS类型测试，外部特性通过引用该模板，测试NQA客户端是否可以与指定的HTTPS服务器建立连接，以及从HTTPS服务器获取数据所需的时间，从而判断HTTPS服务器的连通性及性能。

区别：SSL只建立SSL连接，HTTPS建立SSL连接后发送HTTP请求。

Outbound LLB

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

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

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

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

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

因为就近性表项的刷新，是靠流量匹配来刷新的。此时，因为没有流量来匹配就近性，所以就近性表项可能会老化掉。对于新的会话如果匹配了已有的就近性表项会刷新就近性表项的老化时间。

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

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

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

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

就近性与link带宽限制同时起作用吗？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Link1是持续性表项，同时link1配置带宽保护，为什么会有很多失败呢？

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

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

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

使用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

DNS透明代理与LLB inbound有冲突吗？

如果DNS透明代理dns-proxy设置的DL的地址32位，此时llb inbound的DL监听地址也是这个的话，会优先匹配了LLB inbound，但是正常配置的话，web上面dns-proxy默认为0.0.0.0，因此DNS透明代理和LLB inbound不会有冲突。

2  服务器负载均衡

快速HTTP和HTTP类型虚服务器实现区别

快速HTTP是一种对于HTTP的快速处理机制，目的提高七层LB处理性能，以达到一些用户对负载均衡设备的性能需求。为此快速HTTP类型的虚服务器在功能处理上对某些复杂功能，支持情况和HTTP类型虚服务器有所区别。

快速HTTP类型虚服务器目前支持功能如下表：

业务点

支持功能

不支持功能

持续性

·     addressport持续性方法

·     cookie 持续性方法cookie 会话老化，和老化时间老化cookie 检查所有报文

·     http header 持续性持续性表项显示

Ssl session-id content payload

参数

·     set ip tos exceed-mss

·     case-insensitive

·     rebalance per-request

·     secondary-cookie delimiters

·     secondary-cookie start

·     header modify per-request

·     server-connection reuse

·     content maxparse-length

·     header maxparse-length

·     header exceed-length

源地址池

均支持

实服务器组

·     Predictor

·     Activate

·     slow-online

·     snat-pool

·     selected-server

·     display serverfarm

·     probe

·     success-criteria

·     fail-action

transparent enable

class

·     match url

·     match method

·     match http class

·     match generic class

·     match source

·     match header

·     match cookie

match content

action

·     server farm

·     set ip tos

·     header 插入

·     ssl location

·     header 重写

·     header 删除

策略

均支持

实服务器

均支持

虚服务器

·     fast http 类型虚服务器

·     virtual ip/ipv6 address

·     port

·     default

·     lb-policy

·     parameter

·     service

·     display virtual-server

·     display virtual-server statistic

·     reset virtual-server statistic

·     connection-limit

·     rate-limit connection

·     rate-limit bandwidth

以下功能在fasthttp下不能配置：

·     udp per-packet

·     redirect relocation

·     redirect return-code

·     ssl-server-policy

·     ssl-client-policy

注：不支持pipeline报文转发；解析处理只解析字段，未解析具体内容；部分处理形式和七层有所不同；不支持分片报文的match匹配；只支持特征在请求报文的首包。

七层虚服务下引用策略与默认实服务组优先级问题

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

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

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

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

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

验证：虚服务下有默认实服务器组和策略的时候，策略优先级高，如果策略中的动作里的实服务器组不存在或者没有配置的时候，这时候会丢弃一部分报文，然后走虚服务里配置的默认实服务组。

策略是4层通用类型的，类与转发动作也是4层，动作为转发，不管虚服务中有没有使用默认实服务组，都是流量失败，调用策略，抓包client端404网页失效找不到。（503的意思是网页临时不可访问）

策略是4层通用类型的，类与转发动作也是4层，动作为负载均衡，不管虚服务中有没有使用默认实服务组，都可以正常走策略进行负载均衡。

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，否则无法转换。

HTTP压缩功能

实现HTTP压缩，要求客户端支持压缩，请求报文头中声明支持的压缩算法。

HTTP压缩配置报文头的修改优先于Action下的报文头修改，另外HTTP压缩应答报文，可能会采用chunk分块发送，因此需要增加压缩必须的报文头，这些与用户配置无关，必须保证报文头的正确性，这些不受Action处理影响。

HTTP压缩配置增加vary字段，和Action下配置增加vary字段，两者配置无关，都会进行增加处理，一般不建议用户这么配置。

压缩下rule规则表：

None：没有配置相应的规则。

Permit：匹配到配置是允许压缩。

Deny：匹配到配置禁止压缩。

Not Found：没有匹配到规则。

url\Content

None

Permit

Deny

Not Found

None

Y

Y

N

N

Permit

Y

Y

N

Y

Deny

N

N

N

N

Not Found

N

Y

N

N

入方向负载均衡功能

目前实现基础DNS服务器功能，支持基于IPV4的UDP DNS查询，查询记录包括UDP报文的A、AAAA记录查询。支持迭代查询，不支持递归查询。

规格实现要求：

DNS请求字段请求字段请求数目必须为1。

HTTPS卸载

目前的版本中blade4设备不支持rc算法（rc2，rc4算法均不支持），L5000是支持的。

LB支持IPS\AV\WAF

·     目前的版本中支持如下协议HTTP\HTTPS\POP3\SMTP\IMAP\FTP\TFTP\SIP\DNS\TELNET\RTMP\SMB\NFS

·     L7不支持攻击位于IP头或TCP头的IPS\AV\WAF检测

·     L7对于卸载后报文的IPS\AV\WAF检测，目前只支持HTTPS卸载为HTTP

·     L7只针对客户端侧进行IPS\AV\WAF的检测

·     L7不支持将客户端侧应用识别出的APP ID（会话上记录）继承到服务器侧

互通配置类FAQ

虚配置注意事项

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

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

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

类配置注意事项

不同的负载均衡类可以与同一负载均衡动作组成匹配规则。

如果嵌套的负载均衡类lbc1中已嵌套负载均衡类lbc2，则lbc2在此嵌套中将不会生效。举例：class1 配置 match class class2 ，而class2 配置match class class3 则对class1而言，class3任何配置不生效。

动作配置注意事项

转发类动作：确定是否转发以及如何转发报文。如果没有配置转发类动作，报文将被丢弃处理。

修改类动作：对报文执行一些修改行为。修改类动作应配合转发类动作使用，否则修改后的报文终将被丢弃。

七层的动作可以配置转发实服务器组，如果没有配置默认是丢弃，四层的动作可以配置转发实服务器组，或直接转发，如果没有配置默认是丢弃。

HTTP类型的Action下配置各项header操作，都可以配置多个。

Cookie持续性配置注意事项

Cookie插入和Cookie重写持续性方法不会产生持续性表项，其持续性是通过LB向服务器应答方向报文中插入或改写Set-cookie头域的name及value值实现。

Cookie 持续性方法配置的持续性老化时间，可以配置为0。当其持续性方法为Cookie插入或Cookie重写时，0表示该持续性为会话持续性；当其持续性方法为Cookie截取时，0表示此持续性表项的超时时间为0秒。

常见配置限制注意事项

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

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

测试方法类FAQ

虚服务器及SNAT地址池Ping问题

目前虚服务器IP地址及SNAT地址池地址没有下发地址管理，所以不能直接回应外界Ping报文。

HTTPS卸载组网测试注意事项

具体组网配置请参见《负载均衡配置》手册2.13.3章节“2.13.3  七层服务器负载均衡SSL终结配置举例”。下面就其组网配置常见问题进行说明。

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

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

SSL默认是支持会话重用的，这个不需要进行配置。目前支持会话重用个数的设置，默认为500，个数越大，缓存的会话个数越多

Cookie插入持续性测试建议

配置Cookie插入持续性方法，被虚服务器引用时，不同实服务器组下，建议配置不同的持续性组，且Cookie插入的name信息配置互不相同。防止客户端特征流量发生切换时，将原有name信息对应value值覆盖掉，导致Cookie特征被替换，持续性老化时间内，Cookie插入持续性方法对后续流量无效。

举例：

虚服务器配置引用策略下包含两组规则：class1、action1和class2、action2，如果action1和action2下引用持续性方法均为Cookie插入持续性方法且对应相同持续性组sticky1，当客户端流量先后匹配class1-class2-class1，因匹配class2时，报文根据调度算法重新选择RS，并在应答报文插入新的持续性信息，导致客户端再次请求匹配class1时，原有持续性信息已不存在。

Cookie插入和Cookie重写持续性区别

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

Cookie插入和Cookie重写如何测试持续老化

Cookie插入和cookie重写持续性老化方式分两种：会话老化、持续性老化时间老化。

会话老化：即LB设备对应持续性的老化时间配置为0。测试时，LB给客户端的应答报文不携带expire字段，客户端将正在访问的浏览器关闭，再开启。客户端再次发起的请求不再携带Cookie字段对应name=value字段。LB认为持续性老化，重新分发报文。

持续性老化时间老化方式需要设备设置系统时间和客户端所在时区时间一致，以北京时间为例：

# 取消设备上的时区。

<Sysname> system-view

[Sysname] clock protocol none

[Sysname] undo clock timezone

# 配置系统时间为当前格林尼治时间。

# 根据所在时区配置当前系统时间的时区。

<Sysname> system-view

[Sysname] clock timezone CTS add 8

完成上诉配置后打报文，配置持续性老化时间是60s，抓包查看LB首次回应的应答报文携带set-cookie信息，老化时间距离首次请求的60s之后。

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

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

(1)     假设实服务器组下有5个实服务器，其对应的优先级为1，2，3，4，4，如果配置的最小最大参与实服务器数量为2，3，则参与算法调度的实服务器只有两个优先级为4的实服务器，如果高优先级的实服务器个数等于最小值，则在高优先级的实服务器上进行算法调度。

(2)     假设实服务器组下有5个实服务器，其对应的优先级为1，4，4，4，4，如果配置的最小最大参与实服务器数量为2，3则参与算法调度的实服务器只有优先级为4的三个实服务器，如果高优先级的实服务器个数大于最大值，则在最大值个数的高优先级实服务器下进行调度。

(3)     假设实服务器组下有5个实服务器，其对应的优先级为1，2，3，3，4，如果配                                     置的最小最大参与实服务器数量为2，4则参与算法调度的实服务器有优先级为4与优先级为3的三个实服务器，如果高优先级的个数小于最小值，且高优先级与次优先级的实服务器总数小于最大值，则在高优先级与次高优先级的实服务器上进行调度。

(4)     如果实服务器组没有配置最小最大参与实服务器数量，则算法只在优先级最高的实服务器之间进行调度。

加权轮转及加权最小连接调度算法组网配置注意事项

调度算法的权值只针对加权轮转和加权最小连接算法有效。

轮转调度算法是指在轮转调度中综合考虑各实服务器的权值，在调度新连接时尽量使服务器的分配连接数与权值成比例。当服务器组中所有的服务器权值均相等时，依次轮转。

如：当前有三个服务器A、B、C，权值依次为3、2、1，假设均未达到连接上限，则在调度结果为ABCABAABCABA……

每次能达到测试效果的报文数需为如下基本公式的倍数：

Vcpunum*∑Wi 即 每cpu数*所有实服务器权值求和。

最小连接调度算法是指在调度中综合考虑各实服务器的权值和当前活动连接数，在调度新连接时尽量分配当前连接给连接数/权值后最小的实服务器。

服务器负载均衡工作机制注意事项

服务器负载均衡在网络中工作部署分NAT模式和旁路模式两种，其具体组网请参见《负载均衡配置》手册2.1和2.3章节。下面就其组网配置常见问题进行说明。

NAT模式，具体分DNAT模式、SNAT模式及DNAT+SNAT模式。

(1)     DNAT模式：服务器端需配置静态路由，由服务器发往客户端的应答必须经过LB设备。

(2)     SNAT模式：服务器需在Loopback口上配置与虚服务器相同的IP地址。注：其它不响应ARP的方式亦可。

(3)     DNAT+SNAT模式：因同时做了目的地址转换和源地址转换，故服务器上可无特殊配置。

以上组网服务器均可与客户端不在同一网段内。

旁路模式，使用上有一定局限性，因其应答流量不经过LB设备，HTTP及快速HTTP类型下不可使用，故开启此功能无效。

如果发现基本功能不通，首先排查下是否是组网问题，查看下客户端到LB设备及LB设备到服务器端，报文是否互通，可发ping包测试。再打开LB的debug调试开关，查看报文是否上报虚服务处理，如已上报，再跟踪下是否配置不完全，导致丢包。

其它问题类FAQ

关于快速HTTP下执行cookie插入或是应答报文插入head等，流量不通的问题？

fasthttp对应答报文插入数据之后，应答报文数据将会增加，转发发送的时候可能会大于接口MTU或者是客户端的MSS而被丢弃。

这种情况建议虚服务器配置引用tcp parameter，parameter下配置tcp mss，将lb和后台服务器协商的MSS改小，足以保证执行完应答插入之后的报文不大于接口MTU和客户端的MSS。

就近性表项，持续性表项，先生成哪个，哪个最终起作用呢？

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

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

关于链路负载均衡NQA健康检测的参数设置建议（SLB也适用）？

参数建议：

(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过小可能导致网络震荡。

LB是否支持跨板转发？

LB不支持跨板转发，入出接口只能在同一板卡，设备堆叠时不支持跨板卡转发。

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

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

测试时发现就近性表项空或无预期链路，怎样排查错误？（当前是否放开各局点可以启用就近性：暂时不启用）

请排查如下几项：

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

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

(3)     NQA模板是否已创建且为就近性支持的类型（目前只支持icmp和tcp halfopen类型），模板名即探测方法名

(4)     触发探测的报文协议类型和就近性探测方法的类型是否匹配，若探测方法只有tcp类型，而报文非tcp报文，则不触发NQA探测

(5)     NQA模板下是否已配置reaction trigger per-probe

(6)     NQA模板下配置的探测频率是否过大

(7)     NQA返回探测结果是否为失败（可开启LB就近性调试信息查看返回的探测结果）

(8)     NQA是否因为缓存满而暂缓探测（可通过probe视图下dis system internal loadbalance statistics proximity查看当前重传队列情况）

(9)     link状态是否为active

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

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

请排查如下几项：

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

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

(3)     NQA返回的探测结果中RTT,TTL发生改变，可打开NQA调试开关查看。同样可将就近性视图下RTT、TTL的权值设置为0，排查是否是受其影响

connection-sync这个命令，用于同步IRF主备框之间的会话扩展信息，具体的扩展信息是啥？这个命令和session-sync有何区别？

配置了session-sync后，在VS下配置connection-sync才会同步LB业务的信息、会话信息。

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

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

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

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

支持全部nqa探测模板类型

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

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

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

支持icmp和tcp halfopen（原因这两种nqa探测可以返回RTT和TTL 这两者是 就近性探测需要的，如引用其他探测模板类型，也不会报错，但RTT和TTL将都为0，起不到动态就近性探测的效果）

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

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

服务器负载均衡，入方向链路负载均衡，出方向链路负载均衡，在组合使用时，有什么使用限制？

在实际组网使用时LB设备根据各组网需求，使用场景的不同，在配合上需要注意以下几点：

(1)     outbound是和slb四层一样，基于LB的 L4处理机制处理。 两者的虚服务器可以配置 IP地址为网段；所以他们在虚服务匹配上一些处理机制是相通的。

(2)     当outbound 或 slb 四层 配置了虚服务器地址为网段时 在和其他场景组合使用上 有以下几点限制：

a.     如果outbound 配合 slb 使用时， 要把 slb 对应的 虚服务器地址配置成接口地址

原因： LB处理流程 在匹配虚服务器时 先精确查找，再模糊查找，当发现到达设备的报文命中的是接口ip时 ，outbound 会认为是本机报文上送本机处理，不走透传。

b.     如果配置loopback 口为dnslistener监听地址、outbound 或slb 四层 虚服务器地址时，注意因loopback口不响应arp，要注意增加路由指引。 并且因为命中loopback口的报文认为是本机报文，outbound如果配置虚服务器是网段则不会进行透传。

结合以上说明，测试曾邮件咨询过一个问题 ：

本次组网操作，因为slb 对应vip地址不是设备接口地址，且当时vs是inactive，未实例化，当精确匹配无法查询到虚服务，且判断不需要本机接受此报文，就会查找outbound的全0地址透传出去。

Inbound中DNS监听地址是否可以配置为loopback口地址。

命令行中说的环回地址不是loopback口地址。loopback口地址不响应arp，在正规组网上不会作为监听地址使用，尽量不要错误使用。

基于应用的负载均衡有哪些环境限制?

在公网实验室测试基于应用的负载均衡，按照TCP协议的建立方式与LB实现机制的话，由于TCP是基于连接的协议因此后续的报文不会断掉连接进行重新选路，不建议TCP类型协议的应用在LLB outbound中使用基于应用的负载均衡  。但是基于UDP协议的应用测试的负载均衡效果好于基于TCP，因此如果使用基于应用的负载均衡建议使用UDP类型的应用。

LB与nat server使用哪些限制?

(1)     目前只要能NAT server能产生黑洞路由，匹配该nat server的流量后续不再经过LB流程的处理。如果在配置nat server下发的瞬间，黑洞路由产生需要时间，大约最多1S的时间内产生的匹配nat server的流量还是会走LB的流程（如果是LLB outbound的话，这1S产生的会话会产生环路），由于这个时间比较短，大体可以忽略。

(2)     Nat server有些还是产生不了的黑洞路由的，比如基于ACL的内部服务器，nat server global { ipv4-acl-number | name ipv4-acl-name }。这样走过nat server的流程的报文，还会走LB的流程，建议如果在LLB outbound的情况下，配置选择该内部地址的IP，让其动作为 forward all。

引用缓存策略且已生成缓存文件时，即使实服务组或策略不可用，也能使用缓存应答

缓存文件不与服务器关联，缓存文件对应服务器不可用情况，命中该缓存请求会应答，不会故障处理；进一步，对于服务器组下所有服务器都不可用，对于命中缓存请求仍会应答。

网址：H3C 负载均衡设备用户FAQ https://m.mxgxt.com/news/view/1677952

相关内容

H3C C220无线接入设备
H3C ER G2系列路由器 用户FAQ
华为公司申请资源池负载均衡专利，实现云计算系统中资源池整体的负载均衡
H3C ES4100系列瘦以太网交换机
H3C S1850V2
FAQ
诸葛用户设备对应关系 · 诸葛io使用文档
后疫情时代，FAQ芙颜珂高端美容仪的新探索
StarVR 推出搭载集成眼动追踪的 VR 头戴式设备
《全明星激斗》进阶测试FAQ

随便看看