王曉紅

（山西工程職業(yè)技術學院，山西 太原030009）

隨著當前信息高速公路的發(fā)展，越來越多的網(wǎng)絡Web系統(tǒng)走入人們的視線.人們對系統(tǒng)性能要求也越來越高，單靠提高服務器單機的物理性能，已經(jīng)很難滿足人們的需要.提高系統(tǒng)的整體性能和吞吐量，已經(jīng)迫在眉睫.集群技術正是在這個時候，以其高的性價比和良好的擴展性，成為人們追逐的目標.利用多臺單機性能一般的主機，組建一個高性能運算整體，大大提高系統(tǒng)性能，這是一個具有創(chuàng)造力的想法.

當前服務器集群通常是指通過高性能的LAN或WAN網(wǎng)絡（同構(gòu)的或異構(gòu)的）相互聯(lián)結(jié)而成的一種服務器體系結(jié)構(gòu).它由一臺前置機（即調(diào)度器，簡稱FE）和若干后臺真實服務器（簡稱BE）構(gòu)成，與分布式系統(tǒng)不同，每個BE服務器，都是一個獨立的處理單元，且具有相同的業(yè)務處理能力.整個集群對于使用方來說，就像是一臺超級計算機，而且該計算機還能在客戶需要的時候，動態(tài)地提高整體性能；當客戶需要訪問集群時，只需要訪問集群對外暴露的虛擬IP地址（即直接訪問前置機），就能達到訪問集群的目的.當客戶的請求到達FE，F(xiàn)E通過采用負載均衡等策略將收到的請求分配給集群中某臺服務器，服務器在業(yè)務處理完畢以后，直接把結(jié)果又返回給前置機，由前置機把處理結(jié)果返回給客戶，這是一個通常意義的集群的傳統(tǒng)做法.

1 TCP協(xié)議遷移集群實現(xiàn)技術

當前服務器集群實現(xiàn)技術，實際上是指集群調(diào)度技術，這里并不是指調(diào)度算法.而是對于連接請求的處理方法:基于DNS的解析技術，基于客戶端技術，基于IP層的調(diào)度技術，基于請求內(nèi)容的調(diào)度技術，基于TCP遷移技術[1].

當前TCP協(xié)議遷移技術主要有3種:第一，基于Netfilter的TCP協(xié)議遷移方法.該方法是基于Linux內(nèi)核的，是一個集抓取、截獲和分析網(wǎng)絡數(shù)據(jù)包為一體的編程框架，通過該框架，可以很容易地修改報文字段.基于該框架的TCP遷移方法有很多，但是最多是利用IP隧道進行協(xié)議遷移，即在客戶與前端服務器完成3次握手以后，再通過隧道方式，在后臺服務器再次建立一個3次握手環(huán)境，從而實現(xiàn)TCP協(xié)議的遷移.但是基于隧道的遷移技術都有一個致命的缺陷，那就是性能.對于客戶而言，建立1次連接，這種類型的集群，卻需要建立至少3次的連接，這還是沒有考慮應用性能和IP隧道建立開銷的情況下[2].第二，基于連接修改和傳遞技術的TCP遷移方法[3].該技術同樣是在客戶與前置機完成3次握手以后，再與后臺服務器遷移進程完成新的連接，利用與后臺服務器的連接傳遞遷移的數(shù)據(jù)結(jié)構(gòu)，最后在后臺服務器上創(chuàng)建新的握手成功的數(shù)據(jù)結(jié)構(gòu).該方法同樣是性能問題.第三，基于重構(gòu)連接現(xiàn)場的TCP遷移方法，該方法是“一步到位”建立連接現(xiàn)場.整個遷移過程，F(xiàn)E和BE之間只有1次報文交換，通訊量極小，效率很高，但是該種原始的遷移技術，僅僅是針對HTTP請求，即僅僅能夠利用在Web服務器集群當中.本文提出的新型TCP遷移技術，也是歸屬于這種技術，通過極小的信息開銷，在后臺服務器端重建連接現(xiàn)場，完成TCP協(xié)議的遷移.

3 新型TCP遷移技術

TCP遷移技術的主要思想是通過對TCP／IP協(xié)議，甚至鏈路層協(xié)議的修改，使客戶端和服務器端已經(jīng)建立的連接發(fā)生遷移，導致請求的路徑不變，回復的來源地址發(fā)生了變化.由于考慮到并不是所有的連接請求都需要遷移，和集群調(diào)度算法的需要，新型TCP遷移技術僅僅對TCP協(xié)議進行擴充，兼容標準TCP協(xié)議，可以根據(jù)集群或應用層面的需求，來決定是否遷移，以及遷移目標地址.這樣，系統(tǒng)實現(xiàn)時，只需要在集群的所有服務器中安裝修改后的TCP／IP協(xié)議包——新型的TCP擴充協(xié)議包，建立相應的 Web或其他應用系統(tǒng)，即就可以完成整體性能提升，這些對于客戶都是透明的，客戶端軟件僅僅需要安裝標準的TCP／IP協(xié)議即可.新型TCP擴充協(xié)議包主要是對TCP連接的3次握手和4次中斷進行了擴充，增加了SYNHANDOFF報文和ASK－HANDOFF報文，以及FIN－HANDOFF報文.

標準的TCP連接3次握手原理如下:

1）請求端（通常稱為客戶），根據(jù)目標指定的IP和端口，發(fā)送SYN報文.報文中比較重要的字段是初始序號.2）服務器端在收到SYN報文后，向客戶端發(fā)送ASK報文，報文中，確認SYN的初始化序號，并帶有自己的初始化序號.3）客戶端在收到服務器端的ASK報文后，回復ASK報文，進行確認，完成3次握手[4].

修改后的集群涉及的TCP連接的3次握手原理如下:

1）客戶端向前置機發(fā)送SYN報文以后，前置機根據(jù)端口號或應用需求確認是否產(chǎn)生是否遷移，如果需要發(fā)生遷移，則立即向后臺真實服務器發(fā)送SYN－HANDOFF報文，該報文實際上是除標準的SYN報文之外，增加了客戶端向前置機發(fā)送SYN的信息字段.2）真實服務器在收到SYN－HANDOFF請求后，除了建立相應的標準連接以外，再根據(jù)信息構(gòu)建連接遷移的結(jié)構(gòu)，即所謂的重構(gòu)連接現(xiàn)場，最后利用標準ASK報文進行回復.3）前置機收到真實服務器的標準ASK報文以后，同樣按照標準ASK報文對客戶進行回復，另外還需要構(gòu)建該遷移連接的上下文環(huán)境.4）客戶端收到標準ASK報文以后，最后發(fā)送標準ASK報文給前置機，完成連接的3次握手，成功創(chuàng)建連接.5）前置機在收到3次握手的確認以后，根據(jù)遷移環(huán)境，決定是否進行遷移行為.發(fā)送ASK－HANDOFF報文，該協(xié)議僅僅在標準的ASK協(xié)議之外，添加了客戶端的ASK的信息字段.6）真實服務器在收到ASK－HANDOFF報文以后，完成與前置機的3次握手，并完成協(xié)議的遷移工作.

標準的TCP連接4次中斷原理:客戶端發(fā)送FIN報文到服務器，服務器收到FIN報文以后，發(fā)送FIN的ASK報文給客戶端，客戶即可完成單方面的連接中斷.

修改后的集群4次中斷原理:1）客戶端發(fā)送標準FIN報文到前置機，前置機收到FIN報文以后，根據(jù)連接的上下文環(huán)境，發(fā)送FASK－HANDOFF報文到后臺真實服務器[5]，如圖1所示.2）后臺真實服務器收到該報文后，即可清除“虛擬的”遷移環(huán)境，并回復標準的ASK報文到前置機.3）后續(xù)連接中斷報文與標準協(xié)議一致，就不再贅述了.

圖1 協(xié)議遷移圖

3 系統(tǒng)實現(xiàn)

本方案的實現(xiàn)方式分為兩大部分，前置機和后臺真實服務器.前置機與后臺真實服務器，在centos6.0的基礎上，卸載了標準TCP協(xié)議模塊，安裝了擴充的TCP協(xié)議模塊.這樣，即可兼容TCP標準協(xié)議，又可對標準協(xié)議進行了補充，不影響系統(tǒng)正常工作.另外，前置機上還安裝了應用層面的軟件模塊，以輔助進行TCP協(xié)議遷移.前置機主要包括四部分:系統(tǒng)管理、資源收集、調(diào)度模塊、遷移模塊.4個模塊相輔相成，能夠更好地提高集群的性能.信息模塊，主要對外提供統(tǒng)一、安全的管理接口，因為并不是所有的連接請求或數(shù)據(jù)請求，都需要進行TCP遷移，必須按照一定的管理或配置策略進行協(xié)議遷移，只有這樣才能最大程度上發(fā)揮集群的作用，最大限度上提高集群的性能，最小限度地不影響系統(tǒng)其他正常的工作.比如，有那些物理設備是真實服務器，是為了準備協(xié)議遷移的；哪些連接是完全沒有必要遷移的；服務器調(diào)度算法是怎樣的？遷移日志保存情況如何？在什么情況下，才進行數(shù)據(jù)遷移.雖然遷移的代價已經(jīng)大大減少，但是畢竟要多一部分的性能消耗，因此在訪問量比較小或載荷不高的情況，完全沒有必要進行協(xié)議遷移，如果強制性地進行遷移，反而會降低整體性能.這些問題都是需要通過系統(tǒng)對外暴露API或管理界面進行配置.資源收集模塊，該模塊主要是負責及時主動或被動獲取或接收真實服務器所反饋的每臺機子當前運行的資源信息狀況，為調(diào)度模塊計算數(shù)據(jù)，提供強大的計算依據(jù).調(diào)度模塊，主要是依據(jù)資源收集模塊提供的當前所有真實服務器的運行狀況和網(wǎng)絡狀況，進行調(diào)度策略計算，得出結(jié)果.遷移模塊，主要根據(jù)擴充的TCP協(xié)議進行協(xié)議遷移，或稱之為真實服務器上的協(xié)議重構(gòu).真實服務器上除了安裝擴充的TCP協(xié)議模塊以外，還安裝了資源共享模塊，用于前置機了解每臺真實服務器的物理機子運行狀態(tài)，例如:CPU占用率、內(nèi)存占用量、某個進程線程運行數(shù)量等等.

系統(tǒng)整個運行流程是怎樣的？首先連接請求來源于互聯(lián)網(wǎng)，通過路由器，發(fā)送給集群前置機，當前的前置機已經(jīng)通過系統(tǒng)管理對遷移進行了系統(tǒng)配置，比如:假設集群服務器的端口在80端口，可以配置，前置機的CPU占用率超過30%以后，通過80端口建立的所有連接都進行協(xié)議遷移，否則，僅僅進行基于IP層面上的調(diào)度，即NAT轉(zhuǎn)換技術.另外在發(fā)起TCP遷移之前，系統(tǒng)還要根據(jù)得到的信息，進行調(diào)度，確定遷移的地址.在客戶完成3次握手之后，相應的某臺真實服務器上會建立“虛擬連接終端”，當具體應用請求到路由器之后，則又由路由器轉(zhuǎn)發(fā)給前置機，前置機根據(jù)3次握手建立的上下文環(huán)境，確定轉(zhuǎn)發(fā)的目標，真實服務器收到該請求以后，完成業(yè)務處理，并利用本機建立的“虛擬連接終端”，回復路由器數(shù)據(jù)，從而完成整個數(shù)據(jù)接收和回復過程，在應用數(shù)據(jù)的回復過程中，沒有前置機的參與，減少了前置機的開銷.

4 性能測試和結(jié)果分析

＊ 硬件配置:

前置機1臺，真實服務器2臺，均采用

CPU:AMD Athlon（tm）64X2Dual Core Processor5400＋ CPU

內(nèi)存:2G內(nèi)存

＊ 軟件配置:

Centos6.0系統(tǒng)

＊ 網(wǎng)絡架構(gòu):

將3臺電腦（1臺前置機，2臺真實服務器）后臺真實服務器構(gòu)建成為一個局域網(wǎng)，并通過路由器與客戶端相連.

客戶端IP地址:192.168.10.1

前置機IP地址:192.168.20.129，

真實服務器1IP地址:192.168.20.159

真實服務器2IP地址:192.168.20.189

＊ 測試方法和結(jié)果分析:

編寫TCP客戶端，進行多線程測試.每個線程執(zhí)行邏輯為:首先發(fā)起連接，然后發(fā)送1次固定長度數(shù)據(jù)，再接收固定長度數(shù)據(jù)，最后中斷連接.通過在遷移和不遷移的2種情況下橫向測試比較，發(fā)現(xiàn)在線程并發(fā)數(shù)超過45的情況下，遷移以后的系統(tǒng)性能優(yōu)于不遷移的系統(tǒng)，即遷移后系統(tǒng)一個線程完成一次測試邏輯的平均時間要小于不遷移系統(tǒng).但是在測試線程數(shù)少于45的情況下，不進行協(xié)議遷移系統(tǒng)占優(yōu).結(jié)果證明，TCP協(xié)議遷移在服務器任務繁重的情況下，可以大大提高服務器性能和吞吐量，但在任務輕松的情況下，反應不好，估計是由于系統(tǒng)管理等應用級別的模塊存在，降低了系統(tǒng)性能，另外遷移產(chǎn)生的額外開銷也是問題的原因之一.另外，也證明了論文中提及的一個觀點，TCP協(xié)議遷移無論怎樣減少遷移開銷，都會產(chǎn)生一定的負載.隨著實際運行環(huán)境中，連接頻繁增加和中斷，這種開銷也會逐漸增加，當后臺真實服務器將真實數(shù)據(jù)直接回復給路由器時，帶來的性能提升大于協(xié)議遷移帶來的性能開銷時，這種遷移開銷才能帶來真正的價值，否則，TCP遷移只能是服務器新的負擔.針對這種情況，系統(tǒng)設計了系統(tǒng)管理模塊，該模塊可以設定遷移的策略，從而減少遷移成為負擔的現(xiàn)象.但是此次測試，本系統(tǒng)的調(diào)度算法僅僅是根據(jù)主機CPU占用率來進行調(diào)度，無法真實反映某個進程的執(zhí)行情況，更無法充分發(fā)揮2種技術共存的系統(tǒng)中，遷移和不遷移2種集群技術的優(yōu)勢，還有待于下一步改進.另外，由于調(diào)度算法的依據(jù)來源于后臺真實數(shù)據(jù)服務器的反饋，因此有一定的延遲，如果出現(xiàn)爆發(fā)性的數(shù)據(jù)請求，后臺真實服務器很可能出現(xiàn)忙和閑的2種狀況.因此在TCP遷移解決前置機的性能瓶頸之外，還可以對真實服務器正在處理的任務，或尚未處理的任務，進行任務遷移，要求其他閑機子進行協(xié)助運算.

5 結(jié)束語

本文詳細描述了基于TCP遷移技術的多種集群實現(xiàn)方案，在進行分析后，提出了基于新型TCP遷移方法的集群實現(xiàn)方案，并通過測試證明，該方案是TCP遷移和不遷移技術的最佳結(jié)合，能夠使集群無論在那種環(huán)境下，都能夠發(fā)揮最大的性能.

[1]楊 兵，黃遵國，胡光明.基于高可用性的動態(tài)漂移技術研究[J]，計算機工程與科學，2004，26（3）:4－6

[2]Pai V，Arom M，Banga G，et al.Locality 2aware request distribution in cluster 2based network server[A].Proc of the 8th Int’lConf on architectural support for programming languages and operating systems[C].1998:205－216

[3]X Zhang，M Barrientos，J Chen，et al.HACC:An architecturefor cluster 2based web servers[A].Proc of the 3rd USENIX Windows NT Symp[C].1999

[4]R S Engelschall.Load balancing your web site[J].WEB Techniques Magazines，1998，3（5）:48－50