防火墙之FTP服务器负载均衡
简介
服务器负载均衡技术可以提升企业的业务处理能力，方便后续的网络运维和调整。
日益增长的网络业务量对服务器造成了巨大压力，当单个服务器无法满足网络需求时，企业一般会采取更换高性能设备或增加服务器数量的方法来解决性能不足的问题。如果更换为高性能的服务器，则已有低性能的服务器将闲置，造成了资源的浪费。而且后续肯定会面临新一轮的设备升级，导致投入巨大，却无法从根本上解决性能的瓶颈。如果单纯地增加服务器的数量，则涉及到如何分配流量、服务器间的协同机制等很多复杂的问题。既要考虑成本因素和现实需求，又要兼顾日后的设备升级和扩容，服务器负载均衡（SLB，server load balancing）技术由此应运而生。
服务器负载均衡就是将本应由一个服务器处理的业务分发给多个服务器来处理，以此提高处理业务的效率和能力。如图1所示，这些处理业务的服务器组成服务器集群，对外体现为一台逻辑上的服务器。对于用户来说，访问的是这台逻辑上的服务器，而不知道实际处理业务的是其他服务器。由FW决定如何分配流量给各个服务器，这样做的好处显而易见：如果某个服务器损坏，FW将不再分配流量给它；如果现有服务器集群还需要扩容，直接增加服务器到集群中即可。这些内部的变化对于用户来说是完全透明的，非常有利于企业对网络的日常运维和后续调整。
服务器负载均衡功能可以保证流量较平均地分配到各个服务器上，避免出现一个服务器满负荷运转、另一个服务器却空闲的情况。FW还可以根据不同的服务类型调整流量的分配方法，满足特定服务需求，提升服务质量和效率。
实现机制
本节介绍了服务器负载均衡技术的常见概念和工作原理。
工作原理
服务器负载均衡技术的一些常见概念如下：
- 实服务器：处理业务流量的实体服务器，客户端发送的服务请求最终是由实服务器处理的。
- 实服务器组：由多个实服务器组成的集群，对外提供特定的一种服务。
- 虚拟服务器：实服务器组对外呈现的逻辑形态，客户端实际访问的是虚拟服务器。
- HTTP调度策略：FW分配业务流量给实服务器组时依据的规则，不同的调度策略得到不同的分配结果。仅适用于HTTP和HTTPS（HTTPS配置SSL卸载）协议。
- 负载均衡算法：FW分配业务流量给实服务器时依据的算法，不同的算法可能得到不同的分配结果。
- 会话保持：FW将同一客户端一段时间内的流量分配给同一个实服务器。
- 服务健康检查：FW检查服务器状态是否正常的过程，可以增强为用户提供服务的稳定性。
服务器负载均衡是按照逐流方式进行流量分配的，每一条流到达FW后都会进行一次负载均衡处理。这里的“一条流”可以理解为FW上建立的一条会话或一个连接，所谓“逐流”就是将属于同一条流的报文都分配给同一个服务器来处理。当会话老化后，即使流量的源IP、目的IP等网络参数都没有改变，也会视新建的会话为一条新流。
如图1所示，客户端Client 1发出的服务请求需经过FW负载均衡处理后，再转发至服务器集群中的某台服务器上。R1～Rx是一组提供相同服务的实服务器，它们组成实服务器组grp1，客户端Client 1的服务请求最终是由grp1中的一台实服务器来处理的。为了便于管理并保证实服务器的安全，实服务器组grp1在逻辑上抽象为一台高性能、高可靠性的虚拟服务器vs1。对于客户端Client 1来说，他访问的是虚拟服务器，而并不知道实际处理业务的是实服务器。
如无特别说明，本章所说服务器均指实服务器。
服务器负载均衡技术的核心是HTTP调度策略、负载均衡算法、会话保持和健康检查。
当存在多个可用的实服务器组时，FW会根据更加精细化的流量匹配要求，通过HTTP调度策略选择一个实服务器组，然后转发流量到此服务器组上。
当传输的报文协议是HTTP或者HTTPS（HTPPS协议需要配置SSL卸载）时才支持HTTP调度策略。
当服务器组内存在多个可用的实服务器时，FW会通过负载均衡算法选择一个实服务器，然后转发流量到此服务器上。最终的负载均衡效果受负载均衡算法选择的影响，用户需要根据具体的应用场景和业务特点选择合适的算法。
客户端和实服务器之间可能需要多条连接才能完成某一项任务，FW能通过会话保持确保客户端的多条连接都分配给同一个实服务器处理。
如图1所示，FW可以通过健康检查功能不断向各个实服务器发送探测报文，实时监控各服务器的健康状态并做记录。在转发Client 1的流量前，FW会根据各个实服务器的状态，判断其是否可以参与流量分配，只有状态正常的服务器才能参与流量分配，业务故障的服务器将被排除在外。但是FW仍然会向业务故障的服务器发送探测报文，一旦发现服务器业务恢复，将立即让其参与流量分配。这样可确保流量被转发到健康的服务器上，不会造成请求失败的情况。
转发流程
如图2所示，客户端访问虚拟服务器vserver 1时，FW通过负载均衡功能选择实服务器rserver 1来处理业务流量，并转换报文的目的IP地址和端口号。当实服务器的响应报文到达FW时，FW会再次转换报文的源IP地址和端口号。
服务器负载均衡功能利用Server-map表和会话表完成虚拟服务器和实服务器的映射。配置服务器负载均衡功能后，FW会生成SLB类型的静态Server-map表，该表项在关闭服务器负载均衡功能时立即老化。典型的SLB类型静态Server-Map表如下所示，输出信息描述如表1所示：
[sysname] display firewall server-map static Current Total Server-map : 1 Type: SLB, ANY -> 1.1.1.10:8000[grp1/1], Zone:---, protocol:tcp Vpn: public -> public
| 项目 | 描述 |
|---|---|
| Type: SLB | Server-Map表的类型为SLB。 |
| ANY | 源设备地址。FW对访问虚拟服务器的设备没有限制。 |
| 1.1.1.10:8000 | 虚拟服务器的IP地址和端口。 |
| grp1/1 | 虚拟服务器关联的实服务器组的名称和ID。 |
| Zone | 安全区域。SLB类型静态Server-Map表的安全区域信息恒为空。 |
| protocol | 虚拟服务器的协议类型。 |
| Vpn: public -> public | 源设备和虚拟服务器所属的虚拟系统信息。FW不支持跨虚拟系统访问虚拟服务器。 |
当业务流量到达FW时，如果命中SLB类型的静态Server-map表，FW会建立会话表项，该表项在长时间未被匹配的情况下将自动老化。典型的会话表项如下所示：
[sysname] display firewall session table verbose Current total sessions: 1 http VPN: public --> public ID: a7b2679b4a4c03388d54ca6f81126 Zone: untrust --> dmz TTL: 00:00:10 Left: 00:00:03 Interface: GigabitEthernet1/0/2 NextHop: 192.168.0.11 <--packets: 908 bytes: 7548 -->packets: 23 bytes: 306 2.2.2.20:51886 --> 1.1.1.10:8000[192.168.0.1:80] PolicyName: policy_example
服务器负载均衡功能转发报文的流程如图3所示。
转发流程的说明如下：
- 流量报文到达FW后，FW首先会查找是否存在对应的会话表。如果存在，则按照会话表修改报文的目的IP和目的端口号，然后转发给对应的实服务器。如果不存在，则会根据报文的目的IP、目的端口号和协议类型查找Server-map表。
- 对于单通道协议来说，服务器负载均衡功能会生成静态Server-map表项。对于多通道协议来说（仅支持FTP协议），服务器负载均衡功能会利用ASPF生成动态Server-map表项。如果是单通道协议，当客户端的请求报文命中静态Server-map表时，FW首先判断是否可以根据会话保持表或Cookie来选择实服务器。如果可以，选择一个实服务器，并修改请求报文的目的IP和目的端口号为实服务器的IP和端口号。如果不可以，就根据设置好的负载均衡算法选择实服务器，并修改请求报文的目的IP和目的端口号为实服务器的IP和端口号。如果是多通道协议，FW将根据动态Server-map表修改请求报文的目的IP和目的端口号。如果没有命中动态Server-map表，FW会先通过会话保持或负载均衡算法选择实服务器，然后生成动态Server-map表。根据HTTP调度策略选择实服务器组，是可选步骤。仅适用于HTTP和HTTPS（HTTPS配置SSL卸载）协议。
- FW查询域间安全策略，检查是否可以转发报文。然后根据需要修改报文的目的IP和目的端口号，最后查询路由表进行转发。由于修改报文目的IP和目的端口号发生在查询域间安全策略之后，所以安全策略中指定的IP地址应该是虚拟服务器的IP地址。由于修改报文目的IP和目的端口号发生在查询路由之前，所以路由中指定的IP地址应该是实服务器的IP地址。
- FW转发报文前创建会话表项，同一条流的后续报文到达时，将直接根据会话表进行转发。
负载均衡算法
负载均衡算法决定了FW如何分配业务流量到服务器上，选择合适的负载均衡算法才能获得理想的负载均衡效果。
负载均衡算法是服务器负载均衡功能的核心，通过负载均衡算法即可得到由哪台实服务器来处理业务流量。FW支持的负载均衡算法如下：
- 简单轮询算法
- 加权轮询算法
- 最小连接算法
- 加权最小连接算法
- 源IP hash算法
- 加权源IP hash算法
选择负载均衡算法时需要考虑两个主要因素：
- 服务器的性能根据服务器的性能差异来分配业务，可以保证设备得到充分利用，提高服务的稳定性。当各个服务器的性能不同且成一定比例关系时，可通过设置权重来实现负载均衡：性能高的服务器权重值大，分配到较多的业务；性能低的服务器权重值小，分配到较少的业务。
- 服务器的服务类型服务器的服务类型不同，则会话连接的时长或服务请求的次数可能会有差异。如果用户请求的服务需要长时间保持会话连接，那么必须考虑服务器并发处理的连接数。
简单轮询算法
简单轮询算法是将客户端的业务流量依次分配到各个服务器上。如图1所示，FW将客户端的业务流量依次分配给4个服务器，当每个服务器都分配到一条流后，再从服务器S1开始重新依次分配。当业务流量较大时，经过一段时间后，各服务器的累积连接数大致相等。
简单轮询算法的优点是实现简单，效率较高。但是简单轮询算法不会考虑每个服务器上的实际负载：例如新增服务器上的负载量要小于运行一段时间的服务器，而FW仍然依次分配流量给各个服务器，导致新增服务器没有被充分利用。所以，简单轮询算法是一个静态算法，它的适用场景为服务器的性能相近，服务类型比较简单，且每条流对服务器造成的业务负载大致相等。例如，外部用户访问企业内部网络的DNS或RADIUS服务器。
加权轮询算法
加权轮询算法是将客户端的业务流量按照一定权重比依次分配到各个服务器上。如图2所示，服务器S1、S2、S3、S4的权重依次为2、1、1、1，此时服务器S1将被视为两台权重为1的服务器，所以FW连续分配两条流给S1，然后再分配接下来的三条流给服务器S2、S3、S4。当业务流量比较大时，经过一段时间后，各服务器的累积连接数比例约为2：1：1：1。
加权轮询算法的适用场景为服务器的性能不同，服务类型比较简单，且每条流对服务器造成的业务负载大致相等。例如，外部用户访问企业内部网络的DNS或RADIUS服务器，各服务器的性能存在差异。
最小连接算法
最小连接算法是将客户端的业务流量分配到并发连接数最小的服务器上。并发连接数即服务器对应的实时连接数，会话新建或老化都会影响并发连接数的大小。如图3所示，客户端发出的请求到达FW后，FW会统计4个服务器上的并发连接数。因为服务器S1上的并发连接数最小，所以连续几条流都被分配给服务器S1。
最小连接算法解决了轮询算法存在的问题，即轮询算法在分配业务流量时并不考虑每个服务器上的实际负载量，而最小连接算法会统计各个服务器上的并发连接数，保证业务流量分配到负载最小的服务器上。所以，最小连接算法是动态算法，它的适用场景为服务器的性能相近，每条流对服务器造成的业务负载大致相等，但是每条流的会话存活时间不同。例如，外部用户访问企业内部网络的HTTP服务器。
加权最小连接算法
加权最小连接算法是将客户端的业务流量分配到加权并发连接数最小的服务器上。并发连接数即服务器对应的实时连接数，会话新建或老化都会影响并发连接数的大小，而加权并发连接数是考虑服务器权重后得到的实时连接数。如图4所示，服务器S1、S2、S3、S4的权重依次为2、1、1、1，此时服务器S1需要将并发连接数除以2，然后和其他权重为1的服务器进行比较。因为服务器S1的加权并发连接数最小（等于75），所以FW将接下来的几条流都分配给服务器S1。当业务流量比较大时，经过一段时间后，各服务器的并发连接数比例约为2：1：1：1。
加权最小连接算法的适用场景为服务器的性能不同，每一条流对服务器造成的业务负载大致相等，但是每一条流的会话存活时间不同。例如，外部用户访问企业内部网络的HTTP服务器，各服务器的性能存在差异。
源IP Hash算法
源IP Hash算法是将客户端的IP地址进行Hash运算，得到Hash Index值。FW根据Hash Index值与Hash列表中服务器的对应关系，分配流量至服务器。
源IP Hash算法的应用场景为当各个服务器性能差别不大，FW使用源IP Hash算法进行负载分担时，依然可以将源IP相同的客户端负载分担到同一个服务器。
图5 源IP Hash算法
加权源IP Hash算法
加权源IP Hash算法是将客户端的IP地址进行Hash运算，得到Hash Index值，而后通过FW调整各个服务器的权重得到Hash表中服务器新的权重值。如果服务器S1、S2、S3、S4的权重依次为2、1、1、1，则Hash表中S1、S2、S3、S4权重为2、1、1、1，最后根据Hash Index值与Hash列表中服务器的对应关系，分配流量至服务器。
源IP Hash算法的应用场景为各个服务器的性能有一定的差异，FW使用加权源IP Hash算法进行负载分担时，依然可以将源IP相同的客户端负载分担到同一个服务器。
图6 加权源IP Hssh算法
会话保持
会话保持是将同一客户端一定时间内的业务流量分配到同一台实服务器上。
会话保持的适用场景主要有两个：第一个场景是客户端需要与服务器进行多次交互，才能完成一次特定操作；第二个场景是服务器上保存了用户的相关业务信息，为了方便用户本次或下次使用，可以令此服务器处理该用户的所有请求。
在这两个场景中需要保证同一客户端的业务流量都被分配到同一个服务器上，如果交互过程中更换了处理业务的服务器，则客户端无法成功完成特定操作，需要重新进行请求。例如，用户在购物网站上将电子商品放入购物车，如果需要网站保存购物车中的信息，则用户需要登录该网站。登录过程中，由某一个服务器对用户进行安全认证，然后该服务器保存用户的认证信息和购物信息。当用户选择了类似“下次自动登录账户”的功能时，该用户下次登录时将直接利用服务器上保存的认证信息，无需再进行多次交互认证。另一个例子是校园网的在线培训或考试系统，当用户开始进行在线操作时，需要保证此过程的连续性，所以由固定的服务器来处理该用户的所有请求。
FW支持的会话保持方法有：源IP会话保持、SSL会话ID（Session ID）会话保持、HTTP Cookie会话保持。其中HTTP Cookie会话保持方法又可以分为：Cookie插入、Cookie被动、Cookie重写。会话保持算法与虚拟服务协议的匹配情况如下：
| 虚拟服务协议配置 | any | http | https | ssl | tcp | udp | esp | |
|---|---|---|---|---|---|---|---|---|
| 实服务器组会话保持方法配置 | source-ip | √ | √ | √ | √ | √ | √ | √ |
| session-id | × | × | × | √ | × | × | × | |
| cookie | × | √ | √ | × | × | × | × | |
| √：不冲突×：冲突 | ||||||||
配置会话保持时，如果会话保持表项老化时间到期或者实服务器故障，会话保持表项会被删除。客户端再次访问服务器时，FW将重新根据负载均衡算法分发连接并重新建立会话保持表项。
源IP会话保持
基于源IP的会话保持，是指FW根据访问请求的源地址作进行负载均衡，对来自同一IP地址的所有访问请求进行负载均衡时都会被保持到一台服务器上去。
如图1所示，客户端访问服务器时，FW根据负载均衡算法分发首条连接到实服务器S2，同时在源IP会话保持表中记录客户端源地址值和实服务器的对应关系。FW收到客户端的后续连接时，根据客户端源地址值在会话保持表中查找到对应的实服务器为S2。于是，FW将客户端后续连接也分发到S2上。同时，FW将会话保持表中表项的老化时间恢复为初始值。
如果会话保持表项老化时间到期或者实服务器故障，会话保持表项会被删除。客户端再次访问服务器时，FW将重新根据负载均衡算法分发连接并重新建立会话保持表项。
HTTP Cookie会话保持
基于HTTP Cookie会话保持，是指FW根据会话中的Cookie进行负载均衡，对携带同一Cookie的所有访问请求进行负载均衡时都会被保持到一台服务器上去。HTTP Cookie会话保持有三种方式：Cookie插入、Cookie被动、Cookie重写。选择Cookie被动、Cookie重写算法时，服务器端需要将Cookie字段做对应的配置，选择Cookie插入算法时，服务器端无需配置。不同型号服务器上的配置不同，如在Apache服务器上时，选择Cookie重写算法，在httpd.conf文件中加入以下条目： Header add Set-Cookie:”SLBServerpool=0000000; expires=Sat, 19-Aug-201619:35:45 GMT; path=/”；选择Cookie被动算法，在httpd.conf文件中加入以下条目：Header add Set-Cookie:”SLBServerpool=base64(IP:PORT); expires=Sat, 19-Aug-201619:35:45 GMT; path=/”。
Cookie插入方式如图2所示，FW解析客户端的HTTP请求，检查是否携带自己插入的Cookie。如果未携带，则根据负载均衡算法分发HTTP请求，并在服务器响应的报文中插入FW自己的Cookie。插入的Cookie中会包含分发的实服务器的IP地址。FW再次收到客户端的HTTP请求时，就能从报文携带的Cookie中获取到上一次请求所分发的实服务器IP地址，将本次的请求也分发到同一个实服务器。
Cookie被动方式如图3所示，FW解析客户端的HTTP请求，检查是否携带自己插入的Cookie。如果未携带，则根据负载均衡算法分发HTTP请求。实服务器回复请求报文并插入服务器自己的Cookie。插入的Cookie中会包含分发的实服务器的IP地址。FW再次收到客户端的HTTP请求时，就能从报文携带的Cookie中获取到上一次请求所分发的实服务器IP地址，将本次的请求也分发到同一个实服务器。
Cookie重写方式如图4所示，FW解析客户端的HTTP请求，检查是否携带自己插入的Cookie。如果未携带，则根据负载均衡算法分发HTTP请求。服务器回复请求报文并插入空白Cookie。FW接受到服务器回复的报文时，重写插入的Cookie中会包含分发的实服务器的IP地址。FW再次收到客户端的HTTP请求时，就能从报文携带的Cookie中获取到上一次请求所分发的实服务器IP地址，将本次的请求也分发到同一个实服务器。
SSL Session ID会话保持
基于SSL Session ID的会话保持，是指FW根据会话中的Session ID进行负载均衡，对携带同一Session ID的所有访问请求进行负载均衡时都会被保持到一台服务器上去。
如图5所示，FW解析客户端发来的SSL报文，识别出是Client Hello报文后，检查Client Hello报文是否携带Session ID。如果未携带，则根据负载均衡算法选择一个实服务器分发连接。实服务器发现客户端的Client Hello报文中未携带Session ID，会给本次会话生成一个Session ID，并通过Server Hello报文发送给客户端。FW收到实服务器响应的Server Hello报文后，解析报文获取Session ID，新建Session ID会话保持表项，记录Session ID和实服务器的对应关系。客户端再次和服务器建立连接时，Client Hello报文中会携带上一次连接所用到的Session ID。FW收到Client Hello报文后，解析出报文所携带的Session ID，根据Session ID在会话保持表中查找到该Session ID对应的实服务器，将报文分发到该实服务器。同时，FW将会话保持表中表项的老化时间恢复为初始值。
服务健康检查
健康检查功能可以检测服务器业务是否可用，防止流量被分配到不能正常工作的服务器上，进而导致服务中断。
为了应对日益增加的用户访问量和数据量，企业通过服务器负载均衡技术来解决单一服务器性能不足的问题。服务器负载均衡虽然可以提升服务的质量和可靠性，但是也引入了一系列问题：
- 多个服务器中的一个服务器发生故障时，FW如何感知到这个变化，并作出流量分配上的调整？
- FW收到信息显示服务器故障时，如何确保消息的可信性，即是否有一定的机制保证不会发生误判？
- 当发生故障的服务器恢复正常时，FW如何让其尽快地重新参与到负载均衡计算中？
为了解决上述问题，FW提供了服务健康检查功能。服务健康检查功能可以检测服务器的工作状态，当某个服务器发生故障时，FW会立即修改此服务器的状态。负载均衡算法感知到服务器状态的变化后，可以保证用户请求不会被发送到故障服务器上。
FW通过向服务器定期发送探测报文来及时了解服务器的状态，根据服务类型的不同，使用不同协议类型的探测报文。FW支持的探测报文协议类型包括TCP、ICMP、HTTP、DNS和RADIUS，如果服务器提供的服务类型不包含在这5种协议中，建议使用ICMP协议报文检查服务器的可达性。
每个探测报文都会返回一个检查结果，显示服务器是否处在正常的工作状态，FW提供了结果确认机制来保证不会发生误判。如果有一个检查结果显示服务器故障，则FW在继续发送探测报文的同时，开始统计连续故障的次数。当连续次数达到预设值时，FW才认定此服务器真的发生了故障。检查结果反馈给负载均衡算法后，改变了负载均衡的结果，该服务器不再参与流量分配。
管理员可以选择是否继续对故障服务器进行健康检查，如果指定故障服务器为非激活状态，则FW不会再向服务器发送探测报文，否则FW会继续向故障服务器发送探测报文。
下面以图1所示组网为例进行说明。FW的负载均衡算法为简单轮询算法，客户端的流量被依次分配到各个服务器上。FW向4个服务器定期发送探测报文，监控各个服务器的健康状况。
如图2所示，当服务器S2发生故障时，FW会立即停止向其分配流量，而只分配给其他健康的服务器。但是FW仍然会向服务器S2发送探测报文，监控其健康状况。
如图3所示，当服务器S2恢复正常状态时，FW将立即修改其健康状态，这样S2就会重新参与到流量分配中。
Web举例：配置FTP服务器的负载均衡
本举例以FTP服务器为例，介绍如何配置四层负载均衡。其他IP服务器，如DNS、SMTP、RADIUS等均可参考本举例的配置。
组网需求
如图1所示，企业有三台FTP服务器Server1、Server2和Server3，且这三台服务器的硬件性能顺次降低，Server1性能是Server2的两倍、Server2性能是Server3的两倍。通过配置负载均衡，让这三台服务器联合对外提供FTP服务，且三台服务器承载业务的多少与服务器硬件性能的高低匹配。通过配置健康检测实时监控这三台服务器是否可达。
配置思路
- 三台服务器的性能不同，要根据性能来负载均衡，所以负载均衡算法可以选择“加权最小连接算法”。Server1性能是Server2的两倍、Server2性能是Server3的两倍，所以三台服务器的权值比为4:2:1。
- 为了监控三台服务器是否可达，需要在FW上配置健康检查。本举例中健康检查的协议类型配置为ICMP，您也可以配置为TCP。FW要发送健康检查报文，需要配置local到服务器所在安全区域（dmz）的安全策略。
- 客户端可能需要与服务器建立多条连接才能完成一项操作，为此需要在FW上配置会话保持，让同一个客户端的连接分配到同一台服务器上。服务器提供的是FTP服务，所以会话保持方法只能配置成源IP会话保持。
- 服务器的协议为多通道协议FTP，所以要启用FTP协议的ASPF功能。非多通道协议不需要配置ASPF。
操作步骤
- 选择“网络 > 接口”，配置接口IP地址和安全区域。接口名称GigabitEthernet 1/0/1GigabitEthernet 1/0/2安全区域untrustDMZIP地址1.1.1.1/24192.168.1.254/24
- 选择“策略 > 安全策略 > 安全策略”，配置安全策略。配置untrust到dmz的安全策略，允许Internet用户访问内网的Web服务器。策略的目的地址应该配置虚拟服务器的IP地址。源安全区域untrust目的安全区域dmz目的地址/地区1.1.1.10/24配置local到dmz的安全策略，允许FW向实服务器发送健康探测报文。源安全区域local目的安全区域dmz目的地址/地区192.168.1.1–192.168.1.3
- 选择“策略 > 服务器负载均衡 > 会话保持”，配置会话保持。
- 选择“策略 > 服务器负载均衡 > 实服务器组”，配置实服务器组。
- 选择“策略 > 服务器负载均衡 > 虚拟服务”，配置虚拟服务。
- 选择“策略 > ASPF配置”，启用FTP协议的ASPF功能。
结果验证
- 在Client上ftp 1.1.1.10:2121可以连接到FTP服务器。
- 服务器负载均衡运行一段时间后，在“实服务器组列表”中，查看到三台服务器的流量、会话数比例约为4:2:1。
配置脚本
# interface GigabitEthernet 1/0/1 ip address 1.1.1.1 24 # interface GigabitEthernet 1/0/2 ip address 192.168.1.254 24 # firewall zone untrust add interface GigabitEthernet 1/0/1 # firewall zone dmz add interface GigabitEthernet 1/0/2 # security-policy rule name policy1 source-zone untrust destination-zone dmz destination-address 1.1.1.10 24 action permit rule name policy2 source-zone local destination-zone dmz destination-address range 192.168.1.1 192.168.1.3 action permit # slb enable # slb group 0 Rserver metric weight-least-connection health-check type icmp tx-interval 5 times 3 rserver 0 rip 192.168.1.1 port 21 weight 4 description server1 rserver 1 rip 192.168.1.2 port 21 weight 2 description server2 rserver 2 rip 192.168.1.3 port 21 weight 1 description server3 persistence 0 Session type source-ip aging-time 180 vserver 0 vs-ftp-1.1.1.10 vip 0 1.1.1.10 protocol tcp vport 2121 persistence Session group Rserver # firewall detect ftp