作者簡介

Yellowsea，攜程資深技術支持工程師，負責四層負載均衡研發及私有云 k8s cloud provider 開發，關注 Kubernetes、Linux Kernel、分佈式系統等技術領域。

前言

在攜程的服務流量接入架構中，一般是採用四層負載均衡與七層負載均衡相結合的方式，其中四層負載均衡支撐着業務運行的關鍵部分。在業務流量不斷增長的過程中，不斷考驗着四層負載均衡的性能及可靠性。由於原硬件四層負載均衡存在成本高、採購週期長、HA 工作模式等問題，原有的體系難以滿足快速增長的業務需求，迫切需要在開源社區中尋找高性能四層負載均衡軟件化的解決方案。

本文主要講述基於開源的 DPVS 打造攜程的高性能四層軟件負載均衡 TDLB (Trip.com Dpdk LoadBalancer)，其極大的提升了設備的轉發性能，具有高可靠、可擴展、易使用等特性。

一、TDLB 高性能實現

傳統 LVS 負載均衡的功能與硬件設備類似，但由於其性能存在瓶頸，難以滿足攜程四層負載均衡服務的實際業務場景需求。DPVS (https://github.com/iqiyi/dpvs) 結合 DPDK 的特性，解決了 LVS 的性能瓶頸，同時又能滿足原有的負載均衡服務需求。

1.1 DPDK

在內核中，從網卡獲取數據包是通過硬件中斷模式完成，內核態與用戶態的切換耗時，而且切換導致 cache 命中率下降，影響處理數據包的性能。

在 DPDK 中採用 kernel bypass 的設計，通過應用程序主動輪詢的方式從網卡獲取數據包，使應用程序維持在用戶態運行，避免內核態與用戶態切換的耗時問題，提升處理數據包時 cache 的命中率。

1.2 會話無鎖

初期的 LVS 採用全局的會話資源供多個 core 同時使用，多個 core 之間會產生資源的競爭，帶來了鎖的問題。

TDLB 主要使用 fullnat 模式，爲了避免 core 與 core 之間的資源競爭，我們設計了 percore 的會話，作爲有狀態的四層負載均衡必須保證入向流量與出向流量分配至同一個 core，出向流量才能匹配上原先建立的會話。

入向流量可以利用 RSS 將數據包散列至各個隊列，而每個 core 綁定對應的隊列，對於相同的數據包 (sip,sport,dip,dport) RSS 會被分配至同一 core。爲了保證出向回程流量還經過原先的 core 可以爲每個 core 分配不同的 SNAT IP，在 fullnat 模式中，client IP 會被轉化成 SNAT IP，到達 server 後，server 迴應報文的目的 ip 就是原先的 SNAT IP，此時可以藉助網卡的 FDIR (Flow Director) 技術來匹配 SNAT IP，將回程報文分配至對應的 core，確保數據流的出向流量與入向流量分配至同一 core。

1.3 用戶源 IP 透傳

在 FNAT 模式中，後端服務器需要獲取真實客戶端 IP，目前主要有兩種方式：

• TOA：在 TCP 建連完成後傳遞的第一個數據包中，加入帶有客戶端信息的 TCP Option 字段，以此傳遞用戶源 IP，後端服務可以在無感知的情況下獲取用戶源 IP，但是需要在服務器上掛載 TOA 相應的 kernel module。

• ProxyProtocol：在 TCP 建連完成後傳遞的第一個數據包的數據前，加入 ProxyProtocol 對應的報文，其中包含客戶端信息，這部分報文通過單獨的一個數據包發送，避免分片的產生，ProxyProtocol 可以同時支持 TCP 及 UDP，但是需要在服務的應用層提供 ProxyProtocol 的支持。

DPVS 沿用 LVS 中的 TOA（TCP Option Address）的方式傳遞用戶源 IP，TDLB 在 DPVS 的基礎上增加了對 ProxyProtocol 的支持，以此滿足不同服務場景的需求。

1.4 日誌異步寫入

在 DPDK 原日誌存儲機制中，當有大量日誌需要記錄時，單個文件 I/O 鎖帶來的耗時將影響各個 CPU 的數據包處理，嚴重時將影響控制平面流量並導致 BGP 連接斷開。DPVS 在此基礎上加入消息處理機制，各個核產生的日誌將進入消息隊列，由日誌處理的核單獨處理，保證 I/O 不會受到鎖的影響。

在 DPVS 框架基礎上，技術經過初步的消化吸收，建立了 TDLB 的雛形。爲了適配攜程的網絡環境、業務場景及需求，進一步提升單機及集羣的可靠性，TDLB 主要從以下五個方面進行進一步的改造：

• 集羣多活模式

• 資源隔離

• 集羣配置管理

• 健康檢測策略

• 多維度監控

二、集羣會話同步

===============

在集羣多活模式下，服務器的擴縮容會導致路由路徑的重新分配，沒有會話同步功能支持的情況下，已有的連接會失效並導致應用層超時。這對長連接的應用影響更加明顯，影響集羣的可用性，無法靈活的擴縮容應對業務高峯。

2.1 同步策略

核與核間的會話信息資源已被隔離，同時入向業務流量是通過 RSS 進行分配的，所以在集羣中服務器網卡 RSS 配置一致的情況下，同一網卡隊列編號對應核的會話信息可以共用。

爲了做到多臺服務器核與核間的信息交互，爲每個核單獨分配一個內網 IP 地址（FDIR），用於轉發數據包至後端服務器的同時（SNAT IP），用於會話信息同步的 Source Address 及 Dest Address。

在此基礎上，TDLB 集羣使用的 SNAT Pool 需要一個連續的網段，每臺 TDLB 服務器分配一個同等大小的子網，同時會利用 BGP 同時宣告三個子網掩碼不同的 SNAT Pool 網段路由：

• 網卡對應 CPU 分配的子網段 (32-log(n/2))

• 服務器分配的子網段 (32-log(n))

• TDLB 集羣的 SNAT Pool 網段 (32-log(n*m))

以此保證一臺 TDLB 服務器拉出集羣后，其他 TDLB 服務器可以接收到已有連接中 RealServer 的數據包，保證已有連接不會斷開。

1）服務器正常情況

當 Client（CIP: 1.1.1.0, CPort: 5000）請求服務（VIP: 1.1.1.1, VPort: 80）時，路由到 TDLB 0 並通過 SNAT IP（LIP: 10.0.0.0, LPort: 6000）轉發給 RealServer（RIP: 10.0.1.0, RPort: 8080），其中這個 TDLB 集羣對應的 SNAT Pool 是 10.0.0.0/24。

2）服務器異常情況

當 TDLB 0 拉出集羣（停止 BGP 宣告路由）時，Client 的請求被重新路由到了 TDLB 3，由於查詢到了同步的會話信息，因此使用相同的 SNAT IP（10.0.0.0）轉發給相同的 RealServer（10.0.1.0），RealServer 回覆請求時被重新路由到了 TDLB 1 再轉發給 Client。

3）服務器恢復工作

當 TDLB 0 拉入集羣恢復工作後，原本屬於 TDLB 0 的會話會被重新分配給 TDLB 0。

2.2 同步類型

爲滿足服務器處於不同狀態下的會話同步，同步類型分爲兩種：

• 增量同步：在新的連接建立時進行，並隨着數據的傳輸保持連接的狀態同步

• 全量同步：在新的服務器加入集羣時，需要全量同步會話信息，保證接入流量時不對已有連接產生影響

在支持會話同步的基礎上，TDLB 集羣可以採用多活模式進行靈活的水平擴縮容，一方面可以根據業務的需求調整集羣服務器數量降低成本，另一方面可以在用戶無感知的情況下完成 TDLB 集羣的維護。

三、資源隔離

3.1 CORE 與 CORE 之間的數據隔離

利用網卡的 RSS，FDIR 等流控技術，將數據流分配至同一 core，保證了 core 處理數據流時不需要用到全局資源，避免了資源競爭帶來鎖的問題。處理數據流需要使用的相關資源可以在初始化時，爲每個 core 單獨分配資源，利用消息處理機制保證 core 與 core 之間的信息同步。

3.2 NUMA 架構下 CPU 數據隔離

目前服務器主要採用 NUMA 架構，CPU 與 CPU 之間跨 NUMA 訪問數據在一定程度上限制了應用的性能，在 TDLB 設計的目標中儘可能避免跨 NUMA 訪問數據的情況。

在上述設計中，爲了達到會話無鎖的目標，會話流量已經被限定在同一個隊列、core 中，這已經爲資源隔離打下了基礎。在負載均衡服務處理中，高頻訪問的資源有網卡配置、VS 配置、地址、路由、會話表等，四層的會話處理相關資源已被隔離，網絡協議棧中的相關資源與硬件資源相關，因此根據 NUMA 架構中 CPU 的數量各分配獨立的硬件網卡資源即可，在做到資源隔離的同時，充分利用 CPU 的工作能力，提高單臺服務器的負載能力。

3.3 控制平面與數據平面流量隔離

TDLB 的流量主要分成兩部分：

• 控制平面流量：BGP、健康檢測及二層信息交互

• 數據平面流量：負載均衡服務

在初期設計中，控制平面流量需要通過數據平面的相關工作核處理後進入 KNI 隊列中，當業務負載超出閾值時將影響到 BGP 及健康檢測服務，且混雜的流量增加了系統的複雜度，使控制平面的流量難以定位。

對原先的 RSS 配置進行修改，隔離出一個單獨的隊列，同時結合 FDIR 將控制平面流量導入隔離的隊列中，實現控制平面與數據平面流量的隔離。

四、集羣配置管理

在硬件設備以及 LVS 的集羣管理中，都是通過 API 的方式與設備交互，進行配置的管理。當集羣從主備模式轉變爲多活模式時，通過多線程的方式一定程度上可以保證配置的下發效率，但被動的配置更新無法保證服務器進入集羣提供服務時配置的一致性，且每臺服務器獨立的 API 鑑權增加了控制的複雜度。在 k8s 中的 controller 及 reconcile 機制提供瞭解決方案。

使用 etcd 存儲集羣配置，每臺 TDLB 服務器都會啓動 operator 監聽相關配置更新產生的事件，並通過 etcd 的證書鑑權保證配置的有效性。

• 在更新配置前，API 開始監聽配置對應 key prefix 的事件，開啓監聽後更新 etcd 中的集羣配置

• 配置更新產生事件，TDLB 服務器上的 operator 捕獲事件後進行相應的配置更新操作

• 更新操作成功完成後，將配置版本回寫至 etcd 相應的 key 中

• 配置版本回寫產生事件，API 監聽到事件後進行統計，當集羣所有服務器都更新完成，則操作完成

每當 TDLB 服務啓動後，都會與 etcd 進行配置同步，保證進入集羣提供服務時配置的一致性。集羣水平擴容服務器時，新進入集羣的服務器通過這種同步機制即可完成配置的下發，與服務部署的自動化保證了水平擴縮容的效率，應對業務流量的增長。

五、健康檢測策略

當一臺負載均衡設備上存在多塊網卡時，如果僅從一塊網卡發起健康檢測，當該網卡線路出現故障時，將影響到整臺設備的服務，即網卡線路層面的故障升級到服務器層面。

爲了控制網卡單點故障的影響範圍，在同一時間，從每塊網卡發起健康檢測，並且將服務的部分配置按網卡進行分隔，當一條網卡的線路出現故障，僅影響線路對應的服務配置，其他網卡線路依舊正常工作，這樣更好地保證了服務器剩餘的工作能力。

六、多維度監控

在多活模式的集羣中，需要從不同維度進行監控，提高故障的響應效率及定位效率：

• 集羣維度：監控集羣整體服務狀態

• 服務器維度：監控單臺服務器的服務狀態以及集羣中服務器間的差異

• 服務維度：監控每個服務的狀態，便於用戶對於服務狀態的感知

• CORE 維度：監控每個 CORE 的工作狀態，便於集羣容量的評估

基於 DPDK latency stats 設計了 CORE 與 CORE 獨立的 metric 計算與存儲，從而高效的獲取處理數據包耗時以及工作週期耗時的數據，監控單臺機器以及整個集羣的服務工作狀態。

監控數據接入 prometheus 及 grafana，設置了各個維度的監控告警，幫助快速定位故障點。

總結

TDLB 作爲以 DPVS 基礎框架完成的高性能四層負載均衡軟件，穩定運行近兩年時間，支撐着攜程各項業務。各項性能指標均符合預期，在滿足業務需求的同時，大大降低成本，推進了四層負載均衡服務與私有云的接入，這也是擁抱開源社區的回饋。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Prdf5zo_Bv-qhB8Zwauang