Материал из eSyr's wiki.

Диктофонная запись: http://esyr.org/lections/audio/clusterbuilding_2008_summer/clusterbuilding_08_03_21.ogg

С прошлого раза: в случае, когда провайдер не пускает, ключ -R (а не -L). В блюгене трёхмерный тор, а не 6-мерный.

[править] Постановка задач пользователей в очередь

Есть некий пользователь, есть некая многопроцессорная система…

Есть некий пользователь, есть некая многопроцессорная система, которая пользователю выглядится как некий чёрный ящик, про который ему известно, что там много процессоров, какой-то объём памяти. Пользователь написал/взял где-то зашибись замечательную программу, которая требует себе значительное количество ресурсов. Обычно количество ресурсов можно для соотв. программы варьировать. Вопрос к общественности: какие программе могут понадобиться ресурсы? При этом, мы предоставляенм набор чёрных ящиков на определённое время. Ресурсы:

• Количество процессоров
• Количество памяти
  • Физической на узел кластера
  • Виртуальной на узел кластера
  • Размер файла подкачки на узел кластера
  • Суммарное ограничение на используемую память
• Ограничение на время. Вопрос: какое время?
  • Астрономическое время --- с 15 марта по 15 мая
  • Использовать не больше, чем 300 часов суммарного процессорного времени
  • Использовать не более, чем 300 часов астрономического времени
• Сетевой трафик в случае GRID
• Лицензионные ограничения

[править] Жизненный цикл задачи пользователя

Схема взаимодействия пользователя и сервера очередей

Есть у полььзователя терминал, он говорит,что хочет запустить задачу и указывает ограничения. У него есть приложение клиентское, которое участвует в постановке задачу в очередь. Этот терминал коннектится к серверу очередей. ДАльше сервер очредей занимается тем, что анализирует ограничения. Если с ограничениями всё хорошо (это значит,что пользователь попросил что-то, что по объёму меньше, чем предоставляет многопроцессорная система). После этого проверяются пользовательские ограничения. В некоторых ситуациях он меняется со временем. Потом залдача ставится в очередь. Поставленная задача движется в очереди до момента своего назначения. Перед постановкой задачи в очередь анализируется такая штука, как количество одоновременно поставленных задач в очереди. Про задачу известно:

• Объём ресурсов
• Пользователь
• Статистика по запускам
• Ситуация на много процессорной системе
• У задачи, поставленной в очередь, есть статус

Приоритеты:

• Приоритет адачи
• Приоритет пользователя

Чего добиться:

• Справедливость по отношению к пользователями
• Эффективное использование доступных ресурсов

Причём первое более важное, чем второе. Кроме того, система очередей должна гарантировать, что задача когда-нибудь выполнится.

Наконец, случился момент назначения, задача распределилась по какому-то числу процессоров. Что с этой задачей может произойти дальше?

• Задача запустилась и работает
• Приостановлена
• Отработка контрольной точки
• Стартует задача
• Перемещаемая задача
• Задача может завершаться. Сама или принудительно, по исчерпании ресурсов.

[править] Конкретный пример

Есть несколько известных в текущий момент систем очередей:

• LoadLeveler
• PBS, torque + maui, moab + maui, Sun Grid Engine

У этих двух систем разные соглашения по именованию утилей по запуску задач. У LL --- llsubmit, у остальных --- qsub

• cleo
• run_mvs --- МСЦ

[править] Прочая информация про задачу

…

• Файл ввовывод задача
• Оповещение о запуске
• Оповещение о завершении
• Зарезервировать определённые узлы на определённое время, но при этом ничего тпасм не запускать

[править] Примеры

[править] пример файла с паспортом задачи

#! /bin/sh
#PBS -l wtime=1:00:00
#PBS -l mem=400mb
#PBS -l ncpus=100
./my_job

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

Ключи:

• -h --- захолдить сразу после запуска
• -N --- указать имя задачи
• -o --- поток вывода
• -q --- имя очереди
• -s --- шелл
• -с --- интервал для чекпоинта
• -e --- текущий каталог для задачи

Какие параметры на ограничения можно выставить (синтаксис: -l ограничение=параметр, через запятую, если несколько)

• arch --- Архитектура
• cput --- объём процессорного времени
• mem --- объём памяти
• ncpus --- количество процессоров
• nice --- приоритет юниксовый во время выполнения
• nodes --- число и тип необходимых задаче узлов
• pcput
• pmem
• pvmem --- число виртуальной памяти, необх. задаче
• resc --- позволяет при помощи некоего логического языка выставить ограничения на всё, что перечислено
• software --- указывает лицензии
• walltime --- астрономическое время выполнения задачи

[править] Групповой учёт заданий

Сцепленные задачи

• Запуск одной задачи н раз, желательно подряд. Тогда эта задача отдельно планируется от всех остальных с учётом этого факта
• Сцепленные задачи. Это когда есть набор задач, и для исполнения очередной задачи нужно исполнить неоке количество предыдущих задач. В общем случае это граф задач, где сказано, как эти задачи зависят друг от друга. В случае с LL это job stack, и это планируется отдельно. Указывается это всё в паспорте задач примерно в таком ключе: #job name. В этом случае оно будет другое. И на соотв шаге можно указать, что очередной job step зависит от соответствующих имён: #job step job name 1, job name 2, job name 3...