用Forefront管理Web服務器負載均衡

當Web服務器的用戶數量比較多時，經過Web服務器負載均衡來提升用戶的訪問性能，是一個比較經常使用的手段。以下圖所示。能夠在企業中同時設置兩臺或者兩臺以上的Web服務器，從而實如今服務期之間負載均衡。如此的話，當有一個用戶訪問某個網頁時，系統會自動挑選一臺比較空閒的服務器來應對用戶的請求。如今主要的關鍵點是，由誰來肯定，這個訪問者應該鏈接到哪一臺服務器呢？給用戶選擇恰當的服務器，不只能夠提升用戶的訪問性能，並且還能夠提升數據的安全性。

1、能夠藉助Forefront來充當裁判的角色

在搭建服務器負載均衡環境時，很重要的一個問題就是如何來肯定哪一臺服務器比較空間，或者說用戶該鏈接在那一臺服務器上？雖然如今很多的服務器軟件都帶有這個功能，可是若是採用Forefront安全網關產品的話，還可以帶來一些額外的安全收益。

如如今以上兩臺Web服務器，雖然是爲了實現負載均衡來設置的。可是兩臺服務器有主次之別。如Web服務器1是主服務器，用戶不只能夠在這臺服務器上進行查詢，並且還能夠更新相關的數據。而對於Web服務器來講，其是輔助查詢，通常用戶只可以查詢，而不可以更新。此時爲了安全起見，顯然會對訪問Web服務器1的用戶進行限制。如企業內部的用戶，只可以訪問Web服務器1。而對於外部用戶，優先訪問的是Web服務器2。當Web服務器2比較繁忙時，才容許外部用戶訪問Web服務器1。此時顯然不是簡單的Web服務器負載均衡能夠實現的。要完成這個需求的話，必需要藉助Forefront的幫助。從而在性能與安全之間達到一個均衡。

如上圖所示，在Forefront安全網關的幫助下，管理員在發佈執行相同角色的Web服務器時(即服務器負載均衡)，能夠控制各個服務器之間的複雜均衡(便可以是徹底的負載均衡，也能夠是有條件的負載均衡)，從而實現入站訪問的高可用性，並提升Web服務器的安全與性能。

2、Forefront服務器負載均衡的主要實現方式

Forefront可以確保負載均衡在無需中斷當前端點鏈接的狀況下在可用Web服務器之間平均分佈請求。這是微軟官方文檔上的一句原話。其實將這句話進行分解，能夠找到兩個關鍵點。一是在不用斷開當前鏈接的狀況下實現Web服務器之間的轉換。二是Web服務器之間平均分佈請求這是一個相對的概念。換句話說，不多是多臺服務器的負荷量是相等的。而是能夠根據必定的規則進行調整。另外Forefront還能夠檢測脫機的服務器，並實現故障轉移等相關的工做。在這裏筆者結合本身的工做靜態，談談其服務器負載均衡的主要實現方式。筆者認爲，在瞭解這些主要實現方式的時候，各位讀者主要關注其相同點與差別。由於在各位讀者本身配製時，須要根據企業的實際狀況來選擇合適本身的實現方式。總的來講，Forefront的Web服務器發佈負載均衡的配置難度並不大。其主要的難點還在於選擇合適企業的實現方式。

在Forefront安全網關中，關於Web負載均衡主要有三種實現方式，分別爲基於源IP的負載均衡、機遇Cookie的負載均衡和循環機制。在後續的內容中，筆者會對這三種方式進行分析，並舉例說明其主要的適用場合。但願這些內容可以對各位選擇合適的實現方式有所幫助。

第一種方式是基於IP的負載平衡或者IP關聯。簡單的說，這就是將客戶端的IP地址與服務器相關聯。如筆者在文章一開始就提到了一個案例。雖然兩個服務器之間的內容是相同的，可是在權限上可能有所差異。此時能夠將某些特定的客戶端IP地址進行指定，其能夠優先訪問哪一臺服務器，或者只容許訪問哪一臺服務器。這種方式每每有安全方面的考慮。不過須要注意的是，這種方式並不支持全部的服務器負載均衡。如根據筆者的瞭解，OutlooK客戶端就不支持這種方式。爲此若是須要採用這種負載均衡的實現手段，管理員必定要事先確認，所採起的應用可以支持這種方式。

第二種方式是基於Cookie的負載平衡或這關聯。簡單的說，這就是指用戶會話語服務器進行關聯。這種方式有一個特色，即當從新啓動Web服務器時，會話關聯仍然能夠提供可靠的關聯。或者說，Forefront 安全網關能夠確保用戶在一次路由到特定應用服務器後繼續使用這個服務器。舉一個簡單的例子。如上圖所示，如今某個用戶已經鏈接到了Web服務器A。此時因爲某種特殊狀況，管理員將Web服務器A從新啓動了。在從新啓動後，會話關聯仍然能夠提供可靠的關聯。爲此在一些特定的應用中，每每創建採用會話關聯。如某些應用程序，特別強調會話的重要性。如淘寶網站。在淘寶網中有購物車的概念。此時即便用戶在不一樣的網頁之間進行切換，可是購物車中的內容可以保證是本身剛纔採購的。這主要就是會話在其中起做用。對於相似的應用，就須要採用這種機遇Cookie的負載平衡或者關聯。

第三種方式是循環機制。這個機制主要是在Web服務器成員之間平均分佈來自不一樣的IP地址的請求。循環機制的主要特色，是可以確保在聯機服務器之間平均分佈針對由Web應用程序的用戶請求。並且這種分佈機制在故障轉移期間也可以保持。並且當發生故障轉移時，系統可以檢測沒有響應的服務器，並在可用服務器之間進行分佈均衡。簡單的說，循環機制其會循環的檢查服務器的可用性。當發現用戶鏈接的某臺服務器不可用或者很是繁忙時，會立刻中斷用戶的鏈接，並將其鏈接到可用的服務器上。而無論用戶當前的會話狀態如何。這種方式有缺陷也有優勢。缺陷是用戶當前會話的相關信息(若是沒有保存)則可能會丟失。由於此時相關信息仍是保存在內存中。當會話強制關閉時，相關信息就會遺失。而優勢是可以提供更高的性能。如如今某個用戶在訪問某個網頁，其是鏈接在Web服務器1訪問的。當其轉向到另一個網頁時，此時這個網頁的訪問量很是的大，基本上都集中在服務器1。而這個網頁的Web服務器2訪問量則比較小。在這種狀況下，若是採用循環機制的話，會將這個客戶的請求從新定位到服務器2。目的就是爲了給這個用戶提供更好的性能。但是問題是，如今換了一個服務器，就至關於新建了一個會話 ，原先的會話也就中斷了。其實這種狀況在實際工做中也比較多建。如咱們打1000號的時候，剛開始可能鏈接的是湖南長沙的站點(可能這個站點比較空)。而後再交接線員轉接到1000號的其餘部門，此時這個1000號站點可能就不是長沙了(當轉接的目標部門比較忙時就會自動轉接到其它部門)。此時因爲相關信息比較獨立，即便當前會話中斷了，丟失相關信息影響也不是很大。或者說，相對於漫長的等待時間來講，這個當前會話信息的丟失所形成的影響能夠忽略不計。

可見不一樣的實現方式其目的雖然相同，可是在細節上仍然有很大的差別。這致使其應用場合也有所不一樣。總之，基於IP的負載平衡或者基於Cookies的負載均衡，其主要的特色是確保用戶在一次路由到特定應用服務器後(如Web服務器1)後續訪問繼續路由到這個服務器。而循環機制的話，則可能會由於特定資源訪問量的變化，在可用的Web服務器之間進行不停的轉換。抓住這兩個主要的差別點，而後結合企業的實際狀況，來判斷到底該採用哪一種實現方式。