第 4 層與第 7 層負載平衡
我正在嘗試在為我的數據中心使用第 4 層負載平衡解決方案或第 7 層解決方案之間做出決定。不幸的是（就我的理智而言），我的案例很簡單，兩種解決方案都可以很好地工作，避免了大多數弱點，並沒有真正利用另一個的優勢。無論我們最終使用什麼解決方案，它都必須具有高可用性和高吞吐量。但是我們只打算用它來平衡一組 Web 伺服器的負載，這些伺服器都沒有對“粘性”會話管理（cookie 或 IP）、複雜的重寫規則或就此而言的任何重寫規則有任何要求全部。
負載均衡器將連接到兩台交換機，它們都具有到數據中心聚合層的獨立連接，並使用快速生成樹和交換機用於虛擬化的任何專有協議合併在一起。負載平衡器也將通過交叉電纜相互交叉連結。集群中的所有伺服器都連接到兩台交換機。負載均衡器所要做的就是將流量指向它們。
由於它只是 HTTP，因此我可以使用 HAProxy 或 nginx 之類的第 7 層負載平衡解決方案。但我也可以將 LVS 項目與 ldirectord 或 keepalived 或其他什麼一起使用。
當我看到它們時，我試圖打破它們的優點和缺點，但它最終只是被洗刷了。你會推薦什麼，為什麼？我錯過了什麼嗎？
像 haproxy 這樣的“L7”的一個有用的好處是能夠使用 cookie 來保持同一個瀏覽器訪問同一個後端伺服器。這使得調試客戶端更容易。
L4 平衡可能會在多個後端伺服器上反彈單個使用者。（在某些情況下這可能是有利的，但在調試/分析的意義上，使用“L7”更有價值。）
編輯：使用 HTTP 平衡還有一個潛在的速度優勢。使用 keep-alives 客戶端可以與平衡器建立單個 TCP 會話，然後發送許多 HIT，而無需重新建立新的 TCP 會話（3 次握手）。同樣，許多 LB 保持與後端系統的保持活動會話，從而無需在後端進行相同的握手。
嚴格的 TCP 負載平衡可能無法輕鬆實現這兩者。
/* FWIW：我不會說“L7”或“L4”，我會說 HTTP 或 TCP。但我堅持避免使用 OSI 來描述與它不匹配的事物。*/
我認為從根本上說，如果您不確定要部署什麼，請選擇您覺得簡單自然的東西。測試它（使用 apache bench？）並確保它滿足您的需求。對我來說，HTTP LB 更自然。