摘" 要: 提出一個靈活的基于容器的計算平臺,用于在云上運行科學工作流程。容器集群系統為數據密集型科學工作流程帶來了很少的性能開銷,同時能夠解決工具安裝問題,保證可重復性,提高資源利用率。使用者可在幾分鐘內輕松地在任何云上部署該計算平臺。
關鍵詞: 容器; 云計算; 計算平臺; 科學計算
中圖分類號:TP311.5" " " " " 文獻標識碼:A" " "文章編號:1006-8228(2023)12-05-04
Container based scientific workflow cloud computing platform
Dai Qiang, Zhao Yihui
(Chengdu Zhonglan Information Technology Co., Ltd, Chengdu, Sichuan 610041, China)
Abstrct: A flexible container-based computing platform is proposed for running scientific workflows on cloud. The container cluster system has little performance overhead for data-intensive scientific workflows, while being able to solve tool installation problem, ensure reproducibility and improve resource utilization. Users can easily deploy this computing platform on any cloud in a few minutes.
Key words: container; cloud computing; computing platform; scientific computing
0 引言
科學數據量正在迅速增長。科學研究顯然具有工具依賴性,例如用于基因組研究的下一代測序(NGS)。云平臺已成為進行科學分析的有前途的解決方案,因為它們能夠提供強大、彈性和經濟的存儲和計算能力[1]。由于云平臺的靈活性,科學家能夠根據需要構建自己的數據分析平臺。科學工作流程是一個使用多種科學工具的數據處理管道。這些由不同編程語言開發的工具依賴于大量的庫、二進制文件和配置文件,導致了很多的工具安裝問題。當工具缺乏文檔或多個工具有沖突的依賴關系時,情況會更令人失望。此外,如果我們考慮操作系統、庫和工具版本,那么再現整個工具執行環境是非常具有挑戰性的。
一些研究[2-4]發現,容器技術,如Docker[5],是解決科學工具依賴性問題的一個很好的解決方案。通過將所有依賴項打包到Dockerimages中,工具安裝過程將不那么痛苦。同時,它保證了良好的再現性。
許多科學工作流程系統如Galaxy[7]和Nextflow,被提出來幫助科學家定義、提交、監控和管理科學工作流程。多虧了這些系統,科學家才能夠專注于他們的研究問題而不必擔心工作流執行機制的細節。然而,對于科學工作流程系統來說,工具安裝的問題是大問題,因為科學家需要運行不同的工作流程,其中包括大量的科學工具。Galaxy支持Docker來解決這個問題。然而,它只在單個計算節點上運行容器,這顯然限制了計算能力。為了充分利用可用的計算資源,我們應該能夠以可擴展的方式在多個節點的集群中運行容器化的科學工具。
容器集群系統,如Kubernetes,幫助用戶在多個節點的集群上運行容器。然而,大多數現有的科學工作流系統都不適用于容器集群系統。一些使用容器集群系統的工作流系統依賴于它們自己的專有執行引擎[2-3],而其他工作流系統則在不支持容器技術的傳統集群系統上運行任務[7]。
在本文中,我們建議使用容器集群系統作為科學工作流系統的執行引擎,這帶來了很多好處。首先,它解決了科學的工具安裝問題。我們可以將科學工具打包到Docker映像中,然后在下載相應的映像后,可以在容器內的任何啟用Docker的主機上運行這些工具。其次,它保證了高水平的科學再現性,因為Docker鏡像保證了相同的工具執行環境。第三,基于容器的方法提高了資源利用率。此外,容器集群系統可以同時運行MapReduce或Webapplication等其他任務,這將大大提高整個集群的總體資源利用率。
為了研究利用容器集群系統作為科學工作流系統執行引擎的可行性,我們開發了原型平臺,我們的初步評估結果表明,容器集群系統為數據密集型工作流引入了微不足道的性能開銷,考慮到其巨大優勢,使其成為科學工作流的一個有前途的執行引擎。
1 背景和相關工作
1.1 科學的工作流程系統
科學工作流是一種使用多種科學工具的數據處理管道,通常表示為有向無環圖(DAG),其中節點表示數據處理任務,邊表示數據流。基因組測序中使用的工作流程如,RNA Seq,包括科學工具,TopHat和Cufflink。組成科學工作流程的科學工具是使用不同的編程語言[16]開發的,它們依賴于大量的庫、二進制文件和配置文件。因此,安裝和配置科學工具對科學家來說很重要,因為他們不是計算機專家。
在生物學和天文學等各種科學界,有很多科學工作流程系統,旨在幫助科學家定義、提交、監測和管理科學工作流程。例如,Galaxy[7]是一個用于基因組研究的基于Web的工作流系統。AWE/Shock由一個對象存儲系統和一個專有的執行引擎組成,它也是一個專注于運行生物信息學管道的工作流系統。使用Nextflow編程模型,科學家能夠輕松創建并行的科學管道。對于Pegasus,來自多個領域的科學家已經使用了十多年。科學工作流程系統通常為用戶提供圖形編輯器或編程腳本來定義和提交他們的工作流程。至于工作流的執行,大多數工作流系統都能夠將任務提交給傳統的集群資源管理系統。例如,HTCondor可以用作Galaxy、Nextflow和Pegasus的執行引擎。其他工作流系統如AWE/Shock,都有自己的專有執行引擎。
1.2 容器集群系統
與虛擬機技術相比,容器技術是一種更輕量級的虛擬化技術,它還能夠隔離應用程序。在同一主機上運行的多個容器與主機共享同一內核,而共存的虛擬機運行其獨立的內核。因此,容器技術能夠提供接近本機的性能、更高的密度和更快的啟動/停止時間。Linux內核功能,如Namespaces和Cgroups,是容器技術的重要構建塊。命名空間是將容器與主機和其他容器隔離開來的關鍵,而C組可以限制容器的CPU和內存等主機資源的使用。盡管容器技術已經存在了十多年,但直到近幾年,隨著名為Docker的容器工具的普及,它才越來越受歡迎。
事實上,Docker已經成為業界廣泛使用的事實上的標準容器工具。通過使用Docker,我們可以方便地創建、停止、重新啟動和刪除容器。這種良好的用戶友好性為Docker的成功做出了很大貢獻。將應用程序及其依賴性打包到輕量級Docker映像中的能力是Docker的另一個高級功能。我們可以下載Docker鏡像并在任何啟用Docker的主機上運行應用程序,而無需擔心費力的安裝步驟。這對我們解決工具安裝和云部署問題有很大幫助。容器集群系統彼此非常不同,但他們都有一個主/從體系結構。主節點將容器調度到從節點,從節點負責執行容器。例如,谷歌在Borg上運行了近十年的內容,包括網絡搜索、Gmail和谷歌文檔。因此,容器集群系統也可以用于運行科學工作流程。
2 平臺體系結構
2.1 科學計算平臺
本文討論的科學計算平臺由科學工作流程系統、容器集群系統、存儲系統和各種科學工具組成。科學家使用科學工作流程系統來提交、監控和管理他們的工作流程。組成工作流的科學工具將在容器內執行,容器集群系統負責調度和執行這些容器。所有輸入和輸出數據都存儲在存儲系統中。
所提出的體系結構,利用容器集群系統作為科學工作流的執行引擎。像Skyport這樣的現有系統將工作流系統和執行引擎緊密耦合,而我們的平臺則將工作流系統與執行引擎解耦。工作流系統和執行引擎的解耦大大提高了科學計算平臺的靈活性;也就是說,用戶能通過熟悉的工作流系統和合適的容器集群系統來運行他們的工作流。
理論上,除了具有特定硬件要求的工具(例如,高RAM)外,我們提出的平臺能夠運行幾乎任何類型的科學工作流程。此外,與其他工作流平臺不同,我們的平臺上不需要預先安裝任何科學工具或其依賴性。科學工具在容器中運行,可以在計算集群的任何節點上進行調度。如果沒有容器,任務可以在安裝了所需工具的特定節點上運行。
由于系統的復雜性,在云上部署或復制科學計算平臺是非常具有挑戰性的,尤其是對于缺乏計算機技能的科學家來說。為了解決云部署問題,所提出的架構在Docker容器中運行整個平臺。由于容器技術的強大可移植性,該平臺可以在任何云上創建,而不會出現供應商鎖定問題。
事實上,有許多科學工作流程系統在不同的科學界很受歡迎。對于容器集群系統,我們也有很多選擇。對于存儲系統,共享文件系統、對象存儲系統或其他存儲系統也可以是候選系統。最終,我們計劃為各種選擇提供支持,然后科學家將有充分的靈活性來選擇和組合他們喜歡的組件,以在云上構建定制的科學計算平臺。選擇合適的容器集群系統可能會顯著影響用戶應用程序的性能。
2.2 Galaxy工作流科學計算平臺
作為案例研究,我們選擇了廣泛使用的生物工作流系統Galaxy來構建原型平臺。Galaxy為科學家提供了一個網絡界面來定義他們的工作流程。四個廣泛使用的容器集群系統充當執行引擎。所有科學工具都在Docker容器中運行。目前,我們使用NFS作為存儲系統,并計劃在未來的工作中嘗試其他存儲系統來提高可擴展性。
為了研究利用容器集群系統作為科學工作流系統執行引擎的可行性,我們將Galaxy與Docker Swarm、Kubernetes和Mesos/Aurora三個通用容器集群系統集成。此外,我們還支持HTCondor,這是一個在HPC社區廣泛使用的傳統集群系統。HTCondors最近支持Docker。
我們在Galaxy中實現了四個作業運行程序作為容器集群系統的接口。作業運行程序負責提交,監控和刪除相應容器集群系統上的作業。將作業提交到不同容器集群系統的能力提高了我們平臺的靈活性。此外,對這些容器集群系統做比較對于促進容器集群系統在科學工作流方面的應用也很有價值。
2.3 Docker的實現設置
我們實現了兩個選項來運行容器中的所有內容,Docker in Docker和Sibling Docker。我們還實現了兩種在沒有容器的情況下運行集群從機的選項,即Docker中的Tool和without Docker,以研究容器化一切的靈活性和開銷。
⑴ Docker中的Docker:對于Docker的Docker,clusterslave容器直接在主機上運行,而科學工具容器在slave容器內運行。運行在主機上的Docker守護進程啟動集群從容器,而運行在slavecontainer內的Docker后臺進程負責管理科學工具容器。集群從進程請求內部Docker守護程序啟動、監視和刪除科學工具容器。我們不限制從屬容器的資源使用,例如CPU和內存,這意味著從屬容器能夠消耗盡可能多的主機資源。Docker中的Docker通過引入兩層Dockerization,有效地解決了集群從屬和科學工具的部署問題。Docker中Docker比Sibling Dockersion更容易實現,因為它是Docker原生支持的,尤其是在Docker 1.8.0之后自動安裝到容器中的Cgroupsis。事實上,Docker-in-Docker方法最初是在虛擬云提供商(VCP)項目[6]中提出的,它是我們平臺在容器中運行一切的直觀方法。
⑵ Sibling Docker:Sibling Docker,集群從屬容器和科學工具容器在主機上并排運行,即從屬容器和科技工具容器都在同一臺主機上運行。只有一個Docker守護進程在主機上運行,它負責管理從屬容器和科研工具容器。通過使用Docker卷或環境變量將Docker RemoteAPI端點(即Unix套接字或TCP套接字)映射到從屬容器,來自clusterslave的所有容器管理請求都將發送到外部Docker守護進程。因此,科學工具容器是由外部Docker守護進程啟動的,而科學工具容器直接在主機上運行。與Docker中的Docker一樣,我們對slavecontainer沒有設置資源限制,因此主機的所有資源對于集群slave都是“可見的”,科學工具容器能夠確保所有主機資源。從用戶的角度來看,Sibling Docker的工作原理與Docker中的Docker相同,因為它們都在容器中運行集群從屬工具以及科學工具。Sibling Docker只能部署在安裝了特定版本Docker的主機上,這使得Sibling Docker方法的可移植性不如Docker方法中的Docker。
⑶ Docker中的工具:當只有科學工具在Docker容器中運行,而集群從機直接在主機上運行時,我們將其命名為Docker中工具。主機上的Docker守護進程會實例化工具容器,以響應集群從機的請求。對于Docker方法中的Tool,我們不必擔心工具安裝問題,因為所有容器都在基于相應Docker映像的Docker容器中運行,其中已經打包了科學工具及其依賴項。這大大提高了平臺的靈活性,因為我們可以在任何節點上運行幾乎任何科學工具,而無需在這些節點上安裝任何工具。然而,我們必須手動安裝和配置容器集群系統,這通常是有挑戰性的。根據我們的實驗經驗,安裝容器集群系統,包括Docker Swarm、Kubernetes、Mesos/Aurora和HTCondor,由于其大量的依賴性、多個系統組件、復雜的配置文件和準確的文檔,所以非常困難。此外,當我們想要在云上部署或復制平臺時,這種方法會引起很多麻煩。總之,在容器中運行科學工具有很大好處,但僅僅將科學工具容器化并不能解決本文討論的問題。
3 結論
容器技術是解決科學計算平臺依賴性問題的理想技術,其近年來越來越受歡迎。像Docker Swarm這樣的容器集群系統,由于其固有的性能和巨大的靈活性,是科學工作流系統的有前途的執行引擎。此外,通過利用容器技術,我們可以在幾分鐘內輕松地在任何云上部署您的科學計算平臺。根據我們的實驗結果,Docker中的Sibling Dockeran和Docker的性能幾乎相同。得益于它的完全封裝,Docker中的Docker比Sibling Docker具有更好的可移植性。而對于Sibling Docker來說,它只引入了一層Docker虛擬化,可簡化容器管理。因此,必須在更好的可移植性和更容易的管理之間進行權衡。
參考文獻(References):
[1] V. Marx, “Biology: The big challenges of big data,\" Nature,
2013,498(7453):255-260.
[2] E. Deelman, K. Vahi, M. Rynge et al., \"Pegasus in the
Cloud: Science Automation through Workflow Technologies,\" IEEE Internet Computing, 2016,20(1):70-76.
[3] W. Gerlach, W. Tang, K. Keegan et al., \"Skyport:
Container-based Execution Environment Management for Multi-cloud Scientific Workflows,\" in 5th International Workshop on Data-Intensive Computing in the Clouds,2014.
[4] C. Zheng and D. Thain, \"Integrating Containers into
Workflows: A Case Study Using Makeflow, Work Queue, and Docker,\" in Proceedings of the 8th International Workshop on Virtualization Technologies in Distributed Computing,2015(6).
[5] S. Yokoyama, Y. Masatani, T. Ohta et al., \"Reproducible
Scientific Computing Environment with Overlay Cloud Architecture,\" in 9th IEEE International Conference on Cloud Computing,2016(6).
[6] Docker. [Online]. Available: https://www.docker.com.
[7] J. Goecks, A. Nekrutenko, J. Taylor et al., \"Galaxy: a
comprehensive approach for supporting accessible, reproducible, and transparent computational research in the life sciences,\" Genome Biology,2010,11(8):1-13.