基于容器技術的天文應用軟件自動部署方法*

姚 坤，戴 偉，楊秋萍，梅 盈，石聰明，王 鋒,

(1. 昆明理工大學云南省計算機技術應用重點實驗室，云南 昆明 650500;2. 中國科學院云南天文臺，云南 昆明 650011；3. 廣州大學天體物理中心，廣東 廣州 510006)

平方千米陣列(The Square Kilometre Array, SKA)是目前待建的全世界最大口徑天文射電望遠鏡，其中科學數據處理器(Science Data Processor, SDP)是重要的工作包之一。為了解決超大規模數據處理中面臨的問題，近幾年科學家在多個領域開展了一系列研究，包括硬件加速器、計算框架[1]、系統框架[2]等，取得了一系列的成果[3]。

在諸多平臺技術選型中，云計算以節省成本、資源動態整合、動態可擴展、簡化管理維護和災難恢復等特性成為平方千米陣列天文數據處理的一種選擇。與一般的基于互聯網的應用部署不同，天文軟件一般在部署運行時需要非常多的第三方庫支持，運行時也有諸多參數以滿足不同的要求。天文領域對容器技術的使用還停留在天文應用軟件的封裝層面，特別是在天文應用軟件有專人管理的情況下，用戶面臨等待系統管理員部署特定軟件的交付延遲問題[4]。如何在云環境下快速部署，大幅度降低使用成本和提高整體系統的可用性迫切需要進一步實驗與研究。同時，如何使用Docker[5]配合OpenStack[6]，Mesos和Kubernates等容器編排軟件對復雜的天文應用軟件進行封裝，從而加快部署速度[7]成為當前天文應用軟件的熱點。

子空間交替泛期望最大化校準算法(Space Alternating Generalized Expectation Maximization Calibration, SAGECaL)[8]是一種執行速度快、內存效率高的射電干涉校準程序。它支持點源、高斯和時間序列等多種模型。SAGECal支持通用天文學軟件應用包(Common Astronomy Software Application, CASA)的測量數據集(Measurement Set, MS)數據，在分布式應用中實現了交替方向乘子法(Alternating Direction Method of Multipliers, ADMM)參數的自適應更新[9]。SAGECaL使用期望最大化(Expectation-Maximization, EM)算法獲得對觀測儀器和天空模型的最大似然估計參數技術。普通的期望最大化算法應用非線性疊加信號的參數估計，SAGECaL采用一種被稱為子空間交替泛期望最大化算法，它與普通期望最大化算法相比提高了收斂速度，與最小二乘估計法相比減少了計算復雜度，與剝離校準方法相比提高了校準質量。為了應對新一代射電干涉望遠鏡的海量數據計算需求，SAGECaL支持在頻率上分布式并行校準，代碼實現時可以支持單中央處理器、硬件圖形處理器或消息傳遞接口(Message-Passing-Interface, MPI)并行計算等多種部署環境。

在平方千米陣列科學數據處理器的方案設計階段，為給出較為可信的計算資源需求分析以及能耗設計，項目組和國外團隊在合作中，擬通過在不同環境下SAGECal的部署與實際運行，給出不同配置、不同節點數、不同參數和輸出精度情況下的系統開銷分析結果，根據能源與計算開銷最終給出數據處理的較優設計。顯然，采用傳統的手工安裝與環境配置的方法遠遠不能滿足工作開展的要求。本文在云環境下快速部署SAGECal軟件開展了深入研究，獲得了較好的解決方法，有效推動了科學數據處理器相關工作的開展。

1 基于容器技術的自動部署

1.1 基本需求分析

為了有效地給出測試數據，重點研究了如何快速部署一個基于SAGECaL/MPI的分布式集群(以下簡稱集群)，部署過程中的關鍵點：

? 根據節點情況編輯集群列表

? 設置集群節點處于同一網段

? 配置網絡文件系統(Network File System, NFS)

? 配置各節點安全外殼協議(Secure Shell, SSH)免秘鑰登錄

? 配置MPI集群環境

? 各節點的CASACORE，SAGECaL和OpenMPI使用同一版本編譯

在部署和使用過程中還面臨以下問題：(1)由于用戶硬件環境和使用偏好的差異，用戶所選Linux操作系統發行版本呈現多樣化，SAGECaL的編譯和部署需要專有設置；(2)SAGECaL的編譯需要人工解決組件依賴關系，特別是SAGECaL-MPI和SAGECaL-GPU的編譯，還需根據實際情況人工編輯配置文件才能編譯成功。這對非專業人員來說，極大地增加了部署的難度。

針對上述關鍵點，擬通過一套配置腳本自動配置部署過程中的每一個環節。在實際部署和使用過程中面臨的問題可以通過Docker對SAGECaL進行封裝解決，配合使用交互式友好的用戶接口，進一步降低使用難度。

1.2 部署的整體思路

集群的自動部署通過Docker構造SAGECal鏡像(以下簡稱鏡像)，并通過部署服務啟動鏡像生成多個SAGECaL容器(以下簡稱容器)，然后各容器通過覆蓋網絡(Overlay Network)進行跨容器通訊實現自動配置。其中，構造鏡像時不僅封裝了SAGECal軟件，還封裝了自動部署的配置腳本用以啟動節點時根據節點角色的不同產生不同的配置行為。Docker Swarm(以下簡稱Swarm)是Docker自帶的集群管理工具，主要作用是在若干臺主機上建立容器云并通過統一入口管理容器云上的各種資源[10]。

如圖1，用戶首先對可用機器進行初始化，包括創建集群管理的容器云、配置網絡文件系統和創建私有鏡像倉庫。構建服務和銷毀服務分別用于構建鏡像和集群銷毀。部署服務會調用構建服務和銷毀服務并實現服務編排、彈性伸縮、集群節點發現與維護和用戶接口等功能。在集群運算結束后用戶可以從網絡文件系統指定目錄獲取處理結果。

1.3 鏡像的構建與組成

如圖2，鏡像是基于Linux主流發行版基礎鏡像構建的。本文選用Debian8.6基礎鏡像通過Dockerfile方式構建鏡像，鏡像中的主要軟件包括SSH, CASACORE, Glib, OpenBLAS, Gcc, Make, OpenMPI和SAGECal。

作為通用鏡像，為了讓節點容器在啟動后能夠根據自身在集群中的不同角色自動進行不同的操作，在制作鏡像時需要將定義了不同操作的腳本以及自動維護集群列表的相關腳本一同打包進鏡像[11]。同樣，為了實現集群內部節點間及裸機操作系統與集群主節點間的SSH免秘鑰登錄，裸機操作系統的公匙也需寫入鏡像并配置SSH登錄免提示等相關配置工作。

1.4 自動部署

1.4.1 初始化

首先，對可用物理機進行初始化。提前選取一臺物理機作為物理機機群的主節點，其余物理機作為物理機機群的子節點。通過人工配置的方式在各臺物理機操作系統中配置SSH免秘鑰登錄和設置開機啟動的自動化腳本，使得各臺物理機開機后主動向物理機機群的主節點發起并保持SSH連接，從而讓主節點感知到其余物理機的存在并一直監控和維護物理機機群列表的變化。

其次，配置網絡文件系統用于容器間共享數據。本文中所有機器都將各自的網絡文件系統共享目錄掛載進容器，這樣用戶就可以通過裸機操作系統直接和容器進行數據交換。

然后，創建私有鏡像倉庫并配置負載均衡服務用于鏡像分發。如圖1，基于對鏡像分發容錯的考慮，私有鏡像倉庫采用橫向擴展的形式分布在多臺物理機上，構建好鏡像后將同時推送鏡像至各私有鏡像倉庫。通過配置Nginx負載均衡服務以提供統一的鏡像拉取地址供自動部署服務從私有鏡像倉庫下載所需鏡像并啟動容器進入工作狀態。

圖1 自動部署流程圖
Fig.1 Diagram of automatic deployment

最后，自動部署容器云。容器云部署模塊封裝了直接在物理機機群主節點執行命令的腳本、按照IP列表批量執行命令的腳本和物理機機群列表對比監控等功能的腳本。如圖1和圖3，通過用戶接口調用容器云部署模塊對容器云進行自動部署。具體部署流程如下：

(1)容器云部署模塊通過封裝集群主節點初始化命令對集群主節點進行初始化并將獲得的加入命令寫入一個臨時文件以備后期調用。

圖2 自動部署腳本封裝示意圖
Fig.2 Diagram of automatic deployment script encapsulation

(2)容器云部署模塊從物理機機群列表第2行開始依次讀取IP地址并配合批量執行命令的腳本對目標物理機遠程執行第(1)步中獲得的加入集群的命令。

(3)物理機機群列表對比監控功能持續通過封裝了集群節點查看命令的功能模塊維護集群IP列表，同時不斷地將集群IP列表與物理機機群列表進行比對。當兩個列表的行數一致、內容一致和集群節點的狀態為活動態時，認為所有物理機加入了集群，然后啟動初始界面等待用戶輸入集群自動部署命令。

(4)當有新的物理機開機時，物理機機群列表會自動更新，同時觸發容器云部署模塊對新加入的物理機執行第(1)步中獲得的加入命令，使其自動加入集群。

圖3 容器云創建示意圖
Fig.3 Block diagram of container cloud creation

通過物理機機群列表對比監控功能的持續監控，不但實現了物理機數量動態變化的容器云自動維護，還對容器云的自動部署具備一定的容錯功能。后期的集群自動部署都在容器云上實現。

1.4.2 創建Overlay網絡和集群節點

在啟動集群節點前，需要準備好Overlay網絡以供節點容器在私有邏輯網上進行跨主機通訊。在自動部署過程中創建Overlay網絡通過封裝如下命令實現網絡配置和指定網絡名稱。

自動部署還封裝了集群服務聲明性模型的相關命令來定義服務的期望狀態，并依賴Docker維持該狀態和編排相關的服務。本文集群的節點分別由主服務編排主節點、工作服務編排子節點。具體命令如下：

按照角色的不同，集群的節點起初都是每組服務啟動一個容器，但子節點數會按照工作服務的配置進行彈性擴容。兩組服務都綁定了同一個Overlay網絡和一致的NFS目錄。mpi_bootstrap文件定義了一組操作命令，它會根據role參數決定這個節點容器在啟動后執行何種操作。其中，主節點還傳遞了host_number參數作為集群規模的預設值。集群服務雖然可以設置容器數量，但運行集群還需要通過在容器內自動維護集群列表并確保達到集群規模預設值后才執行用戶輸入的集群計算命令。

1.4.3 集群節點的發現與維護

集群節點的發現采用節點主動暴露IP的方式實現。主節點最先啟動，啟動后開啟對地址解析協議(Address Resolution Protocol, ARP)緩存的持續監控。各子節點啟動后主動向主節點發起SSH連接并訪問主節點dev目錄下的null文件。通過持續保持與null文件的連接，主節點便通過地址解析協議緩存感知子節點的IP變化以達到集群列表動態維護。SSH連接命令如下：

由于預設了集群規模，所以還需要一個變量作為標識來通知集群維護模塊創建的集群是否達到既定規模。本文設置了CLUSTER_GET_READY變量并默認0為集群未準備就緒，1為集群準備完畢。主節點通過不斷監控集群列表的變化情況發現集群達到既定規模時，變量值被修改為1并告知主節點停止對集群列表的監控，然后啟動圖4所示初始界面等待用戶輸入集群計算命令。

1.4.4 用戶接口

集群的自動部署由圖4中例2所示命令啟動。用戶根據實際需要設置集群規模，待自動部署完成后用戶界面會停留在初始界面并等待用戶輸入集群計算命令或其他命令。通過提供交互友好的用戶接口，用戶只需提供較少的必要參數即可完成集群計算、終止并刪除集群和進入集群節點查看運行情況等多種操作。

1.4.5 容錯處理

集群自動部署過程中會出現硬件資源不足、主節點沒有啟動或崩潰和網絡中斷等因素導致部署過程出錯。如果集群長時間沒有準備就緒，自動部署模塊會進行回退處理釋放資源。如果回退失敗，可以手工運行圖4中例5所示命令強制銷毀已創建的服務并將所占資源全部釋放。經過檢查資源申請參數和網絡可達性后可再次執行集群自動部署命令進行自動部署。

總的來說，對于自動部署的全過程，如果各個部分的容錯機制失效，采取的默認策略是回退并釋放資源。

2 實驗設計

圖4 初始界面
Fig.4 Initial interface

通過實驗，測試并比較在不同服務器數量和不同集群規模情況下集群部署和集群計算的時效性以及選用分布式部署進行集群計算的合理性。

2.1 實驗環境

實驗所用服務器型號均為曙光天闊620R，使用Debian9.4 stable作為物理機操作系統并安裝Docker18.03.1-ce和NFS組件。基礎服務節點安裝了Docker，NFS服務端和部署Docker私有鏡像倉庫，其他節點安裝了Docker和NFS客戶端。基于Debian8.6基礎鏡像采用Dockerfile構建鏡像的方式進行構建。

本次實驗使用十二臺服務器，其中基礎服務節點作為主節點，其余機器作為子節點。服務器之間使用千兆以太網相互連接且在同一個網段內可以相互連通，集群運行在私有Overlay網絡中。為了盡可能地還原真實的部署情形，每次進行實驗之前都會清除服務器上所有鏡像，以確保每次自動部署都從頭執行。為了防止集群計算的時間被緩存影響，每次實驗完成后均對所有服務器進行重啟操作，確保清空所有計算過程中產生的緩存內容。實驗所用MS數據來源于SAGECaL自帶的測試數據。

2.2 時效性和合理性

實驗在容器云環境下通過在不同數量服務器上部署不同規模的集群觀察集群部署和集群計算的時間變化情況。每組部署共進行5次并記錄完成時間，取平均數作為最終部署完成時間。集群計算命令如下：

為了降低計算量，各組實驗只計算一個MS數據，交替方向乘子法迭代次數設置為20次。進程數依據容器數設定，每一個節點就是一個容器，一個進程對應一個容器。命令執行時間存放在/root/project/ResultOutput/目錄下的TimeProcessOutput文件中。集群的緩存文件存放在/tmp文件夾下。待處理的MS數據存放在/root/data/MS/文件夾下。集群計算選擇使用3c196模式，最終計算結果存放在/root/project/ResultOutput/目錄下的sm.ms.solutions文件中。

曙光天闊620R服務器配備兩顆4核中央處理器和4 G內存，總共有12臺可用服務器。每一個集群節點在計算時啟動一個進程，也就是在96個集群節點以內的規模，一個進程對應一個中央處理器內核。集群計算時間指集群部署好以后從啟動命令開始到得到計算結果的時間。整體部署時間指從私有鏡像倉庫下載鏡像到集群部署完畢的時間。集群創建時間指服務器在已經下載好鏡像的情況下部署一定規模的集群花費的時間。

表1 實驗結果統計表Table 1 Statistical table of experimental results

從表1可以看出，集群的創建時間很短，加上SAGECaL鏡像的傳輸時間，1 000個節點的集群在一分鐘內部署完畢是傳統人工部署不能比擬的。隨著服務器數量的增加，計算能力得以提升，集群計算時間逐漸縮短。但隨著計算進程數超過可用中央處理器內核數后，由于存在大量進程切換，計算時間有小幅增長。

如圖5，整個部署過程中鏡像的網絡傳輸時間所占比例仍然很大，在鏡像分發過程中集群的網絡傳輸時間損耗依舊明顯。但從圖6可以看出，在1 000個節點的規模下，整體自動部署時間與集群計算時間相比，整體自動部署時間所占比例僅為10%。由此可知，部署過程的時間損耗并不是主要因素，性能瓶頸仍然在硬件的計算能力上。通過分布式整合額外的計算資源并通過自動部署方法提高部署效率，在容器云下部署SAGECaL這類計算密集型的應用是合理的。

圖5 集群部署時間
Fig.5 Cluster delployment time

圖6 部署時間與計算時間
Fig.6 Deployment time & calculation time

3 結論與展望

云環境下使用基于容器技術的自動部署方法，在提高部署效率的同時便捷地整合了更多的計算資源，使得天文應用軟件一次編譯后可以方便地運行在不同的硬件資源上。實驗結果表明，本文給出的自動部署方法極大地提高了集群的部署效率，方便用戶把主要精力集中在天文數據處理層面。

為了應對海量數據處理的需求，在當前并行化發展的趨勢下，部分天文應用軟件已經對基于消息傳遞接口分布式并行計算的并行方式提供了支持。基于容器技術的自動部署方法可以對所有基于消息傳遞接口分布式并行計算的天文應用軟件提供良好的支持，是一種通用的自動部署方法。

當下的消息傳遞接口集群自動部署方法存在主節點一旦沒有最先啟動或是崩潰后整個部署過程將完全失敗的問題。部署過程中雖然可以使用資源調度算法分配節點所在位置，但這樣的資源調度方式僅適用于平等地位的節點調度，對于消息傳遞接口集群這樣有主次之分的節點調度還需要進一步完善調度機制。下一步嘗試使用Zookeeper或是P2P算法結合對物理機的實時性能動態采集與對比，探尋一種同時具備節點容錯和自我演化功能的自動部署方法，讓各節點在初始狀態下進行平等地位的部署，然后根據自身所在的環境性能情況和部署狀況自我演化出合適的角色并進行動態自動部署。

致謝：感謝國家天文臺-阿里云天文大數據聯合研究中心對本文工作的支持。