Facebook 開源可擴展的網路負載均衡軟體 Katran

Nikita Shirokov和RanjeethDasineni

全球數十億人在使用Facebook服務，為此我們的基礎設施工程師開發了一系列系統來優化流量，並為每個人確保快速可靠的訪問。今天我們在開源道路上又邁出了一步：發布了Katran轉發平面軟體庫，該軟體庫在底層支持Facebook基礎設施中所用的網路負載均衡系統。Katran提供了基於軟體的負載均衡解決方案，完全重新設計的轉發平台充分利用了內核工程方面最近的兩個創新：eXpress數據路徑（XDP）和eBPF虛擬機。如今Katran部署在Facebook入網點（PoP）的大批後端伺服器上，它幫助我們提高了網路負載均衡的性能和可擴展性，並減少了低效問題（比如沒有入站數據包時的繁忙循環）。我們希望通過與開源社區共享Katran，其他人也能夠提其負載均衡系統的性能，將Katran用作未來工作的基礎。

艱巨挑戰：在Facebook的龐大環境下處理請求

為了在Facebook的龐大環境下管理流量，我們部署了一個全球分散式入網點網路，充當數據中心的代理系統。鑒於請求數量極大，入網點和數據中心都面臨這個艱巨挑戰：讓大批（後端）伺服器在外界看來如同單一虛擬單元，又可以在那些後端伺服器之間高效地分配工作負載。

這類挑戰通常通過在每個位置向互聯網通告虛擬IP地址（VIP）來加以解決。發往VIP的數據包隨後在後端伺服器之間無縫地分配。然而，分配演算法需要考慮到這一點：後端伺服器通常在應用層運行，並終止TCP連接。這項重任由網路負載均衡系統（常常名為第4層負載均衡系統或L4LB，因為它對數據包進行操作，而不是處理應用層請求）來處理。圖1表明了L4LB相對於其他網路部件的作用。

圖1：網路負載均衡系統面對幾台運行後端應用程序的後端伺服器，將來自每個客戶端連接的所有數據包穩定地發送到一台獨特的後端伺服器。

對高性能負載均衡系統提出的要求

L4LB的性能對管理延遲和擴展後端伺服器的數量來說特別重要，因為L4LB在需要處理每個入站數據包的路徑上。性能通常按L4LB能夠處理的每秒峰值數據包（pps）來衡量。傳統上，工程師們青睞使用基於硬體的解決方案來完成這項任務，因為它們通常使用加速器來減輕主CPU的負擔，比如專用集成電路（ASIC）或現場可編程門陣列（FPGA）。然而，硬體方案的缺點之一是，它限制了系統的靈活性。為了有效地滿足Facebook的需求，網路負載均衡系統須滿足下列要求：

?在大眾化Linux伺服器上運行。這讓我們得以在部分或所有目前部署的大批伺服器上運行負載均衡系統。基於軟體的負載均衡系統滿足這個標準。

?與特定伺服器上的其他服務共存。這就不需要專門運行負載均衡系統的專用伺服器，因而提高了容錯性。

允許低干擾維護。Facebook的軟體必須能夠迅速演進，以支持新的或改進的產品和服務。對於負載均衡系統和後端層來說，維護和升級是常規，而不是例外。執行這些任務過程　中盡量減少干擾讓我們得以更快地迭代。

易於檢測和調試。所有大型分散式基礎設施都必須應對異常和意外事件，因此縮短調試和排查問題的時間很重要。負載均衡系統需要易於檢測，並與tcpdump之類的標準工具兼容。

為了滿足這些要求，我們設計了一種高性能的軟體網路負載均衡系統。我們的第一代L4LB基於IPVS內核模塊，滿足了Facebook四年多的需求。然而，它未能達到與其他服務（尤其是後端）共存的目標。在第二次迭代中，我們利用了eXpress數據路徑（XDP）框架和新的BPF虛擬機（eBPF），讓軟體負載均衡系統與後端在大量機器上一起運行。圖2顯示了兩代L4LB之間的關鍵區別。

圖2：兩代L4LB之間的區別。請注意，兩者都是在後端伺服器上運行的軟體負載均衡系統。Katran（右）讓我們得以將負載均衡系統與後端應用程序放在一起運行，因而增強了負載均衡系統的能力。

第一代L4LB：基於OSS軟體

使用第一代L4LB時，我們高度依賴現有的開源組件來實現大部分功能。這種方法幫助我們在短短几個月內更換了龐大部署環境中基於硬體的解決方案。這種設計有四大組件：

?VIP通告：該組件與L4LB前面的網路元件（通常是交換機）對等互聯，只是向外界通告L4LB負責的虛擬IP地址。然後，交換機使用等價多路徑（ECMP）機制，在通告VIP的L4LB之間分配數據包。由於輕巧靈活的設計，我們將ExaBGP用於VIP通告。

?後端伺服器選擇：為了將來自客戶端的所有數據包發送到同一個後端，L4LB使用一致性哈希，該哈希取決於入站數據包的5元組（源地址、源埠、目的地地址、目的地埠和協議）。使用一致性哈希可確保屬於傳輸連接的所有數據包都被發送到同一個後端，不管接收數據包的L4LB是哪個。這就不需要跨多個L4LB的任何狀態同步。一致性哈希還保證後端離開或加入後端池時對現有連接的干擾最小。

?轉發平面：一旦L4LB選擇了適當的後端，數據包需要被轉發到該主機。為了避免限制（比如L4LB和後端主機要在同一個L2域），我們使用了簡單的IP-in-IP封裝。這讓我們得以將L4LB和後端主機放置在不同的機架中。我們使用IPVS內核模塊進行封裝。後端經過了配置，確保回送介面上有相應的VIP。這讓後端得以將返迴路徑上的數據包直接發送到客戶端（而不是L4LB）。這種優化常常名為直接伺服器返回（DSR），讓L4LB只受入站數據包數量的限制。

?控制平面：該組件執行各項功能，包括對後端伺服器執行健康檢查，提供簡單的介面（通過配置文件）以添加或刪除VIP，並提供簡單的API以檢查L4LB和後端伺服器的狀態。我們內部開發了這個組件。

每個L4LB還將每個5元組的後端選擇作為查找表存儲起來，避免重複計算未來數據包的哈希。這種狀態是純粹的優化，未必是為了檢查正確性。這種設計符合上面列出的Facebook工作負載的幾個要求，但存在一大缺點：將L4LB和後端都放在一個主機上增加了設備故障的可能性。即使在本地狀態下，L4LB也是CPU密集型組件。為了隔離故障域，我們在一組不相關的機器上運行L4LB和後端伺服器。在這種方案中，L4LB的數量少於後端伺服器，這使得L4LB更容易受到負載突增的影響。數據包在由L4LB處理之前要經過常規的Linux網路堆棧，更是加劇了這個問題。

圖3：第一代L4LB的概況。請注意，負載均衡系統和後端應用程序在不同機器上運行。不同的負載均衡系統做出一致的決策，無需任何狀態同步。使用數據包封裝讓運行負載均衡系統的伺服器和運行後端應用程序的伺服器得以放置在不同機架中。在典型的部署環境下，L4LB數量與後端應用伺服器數量之比非常小。

Katran：重新設計轉發平面

Katran是我們的第二代L4LB，採用了完全重新設計的轉發平面，比前一個版本有了顯著改進。內核界最近的兩個創新助力這種新設計：

XDP提供了一種快速的可編程網路數據路徑，無需採用全面的內核旁路方法，可與Linux網路堆棧結合使用。（此處https://www.iovisor.org/technology/xdp有XDP方面的詳細介紹。）

eBPF虛擬機在內核的特定區域運行用戶空間提供的程序，因而提供了一種靈活、高效、更可靠的方法與Linux內核進行交互，並擴展功能。eBPF已在幾個方面帶來了顯著的改進，包括追蹤和過濾。（此處https://www.iovisor.org/technology/ebpf有更多的詳細信息。）

該系統的總體架構與第一代L4LB相似：首先，ExaBGP向外界通告某一個Katran實例負責哪個VIPS。其次，發往VIP的數據包使用ECMP機制發送到Katran實例。最後，Katran選擇一個後端，將數據包轉發到正確的後端伺服器。主要區別在於最後一步。

及早高效的數據包處理：Katran結合使用XDP與BPF程序來轉發數據包。XDP在驅動程序模式下被啟用後，數據包處理常式（BPF程序）在網卡（NIC）收到數據包之後、內核截獲之前立即運行。面對每個入站數據包，XDP一律調用BPF程序。如果網卡有多個隊列，為每一個隊列並行調用該程序。用於處理數據包的BPF程序是無鎖的，使用每個CPU特有的BPF映射。由於這種並行機制，性能可以隨網卡的RX隊列的數量呈線性擴展。Katran還支持「通用XDP」操作模式（而不是驅動程序模式），但性能受到影響。

成本低廉但更穩定的哈希：Katran使用Maglev哈希的擴展版來選擇後端伺服器。擴展版哈希的幾項功能是，遇到後端伺服器故障後可迅速恢復，更均勻地分配負載以及能夠為不同的後端伺服器設置不等的權重。這最後一項是重要功能，讓我們得以輕鬆處理入網點和數據中心的硬體更新：我們只要設置適當的權重就可以兼容新一代硬體。儘管計算這個哈希的代碼更具表達力，但很小巧，足以完全裝入到L1緩存中。

更有彈性的本地狀態：Katran處理數據包和計算哈希方面很高效，因而與本地狀態表有了有趣的交互。我們發現，對後端伺服器選擇組件而言，計算哈希從運算方面來看常常比查找5元組的本地狀態表來得容易。在本地狀態表查找一路遍歷到共享的最後一級緩存這種情況下，這個現象來得更明顯。為了自然地充分利用這種現象，我們將查找表實施成LRU驅逐緩存。LRU緩存大小在啟動時可加以配置，充當可調參數，在計算和查找之間求得平衡。我們憑經驗選擇了這些值，針對pps進行優化。此外，Katran提供了一個運行時「僅計算」開關，那樣萬一主機遇到災難性的內存壓力，就完全忽略LRU緩存。

對RSS友好的封裝：接收端擴展（RSS）是網卡中的一個重要優化，旨在通過將來自每路數據流的數據包轉發到單獨的CPU，從而在CPU之間均勻地分配負載。Katran設計的封裝技術可與RSS結合使用。不是為每個IP-in-IP數據包使用同樣的外部源，而是使用不同的外部源IP來封裝不同數據流中的數據包（比如有不同的5元組），但同一數據流中的數據包始終被分配同樣的外部源IP。

圖4：Katran為高速處理數據包提供了一條快速路徑，無需藉助全面的內核旁路。請注意，數據包通過內核/用戶空間邊界只有一次。這讓我們得以在不犧牲性能的情況下，將L4LB和後端應用程序放在一起。

這些功能顯著增強了L4LB的性能、靈活性和可擴展性。如果沒有入站數據包，Katran的設計還消除了幾乎不耗用任何CPU的接收路徑上的繁忙循環。相比全面的內核旁路解決方案（比如DPDK），使用XDP便於我們在同一個主機上讓Katran與任何應用程序一起運行，性能不會出現任何下降。今天Katran在我們的入網點上與後端伺服器一起運行，L4LB與後端之比得到了改進。這還增強了面對負載猛增、主機故障和維護的適應能力。重新設計的轉發平面是這一轉變的核心。我們認為，若使用我們的轉發平面，其他系統也能從中得益，於是我們開源了代碼，並附有如何用它來設計L4LB的幾個例子。

另外要考慮的事項

Katran在實現性能提升的某些假設和約束條件下運行。實際上，我們發覺這些約束條件相當合理，沒有阻止我們的部署。我們認為，使用我們庫的大多數用戶會發現它們易於滿足。我們在下面逐一列出：

Katran只在直接服務返回（DSR）模式下工作。

Katran是決定發往VIP的數據包的最終目的地的組件，所以網路需要先將數據包路由發送到Katran。這要求網路拓撲結構基於L3，比如數據包由IP路由發送，而不是由MAC地址路由發送。

Katran無法轉發分段的數據包，也無法自行對資料庫分段。這可以通過增加網路內部的最大傳輸單元（MTU）或更改來自後端的通告TCPMSS來緩解。（即使你增加了MTU，還是建議採取後一個措施。）

Katran不支持帶有IP選項集的數據包。最大數據包大小不得超過3.5 KB。

Katran當初在構建時假設它將用於「一體化負載均衡系統」這個場景，即單一介面將用於「從用戶到L4LB（入口）」的流量和「從L4LB到L7LB（出口）」的流量。

儘管存在上述這些限制，我們還是認為Katran為希望利用XDP和eBPF這兩項卓越創新來構建高效負載均衡系統的用戶和組織提供了一種出色的轉發平面。我們樂意回答潛在的採用者在使用我們GitHub代碼倉庫（https://github.com/facebookincubator/katran）的過程中提出的任何問題，也始終歡迎合併請求（pull request）！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！