F5负载均衡器维护手册簿

1、实用标准文档F5 负载均衡器维护手册文案大全目录F5 负载均衡器维护手册 1一、基本原理 511负载均衡器的基本原理 512负载均衡器几要素 513F5 BIG-IP LTM 基本元素 71 . 4 BIG-IP LTM 的 TMM 91 5BIG-IP LTM 的负载均衡算法 1.0.1 . 6BIG-IP LTM 会话保持 1.2.1 .6. 1 会话保持的需求： 1.2.1 .6. 2 源地址会话保持： 1.3.1 .6 .3哈希会话保持 1.4.1 .6.4Cookie 会话保持 1.4.1 . 7 健康检查 1.6.1 .7.1基于 ICMP 的健康检查 1.6.1 .7.2基于 T

2、CP 端口的健康检查 1.71 .7 .3基于应用协议的健康检查 1.8二、F5 BIG-IP LTM 日常维护202. 1 F5 BIG-IP LTM 外观 2.0.22 F5 BIG-IP LTM 配置备份和恢复 2.123 F5 BIG-IP LTM 性能状态 2.2.231 F5 BIG-IP LTM 实时连接状态 2.2232 F5 BIG-IP LTM 性能状态 2.5233 F5 BIG-IP LTM 告警日志 2.7.三、F5 BIG-IP LTM 服务配置 2831 F5 BIG-IP LTM 创建用户 2.8.32 F5 BIG-IP LTM 开启本地服务 2.93 3 手

3、动切换主备状态 3.0.3 4 修改 admin 和 root 密码 3.0.3 5 健康检查的管理和维护 3.1.3 6 pool 的管理和维护 3.3.37 VS 的管理和维护 3.5.3 8 iRules 管理和维护 3.7.3 9 rofile 管理和维护 4.0.四、F5 BIG-IP LTM 故障处理 4.1.4 1 应用服务故障 4.1.42 F5 BIG-IP LTM 硬件故障 4.3.、基本原理1.1负载均衡器的基本原理应用负载均衡器对外提供一个虚拟的应用服务器，接收所有的客户端请求应用负载均衡器通过负载均衡算法处理，将客户端请求转发到后台的多个应用实例应用负载均衡器通过应用

4、健康检查，准确的判断应用程序的工作和服务状态，一旦发现应用不能提供服务，则将其从负载均衡组中摘除DomainVrtLal Server接收客户增At求 自戟均窗处理ApplicationApplicationServer 1Server 21 . 2负载均衡器几要素负载分配策略：如何对用户的流量进行分配，使后台服务器的处负载分配策略是应用负载均衡的整个核心, 理更加合理。 达到均衡负载， 保证用户的最佳体验的目的， 和负载分配策略具有密不可分的 关系。健康检查策略：在一个良好设计的系统中， 负载均衡器往往处于一个系统的核心位置， 很多用户使用四层负 载均衡的一个主要原因就是要实现应用的高可用性

5、而非性能问题。 如何让负载均衡器能智能 的检查到服务器真实的健康状态，在系统的设计中起到至关重要的作用。会话保持策略： 就目前而言，只有很少的应用系统是专为多服务器并行处理而设计，用户的登录信息，Session ID 等还是在单台服务器上存放，并没有同步到其他的服务器上，因此，会话保持 策略的丰富性也是四层负载均衡一个巨大的挑战。冗余切换策略： 在保证了后台设备的高可用性之后， 出于系统核心位置的负载均衡器自身的高可用性就变得 尤其重要， 并且由于应用访问的不透明性， 造成在紧急情况下很难对所有的应用进行迁移工 作。这时负载均衡器的冗余切换策略和手段将关系到整个系统的高可用性。网络结构的灵活性

6、： 对于一个横跨网络和应用的设备来说， 对于网络结构和应用结构的完整支持特性变得尤其重 要，网络层的基本技术如 VLAN 、Trunk 、 Spanning 、Tree 、IPV4/V6 、静态路由、 OSPF 等都将成为负载均衡器的基本配置。 而另外对于应用中的各种特殊协议的支持， 也决定了负 载均衡器部署的围和使用。1 . 3 F5 BIG-IP LTM 基本元素在BIG-IP LTM中，针对应用负载均衡的应用特色和系统需求，将整个流量的处理过程按照以下方式进行定义:lP：PortIP;PortlP:PortlP:PortiRulesVS的定义包含了 IP和端口和VS: Virtual S

7、erver是进入BIG-IP LTM处理流量的入口。VLAN，其中，IP可以是一个IP，也可以是用掩码掩出来的一段 IP,端口可以是一个固定 的端口，比如80,也可以是0端口，0端口的意思就是侦听所有的端口。 VS的定义的含义 就是对于发送到 BIG-IP LTM上的流量，只有同时命中 VS的IP和端口的流量才进行处理。Profile :当流量进入BIG-IP LTM之后，怎样去处理和识别进入VS的流量，就需要由Profile来定义了。Profile 分了几种类型，有协议层的Profile比如TCP profile, UDP profile 。有应用层的 Profile 比如 HTTP pro

8、file , FTP Profile。还有 SSL Profile、会话保持相关的 Profile、 认证的Profile和其他一些 Profile类型。所有的Profile都需要关联在 VS上才能生效。有 些Profile之间是互斥的关系，比如TCP和UDP, HTTP和FTP,VS 上关联了 TCP profile ， 就不能再关联 UDP Profile 了。因为一旦关联了某个 Profile，VS就会按照这个 Profile的定义方式去处理流量。所以有些 Profile 也是相互依存的，比如要关联 HTTP Profile ，就必 须先关联 TCP Profile 。Pool ： Po

9、ol 在 LTM 的部是一个逻辑概念，是指的一组相同服务的资源的组合。Pool 的作用很简单，就是根据自身定义的分发规则，对 VS 接收进来，并且被 Profile 处理之后的流 量进行分发，分发到 Pool 的 member 去。Member : 一个应用服务，通常情况下，一个Member 就是后台服务器的一个侦听进程，是由 IP:port 格式组成。Node : Node 通常用来表示后台的一个服务IP 地址，一个 Node 上面可以有一个或多个Member 。 Node 不需要进行配置，在配置了Member 之后自动产生，系统会根据每一个不同的 Member IP 地址生成一个 Node

10、 地址iRules ：iRules 相当于在整个数据包通路上进行一个监控和处理。 VS -Pool-SNAT 的这一 条路上， iRules 可以通过事件驱动方式，在通路上的任何一个位置上对数据包进行判断和 处理。 比如 Client_Accepted 事件就是当请求命中 VS 的时候被激活， pool webpool 这条 指令用于指示BIG-IP LTM 将流量分配到那个 Pool里面去。而iRules的事件是否能触发或 者 iRules 能获取和处理那些信息， 则都是由关联的 Profile 来决定的。比如 VS 只关联了 TCP Profile ，而没关联 HTTP Profile 。

11、那即使通过 VS 的流量都是 HTTP 请求， iRules 也无法 去获取 URI 、header 等信息。 只有关联了 HTTP Profile 之后， iRules 才能触发 HTTP 相关 事件和按照 HTTP 协议的相关规对请求容进行识别和判断。1 . 4 BIG-IP LTM 的 TMMTMM就是一个应用程序。TMM 一旦启动，就会抢占系统的大部分存(存分配可以在系 统Provision的时候进行分配)，接管所有的业务端口流量、SSL加解密芯片和HTTP硬件 压缩芯片等资源，然后根据自己的需求进行使用。只要从BIG-IP LTM前面板的业务端口进入的流量，都会先经过 TMM的处理。

12、当BIG-IP LTM 只有单核CPU时，主要的CPU资源都优先分配给 TMM进程。在这种 结构下，所有的流量处理都在 TMM里直接处理，则可以到很高的性能，除了负载均衡以外， 在 BIG-IP LTM LTM 上的 SSL、RamCache、Compress、SSL VPN、WOM 等功能都是在TMM 部处理的。而一些比较大型的工作模块如GTM(Global Traffic Manager) 、WA (WebAccelerator )、ASM(Application Security Manager)和认证等一些功能则是通过其他的进程进行处理，这些进程通过部的Plugin结构和TMM 进行通

13、讯。数据传输Campress SSL Offload脱务器服务器.眼务器多核CPU平台：当系统中有多个 CPU核存在时，BIG-IP LTM 将进入CMP(Cluster MutiProcessor)的工作模式，所谓CMP，就是在BIG-IP LTM LTM 的部，使用硬件芯片 HSB( HighSpeed Bridge )对进入生产端口的流量在部进行了一次负载均衡，使流量均匀的分布到每 个TMM核心上去。而每个 TMM核心占据一个CPU核1. 5 BIG-IP LTM 的负载均衡算法轮询算法(Round Robin ):BIG-IP LTM顺序循环将请求一次顺序循环地连接每个服务器。当其中某

14、个服务器发生第2到第7层的故障，则将其从顺序循环队列中拿出，不参加下一次的轮询， 直到其恢复正常。比率算法(Ratio ):在BIG-IP LTM 上给每个服务器分配一个加权值为比例，根据这个比例，BIG-IP LTM 把用户的请求分配到每个服务器。当其中某个服务器发生第2到第7层的故障，就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。最少连接数(Least Connections):在BIG-IP LTM上对每一台服务器的当前连接数进行统计，当有新的请求进入时，将新的请 求分配给当前最少连接处理的服务器。 当其中某个服务器发生第 2 到第 7 层的故障， BIG-IP

15、 LTM 就把其从服务器队列中拿出，不参加下一次的用户请求的分配 , 直到其恢复正常。最快响应速度( Fastest )：在 BIG-IP LTM 上通过观察每台服务器得应用响应速度，当有新的请求进入的时候，将新的 请求分配给响应最快的服务器。当其中某个服务器发生第 2 到第 7 层的故障， BIG-IP LTM 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。观察模式( Observed )： 连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。 当其中某个服务器 发生第二到第 7 层的故障， BIG/IP 就把其从服务器队列中拿出， 不参加下一次的用户请

16、求 的分配，直到其恢复正常。性能预测分配： ( Predictive ) 由负载均衡设备收集到的应用程序和应用服务器的各项性能参数如 CPU 占用率，存占用率、 当前并发用户数等关键信息， 并可进行加权处理。 当有新的请求进入的时候， 将新的请求分 配给综合性能最佳的服务器。当其中某个服务器发生第 2 到第 7 层的故障， BIG-IP LTM 就 把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。1. 6 BIG-IP LTM 会话保持1 . 6 . 1 会话保持的需求：以最典型的HTTP应用为例，在大多数电子商务的应用系统或者需要进行用户身份认证 的在线系统中，一个客户

17、与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个 请求的完成。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果，服务器进行下一步操作时需要这就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上。产生 SesjionlD再产生SessionlD 后.股务髀则通 过Session ID的值 来区别每一个用 户端一个典型的HTTP请求流程如下:HTTP Request: GET /index.jspHTTF RE5PQNSE; index jsp保存 Sessionl

18、D宮户崭在每次发 .起对服务器的请 求的时候，都在 请求中疑送包含 弘ssienlD倍息的 Cookiecookie：nid:234234234HTTP Request: GET /infb.jsp 匚gk叫sessionid:234234234HTTP RESPONSE: infojsp JSsiDnid:234234234HTTP Request; GET /detail.JspCookie： Jse5sionid;234234234客户崭浏览器客户端发起一个连接到服务器的服务端口，并在此连接中发送HTTP请求服务器在接收到用户请求后，在本地产生一个部Sessio nID用于唯一标识该用户

19、服务器将返回容进行组织后，同时将Session ID 通过Cookie返回给用户用户在收到回应后，将Cookie保存在存中。用户下一次点击重新发起一个连接到服务器的服务端口用户在新建连接中发送 HTTP请求，并带上Cookie进行发送。服务器在收到请求后，从Cookie中获得该用户的 Session ID,根据此Session ID进行相关处理1 . 6. 2 源地址会话保持:源地址会话保持的一个基本概念就是将一个源地址认为是一个用户，凡是同一个源地发送过来的连接，则认为是同一个用户发起的多个请求，根据会话保持策略，将这些连接/请求都转发到同一台服务器。当一个新的连接请求发送到虚拟服务后，首先

20、查找源地址会话保持表，如果在源地址会话保持表中查询到了该请求发起的源地址对应的服务器，则直接将该请求转发到相应的服务器上，如果在源地址会话保持表中没有查询到相应的条目，则按照负载均衡算法将请求转发到相应的服务器，同时，将该请求发起的源地址和对应的服务器地址添加到源地址会话保持 表中。这样，下次同一 IP地址再发起新建连接到该虚拟服务时，则在源地址会话保持表中 已经存在相应的条目，新的连接则会根据源地址会话保持表的对应项转发到对应的服务器上。源地址会话保持同时还存在有一个超时时间参数。每次有有新建连接请求或已建立的连接中有数据在传输时，就会刷新会话保持表中的超时时间。比如设置源IP会话保持的超时

21、时间为300秒，则对于同一个源IP，只要有新建连接或已建连接有数据传输，则在源地址 会话保持表中的超时时间一直刷新为0。当没有新建连接或者数据传输时，该值就开始按秒 进行累加，一旦超出 300 秒没有新建连接请求或没有数据传输。则将其条目从源地址会话 保持表中清除。如果该 IP 地址在在过了超时时间之后又有新的连接请求，则以第一次连接 请求按照负载均衡的算法进行处理，此时，源地址会话保持表中的超时时间又从 0 开始计 算。16 3 哈希会话保持哈希会话保持的一个基本概念就是将一个连接中的源 IP 和目的 IP 地址进行 Hash 计算， 根据计算得到的结果并根据后台存在多少台服务器来选择将请求

22、分配到那台服务器。哈希会话保持的特点是在后台服务器的健康状态不发生改变的时候，每个特定的源 IP 地址被分配到的服务器是固定的。 并且， 哈希会话保持可以没有会话保持表， 而仅仅是根据 计算的结果来确定一个源 IP 被分配到那台服务器。哈希会话保持通常被用于一些特定场合， 如要求客户端按照 IP 地址被固定分配的场合， 或者在一些会话保持表查询的开销已经远远大于 Hash 计算开销的情况下，采用 hash 会话 保持可以提高系统的处理能力和响应速度。在实际的应用场景中，针对后台采用 Cache 服务器的情况，还有对 URL 进行 Hash 的 处理方式，将同一个 URL 的请求分配到同一台 C

23、ache 服务器，这样，对后台的 Cache 服 务器群组来说，每台Cache服务器上存放的容都是不一样的，提高Cache服务器的利用率。16 4 Cookie 会话保持 .Cookie 是在浏览器访问 WEB 服务器的某个资源时， 由 WEB 服务器在 HTTP 响应消息头中附带传送给浏览器的一片数据，WEB服务器传送给各个客户端浏览器的数据是可以各不相同的。浏览器可以决定是否保存这片数据，一旦WEB浏览器保存了这片数据，那么它在以后每次访问该 WEB服务器时，都应在HTTP请求头中将这片数据回传给 WEB服务器。 显然，Cookie最先是由 WEB服务器发出的，是否发送Cookie和发送的

24、Cookie的具体容, 完全是由WEB服务器决定的。例如，用一个Cookie来标识访问者的，有效时间等。Cookie In sert会话保持模式因为Cookie被如此广泛的使用，特别是 Session Cookie技术，基本上在所有的电子商务中都在使用这种技术。因此，在BIG-IP LTM中可以通过插入自己可识别的Cookie来实现会话保持。富户蒔诂求+贵有3也在黒务器响应中補入特定C站洛客户漏iS轧包谕壬饷在服务器响应巾亶新持定UMkid客户端百女工盲5-為Bl抿据UookiE内容廿配负载均衙转发不包含CmS的请車股劳器响商.iCwkie服务器当客户进行第一次请求时，客户HTTP请求（不带c

25、ookie ）进入BIG-IP LTM，BIG-IPLTM根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复（不带 cookie ）被发回BIG-IP LTM，然后BIG-IP LTM插入cookie，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIG-IP LTM插入的cookie ）进入BIG-IP LTM，然后BIG-IP LTM 读出cookie里的会话保持数值，将HTTP 请求（带有与上面同样的 cookie ）发到指定的服务器，然后后端服务器进行请求回 复，由于服务器并不写入 cookie ， HTTP 响应将

26、不带有 cookie ，服务器响应再次经过进入 BIG-IP LTM 时， BIG-IP LTM 再次写入更新后的会话保持 cookie 。1 7 健康检查健康检查是负载均衡处理中一个非常重要的环节。 负载均衡的主要作用就是将客户端的 请求分配到多台服务器上， 如果没有健康检查， 在后台服务器发生故障的时候， 部分的客户 端将会被分配到故障的服务器上， 从而导致用户的访问失败。 在一些情况下， 甚至可能出现 服务器本身还在工作， 但其上运行的应用系统已经故障导致无法处理请求， 都将会导致用户 的请求失败。在 BIG-IP LTM 上应当能检查到这些故障，并在进行负载均衡的时候将这些故 障的服务

27、器进行自动摘除，保证应用的持续性和高可用性。17 1 基于 ICMP 的健康检查基于 ICMP 的健康检查属于最基本的健康检查方式， BIG-IP LTM 主动给服务器发送一 个 ICMP（ 互联网控制信息协议 ） 数据包，如果 BIG-IP LTM 收到了服务器的正确响应，则说 明检查成功。ICMP 健康检查通常用于网关类型设备的健康检查，如防火墙、路由器等。这些设备通 常不提供其他的健康检查手段， 因此 ICMP 属于最佳的检查方式。 另外， 在一些无法使用高 级健康检查手段的情况下，也只能使用 ICMP 健康检查手段。BIG-IP LTMIOV1卩健康检査方式简 单的使用国期去探测 服务

28、器的状态.只要 服务器回应I匚MP请求. 则认为服务器在正常 工作1 . 7 . 2 基于TCP端口的健康检查在基于TCP协议的应用中，每个应用系统都会绑定一个TCP端口，应用通过侦听这个端口接受客户端的请求。比如我们常见的80端口在默认情况下就是服务于HTTP服务，通常为 IIS、Apache 等应用系统使用，另外还有 FTP（ 20、21 ）、HTTPS（443 ）、SMTP（ 25 ）、 POP3（ 110 ）等。判断这些应用系统是否在工作最简单的方法就是从BIG-IP LTM和对应的服务器端口做一次完整的TCP握手，如果TCP握手成功，则认为服务器正常工作，如果握手失败，在超过一定的检

29、查次数均握手失败的情况下，BIG-IP LTM则将失败的服务器标记为Down，而将新的客户端请求都发送到其他仍然正常工作的服务器上。在TCP健康检查中还可能出现的一种情况就是在频繁检查的情况下，健康检查的流量可能导致一些比较“脆弱”的应用系统产生故障。通常有两种情况会出现这种故障情况：1. 服务器的Socket侦听程序不完善，对于 TCP健康检查没有正确关闭连接2. 服务器对每个试图连接都进行log，最后整个应用系统的Log都被健康检查的连接所充满。而导致磁盘空间溢出或者正常的log信息无法察看。在这种情况下，有两种解决方式：1. 采用TCP half open 的方式进行健康检查，所谓TCP

30、 half open 就是BIG-IP LTM 向服务器发送一个 Syn 数据包， 一旦受到来自该服务的 Syn-ACK 数据包， 则认为该服务正常工 作，然后立即发送一个 RESET数据包到服务。在一些情况下，这种TCP半连接模式并不会被记录下来。2. 采用基于代理的健康检查，即在服务器上另外编写一个进程，专门用于健康检查使用， 专用的健康检查进程将会负责 BIG-IP LTM 的健康查询，而保护主进程的不受干扰的运行。17 3 基于应用协议的健康检查由于在 ICMP 、 TCP 端口和 UDP 端口的健康检查中，我们都不一定能确认服务器的真 实工作状态。在实际中经常有可能出现这样的情况：服

31、务器 IP 地址还可以 ping ，但是应用服务已经 crash 了应用服务还在监听 80 端口，但是已经不接收任何请求了 应用服务仍然接收请求，但是每次都返回 503 服务器部错误这种服务已经不正常， 但是端口仍在监听的情况， 在一些非关键业务上还可以容忍， 但 在一些关键业务的应用中就不可接受了。以 HTTP 协议为例，基于 HTTP 协议的健康检查过程如下：BIG-IP LTM 发起一个 HTTP 请求到服务器，请求特定的资源服务器进行回应BIG-IP LTM 在返回的容中查找一个关键字， 如果存在该关键字， 则认为 Web 服务器正 常工作中。HTTP 协议层的健康检查通常用于应用服务

32、器的健康检查，如 WebLogic 、 WebSphare 、Tomcat 等。和 IIS 、Apache 服务相比，这些应用服务器出现故障的几率通常较大。而且最 容易出现端口仍然在侦听，但应用已经不工作的情况。典型的基于应用协议的健康检查通常还有：FTP:由BIG-IP LTM向FTP服务器发起FTP请求，在验证用户名和密码后，下载一个文件（通常不会保存这个文件） ，如果文件下载成功，则认为服务器工作正常。这样整个 FTP 服 务器的用户认证、磁盘存储连接等服务都进行了检查。DNS: 由 BIG-IP LTM 向 DNS 服务器发起一个 DNS 请求， 请求特定的域名， 并检查返回的 结果，

33、如果正确，则认为服务器工作正常。HTTPS: 由 BIG-IP LTM 向 HTTPS 发起一个 HTTPS 请求，通常，在 HTTPS 的健康检查中 可能还需要配置客户端证书等，在服务器响应返回后，在返回的数据中查找特定的字符串， 如果匹配成功，则认为 HTTPS 服务器工作正常。POP3 :由BIG-IP LTM向POP3服务器发起一个请求，并进行用户名和密码验证。如果登 陆成功，则认为 POP3 服务器工作正常。SMTP :由 BIG-IP LTM 向 SMTP 服务器发送一个标准的 SMTP 请求， 如果服务器按照标准SMTP 响应返回 HELO 或 QUIT ，则认为 SMTP 服务

34、工作正常。 通常情况下， SMTP 健康检 查在发送请求的时候还需要指定域名。数据库：由BIG-IP LTM向数据库服务器发起一次数据库查询请求，然后判断数据库服务器返回的结果中是否包含特定的字符串，如果匹配成功，则认为数据库服务器工作正常。、F5 BIG-IP LTM 日常维护2. 1 F5 BIG-IP LTM 外观F5在设备前面板上划分明显不同的三个区域，最左侧设计有failover和con sole接口；中部为各种网络接口；最右侧为液晶屏幕、状态显示灯、6个控制按钮及 F5的红色logo灯泡。面板前部设计有冷风入口。电源设计在设备的尾部以方便机架上电源线接入，设备产生的热量从尾部的热风

35、出口散出。1.管理口 2.USB 接口 3.Console 口 4.Failover 口 5.10/100/1000自适应接口 6.SFP 接口7.指示灯8.液晶屏9.液晶屏控制按钮1:/*#1. 电源模块一 2电源模块二 3.散热风扇通过LCD按键修改管理网口 IP地址的方法如下：1. 按红色X按键进入Options 选项；2. 在液晶面板上通过按键按以下顺序设置管理网口的网络地址:Optio ns-System-IP Address/Netmask-Commit2 . 2 F5 BIG-IP LTM 配置备份和恢复可以通过以下WEB界面进行配置的备份与修改:进入 System?Archiv

36、es ，点击 Create :OptrHlIiiijpliB !48TiBZdH-S-MMS3-a*J01200tU&2iBncrypllunDQ4bM *AM*? Heys-I inciuin、如出flBO-F9J3BUMMJFnZ j FhlsKE叮柿Pi n|祚ili种即Saving act ix.ra 口n fiura 配置备份好后，点击设配置文件并下载到外部电脑上:岛I 屮 沖 I iPnFit MiirtVefzianiFncnptcdiJGCebSOArcliive FifeZJHZS MUS3 awl JM6DS 為SitBI&-IP 商 2. 5 Buld 熨 iNaThti

37、Mw2Sain320CSr 3306i咗Ki妙里arDownkihil 乙血.如oai显5 IE肠朝。怯)恢复系统时点击Restore如果没办法重如果是需要一个完全干净的系统，建议通过重装系统来恢复到出厂设置。装系统，但需要将配置清空以重新进行配置，方法如下：从管理网口用命令行登陆BIG-IP，然后执行以下命令：#b db all reset#b reset#b save#b base reset#b base save2 . 3 F5 BIG-IP LTM 性能状态2 . 3 . 1 F5 BIG-IP LTM 实时连接状态在命令行模式输入：b connZ oor6nn*2 ：4et Ive

38、j 亡 nniHq * b conn13.76.1025:4 5 50L3J hM , 10 5+1/UB11詞.宙EQ96： 70S2tcpls4 h 75, 1D5.5 ：d 5413 J -,10 5.90 ； 7Q51-134Ed ,?Q9-6：7CS?XCp134.7G.iaS.235!45G6 L24,(i4 .laS.OD： 7081t 13-1.&4.jO9-6：?U8_TCpA口乳钢，3几9口；708154.2 W.6；7CS2Kp22 :t2 841_34.64,105.QC!7Dftl:7052tcp134.7?*1351?2

39、:1296 134 M.105*90: 7D81 134.64.09.6:7092 tcp 13 .1?T. ?Q：4332 丄创训 + IM”兀：了OKI134 h 2C9 5；7C31tip14,74-137. 7O;43& y-a13d, 410?.90；7OEL丄M4.币4.2*9* 5:71.3. 64T105r90:70K.1344,209,5:7061tcp46:2058 L34. M.lflS.901 7081 134&4.Q9. 5：7QB1 tcp L34*M42+M；70. 14 54. f Q9：7QS2 匸邙 134 .fi5.5 2.2 2S

40、i&45 54 - 1.24.64. lfl 5. QC! 7D&1 134. &4.205. 6:7692 tcp 1?4.64.1151?5：41366 any;any 134.6*20 247:80l1 tcp 13齐町 70+19帆2円 i-i 13 h LQ5.5C；7Ci31 13.203. ： ；7C31 icp-.-4. .4.1 ： n. 1 ?T ：?1. - r V： - I nr - - -. -.4 .4.7-. ?r.1 : S ri|i134.77,109.250:4397L34, M.102,22 ihttp 134, &4.102. 5:hTtpt邙134.7

41、&lCP25：hyafaK 14.105.90:708111.64.2OT. e ： 7Q82 iqa134,76,11 5h 235 ；d 551,105h9D；7031-14 .&l E09；708EICO1S4.76,105,235 :4S63 134,M.105,90: 7D81134,64.6:7082t邙134.7B.IDS.239 ：49B5 LJ4,irf . 105*901 7081 s134 .M.6：70B2TCP13rQ4.1C5.125：22Z3S f any： iny =a 134.20(1,201:3 J cr3134 P 7D_ 2M.lia： 21721.2d

42、.64,102.22 ： http zhttptcp124. ?D. 211.11:213 L24.M._02,J：-ltT31?4.t4.102.blhltpTCp13 . 7DS1118：2177 Lh&I. 102.22I http1强.讽 ICC Mllttptcp154r7Q, 2Sl.li8;?17E -o134 .Sd, 1,Q?T 22; htTp134 r64.10； .fi;hl:tptcp134.70,2 31,118:217 134,M. 102,22!http134,&.1M.Gihitpt邙Ili4.7D3ll.UJ8：31BO L14.M

43、. 1Q3* 22I httpIM.&4.1D2 WkTttptcph7Q. 2 51,116：31&L AL3ii,&J,L0Zr22；lhLlp1 討.&l.丄 OH ：毗“ICp134.70,2 51,118:2102L34.M.102.22 ：http134.54.103.GihTtptcp134.7D.211*118:2193 &4.102*22 ihttp134.&4.102.fcihTtprep13rQ4.1C512 5：62 77 4、any： iny2.别+105,121：3 J Cr%j22 ;1231IB J .Sd, 10 5T 90 ; 7Q8

44、1154.E4.209.fi:70S2tcp134.7?. 135.122 :1293 L3fl,64.105,90r7D81134,64,509.6:70&2ten查看当前端口的状态0 Jr oat Sn h-2:Art 1 ve：j 一ti nV! config + b *i7t er face弓hwp Ic t 5collbits inbits outerrorstrunkimerfice5.pe*dMb/spi:ts1npkt s outpkt 5 朗口卩rtiQnrt upIODO FD2D272LLillilO002L(J. -M80.L1Mlol DM1000 FD8120056

45、7276B0工.2 DM1000 匚口0000001- 3 UP10D0 匚 0B.J333G弭 K72G155 3M02&. S7T2 29吕丁01H UP10L30 FD070h3M874.3M?8Qvol . _G7L33002.1 UPIODO FD9+055GID. DOG11.15H051 5?T4 9.79T0trunkal工二UPIODO FD866G8_ 690G98952d辺 5. 34-T4 5.17TQlIjtlk：-!r oaTtnn- iactI veconf 1ir查看当前node信息|r jat&r h-2:Active conf 1y 岸 b node she

46、wndoe 13hi.-4b9Ss unch&ckdirubicCur. max. limit, toti Q* 57, Q, 了了羽 tpk5In - CLa7BF 11. ?wjiP gut 0095, 12.21MDrequests ttotalQ - 0NDOE 0? uncheclpedl session Pliablyfeur ? m白11nIt 3 TrtJ 篡(0,3, fl B 46!(pkTS.bitJ in - (2712, 3.5 03W),h cut - (231p W5M) requests (tatal) = 0N0OE 14.64 B10

47、2. -lifi匚hed：.eds essi cri enab s(cur, H14, llflilit, tai) = (1.37, UM, 0, dla77P)l) (pkisjbttsl 111 - (3W.2M 570/2G), OUT - (371.3Mf 2+WST) requissics (io匸訂- 0NQO li4.M-102,.6unched宦d-E?1cr cnjLbiCcur- niaxPlot) = (pkrsjbltj In 二(,3. 5m 3 5 73.1GJ, out = (365.335T；rquasts (tatill) 0NQOE 154, o4 -10

48、2 B 3un匚hedEd5 ess i cn enaJb 5(cur4 maju llrrilitH tot) = (141, 37a 0.咼 加(pkiLS Jbiis) In 如；7m九此九 uui (371- 5m.花鈔It) requesi Ciotdl) - 0node 1M. ：4.102-9 unclThd-：:ed弓些mi亡n enab*aCcur, maxUfflr tot) - (214 Zl, Qi 1*33)CpkTS .Mt5)In - t39O.Rp 5S6 - niJT (35& 0MB ?.B93T requests Ctota!2)三 0NOOE 1 j4.

49、64.工02.20 uncih*ck*d ?.b!ssbIich nabltcurniaXp 1 iifllt p tot = (163 9 727, 0, 31.54M)Cptnsin = (40工：曲丁 5 93.1G), out = (3B7.252t)requests- (lot al ) = Q查看pool状态raarBnh-2iA:t5+ b peel s*ar rejL CPMIS_PCO- LB HLTWD round robin HEH/CUR ACTIVE PEHB-Ri 0.-2 Ccur, marf, limit, TQt - C3?5t 2&50, C,ts i 11

50、 . 44 S. Lj. . - -iT ) . clrt -tb . li A WLamis. .EOL/1H4 別“訓釘：；!. allvc.ups ess non eriabl ed pri ority 1 rati 口 1匚uf * maxH 1 Itti it, tot 壬(20S, 2GS 0 g 67,.12Mj (pkl： Pb1t5)巾- Q汩TiG. B11ST) . QUt - O冷歸G* 32-1QT3 requie-stis tots 1 = G75s SIH+ - pool MLkfiER ._PaoL/lS4.4B2D?.6:7082 amifs&sslan ri

51、a.tledprld勺亡了1 1 rar 1 n 1(cur rru心 limit tot ) C. T飢 04 2.12 JM) (pkts Fb1ts) In - 口4丑护甲 IS. 5SG), DLlt 二(if. E-5K. 13 14G) I | r&qu&sts (TCtalJ = 0寸= rwt rCKfiER kadi eritjjQOl/HA . 64.105.202 S 5252ups ess ion eriabl b dpr 1 orlty 1rar1 口 1(cur 5 max. limits tut J = (60. 101B Dq 5.106*1) CpklS Fb1lS)巾 O?p80f*P 巧/旳Qut - Qti耳1筍Qrmqust告 tctalj = Opool ikZservbrjaool Lt ME.THUD ruund robin