Volcano：容器批量調度器實現材料模擬并行計算【與云原生的故事】

容器技術能夠在性能損耗可忽略的前提下，使得材料模擬環境具備隔離性和可遷移性，但是將容器編排服務應用到材料模擬領域還需要開展多方面的研究工作，尤其是對于如何在材料模擬任務中發揮出容器編排服務的優勢，以及如何使用更加貼合深度學習、大數據及 MPI 等計算模式的調度引擎來完成容器化科學計算任務，還缺乏相關的研究和實踐。在容器化材料模擬應用中研究如何將 Kubernetes 擴展為批量容器調度模式，有利于容器技術更加深入地應用到高性能計算領域。因此本文將面向 Kubernetes 等容器編排服務，在 Volcano 批量容器調度引擎的加持下，就解決材料模擬等科學計算中存在的部署困難、環境依賴混亂，以及容器化應用批量計算時容器狀態一致性等限制問題，展開分析和研究。

云原生與材料模擬現狀

能源、環境危機等當代社會問題導致新型材料的需求量日益增長，計算輔助材料模擬儼然成為現代能源、功能材料分析的主要方式之一。但由于高性能計算系統的性能增長幅度遠不及材料原子體系規模的擴大幅度，未來需要使用智能計算的方式來加快計算輔助模擬的時間尺度。高性能計算、人工智能和物理模型三者結合有望成為材料模擬領域中新的計算模式。

基于容器的虛擬化技術能夠有效隔離不同材料模擬應用的依賴環境，并且能夠在多種平臺上進行遷移和擴展。一些深度學習訓練和材料模擬任務需要多個容器同時配合運行，這就需要一種面向作業的批量容器處理系統。常見的高性能計算集群批量作業調度器（工作負載器）是面向節點等計算資源，并不是面向容器的，它無法深度集成容器管理功能和容器生命周期控制機制。在材料模擬研究中控制并調度容器以完成分子動力學模擬作業，這需要一套完善的容器批處理系統，該系統除了需要容器編排服務用于管理容器等資源，還需要批量容器調度器提供面向作業的批量容器調度機制。

Docker Swarm 和 Kubernetes 兩種容器編排服務在材料模擬作業的適用性上仍然存在一定的限制。例如，Kubernetes 內置的資源調度程序根據容器對 CPU 和內存等資源的請求，依次調起每一個容器并開始運行服務，但是對于某些分布式深度學習訓練任務或并行分子動力學計算任務，需要多個容器環境同時啟動成功后，才能夠開始進行計算，此類計算任務中包含的多個容器的狀態必須是同步的， Kubernetes 需要新的容器調度引擎以滿足這一需求。同時，將異構計算資源細粒度地分配給容器，還需要一些對包含GPU在內的異構計算設備混合調度能力。

Docker Swarm 和 Kubernetes 在運行材料模擬作業時，都存在一定的缺陷和不足，具體表現在如下幾個方面：

（1）作業生命周期的管理。對于 MPI 并行計算模式，各個并行節點之間的容器需要頻繁交互計算數據，此時如果某個容器出現故障，那么執行作業的所有容器都應該被重啟。這個機制在 Docker Swarm 和 Kubernetes 上都是缺失的。例如使用Docker Swarm 運行分子動力學模擬作業時，如果 Worker 節點的容器發生故障，那么 Master 節點的容器計算任務不會自動重啟，滯留在故障狀態。

（2）任務清理。當材料模擬作業計算完成后，應當釋放計算資源以供其他作業使用。但是 Docker Swarm 和 Kubernetes 在計算任務結束后，容器還在繼續以長服務的方式運行，此時需要手動刪除整個任務部署才能釋放資源，缺少對容器針對性清理的機制。例如使用 Kubernetes 執行完分子動力學模擬作業后，負載計算任務的 Pod 不會自動進行資源釋放，導致其他 Pod 申請不到足夠的資源，此時形成資源請求死鎖。

（3）多元異構資源的支持。CPU + GPU 的異構計算在材料模擬中應用廣泛，使用Docker Swarm 或 Kubernetes 進行異構計算時使用 NVIDIA Docker 插件在容器中調用 GPU 設備，但是在默認情況下兩者都缺少對 GPU 設備的管理方案，對于多個GPU 占用率低下的容器，不能充分利用 GPU 資源。

（4）調度策略。在以 Slurm 作為批量作業調度器的集群中，是以作業為調度對象的，而 Docker Swarm 和 Kubernetes 以容器或 Pod 為調度單位。當計算資源不足以運行即將調度的一批容器時，Docker Swarm 和 Kubernetes 不會感知到作業整體的資源占用。例如，將需要5個節點的并行計算任務提交到4個節點上，Kubernetes 會依次將4個 Pod 調度到4個節點上，當調度第5個 Pod 時，發現資源不足，此時之前的調度全部作廢。容器編排服務缺少以作業為整體的調度策略。

基于Volcano的容器批處理系統

Volcano 是基于 Kubernetes 的容器批量調度引擎，它提供了 Kubernetes 目前缺少的一套作業管理機制，該機制正是深度學習、大數據應用、科學計算、特效渲染等多種高性能工作負載場景所需的。作為一個通用容器批量調度器，Volcano 與主流計算框架（例如 Spark，TensorFlow，Argo，OpenMPI 等）均實現了對應接口，還提供了包含 CPU（ ARM 架構）和 GPU 在內的異構計算設備混合調度能力。因此，對于材料模擬領域所需的材料模擬應用環境和深度學習環境，基于 Kubernetes 的 Volcano 不但能夠將這兩種環境一次封裝進容器中后多次使用，還能夠滿足在多個封裝后的容器之間進行并行計算的條件，以作業的形式在容器化的材料模擬系統中進行批量容器調度。

方案設計

方案介紹

Volcano批量容器調度器及調度策略

在混合多種場景的高性能計算系統中，不同的應用場景需要不同的計算框架。 目前沒有一種資源管理系統能做到各種計算框架、業務場景的統一，資源管理層形成相互獨立的、分割的 “孤島”，這樣會導致組件無法解耦，資源管理混亂，硬件利用率低下等問題。 Volcano 是基于 Kubernetes 的容器批量計算平臺，它適用于大規模的容器應用場景，提供了 Queue 和 Volcano Job 通用作業管理 API，支持在線和離線作業混合部署。Volcano 集成了多種主流的計算框架，結合 Kubernetes 的資源管理功能，將多種混合場景的資源管理層統一化管理，因此 Volcano 對于高性能計算、 人工智能和物理模型融合的新型計算模式的發展有重要的影響。

它主要解決了 Kubernetes 以下幾個限制：

（1）作業管理能力的缺失。Kubernetes 基本調度單元是 Pod，不能感知到多個 Pod 存在作業層面的聯系。Volcano Job 將一組關聯的 Pod 抽象成作業，不但能夠控制整個作業的生命周期（啟動、終止、完成、重啟），而且提供了資源隊列，作業任務依賴等方面的支持。

（2）任務清理。Volcano 在作業執行完成后，不會直接將 Pod 刪除，而是將 Pod 標記為完成狀態（日志和輸出結果得到保留），釋放 Pod 占用的資源，完成本地資源回填，提高資源利用率。

（3）調度策略的局限性。Kubernetes 沒有針對科學計算作業進行資源預留， 不支持作業間的公平調度等調度策略。Volcano 為成組的容器提供批處理功能， 能夠解決以上缺陷導致的局部容器無效啟動，以及當整體作業失敗時的資源無效占用問題。

（4）對各領域的計算框架支持不足。不同作業場景需要不同的計算框架， Kubernetes 很難統一集成。Volcano 集成了多種作業場景的計算框架，例如 TensorFlow、Spark、Argo、OpenMPI 等。

Volcano 主要在 Kubernetes 的資源管理功能基礎上進行擴展，與 Kubernetes 結合后的各組件架構如圖1所示，藍色部分為 Kubernetes 的組件，綠色部分為 Volcano 的組件。

圖1 Volcano架構

從架構上看，Volcano 在 Kubernetes 的基礎上增加了 volcano-admission、volcano-controllers、volcano-scheduler 三個組件。這三個組件的運作流程如下：

（1）volcano-admission 初始化后，kubectl 將在 kube-apiserver 中創建 Job （Volcano CRD）對象，使用 vsub 以命令行的方式提交作業。

（2）volcano-controllers 會根據 Job 的配置創建相應的 Pod 及 PodGroup。 volcano-controllers 包含了 QueueController、JobController、PodGroupController 等。 JobController 是本實驗的主要控制器，工作原理如圖 2 所示。

圖2 Volcano的JobController工作原理

（3）Pod 及 PodGroup 創建好后，volcano-scheduler 會從 kube-apiserver 中 獲取 Pod 或 PodGroup，以及對應節點的信息。Kubernetes 允許多個調度器在集 群系統中并存，為了保證高性能計算作業運行時的穩定性，防止發生調度器沖突， 本實驗用volcano-scheduler完全替換了Kubernetes的原生調度器kube-scheduler。

（4）volcano-scheduler 獲取到 Cache 處理過的相應信息（Jobinfos）后，將 根據其配置的調度策略（以插件的形式配置）為每一個 Pod 選取合適的節點， 調度過程在一個 Session 會話中進行，每個調度周期會創建一個 Session。volcano-scheduler 工作原理如圖 3 所示。

圖 3 推特數據中心資源利用率

（5）在為 Pod 分配節點后，kubelet 將從 kube-apiserver 中獲取 Pod 的配置， 啟動相應的容器。Pod 的生命周期如圖 4 所示，Volcano 在 Kubernetes 的默認 容器狀態（藍色部分）上加入 volcano-scheduler 中的 Sessison 調度狀態（綠色部 分）和 Cache 狀態（橙色部分）。

圖4 Volcano的volcano-scheduler工作原理

通過分析分子動力學模擬場景下的計算需求，結合 Kubernetes 和 Volcano 組件的各個功能，將 Kubernetes 和 Volcano 二者應用于材料模擬中的優勢在于：

（1）能夠提供通用的作業類型。開發者可以在 Volcano Job 定義文件中描述大部分分子動力學模擬任務，包括指定作業提交時的變量、命令，以及對計算資源的需求量，指定不同類型計算節點等。

（2）能夠支持高性能并行計算框架。在分子動力學模擬計算領域，通過多節點并行計算模擬可以很大程度地提高作業運行效率，并行計算作業一般需要 MPI 實現。Volcano 通過配置 SSH 插件的形式使得容器之間可以直接在 Kubernetes 網絡上進行數據通信。

（3）能夠管理作業生命周期和選擇合適的調度策略。Volcano 通過控制分子動力學模擬作業的生命周期，自動執行計算任務結束后的資源回填，不需要開發者手動釋放資源。能夠選擇適用于 MPI 的調度策略。在進行并行模擬計算之前感知資源狀態，滿足條件后再進行批量調度。

（4）能夠支持多元異構算力。目前分子動力學模擬不單單只運行在 X86 架構的系統上，隨著近幾年 ARM 架構處理器的發展，分子動力學模擬應用也逐漸有了面向諸如鯤鵬、昇騰等處理器的移植優化版本。同時，CPU 和 GPU 異構計算也在分子動力學模擬中應用廣泛。Volcano 可以兼容 ARM 架構進行批量計算系統部署，對 GPU 等多元異構資源也提供了調度和共享機制。

Kubernetes+Volcano 對于 GPU 共享的實現

容器化材料模擬應用進行異構計算時，如果存在 GPU 內存占用量較低的問題，很容易造成資源浪費。而 Kubernetes 集群默認會將節點上的 GPU 設備暴露在該節點的所有 Pod 中，多個 Pod 對 GPU 資源的使用將沒有限制，容易造成 GPU 內存溢出異常（Out Of Memory Error）。 Volcano 能夠提供對 GPU 資源的共享功能，使得多個 Pod 合理有序地利用 GPU 資源。其工作流程如圖 5 所示，流程中的主要三個步驟說明如下：

（1）用 volcano.sh/gpu-memory 資源請求創建一個 Pod，該 Pod 攜帶 GPU 共享資源請求。

（2）volcano-scheduler 會根據 kube-apiserver 中的請求信息，為該 Pod 確 定并分配 GPU 資源，并添加相應的調度注釋。

（3）kubelet 監視綁定到其自身的 Pod，并在運行容器之前調用 allocate API 來設置環境變量。環境變量默認為：容器內可見的 GPU 索 引 （ NVIDIA_VISIBLE_DEVICES ） 、 容 器 被 分 配 的 GPU 內 存 容 量 （ VOLCANO_GPU_ALLOCATED ） 、 容 器 內 可 見 的 GPU 內 存 總 量 （VOLCANO_GPU_TOTAL）。

圖5 Volcano GPU Share 工作流程

落地效果

Volcano下經典勢函數材料模擬系統的實現

這里使用AIREBO經典勢函數為例，在 300 K 恒定溫度的集成過程中分別模擬 1000、10000、 100000 原子體系，分別在 1、3、5 個 Pod 并行環境下，不同原子體系的模 擬性能對比如圖 6 所示。

圖6 AIREBO勢函數不同CPU核心下的模擬性能

圖中顯示，在較小的（1000）原子體系模擬過程中， 單個 Pod（共 32 核心）計算效果比較好，模擬性能達到了 744.414 timesteps/s， 而 5 個 Pod（共 160 核心）時的模擬性能為 469.947 timesteps/s，此時增加 Pod 的 數量只會徒增容器間的通信時延，使得性能下降。但是在較大的（100000）原子 體系中，增加 Pod 數量可以使得并行計算效率有明顯的提升，在單個 Pod（共 32 核心）時的模擬性能為 32.485 timesteps/s，而 5 個 Pod（共 160 核心）將模擬性 能提升至 85.989 timesteps/s。

LAMMPS 計算任務的 Pod 的 CPU 資源利用率如圖7所示。當計算作業開始時，MPI 分別啟動 lmp_mpi 可執行程序，從某一時刻各 Pod 的 CPU 利用率 可以看出，在Volcano層面上，角色為Master的Pod的CPU利用率為9332.266%， 角色為 Worker 的 Pod 的 CPU 利用率為 8920.065%和 9447.651%。 結合圖 4-2 中節點的 CPU 利用率表明，Pod 占據了節點 36 個核心中的 32 核 心，當 Pod 的 CPU 占用達到節點 32 核心的 90%左右時，節點的 CPU 利用率將 會在 80%左右，說明 Volcano 調度結果符合預期。

圖7 Pod CPU利用率監控

Volcano下深度勢函數材料模擬系統的實現

深度勢能（Deep Potential，DP）通過神經網絡生成的深度勢函數（DP勢函數）相對于DFT密度泛函能夠處理更大的體系，時間成本更低，并且與現有的經典力場相比，能夠達到更高的精度。本文將在基于Kubernetes的Volcano容器批處理系統中實現深度勢函數材料模擬環境。深度勢函數訓練和模擬過程需要充分利用 GPU 資源，構建本文提出的深度勢函數材料模擬系統，需要在經典勢函數材料模擬系統基礎上配置 Volcano 的 GPU 共享功能，主要構建流程如下：

（1）修改 Docker 配置文件，將 NVIDIA Docker 作為容器運行時配置，用以 在容器中調用 GPU 設備。

（2）配置Volcano的GPU共享功能，首先需要在volcano-scheduler-configmap 配置文件中加入 predicate.GPUSharingEnable 參數，并將其值配置為 true，其次部 署 volcano-device-plugin 插件。

（3）在指定任務相關資源細節方面，追加 Pod 請求的 GPU 資源量（GPU 塊數和 GPU 內存容量）。

這里先以能夠使用GPU加速的經典勢函數Tersoff 為例，對某材料進行 GPU 加速 LAMMPS 模擬時，分別在 2 個節點中進行 1000 原子體系的模擬，此時每個節點只能調度 1 個 Pod，否則會引發 GPU 內存溢出錯誤。使用 Volcano 的 GPU 共享功能，可以在每個節點上調度 2 個 Pod，將每個 Pod 請求 GPU 資源容量設定為 16280MiB（1 塊 GPU 設備）。 在 2 個節點 4 塊 GPU 設備的相同硬件資源下，使用 Tersoff 勢函數進行材料模擬，2 個 Pod（不使用 GPU 共享）和 4 個 Pod（使用 GPU 共享）10 分鐘內對于 GPU 的利用率情況如圖 8 和圖 9 所示。

圖8 10分鐘內節點GPU利用率監控

圖9 10分鐘內節點GPU利用率監控

可以看出，不使用 GPU 共享 的 2 個 Pod 對于某個節點 GPU 的利用率只能達到 45%左右（其中 1 塊 GPU 設備始終空閑），使用 GPU 共享的 4 個 Pod 對某個節點的 GPU 利用率均能維持在 80% 左右，這說明 Volcano 使得 Pod 以相應 GPU 資源請求的形式被合理調度， 硬件資源可以得到更加充分地利用。

DP 勢函數主要集中在向量矩陣計算，因此采用 GPU 加速可以達到理想的性能提升。使用 DP 勢函數對某材料進行 GPU 加速 LAMMPS 模擬時，分別在 2 個節點（每個節點 1 個 Pod）中進行 10000 個原子體系負載，發現 Pod 對每個節點的兩塊 GPU 設備使用較充分。因此將每一個 Pod 資源請求設定為 GPU 內存占用量 32560MiB（兩塊 GPU 設備）。在 DP 勢函數的 GPU 加速 LAMMPS 模擬中，對單個節點的兩塊 GPU 設備利用率在 1 小時內進行監控，DP 勢函數的記錄如圖 10 所示。

圖10 1小時內GPU利用率監控（使用GPU共享）

在這段時間內，該節點的兩塊 GPU 設備利用率均穩定在 93%左右，可以看出在 Volcano 的調度下，可以使得 Pod 能夠充分地調用 GPU 資源進行 LAMMPS 模擬加速。

計劃與展望

本文通過利用批量容器調度器，使得容器批量調度器能夠極大地促進材料模擬和深度學習兩種計算場景的結合。雖然本文的案例在材料模擬領域比較典型，但是在例如智能醫療、藥物設計、高能物理、大氣模擬、天文學數據處理等其他領域，此解決方案的適用性還有待研究，如果將各個領域中的典型應用都納入到此解決方案中進行批量容器計算，將會使得容器技術與高性能計算和人工智能進一步融合。另外本文結束后將會繼續模擬更大的體系，以及擴大計算資源的規模，深入到大型超算系統的應用場景中。

【與云原生的故事】有獎征文火熱進行中：https://bbs.huaweicloud.com/blogs/345260

云原生 云端實踐

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。