статья - Институт физики высоких энергий

Краткая производственная автобиография
Сайженкова Софья Сергеевна поступила на работу в ИФВЭ в 2006г. после окончания
Международного университета «Дубна» (филиал «Протвино») по специальности инженерпрограммист.
За
короткий
срок
она
самостоятельно
освоила
учёт
потребления
ресурсов
пользователями. Имеет три печатные работы, представленные на Международных симпозиумах
в 2007, 2008 и 2010 годах.
В
круг
основных
обязанностей
Сайженковой
С.С.
входит
администрирование
распределенной иерархической системы хранения данных CASTOR, полученных в результате
физических экспериментов: обеспечение его бесперебойной работы;
обработка запросов
экспериментов, связанных с добавлением новых ленточных носителей или заведением новых
пользователей.
Также в обязанности Сайженковой С.С. входят:
обеспечение внутреннего учёта потребления ресурсов пользователями вычислительного
грид-кластера ИФВЭ;
мониторинг состояния работы дисковых RAID массивов – элементов хранения данных
для Грид;
своевременное обнаружение сбойных дисков, их замена, восстановление массивов
данных после сбоя;
администрирование дисковых пулов, входящих в Storage Elements на Грид сайте ИФВЭ.
За время работы Сайженковой С.С. были проделаны работы по адаптации системы учёта
потребления ресурсов пользователями грид-кластра для инфраструктуры ИФВЭ, установке и
настройке специализированных систем мониторинга работоспособности дисковых устройств в
RAID массивах, создание программы мониторинга запуска задач на кластере, а также она
написала ряд плагинов для системы мониторинга Nagios.
В настоящее время Сайженкова С. С. занимается изучением возможности создания
PROOF-кластера на базе Грид-сайта ИФВЭ.
В 2008 и в 2009 годах Сайженкова С. С. была командирована в CERN, где работала в ITотделе, в группе GRID Deploytment, а также сотрудничала с экспериментом ATLAS, выполнив
ряд задач по установке и настройке специализированного ПО.
За время работы Сайженкова С.С. зарекомендовала себя грамотным, квалифицированным
и ответственным специалистом, умеющим работать в команде, а также инициативным и
умеющим самостоятельно принимать решения человеком.
PROOF кластер и GRID технологии
I Что такое PROOF
PROOF - Parallel ROOT Facility.
ROOT – это объектно-ориентированное программное обеспечение, нацеленная на
решение проблем анализа данных физики высоких энергий.
PROOF – это надстройка ROOT, позволяющая интерактивный анализ больших наборов
ROOT файлов параллельно на кластере, состоящем из мультипроцессорных машин. PROOF
может распараллелить класс задач, решение которых может быть выполнено как набор
независимых подзадач.
PROOF, прежде всего, предназначен как альтернатива batch системе для центральных
средств анализа на сайтах Tier-2 и Tier-3 в экспериментах физики элементарных частиц. Однако,
благодаря многоуровневой архитектуре, позволяющей создать иерархию из мастер нодов, это
может быть легко адаптировано к широкому диапозону виртуальных кластеров географически
распределённых между доменами и гетерогенными машинами (GRID).
Клиентом системы является пользователь, который хочет использовать ресурсы сайта,
чтобы выполнить свою задачу. Master – это точка входа к вычислительному средству: он
разбирает запросы клиента, это распределяет работу между ресурсами, собирает и соединяет
результаты.
PROOF кластер – это набор машин, работающих скоординировано благодаря PROOF
протоколу. Часть этих машин (обычно одна или две) должны играть роль мастера; остальные –
рабочих узлов.
Пользователь, работая в сессии программы ROOT, может запускать процессы, которые
связываются с PROOF кластером и подают запросы на обработку заданий.
Получив запрос на обработку задания, на мастере и на каждом рабочем узле стартует
специальное ROOT приложение – proofserv - для каждой сессии пользователя. Процесс
на
масетер координирует работу между рабочими узлами и соединяет результаты в единое целое.
На рабочих узлах процесс
переменные.
proofserv делает актуальную работу, обрабатывает отдельные
Рис. 1 Архитектура PROOF системы
II Для чего нужен PROOF кластер на GRID сайте ИФВЭ
Сегодня эксперименты физики высокой энергии производят чрезвычайно большие
объемы данных, которые должны быть сохранены и далее обработаны. Нужны сильные, но все
же не сложные инструменты, позволяющие обработать большие объемы данных в разумный
срок. Единственный способ достигнуть этого состоит в том, чтобы использовать врожденный
параллелизм данных физики высоких энергий и следовательно обрабатывает параллельно
различные части образцов данных.
Традиционный путь, как приблизиться к этому, состоит в том, чтобы использовать batch
систему, которая основывается на том, что задачи разделены на несколько подзадач заранее.
Продолжительность всего выполнения ограничена временем выполнения самой медленной
подзадачи, которая приводит к существенному продлению времени обработки в случае
неблагополучного узла или последовательнго представления некоторых подзадач. Другие
слабые места традиционных batch систем например, обратная связь в реальном времени и
использование мультиядерных машин.
Проект под названием Parallel ROOT Facility (PROOF) стартовал в 1997 как дополнение к
ROOT . Это задумывалась как альтернатива batch системам, работающим на Tier-2’s and Tier-3’s
сайтах. PROOF построен на принципе распаралеливания задач. Мастер распределяет работу
между узлами, а те в свою очередь запрашивают новые задачи, после того, как закончат
обработку предыдущих. В конце мастер сеодиняет все подзадачи в один результат.
Один из главных экспериментов, который уже давно и успешно работает с PROOF это
ALICE. Эксперимент использует PROOF предпочтительно для быстрого анализа данных о
столкновениях протонов и экспериментального анализа тяжелых ионов. PROOF кластер ALICE
имеет 500 CPU’s и 100 TB для пользователей ALICE. Кластер не ставит своей целью заменить
Grid для анализа, но обеспечивает быстрый доступ к данным, чем ускоряет цикл обработки и
анализа задач физики высокой энергии.
Установить PROOF кластер также планируется на GRID сайте Санкт-Петербургского
государственного университета, о чём было заявлено на междунаржной конференции GRID2010
в Дубне. То есть работа в этом направлении ведётся и в других научных институтах.
Любой GRID сайт сталкивается с проблемой продуктивности, когда необходимо
постоянно увеличивать вычислительные мощности сайта, чтоб он справлялся с возлагаемыми на
него задачами. Есть два пути решения: первый – это увеличивать “железо”, постоянно
наращивать и увеличивать кластер. А второй способ увеличить продуктивность сайта – это
“программный” способ, то есть настроить программное обеспечение, которое использовало бы
вычислительные мощности сайта более рационально. Именно это и делает PROOF кластер,
который, во-первых, расспаралеливает задачи, во-вторых, на каждом отдельном узле можно
настроить сколько процентов процессорной мощности отдаётся под PROOF сессии и тем самым
сбалансировать выполнение PROOF задач и GRID задач. Для нашего сайта это особенно важно,
так как гридовские пользователи и локальные пользователи института разделены.
III Установка, настройка и работа PROOF кластера на GRID сайте ИФВЭ
Необходимо
скачать
исходники
с
официального
сайта
root.cern.ch:
root_<version>.source.tar.gz. Затем надо распаковать архив, изменить конфигурационные файлы и
выбрать способ установки.
После разархивации скаченного архива переходим в папку, где содержатся исходники и
редактируем конфигурационные файлы.
В первом <директория_где_установлен_root>/etc/proof/proof.conf прописываем машину
мастер и все рабочие ноды:
master <hostname>
worker <hostname>
worker <hostname>
....
Во
втором
конфиг
файле
<директория_где_установлен_root>/etc/proof/xpd.cf
прописываем пути до необходимых библиотек libXrdProofd.so и libXrdOfs.so в части Part one:
data serving. Также указываем путь до конфиг файла proof.conf в третьей части Part three: enable
PROOF serving. В директиве xpd.schedparam указываем тип очереди, который хотим применить
и количество одновременных сессий queue:fifo mxrun:1. На Грид сайте ИФВЭ используется
очередь first input first output и одна одновременная сессия.
Также в файле, запускающем демона xrootd необходимо прописать ряд переменных,
таких как:
export ROOTSYS=<place_where_root_is_installed>
export PATH=$PATH:$ROOTSYS/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ROOTSYS/lib/root/5.26
Далее выбираем способ установки.
Существует два способа устновки ROOT. Первый способ - это собрать ROOT из
исходников.
Второй способ – это собрать Debian GNU/Linux или Redhat Linux пакеты и
устанавливать ROOT уже из пакетов. Был выбран второй способ установки с помощью rpm
пакетов, т. к. Грид сайт содержит десятки нодов, на которые необходимо установить это
программное обеспечение. Необходимо было автоматизировать этот процесс.
В папке, где содержатся исходники выполняем команду:
make redhat
Эта команда создаёт RPM spec файл с именем root.spec.
В файле root.spec делаем необходимые попроавки для своего случая: указываем версию
релиза, директории в которых будет собираться и куда ставиться rpm-пакет и выбираем
возможности, с которыми должен конфигурироваться наш proof.
Создаём файл ~/.rpmmacros где мы будем собирать rpm пакет:
%_topdir <some where you can write>/redhat
%_sourcedir %{_topdir}/SOURCES
%_specdir %{_topdir}/SPECS
%_builddir %{_topdir}/BUILD
Затем создаём сами директории:
mkdir <some where you can write>/SOURCES
mkdir <some where you can write>/BUILD
mkdir <some where you can write>/RPMS
mkdir <some where you can write>/SRPMS
mkdir <some where you can write>/SPECS
и наконец копируем архив с исходниками:
cp root_v<version>.source.tar.gz \ <some where you can write>/SOURCES
Чтобы собрать пакет запускаем команду:
rpmbuild -ba <some where you can write>/SPECS/root.spec
В итоге в папке <some where you can write>/RPMS мы имеем два rpmпакета:
libroot-static-<version>-<release>.x86_64.rpm
root-system-<version>-<release>.x86_64.rpm
Эти два пакета устанавливаем намастер и каждый нод в кластере. Вначале libroot-static<version>-<release>.x86_64.rpm, затем root-system-<version>-<release>.x86_64.rpm.
Далее на всех машинах запускаем демон xrootd. При успешном запуске в лог файле
должно появиться следующее сообщение: initialization completed.
Демон проверяет наличие обращений пользователей (не открыта ли какая-либо сессия)
каждые 30 секунд.
После прохождения регистрации и получения пароля, который пользователь вводит
только один раз самый первый, он может начать работу на PROOF кластере. Сначала
запускается стандартная среда ROOT, а затем уже идёт соединение с PROOF кластером.
В данный момент на PROOF кластере ИФВЭ один мастер и 60 рабочих узлов.
IV Перспективы этой работы в рамках научно-технической программы
ИФВЭ
Проект PROOF постоянно развивается и не стоит на месте. Регулярно выходят новые
версии этого программного обеспечения с новыми интересными возможностями.
В данный момент на GRID сайте ИФВЭ ведутся работы по переходу на керберос 5 и
создания удобной системы мониторинга за задачами, запущенными на PROOF кластере.
V Печатная работа представленная на 4th International Conference
"Distributed Computing and Grid-technologies in Science and Education"
June 28 - July 3, 2010 Dubna, Russia
INSTALLATION AND SETUP PROOF CLUSTER ON GRID SITE
Sayzhenkova S. S.
Institute for High Energy Physics
Russia
142280, Moscow region, Protvino, Pobeda st. 1
8 (4967) 74-74-13
Sofia.Sayzhenkova@ihep.ru
PROOF - Parallel ROOT Facility.
ROOT is an object-oriented framework aimed at solving the data analysis challenges of high-energy
physics.
The Parallel ROOT Facility, PROOF, is an extension of ROOT enabling interactive analysis of large
sets of ROOT files in parallel on clusters of computers or many-core machines. More generally PROOF can
parallelize the class of tasks the solution of which can be formulated as a set of independent sub-tasks.
PROOF is primarily meant as an alternative to batch systems for Central Analysis Facilities and
departmental work groups (Tier-2’s and Tier-3’s) in particle physics experiments. However, thanks to a multi-tier
architecture allowing multiple levels of masters, it can be easily adapted to a wide range of virtual clusters
distributed over geographically separated domains and heterogeneous machines (GRIDs).
Apart from the pure interactive mode, PROOF has also an interactive-batch mode. With interactivebatch the user can start very long running queries, disconnect the client and at any time, any location and from
any computer reconnect to the query to monitor its progress or retrieve the results. This feature gives it a distinct
advantage over purely batch based solutions, that only provide an answer once all sub-jobs have been finished
and merged.
Pic 1. Multi-Tier Master-Worker Architecture
The PROOF system implements a multi-tier architecture as shown in the figure.
The client is the user that wants to use the resources to perform a task. The master is the entry point to
the computing facility: it parses the client requests, it distributes the work to the workers, it collects and merges
the results. The master tier can be multi-layered. This allows, for example, to federate geographically separated
clusters by optimizing the access to auxilliary resources, like mass storages. It also allows to distribute the
distribution and merging work, which may become the bottle-neck in the case of many workers.
The purpose of my work is to enable PROOF on cluster of machines. Enabling PROOF on a cluster of
machines means to configure and start a dedicated daemon on each machine running as master / worker,
hereafter referred to as the servers.
The dedicated daemon - which is implemented as a plug-in for the multi-purpose xrootd daemon processes PROOF-related requests on server nodes, which may come from the client or from a master on behalf
of a client. The daemon is running on the PROOF server machines accepting connections on port 1093 (assigned
by IAAA). It performs two tasks:
 Authenticates the requests: it checks that the request makes sense and comes from an authorized entity;
the strength of the checks depends on the configuration settings;
 Starts a ROOT session and puts the client in connection with it.
GRID site and PROOF cluster
Pic 2. Structure of site RU-Protvino-IHEP
Pic 3. PROOF architecture in IHEP
Server side:The master is the entry point to the computing facility. There are not CPUs on master.
Server side: There are 60 workers with one CPU on each on IHEP GRID site
Client side: User Interface.
Step by step install and configure PROOF cluster on GRID site
It is necessary to download source codes from an official site root.cern.ch: root_<version> .source.tar.gz.
Then unpack archive, change configuration files and choose a way of installation. After archive unpacking we
edit configuration files.
In the config file (proof.conf) we add master machine and all working nodes:
master <hostname>
worker <hostname>
worker <hostname>
....
In the second config file xpd.cf in part one “data serving” we add some libraries such as
libXrdProofd.so and libXrdOfs.so. In third part “enable PROOF serving” we show way to config file proof.conf.
In the instruction xpd.schedparam we specify type of queue which we wish to apply and quantity of
simultaneous sessions queue:fifo mxrun:1. In IHEP GRID site queue fifo (first input first output) and one
simultaneous session is used.
In daemon xrootd start script we must specify some variables, such as:
export ROOTSYS=<place_where_root_is_installed>
export PATH=$PATH:$ROOTSYS/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ROOTSYS/lib/root/5.26
Then we choose a way of installation.
There are two main methods of installing ROOT. The first one is installation from source. As an
alternative, you can build either a set of Debian GNU/Linux or Redhat Linux packages. We decided to use rpm
packages. GRID site contains many nodes and on each we need install this software. It was necessary to
automate this process.
Operating system on master and all nodes is Scientific Linux SL release 5.3 (Boron) (x86_64).
In a folder with source codes we execute a command:
make redhat
This will create a RPM spec file in the source tree: root.spec.
We do some changes in a file root.spec such as: specify release version, directories in which rpmpackages will be gathered and where to be setup and choose features with which proof should be configured.
If you don't have system privileges, you should set up a build area by having the file ~/.rpmmacros with
a contents like:
%_topdir <some where you can write>/redhat
%_sourcedir %{_topdir}/SOURCES
%_specdir %{_topdir}/SPECS
%_builddir %{_topdir}/BUILD
Then you should make the appropiate directories:
mkdir <some where you can write>/SOURCES
mkdir <some where you can write>/BUILD
mkdir <some where you can write>/RPMS
mkdir <some where you can write>/SRPMS
mkdir <some where you can write>/SPECS
and finally copy the source tar-ball and spec file:
cp root_v<version>.source.tar.gz \ <some where you can write>/SOURCES
cp root.spec \ <some where you can write>/SPECS
Whether you have system privileges or not, you can now build the RPM packages by issuing:
rpmbuild -ba <some where you can write>/SPECS/root.spec
Finally in a folder <some where you can write>/RPMS we have two rpm-packages:
libroot-static-<version>-<release>.x86_64.rpm
root-system-<version>-<release>.x86_64.rpm
These two packages should be installed on master and every node in cluster. First libroot-static<version>-<release>.x86_64.rpm, second root-system-<version>-<release>.x86_64.rpm.
Then on master and all nodes we start a daemon xrootd.
/etc/init.d/xrootd status
xrootd (pid 9885) is running...
At successful start in log file there should be a following message: initialization complete.
When user connect with PROOF cluster one can see message in log file: <user> logged in; 1 session are
currently active.
Xrootd daemon check active sessions every 30 seconds.
Pic 4. PROOF log file
When user start proof connection he can see useful short information.
Pic 5. Start PROOF
More detail information you can see during PROOF session.
Pic 6. PROOF session detail information
PROOF and GRID jobs can be executed together on the same GRID site.
Pic 7. PROOF and GRID jobs
The most important conclusion is PROOF compatible with GRID site. PROOF cluster easy to install. It
has not limit worker nodes. Can be install by rpm or deb (multiplatform).
In the future it is planned done authentication by krb5 (now by uid, gid) and PROOF monitoring system.