Система управления заданиями Cleo
Руководство администратора
2004
1.Общие понятия и требования
1.1.Введение.
Система управления заданиями Cleo предназначена для управления запуском задач на многопроцессорных вычислительных установках (в том числе кластерных). Она позволяет автоматически распределять вычислительные ресурсы между задачами, управлять порядком их запуска, временем работы, получать информацию о состоянии очередей. При невозможности запуска задач немедленно, они ставятся в очередь и ожидают, пока не освободятся нужные ресурсы.
Система позволяет работать с различными типами заданий, в том числе последовательными и написанными с использованием различных версий MPI – MPICH-p4, MPICH-gm, Lam, ScaMPI и другими.
В качестве вычислительной единицы используется процессор, но система оперирует и понятием вычислительного узла, который может содержать несколько процессоров. На данный момент система не различает типов процессоров (то есть в рамках одной очереди все процессоры считаются равноправными).
Система написана на языке perl, что позволяет использовать её на различных платформах.
1.2.Системные требования.
Для успешной работы Cleo необходимо наличие работоспособного интерпретатора perl версии не ниже 5.005, а также модулей IO::Socket, IO::Pipe, IO::Handle, IO::Select, IO::File, Storable, Sys::Syslog, Time::Local, POSIX, и Fcntl, соответствующих данной версии perl или более поздних версий. Также необходимо наличие сформированных системных файлов заголовков ph. Для этого от имени суперпользователя должна быть исполнена команда:
cd /usr/include; h2ph -r -l .
При использовании механизма авторизации (см. п. 2.7), требуется совместимость файловой системы /proc с Linux 2.2 либо 2.4 (точнее формата файлов /proc/PID/status и /proc/PID/cmdline).
Если предполагается запуск задач от имени различных пользователей, то запуск сервера системы должен производится с правами суперпользователя.
2.Структура системы
2.1.Общая структура системы.
Система Cleo состоит из сервера, запускаемого с правами суперпользователя, и осуществляющего собственно управление заданиями, программы-монитора, запускаемой на всех рабочих узлах, и набора клиентских программ, осуществляющих непосредственное взаимодействие с сервером, используя протокол TCP/IP, либо через файлы состояния сервера (в последнем случае возможно лишь получение информации от сервера).
Сервер порождает набор процессов в соответствии с иерархией очередей (см. п. 2.2) и в дальнейшем каждый из этих процессов контролирует свою очередь. Головной процесс контролирует головную очередь (по умолчанию – 'main') и отвечает за взаимодействие с клиентскими программами.
В качестве клиентских программ в поставку входит, так называемый, основной клиент (программа qclient3.pl), который поддерживает все команды сервера по протоколу TCP/IP. С его использованием написаны скриптовые программы, осуществляющие простые операции с сервером, такие как постановка задания в очередь, снятие задания, и т.п.
Возможно написание произвольных клиентов, использующих протокол взаимодействия сервера и клиентских программ
2.2.Иерархия очередей.
Система очередей способна поддерживать несколько очередей одновременно. Все они организуются в иерархию, где одни очереди включают в себя другие. Это значит, что любой процессор может использоваться одновременно несколькими очередями. Приведем небольшой пример:
main
|
long
|
short
|
p1:1
|
p1:2
|
p2:1
|
p2:2
|
p3:1
|
p3:2
|
p4:1
|
p4:2
|
На этой картинке представлена иерархия из трех очередей над 4 вычислительными узлами, содержащими по 2 процессора. Узлы имеют имена p1, p2, p3 и p4, а их процессоры соответственно p1:1, p1:2 для узла p1 и т.д.
Очередь main включает в себя все процессоры. Такая объемлющая очередь должна существовать всегда, даже если ей никогда не будут пользоваться (например, если она объединяет несколько несвязанных кластеров, управление которыми осуществляется независимо). В последнем случае можно просто запретить доступ в объемлющую очередь для всех.
Очередь main в данном примере имеет две дочерних очереди – long, включающую в себя процессоры p1:1, p1:2, p2:1 и p2:2, и очередь short, включающую в себя процессоры p3:1, p3:2, p4:1 и p4:2.
Система следит за тем, чтобы каждый процессор использовался одновременно только одной задачей (если явно не оговорено обратное). Это достигается за счет того, что задачи очередей "верхнего" уровня автоматически попадают и в дочерние очереди. Таким образом, когда задача фактически идет на счет, она присутствует и помечается как считающаяся во всех очередях, чьи процессоры она занимает.
Например, поставим в очередь short задачу на 4 процессора и затем в очередь main – задачу на 6 процессоров. Последняя задача автоматически попадет в очереди short и long. В очереди long она будет помечена как пред-запущеная, то есть для нее будут зарезервированы процессоры, но на счет она пущена не будет. В очереди short будет считаться первая задача, а вторая будет ждать окончания ее счета.
До постановки задач
-
После постановки задач
-
main
|
задача2
|
|
long
|
short
|
задача2
|
задача1
|
|
задача2
|
Как только первая задача досчитается, в очереди short будет пред-запущена вторая задача. Очередь main (которой и принадлежит вторая задача) получит 8 процессоров для ее запуска. Так как заказано для нее было только 6 процессоров, то ровно 6 процессоров будет отобрано для счета. Остальные 2 процессора будут сняты с резервирования и могут быть использованы для запуска новых задач.
Каждая из очередей может быть настроена независимо. То есть в различных очередях могут быть заданы различные ограничения.
В качестве ограничений могут быть заданы количество процессоров на одну задачу, количество одновременно занятых процессоров (если одновременно запускается несколько задач), максимальное время счета задачи, максимальный приоритет задачи. Подробнее об этом см. главу «Настройка сервера через файл конфигурации и ключи».
Ограничения могут также задаваться и для отдельных пользователей, при этом они могут быть строже или мягче, чем для очереди в целом.
|