В текущем году в ЦЕРН (Швейцария) планируется запуск в тестовом режиме большого адронного коллайдера (LHC, Large Hadron Collider) — самого крупного в мире ускорителя элементарных частиц. Ежегодно в рамках этого проекта будет генерироваться около 15 Пбайт данных. Когда ускоритель заработает в нормальном режиме, более чем 5 тысячам ученым из 500 исследовательских институтов и университетов со всего мира потребуется обеспечить доступ к экспериментальным данным. Анализ экспериментальных данных, включая их сравнение с моделированными данными, потребует огромных вычислительных мощностей, и для этого в рамках проектов EGEE (Enabling Grids for E-sciencE), WLCG (Worldwide LHC Computing GRID) и OSG (Open Science Grid) разрабатывается модель хранения и обработки данных на базе grid-технологий.
Наиболее сложная проблема, с которой пришлось столкнуться при реализации данных проектов, состоит в обеспечении надежной и эффективной передачи огромных массивов данных между региональными центрами, которые готовятся к обработке и анализу информации с ускорителя LHC. Одно из решений — сервис передачи данных FTS (File Transfer Service), система мониторинга которого разработана в результате сотрудничества ОИЯИ, НИИЯФ МГУ и ЦЕРН.
В проекте WLCG решаются вопросы построения распределенной иерархической архитектуры системы региональных центров, где и будет храниться и обрабатываться информация с ускорителя. Основная задача проекта EGEE, тесно связанного с WLCG, — организация мировых компьютерных ресурсов в единую однородную среду, где ими можно было бы пользоваться совместно. Главный пользователь инфраструктуры EGEE — это сообщество ученых, занимающихся физикой высоких энергий, поэтому упомянутые проекты часто объединяют, а интегрированную инфраструктуру называют EGEE/WLCG.
В рамках проекта EGEE разрабатывается промежуточное программное обеспечение gLite, основными строительными блоками которого являются grid-сервисы, необходимые конкретным пользователям и виртуальным организациям, выполненные в сервисной архитектуре (Service Oriented Architecture, SOA) на базе Web-сервисов, удовлетворяющих спецификации WS-I (Web Services Interoperability). Все сервисы gLite разделены на шесть групп, в зависимости от решаемых задач:
- Helper Services — информационная поддержка пользователей (Configuration & Instrumentation Service, Agreement Service, Bandwidth Allocation & Reservation Service);
- Grid Access — инструменты для взаимодействия с CLI (Command Line Interface) и API (программный интерфейс приложений);
- Security Services — безопасность (Authorization, Authentication, Auditing, Dynamic Connectivity);
- Information & Monitoring Services — предоставление информации о функционировании систем (Information & Monitoring, Job Monitoring, Network Monitoring, Service Discovery);
- Data Services — управление данными (Meta Catalog, File & Replica Catalog, Storage Element, Data Movement);
- Job Management Services — управление заданиями (Accounting, Job Provenance, Package Manager, Computer Element, Workload Management).
Сервис управления данными — один из важнейших в gLite. В проекте EGEE/WLCG используются три системы хранения данных: Castor, dCache и DPM (www.gridpp.ac.uk/wiki/Disk_Pool_Manager), для взаимодействия с которыми разработан специальный сервис SRM (Storage Resource Manager) (www.gridpp.ac.uk/wiki/SRM). За перемещение данных на физическом уровне отвечает GridFTP (dev.globus.org/wiki/GridFTP) — протокол, разработанный в рамках проекта Globus (www.globus.org). Таблицы соответствия между первоначальными названиями файлов (Logical File Name, LFN), уникальными идентификационными номерами (Glbally Unique Identifier, GUID) и названиями файлов на конкретных сайтах (Site URL, SURL) хранятся в каталоге LCG File Catalog (www.gridpp.ac.uk/wiki/LCG_File_Catalog), объединяющем в себе функции файлового каталога и каталога реплик. Для обеспечения необходимой надежности, производительности и организации взаимодействия между остальными сервисами управления данными был создан сервис передачи данных — FTS (File Transfer Service), основные обязанности которого: обеспечение надежных и удобных механизмов передачи файлов типа «точка-точка», контроль и мониторинг передач, распределение ресурсов сайта между различными организациями, управление запросами пользователей. Ежедневно с помощью FTS между различными сайтами передаются десятки тысяч файлов, а объемы составляют десятки терабайт в день. Только в российские центры за последние четыре месяца было передано более 140 Тбайт данных.
Структура FTS
Сервис FTS используют приложения, разрабатываемые для конкретных экспериментов, конечные пользователи крайне редко взаимодействуют с ним напрямую. Типичная задача FTS выглядит как набор пар «файл на сайте источнике — файл на сайте назначения». FTS позволяет: задавать правила использования ресурсов сайта в соответствии с политиками сайтов и виртуальных организаций; предотвращать перегрузку сетей и хранилищ данных; отслеживать общую ситуацию и получать комплексную информацию об ошибках, возникающих во время работы сервиса. Данный сервис призван обеспечить надежный механизм передачи файлов типа «точка-точка», предоставить удобный способ распределения ресурсов между экспериментами, а также различные возможности мониторинга и контроля для администраторов сайтов; предоставить возможность контролировать запросы, поступающие со стороны пользователей, устанавливать последовательность их исполнения, а также ранжировать их по приоритетности для менеджеров виртуальных организаций.
FTS состоит из ряда отдельных компонентов (рис. 1), взаимодействующих только с центральной базой данных на платформе Oracle.
Рис. 1.
Единственный компонент, с которым взаимодействуют пользователи, — Web-сервис. Посредством командной строки либо через собственный скрипт, использующий стандартные интерфейсы, пользователь имеет возможность запускать задачи и отслеживать их состояние. Множество пользователей подключаются к Web-сервису по безопасному соединению через протокол SOAP.
Web-сервис (FTS Web Service) реализован на основе Tomcat, а с помощью WSDL пользователи могут написать собственное приложение для взаимодействия с сервисом на удобном для них языке программирования. Может существовать множество контейнеров Tomcat для взаимодействия с одной и той же базой данных. Подключение к базе осуществляется через JDBC с помощью Tomcat database connection pool.
FTS Database — реализация схемы данных FTS в Oracle. Сервис поддерживает работу только с одной базой.
Агенты каналов (Channel Agent) отвечают за инициализацию и контроль передачи данных. В FTS иерархическая схема объектов выглядит следующим образом. Существует запускаемая пользователем задача, содержащая от одного до N файлов, для каждого из которых будет инициализирована одна или несколько, при возникновении сбоев и в соответствии с политикой повторных попыток, передач. Также агенты каналов отвечают за распределение ресурсов канала между различными виртуальными организациями (Virtual organization, VO).
Агенты виртуальных организаций (VO Agent) отвечают за управление запросами на передачу данных от определенных виртуальных организаций. В самом общем случае это авторизация передачи, а затем направление ее в очередь на подходящий канал. Агенты могут выполнять специфические для каждой VO операции, определять приоритеты, политики повторных передач при возникновении сбоев и т.д. Для улучшения производительности рекомендуется, чтобы агенты виртуальных организаций и агенты каналов были размещены на разных машинах.
Monitoring Tools — предоставление информации о функционировании сервиса.
При работе FTS используется MyProxy Server для получения или обновления пользовательских сертификатов, необходимых при передаче файлов.
Общая схема взаимодействия элементов сервиса FTS представлена на рис. 2.
Рис. 2.
При отказе одного или нескольких элементов данной схемы работоспособность FTS изменится следующим образом: FTS Web Service — деградация сервиса, новые задачи не поступают, но запущенные ранее продолжают исполняться; FTS Database — полная неработоспособность сервиса; VO Agents — новые задачи не доходят до агентов каналов, запущенные ранее работают в нормально режиме. Channel Agents — новые задачи поступают, но передачи не производятся. Monitoring System — работоспособность сервиса не затронута, но отсутствует большая часть информации о его функционировании. MyProxy Server — деградация сервиса по истечении нескольких часов, когда пользовательские сертификаты не смогут быть обновлены. Наиболее уязвимым элементом при подобной организации сервиса является FTS Database, вследствие чего требования к физическому оборудованию и программному обеспечению на узлах, где он установлен, весьма велики.
FTS-канал
FTS-канал — логический элемент управления очередью транспортных задач. Как только задача запускается, в соответствии с начальной и конечной точкой назначения, она направляется на наиболее подходящий канал, определенный на сервере. Структура FTS-каналов может не иметь никакого отношения к физической топологии сети, канал — это логическая единица. Все транспортные задачи на одном и том же канале находятся в единой очереди. Существует возможность «поделить» канал между виртуальными организациями, выделяя каждой определенную долю канала (например, если VO Atlas получит 75% ресурсов канала, то на все остальные организации останется 25%, которые при отсутствии прочих условий будут поделены между ними поровну). В свою очередь, виртуальные организации могут использовать механизм приоритетов для управления очередью задач.
В настройках канала можно указать метод передачи файлов: gridftp или srmcopy. Каждый канал имеет набор специальных параметров, влияющих на производительность: количество передаваемых конкурентных файлов, количество потоков, размер TCP-буфера и т.д. Существует возможность задать максимальное количество передач, ведущихся одновременно на один и тот же элемент хранения, что является удобным механизмом контроля нагрузки.
FTS-каналы однонаправлены, и если требуется организовать двунаправленную связь между сайтами, то создаются два канала — Site1 to Site2 и Site2 to Site1. Существует возможность создать каналы типа Site1 to All и All to Site1, которые будут использованы в случае, когда не определен конкретный канал между двумя сайтами. Однако «конкуренция» между задачами на подобных каналах очень высока. Каналы должны быть определены на всех сайта, где установлен FTS.
В рамках проекта WLCG была разработана модель распределенного хранения и обработки данных с ускорителя LHC. В соответствии с данной моделью в Tier-0 (ЦЕРН) будет производиться первичная реконструкция событий, калибровка и хранение копий полных баз данных. В Tier-1 (крупных региональных центрах) будет производиться полная реконструкция событий, хранение актуальных баз данных по событиям, создание и хранение наборов анализируемых событий, моделирование и анализ. В Tier-2 (небольших региональных центрах) будет производиться репликация и хранение наборов анализируемых событий, моделирование и анализ.
FTS не устанавливается на сайтах Tier-2 — ответственность за проведение передач с их участием лежит на ассоциированном с ними сайте Tier-1. Подобная схема позволяет осуществлять управление глобальной инфраструктурой из крупных региональных центров, не загружая администраторов небольших центров дополнительной работой.
В FTS имеется три основных уровня (роли) безопасности: обычный пользователь, который может запускать задачи и получать информацию об их состоянии; менеджер виртуальной организации, который может получать список всех передач для его виртуальной организации, менять приоритетность задач, задавать политику повторных передач и т.д; менеджер каналов, который может менять состояние канала, изменять доли ресурсов канала между виртуальными организациями, получать список всех передач на канале и т.д. Две последние роли должны быть определены для каждого канала.
Удобный механизм управления ресурсами является несомненным плюсом FTS — все больше организаций предпочитают использовать сторонние инфраструктуры для хранения и обработки информации. При подобной организации вопросы рационального управления и распределения ресурсов выходят на первый план.
Схемы взаимодействия FTS
Для функционирования сервиса управления данными в проекте EGEE/WLCG на каждом сайте должна быть установлена система хранения данных Castor, dCache или DPM, а также SRM (Storage Resource Manager) — протокол, используемый для управления системами хранения, основной обязанностью которого является подготовка файла для транспортировки либо создание места на диске для последующей записи файла. За перемещение данных на физическом уровне отвечает GridFTP — протокол, разработанный в рамках проекта Globus.
В зависимости от настроек FTS может взаимодействовать с SRM и GridFTP, либо только с SRM.
На начальном этапе передачи сервису известны адреса SRM и названия файлов на сайте назначения и сайте- источнике, а затем опрашивается SRM на сайте-источнике; опрашивается SRM на сайте назначения; подготавливается файл на сайте источнике, используя интерфейсы SRM; готовится файл на сайте назначения; инициализируется передача «url to url» по протоколу GridFTP; проверяется файл на сайте назначения; завершаются все работы с файлом на сайте-источнике; завершаются все работы с файлом на сайте назначения. В случае использования варианта взаимодействия SRM copy, FTS не контактирует с GridFTP, за это отвечает SRM на сайте-источнике.
Система мониторинга FTS
Обработка ошибок, возникающих при передаче данных в различных приложениях, является прямой обязанностью FTS. Кроме того, мониторинг способен предоставить информацию о функционировании сервиса, его производительности, нестандартных ситуациях и прочих «узких» местах.
До недавнего времени набор средств мониторинга FTS позволял получать следующую информацию: анализ объемов данных на каналах, посредством системы GridView; отчет о проценте ошибок по каналам за прошедший день и неделю FTS Repport (fts102.cern.ch/ftsstats/prod-fts-ws/index.html); данные о текущем состоянии системы (агентах, настройках каналов и т.д.). Значительный спектр вопросов о функционировании системы оставался за кадром, и зачастую информация о проблемах на каналах приходила с большим опозданием. После создания системы мониторинга Spider появилась возможность отображать информацию об ошибках, возникающих на каналах передачи данных.
Первая версия системы обрабатывала лог-файлы с серверов, на которых установлены «агенты передач» (transfer–agent), и размещала информацию в базе данных MySQL, после чего она была доступна через Web-интерфейс.
Система имеет средства выбора каналов, временных интервалов и видов представления результата. Она содержит несколько модулей, формирующих различные отчеты: количество всевозможных ошибок на каналах; количество определенных ошибок на различных каналах; сведения о наиболее распространенных ошибках на сайтах за определенный временной интервал с учетом порога чувствительности и т.д. Система сейчас активно используется в ЦЕРНе для поддержания работоспособности FTS-каналов и уже позволила выявить ряд программных ошибок в различных приложениях.
За время эксплуатации системы было выделено более 350 шаблонов ошибок. Употребление здесь слова «шаблон» вызвано тем, что большинство сообщений об ошибках содержат персонифицированную информацию — дату, название файла, атрибуты пользователя и т.д., что повлекло за собой необходимость применения механизма паттернов — устойчивых частей, однозначно характеризующих конкретную ошибку. Была разработана и внедрена методология категоризации ошибок, предоставляющая различные уровни детализации.
На основании накопленного опыта предложена концептуальная стратегия развития средств мониторинга для FTS: все компоненты должны разрабатываться в соответствии с классификацией ошибок FTS; агрегирование и визуализация информации должны предоставлять возможность точного определения причин и мест возникновения проблем; должна существовать возможность работы с различными уровнями детализации; все вычисления должны производиться в базе данных; агрегированная для различных отчетов информация должна храниться в базе данных. Организация системы мониторинга, при которой наборы данных, агрегированная информация и функции для работы с ними хранятся непосредственно в базе данных, является оптимальной, поскольку предоставляет удобные и стандартизованные пути публикации информации, а также создания и изменения интерфейсов.
В соответствии с данной стратегией и опираясь на пожелания пользователей, была разработана новая система мониторинга, объединяющая в себе функциональность уже существующих систем и работающая непосредственно с базой FTS. Отличительные черты новой системы: предоставление информации как о конкретных ошибках, так и о категориях (FTS category); наличие четырех различных групп пользователей (операторы FTS, администраторы сайтов, менеджеры виртуальных организаций, управленческий персонал); пять групп отслеживаемых объектов (каналы, сайты, хосты, ошибки, VO); предоставление обобщенной информации о каналах и VO — количество удачных/неудачных передач/задач, количество ошибок на сайте источнике, сайте назначения, в процессе передачи и т.д.; механизм оповещения (Alarm mechanism); информация о настройках и состоянии агентов и каналов.
Данная система допускает возможность добавления различных отчетов, параметров и триггеров оповещения. Удобным средством управления является конструктор триггеров оповещения, используя который, конкретный администратор может облегчить свою работу. Выбрав объект, тип триггера и уровень либо процент ошибок, администратор будет получать оповещения при его срабатывании в виде электронных сообщений, SMS либо непосредственно через Web-интерфейс. Логичным развитием данной технологии представляется расширение возможностей ответных действий триггеров, например, при обнаружении 100% неудачных передач у одной из VO на канале, триггер может не только высылать оповещение, но и уменьшать квоты для данной VO, снижая нагрузку на канал и предоставляя больше возможностей для других VO.
Подобный механизм способен значительно облегчить адаптацию системы под конкретную структуру: потратив некоторое время на создание и отладку наборов правил, администратор получит саморегулирующуюся систему, реагирующую на различные изменения в соответствии с принятыми в заинтересованных организациях представлениями о безопасности, производительности и надежности.
Основные области возникновения ошибок
За время работы с системой Spider были не только выявлены и классифицированы конкретные ошибки выполнения сервиса FTS, но и определены основные области их возникновения: таймауты, программные ошибки, специфические ошибки приложений и ошибки пользователей.
Для программных ошибок существует метод отслеживания развития ошибок на сайтах со схожим программным обеспечением — возникновение одинаковых сбоев на подобных сайтах должно стать сигналом для организации подробного расследования. Специфические ошибки приложений представляют собой сбои, возникающие при логическом взаимодействии различных приложений. Например, большая нагрузка на Castor приводит к возникновению ошибки Device or resource busy. Исправить подобные ошибки программно невозможно, и единственное правильное направление деятельности в данной области — уменьшение числа таких ошибок путем своевременного реагирования на их появление.
Ошибки пользователей возникают при указании неправильных данных в параметрах задачи: названия файлов, путей и т.д., либо при отсутствии у пользователя необходимых прав.
Сбои, возникающие из-за таймаутов, — наиболее сложная область. Основная задача механизма таймаутов состоит в выявлении неработоспособных элементов и предотвращении возникновения чрезмерных очередей, поэтому определение оптимальных таймаутов, при которых система будет сохранять свою функциональность и при этом не терять производительность, — сложная и кропотливая работа, которой приходится заниматься администраторам как конкретных узлов, так и глобальных сервисов. Пожалуй, единственный способ достичь положительных результатов в данном направлении — это постоянные эксперименты, тесное взаимодействие всех вовлеченных сторон и своевременное реагирование на изменения в глобальной инфраструктуре.
***
FTS — активно развивающийся grid-сервис, на который возложены очень важные задачи в проекте EGEE/WLCG. Аналогом FTS является разрабатываемый в рамках проекта Globus сервис Reliable File Transfer, однако его возможности в плане управления и организации взаимодействия между элементами datagrid не столь широки. Кроме физики высоких энергий подобные решения могут быть использованы и в других областях науки, использующих datagrid: в астрономии — обработка и анализ данных от различных телескопов со всего мира (National Virtual Observatory US, Australian Virtual Observatory, European Astrophysical Virtual Observatory, AstroGrid); в био-информатике — моделирование процесса сворачивания белка, лечение рака, анализ мозговой активности и структуры ДНК (BioGrid, eDiaMoND, The Scottish, BioInformatics Research Network); в науке о земле — моделирование климата, исследования в области океанографии, прогнозирование землетрясений (NEESgrid, Earth Systems Grid). На данный момент неизвестны случаи использования данных технологий в бизнес-приложениях, однако опыт вычислительных grid-систем и распределенных баз данных, за которые всерьез взялись такие компании, как IBM, Oracle и SAP, показывает, что любые области, где существует необходимость хранения, обработки и репликации больших объемов данных, должны быть готовы взять подобные технологии на вооружение.
Владимир Кореньков (korenkov@cv.jinr.ru) — заместитель директора Лаборатории информационных технологий ОИЯИ, Александр Ужинский (Alexander.Uzhinskiy@cern.ch) — инженер-программист ОИЯИ (Дубна).
Российский сегмент глобальной инфраструктуры LCG
Российские институты по физике высоких энергий активно участвуют в проекте Большого адронного коллайдера - крупнейшего международного эксперимента в области физики элементарных частиц.
Вячеслав Ильин, Владимир Кореньков, Алексей Солдатов
