上下文
您已經決定在設計或修改基礎結構層時使用羣集，以便在能夠適應不斷變化的要求的同時保持良好的性能。
問題
在保持可接受的性能級別的同時，如何設計一個可適應負載變化的、可伸縮的基礎結構層？
影響因素
在設計可伸縮的基礎結構層時，請考慮下列影響因素：
對於任何指定的應用程序來說，單獨的服務器會受到最大負載容量的限制。例如，如果單臺服務器將 Web 頁作爲基於 Web 的應用程序的一部分提供給用戶，而且用戶或事務負載增加並超過了服務器的限制，則應用程序性能將降至預期值以下，在最壞的情況下還會變得不可用。
單獨的服務器具有最大物理性能限制，包括總線速度、內存量、處理器數和任一服務器可以使用的外圍設備數等限制。例如，如果服務器只能容納四個處理器，則不能爲了提高性能而添加第五個處理器。
某些應用程序對於可以使用的 CPU 數有限制。
服務器作爲單獨的實體，在解決方案中是故障單點。如果只有一臺服務器負責在應用程序內傳遞組件的功能，則它的故障會導致應用程序運行失敗。
添加服務器會增加管理和監視服務器硬件及其關聯軟件的複雜性。
解決方案
將 服務或應用程序安裝到多臺服務器上，並將這些服務器配置爲共享工作負荷。這種類型的配置就是 Load-Balanced Cluster。負載平衡通過將客戶端請求分散在多臺服務器上，從而提高了基於服務器的程序（如 Web 服務器）的性能。負載平衡技術（通常稱爲"負載平衡器"）可以接收傳入請求，並根據需要將它們重定向到特定主機。有負載平衡功能的主機能夠同時響應不同客 戶端請求，甚至是來自同一客戶端的多個請求。例如，Web 瀏覽器有可能從羣集中的不同主機獲得單個 Web 頁所包含的多個圖像。這就分散了負載，加快了處理速度，並縮短了對客戶端的響應時間。
負載平衡器使用不同的算法控制通信流量。這些算法用於以智能方式分散負載，並/或最大限度地利用羣集內的所有服務器。這些算法中的一部分示例包括：
循環法。循環算法將負載均衡地分配給每臺服務器，而不考慮當前的連接數或響應時間。循環法適合於羣集中的服務器具有相同處理能力的情況；否則，一些服務器收到的請求可能會超過它們的處理能力，而其他服務器的處理能力則有富餘。
加權循環法。加權循環算法適合於每臺服務器具有不同處理能力的情況。管理員將性能權值手動分配給每臺服務器，而且按照服務器權值自動生成調度序列。然後，系統按照循環調度序列將請求定向到不同的服務器。
最少連接。最少連接算法根據羣集中哪臺服務器當前正在處理的連接數最少，從而將請求發送給該服務器。
基於負載。基於負載算法先判斷羣集中哪臺服務器當前的負載最低，然後將請求發送給該服務器。
此外，一些負載平衡器還具有故障檢測功能。平衡器可以跟蹤服務器或在服務器上運行的應用程序，並在出現服務器故障後停止向該服務器發送請求。圖 1 顯示負載平衡的基本組件。
圖 1:負載平衡組件
當 負載平衡器收到來自客戶端的請求時，羣集組中的一臺服務器將處理該請求。每臺服務器都能夠獨立地處理請求。如果任何服務器因出現錯誤或正在維護而不可用， 其他服務器仍然可以爲請求提供服務而不會受到影響。因此，服務的總體可用性比由單臺服務器處理所有請求的方案要高得多。但是，如果在一組軟件負載平衡服務 器前面使用單個物理負載平衡器或單個網絡交換機，將會引入另一個故障單點。可以使用冗餘負載平衡設備和/或交換機來減少這類風險。
會話狀態管理
在 完整的用例中，應用程序通常需要在各個步驟之間與用戶交互。在用戶實現其目標的過程中，他們在交互時所作的每個響應會影響可供用戶使用的選項和應用程序的 狀態。術語"會話狀態"通常用於描述這種以用例爲中心的狀態。此會話狀態的一部分僅僅用於跟蹤任務的進度，並在使用結束後丟棄該部分；如果用例成功結束， 則將會話狀態的其他部分保存在數據庫中進行長期存儲。例如，在使用聯機購物車的用戶選擇結帳按鈕（購物車中至少有一個項目時，纔會啓用該按鈕）之前，很少 要求該用戶提供支付或運送信息。
分佈式應用程序通常通過網絡連接調用遠程服務器上的軟件組件。應用程序必須跟蹤在各步驟之間會話狀態發生的更改，以提供它們之間的連續性。應用程序設計人員通常在以下三個基本位置中的某一個維護會話狀態：
客戶端。應用程序設計人員將每個用戶的會話狀態存儲在用戶的計算機上。
中間服務器。應用程序設計人員將會話狀態存儲在一臺在客戶端計算機與永久存儲用戶信息的數據庫服務器之間作爲中介的計算機上。
數據庫服務器。應用程序設計人員將會話狀態與其他長期應用程序和用戶數據一起存儲在數據庫服務器中。
只 有中間服務器方法影響此模式。每種方法及其優缺點在 Designing for Scalability with Microsoft Windows DNA [Sundblad00] 的第 2 章"Designing for Scalability"中有詳細說明。
如 果所有服務器都是無狀態的（就是說，在服務器處理請求後，服務器的狀態將還原爲默認值），一個簡單的解決方案（如圖 1 中所示的解決方案）就足夠了。在兩種情況下服務器可以是無狀態的。其一，客戶端不需要會話；也就是說，每個請求都是單獨的工作單元，並且在請求之間沒有持 續存在的臨時值。其二（稱爲"客戶端會話管理"），客戶端本身將保存會話的狀態，並在請求內發送會話狀態信息，以便任何服務器都可以檢查到請求，並繼續處 理它。
在服務器會話管理方案中，服務器負責維護用戶會話的狀態。服務器會話管理要求負載平衡器將同一個用戶會話內來自一個客戶端的所有請求定向到同一個服務器實例。此機制通常稱爲"服務器關係"。
會 話管理本身的一個問題是：如果服務器因出現錯誤或進行維護而脫機，則可能會丟失客戶端的工作，而且客戶端必須重新發送丟失的會話中已經發送的所有請求。在 某些情況下，偶然丟失會話對用戶來說不是大問題。例如，在聯機地圖搜索應用程序中，如果服務器丟失用戶剛鍵入的地址，用戶重新鍵入該地址不會是一件太麻煩 的事情。但是，在其他情況下，會話丟失可能是極其不便的。例如，在具有無狀態客戶端的聯機租用應用程序中，用戶可能要花費 10 分鐘的時間才能將幾頁有價值的信息鍵入到合約表格中。如果負載平衡組中的一臺服務器脫機，您當然不希望用戶再花費 10 分鐘重新鍵入所有信息。爲避免因負載平衡組中的服務器出現故障而導致的會話丟失，可以使用以下兩種方法：集中式狀態管理和異步會話狀態管理。圖 2 顯示集中式狀態管理。
圖 2:負載平衡和集中式狀態管理
集 中式狀態管理方法將會話狀態信息存儲在一臺與應用程序服務器處於不同層的集中式服務器上。應用程序服務器每次收到作爲會話一部分的請求時，它先從會話管理 服務器提取會話狀態，然後處理該請求。會話管理服務可以是運行在存儲了共享資源並且具有高可靠性配置的服務器上的數據庫或另一類型的應用程序。有關如何改 進共享資源上的容錯的詳細信息，請參閱 Failover Cluster 模式。
圖 3 顯示異步會話狀態管理。
圖 3:負載平衡和異步會話狀態管理
使 用異步會話狀態管理方法時，每臺服務器只要發生會話狀態更改，就會將其會話狀態廣播給所有其他服務器；因此，每臺服務器都包含所有會話的狀態信息，而且任 何服務器都可以處理包含在會話中的請求。會話狀態還會在單獨的服務器出現故障之後繼續存在。因爲不需要額外的設備，所以此解決方案更經濟；但是，因爲它涉 及異步調用，所以其配置和維護更困難。在每臺服務器上存儲所有會話的狀態還會導致效率更低。
實現
負載平衡實現的兩種主要類別是：
基於軟件的負載平衡。基 於軟件的負載平衡包括在負載平衡羣集中安裝在服務器上的特殊軟件。軟件根據不同的算法分派或接受客戶端向服務器發出的請求。算法可以是簡單的循環算法，也 可以是考慮服務器關係的更復雜的算法。例如，Microsoft® Network Load Balancing 是用於 Web 場的負載平衡軟件，而 Microsoft Component Load Balancing 是用於應用程序場的負載平衡軟件。
基於硬件的負載平衡。基於硬件的負載平衡是由以軟件爲其提供負載平衡功能的專用交換機或路由器組成的。此解決方案將交換功能和負載平衡功能集成到單個設備中，從而減少了實現負載平衡所需的額外硬件數量。但是，將這兩項功能組合在一起，也會使設備的故障排除工作變得更困難。
示例
爲了幫助您更好地瞭解如何使用負載平衡實現可伸縮性，下面的討論將現有的非負載平衡解決方案（該方案在應用程序層中包含單個系統，即故障單點）與保持性能並提供可用性的高伸縮解決方案進行比較。
非負載平衡層
一開始，組織可能採用類似於圖 4 中所描述的解決方案體系結構，該體系結構可能滿足最初的性能要求。但是，隨着負載的增加，應用程序層必須適應增加的負載，才能保持可接受的性能。
圖 4:具有單臺應用程序服務器的基本解決方案
在圖 4 中，應用程序層只包含一臺爲客戶端請求提供服務的應用程序服務器 (AppServer20)。如果該服務器超載，則解決方案的性能將降至不可接受的級別，或變得不可用。
負載平衡層
要提高可伸縮性並保持性能，組織可能會使用負載平衡器來擴展應用程序層。在下面的示例（如圖 5 所示）中，將兩臺服務器添加到應用程序層以創建負載平衡羣集，該羣集將訪問數據層數據，併爲客戶端層中的客戶端提供對應用程序的訪問服務。
圖 5:具有可伸縮應用程序層的解決方案
這 將得到一個標準的負載平衡設計。硬件設備或運行在主機上的軟件將虛擬主機名 (AppServer20) 和 IP 地址分配給 AppServer1、AppServer2 和 AppServer3。負載平衡的羣集向網絡公開此虛擬 IP 地址和主機名，並在組內的正常運行服務器之間均衡地分配傳入請求的負載。如果 AppServer1 出現故障，則只需將請求定向到 AppServer2 或 AppServer3 即可。取決於提供此功能的技術，可以將一定數目的額外服務器添加到負載平衡的羣集中，以最大限度地提高可伸縮性，並超前滿足不斷增長的需求。
結果上下文
Load-Balanced Cluster 模式具有下列優缺點：
優點
改進的可伸縮性。可伸縮的負載平衡層使系統可以在提高可用性的同時保持可接受的性能級別。
更高的可用性。通過負載平衡，可以使服務器脫機進行維護，而不會讓應用程序不可用。
可能會降低成本。與更高成本的多處理器系統相比，多臺低成本服務器通常會降低成本。
缺點
開發過程複雜。如果解決方案必須維護各個事務或用戶的狀態，則開發負載平衡的解決方案會是很困難的。
沒有解決網絡故障問題。如果在客戶端會話過程中服務器或網絡出現故障，則可能需要重新登錄才能重新驗證客戶端和重新建立會話狀態。