安道生練功房 - 分享經驗，累積智慧

一般我們設定Nortel Application Switch 2216(以前叫作Alteon Application Switch 2216)時，對於電子商務型網站等應用，需要讓使用者登入後存取同樣的伺服器（建立Persistence），通常會使用minmiss，hash或phash metric，針對來源IP去計算出hash值，然後找出對應的real server。不過這樣的方式，通常會導致如果來源IP是proxy或公司內部OA網路NAT出來的上網IP，甚至為了作壓力測試時產生的一堆模擬用戶，通通被導致同一部主機，造成空有一堆主機的computing power卻只能跑到一部主機的負載量。這樣子恐怕不是公司花錢買一堆伺服器想要看到的事。

那要如何解決這個問題呢？由於上述的方法是在connection建立之時，決定real server是哪部，我們可以改為等connection建立完畢之後，再決定real server是哪部，這樣子稱為delay binding。而決定的方式可以透過cookie來達成。主要的原理大致如下：
1. 用戶端送出未含Cookie的HTTP Request給負載平衡交換器
2. 負載平衡交換器將該HTTP Request依metric(例如round-robin)決定出後端real server
3. 伺服器處理完之後將HTTP Response送給用戶端時, 負載平衡交換器自動插入一個cookie，名稱可以自行定義，例如real_server
4. 用戶端下次送出的HTTP Request表頭將含有剛剛的real_server Cookie，此時負載平衡交換器會自動處理，以判斷出real server。

如此一來，透過round-robin這種輪流分配的負載平衡演算法，將可以平均分散負載到整個server farm的每部主機，即使來源端是同一個IP，也可以有效分散到各部主機。

詳細的說明及設定步驟可以參考以下原廠的網址或由本站下載附件：
http://www116.nortel.com/docs/bvdoc/alteon/tt/TT-0501402a.pdf

謝謝老大的分享，受教
不過，這個 solution 應該只能用在 HTTP 的服務，一般 TCP 的服務好像沒辦法
透過 ab 去作壓力測試 ab -n 50000 -c 200 http://203.66.125.200/
效能似乎也沒甚麼影響，似乎不錯

增加前：
ap Server 1:
Complete requests: 50000
Failed requests: 5866
ap Server 2:
Complete requests: 50000
Failed requests: 5944
ap Server 3:
Complete requests: 50000
Failed requests: 6050
ap Server 4:
Complete requests: 50000
Failed requests: 5375
ap Server 5:
Complete requests: 50000
Failed requests: 5280
ap Server 6:
Complete requests: 50000
Failed requests: 5334

增加後：
ab Server 1:
Complete requests: 50000
Failed requests: 5655
ab Server 2:
Complete requests: 50000
Failed requests: 5949
ab Server 3:
Complete requests: 50000
Failed requests: 5835
ab Server 4:
Complete requests: 50000
Failed requests: 5375
ab Server 5:
Complete requests: 50000
Failed requests: 5494
ab Server 6:
Complete requests: 50000
Failed requests: 5365