Приложение 4. Использование системы управления заданиями Cleo
Система управления заданиями Cleo контролирует запуск задач на многопроцессорных вычислительных установках, в том числе на кластерах. Она позволяет автоматически распределять вычислительные ресурсы между задачами, управлять порядком их запуска, временем работы, получать информацию о состоянии очередей. При невозможности немедленного запуска задач, они ставятся в очередь и ожидают, пока не освободятся нужные ресурсы.
Система позволяет работать с различными типами заданий, в том числе с последовательными и написанными с использованием различных версий MPI: MPICH, MPICH-gm, LAM, ScaMPI, MVAPICH и другими.
В качестве вычислительной единицы используется процессор. Система оперирует и понятием вычислительного узла, который может объединять несколько процессоров. В рамках одной очереди система считает все процессоры равноправными.
Сама система Cleo написана на языке perl, что позволяет использовать ее на различных платформах.
Общая структура системы
Система Cleo состоит из сервера (запускаемого с правами суперпользователя), управляющего заданиями, программ-мониторов, запускаемых на всех рабочих узлах, и набора клиентских программ, осуществляющих взаимодействие с сервером по TCP/IP либо через файлы состояния сервера.
В качестве клиентских программ в поставку входит так называемый основной клиент (программа cleo-client ), который поддерживает полный набор команд сервера Cleo. Его используют скриптовые программы, осуществляющие простые операции с сервером, например, постановку задания в очередь, снятие задания и другие.
Возможно написание произвольных клиентов, использующих протокол взаимодействия сервера и клиентских программ. Предусмотрена возможность анализировать файл состояния сервера для получения данных об очередях, задачах и т.п.
Иерархия очередей
Система очередей способна поддерживать несколько очередей одновременно. Все они организованы иерархически, когда одни очереди включают в себя другие. Это значит, что любой процессор может использоваться одновременно несколькими очередями.
Рассмотрим следующий пример:
Представлена иерархия из трех очередей над 4 вычислительными узлами, содержащими по 2 процессора каждый. Узлы имеют имена p1, р2, р3 и р4, а их процессоры соответственно p1:1, p1:2 для узла p1 и т.д.
Очередь main включает в себя все процессоры. Такая объемлющая очередь должна присутствовать всегда, даже если ей никогда не будут пользоваться (это имеет смысл, например, если она объединяет несколько несвязанных кластеров или разделов одного кластера, управление которыми осуществляется независимо).
В данном примере очередь main имеет две дочерних очереди - long, включающую в себя процессоры p1:1, p1:2, р2:1 и р2:2, и очередь short, включающую в себя процессоры р3:1, р3:2, р4:1 и р4:2.
Дочерние очереди могут пересекаться, но в этом случае информация о занятости процессоров из пересечения не передается между очередями одного уровня, поэтому такой режим нежелателен.
Система следит за тем, чтобы каждый процессор использовался одновременно только одной задачей (если явно не оговорен иной режим). Это достигается за счет того, что задачи очередей верхнего уровня автоматически попадают и в дочерние очереди. Таким образом, когда задача фактически идет на счет, она присутствует и помечается как считающаяся во всех очередях, чьи процессоры она занимает. Например, поставим в очередь short задачу на 4 процессора, а затем в очередь main задачу на 6 процессоров. Последняя задача автоматически попадет в очереди short и long. В очереди long она будет помечена как предзапущенная, то есть для нее будут зарезервированы процессоры, но на счет она отправлена не будет. В очереди short будет считаться первая задача, а вторая будет ждать окончания ее счета.
Как только первая задача досчитается, в очереди short будет предзапущена вторая задача. Очередь main (которой и принадлежит вторая задача) получит 8 процессоров для ее запуска. Так как заказано для нее было только 6 процессоров, то ровно 6 процессоров будет отобрано для счета. Остальные 2 процессора будут сняты с резервирования и могут быть использованы для запуска новых задач.
Описанную выше ситуацию можно условно представить в таком виде:
До постановки задач
После постановки задач
Каждая из очередей может быть настроена независимо. Иными словами, в различных очередях могут быть заданы различные политики для пользователей, лимиты, стратегии планирования.
В качестве лимитов могут быть заданы количество процессоров на одну задачу, количество одновременно занятых процессоров (если пользователь одновременно запускает несколько задач), максимальное время счета задачи, максимальный приоритет задачи и другие.
Ограничения могут также задаваться и для отдельных пользователей, при этом такие ограничения могут быть как строже, так и мягче, чем для очереди в целом.
Приоритеты
В очереди задачи сортируются по приоритету. Приоритет - это целое число в диапазоне от 0 до 256. Приоритет по умолчанию задается в настройках очереди. Если он не задан, то он принимается равным 10. Задачи с более высоким приоритетом всегда ставятся в очередь выше задач с более низким приоритетом и будут запущены раньше, даже если они были поставлены в очередь позже по времени. Приоритет можно повышать и понижать после постановки задачи в очередь.
Пользователь может понизить приоритет своей задачи, а также повысить его до величины, не превышающей установленного для него лимита.
Ограничение времени счета
Для задач можно задать ограничение времени счета. Обычно оно задано по умолчанию, но можно его понизить, если это необходимо. По истечении указанного лимита задача будет принудительно снята со счета.
Система Cleo ориентируется на то, что задача будет считаться не дольше указанного лимита времени, и учитывает это при планировании времени старта других задач.
Стратегии выбора процессоров
При старте задачи для нее выделяются процессоры. В системе есть возможность управлять стратегией выбора процессоров для задач. Есть три встроенные стратегии:
| random | Процессоры выбираются случайным образом. |
| random_hosts | Процессоры выбираются на случайно выбранных узлах, предпочтительно занимая все доступные процессоры на узле. |
| hosts_alone | Процессоры выбираются на случайно выбранных узлах, предпочтительно занимая лишь по одному процессору на узле. |
Элемент случайности в выборе процессоров присутствует для достижения двух целей: лучшей сбалансированности нагрузки на процессоры и предотвращения блокировок, связанных с неудачным заказом конфигурации процессоров.
В системе есть возможность подключения внешних модулей для задания своих стратегий. В случае использования внешнего модуля, он должен быть описан в разделе pe_sel_method секции [server], где также будет описано его имя. Для подключения модуля в систему достаточно просто указать его имя вместо имени встроенного метода.
Политики пользователей
Как для всех очередей, так и для каждой очереди в отдельности можно задать список пользователей, которые имеют право ставить на счет свои задачи. Все остальные пользователи не будут иметь доступа к соответствующим очередям. Можно запретить доступ к очередям фиксированному списку пользователей, тогда для всех остальных доступ будет открыт.
Права доступа не наследуются очередями-потомками. В контексте нашего примера, если пользователю userl разрешен доступ в очередь main, то ему не обязательно разрешен доступ в очередь short или long.
Для всех очередей и для каждой очереди в отдельности можно задать список пользователей-администраторов, которые в рамках соответствующих очередей получают возможность управлять лимитом времени работы задач, приоритетами, удалять любые задачи и выполнять другие административные действия.