目錄
前言
本地是對論文《服務器池的高可用 N+1 冗餘結構模型》的學習記錄，詳細請瀏覽論文。
高可用集羣架構
- 一主多備架構：同一時間只有一個 Master 節點提供服務，多個 Slave 備份節點用於替換。
- 多活架構：同一時間有多個處於 ACTIVE 狀態的節點提供服務，通常結合負載均衡策略使用。
高可用集羣模型模型
- N+1 模型：有 N 個在工作，1 個空閒作爲冗餘。
- N/N 模型：N 個節點中同時運行 N 個服務。
N+1 模型
服務器機羣的高可用性需要靠雙前端負載分配器和後端服務器池來保障，經典案例爲：HAProxy + Keepalived 架構。雙前端結構消除了前端單一故障點隱患，後端服務器池屏蔽了服務器的故障所引起的服務中斷的情況。雙前端結構是高可用機羣應用最廣泛的模型，許多早期的服務器都採用這種方式保證服務器可靠運行。爲追求更高的可靠性，還會擴展到 3 個或更多的節點，例如：3 節點仲裁架構。
高可用系統會將某故障服務器上的工作遷移到其他節點，以保證爲客戶繼續提供服務。服務遷移的前提就是能夠及時準確地發現失效節點，即心跳檢測機制。常見的心跳檢測方案有信任度模型、投票模型和鄰居模型，目的在於提出對多於 2 個節點的服務器池的心跳檢測機制。
- 投票模型：在運行時是一種全連通狀態，網絡通信量較大，不適合大型機羣的應用;
- 鄰居模型：系統中只通過邏輯相鄰的 2 個節點的狀態就可以確定檢測節點是否失效。
- 分佈式多機心跳模型：在服務器機羣中利用選舉機制選出一個主節點，用於檢測其他從節點的健康狀況。 分佈式多級心跳模型的優勢在於將機羣服務器間複雜的全連通檢測模式轉變成主從模式，減少了服務器和網絡資源佔用。
但是，這些服務器池的容錯機制建立在降低系統整體服務處理能力的基礎上，故障服務器的工作量通過負載分配算法重新分配到其他可用的服務器上，這樣既加重了服務器池的負載，也增加了可用服務器故障的可能性。
N+1 冗餘服務器池的高可用系統可以改進服務器池的上述缺陷。N+1 模型利用了備份機不參與系統正常運行的優勢，備份機總是處於初始狀態，因此，由備份機接管故障服務器等於快速地重啓了故障的服務器，從一定程度上說相當於對服務器系統進行了再生操作。N+1 模型通常適用於服務器池規模較小且部署在同一網段的局域網內的情況。
在典型的高可用服務器機羣結構的基礎上，N+1 高可用服務器池增加了一個冗餘節點，爲後端服務器池做冗餘備份。冗餘節點在 N+1 冗餘結構中作爲控制端出現， 服務器池中的服務器被動讀取控制端的狀態，進而及時調整自身動作，並接受控制端的服務檢測。後端服務器通過心跳信號不斷向冗餘節點通告自身的健康情況，同時冗餘節點也主動地發起應用層檢測，這樣做的目的是能夠準確地瞭解服務器池的故障狀況。
N+1 高可用服務器池的軟件主要分佈在冗餘節點和服務 器池上，按照功能劃分爲 7 個模塊：
- 服務檢測模塊，在傳輸層對應用服務進行檢測，通過檢測 TCP 連接同步是否有同步回覆數據包返回，來驗證基於連接的 Web 應用服務是否正常。
- 多元定時器模塊，負責設定和維護服務器池中所有服務器的心跳超時定時器，用單定時器模擬多定時器的功能。
- 心跳檢測模塊，用於不斷地接收後端服務器的心跳信息，以判斷服務器池的運行狀況。
- 節點狀態發佈模塊，它不停地向服務器池廣播冗餘節點當前的運行狀態，通知所有後端服務器，讓它們知道服務器池是否有故障存在，進而調整它們的運行狀態。
- 冗餘節點狀態檢測模塊，與節點狀態發佈模塊的功能相對應，隨時接收冗餘節點狀態的變更，以便對所在服務器的心跳信息進行調整，使之能在恢復功能後立刻重新加入服 務器池。
- 故障處理模塊，用來處理後端服務器的故障，在發現某個服務器在一段時間內沒有心跳信號，或者在應用服務端口的連接請求沒有迴應時，它將激活冗餘節點上的備份服務， 接替故障的服務器繼續提供服務，相應地也將冗餘節點從冗餘態切換成爲替換態。
- 故障處理模塊，用來處理後端服務器的故障，在發現某個服務器在一段時間內沒有心跳信號，或者在應用服務端口的連接請求沒有迴應時，它將激活冗餘節點上的備份服務， 接替故障的服務器繼續提供服務，相應地也將冗餘節點從冗餘態切換成爲替換態。
服務器池 N+1 冗餘結構功能模塊如下圖所示：
N+1 模型關鍵技術
單進程多定時器的設計
在 N+1 服務器池模型中，冗餘節點負責週期性地監測服務器池的 N 個服務器的狀態。冗餘節點的管理控制軟件必須具備並行地接收所有服務節點心跳信息的能力，這樣就要求該軟件爲每個服務節點建立和管理一個心跳定時器，通過定時器對其進行生存狀態的監測。
冗餘節點快速切換技術
冗餘節點主要接管的資源是故障服務器的 IP 地址，故障切換的速度直接取決於 IP 地址的接管速度，因此，冗餘節點快速切換的研究就是對 IP 地址接管的研究。
IP 接管的問題主要在於 ARP 的緩存功能。ARP 協議爲每臺主機設置臨時地址映射緩存表，用於保存網絡地址與物理地址的映射，方便以後取用。正是這個 ARP 緩存表給 IP 地址接管帶來了麻煩。如果服務器主機故障致使無法提供服務，這時即使冗餘節點動態配置了 IP 地址，也會由於其它主 機 ARP 緩存表沒有及時更新而繼續向故障主機發送服務請求，以至於等到 ARP 緩存表中的相應表項老化時才能真正完成 IP 接管。
解決上述問題可以從 ARP 協議本身的特點着手。ARP 協議的常見數據包有 2 種：Request 和 Reply。Request 請求指定 IP 地址的物理地址，Reply 返回 IP 地址的物理地址。請求包與回覆包不需要成對地出現，ARP 協議這種特點的典型應用是 Gratuitous ARP，是指沒有 Request 請求的 Reply 回覆包。接收端可以無條件地接收目的地址是廣播物理地址的 Reply 包，並對 ARP 緩存表做相應的更新操作。請求端也可以發送請求自身 IP 地址的 Request 包，接收端將根據 ARP Request 包的原物理地址更新 ARP 緩存表。
基於 Gratuitous ARP 的服務器池冗餘結構的快速故障切換和故障恢復步驟如下圖：
冗餘節點端的管理控制軟件和服務器端的代理軟件均採用 Gratuitous ARP 機制加速冗餘節點的 IP 接管操作和故障服務器的恢復。
服務器池多級檢測機制
節點監控檢測的項目包括：
- 服務器健康狀態
- 服務進程健康狀態
- 心跳鏈路監控狀態
因此，多級檢測手段並存是十分必要的，心跳檢測和應用服務檢測共同構成了多級檢測機制：
- 當服務節點的心跳信號始終存在，並且其應用服務也能正常工作時，服務節點處於正常態。
- 當心跳信號不存在，但服務仍能正常提供時，服務節點處於非冗餘態。
- 當心跳信號始終存在，應用服務不正常時，服務節點處於不可服務態。
- 當心跳信號和服務都不工作時，服務節點處於非連通態。
服務節點和冗餘節點的狀態轉換如下圖所示：
冗餘節點在 4 種狀態之間轉換，其中：接管態和歸還態屬於臨時狀態。當服務器池沒有失效節點時，冗餘節點處於冗餘態，爲服務器池做冗餘備份。如果檢測到服務器池有失效節點，冗餘節點立刻執行接管操作，這時它進入接管狀態，持續到接管操作完成。接下來，進入替換態，冗餘節點接管失效服務器的工作。如果失效服務器恢復正常，冗餘節點將把工作還給那個服務器，使冗餘節點在切換過程中處於歸還態。服務器重新加入服務器池，冗餘節點又恢復到冗餘態。