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…

     

如果這文章對你有幫助,請掃左上角微信支付-支付寶,給於打賞,以助博客運營