最新F5负载均衡器维护手册.docx

Four short words sum up what has lifted most successful individuals above the crowd: a little bit more.-author-dateF5负载均衡器维护手册F5负载均衡器维护手册F5负载均衡器维护手册目录F5负载均衡器维护手册1一、基本原理411 负载均衡器的基本原理412 负载均衡器几要素413 F5 BIG-IP LTM基本元素514 BIG-IP LTM的TMM815 BIG-IP LTM的负载均衡算法916 BIG-IP LTM会话保持10161 会话保持的需求：10162 源地址会话保持：12163 哈希会话保持13164 Cookie会话保持.1317 健康检查15171 基于ICMP的健康检查15172 基于TCP端口的健康检查16173 基于应用协议的健康检查17二、F5 BIG-IP LTM日常维护1921 F5 BIG-IP LTM外观1922 F5 BIG-IP LTM配置备份和恢复2023 F5 BIG-IP LTM性能状态21231 F5 BIG-IP LTM 实时连接状态21232 F5 BIG-IP LTM 性能状态24233 F5 BIG-IP LTM告警日志26三、F5 BIG-IP LTM服务配置2731 F5 BIG-IP LTM 创建用户2732 F5 BIG-IP LTM开启本地服务2833 手动切换主备状态2934 修改admin和root密码2935 健康检查的管理和维护3036 pool的管理和维护3237 VS的管理和维护3438 iRules管理和维护3639 rofile管理和维护39四、F5 BIG-IP LTM故障处理4041 应用服务故障4042 F5 BIG-IP LTM硬件故障42一、基本原理11 负载均衡器的基本原理应用负载均衡器对外提供一个虚拟的应用服务器，接收所有的客户端请求应用负载均衡器通过负载均衡算法处理，将客户端请求转发到后台的多个应用实例应用负载均衡器通过应用健康检查，准确的判断应用程序的工作和服务状态，一旦发现应用不能提供服务，则将其从负载均衡组中摘除12 负载均衡器几要素负载分配策略：负载分配策略是应用负载均衡的整个核心，如何对用户的流量进行分配，使后台服务器的处理更加合理。达到均衡负载，保证用户的最佳体验的目的，和负载分配策略具有密不可分的关系。健康检查策略：在一个良好设计的系统中，负载均衡器往往处于一个系统的核心位置，很多用户使用四层负载均衡的一个主要原因就是要实现应用的高可用性而非性能问题。如何让负载均衡器能智能的检查到服务器真实的健康状态，在系统的设计中起到至关重要的作用。会话保持策略：就目前而言，只有很少的应用系统是专为多服务器并行处理而设计，用户的登录信息，Session ID等还是在单台服务器上存放，并没有同步到其他的服务器上，因此，会话保持策略的丰富性也是四层负载均衡一个巨大的挑战。冗余切换策略：在保证了后台设备的高可用性之后，出于系统核心位置的负载均衡器自身的高可用性就变得尤其重要，并且由于应用访问的不透明性，造成在紧急情况下很难对所有的应用进行迁移工作。这时负载均衡器的冗余切换策略和手段将关系到整个系统的高可用性。网络结构的灵活性：对于一个横跨网络和应用的设备来说，对于网络结构和应用结构的完整支持特性变得尤其重要，网络层的基本技术如VLAN、Trunk、Spanning、Tree、IPV4/V6、静态路由、OSPF等都将成为负载均衡器的基本配置。而另外对于应用中的各种特殊协议的支持，也决定了负载均衡器部署的范围和使用。13 F5 BIG-IP LTM基本元素在BIG-IP LTM中，针对应用负载均衡的应用特色和系统需求，将整个流量的处理过程按照以下方式进行定义：VS：Virtual Server是进入BIG-IP LTM处理流量的入口。VS 的定义包含了IP和端口和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 profile，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：Pool在LTM的内部是一个逻辑概念，是指的一组相同服务的资源的组合。Pool的作用很简单，就是根据自身定义的分发规则，对VS接收进来，并且被Profile处理之后的流量进行分发，分发到Pool内的member去。Member: 一个应用服务，通常情况下，一个Member就是后台服务器的一个侦听进程，是由IP:port格式组成。Node: Node通常用来表示后台的一个服务IP地址，一个Node上面可以有一个或多个Member。Node不需要进行配置，在配置了Member之后自动产生，系统会根据每一个不同的Member IP地址生成一个Node地址iRules：iRules相当于在整个数据包通路上进行一个监控和处理。VS -Pool-SNAT的这一条路上，iRules可以通过事件驱动方式，在通路上的任何一个位置上对数据包进行判断和处理。比如Client_Accepted事件就是当请求命中VS的时候被激活，pool webpool这条指令用于指示BIG-IP LTM将流量分配到那个Pool里面去。而iRules的事件是否能触发或者iRules能获取和处理那些信息，则都是由关联的Profile来决定的。比如VS只关联了TCP Profile，而没关联HTTP Profile。那即使通过VS的流量都是HTTP请求，iRules也无法去获取URI、header等信息。只有关联了HTTP Profile之后，iRules才能触发HTTP相关事件和按照HTTP协议的相关规范对请求内容进行识别和判断。14 BIG-IP LTM的TMMTMM就是一个应用程序。TMM一旦启动，就会抢占系统的大部分内存(内存分配可以在系统Provision的时候进行分配)， 接管所有的业务端口流量、SSL加解密芯片和HTTP硬件压缩芯片等资源，然后根据自己的需求进行使用。只要从BIG-IP LTM前面板的业务端口进入的流量，都会先经过TMM的处理。当BIG-IP LTM只有单核CPU时，主要的CPU资源都优先分配给TMM进程。在这种结构下，所有的流量处理都在TMM里直接处理，则可以到很高的性能，除了负载均衡以外，在BIG-IP LTM LTM上的SSL、RamCache、Compress、SSL VPN、WOM等功能都是在TMM内部处理的。而一些比较大型的工作模块如GTM(Global Traffic Manager)、WA（Web Accelerator）、ASM(Application Security Manager)和认证等一些功能则是通过其他的进程进行处理，这些进程通过内部的Plugin结构和TMM进行通讯。多核CPU平台：当系统中有多个CPU内核存在时，BIG-IP LTM将进入CMP(Cluster Muti Processor)的工作模式，所谓CMP，就是在BIG-IP LTM LTM的内部，使用硬件芯片HSB（High Speed Bridge）对进入生产端口的流量在内部进行了一次负载均衡，使流量均匀的分布到每个TMM核心上去。而每个TMM核心占据一个CPU内核15 BIG-IP LTM的负载均衡算法轮询算法（Round Robin）：BIG-IP LTM顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生第2到第7 层的故障，则将其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。比率算法（Ratio）：在BIG-IP LTM上给每个服务器分配一个加权值为比例，根椐这个比例，BIG-IP LTM把用户的请求分配到每个服务器。当其中某个服务器发生第2到第7 层的故障，就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。最少连接数（Least Connections）：在BIG-IP LTM上对每一台服务器的当前连接数进行统计，当有新的请求进入时，将新的请求分配给当前最少连接处理的服务器。当其中某个服务器发生第2到第7 层的故障，BIG-IP LTM就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。最快响应速度（Fastest）：在BIG-IP LTM上通过观察每台服务器得应用响应速度，当有新的请求进入的时候，将新的请求分配给响应最快的服务器。当其中某个服务器发生第2到第7 层的故障，BIG-IP LTM就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。观察模式（Observed）：连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障，BIG/IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。性能预测分配：（Predictive）由负载均衡设备收集到的应用程序和应用服务器的各项性能参数如CPU占用率，内存占用率、当前并发用户数等关键信息，并可进行加权处理。当有新的请求进入的时候，将新的请求分配给综合性能最佳的服务器。当其中某个服务器发生第2到第7层的故障，BIG-IP LTM就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。16 BIG-IP LTM会话保持161 会话保持的需求：以最典型的HTTP应用为例，在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果，服务器进行下一步操作时需要这就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上。一个典型的HTTP请求流程如下：l 客户端发起一个连接到服务器的服务端口，并在此连接中发送HTTP请求l 服务器在接收到用户请求后，在本地产生一个内部SessionID 用于唯一标识该用户l 服务器将返回内容进行组织后，同时将Session ID 通过Cookie返回给用户l 用户在收到回应后，将Cookie保存在内存中。l 用户下一次点击重新发起一个连接到服务器的服务端口l 用户在新建连接中发送HTTP请求，并带上Cookie进行发送。l 服务器在收到请求后，从Cookie中获得该用户的Session ID,根据此Session ID进行相关处理162 源地址会话保持：源地址会话保持的一个基本概念就是将一个源地址认为是一个用户，凡是同一个源地发送过来的连接，则认为是同一个用户发起的多个请求，根据会话保持策略，将这些连接/请求都转发到同一台服务器。当一个新的连接请求发送到虚拟服务后，首先查找源地址会话保持表，如果在源地址会话保持表中查询到了该请求发起的源地址对应的服务器，则直接将该请求转发到相应的服务器上，如果在源地址会话保持表中没有查询到相应的条目，则按照负载均衡算法将请求转发到相应的服务器，同时，将该请求发起的源地址和对应的服务器地址添加到源地址会话保持表中。这样，下次同一IP地址再发起新建连接到该虚拟服务时，则在源地址会话保持表中已经存在相应的条目，新的连接则会根据源地址会话保持表的对应项转发到对应的服务器上。源地址会话保持同时还存在有一个超时时间参数。每次有有新建连接请求或已建立的连接中有数据在传输时，就会刷新会话保持表中的超时时间。比如设置源IP会话保持的超时时间为300秒，则对于同一个源IP，只要有新建连接或已建连接有数据传输，则在源地址会话保持表中的超时时间一直刷新为0。当没有新建连接或者数据传输时，该值就开始按秒进行累加，一旦超出300秒没有新建连接请求或没有数据传输。则将其条目从源地址会话保持表中清除。如果该IP地址在在过了超时时间之后又有新的连接请求，则以第一次连接请求按照负载均衡的算法进行处理，此时，源地址会话保持表中的超时时间又从0开始计算。163 哈希会话保持哈希会话保持的一个基本概念就是将一个连接中的源IP 和目的IP地址进行Hash计算，根据计算得到的结果并根据后台存在多少台服务器来选择将请求分配到那台服务器。哈希会话保持的特点是在后台服务器的健康状态不发生改变的时候，每个特定的源IP地址被分配到的服务器是固定的。并且，哈希会话保持可以没有会话保持表，而仅仅是根据计算的结果来确定一个源IP被分配到那台服务器。哈希会话保持通常被用于一些特定场合，如要求客户端按照IP地址被固定分配的场合，或者在一些会话保持表查询的开销已经远远大于Hash计算开销的情况下，采用hash会话保持可以提高系统的处理能力和响应速度。在实际的应用场景中，针对后台采用Cache服务器的情况，还有对URL进行Hash的处理方式，将同一个URL的请求分配到同一台Cache服务器，这样，对后台的Cache服务器群组来说，每台Cache服务器上存放的内容都是不一样的，提高Cache服务器的利用率。164 Cookie会话保持.Cookie是在浏览器访问WEB服务器的某个资源时，由WEB服务器在HTTP响应消息头中附带传送给浏览器的一片数据，WEB服务器传送给各个客户端浏览器的数据是可以各不相同的。浏览器可以决定是否保存这片数据，一旦WEB浏览器保存了这片数据，那么它在以后每次访问该WEB服务器时，都应在HTTP请求头中将这片数据回传给WEB服务器。显然，Cookie最先是由WEB服务器发出的，是否发送Cookie和发送的Cookie的具体内容，完全是由WEB服务器决定的。例如，用一个Cookie来标识访问者的姓名，有效时间等。Cookie Insert会话保持模式因为Cookie被如此广泛的使用，特别是Session Cookie技术，基本上在所有的电子商务网站中都在使用这种技术。因此，在BIG-IP LTM中可以通过插入自己可识别的Cookie来实现会话保持。当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIG-IP LTM，BIG-IP LTM根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行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响应将不带有cookie，服务器响应再次经过进入BIG-IP LTM时，BIG-IP LTM再次写入更新后的会话保持cookie。17 健康检查健康检查是负载均衡处理中一个非常重要的环节。负载均衡的主要作用就是将客户端的请求分配到多台服务器上，如果没有健康检查，在后台服务器发生故障的时候，部分的客户端将会被分配到故障的服务器上，从而导致用户的访问失败。在一些情况下，甚至可能出现服务器本身还在工作，但其上运行的应用系统已经故障导致无法处理请求，都将会导致用户的请求失败。在BIG-IP LTM上应当能检查到这些故障，并在进行负载均衡的时候将这些故障的服务器进行自动摘除，保证应用的持续性和高可用性。171 基于ICMP的健康检查基于ICMP的健康检查属于最基本的健康检查方式，BIG-IP LTM主动给服务器发送一个ICMP(互联网控制信息协议)数据包，如果BIG-IP LTM收到了服务器的正确响应，则说明检查成功。ICMP健康检查通常用于网关类型设备的健康检查，如防火墙、路由器等。这些设备通常不提供其他的健康检查手段，因此ICMP属于最佳的检查方式。另外，在一些无法使用高级健康检查手段的情况下，也只能使用ICMP健康检查手段。172 基于TCP端口的健康检查在基于TCP协议的应用中，每个应用系统都会绑定一个TCP端口，应用通过侦听这个端口接受客户端的请求。比如我们常见的80端口在默认情况下就是服务于HTTP服务，通常为IIS、Apache等应用系统使用，另外还有FTP（20、21）、HTTPS（443）、SMTP（25）、POP3（110）等。判断这些应用系统是否在工作最简单的方法就是从BIG-IP LTM和对应的服务器端口做一次完整的TCP握手，如果TCP握手成功，则认为服务器正常工作，如果握手失败，在超过一定的检查次数均握手失败的情况下，BIG-IP LTM则将失败的服务器标记为Down，而将新的客户端请求都发送到其他仍然正常工作的服务器上。在TCP健康检查中还可能出现的一种情况就是在频繁检查的情况下，健康检查的流量可能导致一些比较“脆弱”的应用系统产生故障。通常有两种情况会出现这种故障情况：1. 服务器的Socket侦听程序不完善，对于TCP健康检查没有正确关闭连接2. 服务器对每个试图连接都进行log，最后整个应用系统的Log都被健康检查的连接所充满。而导致磁盘空间溢出或者正常的log信息无法察看。在这种情况下，有两种解决方式：1. 采用TCP half open的方式进行健康检查，所谓TCP half open就是BIG-IP LTM向服务器发送一个Syn数据包，一旦受到来自该服务的Syn-ACK数据包，则认为该服务正常工作，然后立即发送一个RESET数据包到服务。在一些情况下，这种TCP半连接模式并不会被记录下来。2. 采用基于代理的健康检查，即在服务器上另外编写一个进程，专门用于健康检查使用，专用的健康检查进程将会负责BIG-IP LTM的健康查询，而保护主进程的不受干扰的运行。173 基于应用协议的健康检查由于在ICMP、TCP端口和UDP端口的健康检查中，我们都不一定能确认服务器的真实工作状态。在实际中经常有可能出现这样的情况：l 服务器IP地址还可以ping，但是应用服务已经crash了l 应用服务还在监听80端口，但是已经不接收任何请求了l 应用服务仍然接收请求，但是每次都返回503服务器内部错误这种服务已经不正常，但是端口仍在监听的情况，在一些非关键业务上还可以容忍，但在一些关键业务的应用中就不可接受了。以HTTP协议为例，基于HTTP协议的健康检查过程如下：l BIG-IP LTM发起一个HTTP请求到服务器，请求特定的资源l 服务器进行回应l BIG-IP LTM在返回的内容中查找一个关键字，如果存在该关键字，则认为Web服务器正常工作中。HTTP协议层的健康检查通常用于应用服务器的健康检查，如WebLogic、WebSphare、Tomcat等。和IIS、Apache服务相比，这些应用服务器出现故障的几率通常较大。而且最容易出现端口仍然在侦听，但应用已经不工作的情况。典型的基于应用协议的健康检查通常还有：FTP: 由BIG-IP LTM向FTP服务器发起FTP请求，在验证用户名和密码后，下载一个文件（通常不会保存这个文件），如果文件下载成功，则认为服务器工作正常。这样整个FTP服务器的用户认证、磁盘存储连接等服务都进行了检查。DNS: 由BIG-IP LTM向DNS服务器发起一个DNS请求，请求特定的域名，并检查返回的结果，如果正确，则认为服务器工作正常。HTTPS: 由BIG-IP LTM向HTTPS发起一个HTTPS请求，通常，在HTTPS的健康检查中可能还需要配置客户端证书等，在服务器响应返回后，在返回的数据中查找特定的字符串，如果匹配成功，则认为HTTPS服务器工作正常。POP3：由BIG-IP LTM向POP3服务器发起一个请求，并进行用户名和密码验证。如果登陆成功，则认为POP3服务器工作正常。SMTP：由BIG-IP LTM向SMTP服务器发送一个标准的SMTP请求，如果服务器按照标准SMTP响应返回HELO或QUIT，则认为SMTP服务工作正常。通常情况下，SMTP健康检查在发送请求的时候还需要指定域名。数据库：由BIG-IP LTM向数据库服务器发起一次数据库查询请求，然后判断数据库服务器返回的结果中是否包含特定的字符串，如果匹配成功，则认为数据库服务器工作正常。二、F5 BIG-IP LTM日常维护21 F5 BIG-IP LTM外观F5在设备前面板上划分明显不同的三个区域，最左侧设计有failover和console接口；中部为各种网络接口；最右侧为液晶屏幕、状态显示灯、6个控制按钮及F5的红色logo灯泡。面板前部设计有冷风入口。电源设计在设备的尾部以方便机架上电源线接入，设备产生的热量从尾部的热风出口散出。1.管理口 2.USB接口 3.Console口 4.Failover口 5.10/100/1000自适应接口 6.SFP接口 7.指示灯 8.液晶屏 9.液晶屏控制按钮1.电源模块一 2.电源模块二 3.散热风扇通过LCD按键修改管理网口IP地址的方法如下：1.按红色X按键进入Options选项；2.在液晶面板上通过按键按以下顺序设置管理网口的网络地址：Options->System->IP Address/Netmask->Commit22 F5 BIG-IP LTM配置备份和恢复可以通过以下WEB界面进行配置的备份与修改：进入System?Archives，点击Create：配置备份好后，点击设配置文件并下载到外部电脑上：恢复系统时点击Restore如果是需要一个完全干净的系统，建议通过重装系统来恢复到出厂设置。如果没办法重装系统，但需要将配置清空以重新进行配置，方法如下：从管理网口用命令行登陆BIG-IP，然后执行以下命令：#b db all reset#b reset #b save #b base reset #b base save23 F5 BIG-IP LTM性能状态231 F5 BIG-IP LTM 实时连接状态在命令行模式输入：b conn查看当前端口的状态查看当前node信息查看pool状态查看当前VS信息232 F5 BIG-IP LTM 性能状态查看当前F5性能状态通过WEB页面，Overview选项卡中的Performance查看当前F5 BIG-IP LTM的主备状态查看当前F5 BIG-IP LTM的组件状态命令行模式：b platform查看当前F5 BIG-IP LTM TOP状态命令行模式：bigtop查看F5 BIG-IP LTM TMM内存状态命令行模式：b memory show233 F5 BIG-IP LTM告警日志通过WEB System选项中的logs或者在命令行模式输入more /var/log/messages 查看F5系统日志more /var/log/ltm 查看member和node状态日志收集F5 BIG-IP LTM后台错误日志提交F5官方分析命令行模式输入：qkview f /tmp/myqkview.tar.gz三、F5 BIG-IP LTM服务配置31 F5 BIG-IP LTM 创建用户通过WEB界面，在System选项卡中选择Users-Create32 F5 BIG-IP LTM开启本地服务选择某服务，start即可注：ntpd服务需要在命令行模式修改vi /etc/ntp.conf中，增加ntpserver33 手动切换主备状态34 修改admin和root密码35 健康检查的管理和维护根据需求选择类型以http为例命名规则：类型_端口号，如http_8001Interval：间隔时间，即为健康检查服务向节点发送两次检查数据包的间隔时间。Timeout：超时时间，即为健康检查服务向节点发送健康检查数据包没有回执的超时时间。Send String和Receive String：F5会向节点发送Send String中的内容，如果回执与Receive String中的内容一致，则视为该节点正常。该功能需要有应用人员提供相应的代码。也可以为空。Alias Service Port：指定服务8001端口36 pool的管理和维护 Pool命名规则：pool_（地市名）_系统名（用途），如：pool_oa，pool_anqing_oajkHealth Monitors：指定该pool的健康检查Action On Service Down：节点中服务down了以后的处理方式，一般这里都选择转发（Reselect）Load Balancing Method：负载均衡的方式，根据需求，一般我们选择Round Robin。New Member：这里加入需要负载均衡的应用节点。后续增加pool中的节点在Pool列表选择某个Pool，点击列表上的Members个数链接，或点击Pool名称后，选择Members页签在Member列表，点击右上方的Add按钮，出现添加页面填写ip和端口，configuration选择Advanced，选择monitors,Http服务选择http，其他服务选择tcp（根据具体情况），点击Finished按钮添加完成。如果要移除pool下的节点，可以在pool的列表界面，选中节点，直接点delete，没有确认。37 VS的管理和维护VS命名规则：vs_（地市）_系统用途，例如：vs_oajk，vs_anqing_jtjkDestination：对外提供服务的IPService Port：对外提供服务的端口如果是http服务，http profile需要选上OneConect Profile：链路复用的功能，如果是用cookies inster的会话保持方式时，这一项必须选择oneconnect。或者有会话保持的长连接也需要开启这个功能。SNAT Pool：必须选择Auto Map如果VS只提供单一的服务，不需要irules做条件判断，Default Pool就选择相应的服务节点。如果VS需要有irules做条件判断，来转发vs下属的多个pool，则Default Pool选择none。38 iRules管理和维护iRules运用TCL运行引擎执行脚本。能够对流量直接操控和对任意IP应用流量的管理。iRules命名规则：iRules_服务名称，如：iRules_oajk网厅iRules脚本when HTTP_REQUEST if HTTP:uri starts_with "/sso" pool pool_wt_sso elseif HTTP:uri starts_with "/biz" pool pool_wt_biz elseif HTTP:uri starts_with "/activity" pool pool_wt_activity elseif HTTP:uri starts_with "/vip" pool pool_wt_vip elseif HTTP:uri starts_with "/track" pool pool_wt_track elseif HTTP:uri starts_with "/search" pool pool_wt_search elseif HTTP:uri starts_with "/shop" pool pool_wt_shop elseif HTTP:uri starts_with "/"and HTTP:uri ends_with ".gif" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".jpg" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".jpeg" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".png" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".bmp" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".swf" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".css" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".htm" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".js" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".flv" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".html" pool pool_wt_zy elseif HTTP:uri starts_with "/" and HTTP:uri ends_with ".ico" pool pool_wt_zy elseif HTTP:uri starts_with "/" pool pool_wt_gzfw 39 rofile管理和维护有好几种类型，根据需要选择合适的类型以Source Address Affinity 源地址会话保持为例默认Timeout是180秒，在180内所有请求都会往一个节点分发。根据需要修改Timeout时间。四、F5 BIG-IP LTM故障处理41 应用服务故障模拟场景一：用户反映某通过F5负载均衡的应用服务异常，无法访问。处理过程：1、 web登录应用服务所在的F5 BIG-IP LTM；2、 根据应用服务名称，在VS中搜索相应的VS名称；3、 查看当前VS的状态，是enabled，还是offline，还是disabled。enabled状态是标识，offline是标识，disabled是标识。4、 如果是offline状态，说明该VS下属pool中的members都处于down状态，需要和应用反馈，协查应用服务是否正常。5、 如果VS是enabled状态，需要检查该VS下的pool是那种状态。在vs只有单一pool的情况下，vs是enabled状态，那pool也会是enabled状态。此时需要检查pool下的members是否有不是enabled状态。6、 在检查pool下的members时注意考虑是否有会话保持的设置，可能是应用节点异常，但因健康检查配置不合理，导致F5仍然往故障节点上分发，导致用户正常请求被分发到故障节点上。此时需要与应用沟通，关注应用的日志，是否报错。7、 暂时性恢复此故障，可以把异常的节点先强制offline，让新的请求都发到正常的节点上。模拟场景二：用户反映服务请求都被分发到一个节点上，负载不平均处理过程：1、 web登录应用服务所