Проблемы и решения распределенной обработки

За последние 15 лет распределенные вычисления на гетерогенных ресурсах прошли путь от пионерских исследовательских работ до масштабного применения при решении реальных задач в различных областях науки и техники. Наиболее значительным можно считать проект Worldwide LHC Computing Grid (WLCG) обработки данных Большого адронного коллайдера, объединивший вычислительные ресурсы более 170 исследовательских институтов из 40 стран и позволивший обработать порядка 100 Пбайт данных. Распределенные вычисления достигли наибольшего развития в физике высоких энергий, однако это далеко не единственная область применения подобных технологий — ресурсоемкие задачи имеются в астрономии, медицине, генетике, фармакологии, сейсмологии и др. Снижение стоимости вычислительных элементов, средств хранения данных и повышение пропускной способности компьютерных сетей привели к тому, что распределенная обработка перестает быть привилегией крупных проектов и постепенно становится доступной для исследовательских групп и компаний со скромными ресурсами. Однако основным вопросом при этом является выбор программной базы, позволяющей построить инфраструктуру и организовать вычисления с достаточной надежностью и минимальными затратами. В качестве примера решения подобной задачи можно привести систему распределенных вычислений для эксперимента Beijing Spectrometer III (BES-III) на электрон-позитронном коллайдере в Пекине.

Этот эксперимент стартовал в 2009 году в Институте физики высоких энергий АН КНР и объединил более 400 ученых из 52 институтов в 12 странах [1]. Основной задачей эксперимента является изучение свойств ряда элементарных частиц. Хотя установка BES-III является источником гораздо меньшего объема данных по сравнению с генерируемыми на БАКе, тем не менее объем накопленных экспериментальных данных составляет сейчас около 1 Пбайт, и ожидается, что он возрастет в несколько раз в течение ближайших пяти — семи лет. Нехватка вычислительных ресурсов в компьютерном центре ИФВЭ заставила искать альтернативные решения, из которых наиболее привлекательным оказалось построение распределенной инфраструктуры на базе вычислительных центров институтов — участников эксперимента.

Модель обработки данных в эксперименте BES-III типична как для физики высоких энергий, так и для других областей — данные, содержащие информацию о событиях (взаимодействиях элементарных частиц, образовавшихся при столкновении ускоренных пучков электронов и позитронов), поступают на ленточные накопители со скоростью 40 Мбайт/с. После этого проводится реконструкция событий, а затем данные можно использовать для дальнейшего статистического анализа. Поскольку речь идет об изучении чрезвычайно редких явлений, большое значение при анализе имеет моделирование физической установки, позволяющее точно рассчитать и оптимальным образом подавить вклады фоновых процессов. Объем смоделированных данных достаточно велик и обычно сравним с объемом экспериментальных данных. Само моделирование является чрезвычайно затратной операцией, требующей значительных вычислительных ресурсов. Особенностью BES-III является использование в ходе моделирования реальных данных о шуме в установке, которые непрерывно записываются во время набора статистики.

В первоначальной модели обработки данных все операции реконструкции, моделирования и анализа проводились на вычислительном кластере ИФВЭ, включающем 4500 процессорных ядер, дисковую систему хранения емкостью 3 Пбайт и ленточную емкостью 4 Пбайт. Невысокая пропускная способность компьютерных сетей затрудняет передачу больших объемов данных из ИФВЭ, поэтому было решено хранить и реконструировать «сырые» данные непосредственно в локальном центре, а задачи моделирования, требующие больших ресурсов, вынести на удаленные центры инфраструктуры. Таким образом, для построения распределенной инфраструктуры требовалось программное обеспечение, способное решать следующие задачи: авторизация и аутентификация; предоставление информационной системы и средств мониторинга; управление вычислительными задачами; управление хранением и передачей данных; распространение ПО эксперимента.

Естественно, все перечисленные проблемы уже решались в рамках проекта WLCG, причем было разработано специализированное программное обеспечение EMI/gLite [2], предоставляющее все необходимые компоненты для организации распределенной инфраструктуры, и одновременно с этим аналогичные задачи решались в США в рамках проекта OSG (Open Science Grid). Однако, поскольку все это ПО служит для создания инфраструктуры общего назначения, не учитывающей индивидуальные особенности экспериментов на БАКе, то дополнительно разрабатывались программные надстройки над EMI/gLite и OSG (BigPanDA — система управления заданиями, Rucio — управление большими объемами распределенных данных, DIRAC (diracgrid.org) — управление распределенными ресурсами), оптимизирующие распределенные вычисления под структуру, потоки и процедуры обработки данных конкретного эксперимента. Некоторые из этих надстроек в определенный момент стали обладать функциональностью, полностью заменяющей отдельные сервисы EMI/gLite и OSG.

Кажущееся естественным и логичным применение инструментария WLCG для решения задач, поставленных в эксперименте BES-III, на практике сопряжено с рядом трудностей. В условиях эксперимента BES-III основной проблемой стала нехватка специалистов, которые должны быть во всех ресурсных центрах распределенной инфраструктуры. Для обычного системного администратора установить и сконфигурировать должным образом все необходимые для функционирования ресурсного центра сервисы на базе программного обеспечения WLCG — довольно непростая задача. Организация слаженной работы нескольких подобных ресурсных центров без выделения постоянно действующей высококвалифицированной команды технической поддержки практически невозможна.

Кроме того, поскольку инструментарий WLCG не учитывает индивидуальные особенности эксперимента BES-III, потребуется дополнительно создать программную надстройку над сервисами WLCG, которая будет оптимизировать запуск задач и обработку данных под специфические нужды эксперимента. Для этого также необходима квалифицированная команда разработчиков.

Другим подходом может быть создание грид-системы на основе отдельных независимых компонентов, взятых из различных проектов, включая WLCG. Например, аутентификацию и авторизацию пользователей можно реализовать с помощью сервиса управления пользователями виртуальных организаций из инструментария EMI, а распространение программного обеспечения эксперимента организовать на базе файловой системы CernVM File System. Однако для объединения всех сервисов в единую систему неизбежно потребуется разработка дополнительного ПО, которое возьмет на себя функции координации запуска задач и передачи данных и одновременно будет учитывать особенности эксперимента BES-III. На первый взгляд, эта задача проще, чем использование готового инструментария WLCG, но выяснилось, что значительную часть требуемой функциональности можно относительно легко реализовать на базе инфраструктуры DIRAC (Distributed Infrastructure with Remote Agent Control).

DIRAC возникла в рамках эксперимента LHCb (Large Hadron Collider beauty) на БАКе и со временем превратилась из надстройки над сервисами WLCG в самостоятельное решение для организации распределенных вычислительных инфраструктур. Модульная организация системы позволяет достаточно быстро адаптировать и расширять DIRAC для использования в различных задачах [3–5].

Система написана на языке Python и имеет модульную структуру (см. рисунок), состоящую из базовых сервисов и расширений, дополняющих функциональность в соответствии с требованиями конкретного проекта. Развитый программный интерфейс дает возможность как создавать новые модули в рамках существующей архитектуры, так и интегрировать DIRAC со сторонними приложениями. Важной особенностью является наличие полнофункционального и расширяемого веб-интерфейса, позволяющего получить доступ к возможностям DIRAC и осуществлять администрирование системы при помощи обычного браузера.

Архитектура DIRAC

В базовой части DIRAC реализованы функционал авторизации и аутентификации, информационная система, а также механизмы управления задачами и файлами. DIRAC предоставляет интерфейсы к различным типам вычислительных элементов, кроме того, существует возможность запуска задач через ssh-туннель, что позволяет обойтись вообще без установки системы управления заданиями на удаленном узле. В DIRAC поддерживается большинство систем хранения данных, реализован встроенный каталог файлов и используется система передачи файлов из EMI/gLite. Важной особенностью DIRAC является наличие интерфейсов к облачным ресурсам на базе Amazon EC2, OpenStack, OpenNebula, а также к платформе гридов поддержки добровольных распределенных вычислений BOINC. Также следует отметить большое и активное сообщество пользователей DIRAC, которое при хорошей поддержке со стороны разработчиков позволяет достаточно оперативно находить решения для большинства возникающих проблем и неполадок.

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

В DIRAC имеется система мониторинга, осуществляющая контроль состояния центральных системных сервисов, но в случае распределенной инфраструктуры с ограниченной технической поддержкой на местах требуется более детальный и развитый мониторинг как удаленных ресурсных центров, так и функционирования системы в целом, включая автоматический контроль работоспособности всех сервисов. Наконец, система управления данными позволяет эффективно работать с отдельными файлами, но начинает сбоить, если число файлов становится слишком велико, а данные имеют достаточно сложную структуру. В этом случае становится удобным объединение файлов в логически связанные наборы данных (dataset), при этом все операции (копирование, перемещение и удаление) выполняются с набором данных как с единым целым.

Несмотря на перечисленные недостатки, применение DIRAC позволило успешно организовать и ввести в эксплуатацию систему распределенных вычислений для эксперимента BES-III. Центральные сервисы полностью продублированы в ИФВЭ и ОИЯИ, что повышает надежность работы системы при сбоях в сети и во время процедуры обновления DIRAC. Значительный прогресс достигнут в задаче использования облачных ресурсов в качестве вычислительных элементов.

***

В данный момент инфраструктура распределенной обработки данных BES-III включает в себя девять ресурсных центров из КНР, США и России, на которых с 2013 года было выполнено более 350 тыс. задач моделирования и обработано 250 Тбайт данных. В качестве вычислительных элементов ресурсных центров в основном используются кластеры стандартной архитектуры. Задачи также запускаются на облачных инфраструктурах Туринского университета (Италия), Университета Сучжоу (КНР) и ОИЯИ (Россия) на платформах OpenStack и OpenNebula. Опыт работы с DIRAC будет полезен для других проектов сравнимого масштаба, в которых планируется распределенная обработка данных.

Литература

1. M.Ablikim et al. Design and Construction of the BESIII Detector. Nucl. Instrum. Meth. A614 (2010), P. 345–399.
2. Владимир Кореньков, Александр Ужинский. Архитектура сервиса передачи данных в grid // Открытые системы.СУБД. — 2008. — № 2. — С. 52–56. URL: http://www.osp.ru/os/2008/02/4926522 (дата обращения 20.12.2014).
3. L. Arrabito et al. Application of the DIRAC framework to CTA: first evaluation // J. Phys.: Conf. Ser. 396 032007
4. R. Graciani et al. Belle-DIRAC Setup for Using Amazon Elastic Compute Cloud // J. Grid Comp. Vol. 9, Issue 1 (2011), P. 65–79
5. V. Mendez et al. Powering Distributed Applications with DIRAC Engine // The International Symposium on Grids and Clouds (ISGC) 2014, March 23–28, 2014, Academia Sinica, Taipei, Taiwan.

Сергей Белов (belov@jinr.ru) — ведущий программист, Игорь Пелеванюк (gavelock@gmail.com) — инженер-программист, Александр Ужинский (auzhinskiy@jinr.ru) — ведущий программист, Объединенный институт ядерных исследований (Дубна). Работа проводится при поддержке РФФИ (грант 14-07-91152 ГФЕН_а).