High-Availability
如何處理 n 層架構中的伺服器故障？
想像一下，我在自動擴展的雲環境中有一個 n 層架構，比如：
- 故障轉移對中的負載均衡器
- 反向代理層
- 網路應用層
- 數據庫層
每個層都需要連接到下面層中的實例。
連接層以使它們對每層中的節點故障具有彈性的標準方法是什麼？即每一層如何獲取下一層中每個節點的IP地址？
例如，如果所有反向代理都應該將流量路由到所有 Web 應用程序節點，那麼如何設置它們以便它們不會向死的 Web 應用程序節點發送流量，並且當新的 Web 應用程序節點上線時它們可以發送流量給它？
- 我可以執行一個代理來更新所有節點的所有配置，但它似乎效率低下。
- 我可以在每層之間放置一個 LB 對，所以上面的層只需要連接到負載均衡器，但是我該如何處理 LB 當機的問題呢？這似乎只是將 A 層需要知道 B 層中所有節點的 IP 的問題分流到 A 層中的所有節點需要知道 A 層和 B 層之間所有 LB 的 IP 的問題。
對於某些應用程序，如果他們聯繫下一層中沒有響應的節點，他們可以實現重試邏輯，但是有沒有什麼方法可以使某些中間件僅將流量定向到下一層中的活動節點？
如果我在 AWS 上託管，我可以在各層之間使用 ELB，但我想知道如何自己實現相同的功能。
我已經（簡要地）閱讀了關於心跳和keepalived的內容-這些在這里相關嗎？他們談論的虛擬 IP 是什麼，它們是如何管理的？使用它們是否仍然存在單點故障？
像 haproxy 這樣的應用程序負載均衡器可以做到這一點。例如，如果它檢測到來自 Web 伺服器的 5xx 錯誤，它可以將伺服器標記為失敗。此外，如果伺服器未能通過三次握手，它可以將其標記為失敗，並在客戶端繼續等待時嘗試另一台伺服器。
使用keepalived和heartbeat，你可以擁有一對haproxy伺服器。如果一個失敗，另一個接管。
我在這裡使用 haproxy 作為範例，但幾乎任何應用程序負載均衡器（又名 4/7 層負載均衡器）都具有這些特性。