選擇語言

PUNCH4NFDI 聯邦式異質計算與儲存基礎架構

針對 Compute4PUNCH 與 Storage4PUNCH 概念之分析,旨在整合德國各研究機構中多樣化的高效能計算、高吞吐量計算及儲存資源。
computepowertoken.com | PDF Size: 0.5 MB
評分: 4.5/5
您的評分
您已經為此文檔評過分
PDF文檔封面 - PUNCH4NFDI 聯邦式異質計算與儲存基礎架構

1. 簡介

「國家研究資料基礎建設之粒子、宇宙、原子核與強子研究聯盟」(Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure, PUNCH4NFDI)是由德國研究基金會(DFG)資助的一個重要德國聯盟。它代表了來自粒子物理、天體物理、天體粒子物理、強子物理與核物理領域約 9,000 名科學家。該聯盟的主要目標是建立一個聯邦式、符合 FAIR(可發現、可存取、可互通、可重用)原則的科學資料平台。此平台旨在為分散於各參與機構的多樣化、異質性計算與儲存資源提供無縫存取,以應對海量資料與複雜、資源密集型演算法的共同挑戰。本文件聚焦於為整合這些實物貢獻資源而開發的架構概念——Compute4PUNCH 與 Storage4PUNCH。

2. 聯邦式異質計算基礎架構 – Compute4PUNCH

Compute4PUNCH 概念旨在應對提供統一存取由各機構貢獻的眾多現有高吞吐量計算(HTC)、高效能計算(HPC)與雲端資源的挑戰。這些資源在架構、作業系統、軟體與認證機制上各不相同。關鍵限制在於需最小化對現有、由多個社群共享的運作系統之變更。

2.1 核心架構與整合策略

此策略採用聯邦式覆蓋批次系統。並非修改本地資源管理器(如 SLURM、PBS),而是建立一個基於 HTCondor 的覆蓋池。COBalD/TARDIS 資源元排程器動態且透明地將異質後端(HPC 叢集、HTC 農場、雲端虛擬機器)整合到此統一池中。它扮演「先導」系統的角色,提交佔位工作以取得資源,然後部署實際的使用者工作負載。

2.2 使用者存取與軟體環境

存取是透過傳統登入節點與 JupyterHub 服務提供,作為中央入口點。基於權杖的認證與授權基礎設施(AAI)標準化了存取方式。軟體環境的複雜性透過容器技術(Docker、Singularity/Apptainer)與歐洲核子研究組織虛擬機器檔案系統(CVMFS)來管理,後者以可擴展、唯讀的方式交付預先配置、特定社群專用的軟體堆疊。

3. 聯邦式儲存基礎架構 – Storage4PUNCH

Storage4PUNCH 旨在整合由社群提供的儲存系統,這些系統主要基於在高能物理(HEP)領域已相當成熟的 dCache 或 XRootD 技術。此聯邦建立了一個共用的命名空間與存取層。此概念亦評估了現有的快取(以降低延遲與廣域網路流量)與中繼資料處理技術,目標是進行更深度的整合,以促進跨聯邦儲存的資料探索與管理。

4. 技術實作與核心元件

4.1 計算聯邦:HTCondor 與 COBalD/TARDIS

HTCondor: 在聯邦池內提供工作管理層、佇列與排程功能。其 ClassAd 機制允許將複雜的工作需求與動態資源屬性進行匹配。
COBalD/TARDIS: 位於 HTCondor 與異質後端之間。TARDIS 將 HTCondor 的「先導」工作轉譯為後端特定的提交指令(例如,一個 SLURM 工作腳本)。COBalD 則根據策略、成本與佇列狀態,實作決定何時、何處產生這些先導工作的邏輯。其核心功能可建模為一個最佳化問題:$\text{Maximize } U = \sum_{r \in R} (w_r \cdot u_r(\text{alloc}_r)) \text{ subject to } \text{alloc}_r \leq \text{cap}_r, \forall r \in R$,其中 $U$ 是總效用,$R$ 是資源類型集合,$w_r$ 是權重,$u_r$ 是資源類型 $r$ 的效用函數,$\text{alloc}_r$ 是已分配的容量,$\text{cap}_r$ 是總容量。

4.2 儲存聯邦:dCache 與 XRootD

dCache: 一個階層式儲存管理系統,常被用作磁帶歸檔的前端。它提供類 POSIX 介面(NFS、WebDAV)與 HEP 特定協定(xrootd、gridftp)。
XRootD: 一個用於可擴展、容錯資料存取的協定與套件。其「重定向器」元件使得能夠建立聯邦,將客戶端查詢導向適當的資料伺服器。
聯邦建立了一個邏輯層,將多個實體實例呈現為單一系統,這對於資料位置感知排程至關重要。

4.3 軟體與資料交付:容器與 CVMFS

容器: 確保在不同主機系統間具有可重現的軟體環境。它們封裝了複雜的相依性(例如,特定版本的 ROOT、Geant4)。
CVMFS: 一個用於軟體分發的全球分散式檔案系統。它使用 HTTP 與積極的快取機制。其內容發布一次後即可在各處使用,從大規模上解決了軟體部署問題。發布過程涉及「階層 0」伺服器以及複製到「階層 1」鏡像站。

5. 原型狀態與初步經驗

本文報告指出,Compute4PUNCH 與 Storage4PUNCH 的原型皆已部署。初步的科學應用程式已在可用的原型上成功執行,證明了這些概念的可行性。摘要中未提供具體的效能指標或詳細的個案研究,但成功的執行驗證了整合方法與所選技術堆疊。

6. 關鍵洞察與策略分析

  • 聯邦優先於深度整合: 本專案優先採用對現有系統進行輕量級聯邦化,而非進行深度、破壞性的整合,這對於擁有強大且獨立合作夥伴的聯盟而言,是一個務實的選擇。
  • 善用 HEP 傳統技術: 高度依賴經過實戰考驗的 HEP 技術(HTCondor、dCache、XRootD、CVMFS)降低了風險並加速了開發。
  • 抽象化是關鍵: 成功取決於多個抽象層:COBalD/TARDIS 抽象化計算資源,儲存聯邦抽象化資料位置,容器/CVMFS 抽象化軟體環境。
  • 以使用者為中心的存取: 提供熟悉的入口點(JupyterHub、登入節點)降低了多元使用者社群的採用門檻。

7. 原創分析:核心洞察、邏輯流程、優勢與缺陷、可行建議

核心洞察: PUNCH4NFDI 並非在建造一台新的超級電腦;它是在協調一場由現有、各異「樂器」組成的交響樂。其真正的創新在於元層——由 COBalD/TARDIS 與聯邦協定組成的「樂團指揮」——它創造了一個統一的資源池,卻不要求底層提供者同質化。這對於政治結構複雜、多機構合作的環境是一項策略上的高明之舉,讓人聯想到人工智慧中的聯邦學習範式(例如 Google 在聯邦平均法上的工作),其中資料保持分散,但模型被匯總。

邏輯流程: 此架構遵循清晰的關注點分離。1) 存取與身份: 基於權杖的 AAI 對使用者進行認證。2) 計算抽象化: 使用者提交工作至 HTCondor。COBalD/TARDIS 監控佇列,決定哪個後端(例如,某大學的 HPC 叢集)有容量,並部署一個先導工作以「取得」這些資源供 HTCondor 池使用。實際的使用者工作隨後在此先導工作中執行。3) 軟體環境: 工作透過 CVMFS 或從容器登錄檔拉取其特定的軟體堆疊。4) 資料存取: 工作透過聯邦儲存層(dCache/XRootD)讀寫資料,該層會將請求重定向到實際的資料位置。

優勢與缺陷: 其優勢是無可否認的務實主義。透過包裝現有系統,它實現了快速部署並獲得了資源所有者的支持。使用經過 HEP 驗證的技術堆疊(由 CERN 的全球 LHC 計算網格的成功所驗證)是一個主要的風險緩解因素。然而,缺陷在於元排程層固有的複雜性。COBalD/TARDIS 必須在具有不同策略、成本(例如,雲端點數)與效能特性的異質系統間做出智慧的資源配置決策。一個調校不佳的策略可能導致資源利用率低下或工作飢餓。此外,雖然儲存聯邦提供了統一的存取,但諸如全域命名空間索引、中繼資料目錄聯邦以及智慧資料放置(類似於 Lustre 平行檔案系統中的概念或自動資料分層的研究)等高級資料管理功能,似乎是未來評估項目,代表了當前的限制。

可行建議: 對於其他聯盟(例如,在生物資訊學或氣候科學領域),關鍵啟示是從第一天起就應大力投資於元排程器與抽象層的設計。PUNCH 的方法建議從使用像 HTCondor 這樣的穩定技術建立最小可行聯邦開始,而非嘗試從零開始建造。應以清晰、最小化的類 API 要求(例如,「必須支援 SSH 或特定的批次系統指令」)來與資源提供者合作。至關重要的是,專案必須為聯邦層本身開發健全的監控與稽核工具——理解跨站點利用率並診斷此複雜鏈中的故障將是運維的首要任務。未來的發展藍圖應明確解決與工作流程管理器(如 Nextflow 或 Apache Airflow)的整合,以及開發所評估的快取與中繼資料服務,以從簡單的聯邦邁向智慧化、效能最佳化的資料物流。

8. 技術細節與數學框架

COBalD/TARDIS 處理的資源分配問題可被框架為一個線上最佳化問題。令 $Q(t)$ 為時間 $t$ 時 HTCondor 中待處理工作的佇列,每個工作具有預估執行時間 $\hat{r}_i$ 與資源請求向量 $\vec{c}_i$(CPU、記憶體、GPU)。令 $B$ 為後端集合,每個後端具有時變可用容量 $\vec{C}_b(t)$ 以及一個為資源 $\vec{c}$ 分配時長 $\Delta t$ 的成本函數 $f_b(\vec{c}, \Delta t)$。元排程器的目標是在尊重後端策略與預算限制下,最小化平均工作週轉時間 $T_{ta}$。一個用於在後端 $b$ 上產生先導工作的簡化啟發式決策規則可以是:$\text{Spawn if } \frac{|\{j \in Q(t): \vec{c}_j \preceq \vec{C}_b(t)\}|}{\text{Cost}_b} > \theta$,其中 $\preceq$ 表示「符合於」,$\text{Cost}_b$ 是標準化成本,$\theta$ 是閾值。這捕捉了佇列需求與資源配置成本之間的權衡。

9. 實驗結果與原型指標

雖然提供的 PDF 摘要未包含具體的量化結果,但一個成功的原型意味著關鍵的質性與潛在的量化成果:

  • 功能性成功: 展示了透過 HTCondor/JupyterHub 提交單一工作,並使其在遠端 HPC 或 HTC 資源上透明執行、使用來自 CVMFS 的軟體以及來自聯邦儲存的資料之能力。
  • 需追蹤的關鍵指標(未來):
    • 工作成功率: 在整個聯邦中成功完成的工作百分比。
    • 平均等待時間: 從提交到開始的時間,與原生後端佇列相比。
    • 資源利用率: 在聯邦池中交付的總 CPU 時數。
    • 資料傳輸效率: 工作透過聯邦層存取遠端儲存時的吞吐量與延遲。
  • 圖表描述: 一個概念性架構圖將顯示:使用者JupyterHub/登入節點 互動。這些連接到一個中央的 HTCondor 中央管理器COBalD/TARDIS 元件與 HTCondor 及多個 資源後端(HPC 叢集 A、HTC 農場 B、雲端 C)互動。每個後端都有一個本地批次系統(SLURM、PBS 等)。箭頭表示工作提交與先導部署。一個獨立部分顯示 聯邦儲存(dCache、XRootD 實例)連接到後端並可供工作存取。CVMFS 階層 1 鏡像站顯示為所有後端均可存取的一層。

10. 分析框架:概念性工作流程範例

情境: 一位天體粒子物理學家需要使用一個複雜、客製化的分析流程(基於 Python/ROOT)處理 1,000 張望遠鏡影像。

  1. 使用者入口: 研究人員登入 PUNCH JupyterHub。
  2. 環境設定: 在 Jupyter 筆記本中,他們選擇一個由 Singularity 容器支援的預定義核心,該容器包含其特定的軟體堆疊(已發布至 CVMFS)。
  3. 工作定義: 他們撰寫一個定義分析任務的腳本,並使用 PUNCH 輔助函式庫建立一個 HTCondor 提交描述,指定所需的 CPU、記憶體與輸入資料參考(例如,`root://fed-storage.punch.org/path/to/images_*.fits`)。
  4. 提交與排程: 工作被提交至 HTCondor 池。COBalD/TARDIS 看到 1,000 個短期工作,決定在一個具有快速本地儲存快取(用於輸入資料)的高吞吐量農場(後端 B)上產生多個先導工作。
  5. 執行: 先導工作在後端 B 上取得位置。每個先導工作拉取容器,透過 XRootD 聯邦(可能重定向到本地快取)獲取其分配的輸入檔案,執行分析,並將結果寫回聯邦儲存。
  6. 完成: HTCondor 匯總工作完成狀態。研究人員的筆記本現在可以從輸出儲存位置查詢並視覺化結果。

此範例突顯了完整的抽象化:使用者完全不需要知道後端 B 上的 SLURM 指令、如何在那裡安裝 ROOT,或資料檔案的實體位置。

11. 未來應用與發展藍圖

PUNCH4NFDI 基礎架構為變革性應用奠定了基礎:

  • 多信使天文物理工作流程: 在重力波(LIGO/Virgo)、微中子(IceCube)與電磁波觀測資料之間進行即時關聯分析,需要跨地理分散資源的緊急計算。
  • 大規模 AI/ML 模型訓練: 聯邦學習實驗,其中訓練過程本身分散在計算聯邦中,模型則集中匯總——這是與資料聯邦平行的計算聯邦。
  • 複雜實驗的數位孿生: 執行大規模模擬集合,以建立粒子偵測器或望遠鏡陣列的數位對應物,利用 HPC 進行模擬,並利用 HTC 進行參數掃描。

發展藍圖:

  1. 短期(1-2 年): 鞏固 Compute4PUNCH 與 Storage4PUNCH 核心服務的生產級部署。整合進階監控(Prometheus/Grafana)與計費/核算工具。
  2. 中期(3-4 年): 實作並整合所評估的快取與全域中繼資料目錄服務。開發與工作流程管理系統更緊密的整合。探索在需求高峰期間「爆發」至商業雲端。
  3. 長期(5 年以上): 朝著 PUNCH 科學的「智慧資料湖屋」演進,納入資料探索、溯源追蹤以及由聯邦中繼資料驅動的自動化資料生命週期管理。作為其他 NFDI 聯盟與國際合作的藍圖。

12. 參考文獻

  1. PUNCH4NFDI Consortium. (2024). PUNCH4NFDI White Paper. [Official Consortium Documentation].
  2. Thain, D., Tannenbaum, T., & Livny, M. (2005). Distributed computing in practice: the Condor experience. Concurrency and Computation: Practice and Experience, 17(2-4), 323-356. https://doi.org/10.1002/cpe.938
  3. Krebs, K., et al. (2022). COBalD/TARDIS – A dynamic resource provisioning framework for heterogeneous computing environments. Journal of Physics: Conference Series, 2438(1), 012045. (Reference for the meta-scheduler).
  4. Blomer, J., et al. (2011). The CernVM File System. Journal of Physics: Conference Series, 331(5), 052004. https://doi.org/10.1088/1742-6596/331/5/052004
  5. dCache Collaboration. (2023). dCache.org [Software and Documentation]. https://www.dcache.org
  6. XRootD Collaboration. (2023). XRootD Documentation. http://xrootd.org/docs.html
  7. McMahan, B., Moore, E., Ramage, D., Hampson, S., & y Arcas, B. A. (2017). Communication-Efficient Learning of Deep Networks from Decentralized Data. Proceedings of the 20th International Conference on Artificial Intelligence and Statistics (AISTATS). (Cited for federated learning analogy).
  8. European Organization for Nuclear Research (CERN). (2023). Worldwide LHC Computing Grid (WLCG). https://wlcg.web.cern.ch (Cited as precedent for large-scale federation).