使用 Keepalived 進行主動/主動 HAProxy 設置的任何問題
抱歉，如果以前有人問過這個問題，但我似乎找不到太多關於它的資訊。
我們將使用 HAProxy 來平衡我們的 MariaDB Galera 集群。我在這方面看到的所有文章/教程都使用 Keepalived（或類似的東西）來進行主動/被動 HAProxy 設置。
是否有充分的理由說明您不應該進行主動/主動設置？
每個 HAProxy 節點可以有一個固定 IP，也可以有一個浮動 IP。正常情況下，請求是在兩個 HAProxy 節點之間共享的，如果一個節點宕機，另一個會使用它的浮動 IP 並處理兩個 IP 下的請求。當另一個重新啟動時，它會重新獲取其浮動 IP 和負載份額。
我很感激你對此的意見。
盧克
對於同一資源，不要使用兩個虛擬 IP 地址進行主動/主動設置的重要注意事項是
- 您如何通過兩個虛擬 IP 分配請求
- 您如何處理粘性會話、親和性、持久性等，即當後續請求開始轉到虛擬 IP1 然後轉到虛擬 IP2 時會發生什麼，您是否需要將這些請求轉到同一後端伺服器。
- 當虛擬 IP 地址故障轉移到另一台主機時會發生什麼？
2020 年更新：
keepalived已經過時了一段時間，因為它在虛擬雲 (AWS) 中不起作用。一點歷史
曾幾何時，辦公室裡有一個（思科）網際網路路由器。路由器為所有機器提供網際網路訪問，這很好。
…然後路由器死了，每個人的網際網路都被破壞了，而且很糟糕。
事實證明，任何東西都需要兩個才能有冗餘。因此，思科開始提供成對的可協同工作的路由器。
這是通過稱為HSRP、VRRP或CARP的協議完成的。HSRP是解決問題的原始 cisco 製造的協議。它後來被標準化為VRRP ， https://www.rfc-editor.org/rfc/rfc3768（1998 年）已被大多數網路設備和供應商實施。BSD 人重新發明了他們自己的協議CARP來做同樣的事情，由於對許可或專利的擔憂，他們無法採用 VRRP。
Keepalived（和 uCARP）是實現 VRRP（和 CARP）的軟體。可以在兩個正常 Linux 伺服器上設置它以在它們之間進行故障轉移。
AWS 的崛起與 VRRP 的終結
VRRP如何運作？對於初學者來說，它需要一個浮動 IP，比如說 192.168.1.254，在任何時間點只有一個路由器擁有該 IP 的所有權。網路中的設備只是將流量發送到該（浮動）IP 並到達活動路由器，他們不知道它是浮動的，也不在乎。兩台路由器不斷相互通信，如果其中一台掛掉，另一台路由器接管 IP 並開始處理流量。
此時需要熟悉 OSI 網路第 2 層和第 3 層（MAC 和 IP）。網路設備使用MAC和IP地址進行通信，地址使用ARP 解析。
浮動 IP 被接管的概念涉及網路堆棧中的許多惡作劇（上面的所有首字母縮略詞），它不是完全設計的，也不是預期的行為。
在物理網路上，多台電腦以物理方式插入一個乙太網交換機，它通常可以工作。
在虛擬機上，它通常不起作用。虛擬網路必須處理網路流量（MAC 和 IP 層），它通常會阻止魔術數據包或隔離虛擬主機以阻止 VRRP 執行。
在主要的虛擬雲（AWS、Google 和 co）上。這絕對行不通，而且是故意的。想像一下，如果一個 AWS 實例可以從另一個 Linux 實例（可能來自另一個客戶）接管 IP（所有流量）。我勒個去？！
雲和 CDN 解決方案
雲提供商提供負載均衡器解決方案，請參閱 AWS ELB 和 Google Cloud 負載均衡器。它們帶有針對此問題的內置冗餘，因此您不必考慮它。keepalived 已經過時了。
下一個方面是 CDN（CloudFlare、Akamai）。如今，所有公共網站都執行在提供記憶體、過濾和 DDoS 保護的 CDN 後面。CDN 可以在多個上游伺服器之間提供負載平衡。只需配置所有單獨的伺服器，流量就會被拆分。
最後但並非最不重要的。keepalived 只允許在眾多伺服器中擁有一個活動伺服器，輕描淡寫會浪費資源。這實際上是現實世界中的一個災難性問題，因為事情需要擴展，而不能通過設計擴展。今天使用的故障轉移解決方案（如在雲和 CDN 中發現的那樣）旨在將流量分配到多個活動的目的地。實現起來要復雜得多，並且是在不同的層上累積完成的（參見
DNS,Anycast,OSPF,BGP）。keepalived 不再是全域的一部分。