Windows NLB 或 Hardware NLB Solution 的差異或建議為何 ?

首先您必需先瞭解 Network Load Balance 的 Affinity Type 的差異。

下列列出各種 NLB Affinity Type 的說明：
Existing Cookies ：
此種 affinity 的方法是使用Client/Server Session間所傳遞的Cookie資訊來進行 LOAD BALANCE 。

此種方法只適用於使用 HTTP 的通訊協定而不適用於任何 RPC 的通訊協定用戶端。

OWA 使用表單型驗證所以很適合使用此種 affinity 方法或使用 Application Cookies 的 Affinity 方法。

Load Balancer Cookies:
此種 Affinity 方法很類似於 Existing Cookies 。 Load Balancer Cookies是由負載平衡器來產生 Cookies 而非依賴由 Client/Server Session 間所傳遞的 Cookie 資訊來進行負載平衡。

此種方法與Existing Cookies相同僅適用於HTTP通訊協定的負載平衡，不過與Existing Cookies不同的是用戶端還必需支援 Load balancer-generated cookies。

Exchange ActiveSync，Outlook Anywhere，及部份的 Exchange Web Services 並不支援此種負載平衡方法。

OWA，Exchange Control Panel 及 Remote Windows PowerShell 則適合使用此種 Affinity 方法。

Source IP ：
Source IP 是目前最常見使用最廣泛的 Affinity 方法。

負載平衡器會記錄用戶端的來源 IP 以及目地伺服器端的 IP，所有來自相同 Source IP 的 Traffic 在指定時間內都會被導向至相同的目地端伺服器上。

使用此種方法會有兩種主要的缺點：
一 是若用戶端會經常變更 IP Address 則會導致 Affinity 中斷 ( 失敗 ) ，會造成用戶端可能必需被要求重新進行驗證。

如果您的環境中的用戶端會頻繁的變更 IP Address( 例如：手機用戶或行動裝置用戶在不同的無線 AP 區域移動 ) ，則不適用於此種 Affinity 方法。

二 是若您環境中的用戶端會共同使用相同的 Source IP( 例如都是透過 NAT 轉換進行存取 ) 則會造成平衡負載失敗。

因為所有的用戶端都使用相同的 Source IP 時會導致平衡負載器無法平均的分配用戶端流量到目的地端伺服器上，而會導致所有的用戶端流量都往同一個目的地伺服器造成負載不平衡。

SSL Session ID ：
當用戶端開始進行 SSL 加密程序時會產生 SSL Session ID 。

使用 SSL Session ID 有兩個好處：
一 是相較於 Source IP Address 的 Affinity 方法， SSL Session ID 可以辨別出使用相同 Source IP 的用戶端。

二 是使用 SSL Session ID 並不需要進行 SSL 流量的解密。

SSL Session ID 並無法適用於所有的用戶端存取。例如，微軟的 IE8 在處理每一個瀏灠器處理程序時會建立一個新的 SSL Session ，這將導致使用此 Affinity 方法的用戶端負載失敗。

接著您可以參考 Exchange Server 2010 用戶端存取的 Load Balance 的建議


有關於 Network Load-Balance foe Client Access Server 您可以參考下列兩篇 TechNet 的文章內容的描述：
Understanding Load Balancing in Exchange 2010
Load Balancing Requirements of Exchange Protocols

下表為您整理列出負載平衡器的比較：


從上表中可以得知，使用 Software 的 NLB 有下述缺點：
O 無法與 Windows Failover Cluster 一起使用 ，亦即若您的客戶是三合一角色並啟用 DAG 的 HA 機制時將無法使用 Windows NLB 。

O 不支援 Service Health Check 功能 。

由於 Software NLB 只會檢查網路層連線的可用性而無法檢查應用層服務的可用性所以如果在 NLB 中的 CAS Server 的 IIS Service Failed 時，負載平衡器還是會持續將用戶端流量往此 CAS Server 傳送這將會造成用戶端存取及負載平衡的失敗。

O 在我們的測試結果我們不建議您將超過八台 Exchange Server 的 CAS/HUB 架構在 Windows NLB 中，因為這會造成效能使用上的問題。

O 僅支援使用 Source IP 的 Affinity 方法。

結論 : 在一個要求高可用性及高可靠度的使用環境中，我們會建議您優先使用硬體式的 NLB 解決方案。