參考文稿分析

第27 建立多服務(wù)器本書的絕大部分是圍繞著在單一服務(wù)器上的Wb應(yīng)用程序的開發(fā)與優(yōu)化，而多服務(wù)器的開發(fā)與優(yōu)化同單一服務(wù)器上的情形有細(xì)微的差別。本章重點(diǎn)研究多服務(wù)器以及它們的工作方式。多服務(wù)器的定義，以及何時(shí)或者是否應(yīng)當(dāng)建立一個(gè)多服務(wù)器首先讓我們看一下一個(gè)多服務(wù)器的構(gòu)成。網(wǎng)絡(luò)服務(wù) 數(shù)據(jù)庫服務(wù)圖27-1最典型的有一個(gè)單一的響應(yīng)HTTP請(qǐng)求的網(wǎng)絡(luò)服務(wù)器，這個(gè)服務(wù)器可能使用網(wǎng)絡(luò)服務(wù) 數(shù)據(jù)庫服務(wù)圖27-1，。，。在各種各樣的算法中清理出過于臃腫的內(nèi)容網(wǎng)絡(luò)服務(wù)器也可以通過增加CPU、額外的和更快的硬盤驅(qū)動(dòng)器增強(qiáng)其性能。然而，最終可能無法再通過改進(jìn)系統(tǒng)的性能使其達(dá)到可接受的水平。對(duì)于Internet應(yīng)用程序，這種情況早已出現(xiàn)。改善系統(tǒng)性能的一種顯而易見的方式就是通過多網(wǎng)絡(luò)服務(wù)器分散或平衡負(fù)載。即使的用戶數(shù)量不多，對(duì)于單個(gè)服務(wù)器配置，也存在一些其他的潛在問題。每一個(gè)IT經(jīng)理的一個(gè)基本假設(shè)就是任何機(jī)器都會(huì)失敗，如果這個(gè)失敗的機(jī)器作為網(wǎng)絡(luò)服務(wù)器，則用戶無論如何也不能進(jìn)入這個(gè)。對(duì)于商業(yè)站點(diǎn)來說這將帶來許多麻煩。考慮一個(gè)經(jīng)紀(jì)人例子，如果一個(gè)經(jīng)紀(jì)人不能被，這個(gè)經(jīng)紀(jì)人的顧客可能在等待恢復(fù)的時(shí)候損失大量的。此外，需要注意的是，也是管理生產(chǎn)環(huán)境時(shí)不可缺少的部分。有一些常規(guī)的安全性公告要求應(yīng)用程序熱修補(bǔ)和對(duì)系統(tǒng)或系統(tǒng)軟件的服務(wù)補(bǔ)丁。這可能需要替換硬件。當(dāng)僅有一個(gè)服務(wù)器時(shí)，即使是最一般的改變，也要將整個(gè)停下來。這將導(dǎo)致數(shù)小時(shí)的維修以及IT職員的抱怨。最后還有一個(gè)內(nèi)容升級(jí)的問題。網(wǎng)絡(luò)應(yīng)用程序的發(fā)展趨向于不斷改變的內(nèi)容。在一個(gè)獨(dú)立的服務(wù)器上展示新的內(nèi)容或讓內(nèi)部用戶驗(yàn)證的正確性是一個(gè)極好的方法。這樣能避免許多令人煩惱的問題和咨詢。圖27-2展示了多服務(wù)器的配置網(wǎng)絡(luò)服網(wǎng)絡(luò)服數(shù)據(jù)庫網(wǎng)絡(luò)服網(wǎng)絡(luò)服數(shù)據(jù)庫網(wǎng)絡(luò)服網(wǎng)絡(luò)服圍內(nèi)，任何一部分出現(xiàn)故障將不影響的。此外，網(wǎng)絡(luò)服務(wù)器多于數(shù)據(jù)庫服務(wù)器個(gè)障（failover）配置，其原因是備用機(jī)。器了失敗的現(xiàn)象在用戶面前出現(xiàn)。總而言之，使用Web

圖27- 多服務(wù)器的配Web陣是否是一件好事。當(dāng)討論多網(wǎng)絡(luò)服務(wù)器的運(yùn)行優(yōu)點(diǎn)時(shí)，同樣也需要討論它的不足之處。明顯的缺點(diǎn)是增加了系統(tǒng)的復(fù)雜性，當(dāng)請(qǐng)求通過多服務(wù)器時(shí)，需要某些模式來分配請(qǐng)求給這些服務(wù)器。最具有代表性的是需要增加網(wǎng)絡(luò)硬件或軟件組件。這不僅增加了相關(guān)的開發(fā)和管理工作，而且也增加了測(cè)試工作。為了確定系統(tǒng)按希望工作，必須測(cè)試系統(tǒng)的冗余、負(fù)載平衡和故障屏障等各個(gè)方面。另一個(gè)缺點(diǎn)是這種變化可能影響系統(tǒng)結(jié)構(gòu)，將在后面討論這些問題。狀態(tài)管理、用戶管理和資源管理等模式，移植到多服務(wù)器系統(tǒng)時(shí)需要進(jìn)行改變。一種簡(jiǎn)單的例子是管理上傳的文件，如果這些文件當(dāng)前是放在本地的 結(jié)構(gòu)中，需要修改系統(tǒng)使其指向中心的共享 最后，當(dāng)將原來使用一臺(tái)機(jī)器的改為使用多臺(tái)機(jī)器時(shí)，要增加管理的費(fèi)用。IT需要對(duì)多臺(tái)機(jī)器進(jìn)行追蹤，每臺(tái)機(jī)器的配置。內(nèi)容、代碼、熱修補(bǔ)、補(bǔ)丁等等必須寫入到每臺(tái)服務(wù)器。盡管冗余使得管理能在運(yùn)行期間執(zhí)行，但是冗余和容錯(cuò)不能免除管理員的責(zé)任。此外，測(cè)試環(huán)境必須（最大程度地）反映工作環(huán)境，也就是要測(cè)試機(jī)器。不要輕視這些缺點(diǎn)的影響?？焖俳桓盾浖哪芰κ荌nternet商務(wù)的強(qiáng)大競(jìng)爭(zhēng)優(yōu)勢(shì)。建立一個(gè)Web陣，同單個(gè)服務(wù)器相比，將會(huì)花費(fèi)大量、較長(zhǎng)的時(shí)間（對(duì)于第一次而言）和較高的經(jīng)常性費(fèi)用。如果站點(diǎn)的用戶有限，沒有重要的使命，能夠承擔(dān)由于例行維修和預(yù)料不到的誤起的關(guān)所生的，么就盡能免建立個(gè)eb陣。但是，如果正在開發(fā)一個(gè)網(wǎng)絡(luò)應(yīng)用程序，而且將來可能面對(duì)大量的用戶，最好考慮周到一些。一旦應(yīng)用程序運(yùn)行于多服務(wù)器配置（盡管實(shí)際上沒有多個(gè)服務(wù)器，那么增加附加的資源來應(yīng)付負(fù)載增大的問題就非常容易。如果開始沒有這樣做，擴(kuò)展服務(wù)器的工作會(huì)變慢（潛在有阻塞，根據(jù)的條件，可能會(huì)是幾天或者幾周而不是幾小時(shí)。上面討論了Web陣的優(yōu)點(diǎn)和缺點(diǎn)，就讓我們看一下一個(gè)WebWeb陣是如何工作的？考慮一個(gè)HTTP請(qǐng)求的處理過程，如圖27-3用用瀏覽DNS服務(wù)網(wǎng)絡(luò)服輸入匹配URL到 建立連 連接已建 發(fā)送HTTP請(qǐng) 接收頁 圖27- 一個(gè)HTTP請(qǐng)求的處理過用戶將URL輸入瀏覽器，在瀏覽器向服務(wù)器發(fā)送TCP/TP請(qǐng)求之前，瀏覽器需要知道的IP地址。瀏覽器根據(jù)用戶輸入的主機(jī)名通過詢問系統(tǒng)（DNS）服務(wù)器來查尋相應(yīng)的IPDNS服務(wù)器包含主機(jī)名/IPDNS服務(wù)器上，則服務(wù)器就會(huì)向第二個(gè)DNS服務(wù)器詢問。最終，這個(gè)詢問將被發(fā)送到主機(jī)網(wǎng)絡(luò)的DNS服務(wù)器，這個(gè)DNSIPDNS服務(wù)器，由這個(gè)服務(wù)器把數(shù)據(jù)返回瀏覽器。應(yīng)當(dāng)注意的是，實(shí)際上DNS服務(wù)器的操作要比這里簡(jiǎn)單解釋的復(fù)雜得多，關(guān)于在Internet上使用系統(tǒng)的詳細(xì)描述超出了本書的范圍。一旦瀏覽器有了IP機(jī)址，就會(huì)開始連接，在狀態(tài)欄將會(huì)看到如“ConnectingtositeHTTP請(qǐng)求，服務(wù)器分析這些當(dāng)涉及到單個(gè)的服務(wù)器時(shí)，總是由同樣的機(jī)器響應(yīng)HTTP請(qǐng)求。所有負(fù)載平衡模式都涉及到可能把后續(xù)的HTTP請(qǐng)求安排到不同的服務(wù)器這一問題，這會(huì)使?fàn)顟B(tài)管理變得。 循環(huán)復(fù)用法：使用DNS服務(wù)器平衡負(fù)載微軟的TCP/IPNetworkLoadBalancing逐個(gè)討論這些解決方案，說明它們是如何工作的，分析一下它們?cè)谪?fù)載平衡與容錯(cuò)方面的性能。同時(shí)也將系統(tǒng)中的相關(guān)變化，例如對(duì)服務(wù)器的影響。最后還將簡(jiǎn)單地介紹一些相關(guān)的技術(shù)，例如微軟的HighAvailability 以及＋DynamicLoadBalancing。DNS循環(huán)復(fù)DNS循環(huán)復(fù)用法（DNSRoundRobin）是將HTTP請(qǐng)求安排到多個(gè)服務(wù)器上的簡(jiǎn)單方法。如前所述，一個(gè)DNS服務(wù)器保持著位于某個(gè)特定域內(nèi)的每臺(tái)機(jī)器的主機(jī)名/IP地址對(duì)的集合，其每個(gè)xxx代表0~255的數(shù)（這里沒有給出實(shí)際的數(shù)字，以避免由于無意而涉及任何人的服務(wù)器。當(dāng)建立一個(gè)DNS服務(wù)器時(shí)（微軟的Windows2000AdvancedServer中包含DNS服務(wù)），為每個(gè)附加的機(jī)器創(chuàng)建一個(gè)額外的IP條目（在DNS中稱為記錄或地址記錄），這個(gè)結(jié)果列表與下當(dāng)響應(yīng)DNS，DNS服務(wù)器將循環(huán)使用表中所有記錄。這樣，在上面的例子中，對(duì)于第一個(gè)解析 ，DNS服務(wù)器將會(huì)返回xxx.xxx.xxx.3，對(duì)于下一個(gè)解析，DNS服務(wù)器將會(huì)返回xxx.xxx.xxx.4，等等。結(jié)果所有的請(qǐng)求被分配到所有的網(wǎng)絡(luò)服務(wù)器上。HTTP請(qǐng)求被平衡到一系列網(wǎng)絡(luò)服務(wù)器上，但是只是在每一個(gè)服務(wù)器收到相同數(shù)量的請(qǐng)求這一個(gè)方面達(dá)到了平衡。這是假設(shè)所有的服務(wù)器具有相同的資源（一種可行的假設(shè)有的事務(wù)處理都要求相同數(shù)量的系統(tǒng)資源（這是一種沒有意義的假設(shè)。這種解決方案根本沒有注意到當(dāng)前eb陣中機(jī)器上的處理器負(fù)載。當(dāng)負(fù)載分配達(dá)到某種程度時(shí)，這是一種效率極Web陣為例，如圖27-4服務(wù)器數(shù)據(jù)庫服務(wù)器圖27-4兩個(gè)網(wǎng)絡(luò)服務(wù)器組成的Web如果由于服務(wù)器A響應(yīng)HTTP請(qǐng)求而使它的處理器利用率飽和（100%，而服務(wù)器B的處理器利用率很低（10%~15%，DNSHTTPA，而此時(shí)服務(wù)器A已經(jīng)過載了，這不僅效果很差而且會(huì)導(dǎo)致用戶在看到站點(diǎn)的執(zhí)行緩慢時(shí)去點(diǎn)擊在瀏覽器上的Refresh按鈕。這不僅是極壞的嘗試，而且會(huì)使請(qǐng)求隊(duì)列變長(zhǎng)，直到瀏覽器上出現(xiàn)“Servertoobusy對(duì)于DNS循環(huán)復(fù)用法，另一個(gè)缺點(diǎn)是不能很好地處理系統(tǒng)的運(yùn)行中斷。仍以兩個(gè)服務(wù)器組成的eb陣為例。如果服務(wù)器A，則所有HTTP請(qǐng)求的一半被安排到一臺(tái)無效的服務(wù)器上，結(jié)果就會(huì)是在用戶的瀏覽器上顯示“ServerUnavailable”消息?？梢酝Ｏ聛砭S修機(jī)器，但需要更新DNSDNS服務(wù)器緩存了主機(jī)名/IP地址對(duì)信息，可能在幾天內(nèi)都不更新。DNS循環(huán)復(fù)用法是一個(gè)管理者的夢(mèng)想。管理DNS記錄很容易，而且DNS循環(huán)復(fù)總之，DNS循環(huán)復(fù)用法比DNS循環(huán)復(fù)用法能力更強(qiáng)是硬件負(fù)載平衡。圖27-5就是一種網(wǎng)絡(luò)配置的示意圖有一種新的硬件，即硬件負(fù)載平衡器，其位于網(wǎng)絡(luò)服務(wù)器和其他網(wǎng)絡(luò)設(shè)備（、路由器等）URL的用戶請(qǐng)求被安排到負(fù)載平衡器，連接到負(fù)載平衡器上的接收到的發(fā)送到集群的TCP/IP包，負(fù)載平衡器執(zhí)行如下動(dòng)作網(wǎng)網(wǎng)絡(luò)服熱備集硬件負(fù)載平衡圖27-5決定集群中哪一個(gè)服務(wù)器將接受下一個(gè)TCP/IP請(qǐng)求檢查服務(wù)器和應(yīng)用程序 TCP/IP端口）的可用性在有些情況下，檢查由服務(wù)器返回的數(shù)據(jù)的有效性。當(dāng)服務(wù)器作出響應(yīng)時(shí)，這是非常方HTTPError404轉(zhuǎn)換I 報(bào)頭，以便包能指向選中的服務(wù)器，這項(xiàng)轉(zhuǎn)化技術(shù)通常稱為網(wǎng)絡(luò)地址轉(zhuǎn)（NTNAT的結(jié)果使得客戶接收到的TCP/IP包看起來就是來自代表此集群的IP負(fù)載平衡器如何決定由哪一個(gè)服務(wù)器響應(yīng)發(fā)送來的請(qǐng)求呢？這因廠商不同而不同，但最基本的算法是相同的。負(fù)載平衡器通過監(jiān)視網(wǎng)絡(luò)活動(dòng)性，了大量的信息。這些活動(dòng)性包括進(jìn)入和來自各個(gè)服務(wù)器的信息傳輸量、各個(gè)服務(wù)器響應(yīng)TCP/IP請(qǐng)求的速度、每個(gè)服務(wù)器目前連接的用戶數(shù)量以及每個(gè)服務(wù)器對(duì)負(fù)載的反應(yīng)的歷史情況。負(fù)載平衡器為系統(tǒng)管理員提供了一種基于網(wǎng)絡(luò)流量的算法，而且這種算法一般包括循環(huán)復(fù)用法和比率（循環(huán)復(fù)用法）算法。負(fù)載平衡器通過網(wǎng)絡(luò)流量，能夠智能地有效分配處理負(fù)載到多個(gè)服務(wù)器上，再看一下上面DNS27-6如果由于服務(wù)器A響應(yīng)HTTP請(qǐng)求，使其處理器利用率飽和（100%，而服務(wù)器B的處理器利用率很低（如10%~15%A的響應(yīng)很慢，它將安排后續(xù)的請(qǐng)求到服務(wù)器B。這將持續(xù)到在網(wǎng)絡(luò)服務(wù)器A上的負(fù)載回到一個(gè)可以接受的水平。其結(jié)果比使再以兩個(gè)服務(wù)器的Web陣為例。如果服務(wù)器A停機(jī)，硬件負(fù)載平衡器將不發(fā)送任何TCP/IP流到服務(wù)器AWeb服務(wù)不能進(jìn)行響應(yīng)，負(fù)載平衡器就會(huì)將服務(wù)器A從可用的服務(wù)器的上去掉，并將所有的流傳送給服務(wù)器B，這也比使用DNS循環(huán)復(fù)用法的效果

硬件負(fù)載平衡熱備

服務(wù)器服務(wù)器

數(shù)據(jù)庫圖27-6由兩個(gè)網(wǎng)絡(luò)服務(wù)器組成的硬件負(fù)載平衡Web關(guān)于硬件負(fù)載平衡方案還有一點(diǎn)應(yīng)當(dāng)注意：負(fù)載平衡器本身成為故障的中心點(diǎn)。為了解決這一點(diǎn)，典型的方案應(yīng)包括第二個(gè)負(fù)載平衡器作為熱備用，這種冗余故障配置是相當(dāng)RS-232電纜這樣的串行通信介質(zhì)連接，每個(gè)單元都有“看門狗”處理器不斷地彼此交流。在某個(gè)單元失敗或不正常時(shí)，“看門狗”單元協(xié)商并決定由哪一個(gè)單元完成負(fù)載平衡。通常，硬件負(fù)載平衡器是產(chǎn)品質(zhì)量部件，其一般特性包括將單個(gè)IP地址或介一個(gè)完整的C類地址空間與單個(gè)服務(wù)器關(guān)聯(lián)起來的能力、、基于網(wǎng)絡(luò)的管理能力、在服務(wù)器故障的情況下能力、實(shí)時(shí)的監(jiān)視性能和統(tǒng)計(jì)信息的能力。如果對(duì)硬件負(fù)載平衡系統(tǒng)感的話，Cabletron公司()和CiscoSystems公司（ DNS循環(huán)復(fù)用法的管理復(fù)雜得多，但是不必畏懼。建立負(fù)載平衡器并不比建立一個(gè)典型的路由器（實(shí)際上，這些裝置基本上都是路由器的形式，且你的網(wǎng)絡(luò)管理員對(duì)于路由器的技術(shù)應(yīng)該很了解。對(duì)于網(wǎng)絡(luò)負(fù)載平衡模式的管理是相當(dāng)集中的，而且不影響服務(wù)器機(jī)器本身。這在負(fù)責(zé)建立并服務(wù)器的管理員眼中就是一個(gè)巨大的成功。對(duì)于硬件負(fù)載平衡解決方案的實(shí)際能力有一些局限，最大的局限是帶寬。由于在進(jìn)入和輸出的過程中都要將TCP/IP報(bào)頭轉(zhuǎn)變?yōu)橐粋€(gè)新的IP地址，通過負(fù)載平衡器的，帶寬往往被限制在45～50Mbps。這對(duì)于一般數(shù)據(jù)而言是一個(gè)巨大的帶寬，大的站點(diǎn)在其使用期能夠超過這種能力，額外的信息包被丟棄了。顯而易見，這不是最優(yōu)化的，而且對(duì)于大部分也是不可行的。硬件負(fù)載平衡解決方案的另一不足之處就是費(fèi)用太高。寫本書時(shí)，使用一對(duì)硬件負(fù)載平在20000以上，并且在繼續(xù)上漲。這就意味著必須在負(fù)載平衡器上花的錢而不是在額外的服務(wù)器上。最后，基于硬件的負(fù)載平衡算法必須建立在來自于網(wǎng)絡(luò)流量的可觀測(cè)數(shù)據(jù)的基礎(chǔ)上，對(duì)HTTP請(qǐng)求包含要花費(fèi)大量時(shí)間的數(shù)據(jù)庫操作，但并沒有阻塞網(wǎng)絡(luò)服務(wù)。在這種情況下，硬件負(fù)載平衡器會(huì)認(rèn)為服務(wù)器很忙，但實(shí)際上這時(shí)服務(wù)器是可用的資源。盡管有這些不足之處，但硬件負(fù)載平衡對(duì)于完成一個(gè)的負(fù)載平衡有著不容置疑的可靠性與實(shí)用性。通過將進(jìn)入和輸出的TCP/IP流轉(zhuǎn)換為服務(wù)器集群內(nèi)的IP地址，將負(fù)載分配到多個(gè)服務(wù)器上。根據(jù)觀察服務(wù)器集群內(nèi)的網(wǎng)絡(luò)流情況，決定請(qǐng)求如何分配。這從負(fù)載平衡的意義上看是高效的，但是在服務(wù)器資源方面，例如CPU的利用率、HTTP請(qǐng)求的隊(duì)列長(zhǎng)度和線程數(shù)量等等，不一定高效。每一個(gè)服務(wù)器和每一個(gè)應(yīng)用程序的可用性。負(fù)載平衡器在將包送到服務(wù)器之前檢查可用性。TCP/IPNetworkLoad微軟開發(fā)了一個(gè)軟件組件，稱為NetworkLoadBalancing（NLB，是作為Windows2000AdvancedServer的一部分提供的。NLB首次于1997年10月以WindowsLoadBalancingSerrice（WLBS）這個(gè)名字作為WindowsNT4.0的一種插件發(fā)布，一個(gè)使用NLB的網(wǎng)絡(luò)配置示例如圖集群集群NIC驅(qū)動(dòng)程指定服務(wù)器的集群NIC驅(qū)動(dòng)程指定服務(wù)器的NLB服 NLB服TCP/IPTCP/IPTCP/IPTCP/IPTCP/IPTCP/IP單NIC配雙NIC配圖27- 你會(huì)發(fā)現(xiàn)NLB所需要的配置不同于標(biāo)準(zhǔn)的網(wǎng)絡(luò)配置，也會(huì)發(fā)現(xiàn)來自于Internet的流在一個(gè) IP地址是集群的IP地址，應(yīng)當(dāng)代表網(wǎng)站服務(wù)器的URL。每一個(gè)服務(wù)器還有一個(gè)唯一的IP地址用于非集群傳輸。圖27-7也暗示了對(duì)于每一臺(tái)服務(wù)器存著兩個(gè)相互獨(dú)立的網(wǎng)絡(luò)連接。NLB不要求這樣做，它可以一塊網(wǎng)絡(luò)接口卡（NetworkInterfaceCard，NIC）上工作，這樣不影響服務(wù)器的硬件。但是，大多數(shù)情況應(yīng)該每臺(tái)服務(wù)器的配置是很簡(jiǎn)單的。一旦安裝了NLBIP地址、一個(gè)唯一的主機(jī)ID（1~32，一個(gè)NLB實(shí)現(xiàn)被限制在最多有32個(gè)服務(wù)器、權(quán)重（因?yàn)椴⒉皇撬邢到y(tǒng)都有同樣的容量）和一系列規(guī)則。每一項(xiàng)規(guī)則決定了哪一個(gè)TCP/IP應(yīng)用程序要進(jìn)行負(fù)載平衡及其親和性（個(gè)IP或者C類，下面很快將討論這個(gè)問題。對(duì)于基于網(wǎng)絡(luò)的流80端口（標(biāo)準(zhǔn)的HTTP端口）沒有親和性。你可能會(huì)有這樣的疑問，最多可以有32個(gè)服務(wù)器收到同一IP地址的信息包，為什么客戶端沒有收到32個(gè)響應(yīng)呢？在于微軟稱之為的“并行過濾”的東西。當(dāng)安裝了NLB務(wù)以TCP/IP棧與NIC驅(qū)動(dòng)程序之間，所有傳輸?shù)街付ǚ?wù)器的流直接通過，對(duì)于指向集群的IPNLB軟件決定由哪個(gè)主機(jī)處理請(qǐng)求，這個(gè)服務(wù)器讓流通過它的集群NICIP請(qǐng)求，所以只有被指定的服務(wù)器響應(yīng)這個(gè)請(qǐng)求。NLBTCP/IP請(qǐng)求應(yīng)該由哪個(gè)主機(jī)響應(yīng)。這種算法使用的負(fù)載信息是通過各主機(jī)收集并通過廣播向外共享的。由于這是一個(gè)軟件工具，因此這個(gè)負(fù)載信息包括CPU的利用率、可使用的內(nèi)存和其他情況的詳細(xì)內(nèi)容。通過監(jiān)測(cè)網(wǎng)絡(luò)流，它可以提供一種更精確有效的負(fù)載平衡。因?yàn)檫@僅涉及過濾包而不涉及數(shù)據(jù)包的修改和再發(fā)送，所以NLB不用面對(duì)硬件負(fù)載平衡模式中的那種吞吐量限制問題。前面已經(jīng)NLB僅需一個(gè)NIC，然而，用兩個(gè)NIC是一個(gè)好主意。圖27-7展示了兩個(gè)可能方案。當(dāng)用一個(gè)NIC時(shí)，所有TCP/IP流都通過NLB服務(wù)。另外，非集群流和集群流通過同樣的NIC，寬帶和處理時(shí)間被非集群流和集群流。增加另一塊N把集群流與指定服務(wù)器的流分離，允許管理流和其他指定服務(wù)器的流直接進(jìn)入服務(wù)器，從而使它們對(duì)集群的吞吐量影響最小。NLB主機(jī)以一定周期交換廣播消息，使它們能監(jiān)視集群的狀態(tài)。當(dāng)一個(gè)主機(jī)進(jìn)入或離開NLB軟件開始一個(gè)稱作“集中（convergence”的處理。在集中期間，主機(jī)確定新的10秒鐘。NLB流的一部分是每個(gè)主機(jī)都參與的“心跳（heartbeat”消息，心跳消息的周期是可以配置的，缺省周期為一秒。如果主機(jī)在5個(gè)心跳消息周期內(nèi)還沒參與服務(wù)（或服務(wù)失敗），則和前面討論的解決方案不同，NLB影響每臺(tái)服務(wù)器。它的實(shí)現(xiàn)涉及到每臺(tái)服務(wù)器上的軟件安裝和配置，以及安裝附加的NIC（還有集線器或交換機(jī)端口、電纜接頭等。另外，根據(jù)好消息是NLB提供了對(duì)網(wǎng)上每臺(tái)計(jì)算機(jī)的優(yōu)秀的管理能力。一旦在主機(jī)上安裝了這個(gè)軟件，就可以在集群中控制主機(jī)的加入、移去和配置。簡(jiǎn)而言之，一個(gè)有強(qiáng)大的管理能力對(duì)于負(fù)載平衡的另一個(gè)可行方案就是硬件與軟件技術(shù)結(jié)合的復(fù)合方式。網(wǎng)絡(luò)配置如圖27- 交換網(wǎng)硬件負(fù)載網(wǎng)絡(luò)服務(wù) 集群熱備特定交換網(wǎng)圖27-8圖27-8中有一套硬件負(fù)載平衡器和兩個(gè)服務(wù)器集群，每一個(gè)集群都使用NLB來實(shí)行負(fù)載平衡以及容錯(cuò)。硬件負(fù)載平衡器不關(guān)心這兩個(gè)IP地址與其對(duì)應(yīng)的集群中的服務(wù)器地址的變換關(guān)系。對(duì)于負(fù)載平衡，現(xiàn)在服務(wù)器可以超過NLB限制的32個(gè)服務(wù)器。實(shí)際上，如果假設(shè)硬件負(fù)載平衡器能夠在256個(gè)節(jié)點(diǎn)上分配負(fù)載（一個(gè)完全合理的假設(shè)，就能擴(kuò)展站點(diǎn)達(dá)到不可想象的8192現(xiàn)在可以從網(wǎng)絡(luò)和系統(tǒng)兩個(gè)方面來決定負(fù)載分配。形成瓶頸的主要因素可能是網(wǎng)絡(luò)的狀況，而不是系統(tǒng)的處理能力。在這樣的方案中，允許在硬件負(fù)載平衡器（網(wǎng)絡(luò)）與使用NLB的服務(wù)器集群（系統(tǒng)）之間協(xié)調(diào)負(fù)載平衡的負(fù)擔(dān)。由于增加了硬件負(fù)載平衡器，管理容錯(cuò)時(shí)有了的選擇?，F(xiàn)在完全能夠?qū)b陣在絡(luò)以及地理位置的意義上相互。復(fù)合方式提供了額外的措施來對(duì)付環(huán)境方面的問題（如洪水、火災(zāi)等。也提供了最有力的措施去保護(hù)所有的服務(wù)器以避免危及其安全。后面將進(jìn)一NLB最難處理的安全隱患之一是集群中的所有機(jī)器彼此之間要保持不間斷的通信。正如面所提到的，硬件負(fù)載平衡解決方案并不大量增加管理量。因此，實(shí)現(xiàn)和一種復(fù)合方式負(fù)載平衡并不比實(shí)現(xiàn)一個(gè)NLB解決方案。TCP/IP流轉(zhuǎn)換到集群的IP地址，將負(fù)載分配通過集群的響應(yīng)和可用性處理容錯(cuò)。在各集群內(nèi)，通過廣播的“心跳”消息處理容HighAvailabilityClustering微軟首先推出的集群技術(shù)是1997年10月發(fā)布的WindowsNT4.0EnterpriseEdition中的ClusteringService（MCCS。微軟公司已經(jīng)增強(qiáng)了Windows2000把這項(xiàng)服務(wù)更名為HighAvailabilityClusteringService（HACS。目前它不是一種負(fù)載平衡方集群服務(wù)提供了兩種防止像SQLServer數(shù)據(jù)庫這樣的重要應(yīng)用程序失敗的方法。這不同于通過多網(wǎng)絡(luò)服務(wù)器集群提供負(fù)載平衡的NLB系統(tǒng)?？匆幌聢D27-9所示的硬件負(fù)載平衡網(wǎng)絡(luò)圖27-9是我們熟悉的由兩個(gè)網(wǎng)絡(luò)服務(wù)器處理來自于Internet或者其他網(wǎng)絡(luò)的流的情況，在其中使用硬件負(fù)載平衡的方法實(shí)現(xiàn)負(fù)載平衡和容錯(cuò)。但是，這種方法仍有單一失敗點(diǎn)。如果數(shù)據(jù)庫服務(wù)器失靈了，來自于網(wǎng)絡(luò)服務(wù)器的涉及數(shù)據(jù)庫的請(qǐng)求（可能是大量的）將會(huì)全部失敗。這就是微軟的集群服務(wù)要解決的問題?？紤]一下圖27-1所示的另一個(gè)利用集群的網(wǎng)絡(luò)配置。 熱備 圖27- 網(wǎng)絡(luò)網(wǎng)熱備陣硬件負(fù)載平衡集群的數(shù)據(jù)庫服圖27- 圖27-10中的配置已經(jīng)消除了單一失敗點(diǎn)，現(xiàn)在有兩個(gè)數(shù)據(jù)庫服務(wù)器作為一個(gè)虛擬服務(wù)器。這種集群技術(shù)對(duì)于每一個(gè)服務(wù)器要求有一個(gè)額外的NIC，在這些NIC之間形成一個(gè)網(wǎng)絡(luò)，SCSI總線（至少有一個(gè)磁盤SCSI磁盤陣列必須僅用于集群應(yīng)用程序和其他資源，而系統(tǒng)文件必須單獨(dú)放在一個(gè)獨(dú)立的用于集群的服務(wù)器的SCSI當(dāng)前的微軟集群技術(shù)并不支持負(fù)載平衡。微軟說目前的集群解決方案是它的集群策略的第一階段，第一階段表現(xiàn)為給共套數(shù)據(jù)的兩個(gè)節(jié)點(diǎn)提供故障（failover）功能的能力，第2階段將通過允許最多16個(gè)服務(wù)器實(shí)時(shí)共享數(shù)據(jù)、執(zhí)行負(fù)載平衡以及提供對(duì)故障屏幕的支持來合并負(fù)載平衡和故障屏幕技術(shù)。你會(huì)注意到集群中兩個(gè)節(jié)點(diǎn)共個(gè)網(wǎng)絡(luò)。所有與每臺(tái)機(jī)器的“健康”相關(guān)的信息以“心跳”消息的形式在這個(gè)網(wǎng)絡(luò)中。每一個(gè)服務(wù)器都有一個(gè)稱為集群服務(wù)的軟件組件，用于系統(tǒng)的狀態(tài)，并把這個(gè)信息傳送到另一個(gè)節(jié)點(diǎn)的相應(yīng)部位。集群準(zhǔn)備（cluste-ready）應(yīng)用程序?qū)?shù)據(jù)在共享的SCSI磁盤陣列上。如果一個(gè)應(yīng)用程序失敗，則另一個(gè)節(jié)點(diǎn)就啟微軟的集群技術(shù)對(duì)于網(wǎng)絡(luò)應(yīng)用程序的可用性提供了基本的保障：狀態(tài)數(shù)據(jù)的容錯(cuò)。在多服務(wù)器站點(diǎn)上的網(wǎng)絡(luò)服務(wù)器一般不局部地保持狀態(tài)（在下一節(jié)討論狀態(tài)。這使得重新安排用戶的請(qǐng)求到一個(gè)可用的服務(wù)器變得簡(jiǎn)單。另一方面，數(shù)據(jù)庫負(fù)責(zé)管理對(duì)象的狀態(tài)，這就是其目的。為了提供容錯(cuò)，對(duì)于高度可用的系統(tǒng)，其數(shù)據(jù)庫服務(wù)器必需具有實(shí)時(shí)管理狀態(tài)的故障能力。對(duì)于集群的唯一替代方案是鏡像有故障能力的數(shù)據(jù)庫。但鏡像數(shù)據(jù)庫不能提供實(shí)時(shí)的數(shù)據(jù)同步，因此，一個(gè)系統(tǒng)癱瘓將可能導(dǎo)致數(shù)據(jù)丟失。應(yīng)當(dāng)注意到，集群服務(wù)能提供對(duì)許多資源的容錯(cuò)，而不僅僅是對(duì)數(shù)據(jù)庫。這些資源包括文件共享、活動(dòng) 服務(wù)和一些指定的DHCP信息。HighArailabilityClusteringService需要嚴(yán)格的硬件和精確的系統(tǒng)配置，因此這種解決方案的管理相對(duì)于前面講過的任何一種負(fù)載平衡方案而言，考慮的問題要多。應(yīng)當(dāng)注意到集群解決方案通常涉及到大量的新硬件，這會(huì)產(chǎn)生額外花費(fèi)。HighArailabilityClusteringService總之，HighArailabilityClusteringService通過集群的響應(yīng)和可用性處理容錯(cuò)。在各個(gè)集群內(nèi)通過廣播的“心跳”消息處理容COM＋DynamicLoad業(yè)務(wù)邏表現(xiàn)面，我們?yōu)樨?fù)載平衡和容錯(cuò)而增加了額外的服務(wù)器，增加的服務(wù)器放在表現(xiàn)層（網(wǎng)絡(luò)服務(wù)器）13章所描述的，一個(gè)普通的應(yīng)用程序結(jié)構(gòu)如圖業(yè)務(wù)邏表現(xiàn)圖27-11表現(xiàn)層包括網(wǎng)絡(luò)服務(wù)器和一系列的ASP文檔。嵌入到ASP文檔中的服務(wù)器端實(shí)例化一個(gè)COM＋組件，這個(gè)組件對(duì)某些業(yè)務(wù)邏輯和數(shù)據(jù)庫的細(xì)節(jié)進(jìn)行抽象，并通常在網(wǎng)絡(luò)服務(wù)器上實(shí)例化。如果COM＋提供了本地/的透明性，應(yīng)將業(yè)務(wù)邏輯組件分離到一個(gè)獨(dú)立的服務(wù)器上。網(wǎng)絡(luò)配置的結(jié)果如圖27-12網(wǎng)絡(luò)服務(wù)服務(wù) 熱備 硬件負(fù)載平衡數(shù)據(jù)庫圖27- 現(xiàn)在已把業(yè)務(wù)邏輯組件的處理負(fù)載分配到另一個(gè)服務(wù)器上，使網(wǎng)絡(luò)服務(wù)器有的時(shí)間和資源來處理HTTP請(qǐng)求。但是，現(xiàn)在又重新引入了一個(gè)單一失敗點(diǎn)。如果業(yè)務(wù)邏輯服務(wù)器停機(jī)，負(fù)載平衡器仍然會(huì)將HTTP請(qǐng)求發(fā)送到網(wǎng)絡(luò)服務(wù)器，但是網(wǎng)絡(luò)服務(wù)器將這些請(qǐng)求。對(duì)于將業(yè)務(wù)層從表現(xiàn)層劃分出來，安裝在另一臺(tái)機(jī)器上，COM＋DynamicLoadBalancing。這種能力原來是Window2000AdvancedServer的一個(gè)功能，在本書編寫時(shí)，它隨著Windows2000AppCenterServer一同發(fā)布。圖2713所示就是COM＋DynamicLoad服務(wù)熱備硬件負(fù)載平衡圖27- 使用COM＋DynamicLoadBalancing的網(wǎng)絡(luò)配一個(gè)額外的服務(wù)器已經(jīng)被添加到結(jié)構(gòu)中，即組件負(fù)載平衡路由器。這個(gè)服務(wù)器（通過集群服務(wù)提供容錯(cuò)和高可用性）接收來自網(wǎng)絡(luò)服務(wù)器的請(qǐng)求，并把這些請(qǐng)求安排到業(yè)務(wù)邏輯服務(wù)器陣中。請(qǐng)求的安排根據(jù)每個(gè)應(yīng)用程序服務(wù)器的處理負(fù)載而定。開始時(shí)，業(yè)務(wù)邏輯服務(wù)器陣可以支持最多8到現(xiàn)在為止，已經(jīng)討論了一個(gè)多服務(wù)器的概念，而且研究了一系列分配HTTP請(qǐng)求到HTTP協(xié)議原本是一種無狀態(tài)協(xié)議。根據(jù)其本質(zhì)，在HTTP請(qǐng)求之間服務(wù)器不應(yīng)該有狀態(tài)這個(gè)概念。ASP處理這個(gè)問題時(shí)幾乎都是使用Session對(duì)象，但Session對(duì)象是“指定機(jī)器的”。有幾個(gè)方法可以解決這個(gè)問題，其中包括避免使用狀態(tài)、使用客戶端的代替狀態(tài)、利用親和性（affinity）來允許使用Session對(duì)象以及串行化狀態(tài)數(shù)據(jù)并存入通用器中。不是所有的網(wǎng)絡(luò)應(yīng)用程序都需要管理頁面與頁面之間的狀態(tài)。如果一開始時(shí)就能避免管理狀態(tài)，就能為自己減少很多麻煩。很明顯這并不是令人滿意的答案，但卻是不可忽略的。狀態(tài)管理增加了網(wǎng)絡(luò)應(yīng)用程序的復(fù)雜性，因此，能避免它是件好事。就像第2章介紹的Response和Request對(duì)象允許在客戶機(jī)上和獲取。狀態(tài)也可以在隱藏的窗體中，窗體在頁面之間通過提交傳遞。在這種情況下，客戶端是較好的方法，這把管理數(shù)據(jù)的任務(wù)從服務(wù)器上完全移走。若數(shù)據(jù)在服務(wù)器上，隨著用戶數(shù)量的增加，在服務(wù)器上的數(shù)據(jù)將影響服務(wù)器性能。舉個(gè)例子，如果每個(gè)瀏覽的用戶4KB有價(jià)值的信息，而同時(shí)有10000個(gè)用戶的活動(dòng)會(huì)話，系統(tǒng)必須拿出40MB的內(nèi)存空間來這些不經(jīng)常的數(shù)據(jù)。將這些信息到每個(gè)客戶端，能有效地改善系統(tǒng)，信息隨同每個(gè)HTTP請(qǐng)求一起傳送。因此，客戶端的方法增加了網(wǎng)絡(luò)傳輸量，增加了傳輸時(shí)間，不如在服務(wù)器端管理狀態(tài)數(shù)據(jù)安全，而且對(duì)到客戶端的數(shù)據(jù)量有限制（依賴于瀏覽器除，而且信息只能為特定機(jī)器上的用戶服務(wù)。如果想利用會(huì)話變量并使用多服務(wù)器，可以使用一個(gè)擴(kuò)展的方法，允許“會(huì)話親和性（sessionaffinity續(xù)的請(qǐng)求到這個(gè)服務(wù)器。一個(gè)瀏覽器首先連接到eb陣中的某個(gè)的服務(wù)器上。從此開始，在這個(gè)用戶會(huì)話期間，所有后續(xù)的請(qǐng)求將安排到同一服務(wù)器上。如果在應(yīng)用程序中使用Session對(duì)象，這是必需的。硬件員載平衡器和NLB解決方案都能在確定由哪一個(gè)服務(wù)器響應(yīng)某個(gè)用戶時(shí)，提供這種親和性。然而，親和性的使用部分抵消了使用這些方案而得到的負(fù)載平衡效果。負(fù)載平衡方案是在接收到請(qǐng)求時(shí)，根據(jù)各個(gè)服務(wù)器的負(fù)載情況，將請(qǐng)求分配到某個(gè)服務(wù)器上。在會(huì)話的存活期，服務(wù)器的負(fù)載特征可能會(huì)發(fā)生很大的變化?？匆幌孪旅孢@個(gè)例子，如圖27-14用戶用戶 網(wǎng)絡(luò)服務(wù)器用戶 用戶 用戶 網(wǎng)絡(luò)服務(wù)器圖27- 假設(shè)有4個(gè)用戶（A~D）連接到，他們的請(qǐng)求平均分配給兩個(gè)網(wǎng)絡(luò)服務(wù)器?，F(xiàn)在假設(shè)用戶C和用戶D立即斷開連接，用戶A和用戶B長(zhǎng)時(shí)間連接并執(zhí)行許多復(fù)雜的運(yùn)算。如果我們使用了“親和性”，所有的來自于用戶A和用戶B的HTTP請(qǐng)求將安排到網(wǎng)絡(luò)服務(wù)器A上，用戶使用“親和性”的另一個(gè)問題是容錯(cuò)。網(wǎng)絡(luò)應(yīng)用程序的容錯(cuò)目標(biāo)是完全恢復(fù)任何單個(gè)的故障。如果嚴(yán)格限制一個(gè)用戶只能連接到單個(gè)服務(wù)器，就將失去擁有冗余機(jī)器的好處?？紤]A癱瘓，用戶A和用戶B正在使用的所有事務(wù)數(shù)據(jù)和狀態(tài)數(shù)據(jù)將丟失。最后，即使你愿意犧牲性能和容錯(cuò)（這是Web陣的兩個(gè)主要目的）以便Session對(duì)象，“親和性”也不能在所有情況下工作。請(qǐng)看圖27-15所示的例子。 服務(wù)器網(wǎng)絡(luò)服務(wù)器數(shù)據(jù)庫服務(wù)用戶 負(fù)載平 服務(wù)器網(wǎng)絡(luò)服務(wù)器圖27- 用戶A所在的網(wǎng)絡(luò)有幾個(gè)服務(wù)器平衡負(fù)載。當(dāng)用戶A通過瀏覽器發(fā)出HTTP請(qǐng)求時(shí)瀏覽器就會(huì)將這個(gè)請(qǐng)求傳遞給服務(wù)器。在本例中，有兩個(gè)服務(wù)器。由于本例使用單器A的請(qǐng)求被安排到同一個(gè)網(wǎng)絡(luò)服務(wù)器，即網(wǎng)絡(luò)服務(wù)器A。所有通過服務(wù)器B的請(qǐng)求被安排到網(wǎng)絡(luò)服務(wù)器B。盡管是單個(gè)用戶我們的網(wǎng)絡(luò)，但我們的系統(tǒng)認(rèn)為這些請(qǐng)求來自兩個(gè)用戶并用兩個(gè)網(wǎng)絡(luò)服務(wù)器來分擔(dān)負(fù)載，這將導(dǎo)致試圖訪問會(huì)話數(shù)據(jù)時(shí)出現(xiàn)意想不到的情況。NLB都有解決這個(gè)問題的方案。它們?cè)试S“親和性”針對(duì)于一個(gè)完整的C類地址空間（256個(gè)唯一的IP地址。其基本原理是大部分服務(wù)器集群應(yīng)在同一個(gè)地址空間內(nèi)。C類地址“親和力”會(huì)對(duì)員載平衡效率產(chǎn)生巨大的不利影響，因?yàn)樗鼈円淮笈脩簦ǘ皇且粋€(gè)用戶）綁定到一臺(tái)服務(wù)器。對(duì)于大的用戶組，服務(wù)器經(jīng)常用于幫助傳輸或者緩存HTTP流。（AOL）用C類“親和性”時(shí)，就必須冒著突然關(guān)閉一個(gè)服務(wù)器，同時(shí)使一大批用戶不能獲得服務(wù)的風(fēng)險(xiǎn)。狀態(tài)的首選方式是在一個(gè)中心服務(wù)器上。為了達(dá)到容錯(cuò)的目的，中心服務(wù)器通常是集群的兩個(gè)服務(wù)器。當(dāng)用戶首次站點(diǎn)時(shí)，由一個(gè)定制的服務(wù)器端組件生成一個(gè)會(huì)話ID，并且在瀏覽器中。用戶會(huì)話期間的后續(xù)HTTP話ID。會(huì)話ID鍵與一個(gè)文本字符串一起到數(shù)據(jù)庫表中，通過這個(gè)緩存文本字符串可以和檢索二進(jìn)制大對(duì)象（BLOBBLOBSASP組件具有將自己寫入這個(gè)緩存表中并從中讀出的能力。微軟提供了一個(gè)解決擴(kuò)展網(wǎng)絡(luò)時(shí)出現(xiàn)的狀態(tài)問題的很好方案。進(jìn)一步而言，盡力提供一種可持久的、機(jī)器獨(dú)立的狀態(tài)機(jī)制。現(xiàn)在已經(jīng)有一種比較容易的方式。CommerceServer早期的SiteServer,CommerceEdition）的再利用。CommerceServer提供的個(gè)人化服務(wù)能準(zhǔn)確地解決這個(gè)問題。這些個(gè)人化服務(wù)將被寫入數(shù)據(jù)庫，但是這一麻煩的隱個(gè)MMC插件實(shí)，很容易使用。CommerceServerCommerceServer需要800MB的硬盤空間和許多你不需要或不用的東西。不幸地是除了全部裝上別無選擇。此外，對(duì)于個(gè)人化數(shù)據(jù)的是通過LDAP連進(jìn)行的，這種連接比通過ADO和