refer: http://blog.csdn.net/ghj1976/archive/2009/03/17/3997840.aspx
最近正在研究如何把CSDN的論壇WEB服務器實現負載平衡（NLB）。下面就是我整理資料筆記：
NLB 的工作原理
NLB算法的特點：
- 在NLB羣集中，每臺服務器都會有一個屬於自己的靜態IP地址，同時NLB羣集中的所有服務器還有一個共同的IP地址—NLB羣集地址；
- 當 客戶向NLB羣集（NLB的虛擬IP地址）發起請求時，其實客戶的請求數據包是發送到所有的NLB節點（即：NLB算法需要NLB羣集中的所有主機都能看 到發往羣集的每一個數據包。），然後運行在NLB節點上的NLB服務根據同樣的NLB算法來確定是否應該由自己進行處理，如果不是則丟棄客戶的請求數據 包，如果是則進行處理。
- 網絡負載平衡使得單個子網上的所有羣集主機可以同時檢測羣集 IP 地址的傳入網絡通信。在每個羣集主機上，網絡負載平衡驅動程序充當羣集適配器驅動程序和 TCP/IP 堆棧間的過濾器，以便在主機間分配通信。
要確保上面算法的特點，單播（Unicast ），多播（Multicast）實現NLB就會有以下的特點：
NLB中的單播（Unicast）
在單播模式下，NLB重新對每個NLB節點中啓用NLB的網絡適配器分配MAC地址（此MAC地址稱爲羣集MAC地址），並且所有的NLB節點均使用相同 的MAC地址（均使用羣集MAC地址），同時NLB修改所有發送的數據包中的源MAC地址，確保使交換機不能將此羣集MAC地址綁定在某個端口上。
工作在單播模式下的NLB可以在所有網絡環境下正常運行，但是由於它的工作特性，具有以下兩個限制：
- 由於NLB所使用的羣集MAC地址沒有綁定在某個具體的交換機端口上，所以所有的NLB通訊均通過在交換機的所有端口上廣播進行，而不管此端口是否連接了NLB節點，這造成了額外的網絡流量負擔；
- 由於所有的NLB節點具有相同的MAC地址，NLB節點之間不能通過自己原有的專用IP地址進行通訊。
單播模式的優點也很明顯：它可以無縫地與大多數路由器和交換機協同工作。
如下圖所示：
單播的其他注意項：
- 在Windows server 2003 SP1中，微軟修改了NLB單播模式的驅動，從而支持陣列成員通過自己原有的專用IP地址進行通訊，詳細信息請參見KB898867，Unicast NLB nodes cannot communicate over an NLB-enabled network adaptor in Windows Server 2003。
- 若我們在NLB創建時選擇單播的模式，在“羣集IP配置”中的“網絡地址”是以“02 - BF”開頭，後面緊跟IP地址的十六進制表示，該網絡地址與實際主機的MAC地址相同，後續加入的主機也將修改爲此MAC地址。
參考：
單播模式下的單個網絡適配器
http://technet.microsoft.com/zh-cn/library/cc757150.aspx
單播模式下的多個網絡適配器
http://technet.microsoft.com/zh-cn/library/cc786134.aspx
NLB中的多播（Multicast）
在多播模式下，NLB不會修改NLB節點啓用NLB的網絡適配器的MAC地址，而是爲它再分配一個二層多播MAC地址專用於NLB的通訊（此MAC地址稱爲羣集MAC地址），這樣NLB節點之間可以通過自己原有的專用IP地址進行通訊。
但是在多播模式中，NLB節點發送的針對羣集IP地址MAC地址ARP（Address Resolution Protocol，地址解析協議）請求的ARP回覆會將羣集IP地址映射到多播MAC地址，而許多路由器或者交換機（包括CISCO的產品）會拒絕這一行 爲。當出現這種情況時，你必須在路由器和交換機上手動添加靜態映射，將羣集IP地址映射到羣集的多播MAC地址。
這種模式的優點是可以通過在交換機的“內容可尋址存儲器”(CAM) 表中創建靜態項，從而使得入站流量僅到達羣集中的主機。
還有一個缺點就是很多路由器不會自動將單播 IP 地址（羣集的虛擬 IP 地址）與多播 MAC 地址關聯起來。如果進行靜態配置的話，一些路由器可以存在這種關聯。若我們在NLB創建時選擇多播的模式，在“羣集IP配置”中的“網絡地址”是以“03 -BF”開頭，後面緊跟IP地址的十六進制表示。
如下圖所示：
IGMP Multicast（IGMP多播）
NLB算法需要NLB羣集中的所有主機都能看到發往羣集的每一個數據包。NLB不允許交換機將羣集的MAC地址關聯到交換機的某個特定端口，從而實現了這 個目的。但是，這種做法也會帶來不想要的副作用，就是發往NLB羣集的所有數據包會在交換機上的所有端口上造成數據“洪水”。這不僅非常麻煩，而且必將會 造成網絡資源的浪費。
爲了解決這個問題，一個被稱作IGMP支持的新特性被引入到了Windows Server 2003之中。該特性有助於將數據“洪水”限制到交換機上與NLB計算機相連接的端口上。通過這種方式，非NLB的計算機不會看到發往NLB羣集的數據， 而與此同時，所有的NLB計算機都可以看到發往羣集的數據，因此滿足了NBL算法的要求。但是，應該指出的是：IGMP支持只有在NLB被配置多播 （multicast）模式時才能啓用。
在選擇多播模式時，後面還有個複選項“IGMP Multicast（IGMP多播）”，若複選此項，就像多播操作模式一樣，NLB 保留原廠 MAC 地址不變，但是向網絡適配器中增加了一個 IGMP 多播地址。此外，NLB 主機會發出這個組的 IGMP 加入消息。如果交換機探測到這些消息，它可以使用所需的多播地址來填充自己的 CAM 表，這樣入站流量就不會擴散到 VLAN 上的所有端口。這是這種羣集模式的主要優點。缺點是有一些交換機不支持 IGMP 探測。除此之外，路由器仍然支持單播 IP 地址到多播 MAC 地址的轉換。在IGMP多播模式下，將採用“01 – 00 - 5E”開頭的MAC地址。在多播的模式下，實體主機之間可以互相通信。
如下圖所示：
NLB對路由器的要求
當羣集已配置爲在多播模式下工作時，如果網絡負載平衡客戶端正在通過路由器訪問一個羣集，請確保路由器滿足以下要求：
- 接受地址解析協議 (ARP) 應答，此應答在 ARP 結構的有效負載部分有一個媒體訪問控制 (MAC) 地址，但正如以太網報頭所確定的，它看上去像來自具有另一個 MAC 地址的站點。
- 接受單播 IP 地址的 ARP 應答，此應答在其 ARP 結構的有效負載部分有一個多播 MAC 地址。
單播模式對路由器沒有要求。
參考：
多播模式下的單個網絡適配器
http://technet.microsoft.com/zh-cn/library/cc759683.aspx
多播模式下的多個網絡適配器
http://technet.microsoft.com/zh-cn/library/cc779600.aspx
附：單播（Unicast），多播（Multicast），廣播（Broadcast） 的區別：
單播：
主
機之間“一對一”的通訊模式，網絡中的交換機和路由器對數據只進行轉發不進行復制。如果10個客戶機需要相同的數據，則服務器需要逐一傳送，重複10次相
同的工作。但由於其能夠針對每個客戶的及時響應，所以現在的網頁瀏覽全部都是採用IP單播協議。網絡中的路由器和交換機根據其目標地址選擇傳輸路徑，將
IP單播數據傳送到其指定的目的地。
單播的優點：
1. 服務器及時響應客戶機的請求
2. 服務器針對每個客戶不通的請求發送不通的數據，容易實現個性化服務。
單播的缺點：
1. 服務器針對每個客戶機發送數據流，服務器流量＝客戶機數量×客戶機流量；在客戶數量大、每個客戶機流量大的流媒體應用中服務器不堪重負。
2. 現有的網絡帶寬是金字塔結構，城際省際主幹帶寬僅僅相當於其所有用戶帶寬之和的5％。如果全部使用單播協議，將造成網絡主幹不堪重負。現在的P2P應用就已經使主幹經常阻塞，只要有5％的客戶在全速使用網絡，其他人就不要玩了。而將主幹擴展20倍幾乎是不可能。
多播（組播）：
主
機之間“一對一組”的通訊模式，也就是加入了同一個組的主機可以接受到此組內的所有數據，網絡中的交換機和路由器只向有需求者複製並轉發其所需數據。主機
可以向路由器請求加入或退出某個組，網絡中的路由器和交換機有選擇的複製並傳輸數據，即只將組內數據傳輸給那些加入組的主機。這樣既能一次將數據傳輸給多
個有需要（加入組）的主機，又能保證不影響其他不需要（未加入組）的主機的其他通訊。
組播的優點：
1. 需要相同數據流的客戶端加入相同的組共享一條數據流，節省了服務器的負載。具備廣播所具備的優點。
2. 由於組播協議是根據接受者的需要對數據流進行復制轉發，所以服務端的服務總帶寬不受客戶接入端帶寬的限制。IP協議允許有2億6千多萬個（268435456）組播，所以其提供的服務可以非常豐富。
3. 此協議和單播協議一樣允許在Internet寬帶網上傳輸。
組播的缺點：
1．與單播協議相比沒有糾錯機制，發生丟包錯包後難以彌補，但可以通過一定的容錯機制和QOS加以彌補。
2．現行網絡雖然都支持組播的傳輸，但在客戶認證、QOS等方面還需要完善，這些缺點在理論上都有成熟的解決方案，只是需要逐步推廣應用到現存網絡當中。
廣播：
主
機之間“一對所有”的通訊模式，網絡對其中每一臺主機發出的信號都進行無條件複製並轉發，所有主機都可以接收到所有信息（不管你是否需要），由於其不用路
徑選擇，所以其網絡成本可以很低廉。有線電視網就是典型的廣播型網絡，我們的電視機實際上是接受到所有頻道的信號，但只將一個頻道的信號還原成畫面。在數
據網絡中也允許廣播的存在，但其被限制在二層交換機的局域網範圍內，禁止廣播數據穿過路由器，防止廣播數據影響大面積的主機。
廣播的優點：
1. 網絡設備簡單，維護簡單，佈網成本低廉
2. 由於服務器不用向每個客戶機單獨發送數據，所以服務器流量負載極低。
廣播的缺點：
1.無法針對每個客戶的要求和時間及時提供個性化服務。
2.
網絡允許服務器提供數據的帶寬有限，客戶端的最大帶寬＝服務總帶寬。例如有線電視的客戶端的線路支持100個頻道（如果採用數字壓縮技術，理論上可以提供
500個頻道），即使服務商有更大的財力配置更多的發送設備、改成光纖主幹，也無法超過此極限。也就是說無法向衆多客戶提供更多樣化、更加個性化的服務。
3. 廣播禁止在Internet寬帶網上傳輸。
參考資料：
Load Balancing and ASP.NET
http://www.hanselman.com/blog/LoadBalancingAndASPNET.aspx
Web Farming with the Network Load Balancing Service in Windows Server 2003
http://www.west-wind.com/presentations/loadbalancing/NetworkLoadBalancingWindows2003.asp
網絡負載平衡算法 Works 內部怎樣
http://support.microsoft.com/kb/556068/zh-cn?spid=3198&sid=770
WEB farm - Load Balancing in Asp.net
http://www.c-sharpcorner.com/UploadFile/gopenath/Page107182007032219AM/Page1.aspx
How to test web load balance
http://www.cnblogs.com/oscarxie/archive/2008/05/20/1203157.html
將asp.net遷移到Load Balance和NAS上的步驟
http://blog.joycode.com/hopeq/archive/2006/03/29/73762.aspx
微軟知識庫中的關於負載均衡的HowTo文章彙總
http://support.microsoft.com/ph/3198/zh-cn?sid=770&aid=1&GSA_AC_More1
TechNet 關於 網絡負載平衡羣集 的內容
http://technet.microsoft.com/zh-cn/library/cc759510.aspx
中文
http://technet.microsoft.com/en-us/library/cc759510.aspx
英文
下面文章中間談到了負載均衡的工作原理
http://technet.microsoft.com/zh-cn/library/aa998796%28EXCHG.65%29.aspx
NLB配置中單播與多播區別
http://hi.baidu.com/hneli/blog/item/656725d3e5471433970a16bd.html
NLB羣集
http://blog.sina.com.cn/s/blog_4b611a45010009hh.html
Using NLB with ISA Server Part 2: Layer 2 Fun with Unicast and Multicast Modes
http://www.isaserver.org/articles/basicnlbpart2.html
IP多播概述
http://www.microsoft.com/china/technet/community/columns/cableguy/cg0202.mspx
TCP/IP學習筆記之九 --- 廣播和多播
http://blog.csdn.net/kmajian/archive/2008/11/27/3389667.aspx
網絡負載平衡關鍵特性
http://technet.microsoft.com/en-us/library/cc758275.aspx
Network Load Balancing
http://www.msxfaq.de/verschiedenes/nlb.htm
Network Load Balancing Technical Overview
http://technet.microsoft.com/zh-cn/library/bb742455(en-us).aspx
網絡技術基礎知識一之ARP協議概說
http://cisco.chinaitlab.com/TCP/38035.html