基于LINUX的鏈路聚合應用與實踐

楊衛中 王軍利

傳統的linux主機在做網絡配置時，主要采用bond方式，模式一般采用mode=1，實現鏈路冗余的目標。本文主要針對redhat的鏈路聚合技術的應用和實踐，實現鏈路冗余的同時，主機單側交換機速率將由原有10GB提升至20GB主備鏈路從而達到IO性能翻倍的目標。

一、研究背景

2019年是高質量發展、提升客戶感知的一年。 BSS3.0成功上線讓原IT架構由集中式升級為分布式，應用模型和基礎設施架構較之前發生了巨大變化，如何讓主機、網絡、數據庫等基礎設施更好為上層應用提供支撐，如何提升基礎設施性能就成為一個必須解決的課題。

在去IOE的背景下眾多oracle數據庫業務已經從小型機遷移到了X86架構上，并且完成了向Oracle12c的版本升級。隨著數據庫新特性的增加以及業務量的增長，數據庫主機的網絡帶寬面臨嚴峻的壓力。

為了更好的支撐業務需求，主流做法是采用萬兆交換機接入。數據庫主機業務端口分別連接兩臺萬兆交換機，將單側鏈路的帶寬提升至10Gbps，同時為了保證高可用性，會在主機層面采用網絡組的方式對鏈路做捆綁，即配置Bond，一般情況下會采用Mode=1（active-backup）的模式，即主備模式，兩個10Gbps端口為主備工作方式，端口匯聚后流量經過主用端口轉發，當主用端口故障后會切換備用端口，且端口匯聚后速率仍10Gbps。在前期的時候這樣的速率是充分滿足生產需求的，但是隨著新特性的增加、新業務量的增長、備份策略的調整，10Gbps的帶寬速率已經無法滿足當前Oracle數據庫大流量的生產需求，尤其是PDB（Pluggable Databases）的數據庫遷移。為了解決端口流量帶寬問題，需要對Oracle主機進行網絡端口擴容，從原來的10Gbps帶寬提升至20Gbps。

二、方案簡介

（一）當前主機環境

操作系統：Red Hat Enterprise Linux 7.5 X86_64

數據庫版本：Oralce12cforLinux

網絡配置：每臺主機配置4個10Gbps網口接口，分別兩臺萬兆業務交換機和兩臺萬兆心跳交換機。主機采用Bonding 內核模塊Mode=1（active-backup）的方式配置主備鏈路從而達到高可用性要求。

（二）優化后主機環境

操作系統：Red Hat Enterprise Linux 7.5 X86_64

數據庫版本：Oralce12cforLinux

網絡配置：每臺主機配置6個10G b p s網口接口，使用4個端口分別接入兩臺萬兆業務交換機，剩余的2個端口接入兩臺萬兆心跳交換機。主機采用teamdMode=4（802.3ad）的方式配置和交換機的聚合LACP方式配合單側交換機速率將由原有10GB提升至20GB主備鏈路從而達到高可用性要求。

三、應用和實踐內容

（一）了解網絡成組

聯合或合并網絡連接，以提供具有較高吞吐量的本地連接或冗余的方式可稱為“頻道綁定”、“以太網綁定”、“端口聚合”、“頻道成組”、“NIC 成組”、“鏈接合并”等等。這個最初在 Linux 內核中應用的概念泛指“綁定”?，F使用網絡成組（Network Teaming）代表這個概念的最新應用。

網絡成組或成組旨在通過提供小內核驅動程序，以便使用不同的方法應用這個概念，實現數據包流的快速處理，并讓各種用戶空間應用程序在用戶空間執行各種任務。該驅動程序有一個應用程序編程接口（API），即“成組 Netlink API”，可使用該接口進行 Netlink 通訊。用戶空間程序庫使用這個 API 與該驅動程序通訊。庫指的是“lib”，可用來進行成組 Netlink 通訊及RT Netlink信息在用戶空間的換行。同時還提供應用程序守護進程teamd 使用 Libteam 庫。teamd 的實例可控制成組驅動程序中的實例。該守護進程通過使用附加代碼（即“運行程序”）采用負載平衡及 active-backup 邏輯（比如輪詢）。通過使用這個方式分離代碼，可方便網絡成組對負載平衡及冗余要求的擴展及延伸解決方案。例如：使用teamd 編寫自定義運行程序應用新的邏輯可相對簡單，即使 teamd 為自選程序，用戶仍可編寫其自己的應用程序以便使用 libteam。

teamdctl 提供一個用來控制使用 D-bus 運行 teamd實例的工具。它可為 teamd D-Bus API 提供 D-Bus 換行程序。默認情況下，teamd 使用 Unix 域套接字（Unix Domain Socket）進行偵聽和通訊，但仍監控 D-Bus。這樣做是保證能夠在沒有 D-Bus 或者尚未載入 D-Bus 的環境中使用 teamd。例如：引導 teamd 鏈接時不一定載入D-Bus。可在運行時使用 teamdctl 工具讀取配置、連接監控程序狀態、端口狀態檢查及變更、添加和刪除端口以及將端口狀態在 active 和 backup 狀態間切換。

成組 Netlink API 通信使用 Netlink 信息與用戶空間應用程序通訊。用戶空間庫 libteam 不會直接與這個 API互動，但會使用 libnl 或 teamnl 與驅動程序 API 互動。

總之，不會直接配置或控制內核中運行的成組驅動程序實例。所有配置均采用用戶空間應用程序完成，比如 teamd 程序。然后該程序會根據需要指向內核驅動程序。

（二）端口聚合目標

將原有bond端口聚合模式變更為teamd聚合模式，并且將原有業務聚合的2個端口拓展至4個端口，業務端口速率由10GB拓展至20GB。

（三）teamd原理

Teamd和bond0功能類似，redhat7之前沒有teamd，在redhat7.0以上版本中網絡方面的相關服務被NetworkManager所接管，所以在配置多網卡綁定時，redhat專門提供了teamd工具來實現多網卡的綁定。Teamd不需要手動加載相應內核模塊，具有更強的拓展性。

Teamd的種類：

broadcast（可將數據傳送到所有端口）

round-robin（可按順序將數據傳送到所有端口）

active-backup（使用一個端口或鏈接時其他則處于備用狀態）

loadbalance（使用主動 Tx 負載平衡及基于 BPF 的Tx 端口選擇程序）

lacp（采用 802.3ad 鏈接合并控制協議）

此外還可使用以下鏈接監視程序：

ethtool（Libteam lib 使用 ethtool 監視鏈接狀態變化）。若沒有在配置中指定其他鏈接監控程序，則默認使用該程序。

arp_ping（使用 arp_ping 程序監控使用 ARP 數據包的遠端硬件地址狀態。）

nsna_ping（使用 IPv6 鄰居發現協議中的的鄰居播發和鄰居請求給你監控鄰居的接口狀態。）

（四） 配置思路

停止oracle數據庫相關服務。每臺數據庫主機增加一塊新的2-port萬兆網卡。每臺數據庫主機拓展兩個10GB業務端口。將每臺數據庫主機上聯的四個業務端口使用LACP做端口聚合。為每臺主機安裝teamd軟件并將網口聚合模式由bond更改為teamd。如果是現網主機改造，需要注意聚合后的接口名稱需要與原來的bond方式保持一致，否則數據庫無法啟動。全新配置的數據庫主機不存在此問題。測試業務可用性，檢查Aggregate ID配置是否正確。啟用oracle數據庫服務。

四、應用效果

（一）性能提升：可靠性、穩定性、IO性能

業務端口聚合后，對端口流量帶寬進行測試，通過觀察測試結果，4個業務端口通過teamd做聚合后，流量帶寬達到20GB甚至更高，是原來的2倍。

原單鏈路升級為多鏈路，網絡、鏈路都有多份冗余，可靠性和穩定性比傳統網絡有成倍的提升。

前端業務感知為：業務辦理等提交的工單更快入庫，數據查詢達到實時回應。

（二）架構優化

該成果應用后，無需單獨另外部署備份網絡，由SAN（光纖網絡）備份升級為LAN（IP網絡）備份，節省了機房空間、網絡布線、設備投資等多方資源。

原san網絡需要特有的光纖交換機、om3規格的光纖，每次項目上線均需3個月甚至更久時間，采用新的架構后，數據備份等需求可根據需要在1天內完成，時間成本是原來的1%左右。為前端業務提供了更為優化的服務。

五、推廣價值

（一）商業價值

該成果被成功推廣后，原有SAN（光纖網絡）備份方式將升級為LAN（IP網絡）備份方式，備份網絡將發生很大變化。新購SAN設備、光纖布線、機房空間等一系列工作將不再是棘手問題，底層數據備份等工作項目時間可由原來3個月甚至更久變為1周或1天完成，時間、人力等成本有明顯降低。

（二）技術價值

Teamding功能主要由kernel里的teamd driver、用來作為通訊接口的libteamd lib和userspace的teamdd 三部分組成，teamding也支持不同的工作模式。

實質上teamding的目的就是要把網卡綁定的功能從kernel里搬出來，把這些功能放到userspace來解決，保持kernel的簡潔，讓它只做kernel應該做的事情。

采用teamd端口聚合具有以下幾個方面價值體現：

1. 最多支持8塊網卡聚合

2. 更好的冗錯性

3. 提高吞吐量

4. 具有更好的性能以及擴展性

作者單位：中國電信股份有限公司河南分公司