3. Конфигурирование пакетной системы
В начало страницы
Теперь, когда система построена и установлена, как раз и начинается работа.
Сервер и все Mom должны быть сконфигурированы и реализована политика
планирования. Эти вещи тесно связаны между собой. Управление тем, какие и
сколько заданий должны планироваться на исполнение может быть осуществлено
несколькими методами. Каждый метод накладывает отпечаток на реализацию
политики планирования и на атрибуты Сервера. Примером может служить решение
планировать задания из одного пула (очереди) или распределять задания в
много очередей, каждая из которых управляется отдельно. О дискуссиях на эту
тему говорится в главе 4, Стратегии планирования.
В начало страницы
Если вы устанавливаете PBS на отдельной системе, вам следует конфигурировать
демонов и начать заботиться о вашей стратегии планирования. Мы все еще
рекомендуем прочесть раздел 3.2.3, Где задания могут исполняться, и затем
продолжить чтение с раздела 3.3 Сетевые адреса. Никакие узловые файлы не
нужны.
Если вы хотите, то PBS Сервер и Планировщик, pbs_server и pbs_sched, могут
исполняться на одной системе, а задания исполняться на другой. Это тривиальный
случай кратных исполнительных систем рассматривается в следующем разделе.
Рекомендуем прочесть его. Если вы используете стандартный (default)
Планировщик, fifo, вам необходим узловой файл с одним входом, именем хоста,
на котором работает, с аппендиксом :ts. Если вы пишете собственный
Планировщик, он может действовать не так как файл узлов, на которых должны
пропускаться задания хоста.
В начало страницы
Если вы работаете на более чем одном компьютере, необходимо установить
исполнительный демон (pbs_mom) на каждой системе, где ожидается исполнение
заданий. Если эксплуатируется стандартный планировщик, fifo, вам понадобится
узловой файл с одним входом на каждый исполнительный хост. Входом служит имя
хоста с Mom и с аппендиксом :ts. И опять, если вы пишете собственный
планировщик, он может общаться не через Серверный файл узлов, на которых
могут исполняться задания хоста.
В начало страницы
Имеется четыре способа установки Mom на каждом из различных исполнительных
хостов.
1. Первый метод состоит в полной установке PBS на каждом хосте. Хотя это и
работает, это требует много времени.
2. Второй путь --- перезапустить конфигурацию со следующими параметрами:
--disable-server --set-sched=no. Можно также
избрать --disable-clients, но пользователи часто используют команды
PBS внутри сценария задания, так что вы, наверное захотите строить
команды. И вам тогда нужно будет перекомпилировать и затем делать
установку на каждом исполнительном хосте.
3. Третий путь --- производить установку только Mom (и, возможно, команд)
на каждой системе. Если система будет использовать тот же самый двоичный
код, как и на системе, где PBS был скомпилирован, замените каталог обратно
на src/mom и сделайте установку как корня. Установите команды
cd ../cmds и снова make install. Если система потребует рекомпиляцию,
выполните ее на верхнем уровне, чтобы перекомпилировать библиотеки, и
продолжайте, как выше.
4. Четвертый способ требует, чтобы система была в состоянии выполнять
существующие двоичные коды и чтобы каталоги sbindir и bindir, в которых
демоны PBS и команды были установлены во время начальной полной
постройки, были доступны на каждом хосте. Эти каталоги, в отличие от
PBS_HOME, могут располагаться в сетевой файловой системе.
Если целевое дерево доступно на хосте как корень, выполните следующие
команды на каждом исполнительном хосте:
sh {target_tree}/buildutils/pbs_mkdirs [-d new_directory] mom
sh {target_tree}/buildutils/pbs_mkdirs [-d new_directory] aux
sh {target_tree}/buildutils/pbs_mkdirs [-d new_directory] default
Это приведет к постройке требуемой порции PBS_HOME на каждом хосте.
Используйте параметр -d, если хотите поместить PBS_HOME в другом
месте узла. Этот каталог должен быть в локальной памяти узла, а не в
общей (shared) файловой системе. Если вы используете другой путь для
PBS_HOME, чем был указан при выполнении конфигурации, нужно также
запустить pbs_mom с соответствующим параметром -d, чтобы он знал,
где расположен PBS_HOME.
Если целевое дерево не доступно, скопируйте pbs_mkdirs shellscript в
каждый исполнительный хост и снова, как корень, выполните его с указанными
выше операндами.
Теперь нужно объявить имя исполнительных хостов для демона pbs_server, как
об этом сказано в следующем разделе.
В начало страницы
В PBS, назначение кластерных узлов (фактически, виртуальных процессоров
VPs, узлов) для задания производится Сервером.
Каждый узел должен иметь собственную копию Mom, исполняемую на нем. Если
только разделяемые во времени хосты обслуживаются пакетной системой PBS, то
Планировщик Заданий должен определять, где задание будет исполняться. Если
специально не указано, Сервер будет исполнять задание на хосте, где он сам
работает. См. детали в следующем разделе.
Если узловые виртуальные процессоры должны распределяться монопольно или
временно-совместно, список узлов должен быть сообщен Серверу. Этот список
может содержать также разделяемые во времени узлы. Узлы, отмеченные как
разделяемые во времени, будут указываться Сервером в отчете о статусе узлов
наряду с другими узлами. Однако, Сервер не будет пытаться распределить их
заданиям. Присутствие в списке разделяемых во времени узлов сделано только
для удобства Планировщика Заданий и других программ, таких как xpbsmon.
Список узлов дается Серверу в файле с именем nodes в начальном каталоге
Сервера PBS_HOME/server_priv. Это простой текстовый файл, содержащий по
одному узлу в строке. Формат строк таков:
node_name[:ts] [свойство ...] [np=NUMBER]
- Имя узла есть сетевое имя узла (host name), оно не должно
быть вполне квалифицированным (фактически, лучше, чтоб оно было как
можно более коротким). Некоторые заканчиваются на :ts, указывая, что
он относится к узлу, разделяемому во времени.
- Можно указывать ноль или более свойств. Свойство -- просто цепочка
букв и цифр (первая-- буква), безразличная для PBS.
- Выражение np=NUMBER может быть добавлено для объявления
количества виртуальных процессоров (VP) в узле. NUMBER
есть числовая цепочка, например, np=4. Это выражение
разрешает узлу быть распределенным до NUMBER раз одному заданию
или более чем одному. Если np=# не указано для кластерного узла,
предполагается, что он имеет один VP. Хотя np=# может быть
объявлено и на разделяемом во времени узле, это не имеет смысла.
- Позиции частей одной строки должны разделяться белыми пробелами.
Части могут располагаться в любом порядке, но имя хоста
должно быть первым в строке.
- Могут включаться строки-комментарии, в которых первый не белый пробел
есть знак '#'.
Вот пример возможного узлового файла:
# Первое множество узлов есть кластерные узлы.
# Заметьте, что свойства даны группам,
# объединяющим некоторые узлы.
curly stooge odd
moe stooge even
larry stooge even
harpo marx odd np=2
groucho marx odd np=3
chico marx even
# И для интереса вставим один разделяемый во времени узел.
chaplin:ts
После старта pbs_server список узлов можно дополнять и изменять по команде
qmgr.
Добавить узлы:
Qmgr: create node node_name [attributes=values]
где атрибуты и соответствующие им допустимые значения есть:
+-----------+-----------------------------------------------------------|
|Attribute | Value |
+-----------+-----------------------------------------------------------|
|state | free, down, offline |
|properties | любая цепочка из букв и цифр или множество таких |
| | цепочек, разделенных запятыми |
|ntype | cluster, time-shared |
|np | число виртуальных процессоров больше нуля |
+-----------+-----------------------------------------------------------|
В добавок, к перечисленным состояниям, которые могут быть установлены
администратором, имеются некоторые другие, которые могут быть установлены
только внутренним образом.
busy state устанавливается исполнительным демоном, pbs_mom, когда
достигнут порог средней загрузки узла. См. max_load в файле конфигурации
Mom [раздел 3.6].
Job-exclusive и job-sharing состояния устанавливаются в узле , когда на
нем исполняются задания.
Заметим, что все запятые, разделяющие цепочки, должны быть заключены в
кавычки.
Примеры:
create node box1 np=2,ntype=cluster,properties="green,blue"
Модифицировать узлы:
set node node_name [attributes[+|-]=values]
где атрибуты те же что и при создании.
Примеры:
set node box1 properties+=red
set node box1 properties-=green
set node box1 properties=purple
Удалить узлы :
Qmgr: delete node node_name
Примеры:
delete node box1
В начало страницы
Где задания могут или будут исполняться, определяется взаимодействием между
Планировщиком и Сервером. Это взаимодействие реализуется благодаря
существованию узлового файла.
В начало страницы
Если узловой файл не существует, Серверу непосредственно известен лишь его
собственный хост. Он предполагает, что задания могут исполняться только на нем.
Если приказано исполнять задание без указания имени хоста для исполнения,
он выберет свой собственный хост. В противном случае он будет пытаться
выполнять задание там, где указано в запросе на выполнение задания.
Обычно планировщик заданий будет знать о других хостах, потому что это было
так записано на вашем сайте. Планировщик укажет Серверу, где выполнять задание.
Стандартный планировщик fifo зависит от существования узлового файла, если в
планировке участвует более чем один хост. Любые или все узлы, указанные в
файле, могут быть разделяемыми во времени хостами с окончанием ":ts".
В начало страницы
Если файл узлов существует, то следующие правила войдут в игру.
1. Если определенный host назван в запросе на исполнение задания и этот
хост указан в файле узлов как разделяемый во времени, Сервер
попытается выполнять задание на этом хосте.
2. Если определенный хост назван в запросе на исполнение задания
и названный узел отсутствует в файле узлов как разделяемый во
времени хост или если много узлов названы в запросе на исполнение
задания, то Сервер пытается распределить один (или более, если
запрошены) виртуальных процессоров на названный кластерный узел
или узлы для задания. Все из названных узлов должны появиться в
файле узлов сервера. Если распределение успешно, то задание
[сценарий оболочки] запускается на первом из отведенных узлов.
3. Если никакие размещения не были указаны в запросе на исполнение
задания, но задание запрашивает узлы, тогда виртуальные процессоры
кластерных узлов, если это возможно, отводятся в соответствии с
запросом. Если распределение прошло успешно, задание запускается
на узле, отведенном в соответствии с первой спецификацией в запросе
на узлы. Заметим, что Планировщик может изменить оригинальный
запрос задания на узлы. См. атрибут задания neednodes.
Для узлов SMP, где кратные виртуальные процессоры были объявлены,
порядок распределения процессоров управляется установкой атрибута
Сервера node_pack:
- Если атрибут имеет значение true, VP будет сначала взят
от узлов с наименьшим количеством свободных VP.
Это упаковывает задания в возможно меньшее количество узлов,
оставляя узлы, доступные с большим количеством VP для тех
заданий, которые нуждаются во многих VP на узле.
- Если node_pack установлен на false, то VP берутся от узлов
с наибольшим количеством свободных VP. Это разбрасывает задания
по узлам, минимизируя конфликты между ними.
- Если node_pack не установлен (т.е. ни true, ни false), то VP
распределяются в порядке, в котором узлы объявлены в узловом
файле Сервера,
Знайте, что если node_pack установлен, то внутренний порядок
узлов изменен. Если позже установка node_pack будет снята,
порядок больше не будет изменяться, но будет отличным от
установленного первоначально в файле узлов.
Пользователь может запросить несколько виртуальных процессоров
на узел, добавив член ppn=# (для процессоров на узле) к каждому
узловому выражению. Например, заказ 2 VP на каждом из трех
узлов и 4 VP еще на двух узлах, пользователь может запросить так:
-l nodes=3:ppn=2+2:ppn=4
4. Если установлен атрибут Сервера default_node, то используется его
значение. Если он относится к имени разделяемого во времени узла,
задание запускается на этом узле. Если значение default_node может
быть отнесено к множеству из одного или более свободных кластерных
узлов, то они распределяются для задания.
5 Если default_node не установлен и определен по крайней мере один
разделяемый во времени узел, то используется этот узел. Если
определен более чем один, то один из них избирается для задания, но
какой именно --- предсказать нельзя.
6. Последний выбор означает действие как в том случае, когда задание
запросило 1#shared. Задание распределяется к любому имеющемуся
разделяемому заданиями VP, а если таких нет, то какой-нибудь
свободный VP распределяется как разделяемый заданиями.
Итог всему сказанному выше можно подвести следующим образом:
- Если пакетная система состоит из единственного разделяемого во
времени хоста, на котором исполняются Сервер и Mom, то проблем нет:
все задания там и исполняются. Планировщик нужен только, чтобы
сказать, какое задание он хочет запустить.
- Если вы используете разделяемый во времени комплекс с одним или
более хостов заднего плана ( back-end hosts), где Mom работает
на другом хосте, чем Сервер, то сбалансированное распределение
заданий по разным хостам есть обязанность Планировщика, определяющего
на какой хост поместить избранное задание. Это делается с помощью
запросов к управляющему ресурсами блоку через средства управления
API --- вызовы addreq() и getreq(). Планировщик сообщает серверу,
где выполнять каждое задание.
- Если ваш кластер составлен из кластерных узлов и вы исполняете
распределенные (многоузловые) задания, так же как и последовательные
задания, Планировщик обычно использует запросы типа Query Resource
или Avail к Серверу для каждого очередного задания. Затем
Планировщик избирает одно из заданий, относительно которых Сервер
сообщил, что их можно запускать, и приказывает ему исполнять это
задание. Тогда Сервер отводит один или более VP (виртуальных
процессоров) на одном или нескольких узлах, как требуется заданию.
Установкой атрибута Сервера default_node на один из временно
совместных узлов, 1#shared, задания, которые не запрашивают узлов,
будут помещены вместе на несколько временно совместных узлов.
- Если ваша пакетная система поддерживает как кластерные узлы, так и
разделяемые во времени, ситуация подобна рассмотренной выше, только
вы можете еще пожелать заменить default_node в точке на разделяемый
во времени хост. Задания, которые не просят узлов, будут закончены
исполнением на разделяемом во времени хосте.
- Если ваша пакетная система поддерживает и кластерные узлы и кратные
разделяемые во времени хосты, вы имеете сложную систему , которой
требуется искусный Планировщик. Он должен распознавать, какие задания
требуют узлы и выдавать Серверу запросы типа Avail (возможность).
Он должен также распознавать, какие задания должны сбалансировать
нагрузку на разделяемые во времени хосты и сообщать имя хоста
Серверу при приказании запустить определенное задание. Поставляемый
Планировщик fifo обладает такими способностями.
В начало страницы
PBS использует полные квалификационные имена хостов для идентификации
заданий и мест их размещений. Пакетная система PBS известна по имени хоста, на
котором работает Сервер pbs_server. Имя, используемое демонами, или
используемое для удостоверения сообщений, есть каноническое имя хоста. Это имя
берется из первичного поля имени, h_name, в структуре, выдаваемой по
библиотечному вызову gethostbyaddr(). В соответствии с нашим представлением
о IETF RFCs, это имя должно быть полностью квалифицированным и совместимым
с любым адресом IP, присвоенным данному хосту.
Три демона и команды будут пытаться использовать /etc/services для
идентификации стандартных номеров портов, используемых при коммуникациях.
Номера портов не должны быть меньше магического числа 1024. Служебные
имена, которые должны добавляться к /etc/services, есть
pbs 15001/tcp # pbs server (pbs_server)
pbs_mom 15002/tcp # mom to/from server
pbs_resmom 15003/tcp # запрос mom на управление ресурсами
pbs_resmom 15003/udp # запрос mom на управление ресурсами
pbs_sched 15004/tcp # планировщик
Перечисленные номера по умолчанию используются рассматриваемой версией PBS.
Если вы их измените, используйте одни и также номера на всех системах.
Заметим, имя pbs_resmom взято из ранних версий PBS, с разными демонами
для выполнения заданий (pbs_mom) и управления ресурсами (pbs_resmon).
Обе функции были совмещены в pbs_mom, хотя термин "resmom" можно найти
в ссылках на объединенные функции.
Если услуги не находятся в /etc/services, компоненты PBS используют по
умолчанию перечисленные выше номера.
Если Сервер запущен с нестандартным номером порта, см. параметр -p в
pbs_server(8) man page. Именем Сервера становится host_name.domain:port,
где port есть используемый номер порта. См. дискуссию об Alternate Test
Systems, раздел 6.4.
В начало страницы
Все три "демонических" процесса, Сервер, Планировщик и Mom, должны исполняться
с реальным и эффективным корневым uid. Обычно демоны запускаются из
системных загрузочных файлов, например, /etc/rc.local. Однако рекомендуется,
чтобы Сервер запускался "вручную" в первый раз и конфигурировался до
запуска во время загрузки.
В начало страницы
Mom должен запускаться во время загрузки. Обычно не требуются никакие
параметры. Лучше, если Mom запускается до Сервера и будет готов ответить на
Серверское "are you there?". Запускается Mom строкой
{sbindir}/pbs_mom
в /etc/rc2 или эквивалентном загрузочном файле.
@@@@@@
Если Mom не работает, а система на хосте продолжает функционировать, Mom
должен быть перезапущен одним из следующих параметров:
-p Это предписывает Mom разрешить исполняемым заданиям продолжать
исполняться. Так как он не является больше родителем заданий, он не будет
извещен (SIGCHLD), когда они скончаются и должен опрашивать и
по поводу завершения. Поэтому информация о состоянии ресурсов может
оказаться неточной.
-r Это побудит Mom убить все задания, оставленные исполняющимися. См.
ERS для получения подробных объяснений.
Без параметров -p или -r Mom будет считать, что процессы заданий не
существуют по причине перезапуска системы, или холодного старта. Он
не будет убивать процессы и попросит , чтобы все задания, которые
исполнялись до перезапуска системы, были возвращены в очередь.
По умолчанию Mom только примет связи от привилегированных портов своей
системы, или от порта "localhost" или от имени, возвращенного по
gethostname(2). Если Сервер или Планировщик работают на другом хосте,
его имя (или имена) должны быть указаны в конфигурационном файле Mom.
См. параметр -c на pbs_mom(8B) man page и в настоящем руководстве
раздел 3.6, Конфигурация исполнительного Сервера pbs_mom, информацию о
конфигурационном файле.
Если хотите воспользоваться средствами сценария пролога и/или эпилога,
см. раздел 6.2 "Job Prologue/Epilogue Scripts".
В начало страницы
Начальный запуск Сервера или любой первый запуск после пересоздания начального
каталога должен производиться с созидательным параметром -t. Этот параметр
побуждает Сервер создать новую базу данных сервера. Лучше всего сделать это
вручную. Если база уже есть, она отбрасывается после получения позитивного
подтверждения. В этой точке необходимо конфигурировать Сервер. См. раздел
3.5, Конфигурирование Сервера. Параметр создания оставляет Сервер в
состоянии " холостого хода". В этом состоянии Сервер не контактирует с
Планировщиком и задания не выполняются, кроме как вручную через команду
qrun(1B). Раз Сервер ожил, он может быть переведен в активное состояние
установкой атрибута планирования на значение true:
qmgr -c "set server scheduling=true"
Значение scheduling сохраняется между состояниями Сервера terminations/starts.
После того как Сервер конфигурирован, он может быть введен в действие.
Нормально он запускается в загрузочном файле системы такой строкой:
{sbindir}/pbs_server
Параметр -t start_type может быть указан там, где start_type есть один из
параметров, перечисленных в ERS (и в pbs_server man page). Умолчание есть
warm. Другой полезный параметр есть -a true|false. Он устанавливает
в состояние on|off вызов Планировщика заданий PBS.
В начало страницы
Планировщик также должен запускаться во время загрузки. Запускается он
строкой в /etc/rc2 или эквивалентном файле:
{sbindir}/pbs_sched [options]
Никакие параметры не требуются для стандартного Планировщика fifo.
Для BaSL based Планировщика обычно требуется только параметр -c config_file,
определяющий конфигурационный файл. Для основанного на Tcl Планировщика
параметр нужен для указания вызова сценария Tcl.
В начало страницы
Дело сводится к конфигурации атрибутов Сервера и определению очередей и их
атрибутов. В отличие от Mom и Планировщика заданий, Сервер заданий
(pbs_server) конфигурируется во время работы, за исключением файла узлов.
Конфигурирование сервера и атрибутов очередей и создание очередей производится
командой qmgr(1B). Это требует либо корневой привилегии, либо может сделано
пользователем, который получил привилегию менеджера PBS, как показано в
последнем шаге в разделе Обзор Построения настоящего руководства. Точно то,
что необходимо сделать, зависит от вашей политики планирования и того, как
вы хотите ее реализовать. Система нуждается в установке, по крайней мере одной
очереди и инициализации некоторых атрибутов Сервера.
Атрибуты Сервера рассмотрены в разделе 2.4 документа ERS. Приведем ниже
"минимально требуемый" список атрибутов сервера и рекомендуемые атрибуты.
В качестве примера, предположим, что ваш сайт есть подобласть обширной сети
и все хосты на вашем сайте имеют имена вида:
host.foo.bar.com
а пакетная система состоит из одной большой машины с именем big.foo.bar.com.
В начало страницы
Следующие атрибуты необходимы или рекомендуются. Они устанавливаются по
подкоманде set server (s s) команды qmgr(1B).
Здесь рассматриваются не все атрибуты Сервера, а только те, что нужны для
создания и запуска разумной системы. См. pbs_server_attributes man page,
где приведен полный список атрибутов сервера.
В начало страницы
default_queue
Определяет по умолчанию очередь, которой подчинены задания, если очередь
не определена по команде qsub(1B). Очередь создается в самом начале.
Пример:
Qmgr: c q dque queue_type=execution
Qmgr: s s default_queue=dque
В начало страницы
acl_hosts
Список хостов, с которых могут поступать задания. Например, если хотите
разрешить это всем системам вашей подобласти плюс один внешний хост, boss,
в главном управлении, то установите:
Qmgr: s s acl_hosts=*.foo.bar.com,boss.hq.bar.com
acl_host_enable
Разрешает доступ с Серверного хоста к контрольному списку, приведенному
выше.
Qmgr: s s acl_host_enable=true
default_node
Определяет узел, на котором выполняются задания, если нет других указаний.
См. раздел 3.2.3, Где задания могут исполняться, где говорится, как
устанавливается этот атрибут в зависимости от конкретной системы.
Значение по умолчанию (а также подразумеваемое значение, если атрибут
есть, но не установлен) есть 1#shared.
Qmgr: s s default_node=big
Заметим, что значение можно указать или как big или big.foo.bar.com.
Если имеется файл узлов, значение должно точно совпадать с именем,
указанным в файле узлов. Т.е. big или big.foo.bar.com в обоих местах.
managers
Определяет, какие пользователи, на указанном хосте, имеют привилегию
администратора пакетной системы. Например, чтобы гарантировать привилегию
для "me" на всех системах подобласти и для "sam" только с системы
big, нужно:
Qmgr: s s managers=me@*.foo.bar.com,sam@big.foo.bar.com
node_pack
Определяет порядок, в котором кратные центральные процессоры
кластерных узлов отводятся для заданий. См. дискуссию в разделе
3.2.3, Где задания могут исполняться. Если атрибут установлен, то
внутренний список узлов сортируется по количеству свободных VP.
Если установлено true, задания упаковываются в возможно меньшее
количество узлов. Если установлено false, задания разбрасываются по
возможно большему количеству узлов. Если значение атрибута не
установлено, задания размещаются по узлам в порядке, в котором узлы
объявлены в Сервере.
operators
Определяет, какие пользователи, на указанном хосте, имеют привилегию
оператора пакетной системы. Указываются, так же как и в managers.
query_other_jobs
Эти атрибуты определяют возможность доступа к статусу (qstat) заданий,
принадлежащих другим пользователям. Если он не имеет значения или
установлен на False, то пользователи не могут спрашивать статус не
своего задания. Большинство сайтов хочет устанавливать этот атрибут на
True:
Qmgr: s s query_other_jobs=true
resources_defaults
Этот атрибут определяет предел ресурсов, предоставляемых заданиям,
которые были поставлены без лимитов и для которых лимиты не определены
их очередью. Важно, чтобы значение предела по умолчанию было присвоено
для заявок на все ресурсы, используемые в стратегии планирования.
См. pbs_resources_* man page для систем вашего типа (* означает
irix6, linux, solaris5, ...).
Qmgr: s s resources_defaults.cput=5:00
Qmgr: s s resources_defaults.mem=4mb
resources_max
Этот атрибут определяет максимальное количество ресурсов, которые могут
использоваться заданием, поступающим в любую очередь на Сервере. Этот
предел проверяется только если нет в очереди специального атрибута
resources_max, определенного для конкретного ресурса.
В начало страницы
Имеются два типа очередей, определенных в PBS: трассировка и исполнение.
Очередь на трассировку используется для заданий при постановке в другие
очереди, которые даже могут располагаться на разных Серверах PBS.
Трассировочные очереди подобны старым конвейерным очередям NQS. Задания в
очереди на исполнение должны быть готовы к запуску. Они остаются в этой
очереди на все время исполнения.
Сервер может иметь много очередей того и другого типа. Он обязан иметь по
крайней мере одну очередь. Обычно это очередь на исполнение; задание не может
исполняться, если находится в трассировочной очереди.
Атрибуты очередей делятся на три группы: применимые к обоим типам очередей,
применимые только к исполнительской очереди и применимые только к
трассировочной очереди. Если атрибут "только для исполнительской очереди"
применен к трассировочной очереди, или наоборот, он игнорируется системой.
Однако, если такая ситуация может указывать на ошибку администратора, Сервер
Выдает предостережение о конфликте. То же сообщение будет выдано, если тип
очереди изменится и имеются атрибуты, не соответствующие новому типу.
Здесь обсуждаются не все атрибуты очередей, а только те, которые необходимы
для образования и функционирования разумной системы. См. pbs_queue_attributes
man page, где имеется полный список атрибутов.
В начало страницы
queue_type
Устанавливается на execution или routing (достаточно e или r) .
Тип очереди должен быть установлен до ее задействования. Если тип
вступает в конфликт с некоторым атрибутом, который годится только для
очереди другого типа, запрос на установку отвергается Сервером.
Qmgr: s q dque queue_type=execution
enabled
Если установлен на true, задания могут поступать в очередь. Если false,
то задания не принимаются.
Qmgr: s q dque enabled=true
started
Если установлен на true, задания из очереди будут обрабатываться: или
трассироваться Сервером, если очередь трассировочная, или рассматриваться
планировщиком, если очередь исполнительная.
Qmgr: s q dque started=true
В начало страницы
route_destinations
Список локальных очередей или очередей в других Серверах, в которые
могут передаваться задания из трассировочной очереди. Например:
Qmgr: s q routem route_destinations=dque,overthere@another.foo.bar.com
В начало страницы
resources_max
Если вы предпочли иметь более одной исполнительской очереди на основании
размеров или типов заданий, вам может понадобиться установить максимальное
и минимальное значения для пределов различных ресурсов. Это будет
ограничительным признаком для заданий, отбираемых в очередь.
Трассировочные очереди могут образовываться для "питания" исполнительных
очередей, и задания будут автоматически рассортировываться по таким
лимитам.
Значение resources_max, определенное для некоторого ресурса на уровне
очереди, подавит для того же ресурса значение resources_max,
определенное на уровне Сервера. Поэтому можно определять как большие,
так и меньшие значения лимитов для очереди, чем соответствующие лимиты
у Сервера. Если для некоторого типа ресурса не определено максимальное
значение, то на этот ресурс нет ограничений. Например:
s q dque resources_max.cput=2:00:00
накладывает ограничение не принимать в очередь заданий, требующих более
2 часов машинного времени. На количество требуемой памяти, mem, в этой
очереди ограничений нет.
resources_min
Определяет минимальное значение лимита на ресурс, указываемое
в задании, перед постановкой в очередь. Если не установлен, ограничения
снизу нет.
В начало страницы
resources_default
Определяет множество значений по умолчанию для поступающих в очередь
заданий, в которых отсутствуют лимиты на ресурсы. Имеется соответствующий
атрибут Сервера, который устанавливает значения по умолчанию для всех
заданий.
Предел на определенный ресурс устанавливается обследованием различных
атрибутов заданий, очередей и сервера. Следующий список показывает
атрибуты и их приоритетный порядок;
1. Resource_List атрибутов задания, т.е. что было указано пользователем. i.e. what was
2. resources_default атрибутов очереди.
3. resources_default атрибутов Сервера.
4. resources_max атрибутов очереди.
5. resources_max атрибутов Сервера.
* Для Unicos, указанное пользователем значение должно лежать в
пределах, указанных для пользователей в системной User Data Base,
UDB. Если пользователь значения не указал, берется наименьшее
значение из указанных в предыдущем списке и в UDB.
Отметим, что не установленный предел ресурса для задания рассматривается
как бесконечный лимит.
В начало страницы
Часто желательно направлять задания в различные очереди на одном Сервере
или даже в различные Серверы на основании заявляемых ими требований на
ресурсы. Атрибуты очереди resources_min и resources_max , рассмотренные
выше, делают возможной такую отборочную трассировку. Предположим для
примера, что нужно установить две очереди на исполнение, одну для коротких
заданий меньше чем на 1 минуту времени cpu и другую для заданий на 1 мин.
или дольше. Назовем их соответственно короткими и длинными. Используем
атрибуты resources_min и resources_max следующим образом:
Qmgr: set queue short resources_max.cput=59
Qmgr: set queue long resources_min.cput=60
Когда задание направляется в очередь, запрошенный им ресурс сравнивается с
лимитами очереди:
resources_min <= job_requirement <= resources_max.
Если этот тест не проходит, задание не принимается в очередь. Поэтому
задание, запрашивающее 20 секунд, будет принято в очередь коротких, и не
принято в очередь длинных.
Заметим, что если min и max лимиты равны, только это точное значение
пройдет через тест.
Вы можете установить трассировочную очередь для посылки заданий в очереди
по лимитам на ресурсы. Например так:
Qmgr: create queue feed queue_type=routing
Qmgr: set queue feed route_destinations="short,long"
Qmgr: set server default_queue=feed
Задание будет направлено в конец очереди коротких или длинных в зависимости
от его заявки на время.
Нужно всегда перечислять очереди назначения в порядке: сначала наиболее
ограничительные, для того чтобы первая очередь, которая отвечает запросу
задания, стала его очередью назначения (в предположении, что она задействована
(enabled)). Распространим предыдущий пример на три очереди:
Qmgr: set queue short resources_max.cput=59
Qmgr: set queue long resources_min.cput=1:00,resources_max.cput=1:00:00
Qmgr: create queue verylong queue_type=execution
Qmgr: set queue feed route_destinations="short,long,verylong"
Задание, которое просит 20 минут времени процессора, (20:00), будет помещено
в очередь long. А задание, которое просит 1 час и 10 минут, (1:10:00),
поступит в конец очереди verylong по умолчанию.
Заметьте, если тест основан на ресурсе, как показано выше на примере времени,
а в задании не указан этот тип ресурса (его нет в -l resource=value list
в команде qsub), то тест будет пройден. В предыдущем случае, задание без
лимита на время будет допущено в очередь коротких. По этой причине, вместе с
фактом, что не установленный предел рассматривается как бесконечный, вы можете
по желанию добавить значение по умолчанию в очереди или в Сервер. Либо
Qmgr: set queue short resources_default.cput=40
либо
Qmgr: set server resources_default.cput=40
будет следить за тем, чтобы задание без указания времени ограничивалось
40 секундами. Атрибут resources_default на уровне очереди относится только к
заданиям в этой очереди.
Помните о трех фактах:
1. Если присваивается значение по умолчанию, это делается после тестов
на min и max.
2. Значения по умолчанию, присвоенные заданию от resources_default
в очереди, не переносятся с заданием, если оно переходит в другую очередь.
Если новая очередь указывает значения по умолчанию, эти значения присваиваются
заданию, пока оно находится в новой очереди.
3. Значения по умолчанию на уровне Сервера используются, если в очереди
нет своих значений по умолчанию.
В предыдущем примере атрибут по умолчанию должен применяться и на уровне
сервера и на уровне трассировочной очереди.
Минимальный и максимальный пределы очереди работают с численными значениями
ресурсов, включая значения времени и размеров. Вообще говоря, они не работают
с значениями-цепочками вследствие символьного порядка сравнения. Однако,
установка min и max для тех же значений приводит к правильным сравнениям
даже для значений-цепочек. Например,
Qmgr: set queue big resources_max.arch=unicos8
Qmgr: set queue big resources_min.arch=unicos8
можно использовать для ограничения заданий, поступающих в очередь big теми,
у которых arch=unicos8. Опять напомним, что если arch не указан в задании,
тест проходится автоматически и задание будет принято в очередь.
Можно установить пределы для очереди (и Сервера) на то, как много узлов
задание может запросить. Узловой ресурс сам есть текстовая цепочка, что
трудно для ограничения. Однако, для заданий существуют два дополнительных
ресурса Read-Only. Это nodect и neednodes. Nodect (счет узлов)
устанавливается Сервером на целое число узлов, нужное пользователю и
объявленное в спецификации ресурсов "nodes". Это объявление анализируется
и соответствующее число устанавливается в nodect. Это полезно, когда
администратор хочет поместить лимит-целое, resources_min или resources_max,
на число узлов для задания, принимаемого в очередь.
Возвращаясь к приведенному ранее примеру объявления узлов, если пользователь
запрашивает следующие узлы (см. раздел 7.2 Параллельные задания):
3:marx+2:stooge
то nodect будет установлен на 5 (3+2). Neednodes первоначально устанавливается
Сервером на то же значение, что и nodes. Neednodes может быть
изменен Планировщиком в специальной стратегии. Содержимое neednodes
определяет, какие узлы фактически отводятся заданию. Neednodes видим для
администратора, но невидим для непривилегированного пользователя.
Если вы хотите установить в очереди значение по умолчанию для "nodes"
(значение, устанавливаемое для ресурса, если его не указал пользователь),
соответствующие значения по умолчанию должны быть установлены для "nodect"
и "neednodes". Например
Qmgr: set queue foo resources_default.nodes=1
Qmgr: set queue foo resources_default.nodect=1
Qmgr: set queue foo resources_default.neednodes=1
Минимальный и максимальный лимиты должны устанавливаться только для "nodect".
Например:
Qmgr: set queue foo resources_min.nodect=1
Qmgr: set queue foo resources_max.nodect=15
Минимальное и максимальное значения не должны устанавливаться для nodes или
neednodes, поскольку это значения-цепочки.
В начало страницы
Если вы хотите записать конфигурацию сервера для повторного использования,
можно воспользоваться подкомандой print команды qmgr(8B). Например,
qmgr -c "print server" > /tmp/server.con
запишет в файл server.con подкоманды qmgr, нужные для воссоздания
текущей конфигурации, включая очереди. Команды могут быть посланы в обратно
в qmgr via через стандартный ввод:
qmgr < /tmp/server.con
В начало страницы
Mom конфигурируется через конфигурационный файл, который он читает во время
инициализации и когда послан сигнал SIGHUP. Этот файл описан в pbs_mom(8)
man page и в следующем разделе.
Если параметр -c не указан при исполнении Mom, он откроет
PBS_HOME/mom_priv/config, если такой имеется. Если нет, Mom все равно
продолжит работу. Этот файл может располагаться где угодно или получить
другое имя, и в этом случае pbs_mom должен запускаться с параметром -c.
Этот файл обеспечивает получение нескольких типов информации во время
исполнения pbs_mom: имена статических ресурсов и значений, внешних ресурсов
ресурсов, приготовленных программами, исполняемыми по запросам через выход в
оболочку и значений для передачи внутренним установочным функциям при
инициализации (и повторной инициализации).
Единица каждого типа располагается в отдельной строке, компоненты разделяются
белыми пробелами. Если строка начинается с хеш (т.е с #), она считается
комментарием и пропускается.
В начало страницы
Директива начальных значений имеет имя, начинающееся со знака доллара ($) и
должна быть известна Mom посредством внутренней таблицы. Сейчас входы в эту
таблицу такие:
clienthost
Вход $clienthost добавляет имя хоста к списку хостов, которым разрешено
связываться с Mom, когда они используют привилегированный порт.
Например, вот две строки для конфигурационного файла, которые позволят
связываться хостам "fred" и "wilma":
$clienthost fred
$clienthost wilma
Два хоста, с именами "localhost" и именем, возвращаемым pbs-nom по
системному вызову gethostname(), всегда могут связаться с pbs_mom. Эти
имена не нужно указывать в конфигурационном файле. Хосты, числящиеся как
"clienthosts", составляют "sisterhood" (братство) среди хостов. Любой
из sisterhood будет принимать связь от Планировщика [Resource Monitor
(RM) запросы] или Сервера [задания для исполнения], поступающую из
пределов sisterhood. Они также принимают внутренние сообщения от Mom
(IM-сообщения), поступающие из пределов sisterhood. Чтобы члены
sisterhood были в состоянии обмениваться IM-сообщениями друг с другом,
они должны совместно использовать один и тот же RM port.
Чтобы Планировщик был в состоянии запрашивать от Mom информацию о
ресурсах, хост Планировщика должен числиться как clienthost.
Если Сервер снабжен файлом узлов, то IP-адреса хостов (узлов) в файле
будут переданы Сервером к Mom на каждом хосте, перечисленном в файле
узлов. Эти хосты не обязаны быть в различных конфигурационных файлах
для Mom, поскольку они передаются к Mom внутренним образом, когда список
получается им от Сервера. Хост Сервера должен быть или тем же хостом,
на котором расположен Mom или указан как вход clienthost entry в
каждом конфигурационном файле Mom.
restricted
Вход $restricted предписывает добавить имя хоста к списку хостов,
которым разрешается связываться с Mom не обязательно через
привилегированный порт. Эти имена допускаются для универсального
сопоставления (wildcard matching). Например, вот строка конфигурационного
файла, которая разрешает запросы от любого хоста из области "ibm.com":
$restricted *.ibm.com
Связи от указанных хостов ограничиваются в том, что можно делать только
внутренние запросы. Ни о каких ресурсов не будет
сообщаться от config-файла и никакие управляющие запросы не будут
выдаваться. Это должно предохранить всякие оболочечные команды от
от запуска их не корневыми процессами.
Этот вид входа обычно используется для указания хостов, на которых могут
исполняться средства мониторинга, такие как xpbsmon. Xpbsmon может
запрашивать у Mom общую информацию о ресурсах.
logevent
Вход $logevent устанавливает маску, которая определяет тип событий,
регистрируемых демоном pbs_mom. Например:
$logevent 0x1ff
$logevent 255
Первый пример должен установить маску log event mask на 0x1ff (511),
что задействует регистрацию всех событий, включая отладочные. Второй
пример устанавливает маску 0x0ff (255), которая задействует все
события, кроме отладочных. Значения событий перечислены в разделе 6.3
Использование и поддержка журнала регистраций.
ideal_load
Директива $ideal_load объявляет low water mark (отметку нижнего уровня)
для загрузки узла. Она работает вместе с директивой $max_load directive.
Когда средняя нагрузка на узел опускается ниже ideal_load, Mom на узле
сообщает серверу, что узел больше не занят. Например:
$ideal_load 2.0
$max_load 3.5
max_load
Директива $max_load обявлет отметку верхнего уровня для нагрузки узла.
Она работает вместе с директивой $ideal_load. Когда средняя нагрузка
превышает отметку верхнего уровня, Mom на узле извещает Сервер, что
узел занят. Состояние узла будет показано как busy. Занятый кластерный
узел не будет распределяться заданиям. Это полезно для предотвращения
передачи заданий на узлы, которые заняты интерактивными сеансами.
Занятый разделяемый во времени узел может продолжать выполнять новые
задания под управлением Планировщика. Обе директивы, $ideal_load и
$max_load, добавляют статический ресурс, ideal_load и max_load,
который может быть запрошен Планировщиком. Эти ресурсы поддерживаются
по умолчанию планировщиком FIFO при распределении заданий.
См. дискуссию о планировщиках FIFO для дополнительной информации.
usecp Если Mom должен перенести файл на хост, отличный от того, на котором
находится он сам,
Mom обычно использует для его передачи scp или rcp. Это происходит на
стадиях ввода-вывода и при доставке стандартных выводов заданий или
сообщений об ошибках. [Советуем изучить параметры -o и -e для qsub,
qsub(1) в man page и раздел 3.3.5, Окончание заданий, в документе ERS,
чтобы понимать соглашение о названиях для стандартных выходных файлов и
файлов с сообщениями об ошибках.] Назначение записывается как
hostx:/full/path/name.
Так что если hostx --- не тот, на котором исполняется Mom, то он
использует scp или rcp; если же система та же, Mom использует
/bin/cp.
Если файловая система-назначение есть NFS, смонтированная среди всех
систем в окружении PBS (кластер), то cp может работать
лучше, чем s/rcp. Одна или больше директив $usecp в конфигурационном
файле могут использоваться для информации Mom о том, на какой файловой
системе команда cp может использоваться вместо s/rcp. Вход $usecp
имеет вид:
$usecp host_specification:path_prefix substitute_prefix
host_specification есть или полное квалифицированное host-domain имя
или универсальный символ для спецификации host-domain, как это
используется в Серверском атрибуте host ACL. path_prefix есть
ведущая компонента вполне квалифицированного пути для файлов NFS
на указанном хосте. substitute_prefix есть начальные компоненты
пути к тем же самым файлам на том хосте, где расположен Mom. Если
используются разные точки монтировки, то path_prefix и
substitute_prefix будут разными. Если те же точки монтировки
используются для файловой системы, которая смонтирована накрест (cross
mounted), то оба префикса будут теми же самыми.
Если задано место назначения файла, то Mom предпримет следующие
действия:
1. Сопоставит host_spec и имя своего хоста. Если они совпадают,
Mom будет использовать команду сp для переноса файла. Если
hostspec есть localhost, то Mom также использует cp.
2. Если на первом шаге соответствие не обнаружено, Mom сравнивает
хост-порцию имени назначения последовательно с каждой $usecp
хост-спецификацией. При совпадении Mom сравнивает path_prefix
с начальным сегментом имени назначения. Если они совпадают, Mom
отбрасывает имя хоста, заменяет начальный сегмент пути, который
совпал с path_prefix, на substitute_prefix и использует cp
с полученным именем назначения.
3. Если хост не есть локальный хост и не соответствует ни одной
директиве usecp, то Mom использует для переноса файла команду
rcp.
Например, пользователь представил на хост myworkstation.company.com
задание, в то время как его текущий рабочий каталог есть
/u/wk/her_home/proj. Назначение для его вывода
PBS выдает как myworkstation.company.com:/u/wk/her_home/proj/123.OU
Задание исполняется на хосте pool2.company.com, который имеет
основную файловую систему пользователя смонтированной накрест (cross
mounted) как /r/home/her_home. Тогда каждая из следующих строк в
файле конфигурации на pool2
$usecp myworkstation.company.com:/u/wk/ /r/home/
$usecp *.company.com:/u/wk/ /r/home/
приведет к копированию по cp в
/r/home/her_home/proj/123.OU вместо копирования по rcp в
myworkstation.company.com:/u/wk/her_home/proj/123.OU.
Заметим, что назначение сопоставляется с входами $usecp в порядке,
указанном в конфигурационном файле. Первое соответствие между префиксами
хоста и файла определяет подстановку. Следовательно, если мы имеем ту же
файловую систему, смонтированную на /foo на HostA и на /bar на всех
других хостах, то входы для pool1 должны располагаться в следующем
порядке
$usecp HostA.company.com:/foo /bar
$usecp *.company.com:/bar /bar
cputmult
Вход $cputmult устанавливает коэффициент, используемый для установки
времени центрального процессора, израсходованного заданием. Это сделано,
для возможности устанавливать соответствие затраченного времени с
принудительными пределами там, где задание может исполняться на
системах с другими по производительности процессорами. Если система с
Mom быстрее чем исполнительная система, установите cputmult на
десятичное значение, большее чем 1.0. Если система Mom медленнее,
установите cputmult на значение между 1.0 and 0.0. Значение
определяется так:
value = speed_of_this_system / speed_of_reference_system
Например:
$cputmult 1.5
или
$cputmult 0.75
wallmult
Вход $wallmult устанавливает коэффициент, используемый для приведения
wall time, используемого в задании, к общей справочной системе.
Коэффициент используется в подсчетах walltime и пределов, так же как
cputmult используется для времени центрального процессора.
prologalarm
Вход $prologalarm устанавливает период тайм-аут в секундах для
сценариев пролога и эпилога. Аварийный сигнал устанавливается для
предупреждения блокировки задания сценарием, если сценарий зависнет
или займет слишком много времени своим исполнением. По умолчанию
это значение составляет 30 секунд. Пример:
$prologalarm 60
В начало страницы
Для имен и значений статических ресурсов конфигурационный файл
содержит список пар имя/значение, разделенных белым пробелом, по одной паре
в строке. Примером имен и значений статических ресурсов может служить набор
различных типов лентопротяжек, описанный с помощью
tape3480 4
tape3420 2
tapedat 1
tape8mm 1
Имена могут быть любыми, не ограничиваясь существующей аппаратурой. Например,
строка pong 1 может использоваться для сообщения Планировщику, что
определенный тип аппаратуры имеется на этой системе.
В начало страницы
Если первый символ в части значения в паре имя/значение есть восклицательный
знак (!), весь остаток строки сохраняется для выполнения службами
system(3) standard library routine. Первая строка выхода от команды
оболочки выдается в качестве ответа на запрос ресурса.
Выход оболочки предоставляет для монитора ресурсов средство выдать произвольную
информацию для Планировщика. Происходит замена параметров, так что значение
любого описателя, посланного с запросом ресурса, заменяет, как это объясняется
ниже, ярлык с знаком процента (%) и последующим названием
описателя. Вот пример строки конфигурационного файла с ресурсом по имени
"escape":
escape !echo %xxx %yyy
Если запрос на "escape" посылается без описателей, то будет выполняться команда
"echo %xxx %yyy". Если посылается один описатель, "escape[xxx=hi there]",
то выполняемая команда будет такой:
"echo hi there %yyy". Если посылаются два описателя,
"escape[xxx=hi][yyy=there]", выполнена будет команда:
"echo hi there". Если посылается описатель, не соответствующий ярлыкам в
командной строке, "escape[zzz=snafu]", выдается сообщение об ошибке.
Другой пример позволяет Планировщику получить запрос Mom о существовании файла.
В конфигурационный файл Mom должна быть помещена такая строка:
file_exists !if test -f %file; then echo yes; else echo no; fi
Тогда строка запроса "file_exists[file=/tmp/lockout]" вернет "yes", если
файл существует, и "no" , если его нет.
Другое возможное использование конфигурационной строки команды оболочки
состоит в обеспечении средства, с помощью которого можно проследить
использование лицензий на плавающее программное обеспечение. Если может
быть написана программа опроса лицензионного сервера, то количество доступных
лицензий может быть получено, чтобы сообщить планировщику, может ли он
запустить задание, которое нуждается в определенном лицензионном пакете.
[Попробуйте для забавы написать эту программу.]
В начало страницы
В следующих примерах мы предполагаем, что ваш сайт есть "The Widget Company"
и имя вашей области есть "widget.com". Первый пример есть пример конфиг-файла
для pbs_mom, где пакетная система есть отдельная большая система. Мы хотим
регистрировать большинство записей и указать что система имеет 1 8mm
лентопротяжный привод.
$logevent 0x0ff
tape8mm 1
Если Планировщик для большой системы окажется расположенным на машине
переднего с именем fe.widget.com, и вы хотите разрешить ему доступ к Mom,
то конфигурационный файл будет:
$logevent 0x0ff
$clienthost fe.widget.com
tape8mm 1
Теперь центр расширился до двух больших систем. Новая система имеет два
лентопротяжных механизма и быстрее старой на 30%. Вы хотите получать с
пользователей одну и туже плату независимо от того, где исполняются их задания. faster than the old
Основываясь на плате в старой системе, вам нужно время, использованное в
новой системе, умножать на 1.3 для сохранения таксы по старой шкале.
Конфигурационный файл для старой системы остается прежним.
Конфигурационный файл для новой системы таков:
$logevent 0x0ff
$clienthost fe.widget.com
$cputmult 1.3
$wallmult 1.3
tape8mm 2
Теперь вы сложили вместе кластер процессоров, исполняющих Linux с именем
"bevy", в bevy процессоров. Планировщик и Сервер работают на
bevyboss.widget.com, который также имеет пользовательскую основную файловую
систему, смонтированную как /u/home/... Узлы называются bevy1.widget.com,
bevy2.widget.com, и т.д. Пользовательские основные файловые системы есть
NFS, смонтированные как /r/home/... Ваша личная рабочая станция есть
adm.widget.com и на ней вы планируете выполнять xpbsmon для управления
кластером. Тогда конфигурационный файл для каждого Mom должен выглядеть так:
$logevent 0x1ff
$clienthost bevyboss.widget.com
$restricted adm.widget.com
$usecp bevyboss.widget.com:/u/home /r/home
В начало страницы
Конфигурация, требуемая для Планировщика, зависит от самого планировщика.
Если начинаете с стандартного Планировщика fifo. переходите к разделу
4.5.1 "Планировщик FIFO" в этом руководстве.