F5负载均衡与IBM Webseal 、WebSphere Portal集成

一，问题提出

某大型企业新建设综合协同门户平台（WebSphere Portal &WCM 8.5、Security Acc Manager7.1、 SDS6.3.1 、Oracle 11G R2 ），由于需要通过F5负载均衡设备对IBM webseal反向代理认证以及Portal进行负载均衡，在按照客户之前老版门户的F5配置后，发现门户访问发生偶发性的无法访问现象，504错误，刷新页面又能连上，影响系统上线运行。由于新版综合协同门户平台历经老版门户后采用全新软硬件环境实施后系统环境较复杂，给故障问题的诊断带来了不便。

故障的表现为：在通过浏览器访问门户时，偶发性的突然出现无法访问页面的现象，页面返回504错误（如断网现象一样），刷新页面又能连上。此故障有时访问四到到五次发生一次，有时访问几十次发生一次，故障的间隔时间没有规律性，有的电脑发生频率高，有的电脑发生频率低。

二， F5与后端应用网络部署情况**

新门户平台上线上，新增负载均衡设备F5，如下图所示：

5月6日F5随着新版门户与格尔网关、F5联调测试，就不断发现指纹认证之后会比较频繁出现类似网络断开后的网页界面错误，但并不是每次都会有，刷新却能够连接正常显示正常页面。

三，问题分析与处理过程**

刚开始认为是格尔网关的问题，一直与格尔网关在沟通，对方也反复的对自己的参数进行了调优，其响应速度上也确实得到了提升，修正了一些格尔网关的相关问题，但联调测试发现通过刷指纹走格尔网关仍然有报504断网的现象，因为格尔网关在整个系统中是属于最前端的反向代理层，其主要作用是获取指纹认证信息，指纹认证通过后，格尔网关会将请求指向F5上的一个虚拟IP，经由此F5的虚拟IP负载均衡我门户系统前端的多个反向代理与认证，最后才到我门户系统，因为整个请求经过了格尔网关、F5负载均衡、IBM WebSeal反向代理、WebSphere Portal，所经过的链路比较多，排故点也比较多，加上这些软硬件产品分属客户不同的单位，协调与处理问题特别的困难，没有明确的问题与故障点结论，各方是很难去配合从自己角度找问题的，只是认为自己所负责的部分没有问题，而从我门户项目角度实施来看，唯有去主导这个问题的解决才能够推动大家去努力找问题，才能够让项目按时上线，在这个时候过多的去和各单位斡旋、扯皮是无济于事的。

尽管以前实施项目的时候就涉及到F5与格尔网关这些硬件设备，但每次整合联调都很顺利，从未遇到过问题，所以也就没有过多的去研究这些产品，从目前来看，唯有先从我们自己的门户产品上入手分析，逐个测试，采用排除方式，缩小问题发生的范围，所以先抛开这两个硬件产品的整合，直接从客户端访问Webseal反向代理到门户，和项目团队达成共识后，项目团队成员经过测试后反馈给我的结果是正常，不存在504的错误，继而再和F5联调测试发现，不走格尔网关同样也出现了504的问题，这时应该像是与格尔网关问题不大了，为了进一步证明，所以不走F5，直接走格尔网关到Webseal再到门户， 发现访问一切正常，这时应该基本可以判断与格尔网关没有太大关系，那Webseal+portal也应该问题不大，单独访问都正常，所有问题指向到了F5设备，整个测试是比较繁琐的，因为不是你想测试出问题就有问题，通过浏览器打开网页好几十次才会发生一次，还需要找出些规律性或共性的东西，如：浏览器的版本问题，IE6、IE8 浏览器，操作系统版本问题，windows xp 、Windows 7，64位和32位，所以测试就是反复的打开和关闭浏览器（将门户首页设置为主页），到这个时候一个原计划一两天完事的工作，整整花了一两个星期，不过尽管如此，到这个时候其实大家觉得还是值得的，因为感觉问题点找到了，可客户领导招集网络安全、服务器、系统软件等各单位的人一开会，把测试的结果告知给大家的时候，发现并不是我们所想象的简单，一个很简单的反驳就把我们的努力打回了原型，F5负责单位的人提出：你说我F5有问题，为什么现在运行的老版门户没问题，现在新版门户在F5上的负载均衡配置都一模一样。是啊，我咋能解释了，我能解释这问题不就直接解决了嘛，好吧，各自回去再研究吧，为了确保我Webseal+Portal独立环境没问题，别有测试不到位的情况，会后的一个周六上午我亲自上阵测试，分四种场景:

一，F5+Webseal+Portal
二，F5+WAS应用
三，Webseal+Portal
四，WAS应用

这一测试不要紧，每种场景都发生了504的错误，而且把测试出来的问题当场给项目团队成员看，把大伙给好好的说教了一番，客户的项目经理也在场，这时问题点似乎还真与F5可能没有太大关系，可能是在网络上了，为了以求可信度，正准备让大家都投入到测试当中来时，整个机房这个时候停电了，那就只能周一上班再测试了，有了这个结论周一就在客户领导的招集下，把各单位的人招集在一起开会讨论，把这个结论告知给大家时，顿时我又傻眼了，现在的老版门户不是很正常吗，新版门户服务器所走的网络、汇聚交换机、园区交换机、F5都是同一套啊，没有区别啊，问题依旧又抛回来了，大家回去再研究吧，给了一个很友好的建议，能不能在服务器上直接访问进行测试，多说没用，也只能应声答应了。可这一回去测试发现问题突然不发生了，把情况反映给客户领导，指示继续测试与监控，大家在琢磨，看样子问题是怕开会的，开会问题就没有了啊，这样一直监控了近一个月，直到6月10日都没有发生，其实这个过程中我和客户都是很担心的，我个人直觉告诉我，IT项目中所遇到的问题没有做任何处理就突然好了的情况是最可怕的，因为你不能让问题重现去继续查找问题的原因，只能够等待它的出现，而且这个等待出现的过程是如此受煎熬，果然还是发生了，问题在6月10日往后就频繁发生了，这时门户平台功能开发与完善的工作也特别繁重，为了不影响项目总体进度，我并没有让大家撂下手头的工作来处理此问题，以项目内容实施优先，我来花时间进行一段时间的观察，找问题的共性。

这个阶段我个人每天花少量时间又重新把整个联调测试进行对比测试，联调测试与观察了差不多有1个星期，得出测试结论是：1.走F5负载HP四台刀片上的Webseal应用再到门户，会有504页面错误的发生，2.走F5负载HP四台刀片上的Webseal应用，反向代理刀片机上的一个WAS应用，同样会有504页面错误的发生，但发生频率会相对少于webseal反向代理门户的情况，3.走F5负载HP四台刀片机上的WAS应用上的一个简单的jsp页面，不经过Webseal，也同样会有504页面错误，发生频率会相对少于webseal反向代理门户的情况

这个时候的结论基本上可以认为：

1.F5访问刀片机上的应用就会有问题，因为F5上还有配置其它的负载均衡应用，配置与新版门户的负载是一致的，其它负载均衡应用是正常的，所以客户认为F5应该不是问题点，认为刀片机以及这段网络、应用是不是会有问题

为了进一步验证测试结果，其实最好的方法就是数据抓包进分析数据包，我们建议在F5上进行抓包分析，而客户方负责F5的工程师根本不知道这个抓包要怎么用，或者直接说是生产环境不能抓包，也咨询不到F5的售后了，没有了维保服务，也联系不到懂F5的售后人员，总而言之，要想从F5上找到突破口，一个字，难，两个字，很难，三个字，非常难，因为对方压根就认为F5上没有问题，有问题的话同样的配置，其它的应用也都会有问题，这个逻辑我作为乙方只能默默的接受，明明知道这个逻辑是不成立的，但你又拿不出反驳的理由，因为目前来看我还不懂这个产品。这个时候我也去查了F5的相关文档和配置，包括在F5上用TCPDUMP命令，甚至F5负载均衡的配置参数，也建议去尝试，但每次领导招集大家开会讨论，F5的工程师也好，负责刀片机服务器方的人也好，负责网络方的人也好，认为自己的部分都没有问题，大家依旧在推卸责任，在找不到突破口的情况下，我只能先确保我们的应用没有问题，所以又对webseal应用进行了一番参数优化与测试，同时在刀片机上使用TCPDUMP命令进行网络抓包，反复的测试对比，得出的结论是：
我方的应用是没有问题的，在通过F5访问webseal出现504页面错误的时候，数据包中就没有任何http请求包，也就是说F5就压根没有请求到刀片机。

到6月底的时候，双方就比较着急了，领导招集各单位的人每隔两天开始会讨论，每次各单位的人又开始在见招拆招了。
1.什么建议从网络上排查，画出负载均衡应用上的正常的和不正常的应用网络链路，把不正常部分的网络链路做成与正常的一致，或者尽量拿掉可能有影响的部分；
2.将F5直接指向小机门户进行测试（在5月的时候就要求配置F5到小机门户的应用，但通过F5一直无法访问）；
3.换台机器上安装Webseal应用进行测试，在门户IBM小机上安装Webseal应用进行测试。

这个时候气氛异常紧张，领导也很清楚现状如此，靠自己单位的人配合来解决是不可能的，领导认为需要一个懂整套软硬件环境（服务器、网络、应用）的技术牛人，或者说要一个“外来的和尚好念经“的人，进行全盘的分析来指导这项工作，可能本身是领导的压力比较大，问题不解决有担心项目会延期，这个我理解，我未尝不是承受了巨大的压力了，这个时候领导还不忘反复的在给我施加压力，甚至让我找原厂商，认为原厂商应该会有这样的牛人，刚开始基于领导的不太好心情也不能冒然的去解释，只能说尝试，其实问题不在需要有多牛的人，而在于对问题的认知和各单位人员的协调，作为乙方的我，在这种环境中只能够是建议，如果对方明确拒绝也只能是接受，找外部的牛人可能性不太大，只能是自己来解决了。

没办法，每次开会客户各单位的领导和工程师都会有新的建议，甚至有的领导还认为你们做门户这么大的项目就应该罗软硬件设备、服务器、网络、应用都精通，遇到问题全都能搞定，我想经历几个这样的项目后，不久的将来也许还真会修炼成功。最后发现其实都是在玩太极啊，看来完全是指望不上了各单位的人，只会走入深渊。

人家提的建议你又不能不去做啊，当然需要大家配合的部分还得要出个方案给大家，要罗列出每个单位的事项出来，每次开会先不说别的，先问你需要有方案的部分，方案有做了没有，测试结果怎么样。

截止到7月8日，加班加点去按照建议一个一个的排除测试，结论是：只要是走F5到Webseal访问门户，无论是webseal在刀片机还是小机，都有问题，而F5直接指向小机上的门户没有问题，同时也将刀片机的刀容或网卡都进行了更换，只要走F5问题依然，这个时候一致认为刀片机也没有问题的。

这个时候再和领导讨论，我不建议再将各单位的人招集了，和甲方项目经理一致建议找F5的原厂商工程师，但涉及到要申请费用，担心如果来了后不是F5的问题或者解决不了，不好给上面解释，甚至质疑门户应用是不是本身有问题，需要我一个肯定的答复，这么多年的经验和近段时间的测试与观察告诉我， webseal+portal的部分是可以肯定没有问题，但即便如此，我也不会去做这个承诺，因为没有意义，在态度上来说是不可取了，就我要的是解决问题而不是去划分责任，就算我承诺了保证没问题，最后对我项目来说并不会带来帮助，我的回答是，我们的目标不是去划分谁负责的部分有问题和没有问题，在我看来这个问题就是项目中的一部分，我要去做的就是去解决它。这个时候能够感受到领导的压力挺大的，面对如此情况我的压力要想而之，为了减轻双方各自的压力，我就自高奋勇的建议先不让申请费用，我来深入研究下F5，另外找其它渠道找外部资源，达成共识后，当晚就开始研究F5的各项配置。

F5的核心就是Virtual Server，所以主要关键配置选项还是在virtual Server的配置，而 F5 VS type 又是virtual server配置中比较得要的一环，中的Standard VS模式与四层交换模式，应该是我们门户应用负载均衡都可以用的，尽管相关文档建议是当为http与https协议的应用时，建议采用Standard VS模式，而实际我们的webseal负载只需要F5实现IP+port，不需要对做应用层的处理，只需要负载路由就好，而且选择四层交换模式后，VS的配置项会变得更少，像OneConnectProfile等参数已没有，会话保持选项中的cookie会话保持不能选择，但是有源地址保持可选择，这个可以满足我们的应用负载需求，通过源地址IP来保持一个会话保持到后台的同一台Webseal服务器。简化了参数配置，而且完全满足我们应用的需求，负载性能上也是最优的，为什么不选择这个了？

第二天早上，我就和客户的F5负责人商量，能不能改下配置进行测试，还好的是爽快的同意了，登录到F5的WEB控制台，进行操作，因为事先我反复的看过好几遍F5 的配置，对里面的选项也是比较了解了，到了VS界面我很快的发现，F5直接指向新版本门户的VS配置采用的就是四层交换模式，而F5指向Webseal的配置是Standard VS模式，突然间觉得整个人精神了，因为前者正是一直测试没有问题的负载均衡，后者是测试有问题的负载均衡，将指向webseal的VS配置改成4层后，参数少了很多，oneconnectProfile和httpProfile等参数都没有了，然后将会议保持改成源地址保持。

让大家进行测试了一上午没有发生了，为了谨慎起见，我并没有说问题解决了，只是建议再多使用一段时间看结果，其实我心是明白困扰近三个月的问题总算解决了。

四，总结

整个项目实施过程发现还是会有些客观的问题存在的，甲乙双方沟通、协调、配合等等，最终尽管问题解决了，但总觉得是不是还可以做和更好点，如在第一次测试到可能是F5问题时，就花时间研究下F5的相关配置，甲方工程师不愿意主动来处理此问题，我们是不是可以更主动的去帮别人从F5配置上分析，当然一切都只是假设，谁也没想到会是如此的一个结果，“老版门户没问题，为什么新版门户会有问题了，两个配置是一样的啊”，凡事都是在变的，不能老用惯性思维考虑问题，事物间存在联系与否，在你不了解其本质之前，也许并不是你所理解的和能解释清楚的，少做点理所当然的判断，多一点实践与操作才是解决问题最好的方法。

一个并不复杂的问题为什么花了这么长时间以这种方式解决了，站在我项目管理的角度来看，也许还有值得我去深思与改进的。

五，资料附录

附录F5关键参数配置：
F5负载均衡关键参数配置
F5 Big-IP负载均衡设备的配置文档从头到位看过后，对产品基本功能以及负载均衡的模式有了解到， F5配置最简单负载均衡，需要配置的参数有Node（节点）、Pool（资源池）、和Virtual Server（虚拟服务器），它们的关系式，先配置Node，然后配置VS。Node是最基本的定义，如每个服务器就是一个Node，负载均衡Pool是一组Node接收和处理流量的一组设备，如web服务器集群。BIGIP系统将客户机流量请求发送到Pool成员中的任一服务器上（Node），然后将Pool与BIGIP系统中的Virtual server相关联，最后，BIGIP系统将进入Virtual Server中流量传输到Pool成员，Pool再传达给Node。

F5的核心就是Virtual Server。主要关键配置选项还是在virtual Server的配置，其中VS type和OneconnectProfile选项收集到的信息如下：

Virtual Server重要参数

1、VS Type
在配置VS时，VS的Type有Performance L4、Standard VS、Forwarding IP 和 Fast Http。一般企业中常见的是前三种，考虑到尽量减少F5负载均衡引入对应用系统的影响，在可能的情况下，建议优先选用Performance L4类型的Virtual Server。在一些必须使用Standard的情况下，必然需要在F5设备上启用7层功能，包括Cookie会话保持、Session ID会话保持、Header会话保持、基于交易的长连接拆分等应用场景。另外，在应用系统需要使用F5实现Syn攻击防护时，可以采用 Standard Virtual Server。在明确后台应用基于HTTP协议时，建议在Standard的基础上关联BIGIP内置的标准HTTP Profile。对于非HTTP协议的应用，需要在VS上关联的其他Profile或者iRules根据实际的业务需求进行确定。

第一种： Performance L4 模式（4层数据的转发）

Performance L4模式如图2所示，其中TMM只是负责客户端连接的分配和转发，不改变TCP连接中的任何参数，即客户端连接与服务器拦截是1：1的关系。一般企业中常是这种模式，因为转发速率快。但在一些7层数据包的情况下，如HTTP，建议使用Standard VS模式。

第二种 Standard VS模式
在这种模式下，客户端与服务器端的TCP连接完全独立，同时F5默认情况下以客户端源IP和后台建立连接，在打开SNAT的情况下用SNAT地址和后台建立连接。Standard VS的端口永远对外开放，无论后台是否有服务器在工作。也就是说，如果VS开放的端口是80，在Node A和Node B都down的情况下，虚IP的80端口还是可以telnet通的，只不过网页访问不了了。

第三种： Forwarding IP

一般用于内外网连接，没有Pool Member，转发完全取决于本地路由。默认情况下，F5没有路由功能，需要建立一个全0的VS去开启F5的路由功能，其中，如果想控制只有内网可以访问外网，而外网不能访问内网，可以通过调整“VLAN and Tunnel Traffic”参数来实现。

2. VS Profile

VS Profile 是依赖于VS的存在，是对于VS的流量进行格式化处理。如果VS上配置了TCP Profile，那么对于UDP的连接，F5是不会接受的。

tcp参数中Idel Timeout值（多长时间连接里面没有数据流量时就删除连接表）必须要与服务器相配合，否则会出现错误。如果F5上此值为150s，而IIs服务器为300s，就会产生大量错误。

3、 VS里面的Address Translation 和 Port Translation ，默认情况下都是 enabled。

Address Translation的含义是如果外面访问的主机和VS IP不一样，就需要开启此参数，比如VS IP地址是192.168.27.100，真实机器为192.168.27.10，那么需要开启Address Translation，而企业应用中，这参数一般是开启的，除非特殊的上面介绍的Fowarding IP模式不需要开启。

Port Translation 参数的意思是VS地址是192.168.27.100的8080端口对应真实地址的80端口，那么需要开启Port Translation

4、SNAT Pool

内网需要访问公网进行NAT转换。当配置SNAT AutoMap的时候，表示请求从哪个VLAN发出去，则SNAT的源地址为VLAN上的SelfIp，比如外网用户（192.168.27.1）访问内网服务器（192.168.192.10），在开启SNAT AutoMap的情况下，访问的源IP将转变为F5的内网SelfIP（192.168.192.2）去访问。当一个vlan上有多个SelfIP存在的时候，SNAT的源地址是在多个SelfIP之间轮询。

5、会话保持

在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过多次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，服务器进行下一步操作时需要，就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上。

F5 BigIP支持多种的会话保持方式，其中包括：简单会话保持（源地址会话保持）、HTTP Header的会话保持，基于SSL Session ID的会话保持，I-Rules会话保持以及基于HTTP Cookie的会话保持，此外还有基于SIP ID以及Cache设备的会话保持等。下面重点介绍一下基于源地址会话保持和基于HTTP Cookie的会话保持。

源地址会话保持就是基于访问的源地址，如果一直是该IP在访问，则一直定向到一台服务器。比较重要的是会话保持时间，默认是180s，可以根据具体需要进行修改。

但是存在的问题就在于当多个客户是通过代理或者地址转换的方式来访问服务器时，由于都分配到同一台服务器上，会导致服务器之间的负载严重失衡。另外一种情况是客户机数量很少，但每个客户机都会产生多个并发访问，对这些并发访问也要求通过负载均衡器分配到多个服务器上，这时，基于客户机源地址的会话保持方法也会导致负载均衡失效。

这里就出现了第二种会话保持的功能基于Cookie的会话保持，这个常用于HTTP/HTTPs复杂均衡，即一个用户访问一个网站，在客户没有清除Cookie的情况下，F5总会命中同一台服务器，这就防止了比如用户访问网银时，需要跳转页面时，跳转到另外一台服务器上，导致交易失败的情况发生。

6、 One Connect

在使用VS Standard模式，并且一般和Cookie的会话保持一起使用时，One Connect实现连接聚合降低服务器的总连接数。

基于四层交换技术的负载均衡技术

这种技术是在第四层交换机上设置Web服务的虚拟IP地址,这个虚拟IP地址是DNS服务器中解析到的Web服务器的IP地址,对客户端是可见的， 当客户访问此Web应用时,客户端的Http请求会先被第四层交换机接收到,它将基于第四层交换技术实时检测后台Web服务器的负载,根据设定的算法进行快速交换,常见的算法有轮询，加权，最少连接?随机和响应时间等。

基于七层交换技术的负载均衡技术

基于第七层交换的负载均衡技术主要用于实现Web应用的负载平衡和服务质量保证它与第四层交换机比较起来有许多优势:第七层交换机不仅能检查 TCP/IP数据包的TCP和UDP端口号,从而转发给后台的某台服务器来处理,而且能从会话层以上来分析Http请求的URL,根据URL的不同将不同的Http请求交给不同的服务器来处理(可以具体到某一类文件,直至某一个文件),甚至同一个URL请求可以让多个服务器来响应以分担负载(当客户访问某一个URL,发起Http请求时,它实际上要与服务器建立多个会话连接,得到多个对象,例如.txt/.gif/.jpg文档,当这些对象都下载到本地后,才组成一个完整的页面)