Федеративная гетерогенная вычислительная и хранилищная инфраструктура для PUNCH4NFDI

1. Введение

Консорциум «Частицы, Вселенная, Ядра и Адроны для Национальной исследовательской инфраструктуры данных» (PUNCH4NFDI) — это крупное немецкое объединение, финансируемое Немецким научно-исследовательским сообществом (DFG). Он представляет около 9000 учёных из сообществ физики частиц, астрофизики, астрочастиц, адронной и ядерной физики. Основная цель консорциума — создание федеративной научной платформы данных, соответствующей принципам FAIR (находимость, доступность, совместимость, повторное использование). Эта платформа призвана обеспечить беспрепятственный доступ к разнородным вычислительным ресурсам и ресурсам хранения данных, распределённым по участвующим учреждениям, решая общие проблемы огромных объёмов данных и сложных, ресурсоёмких алгоритмов. В данном документе рассматриваются архитектурные концепции — Compute4PUNCH и Storage4PUNCH, — разработанные для федерации этих ресурсов, предоставленных участниками в натуральной форме.

2. Федеративная гетерогенная вычислительная инфраструктура – Compute4PUNCH

Концепция Compute4PUNCH решает задачу предоставления единого доступа к широкому спектру существующих ресурсов для высокопроизводительных вычислений (HPC), вычислений с высокой пропускной способностью (HTC) и облачных ресурсов, предоставленных различными учреждениями. Эти ресурсы различаются архитектурой, ОС, программным обеспечением и системами аутентификации. Ключевое ограничение — минимизация изменений в существующих, действующих системах, используемых несколькими сообществами.

2.1 Базовая архитектура и стратегия интеграции

Стратегия использует федеративную накладную пакетную систему. Вместо модификации локальных менеджеров ресурсов (таких как SLURM, PBS) создаётся объединённый пул на основе HTCondor. Мета-планировщик ресурсов COBalD/TARDIS динамически и прозрачно интегрирует гетерогенные бэкенды (кластеры HPC, фермы HTC, облачные ВМ) в этот единый пул. Он действует как «пилотная» система, отправляя задания-заглушки для захвата ресурсов, а затем развёртывая фактические рабочие нагрузки пользователей.

2.2 Доступ пользователей и программная среда

Доступ предоставляется через традиционные узлы входа (login nodes) и службу JupyterHub, которые служат центральными точками входа. Инфраструктура аутентификации и авторизации (AAI) на основе токенов стандартизирует доступ. Сложность программной среды управляется с помощью технологий контейнеризации (Docker, Singularity/Apptainer) и файловой системы виртуальных машин ЦЕРН (CVMFS), которая предоставляет предварительно настроенные, специфичные для сообществ стеки программного обеспечения масштабируемым, доступным только для чтения способом.

3. Федеративная инфраструктура хранения данных – Storage4PUNCH

Storage4PUNCH направлена на федерацию систем хранения данных, предоставляемых сообществами, в основном на основе технологий dCache или XRootD, которые хорошо зарекомендовали себя в физике высоких энергий (HEP). Федерация создаёт общее пространство имён и уровень доступа. Концепция также оценивает существующие технологии кэширования (для снижения задержек и трафика глобальной сети) и обработки метаданных, стремясь к более глубокой интеграции для облегчения обнаружения и управления данными в рамках федеративного хранилища.

4. Техническая реализация и ключевые компоненты

4.1 Федерация вычислений: HTCondor и COBalD/TARDIS

HTCondor: Обеспечивает уровень управления заданиями, их постановки в очередь и планирования в рамках федеративного пула. Его механизм ClassAd позволяет сопоставлять сложные требования заданий с динамическими свойствами ресурсов.
COBalD/TARDIS: Находится между HTCondor и гетерогенными бэкендами. TARDIS преобразует «пилоты» HTCondor в команды отправки, специфичные для бэкенда (например, скрипт задания SLURM). COBalD реализует логику принятия решений о том, когда и где запускать этих пилотов, на основе политик, стоимости и состояния очередей. Основную функцию можно смоделировать как задачу оптимизации: $\text{Максимизировать } U = \sum_{r \in R} (w_r \cdot u_r(\text{alloc}_r)) \text{ при условии } \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: Протокол и набор инструментов для масштабируемого, отказоустойчивого доступа к данным. Его компонент «redirector» позволяет строить федерации, где клиентский запрос направляется на соответствующий сервер данных.
Федерация создаёт логический уровень, который представляет несколько физических экземпляров как единую систему, что крайне важно для планирования с учётом локализации данных.

4.3 Доставка ПО и данных: контейнеры и CVMFS

Контейнеры: Обеспечивают воспроизводимость программных сред на разнородных хост-системах. Они инкапсулируют сложные зависимости (например, определённые версии ROOT, Geant4).
CVMFS: Глобальная распределённая файловая система для распространения программного обеспечения. Она использует HTTP и агрессивное кэширование. Её содержимое публикуется один раз и становится доступным повсеместно, решая проблему развёртывания ПО в крупных масштабах. Процесс публикации включает сервер «stratum 0» и репликацию на зеркала «stratum 1».

5. Статус прототипа и первоначальный опыт

В документе сообщается, что прототипы как Compute4PUNCH, так и Storage4PUNCH были развёрнуты. Первоначальные научные приложения были успешно выполнены на доступных прототипах, что демонстрирует осуществимость концепций. Конкретные метрики производительности или детальные тематические исследования в аннотации не приводятся, но успешное выполнение подтверждает подход к интеграции и выбранный стек технологий.

7. Оригинальный анализ: основная идея, логика, сильные и слабые стороны, практические рекомендации

Основная идея: PUNCH4NFDI не строит новый суперкомпьютер; он дирижирует симфонией существующих, разнородных инструментов. Его истинное новшество заключается в мета-уровне — «дирижёре оркестра», состоящем из COBalD/TARDIS и протоколов федерации, — который создаёт единый пул ресурсов, не требуя однородности от нижележащих провайдеров. Это стратегический мастер-ход для политически сложных, многоинституциональных коллабораций, напоминающий парадигму федеративного обучения в ИИ (как в работе Google по Federated Averaging), где данные остаются распределёнными, а модели агрегируются.

Логика работы: Архитектура следует чёткому разделению ответственности. 1) Доступ и идентификация: AAI на основе токенов аутентифицирует пользователей. 2) Абстракция вычислений: Пользователь отправляет задание в HTCondor. COBalD/TARDIS отслеживает очереди, решает, на каком бэкенде (например, HPC-кластере университета) есть свободные мощности, и развёртывает пилотное задание, чтобы «зарезервировать» эти ресурсы для пула HTCondor. Затем фактическое задание пользователя выполняется внутри этого пилота. 3) Программная среда: Задание получает свой специфический стек ПО через CVMFS или из реестра контейнеров. 4) Доступ к данным: Задание читает/записывает данные через федеративный уровень хранения (dCache/XRootD), который перенаправляет запросы к фактическому местоположению данных.

Сильные и слабые стороны: Сильная сторона — неоспоримый прагматизм. Обернув существующие системы, проект достигает быстрой развёртываемости и поддержки со стороны владельцев ресурсов. Использование проверенного стека технологий HEP (подтверждённого успехом Worldwide LHC Computing Grid ЦЕРНа) является серьёзным фактором снижения рисков. Однако слабые стороны заключаются в присущей сложности уровня мета-планирования. COBalD/TARDIS должен принимать интеллектуальные решения о выделении ресурсов в гетерогенных системах с разными политиками, затратами (например, облачные кредиты) и профилями производительности. Плохо настроенная политика может привести к неэффективному использованию ресурсов или «голоданию» заданий. Кроме того, хотя федерация хранения обеспечивает единый доступ, расширенные функции управления данными, такие как индексация глобального пространства имён, федерация каталогов метаданных и интеллектуальное размещение данных (аналогично идеям в параллельной файловой системе Lustre или исследованиям по автоматическому распределению по уровням хранения), по-видимому, являются предметом будущей оценки, что представляет собой текущее ограничение.

Практические рекомендации: Для других консорциумов (например, в биоинформатике или климатологии) ключевой вывод — с самого начала активно инвестировать в дизайн мета-планировщика и уровня абстракции. Подход PUNCH предполагает начать с минимально жизнеспособной федерации, используя стабильную технологию, такую как HTCondor, а не пытаться строить с нуля. С поставщиками ресурсов следует взаимодействовать, предъявляя чёткие, минимальные требования, подобные API (например, «должна поддерживаться SSH или определённая команда пакетной системы»). Критически важно, чтобы проект разработал надёжные инструменты мониторинга и аудита для самого федеративного уровня — понимание межсайтового использования и диагностика сбоев в этой сложной цепочке будут иметь первостепенное операционное значение. Дорожная карта на будущее должна явно предусматривать интеграцию с системами управления рабочими процессами (такими как Nextflow или Apache Airflow) и разработку оцениваемых служб кэширования и метаданных, чтобы перейти от простой федерации к интеллектуальной, оптимизированной по производительности логистике данных.

8. Технические детали и математическая модель

Задачу распределения ресурсов, решаемую COBalD/TARDIS, можно сформулировать как онлайн-оптимизацию. Пусть $Q(t)$ — очередь ожидающих заданий в HTCondor в момент времени $t$, каждое с предполагаемым временем выполнения $\hat{r}_i$ и вектором запроса ресурсов $\vec{c}_i$ (CPU, память, GPU). Пусть $B$ — множество бэкендов, каждый с изменяющейся во времени доступной ёмкостью $\vec{C}_b(t)$ и функцией стоимости $f_b(\vec{c}, \Delta t)$ для выделения ресурсов $\vec{c}$ на время $\Delta t$. Цель мета-планировщика — минимизировать среднее время выполнения задания $T_{ta}$, соблюдая политики бэкендов и бюджетные ограничения. Упрощённое эвристическое правило для запуска пилота на бэкенде $b$ может быть таким: $\text{Запустить, если } \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 Stratum 1 показаны как уровень, доступный всем бэкендам.

10. Аналитическая структура: пример концептуального рабочего процесса

Сценарий: Астрофизику, изучающему частицы, необходимо обработать 1000 изображений телескопа с использованием сложного, пользовательского конвейера анализа (на основе Python/ROOT).

1. Вход пользователя: Исследователь входит в PUNCH JupyterHub.
2. Настройка среды: В блокноте Jupyter он выбирает предопределённое ядро (kernel), основанное на контейнере Singularity, который содержит его специфический стек ПО (опубликованный в CVMFS).
3. Определение задания: Он пишет скрипт, определяющий задачу анализа, и использует вспомогательную библиотеку PUNCH для создания описания отправки HTCondor, указывая необходимые CPU, память и ссылки на входные данные (например, `root://fed-storage.punch.org/path/to/images_*.fits`).
4. Отправка и планирование: Задание отправляется в пул HTCondor. COBalD/TARDIS, видя 1000 коротких заданий, решает запустить несколько пилотных заданий на ферме с высокой пропускной способностью (Бэкенд B) с быстрым локальным кэшем хранилища для входных данных.
5. Выполнение: Пилоты захватывают слоты на Бэкенде B. Каждый пилот загружает контейнер, получает свои назначенные входные файлы через федерацию XRootD (которая может перенаправить на локальный кэш), выполняет анализ и записывает результаты обратно в федеративное хранилище.
6. Завершение: HTCondor агрегирует статус завершения заданий. Теперь блокнот исследователя может запрашивать и визуализировать результаты из места выходного хранилища.

Этот пример подчёркивает полную абстракцию: пользователю никогда не нужно было знать команды SLURM на Бэкенде B, как установить там ROOT или физическое местоположение файлов данных.

11. Будущие приложения и план развития

Инфраструктура PUNCH4NFDI закладывает основу для преобразующих приложений:

• Рабочие процессы многоканальной астрофизики: Анализ корреляций в реальном времени между данными гравитационно-волновых (LIGO/Virgo), нейтринных (IceCube) и электромагнитных обсерваторий, требующий срочных вычислений на географически распределённых ресурсах.
• Масштабное обучение моделей ИИ/МО: Эксперименты по федеративному обучению, где сам процесс обучения распределён по вычислительной федерации, а модели агрегируются централизованно — вычислительный аналог федерации данных.
• Цифровые двойники сложных экспериментов: Запуск массивных ансамблей симуляций для создания цифровых копий детекторов частиц или массивов телескопов, использующих HPC для моделирования и HTC для сканирования параметров.

План развития:

1. Краткосрочный (1-2 года): Укрепить промышленное развёртывание основных служб Compute4PUNCH и Storage4PUNCH. Интегрировать расширенный мониторинг (Prometheus/Grafana) и инструменты учёта/биллинга.
2. Среднесрочный (3-4 года): Реализовать и интегрировать оцениваемые службы кэширования и глобального каталога метаданных. Разработать более тесную интеграцию с системами управления рабочими процессами. Исследовать возможность «всплескового» использования коммерческих облаков в периоды пиковой нагрузки.
3. Долгосрочный (5+ лет): Эволюционировать в направлении «интеллектуального озера данных» для науки PUNCH, включив обнаружение данных, отслеживание происхождения и автоматизированное управление жизненным циклом данных на основе федеративных метаданных. Служить образцом для других консорциумов NFDI и международных коллабораций.

12. Ссылки

1. Консорциум PUNCH4NFDI. (2024). Белая книга PUNCH4NFDI. [Официальная документация консорциума].
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. (Ссылка на мета-планировщик).
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 [Программное обеспечение и документация]. 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). (Цитируется по аналогии с федеративным обучением).
8. European Organization for Nuclear Research (CERN). (2023). Worldwide LHC Computing Grid (WLCG). https://wlcg.web.cern.ch (Цитируется как прецедент крупномасштабной федерации).