Выбрать язык

Compute4PUNCH & Storage4PUNCH: Федеративная инфраструктура для физики частиц, астрофизики и ядерной физики

Анализ концепций федеративных вычислительных и хранилищных инфраструктур консорциума PUNCH4NFDI, интегрирующих гетерогенные ресурсы HPC, HTC и облачных вычислений по всей Германии.
computepowertoken.com | PDF Size: 0.5 MB
Оценка: 4.5/5
Ваша оценка
Вы уже оценили этот документ
Обложка PDF-документа - Compute4PUNCH & Storage4PUNCH: Федеративная инфраструктура для физики частиц, астрофизики и ядерной физики

1. Введение

Консорциум PUNCH4NFDI (Particles, Universe, NuClei and Hadrons for the National Research Data Infrastructure), финансируемый Немецким научно-исследовательским сообществом (DFG), объединяет около 9000 учёных из сообществ физики частиц, астрофизики, астрочастиц, адронной и ядерной физики Германии. Будучи частью национальной инициативы NFDI, его главная цель – создание федеративной научной платформы данных, соответствующей принципам FAIR (Findable, Accessible, Interoperable, Reusable – находимые, доступные, совместимые, повторно используемые). Эта платформа призвана обеспечить бесшовный доступ к разнообразным и гетерогенным вычислительным и хранилищным ресурсам, предоставленным учреждениями-участниками, решая общую задачу анализа экспоненциально растущих объёмов данных с помощью сложных алгоритмов. В данном документе рассматриваются технические концепции Compute4PUNCH и Storage4PUNCH, которые составляют основу этой федеративной инфраструктуры.

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

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

2.1. Базовая архитектура и оверлейная система

Краеугольным камнем Compute4PUNCH является создание федеративной оверлейной пакетной системы на основе HTCondor. Ключевая инновация заключается в использовании мета-планировщика ресурсов COBalD/TARDIS. TARDIS (TARDIS Acts as a Resource Dispatcher for In-place Scheduling) динамически и прозрачно интегрирует внешние гетерогенные ресурсы в пул HTCondor. Он действует как «пилотная» система, отправляя задания-заглушки на внешние кластеры (например, HPC-системы на основе Slurm), которые затем забирают и выполняют реальные пользовательские задания из центральной очереди 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 Virtual Machine File System (CVMFS). CVMFS предоставляет масштабируемое, доступное только для чтения и глобально распределённое пространство имён для установки программного обеспечения. Специфичные для сообществ программные стеки публикуются в репозиториях CVMFS, что гарантирует, что любой вычислительный узел, независимо от его физического местоположения, может мгновенно и согласованно получить доступ к требуемой программной среде, устраняя необходимость локальной установки.

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

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

3.1. Стратегии федерации и кэширования

Федерация создаёт единое пространство имён, позволяя пользователям получать доступ к данным в нескольких институциональных элементах хранения, как если бы это была единая система. Для достижения этого используются такие технологии, как протокол федерации XRootD и пулинг фронтендов dCache. Система выполняет интеллектуальное определение местоположения данных и маршрутизацию.

Критическим компонентом, находящимся на стадии оценки, является кэширование. Глобальный или региональный уровень кэша может значительно снизить задержку и нагрузку на глобальную сеть для часто запрашиваемых наборов данных. Коэффициент попадания в кэш $H$ для кэша размером $S$ при определённом шаблоне доступа к данным можно смоделировать. Если вероятность доступа к элементу данных $d_i$ следует распределению, подобному закону Ципфа $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$ – это направленный ациклический граф (DAG) задач $T$ с зависимостями по данным $D$.

Задача планирования формулируется следующим образом: разместить каждую задачу $t \in T$ на вычислительном ресурсе $r_c \in V_c$ и направить её требуемые входные данные из ресурсов хранения $r_s \in V_s$ таким образом, чтобы общее время выполнения (время завершения рабочего процесса) было минимальным, при соблюдении ограничений:

$\text{минимизировать } \max_{t \in T} (ft(t))$
при условиях:
$\forall r \in V_c, \sum_{t размещена\ на\ 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) Время выполнения задания в сравнении федеративного сценария с использованием изолированных ресурсов. Федеративная система показала бы более низкое среднее значение и дисперсию времени выполнения, особенно для заданий с гибкими требованиями к ресурсам, поскольку они могут быть направлены на ресурсы с самой короткой очередью. Интеграция ресурсов HPC через TARDIS показала бы отдельную кривую, изначально добавляющую задержку из-за механизма пилотных заданий, но предоставляющую доступ к иначе недоступным узлам с большим количеством ядер для подходящих рабочих нагрузок.

Сообщается, что использование CVMFS успешно обеспечивает единообразные программные среды, что является критически важным фактором успеха для пользователей. AAI на основе токенов была реализована, обеспечивая необходимую основу для безопасного доступа из нескольких учреждений.

6. Фреймворк анализа: концептуальный пример использования

Пример: Анализ в многоканальной астрофизике. Астрофизику, изучающему частицы, необходимо проанализировать данные о гамма-всплеске (GRB), зарегистрированном Fermi-LAT и IceCube, сопоставив их с оптическими наблюдениями от ASAS-SN. Рабочий процесс включает: A) Обработку терабайтов сырых данных о фотонах (Fermi) на ферме HTC, оптимизированной для высокого ввода-вывода. B) Запуск Монте-Карло симуляций для реконструкции нейтринных событий (IceCube) на HPC-кластере с большим количеством ядер. C) Выполнение анализа изображений оптических данных с использованием GPU-узлов.

Федеративное выполнение через Compute4PUNCH/Storage4PUNCH:
1. Пользователь отправляет единое высокоуровневое описание рабочего процесса (например, с использованием Common Workflow Language - CWL) через JupyterHub.
2. Токен AAI аутентифицирует пользователя во всех системах.
3. Оверлей HTCondor под управлением COBalD/TARDIS анализирует DAG рабочего процесса:
- Задача A сопоставляется и отправляется на HTC-воркеры в DESY, расположенные близко к хранилищу на базе dCache.
- Требование задачи B в 10 000 CPU-часов заставляет TARDIS выделить слоты на HPC-кластере на основе Slurm в KIT.
- Задача C отправляется в GPU-секцию в Боннском университете.
4. Все задачи загружают идентичный стек программного обеспечения для анализа (Python, специфичные научные библиотеки) из репозитория PUNCH CVMFS.
5. Промежуточные данные обмениваются через федеративное пространство имён Storage4PUNCH (например, с использованием XRootD), причём часто запрашиваемые калибровочные файлы обслуживаются из регионального кэша.
6. Итоговые результаты агрегируются и возвращаются пользователю.

Этот пример демонстрирует ценностное предложение: физик взаимодействует с единой логической инфраструктурой, а не управляет отдельными логинами, установками ПО и передачей данных в трёх различных системах.

7. Ключевая идея и взгляд аналитика

Ключевая идея: PUNCH4NFDI не строит ещё один монолитный суперкомпьютер; он создаёт уровень федерации — «мета-операционную систему» для исследовательских вычислений национального масштаба на гетерогенных ресурсах. Его реальная инновация — прагматичная оркестрация существующих, политически изолированных ресурсов в согласованную утилиту, где приоритет отдаётся минимальному вмешательству, а не технологической чистоте. Это больше похоже не на Google Borg, а на сложную общеевропейскую систему управления воздушным движением для вычислительных заданий.

Логическая последовательность: Логика элегантно рекурсивна. Начните с неоспоримого ограничения: не нарушать существующие операции сообществ. Это вынуждает использовать архитектуру на основе вытягивания (pull-based), оверлейную архитектуру (HTCondor + TARDIS) вместо централизованного планировщика на основе проталкивания (push-based). Этот оверлей, в свою очередь, требует универсального механизма доставки ПО (CVMFS/Контейнеры) и унифицированного уровня идентификации (Token AAI). Федерация хранения данных развивается по параллельному пути, используя проверенные в боях инструменты HEP (dCache/XRootD). Вся последовательность — это мастер-класс по проектированию, основанному на ограничениях, где каждый технический выбор является прямым следствием социально-политической реальности межучрежденческого сотрудничества.

Сильные стороны и недостатки:
Сильные стороны: Архитектура блестяще федеративна. Она масштабирует управление по горизонтали по замыслу, снижая барьеры для новых поставщиков ресурсов. Использование HTCondor и CVMFS опирается на десятилетия доверия сообщества и операционного опыта коллабораций LHC, снижая технические риски. Фокус на ресурсах «в натуральной форме» финансово устойчив, превращая проблему фрагментации в преимущество разнообразия.
Недостатки: Слон в комнате — это накладные расходы на производительность. Двойное планирование (мета-планировщик + локальная пакетная система) и модель пилотных заданий неизбежно добавляют задержку, делая систему непригодной для мелкозернистых, тесно связанных MPI-заданий — значительное ограничение для чисто HPC-нагрузок. Зависимость от CVMFS, хотя и надёжная, создаёт единую точку отказа для доставки ПО и может столкнуться с трудностями при работе с высоко проприетарным или лицензионным кодом. Более того, как отмечено в принципах данных FAIR, истинная совместимость требует богатых метаданных; текущее описание Storage4PUNCH, кажется, сильно сосредоточено на доступе на уровне байтов, а не на семантическом обнаружении.

Практические выводы:
1. Для команды PUNCH: Удвоить усилия по характеристике производительности. Опубликовать прозрачные тесты, сравнивающие пропускную способность и задержку заданий в федеративном и нативном режимах для канонических рабочих процессов. Эти данные имеют решающее значение для убеждения скептически настроенных менеджеров HPC-центров и пользователей. Активно разработать модель поддержки «Уровня 1» для самого уровня федерации; его сложность становится критической зависимостью.
2. Для других консорциумов (например, в биоинформатике или климатологии): Не просто копируйте технологический стек. Скопируйте модель управления, которая сделала его возможным. Ключевой урок — соглашение о «взносе в натуральной форме», которое согласует институциональные стимулы. Начните с федерации аутентификации и распространения ПО, как это сделал PUNCH; это фундаментальные шаги.
3. Для финансирующих организаций (DFG, ЕС): Эта модель должна стать образцом для будущих конкурсов на создание национальной исследовательской инфраструктуры. Финансируйте «скрепляющий раствор» (координацию, основное devops для уровня федерации) и позвольте учреждениям финансировать «кирпичи» (фактические вычисления/хранение). Это более эффективно использует существующие капитальные вложения, чем строительство новых централизованных объектов, — принцип, отражённый в стратегическом видении European Open Science Cloud (EOSC).

В заключение, Compute4PUNCH и Storage4PUNCH представляют собой зрелую, прагматичную и легко воспроизводимую модель инфраструктуры для крупномасштабной науки XXI века. Она жертвует частью теоретической производительности ради огромного выигрыша в доступности, отказоустойчивости и политической осуществимости. Её успех будет измеряться не во флопсах, а в количестве аспирантов, которые смогут завершить свой анализ, не становясь экспертами по системному администрированию для пяти разных кластеров.

8. Будущие применения и план развития

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

  • Интеграция с рабочими процессами машинного обучения: Федерация может быть расширена для поддержки специализированных ускорителей ИИ/МО (например, NVIDIA DGX pods, Google TPU) в качестве типа ресурса. Фреймворки, такие как Kubeflow, могут быть интегрированы вместе с HTCondor, а TARDIS будет управлять гибридным размещением заданий между традиционными HTC-ресурсами и ресурсами, ориентированными на МО.
  • Проактивное размещение данных и планирование с учётом рабочих процессов: Выходя за рамки кэширования, система может реализовать прогнозируемое промежуточное хранение данных. Анализируя DAG рабочих процессов, отправленные пользователями, она могла бы предварительно загружать требуемые наборы данных с удалённых конечных точек Storage4PUNCH в локальные кэши рядом с запланированными вычислительными ресурсами до начала выполнения задания, эффективно скрывая задержку передачи данных. Это требует более тесной интеграции между мета-планировщиком вычислений и пространством имён и данными мониторинга федерации хранения.
  • Расширение на периферийные вычисления: Для таких областей, как радиоастрономия или физика нейтрино, где сенсоры генерируют огромные потоки данных, модель федерации может включать сайты периферийных вычислений. Облегчённые агенты TARDIS могли бы работать в обсерваториях, забирая задачи предварительной обработки из центральной очереди для фильтрации и сокращения данных на месте перед передачей только релевантных событий в центральное хранилище.
  • Зелёные вычисления и планирование с учётом углеродного следа: Мета-планировщик может быть улучшен за счёт данных об углеродоёмкости электросетей по всей Германии. Затем он мог бы направлять задания предпочтительно в дата-центры в регионах с высокой долей возобновляемой энергии (например, ветряной энергии на севере) в периоды пиковой выработки, минимизируя углеродный след крупномасштабных вычислений — это становится всё более важным приоритетом для исследовательских инфраструктур, как подчёркивается инициативой Linux Foundation Carbon Call.
  • Межфедеративное взаимодействие с международными партнёрами: Следующим логическим шагом является подключение немецкой федерации PUNCH к аналогичным инфраструктурам за рубежом, таким как Worldwide LHC Computing Grid (WLCG), Open Science Grid (OSG) или European Open Science Cloud (EOSC). Это создало бы глобальную междисциплинарную исследовательскую инфраструктуру, хотя и подняло бы значительные проблемы в области согласования политик, безопасности и учёта ресурсов.

9. Ссылки

  1. Консорциум PUNCH4NFDI. «PUNCH4NFDI - Particles, Universe, NuClei and Hadrons for the NFDI.» Белая книга, 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.» В 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.» В Proceedings of the IEEE International Conference on Computer Vision (ICCV), 2017. (Приведено как пример сложной вычислительной нагрузки, которая может выиграть от федеративного доступа к гетерогенным ресурсам).