持久性負載平衡最佳實踐
我們執行一個 Web 應用程序，為越來越多的客戶提供 Web API。首先，客戶端通常是家庭、辦公室或其他向我們的 API 送出分塊 http 上傳的無線網路。我們現在已經擴展到處理更多的移動客戶端。這些文件從幾 k 到幾 gig，被分解成更小的塊並在我們的 API 上重新組合。
我們目前的負載均衡是在兩層執行的，首先我們使用循環 DNS 為我們的 api.company.com 地址通告多個 A 記錄。在每個 IP 上，我們託管一個 Linux LVS：http ://www.linuxvirtualserver.org/ ，負載平衡器查看請求的源 IP 地址以確定將連接交給哪個 API 伺服器。這個 LVS 盒子配置了 heartbeatd 來互相接管外部 VIP 和內部網關 IP。
最近，我們看到了兩種新的錯誤情況。
第一個錯誤是客戶端在上傳過程中從一個 LVS 振盪或遷移到另一個 LVS。這反過來又會導致我們的負載均衡器失去對持久連接的跟踪並將流量發送到新的 API 伺服器，從而中斷跨兩個或更多伺服器的分塊上傳。我們的目的是讓下游記憶體名稱伺服器、作業系統記憶體層和客戶端應用程序層遵守 api.company.com（我們設置為 1 小時）的循環 DNS TTL 值。大約 15% 的上傳內容會出現此錯誤。
我們看到的第二個錯誤要少得多。客戶端將啟動到 LVS 盒的流量並路由到它後面的 realserver A。此後，客戶端將通過 LVS 框無法辨識的新源 IP 地址進入，從而將正在進行的流量路由到也在該 LVS 後面的 realserver B。
鑑於我們在上面部分描述的架構，我想知道人們使用更好的方法的經驗是什麼，這將使我們能夠更優雅地處理上述每個錯誤情況？
2010 年 5 月 3 日編輯：
這看起來像我們需要的。源 IP 地址上的加權 GSLB 散列。
對此的規範解決方案是不依賴最終使用者 IP 地址，而是通過 cookie 使用帶有“粘性會話”的第 7 層 (HTTP/HTTPS) 負載平衡器。
粘性會話意味著負載均衡器將始終將給定客戶端定向到同一後端伺服器。通過 cookie 意味著負載均衡器（它本身是一個功能齊全的 HTTP 設備）插入一個 cookie（負載均衡器自動創建和管理）以記住給定 HTTP 連接應該使用哪個後端伺服器。
粘性會話的主要缺點是後端伺服器負載可能變得有些不均勻。負載均衡器只能在建立新連接時公平地分配負載，但鑑於現有連接在您的場景中可能是長期存在的，那麼在某些時間段內，負載將不會完全公平地分配。
幾乎每個第 7 層負載均衡器都應該能夠做到這一點。在 Unix/Linux 上，一些常見的例子是 nginx、HAProxy、Apsis Pound、帶有 mod_proxy 的 Apache 2.2 等等。在 Windows 2008+ 上，有 Microsoft 應用程序請求路由。作為家電，Coyote Point、loadbalancer.org、Kemp 和 Barracuda 在低端領域很常見；F5、Citrix NetScaler 等高端產品。
HAProxy 的作者 Willy Tarreau 在這裡對負載平衡技術進行了很好的概述。
關於 DNS 循環：
我們的目的是讓下游記憶體名稱伺服器、作業系統記憶體層和客戶端應用程序層遵守 api.company.com（我們設置為 1 小時）的循環 DNS TTL 值。
不會的。而DNS Round Robin 不適合負載平衡。如果沒有其他東西能說服您，請記住，由於最長前綴匹配固定，現代客戶端可能更喜歡一個主機而不是所有其他主機，因此如果移動客戶端更改 IP 地址，它可能會選擇切換到另一個 RR 主機。
基本上，通過將 2 個或更多 RR 記錄指向高可用 IP 地址，由主動/被動或主動/主動 HA 中的實際負載平衡器處理，可以使用 DNS 循環作為粗粒度負載分佈。如果這就是您正在做的事情，那麼您不妨為那些具有較長生存時間值的 DNS RR 記錄提供服務，因為相關的 IP 地址已經高度可用。