測控基帶資源池的設計與實現

黨 赟，高群福，賈丙強，劉云杰

(中國電子科技集團公司第五十四研究所，河北 石家莊 050081)

0 引言

近年來，隨著信息化、網絡化的快速推進，云計算得到大規模推廣和應用。國內外不少學者、工程人員已開始研究如何將云計算、資源池應用于復雜控制系統及其設備中，在應用中首先需要解決物理設備虛擬化共享問題。20世紀90年代，工業界和學術界已經開始進行設備I/O虛擬化技術研究，主要從聚合、融合和共享3個方面開展研究[1]。主要技術成果包括PCI-SIG提出的單根虛擬化技術(SR-IOV)[2]和以太網光纖通道技術(Filber Channel over Ethernet FCoE)[3]、NEC提出的ExpEther[1]和NextIO提出的vNet等。在PCI-SIG提出的單根虛擬化技術基礎上，王展等人實現了多主機共享PCI-e物理設備[4]，達到了近乎物理直連的傳輸性能。

隨著大規模測控陣列天線在航天多目標測控系統中的應用，設備數量和控制復雜度急劇增加，云計算、資源池管理技術在測控系統中的應用成為業界研究的熱點，采用設備虛擬化技術，將測控設備資源整合成虛擬資源池，通過云管理平臺按需為測控任務分配計算、存儲、測控資源和各種服務，實現資源動態分配、靈活調度和跨域共享。

從應用需求出發，對各類虛擬化技術進行分析和比較，提出了基于網絡的基帶設備虛擬化方案，對基帶板卡進行虛擬化，使其兼容PCI-e和網絡2種通信協議，實現了基帶設備資源池化管理的目標。采用云管理平臺對計算、存儲、網絡和基帶設備進行統一管控、動態分配，在提高設備靈活性的同時可有效降低升級和維護開銷[5]。同時，云平臺具備的虛擬機在線遷移、負載均衡[6]等特性，可加速應用部署[7]，從而提高了整個系統的可用性[8]。該技術在解決行業應用需求的同時，也可為同類型功能設備實現虛擬化提供了參考。

1 測控基帶資源池總體設計

1. 1 架構設計

測控基帶資源池由計算、存儲、網絡和基帶設備資源組成，基帶設備、刀片服務器和磁盤整列集中部署于設備機架，方便擴展，基帶設備、服務器、磁盤整列和外設之間通過高性能網絡交換機實現互聯互通，設備組成及連接關系如圖1所示。

圖1 測控基帶資源池設備組成

測控基帶資源池采用云管理平臺[9]進行管理，將各類虛擬資源按照任務需求進行動態分配。測控基帶云管理平臺分為基礎架構即服務(Infrastructure as a Service，IaaS)、平臺即服務(Platform as a Service，PaaS)和軟件即服務(Software as a Service，SaaS)[10-11]3層。其中，IaaS提供虛擬基礎資源，如虛擬主機、存儲和設備等[12]，可以此為基礎建立測控基帶系統運行環境[13]；PaaS提供構建系統所需的平臺級應用，如操作系統、虛擬化服務、負載均衡和動態遷移[14]等；SaaS向用戶提供測控基帶應用服務，包括各測控模式應用等。測控基帶云管理平臺服務層次關系如圖2所示。

圖2 測控基帶云管理平臺層次關系

采用云管理平臺對測控基帶進行資源池化管理具有以下優點：

① 通過虛擬化技術使得測控資源得到了充分、最大化的利用，采用集約化部署可減少設備體積[ 15]和設備數量，降低設備冗余；

② 擴展能力強，當基礎設施資源不足時，可通過增加刀片服務器、網絡交換機、磁盤陣列或基帶板卡數量，方便實現資源擴展[ 16]；

③ 云管理平臺具備負載均衡和動態遷移功能，可實現數據自動備份，有效提高系統的可靠性和可用性[ 17]；

④ 基帶板卡與物理主機采用松耦合架構動態配置，部署靈活，改變了傳統的主備配置方案，可實現多路備份，有利于提高設備可靠性；

⑤ 云管理平臺具備完善的安全防范機制，使得系統安全可控、數據保密和信息安全[ 18]；

⑥ 測控基帶應用軟件、板級軟件由云平臺統一管控，易于維護和升級[ 19]。

1. 2 資源分配過程

采用云平臺管理的測控基帶資源池，執行測控任務時需要進行資源分配，分配過程如圖3所示。

圖3 測控基帶資源分配流程

資源分配步驟如下：

① 云管理平臺計算機接收管控計算機的測控任務需求，確定測控資源需求；

② 云管理平臺計算機進行虛擬機運行資源和處理板卡的資源分配，啟動虛擬機及對應的基帶應用軟件；

③ 云管理平臺計算機向基帶應用軟件下發資源分配列表，主要包括基帶板卡ID、網絡通信地址和數據存儲目錄等；

④ 基帶應用軟件對所屬資源進行初始化工作，包括基帶板級軟件加載、網絡設備初始化、基帶功能單元加載和數據存儲目錄初始化等工作；

⑤ 基帶應用軟件按照流程執行遙控、遙測、速度測量和距離測量等測控任務；

⑥ 測控任務完成后，基帶應用軟件退出并將所屬資源交還云管理平臺計算機。

2 需要解決的問題

現有測控基帶采用基帶設備資源與物理主機綁定的緊耦合架構，如圖4所示，系統擴展時只能以增加單體主機、基帶設備的數量來應對，這無疑會增加測控設備冗余、購置成本和管理成本，同時，主機數量和種類的增加還會導致整個系統信號和網絡連線數量的增加，增加網絡部署的復雜度。

圖4 現有測控基帶設備組成

隨著測控系統的發展，基帶設備數量的大幅增加給系統管理、維護和升級等帶來巨大挑戰。將基帶設備與物理主機解綁，采用資源池的方式對計算資源、存儲資源和測控資源進行松耦合式動態管理，可有效解決上述問題。基帶設備資源池化管理需要解決以下問題：

① 實現基帶設備I/O虛擬化：通過基帶設備虛擬化實現設備資源的動態分配、靈活調度，并可采用軟件的方法進行重新定義和劃分；

② 設備性能要求：基帶設備對控制實時性、可靠性和數據通信速率有較高要求，設備實現虛擬化后應滿足系統對設備的性能要求。

3 關鍵技術

針對基帶設備資源池化管理急需解決的基帶設備I/O虛擬化和設備性能問題進行重點分析。

3. 1 I/O虛擬化方案

3. 1. 1 方案分析

目前，學術界和工業界都已開展了一些研究工作，致力于實現多服務器間的I/O共享，主要從I/O聚合、I/O融合、共享復用和集中轉換4個方面展開。

① I/O聚合是通過設備本身的硬件輔助虛擬化技術，將直接 I/O 虛擬化所需的多個物理I/O設備聚合轉換為單個物理設備內的多個虛擬功能，以減少單個物理服務器所需配備的I/O設備數量，如PCI-SIG提出的PCI-e單根虛擬化(Single Root I/O Virtualization，SRIOV)技術；

② I/O融合是通過設備本身的硬件輔助協議轉換，實現單個物理I/O設備支持多種協議數據包的處理和傳輸，從而降低數據中心所需配備的I/O設備和互連網絡的多樣性，如以太網光纖通道(Fiber Channel over Ethernet)技術；

③ 共享復用是將I/O設備的共享范圍從單個物理服務器內的多個虛擬機之間擴大到多個物理服務器之間，以縮減單機所需的I/O設備的數量和數據中心內部網絡連線的數量，同時，通過共享復用提高I/O資源的利用率，例如NEC ExpEther和NextIo vNet等；

④ 集中轉換是使用軟件方式實現I/O設備的多服務器間共享，其使用一臺配有I/O設備的物理主機作為多機I/O共享的服務器端，通過網絡向客戶端提供通用的I/O接口服務，客戶端使用該接口進行I/O操作。

根據應用需求和板卡特點結合上述4種虛擬化技術進行分析，制定適合應用需求的解決方案。

① I/O聚合方案的前提是將板卡必須與計算機主機綁定，通過將板卡轉化為多個虛擬功能以供多個虛擬機進行使用；

② I/O融合方案是在設備端增加多種協議轉換功能模塊，以滿足虛擬主機對設備的訪問需求，使用該方案可以實現主機與設備資源的分離，需在設備端增加局部總線/以太網協議轉換模塊；

③ 共享復用方案是在板卡與主機綁定的架構下，通過將設備的共享范圍擴展以實現多機共享的目的。該方式在虛擬機部署時對服務器系統、網絡帶寬有較高要求，板卡、主機、BIOS和宿主計算機都需要支持SR-IOV才能使用虛擬化功能，在多機共享時是以占用網絡帶寬為代價的；

④ 集中轉換式方案將一臺物理主機用作協議轉換服務器向多機提供共享服務，該模式使該物理主機成為整個系統的性能瓶頸，此外，由于經過了較多的軟件層次導致客戶端主機的I/O性能較低。

經過上述分析，在不增加額外設備的情況下，I/O融合方案可實現主機與板卡松耦合管理，無需改變設備物理結構，只需對設備板卡軟件進行改造升級可滿足虛擬化需求。

3. 1. 2 板卡改造方案

數字基帶板卡架構示意圖如圖5所示，圖中數據交換FPGA主要功能是實現板卡與上位機I/O數據交換。

圖5 數字基帶板卡架構示意

為實現設備虛擬化需求，需要進行如下改造：

① 在數據交換FPGA中增加以太網絡模塊，網絡MAC地址、IP地址等網絡信息可通過上位機軟件或板卡配置芯片進行動態或靜態配置；

② 在數據交換FPGA中增加以太網←→局部總線雙向協議轉換模塊，實現網絡協議與局部控制總線間的協議互轉，板卡內部各模塊間局部總線及協議保持不變；

③ 保留板卡原PCI-e接口模塊，使其具備2種協議分時工作能力，可通過配置信息或板卡跳線實現接口協議的選擇；

④ 在對插板上增加以太網接插件，實現網絡數據接入，對插板與處理板之間數據通訊可復用原PCI-e連接線，盡可能減少板卡更動內容。

3. 2 接口協議設計

增加以太網←→局部總線雙向協議轉換模塊后，設備具備了與上位機進行網絡數據交換的能力，選擇合適的傳輸協議對于設備的穩定性和可靠性有重要意義。目前，常用的網絡協議主要包括TCP和UDP協議，2種協議的特點如下：

① 二者都屬于傳輸層協議，TCP為面向連接協議，在客戶端和服務器端進行通信之前，首先要交換傳輸層控制信息，為雙方的通信做好準備。UDP是一個非連接的協議，傳輸數據之前雙方不建立連接，當傳送數據時，簡單地抓取來自應用程序的數據，并盡快把數據傳送到網絡上。

② UDP協議的數據傳輸不需要維護收發狀態和連接狀態等，與TCP相比，網絡的有效利用率得到很大提高。

③ TCP協議提供數據確認重傳、擁塞控制等可靠性保證，UDP協議不提供可靠性保證，也不提供流量控制。

與TCP協議相比，UDP協議具有連接網絡延遲小且數據傳輸速度快的特點[20]，為了保證數據可靠性，在UDP協議的基礎上，增加了接收確認、數據重傳和滑動窗口機制以提高數據可靠性。

本方案采用的UDP傳輸過程如圖6所示。

圖6 基于UDP協議的數據傳輸過程

基于UDP協議的數據傳輸過程如下：

① 收發雙方按照既定網絡信息建立網絡通信套接字，在建立網絡連接后先進行3次握手建立數據連接，并保持定時數據互通；

② 發送方利用滑動窗口緩存已發送數據，直至收到確認、重傳或發送超時消息；

③ 接收方收到數據后利用數據幀序號進行數據重組、亂序糾正，如發生丟包則向發送方發送重傳的請求消息。

4 關鍵指標測試

4. 1 測試環境

按照應用需求進行測試環境搭建，采用一臺測試計算機+4塊基帶板卡的配置方式，以模擬最復雜測控任務情況，網絡化基帶板卡和測試計算機利用高性能網絡交換機實現互聯，測試環境連接如圖7所示。

圖7 測試環境連接

4. 2 測試過程

4. 2. 1 板級軟件加載測試

板級軟件加載測試過程如下：

① 啟動部署在測試計算機的測試程序；

② 分別向4塊板卡發送IP地址配置命令，設置板卡通信地址信息，并與測試程序建立數據通信連接；

③ 依次向4塊基帶板卡寫入FPGA運行文件，該文件容量為28 660 KB，寫入完成后由加載單元進行數據校驗，無誤后上報確認信息，即認為加載成功；

④ 重復步驟②2 000次，以測試板卡加載時間和加載成功率。

4. 2. 2 網絡性能測試

網絡性能測試包括傳輸時延和典型數據傳輸能力測試。

準備工作如下：

① 在設備端設計測試程序，該測試程序在收到應用軟件發送的網絡數據包后直接原樣返回，用于測試傳輸時延；

② 在設備端設計2路數據發送模塊，數據包長、發送頻率可設，用于測試數據傳輸性能。

測試過程如下：

① 啟動部署在測試計算機的測試程序；

② 分別向4塊板卡發送IP地址配置命令，設置板卡通信地址信息，并與測試程序建立數據通信連接；

③ 以500 ms/幀的頻率向板卡發送網絡數據包，記錄發送時間和返回時間，并計算時延差；

④ 接收板卡上報的2路數據，統計數據丟包率和實時速率。

4. 3 測試結果

4. 3. 1 板級軟件加載測試結果

板級軟件加載測試結果如圖8所示，測試樣本為2 000次，平均加載時間為1. 922 s。

圖8 板級軟件加載測試結果

4. 3. 2 網絡性能測試結果

在測試條件為：測試數據包長為1 024 Byte，傳輸間隔為500 ms，網絡傳輸延測試結果如圖9所示，網絡傳輸平均時延為1. 472 ms。

圖9 網絡傳輸時延測試結果

在測試條件為：單路數據接收測試數據包長1 000 Byte，包頻2 500 包/s，2路數據流同時接收的情況下，網絡傳輸性能測試結果如圖10所示，此時CPU占用率小于5%，網絡資源占用率小于5%。

圖10 網絡傳輸性能測試結果

4. 4 測試結果分析

對上述測試結果分析可知：

① 基帶板卡可以進行IP地址動態配置，滿足動態資源分配要求。

② 板級軟件加載是測控系統功能重組的關鍵步驟，在長時間測試過程中，板級軟件加載性能穩定，加載時間小于2 s且穩定性較好，在測試樣本中，加載成功率為100%，滿足使用要求。

③ 網絡傳輸平均時延為1. 472 ms，測試樣本中，時延抖動方差很小，該結果優于目前采用PCI-e接口設備的通信性能；在網絡傳輸性能方面，在進行2路數據接收的情況下，CPU和網絡占用率均維持在較低水平，可以滿足使用要求。

通過上述分析，網絡化后的基帶板卡在功能和性能均滿足系統要求。

5 結束語

本文提出了基于I/O融合技術的基帶板卡虛擬化方案，通過對板卡I/O的網絡化升級，使測控基帶設備具備了資源池化管理的條件，為實現測控系統松耦合、集約化部署奠定了技術基礎。實驗結果分析表明，采用網絡化基帶板卡構建的測控基帶資源池具備動態重組、高效傳輸和集中部署的特點，在工程應用中可顯著提高系統的擴展能力和重構能力。