【正文】 的總數(shù)調(diào)度器中所有并發(fā)連接的數(shù)目每個(gè)虛擬服務(wù)處理連接的總數(shù)每個(gè)服務(wù)器所有并發(fā)連接的數(shù)目連接處理速率：在單位時(shí)間內(nèi)，我們可以根據(jù)調(diào)度器所處理報(bào)文總數(shù)之差得出調(diào)度器的報(bào)文處理速率，根據(jù)調(diào)度器所處理連接總數(shù)之差得出調(diào)度器的連接處理速率。同樣，我們可以算出每個(gè)虛擬服務(wù)的連接處理速率。 防衛(wèi)策略IPVS調(diào)度器本身可以利用Linux內(nèi)核報(bào)文過濾功能設(shè)置成一個(gè)防火墻，只許可虛擬服務(wù)的報(bào)文進(jìn)入，丟掉其他報(bào)文。調(diào)度器的脆弱之處在于它需要記錄每個(gè)連接的狀態(tài)，每個(gè)連接需要占用128個(gè)字節(jié)，一些惡意攻擊可能使得調(diào)度器生成越來越多的并發(fā)連接，直到所有的內(nèi)存耗盡，系統(tǒng)出現(xiàn)拒絕服務(wù)（DenialofService）。但是，一般SYNFlooding攻擊調(diào)度器是非常困難的，假設(shè)系統(tǒng)有128Mbytes可用內(nèi)存，則系統(tǒng)可以容納一百萬個(gè)并發(fā)連接，每個(gè)處理接受SYN連接的超時(shí)（Timeout）為60秒，SYNFlooding主機(jī)需要生成16,666Packets/Second的流量，這往往需要分布式SYNFlooding工具，由許多個(gè)SYNFlooding主機(jī)同時(shí)來攻擊調(diào)度器。為了避免此類大規(guī)模的惡意攻擊，我們在調(diào)度器中實(shí)現(xiàn)三種針對DoS攻擊的防衛(wèi)策略。它們是
隨機(jī)丟掉連接、在調(diào)度報(bào)文前丟掉1/rate的報(bào)文、使用更安全的TCP狀態(tài)轉(zhuǎn)換和更短的超時(shí)。在系統(tǒng)中有三個(gè)開關(guān)分別控制它們，開關(guān)處于0表示該功能完全關(guān)掉。1和2表示自動(dòng)狀態(tài)，當(dāng)系統(tǒng)的有效內(nèi)存低于設(shè)置的閥值時(shí)，該防衛(wèi)策略被激活，開關(guān)從1狀態(tài)遷移到2狀態(tài)；當(dāng)系統(tǒng)的有效內(nèi)存高于設(shè)置的閥值時(shí)，該防衛(wèi)策略被關(guān)掉，開關(guān)從2狀態(tài)遷移到1狀態(tài)。3表示該策略永遠(yuǎn)被激活。 調(diào)度器間的狀態(tài)同步盡管IPVS虛擬服務(wù)器軟件已被證明相當(dāng)魯棒，但調(diào)度器有可能因?yàn)槠渌蚨?，如機(jī)器的硬件故障和網(wǎng)絡(luò)線路故障等。所以，我們引入一個(gè)從調(diào)度器作為主調(diào)度器的備份，當(dāng)主調(diào)度器失效時(shí)，從調(diào)度器將接管VIP等地址進(jìn)行負(fù)載均衡調(diào)度。在現(xiàn)在的解決方案中，當(dāng)主調(diào)度器失效時(shí)，調(diào)度器上所有已建立連接的狀態(tài)信息將丟失，已有的連接會中斷，客戶需要向重新連接，從調(diào)度器才會將新連接調(diào)度到各個(gè)服務(wù)器上。這對客戶會造成一定的不便。為此，我們考慮一種高效機(jī)制將主調(diào)度器的狀態(tài)信息及時(shí)地復(fù)制到從調(diào)度器，當(dāng)從調(diào)度器接管時(shí)，絕大部分已建立的連接會持續(xù)下去。因?yàn)檎{(diào)度器的連接吞吐率是非常高的，如每秒處理一萬多個(gè)連接，如何將這些變化非?？斓臓顟B(tài)信息高效地復(fù)制到另一臺服務(wù)器？我們設(shè)計(jì)利用內(nèi)核線程實(shí)現(xiàn)主從同步進(jìn)程，在操作系統(tǒng)的
內(nèi)核中，直接將狀態(tài)信息發(fā)送到從調(diào)度器上，可以避免用戶空間和核心的切換開銷。其結(jié)構(gòu)如圖所示在主從調(diào)度器的操作系統(tǒng)內(nèi)核中分別有兩個(gè)內(nèi)核線程ConnSyncd，主調(diào)度器上的ConnSyncd每隔1/10秒鐘喚醒一次從更新隊(duì)列中將更新信息讀出，將更新信息發(fā)給從調(diào)度器上的ConnSyncd，然后在從調(diào)度器內(nèi)核中生成相應(yīng)的狀態(tài)信息。為了減少主從調(diào)度器間的通訊開銷，在主調(diào)度器的更新隊(duì)列中只放新連接生成的信息，在從調(diào)度器中生成連接信息，設(shè)置定時(shí)器，當(dāng)連接超時(shí)，該連接會自動(dòng)被刪除。主從調(diào)度器間狀態(tài)復(fù)制的代碼正在編寫中。因?yàn)橹鲝恼{(diào)度器間的狀態(tài)復(fù)制會降低調(diào)度器的吞吐率，所以主從調(diào)度器間狀態(tài)復(fù)制會以模塊的形式出現(xiàn)，當(dāng)用戶特別需要時(shí)，可以將該模塊加入內(nèi)核中。 內(nèi)核中基于內(nèi)容的請求分發(fā)KTCPVSIPVS基本上是一種高效的Layer4交換機(jī)，它提供負(fù)載平衡的功能。當(dāng)一個(gè)TCP連接的初始SYN
報(bào)文到達(dá)時(shí)，IPVS就選擇一臺服務(wù)器，將報(bào)文轉(zhuǎn)發(fā)給它。此后通過查發(fā)報(bào)文的IP和TCP報(bào)文頭地址，保證此連接的后繼報(bào)文被轉(zhuǎn)發(fā)到相同的服務(wù)器。這樣，IPVS無法檢查到請求的內(nèi)容再選擇服務(wù)器，這就要求后端的服務(wù)器組是提供相同的服務(wù)，不管請求被送到哪一臺服務(wù)器，返回結(jié)果都應(yīng)該是一樣的。但是在有一些應(yīng)用中后端的服務(wù)器可能功能不一，有的是提供HTML文檔的Web服務(wù)器，有的是提供圖片的Web服務(wù)器，有的是提供CGI的Web服務(wù)器。這時(shí)，就需要基于內(nèi)容請求分發(fā)(ContentBasedRequestDistribution)，同時(shí)基于內(nèi)容請求分發(fā)可以提高后端服務(wù)器上訪問的局部性。由于用戶空間TCPGateway的開銷太大，導(dǎo)致其伸縮能力有限。為此，我們提出在操作系統(tǒng)的內(nèi)核中實(shí)現(xiàn)Layer7交換方法，來避免用戶空間與核心空間的切換開銷和內(nèi)存復(fù)制的開銷。在Linux操作系統(tǒng)的內(nèi)核中，我們實(shí)現(xiàn)了Layer7交換，稱之為KTCPVS（KernelTCPVirtualServer）。以下幾小節(jié)將介紹KTCPVS的體系結(jié)構(gòu)、實(shí)現(xiàn)方法、負(fù)載平衡和高可用特征等。 什么是基于內(nèi)容的請求分發(fā)根據(jù)應(yīng)用層（Layer7）的信息調(diào)度TCP負(fù)載不是很容易實(shí)現(xiàn)，對于所有的TCP服務(wù)，應(yīng)用層信
息必須等到TCP連接建立（三次握手協(xié)議）以后才能獲得。這就說明連接不能用Layer4交換機(jī)收到一個(gè)SYN報(bào)文時(shí)進(jìn)行調(diào)度。來自客戶的TCP連接必須在交換機(jī)上被接受，建立在客戶與交換機(jī)之間TCP連接，來獲得應(yīng)用的請求信息。一旦獲得請求信息，分析其內(nèi)容來決定哪一個(gè)后端服務(wù)器來處理，再將請求調(diào)度到該服務(wù)器?，F(xiàn)有兩種方法實(shí)現(xiàn)基于內(nèi)容的調(diào)度。一種是TCP網(wǎng)關(guān)（TCPGateway），交換機(jī)建立一個(gè)到后端服務(wù)器的TCP連接，將客戶請求通過這個(gè)連接發(fā)到服務(wù)器，服務(wù)器將響應(yīng)結(jié)果通過該連接返回到交換機(jī)，交換機(jī)再將結(jié)果通過客戶到交換機(jī)的連接返回給客戶。另一種是TCP遷移（TCP Migration），將客戶到交換機(jī)TCP連接的交換機(jī)端遷移到服務(wù)器，這樣客戶與服務(wù)器就可以建立直接的TCP連接，但請求報(bào)文還需要經(jīng)過交換機(jī)調(diào)度到服務(wù)器，響應(yīng)報(bào)文直接返回給客戶。就我們所知，Resonate實(shí)現(xiàn)了TCP遷移方法，他們稱之為TCP連接跳動(dòng)（TCPConnectionHop），他們的軟件是專有的。TCP遷移需要修改交換機(jī)的TCP/IP協(xié)議棧，同時(shí)需要修改所有后端服務(wù)器的TCP/IP協(xié)議棧，才能實(shí)現(xiàn)將TCP連接的一端從一臺機(jī)器及其遷移到另一臺上。Rice大學(xué)和IBM的研究人員簡要地描述了它們的TCPHandoffProtocol，在交換機(jī)和后端服務(wù)器上安裝TCPHandoff協(xié)議，交換機(jī)獲得客戶請求后，通過TCPHandoff協(xié)議將TCP連接的交換機(jī)端轉(zhuǎn)給后端服務(wù)器。但是，他們沒有提供任何其他文檔或研究報(bào)告描述他們的TCPHandoff協(xié)議和實(shí)現(xiàn)。他們提出的提高局部性調(diào)度算法LARD只考慮靜態(tài)文檔。雖然在交換機(jī)獲得客戶請求后，TCP遷移方法比較高效，但是該方法實(shí)現(xiàn)工作量大，要修改交換機(jī)和后端服務(wù)器的操作系統(tǒng)，不具有一般性。因此，TCP網(wǎng)關(guān)方法被絕大部分Layer7交換的商業(yè)產(chǎn)品和自由軟件所使用，如ArrowPoint的CS100和CS800Web交換機(jī)（WebSwitch）、Zeus負(fù)載調(diào)度器、愛立信實(shí)驗(yàn)室的EDDIE、自由軟件Apache和Squid等。TCP網(wǎng)關(guān)方法不需要更改服務(wù)器的操作系統(tǒng)，服務(wù)器只要支持TCP/IP即可，它具有很好的通用性。但是，TCP網(wǎng)關(guān)一般都是在用戶空間實(shí)現(xiàn)的，其處理開銷比較大，如圖：用戶空間的TCPGateway
從圖中我們可以看出，對于任一TCP請求，客戶將請求發(fā)到交換機(jī)，計(jì)算機(jī)將請求報(bào)文從內(nèi)核傳給用戶空間的Layer7交換程序，Layer7交換程序根據(jù)請求選出服務(wù)器，再建一個(gè)TCP連接將請求發(fā)給服務(wù)器，返回的響應(yīng)報(bào)文必須先由內(nèi)核傳給用戶空間的Layer7交換程序，再由Layer7交換程序通過內(nèi)核將結(jié)果返回給客戶。對于一個(gè)請求報(bào)文和對應(yīng)的響應(yīng)報(bào)文，都需要四次內(nèi)核與用戶空間的切換，切換和內(nèi)存復(fù)制的開銷是非常高的，所以用戶空間TCPGateway的伸縮能力很有限，一般來說一個(gè)用戶空間TCPGateway只能調(diào)度三、四臺服務(wù)器，當(dāng)連接的速率到達(dá)每秒1000個(gè)連接時(shí)，TCPGateway本身會成為瓶頸。所以，在ArrowPoint的CS800Web交換機(jī)中集成了多個(gè)TCPGateway。雖然Layer7交換比Layer4交換處理復(fù)雜，但Layer7交換帶來以下好處：相同頁面的請求被發(fā)送到同一臺的服務(wù)器，所請求的頁面很有可能會被服務(wù)器緩存，可以提高單臺服務(wù)器的主存Cache使用效率。一些研究表明WEB訪問流中存在空間的局部性。Layer7交換可以充分利用訪問的局部性，將相同類型的請求發(fā)送到同一臺服務(wù)器，使得每個(gè)后端服務(wù)器收到的請求相似性好，有利于進(jìn)一步提高單臺服務(wù)器的主存Cache使用效率，從而在有限的硬件配置下提高系統(tǒng)的整體性能。 KTCPVS的體系結(jié)構(gòu)KTCPVS集群的體系結(jié)構(gòu)如圖所示：它主要由兩個(gè)組成部分，一是KTCPVS交換機(jī)，根據(jù)內(nèi)容不同將請求發(fā)送到不同的服務(wù)器上；二是后端服務(wù)器，可運(yùn)行不同的網(wǎng)絡(luò)服務(wù)。KTCPVS交換機(jī)和后端服務(wù)器通過LAN/WAN互聯(lián)。KTCPVS交換機(jī)能進(jìn)行根據(jù)內(nèi)容的調(diào)度，將不同類型的請求發(fā)送到不同的后端服務(wù)器，再將結(jié)果返回給客戶，后端服務(wù)器對客戶是不可見的。所以，KTCPVS集群的結(jié)構(gòu)對客戶是透明的，客戶訪問集群提供的網(wǎng)絡(luò)服務(wù)就像訪問一臺高性能、高可用的服務(wù)器一樣，故我們也稱之為虛擬服務(wù)器?？蛻舫绦虿皇芊?wù)器集群的影響不需作任何修改。 KTCPVS實(shí)現(xiàn)，我們用內(nèi)核線程（Kernelthread）實(shí)現(xiàn)Layer7交換服務(wù)程序，并把所有的程序封裝在可裝卸的KTCPVS模塊。KTCPVS的主要功能模塊如圖所示：KTCPVS系統(tǒng)的主要功能模塊當(dāng)KTCPVS模塊被加載到內(nèi)核中時(shí)，KTCPVS主內(nèi)核線程被激活，并在/proc文件系統(tǒng)和setsockopt上掛接KTCPVS的內(nèi)核控制程序，用戶空間的管理程序tcpvsadm通過setsockopt函數(shù)來設(shè)置KTCPVS服務(wù)器的規(guī)則，通過/proc文件系統(tǒng)把KTCPVS服務(wù)器的規(guī)則讀出?；趦?nèi)容調(diào)度的模塊被做成可裝卸的模塊（LoadableModule），不同的網(wǎng)絡(luò)服務(wù)可以使用不同的基于內(nèi)容調(diào)度模塊，如HTTP和RTSP等。另外，系統(tǒng)的結(jié)構(gòu)靈活，用戶也可以為自己不同類型的網(wǎng)絡(luò)服務(wù)編寫相應(yīng)的模塊?？梢酝ㄟ^tcpvsadm命令使得KTCPVS主線程生成多個(gè)子線程監(jiān)聽在某個(gè)端口。這組子線程可以接受來自客戶的請求，通過與其綁定的基于內(nèi)容的調(diào)度模塊獲得能處理當(dāng)前請求的服務(wù)器，并建立一個(gè)TCP連接到該服務(wù)器，將請求發(fā)到服務(wù)器；子線程獲得來自服務(wù)器的響應(yīng)結(jié)果后，再將結(jié)果返回給客戶。所有的請求和響應(yīng)數(shù)據(jù)處理都是在操作系統(tǒng)的內(nèi)核中進(jìn)行的，所以沒有用戶空間與核心空間的切換開銷和內(nèi)存復(fù)制的開銷，其處理開銷比用戶空間的TCPGateway小很多。 KTCPVS高可用性KTCPVS集群系統(tǒng)的高可用性可分為二部分達(dá)到，一是服務(wù)器故障處理，二是KTCPVS調(diào)度器故障處理。在服務(wù)器故障處理上，我們可以一種或者組合多種方法來檢測服務(wù)器或者網(wǎng)絡(luò)服務(wù)是否可用。例如，一是資源監(jiān)測器每隔t個(gè)毫秒對每個(gè)服務(wù)器發(fā)ARP（AddressResolveProtocol）請求，若有服務(wù)器過了r毫秒沒有響應(yīng)，則說明該服務(wù)器已發(fā)生故障，資源監(jiān)測器通知調(diào)度器將該服務(wù)器的所有服務(wù)進(jìn)程調(diào)度從調(diào)度列表中刪除。二是資源監(jiān)測器定時(shí)地向每個(gè)服務(wù)進(jìn)程發(fā)請求，若不能返回結(jié)果則說明該服務(wù)進(jìn)程發(fā)生故障，資源監(jiān)測器通知調(diào)度器將該服務(wù)進(jìn)程調(diào)度從KTCPVS調(diào)度列表中刪除。資源監(jiān)測器能通過電子郵件或傳呼機(jī)向管理員報(bào)告故障，一旦監(jiān)測到服務(wù)進(jìn)程恢復(fù)工作，通知調(diào)度器將其加入調(diào)度列表進(jìn)行調(diào)度。通過檢測節(jié)點(diǎn)或服務(wù)進(jìn)程故障和正確地重置系統(tǒng)，可以將部分結(jié)點(diǎn)或軟件故障對用戶屏蔽掉，從而實(shí)現(xiàn)系統(tǒng)的高可用性。在KTCPVS調(diào)度器故障處理上，跟IPVS調(diào)度器故障處理類似，通過心跳或者VRRP來實(shí)現(xiàn)。 KTCPVS的負(fù)載均衡調(diào)度KTCPVS的負(fù)載均衡調(diào)度是以TCP連接為粒度的。同一用戶的不同連接可能會被調(diào)度到不同的服務(wù)器上，所以這種細(xì)粒度的調(diào)度可避免不同用戶的訪問差異引起服務(wù)器間的負(fù)載不平衡。在調(diào)度算法上，我們先實(shí)現(xiàn)了加權(quán)最小連接調(diào)度（WeightedLeastConnectionScheduling），因?yàn)樵撍惴ǘ驾^容易實(shí)現(xiàn)，便于調(diào)試和測試。另外，KTCPVS交換機(jī)網(wǎng)絡(luò)配置比Layer4交換機(jī)的簡單，KTCPVS交換機(jī)和服務(wù)器只要有網(wǎng)絡(luò)相連，能進(jìn)行TCP/IP通訊即可，安裝使用比較方便，所以在整個(gè)系統(tǒng)規(guī)模不大（例如不超過10個(gè)結(jié)點(diǎn)）且結(jié)點(diǎn)提供的服務(wù)相同時(shí)，可以利用以上算法來調(diào)度這些服務(wù)器，KTCPVS交換機(jī)仍是不錯(cuò)的選擇。同時(shí)，在實(shí)際的性能測試中，這些調(diào)度算法可以用作比較。我們給出基于局部性的最小連接調(diào)度（LocalityBasedLeastConnectionScheduling）和基于內(nèi)容的調(diào)度（ContentbasedScheduling）算法?；诰植啃缘淖钚∵B接調(diào)度是假設(shè)后端服務(wù)器都是相同的，在后端服務(wù)器的負(fù)載基本平衡情況下，盡可能將相同的請求分到同一臺服務(wù)器，以提高后端服務(wù)器的訪問局部性，從而提高后端服務(wù)器的Cache命中率?；趦?nèi)容的調(diào)度是考慮后端服務(wù)器不相同時(shí)，若同一類型的請求有多個(gè)服務(wù)器可以選擇時(shí)，將請求負(fù)載均衡地調(diào)度到這些服
務(wù)器上。216。 加權(quán)最小連接調(diào)度216。 基于局部性的最小連接調(diào)度216。 基于內(nèi)容的調(diào)度 LVS安裝配置詳解 安裝LVS和配置LVS的工作比較繁雜，讀者在配置的過程中需要非常細(xì)心和耐心。主要包括如下幾個(gè)核心步驟： 獲取支持LVS的內(nèi)核源代碼如果讀者需要使用LVS。下載地址為。目前主流的Linux內(nèi)核已經(jīng)支持LVS，只需要直接使用，不需要進(jìn)行內(nèi)核的下載和更新工作。
用戶配置工具ipvsadm該軟件的下載地址為：。 下載軟件wget 解壓縮tar zxvf cd 建立編譯時(shí)必須的一個(gè)軟鏈接ln s/usr/src/kernels/編譯安裝make amp。amp。 make install確認(rèn)安裝成功whereis ipvsadm to/usr/include/net下 cp libipvs/ s/usr/src/kernels/： INCLUDE = I/usr/src/linux/include I..I.