如何在 Amazon EC2 上部署可擴展、可靠的 haproxy 集群？
我們需要一些比 ELB 提供的更高級的功能（主要是 L7 檢查），但是如何使用 EC2 處理諸如 haproxy 之類的心跳和高可用性之類的事情並不明顯。我們很有可能在集群中需要 3 個或更多 haproxy 節點，因此兩個節點之間的簡單心跳是行不通的。
似乎在 haproxy 節點前面有一個心跳層將是可行的方法，可能使用 IPVS，但隨著 EC2 集群的變化處理配置更改（通過有意的更改，如擴展，或無意的，如失去EC2 節點）似乎很重要。
優選地，該解決方案將跨越至少兩個可用區。
回答問題：不，會話不粘。是的，我們需要 SSL，但理論上這可以完全由另一個設置來處理 - 我們能夠將 SSL 流量引導到與非 SSL 流量不同的位置。
好的，我自己從未建構過具有 SmugMug 級別流量的 AWS 負載平衡解決方案，但僅考慮理論和 AWS 的服務，我就想到了一些想法。
最初的問題缺少一些往往會影響負載平衡設計的東西：
- 粘性會話與否？最好不要使用粘性會話，而讓所有負載均衡器 (LB) 使用循環 (RR) 或隨機後端選擇。RR 或隨機後端選擇簡單、可擴展，並在所有情況下提供均勻的負載分佈。
- SSL 與否？SSL 是否在使用，以及請求的百分比，通常會對負載平衡設計產生影響。通常最好儘早終止 SSL，以簡化證書處理並使 SSL CPU 負載遠離 Web 應用程序伺服器。
我是從如何保持負載平衡層本身高可用的角度來回答的。通過 L7 負載均衡器中內置的執行狀況檢查來保持應用程序伺服器的 HA。
好的，有幾個想法應該可行：
1）“AWS方式”：
- 第一層，在最前面，使用 L4 (TCP/IP) 模式的 ELB。
- 第二層，將 EC2 實例與您選擇的 L7 負載均衡器（nginx、HAProxy、Apache 等）一起使用。
好處/想法： L7 負載均衡器可以是相當簡單的 EC2 AMI，全部從同一個 AMI 複製並使用相同的配置。因此，Amazon 的工具可以處理所有 HA 需求： ELB 監控 L7 負載均衡器。如果 L7 LB 死亡或變得無響應，ELB 和 Cloudwatch 會自動生成一個新實例並將其放入 ELB 池中。
2）“帶有監控方式的DNS輪詢：”
- 使用基本的 DNS 循環法在幾個 IP 地址上獲得粗粒度的負載分佈。假設您為您的網站發布了 3 個 IP 地址。
- 這 3 個 IP 中的每一個都是一個 AWS 彈性 IP 地址 (EIA)，綁定到一個 EC2 實例，並帶有您選擇的 L7 負載均衡器。
- 如果 EC2 L7 LB 當機，兼容的使用者代理（瀏覽器）應該只使用其他 IP 之一。
- 設置外部監控伺服器。監控 3 個 EIP 中的每一個。如果其中一個變得無響應，請使用 AWS 的命令行工具和一些腳本將 EIP 移動到另一個 EC2 實例。
**好處/想法：**如果使用者代理無響應，兼容的使用者代理應該自動切換到另一個 IP 地址。因此，在發生故障的情況下，只有 1/3 的使用者會受到影響，而且大多數使用者不會注意到任何事情，因為他們的 UA 會默默地故障轉移到另一個 IP。你的外部監控箱會注意到一個 EIP 沒有響應，並在幾分鐘內糾正這種情況。
3) DNS RR 到 HA 伺服器對：
基本上這是 Don 自己對一對伺服器之間的簡單心跳的建議，但對多個 IP 地址進行了簡化。
- 使用 DNS RR，為服務發布多個 IP 地址。按照上面的範例，假設您發布了 3 個 IP。
- 這些 IP 中的每一個都連接到一對EC2 伺服器，因此總共有 6 個 EC2 實例。
- 這些對中的每一個都使用 Heartbeat 或其他 HA 解決方案以及 AWS 工具來保持 1 個 IP 地址處於活動狀態，處於主動/被動配置中。
- 每個 EC2 實例都安裝了您選擇的 L7 負載均衡器。
**好處/想法：**在 AWS 完全虛擬化的環境中，實際上並不那麼容易推理 L4 服務和故障轉移模式。通過簡化為僅保留 1 個 IP 地址的一對相同伺服器，推理和測試變得更加簡單。
**結論：**同樣，我實際上並沒有在生產中嘗試過任何這些。就我的直覺而言，在 L4 模式下使用 ELB 的選項一和作為 L7 LB 的自我管理 EC2 實例似乎最符合 AWS 平台的精神，也是亞馬遜最有可能在以後投資和擴展的地方。這可能是我的第一選擇。