B站邊緣網絡四層負載均衡器的探索與應用

作者：B站CDN平臺 2023-12-08 13:27:22

針對以上問題，我們調研了常見的四層負載均衡器，傳統的 SLB，LVS，DPVS 這類四層負載均衡器，在功能上也能滿足我們現有的需求。但是以上幾個負載均衡器均需要獨占機器，進而造成成本升高，資源浪費。

01 背景介紹

B站的 CDN 下行邊緣節點過去是非集群化架構。這種架構下有幾個弊端：

增加調度邏輯復雜性；
同機房流量/負載難以均衡；
暴露過多的公網IP，增加安全隱患 (盜鏈等)；
灰度流量比例分配粒度大；

有沒有一種既不增加成本，又能解決邊緣節點四層負載需求的方案呢？由 Cloudflare 提出的基于 Express Data Path (XDP) 的高性能四層負載均衡器 Unimog[1]性能優異，并且可以和后端服務同機部署，在性能上也完全滿足我們邊緣場景的要求。所以我們參考 Cloudflare Unimog 的思想，在其基礎上自研了適用于B站的邊緣四層負載均衡器 Nickel (以下簡稱 Ni) 。

與業務服務同機部署，更劃算；
只保留業務需要功能，更輕量；
可針對業務特點優化，更靈活；

目前已部署在自建動態加速，及自建點直播 CDN 集群化生產環境中。其支持與后端服務同機部署，底層使用 XDP、Traffic Control (TC) 進行包粒度轉發，支持 Direct Server Return (DSR) 模式，支持根據 CPU/QPS (或其他業務維度) 動態調整流量分配。

下面左圖為傳統 DSR 模式，右圖為自研負載均衡器 Ni 的 DSR 模式，不需獨占資源，支持與服務同機部署，更符合邊緣場景。

圖片

02 架構設計

2.1 總體設計

四層負載均衡器 Ni 由兩部分組成，控制面和數據面。控制面主要負責服務發現、配置管理、數據上報，及LB規則的動態維護等。數據面主要由 LoadBalance (XDP) , Redirect (TC Traffic Control) 等模塊組成，主要用來負責數據包的轉發。控制面和數據面根據預定義的接口傳輸數據。

圖片

開始介紹之前先明確幾個下文中用的到名詞及其意義：

VIP (virtual IP) ：用于統一接受用戶請求，代表當前集群流量入口，下文中VIP指LB所在機器的IP（目前邊緣沒有支持真正虛擬IP的建設）。
DIP (direct IP) ：業務服務所在機器的 IP。

2.2 控制面

控制面基于開源框架 kglb[2] 結合邊緣網絡特點做的改造和開發，其核心為生成和維護供數據面使用的轉發表。為了保證轉發表的數據的正確性、實時性、高效性，控制面使用以下幾個功能和模塊更新信息：

服務發現、管理

Ni 控制面需要維護同集群邊緣節點的所有服務器信息 (VIP，DIP，Hostname，運營商，權重等)，以及需要感知當前邊緣機房內機器或者服務的狀態變化，如標記為下線的機器不再接受新的連接請求，但是需要維護當前已經建立的連接直至其主動斷開；

健康檢查

處于異常狀態的服務在確認其不可用后應該盡快從轉發表中刪除，避免影響范圍擴大。因此機房內需要有服務器級別的健康狀態檢查。目前 Ni 提供多種協議類型的健康檢查方式，如 Http、Tcp 等。以下為 Http 健康檢查的相關配置字段：

{
    "checker": {
        "http": {
            "scheme": "http",
            "uri": "/",
            "check_port": 9080,
            "codes": [
                200
            ]
        }
    },
    "fall_count": 2,
    "interval_ms": 2000,
    "rise_count": 2
}

支持基于機器使用率/QPS等做負載均衡

Ni定期收集機房內各服務器的資源使用情況，以便于根據資源使用率做動態調整。使用收集的信息計算機房內機器負載，讓負載偏低的服務分配更多的連接，偏高則反之，從而保證一個邊緣機房內所有服務器的負載收斂。QPS類似。

基于轉發表Beamer[3]的負載均衡

第一步首先需要一個穩定高效的 Hash 計算方法，輸入四元組 (源 IP、源 port、目的 IP、目的 port) 后得到對應的 Hash 索引值，第二步使用索引值轉換為 DIP。

圖片

支持按照配置的 DIP 權重做負載均衡，也可以動態根據 DIP 所在機器的CPU進行實時的權重調整，也就是調整 Hash 值在整個轉發表中的比例。

圖片

如圖所示，比例變化后 Hash 值對應的DIP也會改變。原本應該發往 DIP A 的數據包，發給了 DIP B。如果這和數據包是發起建連的 (TCP SYN) ，則B服務器與該數據包的 Client 端三次握手建立新連接。但如果數據包屬于之前與 A 服務器建立連接的 Client，因為 B 服務器沒有對應的 TCP socket，會向 Client 發送 RST 斷開連接。

要解決這個問題，需要 B 服務器收到的數據包不屬于自己的 socket 后，將這類數據包二次轉發給A服務器。也就是說 B 服務器需要知道二次轉發的數據包應該發給誰，如果把這個信息存下來，A 服務器與 Client 的連接就可以繼續保持。

為了實現這一點，我們擴展了轉發表。使用四元組 Hash 之后的值，對應兩個 DIP，動態更新后的稱為第一跳，動態更新前的稱為第二跳。

圖片

如果第一跳和第二跳的DIP是一樣的，即使在判斷后發現數據包不屬于第一跳服務器，也不需要做第二跳的判斷和轉發，因此實際我們只需要保留發生變化的部分。

圖片

關于二次轉發的邏輯，主要分為以下三個部分：

如果數據包是 SYN，則在第一跳服務器上新建一個連接，保證新連接的數據包都在第一跳服務器上處理。
非SYN的數據包，需要檢查第一跳服務器上是否存在相應的 socket。如果存在，則交由第一跳服務器處理。
第一跳不存在對應的 socket，則將該數據包轉發給第二跳服務器。如果發現第二跳為空則將該數據包丟棄。

如果出現需要轉發到第二跳的情況，因為多轉發了一次數據包，所以在一定程度上會造成帶寬的增大。但是隨著新連接的建立，老連接的斷開，需要二次轉發的數據包比例會很快降低。

圖片

同時從理論上來說，只要某個 Client 的連接時間足夠長，經過多次轉發表動態調整，比如第一跳和第二跳都不是A服務器，那么這個 Client 會因為收到 RST 而斷開。基于當前的調整策略，這種情況是不可避免的。對此我們在調整頻率和調整策略上都做了以下優化：

控制最快調整時間間隔；
優先選擇通過第一跳和第二跳對換即可實現調整目標的桶；
優先選擇最近調整次數最少的桶；
避免表項大規模調整，小步迭代；
盡可能保證表項連續性，減少碎片等；

2.3 數據面

控制面維護的轉發表是來指導底層做數據轉發的，我們的數據轉發模塊使用 XDP 來實現，XDP之前在 QUIC 使用其做性能收發包優化[4]時也有介紹，它是 Linux 內核網絡棧的最底層集成的數據包處理器。當網絡包到達內核時，XDP 程序會在早期被執行，跳過了內核協議棧，提高了包處理的效率，XDP 共有3種模式：

Offload：XDP 的 eBPF 程序直接 hook 到可編程網卡硬件設備上，而不是在主機 CPU 上執行。因為該模式將執行從 CPU 上移出，并且處于數據鏈路的最前端，過濾效率與性能最高。
Native：XDP的 eBPF 程序在網絡驅動程序的早期接收路徑之外直接運行。
Generic：可以在沒有硬件或驅動程序支持的主機上執行上執行 XDP 的 eBPF 程序。缺點：仿真執行，需要分配額外的套接字緩沖區，導致性能下降。

Offload 模式雖性能最優但需要特定硬件的支持，Native 模式為最常用的模式，掛載在驅動路徑上，需要驅動的支持，Generic 模式是內核模擬出的一種模式，不依賴于網卡驅動，不過掛載點靠后，性能在三種模式種最差。綜合邊緣節點機器網卡、系統等因素，我們在生產環境選用Native 模式。

圖片

控制面維護的轉發表，傳遞到XDP模塊時，其本身是一個類型為 map in map 的 eBPF map。外側的 map key 為用戶訪問的服務二元組，即服務的 IP 和 Port，外側的 map value 對應內側的 eBPF map對象；內側的 map key 為桶的編號，即 Hash 的索引值，value 為一個 simple C struct, 內部存儲了第一跳和第二跳的IP地址。數據面在進行相應的 hash value calculation 之后，找到一對 Hop IPs，將用戶的原始數據包封入由該 Hop IPs 組成的 GUE header 中。

GUE header[5] 為 Github LB 使用的一個私有頭格式，詳細見下圖。在封包完成后，XDP 將該數據包傳輸給對應機器，在該機器上，由 TC 通過四元組判斷該連接是否已存在；如果存在，則將該數據包解封并傳輸給上層；如果不存在，則根據 GUE header 轉發給下一跳。

圖片

在 TC 解封完成后，如果此邊緣集群支持 VIP，并且服務監聽了該 VIP，其已經可以正常通過 Linux 網絡協議棧的 Socket 拿到數據包，由于目前我司邊緣集群尚不支持 VIP，除非通過 ip_transparent 等特殊手段，否則后端服務器上的服務無法監聽作為 LB 的機器的 IP。為了使后端服務無感，我們選擇使用過渡手段的 netfilter conntrack 對 ingress 數據包進行 SNAT (Source Network Address Translation) ，并對 egress 數據包進行 DNAT (Destination NAT) 。由于 conntrack 本身的性能瓶頸，會限制 Ni 作為 LB 的能力。不過在當前線上的業務場景下，并不會達到 conntrack 的性能瓶頸，邊緣節點支持 VIP 也在和相關部門推進中，未來支持后，去掉 NAT 轉換 Ni 的性能會進一步提高。

圖片

03 應用場景

3.1 動態加速的應用

動態加速是在傳統 CDN 基礎上實現的對數據網絡加速進一步優化的智能管理服務，通過全方位的 CDN 質量監控，以及智能易用的節點調度等功能，提供穩定快速的網絡訪問服務。

動態加速的節點分布在全國的各個地區，每個節點都由多臺機器組成。如果將節點內所有機器全都對外暴露，可能會有以下問題：

增加動態智能選路服務的運算量，一定程度上增加排查問題的復雜度；
如果單臺機器不可用時需要通過遠端探測發現并反饋到選路服務，進而計算新的路并下發，流程較長，造成路徑切換變慢；
動態加速機房多為過保機器，存在硬件配置殘次不齊的情況，性能好的機器應該處理更多的業務請求；

部署Ni之后

將機房內機器組成一個集群，收斂流量入口；
通過主動健康檢查實時將不可用服務摘流，集群外部無感，服務恢復后自動加回；
檢查集群內機器的 CPU 使用情況，并根據配置參數做出實時調整；

圖片

下圖為紅色部分代表機器 CPU 升高超出閾值后，自動將該機器接流占比減小的監控。

圖片

3.2 點直播CDN集群化場景的應用

單個點直播集群內可能有幾臺或幾十臺機器，調度服務從感知資源池內機器狀態變化到對用戶的請求做出反應，可能會有分鐘級的延遲，存在一定的滯后性。且在多機房、多機器的調度場景下，基于調度服務的負載均衡也難以完全將流量打均。將負載均衡能力下沉到機房內之后，反應時間可以降低到秒級，靈敏度更高。同時流量調度的的控制粒度也可以做到更加精細，更有利于提升邊緣集群的利用率。

圖片