Compute4PUNCH 同 Storage4PUNCH：粒子、天體同核子物理學嘅聯合基礎設施

1. 簡介

由德國研究基金會（DFG）資助嘅 PUNCH4NFDI（國家研究數據基礎設施嘅粒子、宇宙、原子核同強子）聯盟，代表咗德國粒子物理、天體物理、天體粒子物理、強子物理同核子物理界別大約 9,000 名科學家。作為國家 NFDI 倡議嘅一部分，其主要目標係建立一個聯合且符合 FAIR（可查找、可存取、可互通、可重用）原則嘅科學數據平台。呢個平台旨在無縫存取其成員機構提供嘅多元化同異構運算同儲存資源，以應對使用複雜算法分析指數級增長數據量嘅共同挑戰。本文檔重點介紹 Compute4PUNCH 同 Storage4PUNCH 嘅技術概念，佢哋構成咗呢個聯合基礎設施嘅骨幹。

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 專注於聯合社群提供嘅儲存系統，呢啲系統主要基於 dCache 或 XRootD 技術，兩者喺高能物理（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. 參考文獻

PUNCH4NFDI Consortium. "PUNCH4NFDI - Particles, Universe, NuClei and Hadrons for the NFDI." White Paper, 2021.
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
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
Giffels, M., et al. "COBalD/TARDIS – Dynamic, Pilot-based Resource Provisioning for a Federated HTCondor Pool." In Proceedings of CHEP 2018, 2018.
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
European Commission. "European Open Science Cloud (EOSC) Strategic Implementation Roadmap." 2018.
Linux Foundation. "Carbon Call: A Global Initiative for Reliable Carbon Accounting." 2022. https://www.linuxfoundation.org/research/carbon-call
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. （引用作為一個可以受益於聯合、異構資源存取嘅複雜運算工作負載嘅例子）。