7. Совет пользователям
В начало страницы
Следующие разделы обеспечивают информацию, необходимую для всех пользователей
системы PBS. Постарайтесь сделать ее доступной для всех.
В начало страницы
Задание пользователя может не запуститься, если стартующие файлы
пользователя (.cshrc, .login, или .profile) содержат команды, которые
пытаются установить терминальные характеристики. Всякая такая активность
должна быть убрана помещением теста переменной окружения PBS_ENVIRONMENT
(или для NQS совместимости, ENVIRONMENT). Это можно сделать, как показано
в следующем примере для .login:
setenv PRINTER printer_1
setenv MANPATH /usr/man:/usr/local/man:/usr/new/man
if ( ! $?PBS_ENVIRONMENT ) then
do terminal stuff here
endif
Если пользовательская оболочка login есть csh, то следующее сообщение
может появиться в стандартном выходе задания:
Warning: no access to tty,
thus no job control in this shell
(Внимание: доступа к tty нет,
поэтому никакого управления заданием в этой
оболочке).
Это сообщение выдается многими версиями csh когда оболочка
обнаруживает, что ее ввод идет не с терминала. Кроме модификации csh, нет
путей для исключения этого сообщения. К счастью, это только информационное
сообщение, не влияющее на задание.
В начало страницы
Если вы поставили PBS для управления кластером систем или на параллельную
систему, вероятно, вы хотите управлять параллельными заданиями. Как говорилось
в разделе 2.1 "Планирование# и 3.2 "Кратные исполнительные системы", PBS,
которая отводит узлы одному заданию на все его время, называется
пространственно разделяющей. Важно помнить, что целый узел отводится заданию
независимо от числа процессоров и количества памяти в узле.
Чтобы PBS отвела узлы заданию пользователя, пользователь должен указать,
сколько и какого типа узлы требуются для задания. А затем параллельное задание
пользователя должно выполнять задачи на отведенных узлах.
В начало страницы
Объект, называемый списком узловых ресурсов (nodes resources_list),
устанавливается пользователем для объявления узлов, требующихся заданию.
Это есть цепочка вида
-l nodes=node_spec[+node_spec...]
где node_spec есть
number | property[:property...] | number:property[:property...]
В конец node_spec может быть добавлен глобальный модификатор.
Он имеет вид #property. Например:
6+3:fat+2:fat:hippi+disk
или
6+3:fat+2:fat:hippi+disk#prime.
Здесь fat, hippi и disk --- примеры имен свойств, присвоенных
администратором в файле {PBS_HOME}/server_priv/nodes. Предыдущий пример
переводится как запрос пользователя на 6 простых узлов плюс 3 "fat"
узла плюс 2 узла, которые одновременно "fat" и "hippi" плюс один узел
"disk", всего 12 узлов. Там где приписано #prime как глобальный модификатор,
глобальное свойство "prime" добавляется Сервером к каждому элементу в spec.
Это эквивалентно такой записи:
6:prime+3:fat:prime+2:fat:hippi:prime+disk:prime .
Основное назначение глобального модификатора состоит в обеспечении совместным
ключевым словом. Оно показывает, что все узлы должны быть временно
совместно используемыми узлами. Ключевое слово shared распознается как
таковое только если используется как глобальный модификатор.
В начало страницы
PBS предоставляет средство, благодаря которому параллельное задание может
порождать, следить и управлять задачами на отдаленных узлах. См. man
page для tm(3). К несчастью, никто из фирм-поставщиков не воспользовался
этой способностью PBS, хотя некоторые из них внесли вклад в ее проектирование.
Поэтому порождение задач в параллельном задании легло на само параллельное
окружение. PVM предоставляет одно средство, посредством которого параллельное
задание порождает процессы через демона pvmd daemon. MPI обычно имеет
зависящий от производителя метод, часто с использованием rsh или rexec.
Все эти средства лежат вне контроля PBS. PBS не может управлять использованием
ресурсов отдаленными заданиями, а только теми, которые используются заданием на
родительской вершине. PBS может только составить список отведенных узлов,
доступных для для параллельных заданий и надеяться, что поставщик и
пользователь воспользуются этим списком и не выйдут за пределы отведенных
узлов.
Имена отведенных узлов находятся в файле в {PBS_HOME}/aux. Файл принадлежит
корню, но читаем для всех. Имя файла передается в переменную окружения
PBS_NODEFILE. Для систем IBM SP оно также есть в переменной MP_HOSTFILE.
Если вы используете какую-нибудь версию MPI с открытым источником, такую как
MPICH, то команда mpirun может быть изменена для проверки окружения PBS
и использовать имеющийся в PBS хост-файл
В начало страницы
Когда PBS запускает задание, она вызывает пользовательскую регистрационную
оболочку (если только пользователь не представил задание
с параметром -S). PBS передает сценарий задания, являющийся сценарием
оболочки, в журнал одним из двух способов в зависимости от того, как PBS
была установлена.
Имя сценария на стандартном вводе
Метод по умолчанию (PBS строится с --enable-shellpipe) состоит в
передаче имени сценария задания в программу оболочки. Это
эквивалентно печати имени сценария как команды для интерактивной
оболочки. Поскольку это только строка, передаваемая сценарию,
стандартный ввод готов ее принять. Этот подход имеет и преимущества
и недостатки:
+ Любая команда, которая читает из стандартного ввода без
перенаправления, получает конец файла.
+ Синтаксис оболочки может меняться от сценария к сценарию, он не
обязан соответствовать синтаксису регистрационной оболочки
пользователя. Первоя строка сценария, даже перед любой директивой
#PBS, должна быть #!/shell, где shell есть полный путь к избранной
оболочке, /bin/sh, /bin/csh, ...
Регистрационная оболочка будет интерпретировать строку #! line и
вызывать эту оболочку для обработки задания.
- Используется лишний оболочечный процесс для обработки сценария
задания.
- Если сценарий не содержит строку с #! в качестве первой строки,
не та оболочка может пытаться интерпретировать сценарий, что
ведет к синтаксическим ошибкам.
- Если нестандартная оболочка используется через параметр -S,
она будет получать со своего стандартного входа не сценарий, а
его имя.
Сценарий как стандартный ввод
Альтернативный метод для PBS (постройка с --disable-shell-invoke),
состоит в открытии файла сценария как стандартного ввода для
оболочки. Это эквивалентно печати shell < script. Это также
имеет преимущества и недостатки:
+ Пользовательский сценарий будет всегда обрабатываться
непосредственно регистрационной оболочкой пользователя.
+ Если пользователь указывает нестандартную оболочку (любую старую
программу) с параметром -S, сценарий может читаться этой
программой, как ее ввод.
- Если команда в пределах сценария задания читает из стандартного
ввода, она может прочесть строки из сценария в зависимости от того,
как далеко перед оболочкой был буферизован ее ввод. Каждая так
прочтенная строка
не будет выполнена оболочкой. Команд, которые читают из
стандартного ввода без явного перенаправления, вообще говоря, не
не должно быть в пакетном задании.
Выбор метода вызова оболочки предоставляется сайту. Рекомендуется, чтобы
все исполнительные серверы PBS (pbs_mom) в пределах сайта были построены
для использования одного и того же метода вызова оболочки.
В начало страницы
Статус завершения задания нормально есть статус оболочки, выполняющей сценарий
задания. Если пользователь употребляет csh и имеет .login file в начальном
каталоге, выходной статус csh становится выходным статусом последней команды
в .logout. Это может повлиять на использование зависимостей задания, которые
зависят от статуса окончания задания. Чтобы сохранить статус задания,
пользователь может или убрать .logout или добавить к нему две следующие
строки. В качестве его первой строки, добавьте:
set EXITVAL = $status
и как последнюю исполнимую строку:
exit $EXITVAL
В начало страницы
Чтобы передать выходные файлы или передать устанавливаемые или убираемые файлы
к/от далеко расположенных узлов, PBS использует или rcp или scp в
зависимости от параметров конфигурации. PBS содержит источник версии команд
rcp(1), от поставки bsd 4.4 lite. Используется результирующая объектная
программа pbs_rcp(1B). Эта версия rcp дается потому, что в отличие от
некоторых других реализаций rcp, всегда заканчивается с ненулевым выходным
статусом при любой ошибке. И таким образом, Mom знает, доставлен файл или нет.
К счастью, безопасная программа копирования, scp, также опирается на эту
версию rcp и кончает с соответствующим кодом возврата.
При использовании rcp копирование выходных или устанавливаемых файлов может
окончиться неудачей по крайней мере по двум причинам.
1. Если пользовательский сценарий .cshrc выводит какие-нибудь символы на
стандартный вывод, например, по команде echo, то pbs_rcp потерпит неудачу.
См. раздел 7.1 настоящего документа.
2. Пользователь должен иметь допуск к rsh для отдаленного хоста. Вывод
доставляется в далекий хост назначения с именем владельца файла,
являющимся также именем владельца задания (представившего задание). На
исполнительном хосте файл именуется по исполнительскому имени
пользователя, которое может быть другим. Подробности см. в параметре
-u user_list в команде qsub(1) command.
Если оба имени совпадают, допуск к rcp может гарантироваться на уровне
системы по входу на хосте назначения в
файл /etc/host.equiv вызова исполнительного хоста.
Если имена владельца и исполнителя различны или если файл
/etc/hosts.equiv file на хосте назначения не содержит входа для
исполнительного хоста, пользователь должен иметь ".rhosts"-файл в
в начальном каталоге своей системы, к которому возвращаются выходные
файлы. .rhosts должен содержать вход для системы, на которой исполняется
задание, с именем пользователя, под которым задание исполняется. Хорошо
иметь две строки, одну с "базисным" именем хоста и другую с полным именем
host.domain_name.
Если PBS построена для использования Безопасной Копирующей Программы, scp, то
PBS будет сначала пытаться доставить выход или
устанавливаемые/возвращаемые файлы с помощью scp. Если она потерпит неудачу,
PBS будет пытаться использовать опять rcp [предполагая, что scp могла не
быть на отдаленном хосте]. Если rcp также не сработает, названный выше цикл
повторится после некоторой отсрочки в случае, если причиной является временная
неполадка в сети. Все ошибки регистрируются в журнале Mom'а.
Для доставки выходных файлов на местный хост PBS использует команду /bin/cp(1).
Локальная и удаленная доставки могут потерпеть неудачу по следующим
дополнительным причинам:
1. Каталог по указанному в назначении пути не существует.
2. Каталог по указанному в назначении пути пользователь не имеет права
искать.
3. Пользователь не имеет права записи в указанный каталог.
Дополнительная информация о трудностях с доставкой может быть получена из
регистрационного файла Mom'а. Все неудачи регистрируются. Различные коды
ошибок описаны в requests.c/sys_copy() в IDS.
В начало страницы
Те же самые требования и указания, которые рассматривались выше в отношении
доставки выхода, применимы в отношении установки и возвращения файлов.
Полезно заметить, что опции установки и возвращения в qsub обе имеют форму
local_file@remote_host:remote_file
безотносительно направления передачи. Так, для установки файлов направление
передачи указывается так
local_file <-- remote_host:remote_file
и для возврата направление указывается так
local_file --> remote_host:remote_file
Заметим также, что все относительные пути относятся к пользовательскому
начальному каталогу на соответствующих хостах. PBS употребляет rcp или scp
(или cp, если удаленный хост есть локальный хост), чтобы осуществить
передачу. Поэтому для установки файлов нужно только
rcp -r remote_host:remote_file local_file
а для их возвращения нужно только
rcp -r local_file remote_host:remote_file
Как и с rcp, удаленный файл может быть именем каталога. Также как с rcp,
local_file, указанный в директиве установить/возвратить, может быть именем
каталога. Для установки, если remote_file есть каталог, то локальный файл
также должен быть каталогом. При возвращении, если локальный файл есть каталог,
то remote_file также должен быть каталогом.
Если локальный файл в директиве возвращения (stage out directive) есть
каталог, то с исполнительного хоста будет скопирован весь каталог, включая все
файлы и подкаталоги. При окончании задания этот каталог, включая все файлы и
подкаталоги, будет уничтожен.
Пользователи должны знать, что это приведет к ошибкам, если другие задания
используют тот же каталог.
Установка файлов влечет и другую неприятность. Предположим, пользователь
хочет установить содержимое одного файла с именем poo и выдает следующую
директиву установки:
-W stagein=/tmp/bear@somehost:poo
Если /tmp/bear есть существующий каталог, локальный файл получает имя
/tmp/bear/poo. По окончании задания PBS определит, что /tmp/bear есть
каталог и присоединит к нему /poo. Таким образом /tmp/bear/poo будет
уничтожен. Но если пользователь хочет установить содержимое каталога с именем
cat и выдает следующую директиву:
-W stagein=/tmp/dog/newcat@somehost:cat
где /tmp/dog есть существующий каталог, то при конце задания BS определит,
что /tmp/dog/newcat есть каталог и добавит в него /cat, а затем
сделает ошибку, пытаясь уничтожить /tmp/dog/newcat/cat.
При установке, когда отдаленный файл есть каталог, пользователь не должен
указывать новый каталог как локальное имя. В предыдущем случае нужно
поступить так:
-W stagein=/tmp/dog@somehost:cat
что произведет /tmp/dog/cat, который будет означать то, что PBS будет
убирать в конце задания.
Специальные символы не должны использоваться в именах ни локальных файлов,
ни отдаленных. PBS не использует специальные символы в локальных системах.
Если же они фигурируют в именах отдаленных файлов, то, поскольку rcp
запускается там по rsh, такое распространение может произойти. Однако при
конце задания PBS будет стараться убрать файлы, чьи имена содержат специальные
символы, и не сможет их найти. Это оставит установленные файлы на месте ( т.е,
они не будут уничтожены.
В начало страницы
На системах Irix 6.5 и позднейших параллельные задания MPI, так же как и
последовательные задания, могут быть снабжены контрольными точками и
перезапускаться по системам SGI, при условии. что они удовлетворяют
некоторым критериям. Система контрольных точек SGI не может обслуживать
процессы, которые имеют открытые разъемы (sockets). Поэтому надо попросить
mpirun не создавать или закрыть открытый разъем к демону обслуживания массивов,
используемый для старта параллельных процессов. Должна использоваться одна из
двух опций mpirun:
-cpr Эта опция побуждает mpirun закрыть ее связи с демоном
обслуживания массивов, если встречается контрольная точка.
-miser Эта опция побуждает к непосредственному созданию параллельного
процесса вместо использования услуг с массивами. Это позволяет
вообще избежать связи через разъемы.
Параметр -miser представляет лучший выбор, так как в первую очередь избегает
разъемы. Если используется параметр -cpr, контрольная точка будет работать,
но медленнее, потому что сначала надо закрыть разъемную связь.
Заметим, что интерактивные задания или MPMD-задания (более чем одна
исполнимая программа) не могут иметь контрольных точек ни в каком случае.
И те и другие используют разъемы (и TCP/IP) для коммуникаций, вне задания для
интерактивных заданий и между программами в случае MPMD.