親，你的硬體負載平衡器真的均衡了嗎？

       目前使用硬體負載平衡器作為Exchange 的部署情境中，採用硬體負載平衡器一個很好的好處就是應用的負載能夠更均衡的分布到各台後端的伺服器上，目前硬體負載平衡器存在兩種不同的工作模式，一種方式是轉寄，另一種是代理模式。

       轉寄採用的工作模式很類似於微軟的NLB，採用一種無狀態的方式進行轉寄，當服務要求過來，我通過網路檢測來判斷這台伺服器沒有出現宕機的情況下就會將這段報文直接轉寄到相應的機器，而不關心這台機器上相應的進程能夠提供服務，這種模式毫無疑問存在一定的缺點。同時他們的網關採用了當前網路的網關，不需要將網關設定到真正的負載平衡裝置上。

       基於轉寄的缺點是因為他工作在網路層，不關心具體的應用資料相應的伺服器是否能夠接收，基於存在這樣的問題，就出現了7層負載平衡裝置，也就是關心應用程式層資料是否能夠正常的接受和處理，7層負載平衡裝置多工作在代理模式。所以基於這種模式我們能夠對於伺服器健康狀態進行檢測。同時根據連接埠及服務狀態來判斷伺服器是否符合提供相應的服務標準來確定將服務是否轉寄到相應的伺服器上。所以他的工作模式基本上如下圖：

     相對來說，基於應用檢測的代理模式是非常適合企業中相應的部署的，但是如果相應的演算法不正確或者相關的設定不OK，我們在監控伺服器的指標的時候發現美譽實現該有的負載平衡。如下圖，我們當初採用的訪問模式是Cylic，基於這樣一種模式我們的訪問是有負載平衡器將相應的訪問按照一定的順序直接轉寄到每台伺服器上。我們在監控計數器指標的時候發現使用者串連的不均衡，我們主要監控的是Exchange 伺服器的三個指標，是基於RPC CLIENT ACCESS的指標：

1. active user count   活動使用者串連

2. connection count   串連數統計

3. User Count     使用者數統計

 

 

 

 

在設定Cylic的時候我們發現串連數和相應的活動使用者數在某一情況下沒有辦法達到很好的負載平衡，因此我們需要對演算法進行調整。在應用負載平衡器中有一種演算法死基於HASH值進行相應調整的演算法，我們採用Hash同時在中斷連線後不再保留緩衝調整之後我們就能發現我們能夠很好的實現真正的負載平衡。

所以在一般的情況下我們處理設定負載平衡器可能還要在某種程度上保證應用負載平衡裝置能夠很好的運作的話我們就需要持續的對於用戶端串連狀況進行串連，最後這張圖片是我們對應用負載平衡器調整後的結果，各位可以根據這個結果來調整相應的參數。這裡我提出了一些注意的事情和想法，大家可以根據這些路徑去真正尋找你所需要的解決問題的方法，希望對大家排錯能夠有所協助：