用負載均衡技術(shù)建設高負載站點

　Internet的快速增長使多媒體網(wǎng)絡服務器，特別是Web服務器，面對的訪問者數(shù)量快速增加，網(wǎng)絡服務器需要具備提供大量并發(fā)訪問服務的能力。例如Yahoo每天會收到數(shù)百萬次的訪問請求，因此對于提供大負載Web服務的服務器來講，CPU、I/O處理能力很快會成為瓶頸。

　　簡單的提高硬件性能并不能真正解決這個問題，因為單臺服務器的性能總是有限的，一般來講，一臺PC服務器所能提供的并發(fā)訪問處理能力大約為1000個，更為高檔的專用服務器能夠支持3000-5000個并發(fā)訪問，這樣的能力還是無法滿足負載較大的網(wǎng)站的要求。尤其是網(wǎng)絡請求具有突發(fā)性，當某些重大事件發(fā)生時，網(wǎng)絡訪問就會急劇上升，從而造成網(wǎng)絡瓶頸，例如在網(wǎng)上發(fā)布的克林頓彈劾書就是很明顯的例子。必須采用多臺服務器提供網(wǎng)絡服務，并將網(wǎng)絡請求分配給這些服務器分擔，才能提供處理大量并發(fā)服務的能力。

　　當使用多臺服務器來分擔負載的時候，最簡單的辦法是將不同的服務器用在不同的方面。按提供的內(nèi)容進行分割時，可以將一臺服務器用于提供新聞頁面，而另一臺用于提供游戲頁面；或者可以按服務器的功能進行分割，將一臺服務器用于提供靜態(tài)頁面訪問，而另一些用于提供CGI等需要大量消耗資源的動態(tài)頁面訪問。然而由于網(wǎng)絡訪問的突發(fā)性，使得很難確定那些頁面造成的負載太大，如果將服務的頁面分割的過細就會造成很大浪費。事實上造成負載過大的頁面常常是在變化中的，如果要經(jīng)常按照負載變化來調(diào)整頁面所在的服務器，那么勢必對管理和維護造成極大的問題。因此這種分割方法只能是大方向的調(diào)整，對于大負載的網(wǎng)站，根本的解決辦法還需要應用負載均衡技術(shù)。

　　負載均衡的思路下多臺服務器為對稱方式，每臺服務器都具備等價的地位，都可以單獨對外提供服務而無須其他服務器的輔助。然后通過某種負載分擔技術(shù)，將外部發(fā)送來的請求均勻分配到對稱結(jié)構(gòu)中的某一臺服務器上，而接收到請求的服務器都獨立回應客戶機的請求。由于建立內(nèi)容完全一致的Web服務器并不復雜，可以使用服務器同步更新或者共享存儲空間等方法來完成，因此負載均衡技術(shù)就成為建立一個高負載Web站點的關鍵性技術(shù)。

　　基于特定服務器軟件的負載均衡

　　很多網(wǎng)絡協(xié)議都支持“重定向”功能，例如在HTTP協(xié)議中支持Location指令，接收到這個指令的瀏覽器將自動重定向到Location指明的另一個URL上。由于發(fā)送Location指令比起執(zhí)行服務請求，對Web服務器的負載要小的多，因此可以根據(jù)這個功能來設計一種負載均衡的服務器。任何時候Web服務器認為自己負載較大的時候，它就不再直接發(fā)送回瀏覽器請求的網(wǎng)頁，而是送回一個Locaction指令，讓瀏覽器去服務器集群中的其他服務器上獲得所需要的網(wǎng)頁。

　　在這種方式下，服務器本身必須支持這種功能，然而具體實現(xiàn)起來卻有很多困難，例如一臺服務器如何能保證它重定向過的服務器是比較空閑的，并且不會再次發(fā)送Location指令？Location指令和瀏覽器都沒有這方面的支持能力，這樣很容易在瀏覽器上形成一種死循環(huán)。因此這種方式實際應用當中并不多見，使用這種方式實現(xiàn)的服務器集群軟件也較少。有些特定情況下可以使用CGI（包括使用FastCGI或mod_perl擴展來改善性能）來模擬這種方式去分擔負載，而Web服務器仍然保持簡潔、高效的特性，此時避免Location循環(huán)的任務將由用戶的CGI程序來承擔。

　　基于DNS的負載均衡

　　由于基于服務器軟件的負載均衡需要改動軟件，因此常常是得不償失，負載均衡最好是在服務器軟件之外來完成，這樣才能利用現(xiàn)有服務器軟件的種種優(yōu)勢。最早的負載均衡技術(shù)是通過DNS服務中的隨機名字解析來實現(xiàn)的，在DNS服務器中，可以為多個不同的地址配置同一個名字，而最終查詢這個名字的客戶機將在解析這個名字時得到其中的一個地址。因此，對于同一個名字，不同的客戶機會得到不同的地址，他們也就訪問不同地址上的Web服務器，從而達到負載均衡的目的。

　　例如如果希望使用三個Web服務器來回應對www.exampleorg.org.cn的HTTP請求，就可以設置該域的DNS服務器中關于該域的數(shù)據(jù)包括有與下面例子類似的結(jié)果：

　　www1 IN A 192.168.1.1
　　www2 IN A 192.168.1.2
　　www3 IN A 192.168.1.3
　　www IN CNAME www1
　　www IN CNAME www2
　　www IN CNAME www3

　　此后外部的客戶機就可能隨機的得到對應www的不同地址，那么隨后的HTTP請求也就發(fā)送給不同地址了。

　　DNS負載均衡的優(yōu)點是簡單、易行，并且服務器可以位于互聯(lián)網(wǎng)的任意位置上，當前使用在包括Yahoo在內(nèi)的Web站點上。然而它也存在不少缺點，一個缺點是為了保證DNS數(shù)據(jù)及時更新，一般都要將DNS的刷新時間設置的較小，但太小就會造成太大的額外網(wǎng)絡流量，并且更改了DNS數(shù)據(jù)之后也不能立即生效；第二點是DNS負載均衡無法得知服務器之間的差異，它不能做到為性能較好的服務器多分配請求，也不能了解到服務器的當前狀態(tài)，甚至會出現(xiàn)客戶請求集中在某一臺服務器上的偶然情況。

　　反向代理負載均衡

　　使用代理服務器可以將請求轉(zhuǎn)發(fā)給內(nèi)部的Web服務器，使用這種加速模式顯然可以提升靜態(tài)網(wǎng)頁的訪問速度。因此也可以考慮使用這種技術(shù)，讓代理服務器將請求均勻轉(zhuǎn)發(fā)給多臺內(nèi)部Web服務器之一上，從而達到負載均衡的目的。這種代理方式與普通的代理方式有所不同，標準代理方式是客戶使用代理訪問多個外部Web服務器，而這種代理方式是多個客戶使用它訪問內(nèi)部Web服務器，因此也被稱為反向代理模式。

　　實現(xiàn)這個反向代理能力并不能算是一個特別復雜的任務，但是在負載均衡中要求特別高的效率，這樣實現(xiàn)起來就不是十分簡單的了。每針對一次代理，代理服務器就必須打開兩個連接，一個為對外的連接，一個為對內(nèi)的連接，因此對于連接請求數(shù)量非常大的時候，代理服務器的負載也就非常之大了，在最后反向代理服務器會成為服務的瓶頸。例如，使用Apache的mod_rproxy模塊來實現(xiàn)負載均衡功能時，提供的并發(fā)連接數(shù)量受Apache本身的并發(fā)連接數(shù)量的限制。一般來講，可以使用它來對連接數(shù)量不是特別大，但每次連接都需要消耗大量處理資源的站點進行負載均衡，例如搜尋。

　　使用反向代理的好處是，可以將負載均衡和代理服務器的高速緩存技術(shù)結(jié)合在一起，提供有益的性能，具備額外的安全性，外部客戶不能直接訪問真實的服務器。并且實現(xiàn)起來可以實現(xiàn)較好的負載均衡策略，將負載可以非常均衡的分給內(nèi)部服務器，不會出現(xiàn)負載集中到某個服務器的偶然現(xiàn)象。

　　基于NAT的負載均衡技術(shù)

　　網(wǎng)絡地址轉(zhuǎn)換為在內(nèi)部地址和外部地址之間進行轉(zhuǎn)換，以便具備內(nèi)部地址的計算機能訪問外部網(wǎng)絡，而當外部網(wǎng)絡中的計算機訪問地址轉(zhuǎn)換網(wǎng)關擁有的某一外部地址時，地址轉(zhuǎn)換網(wǎng)關能將其轉(zhuǎn)發(fā)到一個映射的內(nèi)部地址上。因此如果地址轉(zhuǎn)換網(wǎng)關能將每個連接均勻轉(zhuǎn)換為不同的內(nèi)部服務器地址，此后外部網(wǎng)絡中的計算機就各自與自己轉(zhuǎn)換得到的地址上服務器進行通信，從而達到負載分擔的目的。

　　地址轉(zhuǎn)換可以通過軟件方式來實現(xiàn)，也可以通過硬件方式來實現(xiàn)。使用硬件方式進行操作一般稱為交換，而當交換必須保存TCP連接信息的時候，這種針對OSI網(wǎng)絡層的操作就被稱為第四層交換。支持負載均衡的網(wǎng)絡地址轉(zhuǎn)換為第四層交換機的一種重要功能，由于它基于定制的硬件芯片，因此其性能非常優(yōu)秀，很多交換機聲稱具備400MB-800MB的第四層交換能力，然而也有一些資料表明，在如此快的速度下，大部分交換機就不再具備第四層交換能力了，而僅僅支持第三層甚至第二層交換。

　　然而對于大部分站點來講，當前負載均衡主要是解決Web服務器處理能力瓶頸的，而非網(wǎng)絡傳輸能力，很多站點的互聯(lián)網(wǎng)連接帶寬總共也不過10MB，只有極少的站點能夠擁有較高速的網(wǎng)絡連接，因此一般沒有必要使用這些負載均衡器這樣的昂貴設備。

　　使用軟件方式來實現(xiàn)基于網(wǎng)絡地址轉(zhuǎn)換的負載均衡則要實際的多，除了一些廠商提供的解決方法之外，更有效的方法是使用免費的自由軟件來完成這項任務。其中包括Linux Virtual Server Project中的NAT實現(xiàn)方式，或者本文作者在FreeBSD下對natd的修訂版本。一般來講，使用這種軟件方式來實現(xiàn)地址轉(zhuǎn)換，中心負載均衡器存在帶寬限制，在100MB的快速以太網(wǎng)條件下，能得到最快達80MB的帶寬，然而在實際應用中，可能只有40MB-60MB的可用帶寬。

　　擴展的負載均衡技術(shù)

　　上面使用網(wǎng)絡地址轉(zhuǎn)換來實現(xiàn)負載分擔，毫無疑問所有的網(wǎng)絡連接都必須通過中心負載均衡器，那么如果負載特別大，以至于后臺的服務器數(shù)量不再在是幾臺、十幾臺，而是上百臺甚至更多，即便是使用性能優(yōu)秀的硬件交換機也回遇到瓶頸。此時問題將轉(zhuǎn)變?yōu)椋绾螌⒛敲炊嗯_服務器分布到各個互聯(lián)網(wǎng)的多個位置，分散網(wǎng)絡負擔。當然這可以通過綜合使用DNS和NAT兩種方法來實現(xiàn)，然而更好的方式是使用一種半中心的負載均衡方式。

　　在這種半中心的負載均衡方式下，即當客戶請求發(fā)送給負載均衡器的時候，中心負載均衡器將請求打包并發(fā)送給某個服務器，而服務器的回應請求不再返回給中心負載均衡器，而是直接返回給客戶，因此中心負載均衡器只負責接受并轉(zhuǎn)發(fā)請求，其網(wǎng)絡負擔就較小了。

　　上圖來自Linux Virtual Server Project，為他們使用IP隧道實現(xiàn)的這種負載分擔能力的請求/回應過程，此時每個后臺服務器都需要進行特別的地址轉(zhuǎn)換，以欺騙瀏覽器客戶，認為它的回應為正確的回應。

　　同樣，這種方式的硬件實現(xiàn)方式也非常昂貴，但是會根據(jù)廠商的不同，具備不同的特殊功能，例如對SSL的支持等。

　　由于這種方式比較復雜，因此實現(xiàn)起來比較困難，它的起點也很高，當前情況下網(wǎng)站并不需要這么大的處理能力。?

　　比較上面的負載均衡方式，DNS最容易，也最常用，能夠滿足一般的需求。但如果需要進一步的管理和控制，可以選用反向代理方式或NAT方式，這兩種之間進行選擇主要依賴緩沖是不是很重要，最大的并發(fā)訪問數(shù)量是多少等條件。而如果網(wǎng)站上對負載影響很厲害的CGI程序是由網(wǎng)站自己開發(fā)的，也可以考慮在程序中自己使用Locaction來支持負載均衡。半中心化的負載分擔方式至少在國內(nèi)當前的情況下還不需要。