選擇語言

Compute4PUNCH 與 Storage4PUNCH:粒子、天文與核物理學的聯邦式基礎設施

分析 PUNCH4NFDI 聯盟的聯邦式運算與儲存基礎設施概念,整合德國境內異質性的高效能運算、高吞吐量運算與雲端資源。
computepowertoken.com | PDF Size: 0.5 MB
評分: 4.5/5
您的評分
您已經為此文檔評過分
PDF文檔封面 - Compute4PUNCH 與 Storage4PUNCH:粒子、天文與核物理學的聯邦式基礎設施

1. 簡介

由德國研究基金會(DFG)資助的 PUNCH4NFDI(國家研究資料基礎設施之粒子、宇宙、原子核與強子)聯盟,代表了德國約 9,000 名來自粒子物理、天體物理、天體粒子物理、強子物理與核物理領域的科學家。該聯盟隸屬於國家 NFDI 倡議,其主要目標是建立一個聯邦式且符合 FAIR(可查找、可存取、可互通、可重用)原則的科學資料平台。此平台旨在無縫存取其成員機構貢獻的多樣化、異質性運算與儲存資源,以應對使用複雜演算法分析指數級增長資料量的共同挑戰。本文件聚焦於 Compute4PUNCHStorage4PUNCH 的技術概念,它們構成了此聯邦式基礎設施的骨幹。

2. 聯邦式異質運算基礎設施 – Compute4PUNCH

Compute4PUNCH 旨在解決有效利用分散於德國各地、由各方實物貢獻的高吞吐量運算(HTC)、高效能運算(HPC)與雲端資源的挑戰。這些資源在架構、作業系統、軟體堆疊與認證機制上各不相同。

2.1. 核心架構與覆蓋系統

Compute4PUNCH 的基石是基於 HTCondor 建立一個聯邦式覆蓋批次系統。其關鍵創新在於使用 COBalD/TARDIS 資源元排程器。TARDIS(TARDIS 作為就地排程的資源分派器)能動態且透明地將外部異質資源整合到 HTCondor 資源池中。它扮演「先導」系統的角色,向外部叢集(例如基於 Slurm 的 HPC 系統)提交佔位符工作,這些佔位符工作隨後會從中央 HTCondor 佇列中提取並執行實際的使用者工作。這種方法最大限度地減少了對資源提供者現有運作設定的侵入,這是採用的關鍵要求。

資源匹配與排程邏輯可以抽象地用一個最佳化函數表示。令 $R = \{r_1, r_2, ..., r_n\}$ 為可用異質資源的集合,每個資源具有架構 $arch(r_i)$、可用核心數 $c(r_i)$、記憶體 $m(r_i)$ 和佇列等待時間 $w(r_i)$ 等屬性。令 $J = \{j_1, j_2, ..., j_m\}$ 為使用者工作的集合,每個工作有需求 $req(j_k)$。元排程器的目標是找到一個映射 $M: J \rightarrow R$,以最大化一個目標函數 $F$,該函數通常是效率與公平性的加權和:

$F(M) = \alpha \cdot \sum_{j_k} U(j_k, M(j_k)) - \beta \cdot \sum_{r_i} L(r_i, M^{-1}(r_i))$

其中 $U$ 是一個效用函數,衡量資源滿足工作需求的程度(考慮透過 CVMFS 的軟體環境相容性),而 $L$ 是一個負載函數,懲罰對任何單一資源的過度訂閱。COBalD/TARDIS 以啟發式方法解決這個動態、即時的排程問題。

2.2. 存取與軟體環境

使用者存取透過基於權杖的認證與授權基礎設施(AAI)進行標準化。主要的入口點是傳統的登入節點和 JupyterHub 服務,為互動式分析與原型設計提供熟悉的網頁介面。

為處理多樣的軟體相依性,此基礎設施利用容器技術(例如 Docker、Singularity/Apptainer)和 CERN 虛擬機器檔案系統(CVMFS)。CVMFS 為軟體安裝提供了一個可擴展、唯讀且全球分佈的命名空間。特定領域的軟體堆疊被發佈到 CVMFS 儲存庫,確保任何運算節點,無論其實體位置為何,都能即時且一致地存取所需的軟體環境,從而消除了本地安裝的負擔。

3. 聯邦式儲存基礎設施 – Storage4PUNCH

Storage4PUNCH 專注於聯邦化由社群提供的儲存系統,這些系統主要基於 dCacheXRootD 技術,兩者在高能物理(HEP)領域都已相當成熟。

3.1. 聯邦化與快取策略

聯邦化創造了一個統一的命名空間,允許使用者存取跨越多個機構儲存元件的資料,彷彿它們是一個單一系統。為實現此目標,採用了如 XRootD 的聯邦協定dCache 的前端池化等技術。系統執行智慧的資料定位與路由。

正在評估的一個關鍵元件是 快取。一個全域或區域性的快取層可以顯著降低頻繁存取資料集的延遲與廣域網路負載。一個大小為 $S$ 的快取對於某種資料存取模式的命中率 $H$ 可以建模。如果存取資料項目 $d_i$ 的機率遵循類似 Zipf 的分佈 $P(i) \sim 1 / i^{\alpha}$,則 LRU 快取的預期命中率約為:

$H(S) \approx \sum_{i=1}^{S} P(i)$

其中 $\alpha$ 是偏斜參數。對於具有高資料重用性的科學工作流程(在分析鏈中很常見),即使是中等大小的快取也能產生高 $H$ 值,證明了其部署的合理性。該專案也正在評估用於更深層整合的中繼資料處理解決方案,目標不僅是提供檔案存取,還要在整個聯邦範圍內提供資料發現能力。

4. 技術細節與數學框架

聯邦系統的效能取決於高效的資源發現與排程。系統狀態可以建模為一個圖 $G=(V,E)$,其中頂點 $V$ 代表資源(運算節點、儲存端點),邊 $E$ 代表具有頻寬 $bw(e)$ 和延遲 $lat(e)$ 的網路連結。一個工作流程 $W$ 是具有資料相依性 $D$ 的任務 $T$ 的有向無環圖(DAG)。

排程問題變為:將每個任務 $t \in T$ 放置在一個運算資源 $r_c \in V_c$ 上,並將其所需的輸入資料從儲存資源 $r_s \in V_s$ 路由過來,以最小化總完工時間(工作流程完成時間),並滿足以下約束條件:

$\text{minimize } \max_{t \in T} (ft(t))$
受制於:
$\forall r \in V_c, \sum_{t placed\ on\ r} c(t) \leq C(r)$ (CPU 容量)
$\forall d \in D, \text{transfer\_time}(d) = \frac{size(d)}{\min\_bw(path)} + \sum_{e \in path} lat(e)$

其中 $ft(t)$ 是任務 $t$ 的完成時間,$c(t)$ 是其 CPU 需求,$C(r)$ 是資源 $r$ 的容量。聯邦系統使用 HTCondor 和 COBalD/TARDIS 內的啟發式演算法,來即時逼近這個 NP 難題的解。

5. 實驗結果與原型效能

本文報告了運作中原型機的初步經驗。雖然提供的摘錄中未詳細說明具體的量化基準測試,但文本暗示了科學應用程式在聯邦基礎設施上的成功執行。

圖表說明(推測的效能指標): 一個假設的效能圖表可能會顯示隨時間變化的兩個關鍵指標:1) 聯邦資源池的總體資源利用率,展示覆蓋系統如何有效填補不同貢獻中心之間的容量缺口。2) 工作週轉時間,比較聯邦情境與孤立資源使用的情境。聯邦系統將顯示出較低的平均週轉時間和變異數,特別是對於資源需求靈活的工作,因為它們可以被路由到佇列最短的資源。透過 TARDIS 整合 HPC 資源將顯示一條獨特的曲線,最初由於先導工作機制而增加延遲,但為合適的工作負載提供了存取原本無法使用的高核心數節點的途徑。

據報告,CVMFS 的使用成功地提供了統一的軟體環境,這是使用者採用的關鍵成功因素。基於權杖的 AAI 已實施,為安全、跨機構的存取提供了必要的基礎。

6. 分析框架:概念性案例研究

案例:多信使天文物理分析。 一位天體粒子物理學家需要分析來自 Fermi-LAT 和 IceCube 探測到的伽瑪射線暴(GRB)資料,並將其與 ASAS-SN 的光學後續觀測相關聯。工作流程涉及:A) 在針對高 I/O 優化的 HTC 農場上處理太位元組級的原始光子資料(Fermi)。B) 在具有多核心的 HPC 叢集上執行用於微中子事件重建的蒙地卡羅模擬(IceCube)。C) 使用 GPU 節點對光學資料進行影像分析。

透過 Compute4PUNCH/Storage4PUNCH 的聯邦執行:
1. 使用者透過 JupyterHub 提交單一的高階工作流程描述(例如使用通用工作流程語言 - CWL)。
2. AAI 權杖在所有系統中驗證使用者身份。
3. HTCondor 覆蓋層在 COBalD/TARDIS 的引導下,分析工作流程 DAG:
- 任務 A 被匹配並分派到 DESY 靠近 dCache 儲存的 HTC 工作節點。
- 任務 B 對 10,000 CPU 小時的需求觸發 TARDIS 在 KIT 的基於 Slurm 的 HPC 叢集上配置運算槽。
- 任務 C 被送到波昂大學的 GPU 分區。
4. 所有任務從 PUNCH CVMFS 儲存庫提取相同的分析軟體堆疊(Python、特定科學函式庫)。
5. 中間資料透過聯邦的 Storage4PUNCH 命名空間(例如使用 XRootD)交換,頻繁存取的校正檔案則由區域快取提供。
6. 最終結果被彙總並返回給使用者。

此案例展示了其價值主張:物理學家只需與單一、邏輯上的基礎設施互動,而無需管理跨三個不同系統的獨立登入、軟體安裝和資料傳輸。

7. 核心洞見與分析師觀點

核心洞見: PUNCH4NFDI 並非在建造另一台單體式超級電腦;它是在設計一個 聯邦層——一個適用於國家級、異質性研究運算的「元作業系統」。其真正的創新在於務實地將現有的、政治上孤立的資源協調成一個連貫的公用設施,優先考慮最小侵入性而非技術純粹性。這與其說像 Google 的 Borg,不如說更像一個為運算工作設計的、複雜的歐盟範圍空中交通管制系統。

邏輯流程: 其邏輯優雅地遞迴。從不可協商的約束開始:不干擾現有的社群運作。這迫使採用基於提取的覆蓋架構(HTCondor + TARDIS),而非基於推送的集中式排程器。而該覆蓋層反過來又需要一個通用的軟體交付機制(CVMFS/容器)和一個統一的身分層(權杖 AAI)。儲存聯邦遵循一條平行的軌道,利用久經考驗的 HEP 工具(dCache/XRootD)。整個流程是約束驅動設計的典範,其中每個技術選擇都是多機構合作的社會政治現實的直接結果。

優勢與缺陷:
優勢: 此架構在設計上巧妙地具有 可聯邦化 的特性。它水平擴展治理,降低了新資源提供者的門檻。使用 HTCondor 和 CVMFS 利用了來自 LHC 合作計畫數十年的社群信任與運營專業知識,降低了技術風險。對「實物」資源的關注具有財務可持續性,將碎片化問題轉化為多樣性優勢。
缺陷: 顯而易見的問題是 效能開銷。雙重排程(元排程器 + 本地批次系統)和先導工作模型不可避免地增加了延遲,使其不適用於細粒度、緊密耦合的 MPI 工作——這對純 HPC 工作負載是一個重大限制。對 CVMFS 的依賴雖然穩健,但為軟體交付創造了一個單點故障,並且可能難以處理高度專有或需授權的程式碼。此外,正如 FAIR 資料原則 中所指出的,真正的互通性需要豐富的中繼資料;目前 Storage4PUNCH 的描述似乎過於專注於位元組層級的存取,而非語義發現。

可行建議:
1. 對於 PUNCH 團隊: 加倍努力進行效能表徵。針對典型工作流程,發佈比較聯邦式與原生工作吞吐量及延遲的透明基準測試。這些資料對於說服持懷疑態度的 HPC 中心管理者和使用者至關重要。主動為聯邦層本身建立一個「第一級」支援模式;其複雜性已成為關鍵的依賴項。
2. 對於其他聯盟(例如生物資訊學或氣候科學領域): 不要只複製技術堆疊。複製使其成為可能的 治理模式。關鍵教訓是「實物貢獻」協議,它調整了機構的激勵機制。像 PUNCH 所做的那樣,從聯邦化認證和軟體分發開始;這些是基礎。
3. 對於資助機構(DFG、歐盟): 此模式應成為未來國家研究基礎設施徵求計畫的藍圖。資助「黏合劑」(協調、聯邦層的核心開發維運),讓機構資助「磚塊」(實際的運算/儲存)。這比建造新的集中式設施更能有效利用現有的資本投資,這一原則與歐洲開放科學雲(EOSC)的戰略願景相呼應。

總而言之,Compute4PUNCH 和 Storage4PUNCH 代表了一個成熟、務實且高度可複製的 21 世紀大規模科學基礎設施模型。它犧牲了一些理論效能,換取了在可存取性、韌性和政治可行性方面的巨大收益。其成功將不是以 FLOPS 來衡量,而是以有多少博士生能夠完成他們的分析,而無需成為五個不同叢集的專家系統管理員來衡量。

8. 未來應用與發展藍圖

PUNCH4NFDI 基礎設施為幾項未來的進展奠定了基礎:

  • 與機器學習工作流程整合: 聯邦系統可以擴展以支援專業的 AI/ML 加速器(例如 NVIDIA DGX pod、Google TPU)作為一種資源類型。像 Kubeflow 這樣的框架可以與 HTCondor 並行整合,由 TARDIS 管理跨傳統 HTC 和專注於 ML 的資源的混合工作安置。
  • 主動式資料放置與工作流程感知排程: 超越快取,系統可以實施預測性資料預備。透過分析使用者提交的工作流程 DAG,它可以在工作執行開始之前,將所需的資料集從遠端 Storage4PUNCH 端點預先提取到排定運算資源附近的本地快取中,從而有效隱藏資料傳輸延遲。這需要運算元排程器與儲存聯邦的命名空間及監控資料之間更緊密的整合。
  • 擴展至邊緣運算: 對於像無線電天文學或微中子物理這樣感測器產生巨量資料流的領域,聯邦模型可以納入邊緣運算站點。輕量級的 TARDIS 代理程式可以在天文台運行,從中央佇列提取預處理任務,在現場過濾和減少資料,然後僅將相關事件傳輸到中央儲存。
  • 綠色運算與碳感知排程: 元排程器可以增強來自德國各地電網的碳強度資料。然後,它可以優先將工作路由到可再生能源滲透率高(例如北部的風力發電)且處於發電高峰時期的地區的資料中心,從而最小化大規模運算的碳足跡——這是研究基礎設施的新興優先事項,正如 Linux 基金會的 Carbon Call 倡議所強調的。
  • 與國際合作夥伴的跨聯邦互連: 邏輯上的下一步是將德國的 PUNCH 聯邦與國外的類似基礎設施連接起來,例如全球 LHC 計算網格(WLCG)、開放科學網格(OSG)或歐洲開放科學雲(EOSC)。這將創造一個全球性、多學科的研究基礎設施,儘管這將在政策協調、安全性和核算方面帶來重大挑戰。

9. 參考文獻

  1. PUNCH4NFDI Consortium. "PUNCH4NFDI - Particles, Universe, NuClei and Hadrons for the NFDI." White Paper, 2021.
  2. Thain, D., Tannenbaum, T., & Livny, M. "Distributed computing in practice: the Condor experience." Concurrency - Practice and Experience, 17(2-4), 323-356, 2005. https://doi.org/10.1002/cpe.938
  3. Blomer, J., et al. "CernVM-FS: delivering scientific software to globally distributed computing resources." International Journal of High Performance Computing Applications, 28(2), 158-174, 2014. https://doi.org/10.1177/1094342013509700
  4. Giffels, M., et al. "COBalD/TARDIS – Dynamic, Pilot-based Resource Provisioning for a Federated HTCondor Pool." In Proceedings of CHEP 2018, 2018.
  5. Wilkinson, M. D., et al. "The FAIR Guiding Principles for scientific data management and stewardship." Scientific Data, 3:160018, 2016. https://doi.org/10.1038/sdata.2016.18
  6. European Commission. "European Open Science Cloud (EOSC) Strategic Implementation Roadmap." 2018.
  7. Linux Foundation. "Carbon Call: A Global Initiative for Reliable Carbon Accounting." 2022. https://www.linuxfoundation.org/research/carbon-call
  8. Zhu, J.-Y., Park, T., Isola, P., & Efros, A. A. "Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks." In Proceedings of the IEEE International Conference on Computer Vision (ICCV), 2017. (引用作為一個可受益於聯邦式、異質資源存取的複雜計算工作負載範例)。