Отчет о научно-исследовательской работе

Содержание

1. Введение 5

2. Исследование технологических решений по повышению эффективности совместного использования вычислительных ресурсов центров RuTier2/РДИГ 6

3. Разработка методов совместного использования распределенных вычислительных мощностей экспериментами БАК в составе единой Грид-инфраструктуры 6

4. Определение параметров оптимальных настроек системы управления локальными ресурсами для повышения эффективности их функционирования в Грид-среде gLite; 8

4.1. Управление заданиями пользователей в WLCG 8

4.1.1 Менеджер ресурсов TORQUE 9

4.1.2 Диспетчер задач MAUI. 11

4.2. Оптимальная система параметров настроек системы управления локальными ресурсами вычислительных ресурсов RuTier2/РДИГ 12

5. Заключение 15

6. Литератрура 16

Приложение 1. Пример настройки диспетчера заданий MAUI 17

Приложение 2. Пример настройки менеджера ресурсов TORQUE 21

1.Введение

На осень 2009 года планируется начало первого рабочего сеанса работы ускорителя БАК и детекторов ALICE, ATLAS, CMS и LHCb. Общая продолжительность сеанса должен составить 10 месяцев. Российские научные центры являются активными участниками проекта БАК.

Поток сырой информации, который будет поступать в глобальную географически распределённую систему WLCG, составит порядка 2 ТБайта в час. Российская часть этой глобальной грид-системы, RuTier2/РДИГ, должна быть готова к приёму всего объема данных, подготовленных к распределенному анализу физиками, а также части сырых данных, необходимых для отработки алгоритмов обработки и анализа, и обеспечить российские научные центры средствами оперативного управления данными для их распределенного анализа и хранения.

Для успешного выполнения стоящих перед RuTier2/РДИГ центрами задач необходимо осенью 2009 года увеличить существующие мощности вычислительных ресурсов не менее чем на 1400 kSI2000 в целом для комплекса RuTier2/РДИГ, или не менее чем на 700 kSI2000 для базовых центров, без учета центрального узла в РНЦ КИ.

Одной из критических задач для устойчивого и качественного функционирования грид-системы является оптимизация настроек систем управления локальными ресурсами. Указанная задача решается в рамках данного договора.

2.Исследование технологических решений по повышению эффективности совместного использования вычислительных ресурсов центров RuTier2/РДИГ

Повышение эффективности совместного использования вычислительных ресурсов центров RuTier2/РДИГ является ключевой целью для выполнения обязательств РФ по обработке и анализу данных БАК. Однако, при решении этой задачи необходимо учитывать как используемое ПО на ресурсных центрах, так и требования со стороны экспериментальных коллабораций. Эти требования являются следствием моделей компьютинга, принятыми в коллаборациях, и они уточняются коллаборациями по мере приближения пуска БАК.

Особенностью работы в грид является совместное использование ресурсов. В первую очередь это относится к вычислительным ресурсам — кластерам. Совместное использование обеспечивает эффективное использование ресурсов в условиях их неравномерной загрузки, характерной для задач анализа.

3.Разработка методов совместного использования распределенных вычислительных мощностей экспериментами БАК в составе единой Грид-инфраструктуры

Для эффективного использования ресурсов в условиях неравномерного запроса к ним со стороны экспериментов необходимо максимально обеспечить их совместное использование. Однако, требование эффективности ограничено требованиями со стороны экспериментов, которые следуют из их политик. Таким образом нам надо выработать компромиссный подход, который сохранит высокую эффективность использования ресурсов RuTier2/РДИГ сайтов и при удовлетворении противоречивых требований со стороны экспериментов.

Остановимся подробнее на требования экспериментов (см. Таб.1).

Требование	Алиса	Атлас	CMS	LHCb
Резервирование рабочих узлов	желательно	нет	да	нет
Использование максимально возможного числа рабочих узлов	да	да	нет	да
Гарантированный процент ресурсов при полной загрузке.	да	да	да	Да
Время выхода на рабочий режим.	часы	часы	часы	часы

Таблица 1. Требования экспериментов к ресурсам. Где да — требуется, нет — не обязательно.

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

Таким образом можно сформулировать следующие принципы совместного использование ресурсов экспериментами |БАК:

1. 
   Частичное резервирование ресурсов по экспериментам.
   
2. 
   Предоставление основной части ресурсов в совместное пользование.
   
3. 
   Распределение ресурсов в случае их полной загрузки в соответствии с принципом «справедливого распределения».
   
4. 
   Сохранение на приемлемом уровне эффективность использования ресурсов RuTier2/РДИГ.
   

Остановимся более подробно на каждом из них.

Первый из перечисленных принципов, позволяет резко сократить время, в течении которого задания от эксперимента получат необходимый пул ресурсов. Фактически в любое время, эксперименту гарантируется предоставление некоторого количества ресурсов независимо от текущей ситуации на сайте. Конечно, такое резервирование входит в противоречие с п.4.

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

Третий принцип говорит о том, что в случае нехватки ресурсов в данный момент, их распределение между экспериментами должно соответствовать некоторым взаимно приемлемой пропорции.

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

Практическая реализация этих принципов определяется взаимной договоренностью российских частей экспериментов и общей политикой участия России в БАК на основе выработанного и утвержденного руководящими органами регламента по использованию ресурсов. В рамках данного НИР решается только техническая сторона вопроса.

4.Определение параметров оптимальных настроек системы управления локальными ресурсами для повышения эффективности их функционирования в Грид-среде gLite;

4.1.Управление заданиями пользователей в WLCG

Для управления работой кластеров в WLCG используется менеджер ресурсов TORQUE[1] и диспетчер задач MAUI[2].

Совместное использование этого ПО обеспечивает гибкое управление прохождением задач.

В разделе 2.2 приведены параметры управления очередями TORQUE.

4.1.1Менеджер ресурсов TORQUE

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

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

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

Роль вычислительных узлов - выполнять поставленные задачи. На каждом из них работает демон pbs_mom для того, чтобы начинать, прекращать и управлять поставленными в очередь задачами. Это единственный демон, который должен быть запущен на вычислительном узле кластера.

И наконец, демон pbs_sched. Этот демон занимается собственно планированием запуска и остановки задач. Он должен быть запущен на главном компьютере кластера.

Менеджер ресурсов TORQUE обладает гибкой системой настройки очередей. Список параметров приведен в таблице 2.

Атрибут	Формат	Описание
acl_groups	[@] [+[@]]...	Определяет список групп, которые могут запускать задания в данную очередь.
acl_group_enable		Если TRUE, ограничивает запуск щзаданий только группами, которые были указаны в параметре acl_groups. DEFAULT: FALSE
acl_group_sloppy		Если TRUE, acl_groups будет проверятся во всех группах, в которых зарегистрирован пользователь, запустивший задание. DEFAULT: FALSE
acl_hosts	[+]...	Определяет список хостов, с которых можно запускать задания в очередь.
acl_host_enable		Если TRUE, то ограничивает запуск заданий только с хостов, заданных параметром acl_hosts. DEFAULT: FALSE
acl_users	[@] [+[@]]...	Список пользователей, которые имеют право запускать задания в очерель.
acl_user_enable		Если TRUE, то допускается запуск заданий только пользователей, определенных параметром acl_users. DEFAULT: FALSE
acl_logic_or		Если TRUE, то допускается запуск заданий либо пользователей либо группы.. DEFAULT: FALSE
enabled		Определяет возможность запуска заданий в очередь. DEFAULT: FALSE
keep_completed		Определяет в течении скольких секунд задание будет задержано в состоянии Completed после завершения. Defaults to 0.
kill_delay		Определяет через сколько секунд после посылки сигнала SIGTERM будет послан сигнал SIGKILL чтобы снять задание. DEFAULT: 2 seconds
max_queuable		Определяет максимальное число заданий в очереди. DEFAULT: unlimited
max_user_queuable		Определяет максимальное число заданий в очереди от одного пользователя. DEFAULT: unlimited.
max_running		Определяет максимальное число заданий в очереди в состоянии run. DEFAULT: unlimited
max_user_running		Определяет максимальное число заданий от одного пользователя в состоянии run в очереди. DEFAULT: unlimited
priority		Определяет приоритет очереди. DEFAULT: 0
queue_type	one of e, execution, r, or route	Определяет тип очереди.
resources_available		Определяет коммулятивный ресурс доступный для всех запущенных заданий в очереди. DEFAULT: N/A
resources_default		Определяет ресурс по умолчанию требующийся для всех запущенных заданий в очереди.DEFAULT: N/A : По умолчанию рекомендуется требовать walltime и nodes.
resources_max		Определяет максимальное значение ресурса для запущенных заданий в очереди. DEFAULT: N/A
resources_min		Определяет минимальное значение ресурса для запущенных заданий в очереди.
route_destinations	[@] [+[@]]...	Определяет потенциальные очереди для запущенных задач. DEFAULT: N/A
started		Определяет можно ли выполнять задания в очереди. DEFAULT: FALSE

Таблица 2. Список параметров настройки очередей TORQUE

4.1.2 Диспетчер задач MAUI.

Диспетчер MAUI hазработан в Maui High Performance Center [http://www.mhpcc.hpc.mil/]. Является свободно распространяемой программой с открытыми исходными кодами (www.clusterresources.com/maui/). Для своей работы требует ОС Linux и другие UNIX-платформы. С коммерческим аналогом Maui – планировщик Moab, в который добавлены графические средства использования и ряд других расширений, можно ознакомиться по адресу www.clusterresources.com/moab/.

MAUI при планировании использует алгоритм обратного заполнения (backfilling) в сочетании со стратегией резервирования ресурсов.

В связи с большим списком параметров MAUI, мы их здесь не приводим. С ними можно ознакомиться в [3]. Ниже мы приведем лишь те из них, которые нам понадобятся для достижения поставленных целей.

• 
  SRCFG[X] Формат: Одна или более пар вида =. ACCESS, ACCOUNTLIST, APPLICATION, CHARGEACCOUNT, CHARGEUSER, CLASSLIST, CLUSTERLIST, COMMENT, DAYS, DEPTH, DISABLE, ENDTIME, FLAGS, GROUPLIST, HOSTLIST, JOBATTRLIST, MAXTIME, NODEFEATURES, OWNER, PARTITION, PERIOD, PRIORITY, QOSLIST, RESOURCES, ROLLBACKOFFSET, RSVACCESSLIST, STARTTIME, TASKCOUNT, TIMELIMIT, TPN, TRIGGER, или USERLIST
  

Примечание: элементы в списках HOSTLIST и ACL должны разделяться запятыми. Например: HOSTLIST=nodeA,nodeB

• 
  GROUPCFG[] Формат: Список пар вида =, где одно из следующих значений: General Credential Flags, PRIORITY, ENABLEPROFILING, QLIST, QDEF, PLIST, PDEF, FLAGS, используемые ограничения, или параметры «справедливого распределения» (fairshare).
  
• 
  FSWEIGHT Формат: Значение по умолчанию:1. Определяет вес приоритета присвоенный фактору «справедливого распределения».
  
• 
  FSGROUPWEIGHT Формат: Значение по умолчанию:0.
  
• 
  FSPOLICY Формат:
  [*], где
  - одно из следующих значений: DEDICATEDPS, DEDICATEDPES, UTILIZEDPS, PDEDICATEDPS, или SDEDICATEDPES. Значение по умолчанию: нет.
  

4.2.Оптимальная система параметров настроек системы управления локальными ресурсами вычислительных ресурсов RuTier2/РДИГ

В качестве локального менеджера ресурсов на сайтах RuTier2/РДИГ используются TORQUE и диспетчер MAUI.. В разделе 3 отчета сформулированы принципы, на которых должна строится система параметров настройки сайтов. В соответствии с возможностями менеджера ресурсов и диспетчера указанным принципам можно удовлетворить при помощи соответствующих параметров. Потребуем, чтобы эффективность была не ниже 75%.

Для решения поставленной задачи формализуем условия (см. Таб.3) для одного сайта. Числа в таблице носят ориентировочный характер и должны быть изменены в соответствии с регламентом по использованию ресурсов.

	Название ВО:	Алиса	Атлас	CMS	LHCb
Название параметра MAUI	Название под параметра
SRCFG[x-min]	TASKCOUNT	158	164	78	100
GROUPCFG[x]
	FSTARGET (в процентах)	32	24	26	18
Название параметра TORQUE
set queue X
	max_running	658	664	574	600
	max_queuable	958	964	874	900

Таб.3. Параметры настроек TORQUE и MAUI. Здесь X — название ВО.
Настройки остальных параметров общие для всех ВО.

В данной таблице предполагается, что полное число рабочих узлов соответствующие максимально допустимому числу одновременно обрабатываемых заданий total_slotes=1000. Половина из них (static_pull=total_slots*0.5) зарезервирована за экспериментами в соответствии со следующей пропорцией:

Алиса:Атлас:CMS:LHCb=31.6:32.8:15.6:20%

Параметр FSTARGET определяет «справедливое распределение» ресурсов в случае их полной загрузки. В указанном случае это

Алиса:Атлас:CMS:LHCb=32:24:20:18%

Параметр max_running вычисляется по формуле:

max_running=TASKCOUNT+sharing_pull,

где

sharing_pull=tot_slotes-static_pull=1000-500=500.

Вычислим минимальную эффективность, которая может получена в данном примере. Для этого предположим, что заданий от ВО Атлас в некоторый момент не запускаются на ресурсе. Тогда остальным ВО будет доступны 1000-164=836. Таким образом эффективность составить

эфф=83.6%

Что является приемлемой величиной в соответствии с принятыми предположениями.

5.Заключение

Результатом НИР на данном этапе являются следующие рекомендации по совместному использованию вычислительных ресурсов центров RuTier2/РДИГ:

1. 
   Ограничить резервируемую часть ресурсов для всех четырех экспериментов не более 50% от общего числа ресурсов.
   
2. 
   Остальная часть ресурсов должна быть в совместном пользовании.
   
3. 
   В случае полной загрузки ресурсов они должны распределяться в соответствии с политикой «справедливого распределения».
   

В результате проведенного исследования показано, что возможности настройки менеджера ресурсов TORQUE и диспетчера заданий MAUI позволяют достичь поставленных целей. В частности, обеспечивается эффективная совместная эксплуатация ресурсов всеми экспериментами БАК в условиях нехватки ресурсов и сильной неравномерности загрузки ресурсов заданиями анализа первых данных БАК.

6.Литератрура

[1] TORQUE Admin Manual, http://www.clusterresources.com/torquedocs21/

[2] Maui Scheduler Administrator's Guide, http://www.clusterresources.com/products/maui/docs/mauiadmin.shtml

[3] Appendix F: Maui Parameters, http://www.clusterresources.com/products/maui/docs/a.fparameters.shtml#groupcfg

Приложение 1. Пример настройки диспетчера заданий MAUI

#########################################################

################### Example ######################

#########################################################

#--------------------------------------------------

# Reservation slots for LHC VO's. 360 in total including 2 slots for OPS.

#--------------------------------------------------

# Reserve 2 CPUs for OPS jobs

# It is necessary for SAM test.

SRCFG[ops-sft] GROUPLIST=ops

SRCFG[ops-sft] TASKCOUNT=2 RESOURCES=PROCS:1;MEM=256

SRCFG[ops-sft] PERIOD=INFINITY PRIORITY=10000 FLAGS=SPACEFLEX

# Reserve 121 CPUs for ATLAS jobs

SRCFG[atlas-min] GROUPLIST=atlas

SRCFG[atlas-min] TASKCOUNT=121 RESOURCES=PROCS:1;MEM=256

SRCFG[atlas-min] PERIOD=INFINITY PRIORITY=10000 FLAGS=SPACEFLEX

# Reserve 58 CPUs for CMS jobs

SRCFG[cms-min] GROUPLIST=cms

SRCFG[cms-min] TASKCOUNT=58 RESOURCES=PROCS:1;MEM=256

SRCFG[cms-min] PERIOD=INFINITY PRIORITY=10000 FLAGS=SPACEFLEX

# Reserve 116 CPUs for ALICE jobs

SRCFG[alice-min] GROUPLIST=alice

SRCFG[alice-min] TASKCOUNT=116 RESOURCES=PROCS:1;MEM=256

SRCFG[alice-min] PERIOD=INFINITY PRIORITY=10000 FLAGS=SPACEFLEX

# Reserve 74 CPUs for LHCb jobs

SRCFG[lhcb-min] GROUPLIST=atlas

SRCFG[lhcb-min] TASKCOUNT=40 RESOURCES=PROCS:1;MEM=256

SRCFG[lhcb-min] PERIOD=INFINITY PRIORITY=10000 FLAGS=SPACEFLEX

## Limit maximal number of running and idle jobs

## Limits should be synced with Torque ones -- LCG/gLite infosystem

## extracts limits from 'qstat'.

# OPS should not run more than three jobs and three jobs can wait

GROUPCFG[ops] MAXPROC=3,3 MAXIJOB=3 FSTARGET=1.0

# DTEAM should not run more than three jobs and three jobs can wait

GROUPCFG[dteam] MAXPROC=3,3 MAXIJOB=3 FSTARGET=1.0

#-----------------------------------------------------

# Setting FairShare for LHC VO's in asymptotic

# Atlas:CMS:Alice:LHCb=237:174:193:132=32:24:26:18 (%)

#-----------------------------------------------------

GROUPCFG[atlas] MAXPROC=600,600 MAXIJOB=300 FSTARGET=32

GROUPCFG[cms] MAXPROC=600,600 MAXIJOB=300 FSTARGET=24

GROUPCFG[alice] MAXPROC=600,600 MAXIJOB=300 FSTARGET=26

GROUPCFG[lhcb] MAXPROC=600,600 MAXIJOB=300 FSTARGET=18

## Fairshare configuration

FSWEIGHT=400

FSGROUPWEIGHT=10

FSDEPTH=14

FSINTERVAL=12:00:00

FSDECAY=0.995

FSPOLICY=DEDICATEDPS

## Priorietisation strategies

GROUPWEIGHT=0

QUEUETIMEWEIGHT=0

Приложение 2. Пример настройки менеджера ресурсов TORQUE

Остальные параметры настроек не зависят от ВО.

set queue atlas max_running = 489

set queue atlas max_queuable = 789

set queue cms max_running = 426

set queue cms max_queuable = 726

set queue alice max_running = 484

set queue alice max_queuable = 784

set queue lhcb max_running = 442

set queue lhcb max_queuable = 742