網絡化測試系統中并行數據處理架構的實現*

劉兆慶,于洪彬,梁洋洋,梁軍

(哈爾濱工業大學 電氣工程及其自動化學院，黑龍江 哈爾濱 150001)

0 引言

網絡化測試系統在武器裝備測試、核爆炸試驗、航空航天測試等領域有著廣泛的應用[1]。實時性是網絡化測試系統面臨的主要問題之一[2]。除了采用高性能測試儀器和高速通信網絡外，測試數據的處理是影響系統實時性的關鍵。

目前，網絡化測試系統中大多采用集中式數據處理方式。在該方式下，數據全部存儲在主控計算機，由數據庫管理系統進行統一管理，主控計算機承擔所有測試數據的計算、綜合和處理任務。集中式數據處理方式對計算機的性能要求較高，骨干網絡帶寬壓力大，測試數據在數據庫中的查詢時間變長，數據處理時效性差[3]。隨著測試系統規模的增大，這些問題越來越凸顯出來。

在不投入更多硬件資源的情況下，為了提升網絡化測試系統的實時性，必須充分挖掘系統內的計算資源并設計相應的數據處理模式。由于嵌入式技術在儀器領域的應用不斷模糊著計算機與儀器的界限，智能儀器大多有獨立的CPU、內存、硬盤、網絡接口等一系列資源，具有一定的數據處理能力。而且隨著并行處理或分布式處理技術支持的日漸成熟，將儀器資源共享出來，聯合多個儀器資源，在主控計算機的管理調度下，協同地進行部分或全部數據處理任務，使數據處理任務以一種空間并行的方式在儀器節點本地運行，存在著降低時延，提高系統實時性的可能。這種方式有利于實時性的根本原因在于以下2點：

(1) 利用并行方式的可擴展性引入更多計算資源加入進數據處理任務；

(2) 數據傳輸以局部傳輸為主，避免了集中式處理僵硬的數據傳輸模式。

在利用儀器資源進行數據處理應以不犧牲測試任務的執行性能為前提，這要求在儀器上引入隔離技術。本文設計了一種基于儀器資源的并行數據處理計算架構。在該架構下，在主控計算機根據數據處理任務的資源需求，為任務分配滿足資源需求的物理節點；在儀器節點上，使用隔離技術，將任務進程限制在特定的資源上。構建并行數據處理平臺，利用并行FFT(faster Fourier transformation)應用驗證數據處理架構的可行性，分析了該模式的計算性能和在這種計算模式下進一步提升數據處理效率進而提高系統實時性的關鍵因素，為后續研究指出了研究方向。

1 并行計算模式和平臺構建分析

文獻[4]指出了在一個分布式系統上構建計算平臺的要解決的一般問題：

(1) 管理系統中多種硬件資源；

(2) 定義用戶可以發現、請求和使用資源；

(3) 實現在資源上并行計算的執行。

目前，尚未查找到基于嵌入式儀器進行并行計算平臺的構建方案。本文將根據網絡化測試系統簡潔、高效、實時的應用需求，結合現有并行技術、集群技術及隔離技術的技術支持，設計適宜在網絡化測試系統的平臺構建方案。文獻[5]提出了一種基于MPI(message passing interface)的云計算模型，該模型替換了Hadoop中的MapReduce編程模型，實現了在MPI計算平臺上的云計算。文獻[6]提出了利用MPI構建云計算的非虛擬化平臺，利用MPI對異構環境的支持，直接在異構環境上構建MPI集群，避免了虛擬化的性能損耗，并進一步在對MapReduce的替換、多級容錯機制等方面進行了研究。文獻[7]實現了在Docker容器上部署MPI集群用于高性能計算。MPI是一個高性能的消息傳遞模型，在注重時效性的并行計算中有著廣泛應用。但以上都是以云計算為應用環境展開的，在網絡化測試應用環境中存在著不適宜。

對于硬件設備的處理主要由2種處理方式——非虛擬化技術和虛擬化技術。非虛擬化技術應用以網格計算為代表，直接對物理資源進行管理，按照批處理方式對資源進行調度。虛擬化技術以云計算為代表，對底層硬件使用虛擬化技術構成虛擬資源，在虛擬資源上以數據為驅動進行調度。

網絡化測試系統中的計算平臺構建應強調高效實時。智能儀器相對于PC來說資源有限，虛擬化技術的性能開銷較大，影響節點計算性能和通信性能。非虛擬化技術會保留原有硬件性能，通信性能更好，有利于系統的實時性要求。網絡化測試系統中的并行數據處理不宜構建虛擬化的計算平臺。因此，資源的管理調度應以具體物理硬件為基礎，作業資源需求通過資源參數或屬性描述直接定位到具體物理節點。這可以通過本地的資源管理器實現[8]。

事實上，虛擬化技術在構建統一資源類型的同時也實現了資源的隔離與控制。虛擬機由于Hypervisor的存在，在獲得良好隔離性的同時產生了很大的系統開銷。LXC(Linux containers)和Docker是輕量級虛擬化技術，在云計算中具有廣泛應用，是滿足云計算環境需求的技術架構，但對于網絡化測試系統存在冗余封裝。LXC基于Linux內核Cgroups和Namespace構建，Cgroups進行資源管理，Namespace用于安全隔離[9-10]。本文直接調用Linux的Cgroups內核支持，實現對計算任務的資源控制。

綜上所述，本文將采用本地資源管理器實現系統資源的管理分配，采用Cgroups實現儀器節點資源的隔離與控制，采用MPI消息傳遞模型構建計算平臺。

2 適用于網絡化測試系統的計算資源模型

在分析了網絡化測試系統體系結構的基礎上，本文提出了一種雙層資源模型，用來解決網絡化測試系統中的資源問題。

雙層資源模型如圖1所示。在系統的層面上，主控計算機管理系統中所有儀器節點及其附帶的資源屬性。服務中心是系統的核心，作為全局的用戶的唯一接口，可以對系統進行查詢、配置，提交計算任務、進行任務狀態監測。調度中心根據計算任務提出的資源屬性需求，按照可插拔式的調度策略配置，以物理儀器節點作為基本單位，從系統中選出可以滿足計算需求的節點集合，給出任務運行的節點建議。

在儀器節點上，將計算所需的資源(CPU、內存等)以一定的形式聯合起來，構成資源容器，計算進程僅可使用容器內的全部資源，從而避免了不同進程間的資源搶占。

圖1 雙層資源模型Fig.1 Two-level resource model

2.1 頂層資源管理

本文采用TORQUE資源管理器實現位于頂層的面向用戶的作業管理和系統資源管理分配[11]。TORQUE是基于PBS(portable batch system)工程的高級開源產品，包含了目前最好的社區版和專業版。它具有良好的可擴展性、穩定性和功能性，因此在全世界的政府、科研、商業領域有著廣泛應用[12]。由于TORQUE可以免費被使用、修改、發布，為后續進一步研究開發提供可能，本文采用TORQUE社區版作為資源管理器。

通過在網絡化測試系統中布置TORQUE，可以達到以下目的：①以節點為基本資源單位，將節點具有的資源和特性進行定義或統計。②根據資源或特性需求，為作業找到合適節點運行。③使作業按照創建、提交、執行、結束的工作流運行，通過命令對作業進行監控或控制。

PBS有4個主要部件：命令、作業服務器、作業執行器以及作業調度器。網絡化測試系統是多機系統，其中主控計算機性能較強且更為穩定，所以主控計算機中布置服務進程(Server)和執行進程(MOM)，負責上述用戶服務器的基本功能和部分計算任務。此外，調度進程(Scheduler)運行在主控計算機上，一方面從服務器獲取集群系統上的作業信息，另一方面獲取本分區節點資源信息。主控計算機作為面向用戶的接口，需要布置客戶命令。

在儀器節點上布置執行進程，接受來自Server的加載、查詢等命令，并負責作業狀況的監測以及向Server報告作業結果信息。

PBS組件在網絡化測試系統中結構如圖2所示。

圖2 PBS組件在網絡化測試系統中結構Fig.2 Structure of PBS components in net-centric ATS

2.2 儀器資源隔離

Cgroups(control groups)是Linux內核的一個功能，用來限制、統計和分離一個進程組的資源(CPU、內存、磁盤輸入輸出等)，從而實現Linux操作系統環境下的物理分割。在Cgroups中，任務就是系統中的一個進程，控制族群是按照某種標準劃分的進程，資源控制都是以控制族群為單位實現的。一個加入控制族群的進程可以使用到為控制族群分配的資源，同時受到以控制族群為單位的限制。一個子系統就是一個資源控制器，Cgroups為每種可以控制的資源定義了一個子系統，比如cpu子系統就是控制CPU時間分配的一個控制器。子系統必須附加到一個層級上才能起作用，層級就是一棵控制族群樹，通過在Cgroups文件系統中創建、移除、重命名等操作構建的。

本文主要涉及到計算資源的控制，所以我們只關注系統的CPU資源和內存資源的控制，涉及到Cgroups子系統有cpuset，cpu和memory。將運行進程的進程號分別寫入相應子系統下的task文件，即完成了一個硬件容器的劃分并將進程限制在該容器內運行。

cpuset子系統為cgroup中的任務分配獨立CPU(在多核系統)和內存節點。通過cpuset.cpus和cpuset.mems可分別選擇使用的CPU節點和內存節點。

cpu子系統使用調度程序提供對CPU的cgroup任務訪問。比如，通過cpu子系統下的cpu.cfs_quota_us調整至cpu.cfs_period_us數值的比例限定了單位時間內使用CPU時間。

memory子系統設定cgroup中任務使用的內存限制，并自動生成由那些任務使用的內存資源報告。通過memory.limit_in_bytes限制內存使用量。

多種儀器資源整合與限制如圖3所示。

圖3 多種儀器資源整合與限制Fig.3 Integration and limitation of multiple instruments’ resources

3 實驗驗證及結果分析

本文采用1臺主控計算機和4塊Digilent公司的Zedboard實驗載板，通過商用交換機和網線互聯，用來模擬網絡化測試硬件環境。本文在該硬件平臺上，構建了基于MPI消息傳遞模型的程序開發和運行環境[13-14]。MPI標準的功能通過MPICH和Hydra進程管理器配合實現。通信系統通過一系列網絡配置，使用戶無需對每個節點進行顯示登錄操作，屏蔽了底層IP通信，在程序開發時關心的對象是計算進程。進程管理系統在機群上派生計算進程，管理用戶參數、環境變量及進程開啟節點信息等，并進行進程控制[15]。在此基礎上進行并行FFT的MPI程序進行實驗驗證。

分3種模式進行實驗，分別是：①在單一節點讀取全部數據，在該節點上進行串行FFT計算，計算結束后，將計算結果上傳主控機，在特定文件夾下生成結果文件；②依次在2個、4個節點上展開并行FFT計算，每個節點上數據子向量分別為完整數據文件的1/2和1/4，讀取數據，節點間利用本地數據或向其余節點請求各步FFT計算所需數據，完成相應部分的FFT計算，隨后計算結果被主控計算機收集并綜合生成最終結果文件；③將不同數據規模的完整數據文件拆分在2個節點上，節點讀取數據文件被主控計算機收集，由主控計算機按串行方式完成FFT計算。

(1) 算法執行時間

圖4表示FFT計算的算法執行時間隨著數據規模增加的變化情況。橫坐標表示采樣的數據點數按2的次冪增加，縱坐標表示在不同模式下的算法執行時間，可以得到以下結論：

1) 隨著數據規模按2的次冪增加，在數據規模較小時，各種模式下算法執行時間基本相同且約等于0；在數據規模較大時，隨著數據規模增大，可以看到執行時間有較為明顯的變化且按指數規律增長。

2) 在1節點、2節點和4節點進行計算時，當數據規模較大時，在數據規模相同的情況下，隨著計算節點數目的增加，算法執行時間有著明顯的減少。

圖4 不同模式下FFT計算的算法執行時間Fig.4 Execution time of FFT under different modes

3) 采用主控計算機進行數據收集進行FFT計算的模式下，執行時間小于其他模式的計算。

圖5截取數據規模為210～216部分詳細展示數據規模較小時的算法執行情況。可以看到,當數據規模較小時，增大并行儀器節點規模不能無限縮小算法的執行時間。如表1所示，2節點并行處理時間在213之前大于單節點處理，4節點并行處理時間在214之前大于其余2種節點計算模式。這是由于并行數據處理的通信開銷造成的。

圖5 210～216數據規模下算法執行時間Fig.5 Execution time of data scale varying from 210 to 216

(2) 并行數據處理通信時間分析

算法執行時間主要由通信時間和計算時間兩部分組成，圖6表現了并行數據處理中通信時間占總執行時間比例，橫坐標為數據規模，縱坐標為時間百分比。圖7表示2,4節點并行數據處理中的通信時間，橫坐標為數據規模。結論如下：

表1 210～216數據規模算法執行時間Table 1 Execution time of data scale varying from 210 to 216 s

圖6 通信時間占并行處理時間的比例Fig.6 Communication time percentage of parallel processing

圖7 并行數據處理通信時間對比Fig.7 Comparison of communication time between nodes

1) 2種不同模式的并行數據處理的通信時間基本相同，投入更多儀器節點沒有明顯的減小。

2) 4節點并行的通信時間占比明顯高于2節點并行的情況，因為隨著投入更多儀器節點進行計算，計算時間有明顯的縮減，在通信時間基本不變的情況下，4節點并行的通信占比會更大。

3) 當數據規模較小時，通信時間是主要的時間開銷。2節點并行數據規模小于等于213時，4節點并行數據規模小于等于216時，通信時間都占總時間的50%以上。

(3) 加速比與效率分析

加速比(speed-up)，是同一任務在單處理器系統和并行處理器系統中運行消耗時間的比率，用來衡量并行系統或程序并行化的性能和效果。

SP=T1/TP,

式中：SP為加速比；T1為單處理器下的運行時間；TP表示在有P個處理器并行系統中的運行時間。

效率(efficiency)，它反映了處理器的利用率，P為并行計算機中處理器的個數[16]。

EP=SP/P.

考慮到測試的應用環境，本文的加速比與效率評價中包括了單節點至主控計算機的數據傳輸時間。圖8,9分別表示2節點、4節點并行計算加速比和效率隨著數據規模變化的關系。可以得到以下結論：

圖8 并行FFT計算加速比隨數據規模變化的關系Fig.8 Speedup ratio of parallel FFT algorithm with data scale

圖9 并行FFT計算效率隨數據規模變化的關系Fig.9 Parallel FFT algorithm efficiency with data scale

1) 加速比隨數據規模增加呈上升趨勢，但數據規模較大時增速變緩。從圖中可以看到4節點并行在221時可達2.8左右(最理想情況為4)，2節點加速比可達1.8左右(最理想情況為2)。

2) 效率隨數據規模增大呈上升趨勢。雖然4節點并行計算相較于2節點可以獲得更大的加速比，但2節點的并行效率更高。

3) 數據規模較小時，并行計算的加速比和效率都比較低，這是因為在該情況下通信時間在全部執行時間中所占的比例大。

4) 可以看出,數據通信已是影響系統達到線性加速比的主要因素。

4 結束語

本文設計了一種網絡化測試系統中的并行數據處理模式，充分利用系統內計算資源，減小網絡傳輸延遲，進而提高系統實時性。成功實現了從頂層作業腳本編寫、提交，系統給出運行儀器節點建議，并行FFT程序在建議節點上運行，并將計算進程納入資源容器進行執行的工作流程。實驗結果表明，通過引入更多儀器資源，計算時間的減少較為明顯，而通信開銷卻基本不變，成為進一步提高實時性的關鍵因素。