IBM Http Server 配置文件plugin-cfg.xml详细说明

 

 

内容提要:

WebSphere Application Server V5.0.xV5.1.x(以下简称WAS)中HTTP插件(plugin)负责提供WAS群集中Web容器的负载均衡和失效接管功能。但是有些情况下,插件没能有效地实现失效接管功能。

本文给出了在WAS群集环境中和插件失效接管功能相关的配置参数,并解释这些参数将如何影响插件的行为。

正文:

在群集环境中设置了HTTP插件负责负载均衡后,在有些情况下当某个群集成员失效时,插件不能及时地实现失效接管或者根本无法实现失效接管。在多数情况下,造成这种情况的原因是对HTTP插件工作原理的误解或者不恰当的插件配置。另外,Web服务器是单线程还是多线程也会影响到失效接管的效果。

下面的内容主要是为了帮助用户理解:1HTTP插件的失效接管功能是如何利用某些性能调节参数;2,给用户一些关于这些参数的合理建议值。

注意:下面的内容是是基于IBM HTTP Server(以下简称IHS)完成的。但是,这些信息对于插件支持的常用Web服务器(例如:IIS, SunOne, Domino等)也是有效的。

WAS的群集环境中,当HTTP插件无法将请求发送给某一个群集成员的时候,HTTP插件有提供失效接管的能力。在默认情况下,插件判断某个群集成员宕机并启用失效接管功能将客户端请求发往其他可用服务器的条件有:

● HTTP
插件无法和群集成员的传输端口建立连接。

● HTTP
插件监测到一个刚刚建立的连接在活动期间被群集成员过早地关闭掉

HTTP插件的配置文件plugin-cfg.xml中有一些可调整的参数。通过调整这些参数能够改变HTTP插件判断一个群集成员宕机并启用失效接管功能的快慢。下面就逐一介绍这些参数:

 

●ConnectTimeout
插件文件plugin-cfg.xmlServer元素的属性ConnectTimeout可以使HTTP插件与后端服务器建立非阻塞(non-blocking)连接。非阻塞连接在HTTP插件无法连接到目的地址,无法确定群集成员的传输端口是否可用的情况下,可以缩短等待时间。例如:

<Server CloneID=”10k66djk2″ ConnectTimeout=”10″ ExtendedHandshake=”false” LoadBalanceWeight=”1000″ MaxConnections=”0″ Name=”Server1_WebSphere_Appserver” WaitForContinue=”false”>
<Transport Hostname=”server1.domain.com” Port=”9091″ Protocol=”http”/>
</Server>
如果ConnectTimeout的值没有设定,那么HTTP插件会尝试建立阻塞(blocking)连接。在阻塞连接状态下,当插件无法连接到目的地址的时候,插件会一直等到操作系统的TCP超时发生(不同的操作系统设置不同,一般是在90-120秒)后才会将群集成员标记为宕机。如果ConnectTimeout的值设定为0,那么HTTP插件依旧会建立阻塞(blocking)连接。如果ConnectTimeout的值设定为大于0,那么ConnectTimeout的值代表HTTP插件在成功建立连接前可以等候的秒数。如果过了这一时间间隔后连接没有被建立,那么HTTP插件会将群集成员标记为不可用,并且将请求转发给群集中其他可用的成员。

注意:在某些压力非常大或者网络非常慢的环境中,如果设置ConnectTimeout值过低可能会造成HTTP插件错误地将某个群集成员标记为不可用。

 

●ServerIOTimeout(Solaris平台无效)
HTTP
插件文件plugin-cfg.xmlServer元素的属性ServerIOTimeout使HTTP插件对于从发出请求到接到群集成员响应设置了一个超时值,单位为秒。如果没有为属性ServerIOTimeout设定值,那么HTTP插件默认会使用阻塞(blockedI/O向群集成员写请求和从群集成员读取响应,直到TCP连接超时。例如:

<Server CloneID=”10k66djk2″ ServerIOTimeout=”120″ ConnectTimeout=”10″ ExtendedHandshake=”false” LoadBalanceWeight=”1000″ MaxConnections=”0″ Name=”Server1_WebSphere_Appserver” WaitForContinue=”false”>
<Transport Hostname=”server1.domain.com” Port=”9091″ Protocol=”http”/>
</Server>
在这种情况下,如果群集成员停止响应请求,HTTP插件在结束TCP连接前将等待120秒。设置属性ServerIOTimeout为一个合理的值,能够在群集成员不响应请求的时候使HTTP插件更快地结束连接并将请求转发给其他可用的群集成员。

在给属性ServerIOTimeout设置值的时候,需要注意有的时候群集成员确实需要12分钟的时间处理一个复杂的请求。在这种情况下将属性ServerIOTimeout设置地过低会造成HTTP插件向客户端传送一个服务器不可用的错误信息。

如果在WASHTTP插件之间存在保持活动(keepalive)的连接,当WAS的服务器突然从网络上断开时,属性ServerIOTimeout能够很理想地解决这种情况下的失效接管。例如:当WAS某个群集成员所在的物理机器突然关机,在WASHTTP插件之间保持活动(keepalive)的连接可能没有全部关闭。这样,当HTTP插件需要将一个请求路由到关闭的主机,如果连接池内还存在保持活动(keepalive)的连接,HTTP插件将会使用这种连接。当插件将请求通过这种连接发送出去,由于机器已经宕机,HTTP插件不会接收到任何TCP包。HTTP插件发送的请求不会得到任何错误直到TCP级别的超时发生。接着,HTTP插件将尝试和同一个应用服务器建立新的连接。Connect()方法会在TCP超时后返回错误。这样,在HTTP插件启用失效接管前,花了大量的时间(时间长短依赖于操作系统的TCP超时设定)。如果在此期间有很多请求发送给服务器,那么每一个请求都会发生这种情况。

注意:为了避免这种情况,属性ServerIOTimeout在补丁PQ96015中被引入,这一补丁被包含在5.0.2.105.1.1.4以及以后的版本中。

 

●RetryInterval
属性RetryInterval需要一个自然数值,用以标记从应用服务器被认定为不可用到HTTP插件重新尝试连接服务器之间的时间间隔。默认值为60秒。

HTTP
插件文件plugin-cfg.xmlServerCluster元素包含这一属性,例如:

<ServerCluster CloneSeparatorChange=”false” LoadBalance=”Round Robin”
Name=”Server_WebSphere_Cluster” PostSizeLimit=”10000000″ RemoveSpecialHeaders=”true” RetryInterval=”120″>
上面的设置表明如果一个群集成员被标记为宕机,HTTP插件在120秒之内不会重新尝试连接它。关于这个属性没有一个推荐值,这个值的选取完全依赖于系统的环境。例如:如果系统内有很多群集成员,而且任何一个群集成员不可用都不会影响到应用的性能,那么用户完全可以为属性RetryInterval设置一个很高的值。

相反的,如果系统的最佳负载是在所有群集成员都可用的情况下计算出来的,或者系统没有很多的冗余资源。那么,用户可以希望HTTP插件尽快重新尝试连接群集成员以保证负载。

另外,考虑到重新启动服务器需要花一些时间。如果一个应用服务器需要花很长的时间重新启动和加载应用,那么系统就需要一个比较长的RetryInterval时间。

 

●PrimaryServers VS BackupServers
HTTP
插件可以通过在HTTP插件文件plugin-cfg.xml中使用PrimaryServers & BackupServers元素被配置为真正的失效接管。在下面的例子中,HTTP插件将在所有定义的群集成员Server1_WebSphere_Appserver Server2_WebSphere_Appserver中实现负载均衡。Server1_WebSphere_Appserver Server2_WebSphere_Appserver在元素PrimaryServers中被定义。一旦,Server1_WebSphere_Appserver Server2_WebSphere_Appserver都变为不可用,HTTP插件将向定义在BackupServers元素中的Server3_WebSphere_Appserver发送请求。

 

<ServerCluster CloneSeparatorChange=”false” LoadBalance=”Round Robin”
Name=”Server_WebSphere_Cluster” PostSizeLimit=”10000000″ RemoveSpecialHeaders=”true” RetryInterval=”120″>

<Server CloneID=”10k66djk2″ ServerIOTimeout=”120″ ConnectTimeout=”10″ ExtendedHandshake=”false” LoadBalanceWeight=”1000″ MaxConnections=”0″ Name=”Server1_WebSphere_Appserver” WaitForContinue=”false”>
<Transport Hostname=”server1.domain.com” Port=”9091″ Protocol=”http”/>
</Server>

<Server CloneID=”10k67eta9″ ServerIOTimeout=”120″ ConnectTimeout=”10″ ExtendedHandshake=”false” LoadBalanceWeight=”999″ MaxConnections=”0″ Name=”Server2_WebSphere_Appserver” WaitForContinue=”false”>
<Transport Hostname=”server2.domain.com” Port=”9091″ Protocol=”http”/>
</Server>

<Server CloneID=”10k68xtw10″ ServerIOTimeout=”120″ ConnectTimeout=”10″ ExtendedHandshake=”false” LoadBalanceWeight=”998″ MaxConnections=”0″ Name=”Server3_WebSphere_Appserver” WaitForContinue=”false”>
<Transport Hostname=”server3.domain.com” Port=”9091″ Protocol=”http”/>
</Server>

<PrimaryServers>
<Server Name=”Server1_WebSphere_Appserver”/>
<Server Name=”Server2_WebSphere_Appserver”/>
</PrimaryServers>
<BackupServers>
<Server Name=”Server3_WebSphere_Appserver”/>
</BackupServers>

 

 

参考链接:

http://www-1.ibm.comsupportdocview.wssuid=swg21219808

http://www.redbooks.ibm.com/abstracts/TIPS0240.html?Open

http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21219567

以下文章点击率最高

Loading…


发表评论

电子邮件地址不会被公开。 必填项已用*标注