1. Введение
Консорциум PUNCH4NFDI (Частицы, Вселенная, Ядра и Адроны для Национальной исследовательской инфраструктуры данных), финансируемый Немецким научно-исследовательским сообществом (DFG), объединяет около 9000 ученых из сообществ физики частиц, астрофизики, астрочастиц, адронной и ядерной физики. Будучи частью более широкой инициативы NFDI, его главная цель — создание федеративной платформы научных данных, соответствующей принципам FAIR (Находимость, Доступность, Совместимость, Повторное использование). Эта платформа призвана обеспечить беспрепятственный доступ к разнообразным вычислительным ресурсам и ресурсам хранения данных участвующих учреждений, решая общие проблемы, вызванные экспоненциальным ростом объемов данных и вычислительно сложными алгоритмами анализа. В данном документе рассматриваются архитектурные концепции — Compute4PUNCH и Storage4PUNCH, — предназначенные для федерации гетерогенной исследовательской инфраструктуры Германии.
2. Федеративная гетерогенная вычислительная инфраструктура – Compute4PUNCH
Compute4PUNCH решает задачу эффективного использования широкого спектра предоставленных ресурсов, включая системы высокопроизводительных вычислений (HPC), вычислений с высокой пропускной способностью (HTC) и облачные системы, распределенные по всей Германии. Эти ресурсы различаются по архитектуре, операционным системам, стекам программного обеспечения и политикам доступа. Основной принцип проектирования — создание единой накладной системы с минимальным вмешательством в работу существующих операторов ресурсов.
2.1. Базовая архитектура и интеграция
Федерация построена вокруг HTCondor как центральной накладной системы пакетной обработки. Гетерогенные ресурсы динамически интегрируются с использованием метапланировщика ресурсов COBalD/TARDIS. COBalD/TARDIS действует как интеллектуальный брокер, направляя задания на подходящие бэкенды (например, кластеры Slurm, Kubernetes) на основе доступности ресурсов, требований заданий и политик. Это создает единый логический пул ресурсов из физически разрозненных систем.
2.2. Доступ пользователей и программная среда
Точки входа для пользователей предоставляются через традиционные логин-узлы и сервис JupyterHub. Токеновая инфраструктура аутентификации и авторизации (AAI) стандартизирует доступ. Сложность программной среды управляется с помощью технологий контейнеризации (например, Docker, Singularity/Apptainer) и CERN Virtual Machine File System (CVMFS), которая обеспечивает масштабируемое, доступное только для чтения распространение программного обеспечения на вычислительные узлы по всему миру.
3. Федеративная инфраструктура хранения данных – Storage4PUNCH
Storage4PUNCH направлен на федерацию предоставляемых сообществом систем хранения данных, в основном основанных на технологиях dCache и XRootD, которые хорошо зарекомендовали себя в физике высоких энергий (HEP). Федерация использует общие пространства имен и протоколы (такие как xrootd, WebDAV) для представления единого уровня доступа к данным. Концепция также предусматривает оценку интеграции решений кэширования и служб обработки метаданных для улучшения локальности данных и их обнаружимости в рамках федерации.
4. Техническая реализация и компоненты
4.1. Аутентификация и авторизация (AAI)
Токеновая AAI (вероятно, использующая стандарты OAuth 2.0/OpenID Connect, аналогичные WLCG IAM или INDIGO IAM) обеспечивает единый вход в систему. Она сопоставляет идентификаторы сообщества с локальными разрешениями на ресурсы, абстрагируясь от гетерогенных локальных систем аутентификации (например, Kerberos, SSH-ключи).
4.2. Метапланирование ресурсов: COBalD/TARDIS
COBalD (Координатор) и TARDIS (Transparent Adaptive Resource Dynamic Integration System) работают в тандеме. COBalD принимает решения высокого уровня по планированию, а TARDIS управляет жизненным циклом «пилотов» или «заполнителей заданий» на целевых ресурсах. Такое разделение позволяет гибко применять политики (например, стоимость, справедливость, приоритет) и динамически адаптироваться к изменяющимся состояниям ресурсов. Планирование можно смоделировать как задачу оптимизации, минимизирующую функцию стоимости $C_{total} = \sum_{i}(w_i \cdot T_i) + \lambda \cdot R$, где $T_i$ — время выполнения задания $i$, $w_i$ — его весовой коэффициент приоритета, $R$ представляет стоимость использования ресурса, а $\lambda$ — балансировочный параметр.
4.3. Слой данных и программного обеспечения
CVMFS имеет критическое значение для распространения программного обеспечения. Она использует модель адресуемого по содержимому хранилища и агрессивное кэширование (с серверами Stratum 0/1 и локальными кэшами Squid) для эффективной доставки репозиториев программного обеспечения. В федерации, вероятно, используется иерархия стратумов CVMFS с центральным стратумом 0 репозитория PUNCH и институциональными зеркалами стратума 1. Доступ к данным следует аналогичной федеративной модели: элементы хранения (SE) публикуют свои конечные точки в глобальном каталоге (например, Rucio или простой REST-сервис), что позволяет клиентам прозрачно определять местоположение данных.
5. Статус прототипа и первоначальный опыт
В документе указано, что прототипы как Compute4PUNCH, так и Storage4PUNCH находятся в рабочем состоянии. Были выполнены первые научные приложения, что дало ценную обратную связь по производительности, удобству использования и проблемам интеграции. Хотя в приведенном отрывке не указаны конкретные результаты тестов, успешное выполнение подразумевает, что базовая функциональность накладной пакетной системы, интеграция AAI и доставка программного обеспечения через CVMFS были проверены. Полученный опыт направляет доработки в конфигурации политик, обработке ошибок и пользовательской документации.
6. Ключевые выводы и стратегический анализ
Основной вывод: PUNCH4NFDI не строит новый суперкомпьютер; он создает «ткань федерации», которая прагматично объединяет существующие, разрозненные ресурсы. Это стратегический сдвиг от монолитной инфраструктуры к гибкой, определяемой программным обеспечением агрегации ресурсов, отражающий тенденции коммерческого облака, но адаптированный к ограничениям и культуре публично финансируемой академической среды.
Логическая последовательность: Архитектура следует четкой, зависимой логике: 1) Унификация идентификации (AAI) для решения проблемы «кто», 2) Абстрагирование ресурсов (COBalD/TARDIS + HTCondor) для решения проблемы «где» и 3) Отделение среды (Контейнеры + CVMFS) для решения проблемы «с помощью чего». Это многоуровневое абстрагирование является классическим системным инжинирингом, напоминающим успех Worldwide LHC Computing Grid (WLCG), но применяемым к более разнообразному набору ресурсов.
Сильные стороны и недостатки: Основная сила — это модель внедрения без разрушения. Используя накладные технологии и уважая автономию площадок, она снижает барьер для поставщиков ресурсов — что является решающим фактором успеха для консорциумов. Однако это же является и ее ахиллесовой пятой. Накладные расходы на метапланирование и присущая сложность отладки в гетерогенных, независимо управляемых системах могут быть значительными. Требование «минимального вмешательства» может ограничить возможность реализации продвинутых функций, таких как тесная связь вычислений и хранения или динамическое выделение сетевых ресурсов, потенциально ограничивая рост эффективности. По сравнению с целенаправленно построенной централизованной системой, такой как Google Borg или кластер Kubernetes, федерация всегда будет иметь более высокую задержку и менее предсказуемую утилизацию.
Практические выводы: Для других консорциумов, рассматривающих этот путь: 1) Значительно инвестируйте в мониторинг и наблюдаемость с самого начала. Инструменты, такие как Grafana/Prometheus для инфраструктуры и APM (Application Performance Monitoring) для пользовательских заданий, являются обязательными для управления сложностью. 2) Стандартизируйтесь на узком наборе базовых образов контейнеров, чтобы снизить нагрузку на обслуживание CVMFS. 3) Разработайте четкую, многоуровневую модель поддержки, которая различает проблемы уровня федерации и локальные проблемы площадок. Настоящим испытанием будет не техническая осуществимость — сообщество HEP это уже доказало, — а операционная устойчивость и удовлетворенность пользователей в масштабе.
7. Техническое углубление
Математическая модель планирования ресурсов: Систему COBalD/TARDIS можно концептуализировать как решение задачи условной оптимизации. Пусть $J$ — множество заданий, $R$ — множество ресурсов, а $S$ — множество состояний ресурсов (например, простаивает, занят, отключен). Планировщик стремится максимизировать функцию полезности $U$, учитывающую приоритет задания $p_j$, эффективность ресурса $e_{j,r}$ и стоимость $c_r$: $$\max \sum_{j \in J} \sum_{r \in R} x_{j,r} \cdot U(p_j, e_{j,r}, c_r)$$ при ограничениях: $$\sum_{j} x_{j,r} \leq C_r \quad \forall r \in R \quad \text{(Емкость ресурса)}$$ $$\sum_{r} x_{j,r} \leq 1 \quad \forall j \in J \quad \text{(Назначение задания)}$$ $$x_{j,r} \in \{0,1\} \quad \text{(Бинарная переменная решения)}$$ где $x_{j,r}=1$, если задание $j$ назначено на ресурс $r$. TARDIS динамически управляет выполнимостью назначений на основе состояния $S$ в реальном времени.
Экспериментальные результаты и описание диаграмм: Хотя в предоставленном отрывке PDF нет конкретных графиков производительности, типичная оценка включала бы диаграммы, сравнивающие:
1. Пропускную способность заданий во времени: Линейный график, показывающий количество заданий, выполненных в час, в федеративном пуле по сравнению с отдельными кластерами ресурсов, демонстрируя преимущество агрегации.
2. Тепловую карту использования ресурсов: Визуализация в виде сетки, показывающая процент используемых CPU/GPU у разных поставщиков ресурсов (KIT, DESY, Bielefeld и т.д.) в течение недели, подчеркивающая эффективность балансировки нагрузки.
3. CDF задержки запуска задания: График кумулятивной функции распределения, сравнивающий время от отправки задания до начала выполнения в федеративной системе с прямой отправкой в локальную пакетную систему, выявляющий накладные расходы метапланирования.
4. Производительность доступа к данным: Гистограмма, сравнивающая скорости чтения/записи для данных, доступных локально, с федеративного элемента хранения в том же регионе и с удаленного федеративного элемента, иллюстрирующая влияние кэширования и сети.
8. Аналитическая структура и концептуальная модель
Пример использования: Федеративный анализ данных астрономического обзора
Сценарий: Исследовательская группа в Тюрингской государственной обсерватории Таутенбург должна обработать 1 ПБ данных изображений из Sloan Digital Sky Survey (SDSS) для идентификации скоплений галактик — вычислительно сложная задача, требующая ~100 000 CPU-часов.
Процесс через Compute4PUNCH/Storage4PUNCH:
1. Аутентификация: Исследователь входит в PUNCH JupyterHub, используя свои институциональные учетные данные (через токеновую AAI).
2. Программная среда: Ядро его блокнота Jupyter запускается из образа контейнера, размещенного на CVMFS, содержащего все необходимые астрономические пакеты (Astropy, SExtractor и т.д.).
3. Определение и отправка задания: Он определяет задание с перебором параметров в блокноте. Блокнот использует клиентскую библиотеку PUNCH для отправки этих заданий в виде DAG (Directed Acyclic Graph) HTCondor в федеративный пул.
4. Сопоставление ресурсов и выполнение: COBalD/TARDIS оценивает требования задания (CPU, память, возможно, GPU) и направляет их на доступные слоты, например, в пулы HTC в KIT, очереди HPC в Университете Билефельда и облачные узлы в DESY. Задания считывают входные данные через федеративное пространство имен XRootD из ближайшего местоположения хранения, возможно, используя кэш.
5. Агрегация результатов: Выходные файлы записываются обратно в федеративное хранилище. Исследователь отслеживает прогресс через единую веб-панель и, наконец, агрегирует результаты в своем блокноте для анализа.
Этот пример демонстрирует бесшовную интеграцию идентификации, вычислений, хранения и управления программным обеспечением.
9. Будущие приложения и план развития
Инфраструктура PUNCH4NFDI закладывает основу для нескольких продвинутых приложений:
1. Федеративное обучение моделей машинного обучения: Гетерогенный пул ресурсов, включая потенциальные GPU-кластеры, может поддерживать распределенные фреймворки обучения ML, такие как PyTorch или TensorFlow, через институциональные границы, решая задачи обучения с сохранением конфиденциальности, когда данные не могут быть централизованы.
2. Интерактивный анализ и визуализация: Улучшение сервиса JupyterHub с помощью масштабируемых инструментов интерактивной визуализации с поддержкой бэкенда (например, виджеты Jupyter, подключенные к кластерам Dask в федерации) для исследования больших наборов данных.
3. Интеграция с внешними облаками и центрами HPC: Расширение федеративной модели для включения коммерческих облачных кредитов (например, AWS, GCP) или национальных суперкомпьютерных центров (например, JUWELS в JSC) через общий уровень биллинга/учета, создавая истинное гибридное облако для науки.
4. Интеграция метаданных и Data Lake: Переход от простой федерации файлов к интегрированной архитектуре Data Lake, где уровень хранения связан с единым каталогом метаданных (например, на основе Rucio или iRODS), обеспечивая обнаружение данных и отслеживание происхождения между сообществами.
5. Workflow-as-a-Service: Предоставление сервисов платформы более высокого уровня, таких как REANA (Reproducible Analysis Platform) или Apache Airflow, поверх федеративной инфраструктуры, позволяя ученым определять и выполнять сложные, воспроизводимые аналитические конвейеры без управления базовой инфраструктурой.
План развития, вероятно, будет сосредоточен на укреплении производственного сервиса, расширении пула ресурсов, интеграции более сложных инструментов управления данными и разработке удобных API и SDK для снижения барьера входа для неэкспертных пользователей.
10. Ссылки
- Консорциум PUNCH4NFDI. (2024). Белая книга PUNCH4NFDI. [Внутренний документ консорциума].
- Thain, D., Tannenbaum, T., & Livny, M. (2005). Distributed computing in practice: the Condor experience. Concurrency - Practice and Experience, 17(2-4), 323-356. https://doi.org/10.1002/cpe.938
- Blomer, J., et al. (2011). Distribution of software in the CernVM file system with Parrot. Journal of Physics: Conference Series, 331(4), 042009. https://doi.org/10.1088/1742-6596/331/4/042009
- Giffels, M., et al. (2022). COBalD and TARDIS – Dynamic resource overlay for opportunistic computing. EPJ Web of Conferences, 251, 02009. https://doi.org/10.1051/epjconf/202225102009
- Сотрудничество dCache. (2023). dCache: A distributed storage data caching system. Получено с https://www.dcache.org/
- Сотрудничество XRootD. (2023). 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, 160018. https://doi.org/10.1038/sdata.2016.18
- Verma, A., et al. (2015). Large-scale cluster management at Google with Borg. Proceedings of the Tenth European Conference on Computer Systems (EuroSys '15). https://doi.org/10.1145/2741948.2741964