F5负载均衡器维护手册

-.z.F5负载均衡器维护手册目录F5负载均衡器维护手册1一、根本原理31．1负载均衡器的根本原理31．2负载均衡器几要素31．3F5BIG-IPLTM根本元素31．4BIG-IPLTM的TMM31．5BIG-IPLTM的负载均衡算法31．6BIG-IPLTM会话保持31．6．1会话保持的需求：31．6．2源地址会话保持：31．6．3哈希会话保持31．6．4Cookie会话保持.31．7安康检查31．7．1基于ICMP的安康检查31．7．2基于TCP端口的安康检查31．7．3基于应用协议的安康检查3二、F5BIG-IPLTM日常维护32．1F5BIG-IPLTM外观32．2F5BIG-IPLTM配置备份和恢复32．3F5BIG-IPLTM性能状态32．3．1F5BIG-IPLTM实时连接状态32．3．2F5BIG-IPLTM性能状态32．3．3F5BIG-IPLTM告警日志3三、F5BIG-IPLTM效劳配置33．1F5BIG-IPLTM创立用户33．2F5BIG-IPLTM开启本地效劳33．3手动切换主备状态33．4修改admin和root密码33．5安康检查的管理和维护33．6pool的管理和维护33．7VS的管理和维护33．8iRules管理和维护33．9rofile管理和维护3四、F5BIG-IPLTM故障处理34．1应用效劳故障34．2F5BIG-IPLTM硬件故障3一、根本原理1．1负载均衡器的根本原理应用负载均衡器对外提供一个虚拟的应用效劳器，接收所有的客户端请求应用负载均衡器通过负载均衡算法处理，将客户端请求转发到后台的多个应用实例应用负载均衡器通过应用安康检查，准确的判断应用程序的工作和效劳状态，一旦发现应用不能提供效劳，则将其从负载均衡组中摘除1．2负载均衡器几要素负载分配策略：负载分配策略是应用负载均衡的整个核心，如何对用户的流量进展分配，使后台效劳器的处理更加合理。到达均衡负载，保证用户的最正确体验的目的，和负载分配策略具有密不可分的关系。安康检查策略：在一个良好设计的系统中，负载均衡器往往处于一个系统的核心位置，很多用户使用四层负载均衡的一个主要原因就是要实现应用的高可用性而非性能问题。如何让负载均衡器能智能的检查到效劳器真实的安康状态，在系统的设计中起到至关重要的作用。会话保持策略：就目前而言，只有很少的应用系统是专为多效劳器并行处理而设计，用户的登录信息，SessionID等还是在单台效劳器上存放，并没有同步到其他的效劳器上，因此，会话保持策略的丰富性也是四层负载均衡一个巨大的挑战。冗余切换策略：在保证了后台设备的高可用性之后，出于系统核心位置的负载均衡器自身的高可用性就变得尤其重要，并且由于应用访问的不透明性，造成在紧急情况下很难对所有的应用进展迁移工作。这时负载均衡器的冗余切换策略和手段将关系到整个系统的高可用性。网络构造的灵活性：对于一个横跨网络和应用的设备来说，对于网络构造和应用构造的完整支持特性变得尤其重要，网络层的根本技术如VLAN、Trunk、Spanning、Tree、IPV4/V6、静态路由、OSPF等都将成为负载均衡器的根本配置。而另外对于应用中的各种特殊协议的支持，也决定了负载均衡器部署的围和使用。1．3F5BIG-IPLTM根本元素在BIG-IPLTM中，针对应用负载均衡的应用特色和系统需求，将整个流量的处理过程按照以下方式进展定义：VS：VirtualServer是进入BIG-IPLTM处理流量的入口。VS的定义包含了IP和端口和VLAN，其中，IP可以是一个IP，也可以是用掩码掩出来的一段IP，端口可以是一个固定的端口，比方80，也可以是0端口，0端口的意思就是侦听所有的端口。VS的定义的含义就是对于发送到BIG-IPLTM上的流量，只有同时命中VS的IP和端口的流量才进展处理。Profile：当流量进入BIG-IPLTM之后，怎样去处理和识别进入VS的流量，就需要由Profile来定义了。Profile分了几种类型，有协议层的Profile比方TCPprofile,UDPprofile。有应用层的Profile比方profile，FTPProfile。还有SSLProfile、会话保持相关的Profile、认证的Profile和其他一些Profile类型。所有的Profile都需要关联在VS上才能生效。有些Profile之间是互斥的关系，比方TCP和UDP,和FTP，VS上关联了TCPprofile，就不能再关联UDPProfile了。因为一旦关联了*个Profile，VS就会按照这个Profile的定义方式去处理流量。所以有些Profile也是相互依存的，比方要关联Profile，就必须先关联TCPProfile。Pool：Pool在LTM的部是一个逻辑概念，是指的一组一样效劳的资源的组合。Pool的作用很简单，就是根据自身定义的分发规则，对VS接收进来，并且被Profile处理之后的流量进展分发，分发到Pool的member去。Member:一个应用效劳，通常情况下，一个Member就是后台效劳器的一个侦听进程，是由IP:port格式组成。Node:Node通常用来表示后台的一个效劳IP地址，一个Node上面可以有一个或多个Member。Node不需要进展配置，在配置了Member之后自动产生，系统会根据每一个不同的MemberIP地址生成一个Node地址iRules：iRules相当于在整个数据包通路上进展一个监控和处理。VS-Pool-SNAT的这一条路上，iRules可以通过事件驱动方式，在通路上的任何一个位置上对数据包进展判断和处理。比方Client_Accepted事件就是当请求命中VS的时候被激活，poolwebpool这条指令用于指示BIG-IPLTM将流量分配到那个Pool里面去。而iRules的事件是否能触发或者iRules能获取和处理那些信息，则都是由关联的Profile来决定的。比方VS只关联了TCPProfile，而没关联Profile。那即使通过VS的流量都是请求，iRules也无法去获取URI、header等信息。只有关联了Profile之后，iRules才能触发相关事件和按照协议的相关规对请求容进展识别和判断。1．4BIG-IPLTM的TMMTMM就是一个应用程序。TMM一旦启动，就会抢占系统的大局部存(存分配可以在系统Provision的时候进展分配)，接收所有的业务端口流量、SSL加解密芯片和硬件压缩芯片等资源，然后根据自己的需求进展使用。只要从BIG-IPLTM前面板的业务端口进入的流量，都会先经过TMM的处理。当BIG-IPLTM只有单核CPU时，主要的CPU资源都优先分配给TMM进程。在这种构造下，所有的流量处理都在TMM里直接处理，则可以到很高的性能，除了负载均衡以外，在BIG-IPLTMLTM上的SSL、RamCache、press、SSLVPN、WOM等功能都是在TMM部处理的。而一些比拟大型的工作模块如GTM(GlobalTrafficManager)、WA〔WebAccelerator〕、ASM(ApplicationSecurityManager)和认证等一些功能则是通过其他的进程进展处理，这些进程通过部的Plugin构造和TMM进展通讯。多核CPU平台：当系统中有多个CPU核存在时，BIG-IPLTM将进入CMP(ClusterMutiProcessor)的工作模式，所谓CMP，就是在BIG-IPLTMLTM的部，使用硬件芯片HSB〔HighSpeedBridge〕对进入生产端口的流量在部进展了一次负载均衡，使流量均匀的分布到每个TMM核心上去。而每个TMM核心占据一个CPU核1．5BIG-IPLTM的负载均衡算法轮询算法〔RoundRobin〕：BIG-IPLTM顺序循环将请求一次顺序循环地连接每个效劳器。当其中*个效劳器发生第2到第7层的故障，则将其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。比率算法〔Ratio〕：在BIG-IPLTM上给每个效劳器分配一个加权值为比例，根椐这个比例，BIG-IPLTM把用户的请求分配到每个效劳器。当其中*个效劳器发生第2到第7层的故障，就把其从效劳器队列中拿出，不参加下一次的用户请求的分配,直到其恢复正常。最少连接数〔LeastConnections〕：在BIG-IPLTM上对每一台效劳器的当前连接数进展统计，当有新的请求进入时，将新的请求分配给当前最少连接处理的效劳器。当其中*个效劳器发生第2到第7层的故障，BIG-IPLTM就把其从效劳器队列中拿出，不参加下一次的用户请求的分配,直到其恢复正常。最快响应速度〔Fastest〕：在BIG-IPLTM上通过观察每台效劳器得应用响应速度，当有新的请求进入的时候，将新的请求分配给响应最快的效劳器。当其中*个效劳器发生第2到第7层的故障，BIG-IPLTM就把其从效劳器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。观察模式〔Observed〕：连接数目和响应时间以这两项的最正确平衡为依据为新的请求选择效劳器。当其中*个效劳器发生第二到第7层的故障，BIG/IP就把其从效劳器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。性能预测分配：〔Predictive〕由负载均衡设备收集到的应用程序和应用效劳器的各项性能参数如CPU占用率，存占用率、当前并发用户数等关键信息，并可进展加权处理。当有新的请求进入的时候，将新的请求分配给综合性能最正确的效劳器。当其中*个效劳器发生第2到第7层的故障，BIG-IPLTM就把其从效劳器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。1．6BIG-IPLTM会话保持1．6．1会话保持的需求：以最典型的应用为例，在大多数电子商务的应用系统或者需要进展用户身份认证的在线系统中，一个客户与效劳器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的，效劳器在进展这些交互过程的*一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果，效劳器进展下一步操作时需要这就要求所有这些相关的交互过程都由一台效劳器完成，而不能被负载均衡器分散到不同的效劳器上。一个典型的请求流程如下：客户端发起一个连接到效劳器的效劳端口，并在此连接中发送请求效劳器在接收到用户请求后，在本地产生一个部SessionID用于唯一标识该用户效劳器将返回容进展组织后，同时将SessionID通过Cookie返回给用户用户在收到回应后，将Cookie保存在存中。用户下一次点击重新发起一个连接到效劳器的效劳端口用户在新建连接中发送请求，并带上Cookie进展发送。效劳器在收到请求后，从Cookie中获得该用户的SessionID,根据此SessionID进展相关处理1．6．2源地址会话保持：源地址会话保持的一个根本概念就是将一个源地址认为是一个用户，但凡同一个源地发送过来的连接，则认为是同一个用户发起的多个请求，根据会话保持策略，将这些连接/请求都转发到同一台效劳器。当一个新的连接请求发送到虚拟效劳后，首先查找源地址会话保持表，如果在源地址会话保持表中查询到了该请求发起的源地址对应的效劳器，则直接将该请求转发到相应的效劳器上，如果在源地址会话保持表中没有查询到相应的条目，则按照负载均衡算法将请求转发到相应的效劳器，同时，将该请求发起的源地址和对应的效劳器地址添加到源地址会话保持表中。这样，下次同一IP地址再发起新建连接到该虚拟效劳时，则在源地址会话保持表中已经存在相应的条目，新的连接则会根据源地址会话保持表的对应项转发到对应的效劳器上。源地址会话保持同时还存在有一个超时时间参数。每次有有新建连接请求或已建立的连接中有数据在传输时，就会刷新会话保持表中的超时时间。比方设置源IP会话保持的超时时间为300秒，则对于同一个源IP，只要有新建连接或已建连接有数据传输，则在源地址会话保持表中的超时时间一直刷新为0。当没有新建连接或者数据传输时，该值就开场按秒进展累加，一旦超出300秒没有新建连接请求或没有数据传输。则将其条目从源地址会话保持表中去除。如果该IP地址在在过了超时时间之后又有新的连接请求，则以第一次连接请求按照负载均衡的算法进展处理，此时，源地址会话保持表中的超时时间又从0开场计算。1．6．3哈希会话保持哈希会话保持的一个根本概念就是将一个连接中的源IP和目的IP地址进展Hash计算，根据计算得到的结果并根据后台存在多少台效劳器来选择将请求分配到那台效劳器。哈希会话保持的特点是在后台效劳器的安康状态不发生改变的时候，每个特定的源IP地址被分配到的效劳器是固定的。并且，哈希会话保持可以没有会话保持表，而仅仅是根据计算的结果来确定一个源IP被分配到那台效劳器。哈希会话保持通常被用于一些特定场合，如要求客户端按照IP地址被固定分配的场合，或者在一些会话保持表查询的开销已经远远大于Hash计算开销的情况下，采用hash会话保持可以提高系统的处理能力和响应速度。在实际的应用场景中，针对后台采用Cache效劳器的情况，还有对URL进展Hash的处理方式，将同一个URL的请求分配到同一台Cache效劳器，这样，对后台的Cache效劳器群组来说，每台Cache效劳器上存放的容都是不一样的，提高Cache效劳器的利用率。1．6．4Cookie会话保持.Cookie是在浏览器访问WEB效劳器的*个资源时，由WEB效劳器在响应消息头中附带传送给浏览器的一片数据，WEB效劳器传送给各个客户端浏览器的数据是可以各不一样的。浏览器可以决定是否保存这片数据，一旦WEB浏览器保存了这片数据，则它在以后每次访问该WEB效劳器时，都应在请求头中将这片数据回传给WEB效劳器。显然，Cookie最先是由WEB效劳器发出的，是否发送Cookie和发送的Cookie的具体容，完全是由WEB效劳器决定的。例如，用一个Cookie来标识访问者的，有效时间等。CookieInsert会话保持模式因为Cookie被如此广泛的使用，特别是SessionCookie技术，根本上在所有的电子商务中都在使用这种技术。因此，在BIG-IPLTM中可以通过插入自己可识别的Cookie来实现会话保持。当客户进展第一次请求时，客户请求〔不带cookie〕进入BIG-IPLTM，BIG-IPLTM根据负载均衡算法策略选择后端一台效劳器，并将请求发送至该效劳器，后端效劳器进展回复〔不带cookie〕被发回BIG-IPLTM，然后BIG-IPLTM插入cookie，将回复返回到客户端。当客户请求再次发生时，客户请求〔带有上次BIG-IPLTM插入的cookie〕进入BIG-IPLTM，然后BIG-IPLTM读出cookie里的会话保持数值，将请求〔带有与上面同样的cookie〕发到指定的效劳器，然后后端效劳器进展请求回复，由于效劳器并不写入cookie，响应将不带有cookie，效劳器响应再次经过进入BIG-IPLTM时，BIG-IPLTM再次写入更新后的会话保持cookie。1．7安康检查安康检查是负载均衡处理中一个非常重要的环节。负载均衡的主要作用就是将客户端的请求分配到多台效劳器上，如果没有安康检查，在后台效劳器发生故障的时候，局部的客户端将会被分配到故障的效劳器上，从而导致用户的访问失败。在一些情况下，甚至可能出现效劳器本身还在工作，但其上运行的应用系统已经故障导致无法处理请求，都将会导致用户的请求失败。在BIG-IPLTM上应当能检查到这些故障，并在进展负载均衡的时候将这些故障的效劳器进展自动摘除，保证应用的持续性和高可用性。1．7．1基于ICMP的安康检查基于ICMP的安康检查属于最根本的安康检查方式，BIG-IPLTM主动给效劳器发送一个ICMP(互联网控制信息协议)数据包，如果BIG-IPLTM收到了效劳器的正确响应，则说明检查成功。ICMP安康检查通常用于网关类型设备的安康检查，如防火墙、路由器等。这些设备通常不提供其他的安康检查手段，因此ICMP属于最正确的检查方式。另外，在一些无法使用高级安康检查手段的情况下，也只能使用ICMP安康检查手段。1．7．2基于TCP端口的安康检查在基于TCP协议的应用中，每个应用系统都会绑定一个TCP端口，应用通过侦听这个端口承受客户端的请求。比方我们常见的80端口在默认情况下就是效劳于效劳，通常为IIS、Apache等应用系统使用，另外还有FTP〔20、21〕、S〔443〕、SMTP〔25〕、POP3〔110〕等。判断这些应用系统是否在工作最简单的方法就是从BIG-IPLTM和对应的效劳器端口做一次完整的TCP握手，如果TCP握手成功，则认为效劳器正常工作，如果握手失败，在超过一定的检查次数均握手失败的情况下，BIG-IPLTM则将失败的效劳器标记为Down，而将新的客户端请求都发送到其他仍然正常工作的效劳器上。在TCP安康检查中还可能出现的一种情况就是在频繁检查的情况下，安康检查的流量可能导致一些比拟“脆弱〞的应用系统产生故障。通常有两种情况会出现这种故障情况：1.效劳器的Socket侦听程序不完善，对于TCP安康检查没有正确关闭连接2.效劳器对每个试图连接都进展log，最后整个应用系统的Log都被安康检查的连接所充满。而导致磁盘空间溢出或者正常的log信息无法观察。在这种情况下，有两种解决方式：1.采用TCPhalfopen的方式进展安康检查，所谓TCPhalfopen就是BIG-IPLTM向效劳器发送一个Syn数据包，一旦受到来自该效劳的Syn-ACK数据包，则认为该效劳正常工作，然后立即发送一个RESET数据包到效劳。在一些情况下，这种TCP半连接模式并不会被记录下来。2.采用基于代理的安康检查，即在效劳器上另外编写一个进程，专门用于安康检查使用，专用的安康检查进程将会负责BIG-IPLTM的安康查询，而保护主进程的不受干扰的运行。1．7．3基于应用协议的安康检查由于在ICMP、TCP端口和UDP端口的安康检查中，我们都不一定能确认效劳器的真实工作状态。在实际中经常有可能出现这样的情况：效劳器IP地址还可以ping，但是应用效劳已经crash了应用效劳还在监听80端口，但是已经不接收任何请求了应用效劳仍然接收请求，但是每次都返回503效劳器部错误这种效劳已经不正常，但是端口仍在监听的情况，在一些非关键业务上还可以容忍，但在一些关键业务的应用中就不可承受了。以协议为例，基于协议的安康检查过程如下：BIG-IPLTM发起一个请求到效劳器，请求特定的资源效劳器进展回应BIG-IPLTM在返回的容中查找一个关键字，如果存在该关键字，则认为Web效劳器正常工作中。协议层的安康检查通常用于应用效劳器的安康检查，如WebLogic、WebSphare、Tomcat等。和IIS、Apache效劳相比，这些应用效劳器出现故障的几率通常较大。而且最容易出现端口仍然在侦听，但应用已经不工作的情况。典型的基于应用协议的安康检查通常还有：FTP:由BIG-IPLTM向FTP效劳器发起FTP请求，在验证用户名和密码后，下载一个文件〔通常不会保存这个文件〕，如果文件下载成功，则认为效劳器工作正常。这样整个FTP效劳器的用户认证、磁盘存储连接等效劳都进展了检查。DNS:由BIG-IPLTM向DNS效劳器发起一个DNS请求，请求特定的域名，并检查返回的结果，如果正确，则认为效劳器工作正常。S:由BIG-IPLTM向S发起一个S请求，通常，在S的安康检查中可能还需要配置客户端证书等，在效劳器响应返回后，在返回的数据中查找特定的字符串，如果匹配成功，则认为S效劳器工作正常。POP3：由BIG-IPLTM向POP3效劳器发起一个请求，并进展用户名和密码验证。如果登陆成功，则认为POP3效劳器工作正常。SMTP：由BIG-IPLTM向SMTP效劳器发送一个标准的SMTP请求，如果效劳器按照标准SMTP响应返回HELO或QUIT，则认为SMTP效劳工作正常。通常情况下，SMTP安康检查在发送请求的时候还需要指定域名。数据库：由BIG-IPLTM向数据库效劳器发起一次数据库查询请求，然后判断数据库效劳器返回的结果中是否包含特定的字符串，如果匹配成功，则认为数据库效劳器工作正常。二、F5BIG-IPLTM日常维护2．1F5BIG-IPLTM外观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. 按红色*按键进入Options选项；2. 在液晶面板上通过按键按以下顺序设置管理网口的网络地址：Options->System->IPAddress/Netmask->mit2．2F5BIG-IPLTM配置备份和恢复可以通过以下WEB界面进展配置的备份与修改：进入System"Archives，点击Create：配置备份好后，点击设配置文件并下载到外部电脑上：恢复系统时点击Restore如果是需要一个完全干净的系统，建议通过重装系统来恢复到出厂设置。如果没方法重装系统，但需要将配置清空以重新进展配置，方法如下：从管理网口用命令行登陆BIG-IP，然后执行以下命令：*bdballreset*breset*bsave*bbasereset*bbasesave2．3F5BIG-IPLTM性能状态2．3．1F5BIG-IPLTM实时连接状态在命令行模式输入：bconn查看当前端口的状态查看当前node信息查看pool状态查看当前VS信息2．3．2F5BIG-IPLTM性能状态查看当前F5性能状态通过WEB页面，Overview选项卡中的Performance查看当前F5BIG-IPLTM的主备状态查看当前F5BIG-IPLTM的组件状态命令行模式：bplatform查看当前F5BIG-IPLTMTOP状态命令行模式：bigtop查看F5BIG-IPLTMTMM存状态命令行模式：bmemoryshow2．3．3F5BIG-IPLTM告警日志通过WEBSystem选项中的logs或者在命令行模式输入more/var/log/messages查看F5系统日志more/var/log/ltm查看member和node状态日志收集F5BIG-IPLTM后台错误日志提交F5官方分析命令行模式输入：三、F5BIG-IPLTM效劳配置3．1F5BIG-IPLTM创立用户通过WEB界面，在System选项卡中选择UsersCreate3．2F5BIG-IPLTM开启本地效劳选择*效劳，start即可注：ntpd效劳需要在命令行模式修改vi/etc/ntp.conf中，增加ntpserver3．3手动切换主备状态3．4修改admin和root密码3．5安康检查的管理和维护根据需求选择类型以为例命名规则：类型_端口号，如_8001Interval：间隔时间，即为安康检查效劳向节点发送两次检查数据包的间隔时间。Timeout：超时时间，即为安康检查效劳向节点发送安康检查数据包没有回执的超时时间。SendString和ReceiveString：F5会向节点发送SendString中的容，如果回执与ReceiveString中的容一致，则视为该节点正常。该功能需要有应用人员提供相应的代码。也可以为空。AliasServicePort：指定效劳8001端口3．6pool的管理和维护Pool命名规则：pool_〔地市名〕_系统名〔用途〕，如：pool_oa，pool_anqing_oajkHealthMonitors：指定该pool的安康检查ActionOnServiceDown：节点中效劳down了以后的处理方式，一般这里都选择转发〔Reselect〕LoadBalancingMethod：负载均衡的方式，根据需求，一般我们选择RoundRobin。NewMember：这里参加需要负载均衡的应用节点。后续增加pool中的节点在Pool列表选择*个Pool，点击列表上的Members个数，或点击Pool名称后，选择Members页签在Member列表，点击右上方的Add按钮，出现添加页面填写ip和端口，configuration选择Advanced，选择monitors,效劳选择，其他效劳选择tcp〔根据具体情况〕，点击Finished按钮添加完成。如果要移除pool下的节点，可以在pool的列表界面，选中节点，直接点delete，没有确认。3．7VS的管理和维护VS命名规则：vs_〔地市〕_系统用途，例如：vs_oajk，vs_anqing_jtjkDestination：对外提供效劳的IPServicePort：对外提供效劳的端口如果是效劳，profile需要选上OneConectProfile：链路复用的功能，如果是用cookiesinster的会话保持方式时，这一项必须选择oneconnect。或者有会话保持的长连接也需要开启这个功能。SNATPool：必须选择AutoMap如果VS只提供单一的效劳，不需要irules做条件判断，DefaultPool就选择相应的效劳节点。如果VS需要有irules做条件判断，来转发vs下属的多个pool，则DefaultPool选择none。3．8iRules管理和维护iRules运用TCL运行引擎执行脚本。能够对流量直接操控和对任意IP应用流量的管理。iRules命名规则：iRules_效劳名称，如：iRules_oajk网厅iRules脚本when_REQUEST{if{[::uri]starts_with"/sso"}{poolpool_wt_sso}elseif{[::uri]starts_with"/biz"}{poolpool_wt_biz}elseif{[::uri]starts_with"/activity"}{poolpool_wt_activity}elseif{[::uri]starts_with"/vip"}{poolpool_wt_vip}elseif{[::uri]starts_with"/track"}{poolpool_wt_track}elseif{[::uri]starts_with"/search"}{poolpool_wt_search}elseif{[::uri]starts_with"/shop"}{poolpool_wt_shop}elseif{[::uri]starts_with"/"and[::uri]ends_with".gif"}{poolpool_wt_zy}elseif{[::uri]starts_with"/"and[::uri]ends_with".jpg"}{poolpool_wt_zy}elseif{[::uri]starts_with"/"and[::uri]ends_with".jpeg"}{poolpool_wt_zy}elseif{[::uri]starts_with"/"and[::uri]ends_with".png"}{poolpool_wt_zy}elseif{[::uri]starts_with"/"and[::uri]ends_with".bmp"}{poolpool_wt_zy}elseif{[::uri]starts_with"/"and[::uri]ends_with".swf"}{poolpool_wt_zy}elseif{[::uri]starts_with"/"and[::uri]ends_with".css"}{poolpool_wt_zy}elseif{[::uri]starts_with"/"and[::uri]ends_with".htm"}{poolpool_wt_zy}elseif{[::uri]starts_with"/"and[::uri]end