PUNCH4NFDI 嘅聯邦異構計算同儲存基礎設施

1. 簡介

PUNCH4NFDI（國家研究數據基礎設施嘅粒子、宇宙、原子核同強子領域）係一個由德國研究協會（DFG）資助嘅主要德國聯盟。佢代表咗大約 9,000 名來自粒子物理、天體物理、天體粒子物理、強子物理同核物理界別嘅科學家。聯盟嘅首要目標係建立一個聯邦式、符合 FAIR（可搵到、可存取、可互通、可重用）原則嘅科學數據平台。呢份貢獻詳細闡述咗 Compute4PUNCH 同 Storage4PUNCH 呢兩個架構概念，旨在統一存取由德國各地成員機構以實物形式貢獻嘅高度異構計算（HPC、HTC、雲端）同儲存資源。

2. 聯邦異構計算基礎設施 – Compute4PUNCH

Compute4PUNCH 計劃旨在應對一個挑戰：喺唔對資源提供者嘅運作模式作出重大改變嘅前提下，提供無縫存取多元化現有計算資源池嘅能力。

2.1. 核心架構同技術

聯邦系統建基於一個 基於 HTCondor 嘅覆蓋式批次系統。關鍵創新在於使用 COBalD/TARDIS 資源元排程器。TARDIS 充當一個動態代理，將來自 HTCondor 池嘅抽象資源請求，轉譯成對後端系統（例如，喺 OpenStack 上生成虛擬機、向 Slurm 提交作業）嘅具體配置操作。咁樣就創建咗一個 動態且透明嘅整合 層。一個基於令牌嘅身份驗證同授權基礎設施（AAI）提供標準化存取。

2.2. 存取同用戶介面

用戶主要通過兩個入口點同聯邦系統互動：

傳統登入節點： 提供對統一環境嘅 Shell 存取。
JupyterHub： 提供一個基於網頁嘅互動式計算環境，顯著降低數據分析嘅入門門檻。

從呢啲入口點，用戶可以向 HTCondor 池提交作業，然後由 COBalD/TARDIS 喺異構後端之間進行管理。

2.3. 軟件環境管理

為咗處理唔同界別嘅多元化軟件需求，項目採用咗：

容器技術（例如 Docker、Singularity/Apptainer）： 用於封裝應用程式環境。
CERN 虛擬機檔案系統（CVMFS）： 一個唯讀、全球分佈嘅檔案系統，用於以可擴展嘅方式交付軟件堆疊同實驗數據。咁樣就將軟件分發同底層基礎設施解耦。

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

Storage4PUNCH 旨在聯邦化主要基於 dCache 同 XRootD 技術嘅界別儲存系統，呢啲技術喺高能物理（HEP）領域已經好成熟。

3.1. 儲存聯邦策略

策略唔係要創建一個單一嘅龐大儲存系統，而係要聯邦化現有嘅系統。重點係提供一個統一嘅命名空間同存取協議層，以抽象化底層儲存嘅異構性。咁樣可以保留數據嘅局部性，同時實現全球存取。

3.2. 技術堆疊同整合

聯邦系統利用咗：

dCache： 用作儲存後端，同時利用其聯邦能力。
XRootD： 採用其高效嘅數據存取協議同重定向能力，對於構建數據聯邦至關重要。
緩存同元數據技術評估： 項目正積極評估 Rucio（用於數據管理）等技術同緩存層，以優化數據存取模式並實現更智能嘅數據放置，邁向超越簡單聯邦嘅更深層次整合。

4. 技術細節同數學框架

COBalD/TARDIS 中嘅核心排程邏輯可以建模為一個優化問題。設 $R = \{r_1, r_2, ..., r_n\}$ 為來自 HTCondor 池嘅資源請求集合，$B = \{b_1, b_2, ..., b_m\}$ 為可用後端資源類型（例如，HPC 節點、雲端虛擬機）嘅集合。每個請求 $r_i$ 都有其要求（核心數、記憶體、軟件）。每個後端 $b_j$ 都有一個成本函數 $C_j(r_i)$ 同一個配置時間 $T_j(r_i)$。

元排程器嘅目標係搵到一個映射 $M: R \rightarrow B$，以最小化一個總成本函數，通常係財務成本同完成時間嘅加權和，並受後端配額同軟件可用性等約束限制：

$$\min_{M} \sum_{r_i \in R} \left[ \alpha \cdot C_{M(r_i)}(r_i) + \beta \cdot T_{M(r_i)}(r_i) \right]$$

其中 $\alpha$ 同 $\beta$ 係權重因子。呢個形式化咗「動態且透明」嘅整合挑戰。

5. 原型結果同性能

論文報告咗喺可用原型上運行科學應用程式嘅初步經驗。雖然提供嘅摘錄中冇詳細說明具體嘅定量基準測試，但成功執行意味住：

功能整合： HTCondor/COBalD/TARDIS 堆疊成功將作業路由到唔同嘅後端系統（HTC、HPC、雲端）。
軟件交付： CVMFS 同容器可靠地喺異構工作節點上提供咗必要嘅軟件環境。
用戶存取： JupyterHub 同登入節點作為研究人員嘅有效入口點。

概念圖： 系統架構可以視為一個三層模型：

用戶存取層： JupyterHub、登入節點、令牌 AAI。
聯邦同排程層： HTCondor 池 + COBalD/TARDIS 元排程器。
資源層： 異構後端（HPC 叢集、HTC 農場、雲端虛擬機）同聯邦儲存（dCache、XRootD 實例）。

數據同作業從頂層流經智能排程中間層，到達底層嘅適當資源。

6. 分析框架：一個用例場景

場景： 一位核物理研究人員需要處理 10,000 個蒙特卡羅模擬任務，每個任務需要 4 個 CPU 核心、16 GB RAM 同一個特定軟件堆疊（Geant4、ROOT）。

提交： 研究人員登入 PUNCH JupyterHub，編寫分析腳本，並向本地 HTCondor 排程器提交 10,000 個作業。
元排程： COBalD/TARDIS 監控 HTCondor 隊列。佢評估可用後端：大學 A 嘅 HTC 農場（低成本，高隊列時間）、研究所 B 嘅 HPC 叢集（中等成本，專用硬件）同商業雲端（高成本，即時可用性）。
決策同執行： 使用其成本模型，TARDIS 可能會決定將 2,000 個即時作業爆發到雲端以快速啟動，同時穩定地喺更便宜嘅 HTC 農場上處理其餘作業。佢使用令牌 AAI 喺所有系統上進行身份驗證。
軟件同數據： 每個作業，無論喺邊個後端運行，都從 CVMFS 拉取其 Geant4/ROOT 環境。輸入數據從聯邦 Storage4PUNCH 命名空間（例如，通過 XRootD）獲取，輸出則寫返去指定嘅儲存端點。
完成： 研究人員從單一 HTCondor 作業隊列監控同匯總結果，無需理會底層嘅多基礎設施執行。

呢個場景展示咗聯邦基礎設施嘅透明度、效率同以用戶為中心嘅設計。

7. 批判性分析同專家觀點

核心見解： PUNCH4NFDI 唔係要建立另一個雲端；佢係喺設計一個 具有顯著政治同技術實用主義嘅聯邦層。佢真正嘅創新在於 COBalD/TARDIS 元排程器，佢充當資源共享嘅「外交翻譯官」，而唔係一個征服性嘅統一者。呢個做法承認咗現有機構叢集嘅主權——呢個係德國學術界不可協商嘅現實——同時仍然創建咗一個功能性嘅超資源。

邏輯流程： 邏輯無懈可擊：從用戶開始（JupyterHub/登入），通過一個久經考驗嘅排程器（HTCondor）抽象化混亂，然後使用一個智能代理（TARDIS）將抽象請求映射到具體、政治上可行嘅後端。依賴 CVMFS 同容器嚟處理軟件係一個妙招，解決咗困擾大多數聯邦系統嘅「依賴地獄」問題。儲存策略明智地保守，建基於 HEP 領域已驗證嘅 dCache/XRootD 組合，避免咗試圖強推單一新技術嘅泥潭。

優點同缺點：

優點： 最小入侵 係佢嘅超能力。佢唔需要提供者改變其本地政策。使用 成熟、由界別驅動嘅工具（HTCondor、CVMFS、dCache）大大降低咗風險並提高咗可持續性，唔似啲基於定制框架嘅項目。對 FAIR 原則 嘅關注完全符合現代資助要求。
缺點同風險： 元排程器方法引入咗一個 複雜性同潛在故障嘅單點。COBalD/TARDIS 雖然有前景，但唔似其他組件咁久經考驗。對緩存/元數據技術（如 Rucio）嘅「評估」暗示咗 最困難嘅部分仲喺前面：智能數據管理。冇咗佢，呢個只係一個附帶儲存目錄嘅計算聯邦，而唔係一個有凝聚力、以數據為中心嘅平台。對於用戶嚟講，仲存在一個潛在嘅 性能不可預測性 風險，因為佢哋嘅作業會喺根本唔同嘅架構之間跳轉。

可行建議：

對於 PUNCH 架構師： 加倍努力使 TARDIS 更加穩健同可觀察。佢嘅指標同決策日誌對於優化同建立信任係寶貴資源。下一步優先整合數據管理層（如 Rucio）；冇智能數據嘅計算只係半個解決方案。
對於其他聯盟： 呢個係一個值得仿效嘅藍圖，尤其係「整合而非取代」嘅理念。然而，要評估你嘅界別係咪有類似 CVMFS 嘅同等物——如果冇，呢個就係你第一個要決定建造抑或購買嘅嘢。
對於資源提供者： 呢個模式對你哋嚟講風險低。參與其中。基於令牌嘅 AAI 係一種提供存取而又唔損害本地安全性嘅乾淨方式。對於能見度同利用率嚟講，佢係一個淨收益。

項目嘅成功唔係用峰值 FLOPS 嚟衡量，而係用佢幾咁無形地令到陶滕堡嘅一位博士生能夠無縫使用波恩嘅計算週期同卡爾斯魯厄嘅數據嚟衡量。呢個係一個更加雄心勃勃——同有價值——嘅目標。

8. 未來應用同發展路線圖

PUNCH4NFDI 基礎設施為幾個高級應用同研究方向奠定咗基礎：

跨領域工作流程： 實現複雜嘅多步驟分析管道，可以無縫喺模擬（HPC）、高通量事件處理（HTC）同機器學習訓練（雲端 GPU）之間移動。
以數據為中心嘅排程： 將儲存聯邦更深入地同計算排程器整合。未來版本嘅 COBald/TARDIS 可以將數據局部性（最小化廣域網傳輸）同預先準備納入其成本函數，邁向 數據感知排程。
與 FAIR 數據存儲庫整合： 作為國家 FAIR 數據存儲庫嘅高性能計算骨幹，允許研究人員直接喺數據存儲嘅地方分析大型數據集，遵循「計算到數據」嘅範式。
AI/ML 即服務： JupyterHub 介面同可擴展後端可以擴展，加入針對專用 AI/ML 框架（PyTorch、TensorFlow）嘅策展環境同對 GPU 資源嘅存取，為物理科學領域普及 AI。
擴展到國際資源： 聯邦模型可以擴展到包含來自歐洲計劃（如歐洲開放科學雲（EOSC）或 LHC 計算網格（WLCG）站點）嘅資源，創建一個真正嘅泛歐洲研究基礎設施。

路線圖可能涉及強化當前原型、擴展整合資源嘅數量、實施已評估嘅元數據/緩存解決方案，以及為聯盟內公平共享資源使用開發更複雜嘅策略同計費機制。

9. 參考文獻

PUNCH4NFDI Consortium. (2024). PUNCH4NFDI White Paper. [Internal Consortium Document].
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.
Blomer, J., et al. (2011). The CernVM file system. Journal of Physics: Conference Series, 331(5), 052004.
COBalD/TARDIS Documentation. (n.d.). Retrieved from https://tardis.readthedocs.io/
dCache Collaboration. (n.d.). dCache: A distributed storage system. https://www.dcache.org/
XRootD Collaboration. (n.d.). XRootD: High performance, scalable fault tolerant access to data. http://xrootd.org/
Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific data, 3(1), 1-9.
European Open Science Cloud (EOSC). (n.d.). https://eosc-portal.eu/
Worldwide LHC Computing Grid (WLCG). (n.d.). https://wlcg.web.cern.ch/