А.В. Баранов

А.О. Лацис

С.В. Сажин

М.Ю. Храмцов

С.В. Шарф

Руководство администратора системы управления прохождением задач МВС-1000/16

Введение

Предлагаемое руководство предназначено для администратора систему управления прохождением задач в системе МВС-1000/16. Руководство состоит из трех частей: описания системы управления прохождением задач с точки зрения администратора, инструкции по установке системы и описания команд администратора. Настоятельно рекомендуем обратить внимание прежде всего на первую часть руководства, без знания которой невозможно понимание логики работы системы и, как следствие, - невозможность эффективного администрирования.

1. Описание системы управления прохождением задач МВС-1000/16

1.1 Принципы функционирования системы управления прохождением задач МВС-1000/16

1.1.1 Основные понятия

Введем несколько определений.

Параллельная программа (задача) – программа (задача), состоящая из нескольких взаимодействующих процессов, каждому из которых необходим для выполнения отдельный процессор.

Вычислительный модуль – компьютер под управлением единой ОС Linux, являющийся квантом выделяемых системой ресурсов. При этом модуль может быть многопроцессорной SMP-системой.

Вычислитель – совокупность нескольких вычислительных модулей, соединенных локальной сетью и/или иной коммуникационной средой.

Параллельный ресурс - подсистема из одного или нескольких связанных процессоров вычислителя.

Управляющая ЭВМ – специально выделенный компьютер, соединенный с вычислителем локальной сетью, на котором функционирует система управления прохождением задач.

Сервер доступа – специально выделенный компьютер, обеспечивающий доступ пользователей к одной или нескольким управляющим ЭВМ. Сервер доступа является шлюзом между открытой сетью и вычислительной установкой. Функции сервера доступа и управляющей ЭВМ могут быть объединены на одном компьютере.

Многопользовательский режим работы кластера подразумевает, что на вход системы поступает поток параллельных задач от разных пользователей. Каждая из поступающих параллельных задач требует для своего исполнения определенный параллельный ресурс.

Система управления прохождением задач обеспечивает:

1. Прием входного потока.

2. Выделение для параллельной задачи требуемого параллельного ресурса.

3. При невозможности немедленного выделения требуемого ресурса – ведение очереди параллельных задач.

4. Освобождение любого занятого любой параллельной задачей ресурса в любой момент времени.

5. Удовлетворение требованиям защиты от НСД.

Предполагается, что работа пользователя будет происходить только на сервере доступа, а для контроля доступа к вычислительным узлам достаточно использовать механизмы, предназначенные для управления запуском программ с помощью команды rsh.

После компиляции программы и подготовки ее выполняемых модулей пользователь должен выдать команду для постановки этой программы в очередь задач, готовых к выполнению на вычислителе. В процессе выполнения этой команды готовится файл паспорта задачи, в который записываются параметры параллельной задачи. Также в процессе выполнения этой команды формируется командный файл, выполняемый в момент запуска программы на счет. Если ресурсы, необходимые для запуска задачи свободны, задача может сразу же начать исполняться, иначе она ставится в очередь.

Подготовленный файл паспорта задачи поступает планировщику ресурсов вычислителя. Планировщик ресурсов ведет учет занятых и свободных модулей вычислителя, на основе информации о времени выполнения задач, находящихся в очереди и требуемых им числе процессоров прогнозирует время запуска той ли иной задачи и оптимизирует процесс запуска задач согласно задаваемым планировщику задач параметрам.

При выборке очередной задачи из очереди планировщик читает паспорт задачи, выбирает вычислительные модули, на которых будет выполняться параллельная задача, открывает к ним доступ для пользователя, которому принадлежит задача и выполняет командный файл для запуска задачи. Этому командному файлу передаются в качестве параметров число и имена выделенных вычислительных модулей. Командный файл формирует конфигурационный файл для библиотеки обмена сообщениями и запускает задачу на счет.

Поле окончания счета задачи или использованием задачей времени больше заказанного планировщик ресурсов завершает все процессы, порожденные задачей на выделенных процессорах, и переходит к обработке следующей задачи, находящейся в очереди.

1.1.2 Основные принципы построения очередей

Все задачи пользователей делятся на три категории – отладочные, пакетные и фоновые.

Отладочные задачи – это короткие по времени задачи, которые запускаются исключительно в целях отладки.

Пакетные задачи – это средние по времени задачи, которые производят реальные расчеты и выполняются, не прерываясь.

Фоновые задачи – задачи с большим временем счета, которые могут прерываться системой. Для фоновой задачи пользователь должен явно указать квант – минимальное время счета фоновой задачи, в течение которого задачу прерывать нельзя.

Планирование очередей в каждый момент времени производится в соответствии с параметрами текущего режима планирования. Режим планирования определяется следующими параметрами:

- дата и время включения режима;

- максимальное время, отведенное для отладочных задач;

- максимальное время, отведенное для пакетных задач;

- максимальное число процессоров, которые в сумме могут занимать все пакетные задачи;

- шкала приоритетов пользователей.

Рассмотрим каждый параметр подробнее.

Дата и время включения определяют время, начиная с которого параметры режима вступают в силу. Параметры режима действуют вплоть до включения следующего режима.

Максимальное время, отведенное для отладочных задач, определяет время счета отладочной задачи. Если пользователь хочет сообщить системе, что его задача отладочная, то он должен указать для задачи время счета, не превышающее значение максимального времени для отладочных задач. При превышении данного значения задача автоматически будет считаться пакетной.

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

Шкала приоритетов пользователей. Задачи планируются системой согласно приоритетам пользователей, т.е. задача пользователя с высоким приоритетом может посчитаться раньше, чем задача пользователя с низким приоритетом. Приоритет пользователя определяется по указанной шкале и напрямую зависит от суммарного времени счета пользователя за текущие сутки. Например, если шкала имеет следующий вид:

(120,300,600,1200,0)

то это означает, что наивысшим приоритетом будут обладать задачи пользователей, которые за текущие сутки считали менее 120 минут, чуть меньшим приоритетом – тех, кто считал менее 300 минут, еще меньшим – тех, кто считал менее 600 минут и т.д. Низшим приоритетом будут обладать задачи пользователей, считавших более 1200 минут. При вычислении приоритета задачи учитывается заказываемое пользователем ее время счета.

Планирование фоновых задач осуществляется следующим образом. Пользователь должен указать квант для фоновой задачи. Система гарантирует, что если фоновая задача была выбрана на счет, то ей будет дано для счета время, не меньшее указанного кванта. По истечении кванта задача может быть снята системой со счета и перепланирована. Если указанный пользователем квант не превышает максимального времени для отладочных задач, то его фоновая задача может быть включена в решение наравне с прочими отладочными задачами. Однако, при появлении в системе первой отладочной задачи, фоновая задача, по истечении кванта, будет снята с выполнения и перепланирована.

Если указанный пользователем квант не превышает максимального времени для пакетных задач, то фоновая задача планируется, как пакетная. Она уже не сможет занимать процессоры, «зарезервированные» для отладочных задач. При превышении квантом максимального времени для пакетных задач фоновая задача не сможет войти в счет в текущем режиме.

1.1.3 Паспорт параллельной задачи

При взаимодействии процессы системы управления прохождением задач передают друг другу паспорт параллельной задачи. Паспорт представляет собой файл следующего формата:

# Это комментарий

# Следующая строка - название секции

[General]

# Далее идет содержимое секции

# Следующая срока определяет имя задачи

task_name = testmod

# Следующая срока определяет имя каталога

# стандартного вывода

host_directory = /usr/people/lacis/testmod/work

# Следующая срока определяет необходимое число

# процессоров для выполнения задачи

# Если указывается значение any, то число процессоров

# должно быть определено при старте задачи

cpu_count = any

# Следующая срока определяет имя

# логической системы, в которой должна быть

# выполнена задача

system = mpi

# Следующая срока определяет имя

# пользователя - владельца

# параллельной задачи

user = maximh

# Следующая строка - название секции

[TimeRequest]

# Время (по максимуму), необходимое для выполнения задачи,

# указывается в минутах

limit = 240

# количество повторов задачи

repeat_times = 2

# квант для фоновых задач

quant = 20

# Следующая строка - название секции

[Batch]

# Далее идет содержимое секции

# Здесь помещается текст командного файла,

# который будет выполнен на нулевом по счету модуле,

# среди выделенных для задачи

Рассмотрим некоторые параметры подробнее. Параметр task_name секции [General] определяет имя параллельной задачи. При постановке задачи в очередь ей, помимо символьного имени, будет присвоен уникальный номер. Полное имя задачи будет складываться из значения параметра task_name и, через точку, - уникального номера. Для нашего примера полное имя запущенной задачи может быть testmod.2. Кроме этого, если определена логическая система, в которой будет выполняться задача (см. п. 1.3.1 Логические системы), то ее имя будет добавлено в начало полного имени задачи. В нашем примере, если система присвоит задаче номер 2, то ее полное имя будет mpi.testmod.2.

Такой порядок формирования полного имени задачи необходим для обеспечения уникальности имен. Пользователь может запустить одну и ту же параллельную задачу, во-первых, одновременно несколько раз (система присвоит каждому экземпляру уникальный номер), во-вторых, одновременно на разных логических системах (система прибавит имя системы к имени задачи). Отметим, что после завершения параллельной задачи номер, присвоенный ей, освобождается и будет использован повторно при последующих запусках этой задачи.

Параметр host_directory секции [General] определяет имя каталога стандартного вывода для параллельной задачи. В данном каталоге при постановке задачи в очередь будет создан подкаталог с именем, совпадающим с полным именем задачи. В этом подкаталоге размещается файл стандартного вывода параллельной задачи, а также ряд других специальных файлов (см. п. 1.4.3.1 Как запускается и завершается параллельная задача). Заметим, что при одновременном запуске двух экземпляров задачи с одним и тем же паспортом, благодаря уникальности полных имен задач, в каталоге стандартного вывода будут созданы разные подкаталоги для разных экземпляров задачи.

Секция [Batch] содержит текст командного файла, который будет выполнен системой на первом (нулевом) вычислительном модуле из числа выделенных для параллельной задачи (см. п. 1.4.3.1 Как запускается и завершается параллельная задача).

1.2 Взаимодействие процессов в системе управления прохождением задач

Система управления прохождением задач представляет собой совокупность взаимодействующих процессов управляющей ЭВМ, основные из которых (см. рис. 1) следующие:

- runmvs – клиент, вызываемый на сервере доступа, обеспечивает связь пользователя с системой управления прохождением задач, именно эта программа вызывается при выполнении всех пользовательских команд (см. Руководство пользователя);

- runmvsd – сервер запросов, отвечающий за связь с клиентом и обработку клиентских запросов;

- qserver – сервер очередей параллельных задач;

- mrun – процесс-«запускатель» задачи.

Рис. 1. Схема взаимодействия процессов

Каждый из перечисленных процессов представляет собой отдельную программу. Все остальные процессы порождаются динамически во время работы перечисленных программ. По умолчанию программы runmvsd и mrun размещаются в каталоге /usr/runmvs/bin, qserver - в каталоге /usr/runmvs/qserv/bin, runmvs - в каталоге /common/runmvs/bin. Умалчиваемое размещение может быть изменено администратором.

Схема взаимодействия процессов системы управления прохождением задач МВС-1000/16 следующая.

Задачи, использующие MPI, должны при своем запуске использовать специальный командный файл mpirun, формирующий паспорт задачи и передающий его системе управления прохождением задач. По умолчанию при установке данный командный файл помещается в каталог /common/runmvs/bin.

В начале файла mpirun переменной MPIR_HOME присваивается имя корневой директории с файлами MPI. После вызова файла mpirun.args, в котором обрабатываются параметры командной строки формируется секция [General] паспорта задачи на основе этих параметров.

Далее формируется секция [Batch] паспорта задачи. В этой секции описывается командный файл, который будет выполняться на нулевом из выделенных задаче вычислительных модулей. Важно понимать, какие действия, подстановки переменных и перенаправления ввода/вывода будут выполняться на этапе формирования командного файла, а какие - в момент его исполнения.

Командному файлу, формируемому из секции [Batch] паспорта задачи, при его запуске передаются два параметра: число процессоров (не модулей!), выделенных задаче, и имя файла, в котором содержится список модулей, на которых необходимо запустить задачу, в виде:

<имя_модуля1>:<число_процессоров_выделенных_задаче_на_модуле1>

<имя_модуля2>:<число_процессоров_выделенных_задаче_на_модуле2>

. . .

<имя_модуляN>:<число_процессоров_выделенных_задаче_на_модулеN>

Командный файл, формируемый в секции [Batch] паспорта задачи, служит для восстановления окружения, существующего при постановке задачи в очередь, и запуска команды mpirun, соответствующей используемой версии MPI. Для этого в командном файле формируются инструкции перехода в директорию, из которой запускается задача и восстановление переменных окружения, существовавших в момент постановки задачи в очередь.

Список модулей, на которых будет запускаться задача, необходимо привести к виду, пригодному для использования конкретной версией MPI. В данном случае для преобразования списка модулей используется командный файл на языке программирования python. Например, для версиии MPI для gm, в начале этого файла в переменной available_gmports записываются номера портов gm. В конкретной ситуации возможна корректировка значения этой переменной.

После формирования команды запуска программы на выполнение и формирования команд удаления временных файлов формирование секции [Batch] заканчивается и сформированный паспорт задачи передается в очередь задач с помощью команды runmvs.

При наборе пользователем любой из команд системы (см. Руководство пользователя) вызывается клиент runmvs с соответствующими набранной команде ключами. Клиент runmvs соединяется с сервером запросов runmvsd, проходит авторизацию и передает ему на исполнение пользовательскую команду. Общение между клиентом и сервером происходит через протокол TCP/IP по серверному порту 27778, что позволяет выполнять клиент и сервер на разных ЭВМ.

Все команды клиента сервер runmvsd выполняет самостоятельно, за исключением команд на запуск и постановку в очередь параллельных задач. Подробное описание выполнения команд см. п. 1.4.1.1.2 Команды сервера runmvsd, здесь мы рассмотрим процесс запуска и завершения параллельной задачи.

При поступлении команды на запуск или постановку в очередь параллельной задачи runmvsd получает от клиента паспорт задачи, содержащий ее описание в терминах системы управления прохождением задач. Существенными характеристиками задачи из числа данных паспорта являются количество процессоров и время исполнения, требуемые задаче. Проверив корректность данных паспорта задачи runmvsd, обращается к серверу очередей qserver с запросом на постановку задачи в очередь. Заметим, что для взаимодействия сервера запросов и сервера очередей используется очередь сообщений IPC, поэтому эти две программы должны выполняться на одной ЭВМ. При этом сервер запросов runmvsd запускается через демон inetd (xinetd) всякий раз, когда к нему обращается новый клиент, а сервер очередей qserver - это один процесс, постоянно выполняющийся на управляющей ЭВМ. Номера очередей IPC, через которые сервер очередей общается с сервером запросов, задаются администратором и не должны совпадать для разных серверов очередей.

Сервер очередей ведет очередь параллельных задач согласно принципам планирования очередей. В момент запуска задачи сервер очередей вызывает программу mrun, которая осуществляет:

- определение свободных вычислительных модулей;

- выделение требуемого параллельного ресурса для задачи;

- порождает с помощью fork() специальный процесс-менеджер задачи (на схеме – manager), осуществляющий запуск задачи и контроль над ней.

Процесс-менеджер осуществляет конфигурацию выделенных вычислительных модулей для параллельной задачи (подробнее см. п. 1.4.3.1 Как запускается и завершается параллельная задача), после чего на модуле, стоящим первым в списке выделенных для задачи (node0 на схеме) с помощью команды rsh запускает на выполнение специальный командный файл, который инициирует параллельную задачу.

Далее процесс-менеджер с помощью fork() порождает процесс sleeper, осуществляющий контроль за временем выполнения задачи. Если все перечисленные действия менеджера завершились благополучно, он посылает сигнал USR1 процессу mrun, если произошла какая-либо ошибка – сигнал USR2. Вместе с этим менеджер в системе учета вычислительных модулей помечает выделенные модули как занятые, а также создает специальные файлы, содержащие информацию о запущенной задаче. Далее менеджер начинает ожидать либо завершения порожденных им процессов, либо сигнала.

Процесс mrun, получив тот или иной сигнал от менеджера, формирует код возврата и диагностическое сообщение, передает их серверу очередей через стандартный вывод и завершается.

Успешно запущенная задача может быть завершена тремя различными способами:

- «естественным» путем, т.е. закончив счет;

- по истечении заказанного времени;

- принудительно пользователем или администратором системы.

В любом случае, при завершении задачи менеджер осуществляет следующие действия:

- производит очистку всех выделенных задаче вычислительных модулей (возможно – перезагрузку модулей);

- выполняет протокол подтверждения очистки (перезагрузки) вычислительных модулей (подробнее см. п. 1.4.3.2 Протокол подтверждения перезагрузки);

- освобождает вычислительные модули в системе учета занятых модулей, а также вносит изменения в специальные файлы, содержащие информацию о запущенных и завершенных задачах;

- соединяется через очередь IPC со своим сервером очередей и сообщает ему о завершении задачи и освобождении ресурсов, после чего завершается.

При завершении задачи «естественным» путем, менеджер завершает sleeper и выполняет вышеперечисленные действия.

При истечении заказанного времени счета sleeper посылает менеджеру сигнал INT, который сообщает менеджеру о необходимости завершения задачи. Менеджер, получив сигнал, завершает процесс rsh и выполняет перечисленные выше действия.

Администратор для завершения задачи просто посылает сигнал INT процессу-менеджеру. Пользователь для той же цели должен вызвать клиент runmvs и передать ему команду на завершение задачи. Клиент runmvs передает эту команду серверу запросов. Последний находит процесс-менеджер и посылает ему сигнал INT. Менеджер по получении сигнала выполняет уже описанные действия.

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

Фоновая задача (подробнее см. п. 1.1.2 Основные принципы построения очередей) может прерываться системой и выполняться по квантам. При этом меняется схема взаимодействия процессов. Процесс sleeper «засыпает» не на все время счета задачи, а только на время кванта. По истечении кванта sleeper обращается через очередь IPC к серверу очередей с запросом на продолжение счета параллельной задачи. Сервер очередей, сообразуясь с собственным расписанием прохождения задач, принимает решение о прекращении или продолжении счета. Данное решение передается процессу sleeper. Если счет задачи продолжается, sleeper «засыпает» на время очередного кванта. Если задача снимается со счета, sleeper посылает сигнал INT менеджеру.

Задача с повтором может быть выполнена на вычислителе несколько раз. Механизм завершения такой задачи отличается тем, что при получении сигнала INT менеджер производит действия по завершению лишь текущей итерации. Далее задача с повтором будет вновь поставлена в очередь и запущена. Для полного завершения задачи (без возможности повторов) необходимо послать менеджеру сигнал TERM.

1.3 Конфигурация системы управления прохождением задач

1.3.1 Логические системы

Система управления прохождением задач позволяет разбивать вычислитель на две и более логических систем. Вычислительные модули, отнесенные к той или иной логической системе, могут пересекаться, но могут быть и разными. Кроме этого, механизм логических систем позволяет работать одной управляющей ЭВМ сразу с несколькими вычислителями. Логические системы различаются по именам.

На рисунке 2 показаны две логические системы – sys1 и sys2. Как видно, каждая система имеет собственный сервер очередей – qserver1 и qserver2 соответственно. Сервер запросов runmvsd обращается к серверам очередей разных систем по разным очередям IPC (IPC1 и IPC2). Сервер очередей каждой из логических систем может использовать для запуска задачи свой собственный процесс mrun. Для простоты на схеме не показаны процессы sleeper.

Заметим, что любые компоненты, кроме сервера запросов, в разных логических системах могут быть как разными, так и одинаковыми. Например, две разные логические системы могут иметь один сервер очередей, но разные процессы-«запускатели», и наоборот. Сервер запросов один и тот же для разных логических систем, т.к. именно на его уровне производится деление на системы.

Логические системы определяются администратором через соответствующие конфигурационные файлы. При этом в системе всегда должна существовать система по умолчанию (с именем default). Конфигурация системы по умолчанию задается в главном конфигурационном файле /usr/runmvs/.grunmvs.

Рис. 2. Логические системы

ВНИМАНИЕ! Ответственность за корректность конфигурации логических систем лежит на администраторе. Нет механизма автоматической проверки корректности конфигурации. Например, если администратор определил две логические системы для двух физически различных групп вычислительных модулей, то он должен организовать две различные очереди. Соответственно должны быть определены и правильно сконфигурированы два различных сервера очередей.

1.3.2 Специальные каталоги системы

Если пользователь соединяется с сервером впервые, то сервер запросов runmvsd создает в базовом каталоге системы управления прохождением задач (по умолчанию - /usr/runmvs) подкаталог с именем пользователя. Базовый каталог может быть отдельным для каждой логической системы. В этом подкаталоге создаются еще ряд подкаталогов, имена и назначения которых следующие:

images – содержит базу паспортов задач данного пользователя; каждый паспорт представляет собой файл, имя файла – это имя паспорта.

run – содержит базу запущенных пользователем задач; каждая задача – один файл, имя файла – это имя запущенной задачи, включая уникальный номер через точку. Формат файла аналогичен выдаче команды mps (см. п. 1.4.1.1 Протокол сервера runmvsd).

done – содержит базу завершенных пользователем задач; по завершении задачи в ее файл каталога run записывается время завершения задачи, а затем файл переносится из каталога run в каталог done.

tmp – каталог для временных файлов, runmvsd очищает его сам при каждом запуске.

queue – содержит базу задач пользователя, стоящих в очереди.

Доступ на чтение и запись базового каталога и его подкаталогов должен быть предоставлен только суперпользователю.

ВНИМАНИЕ! Каталоги run и done всех пользователей должны очищаться при каждом общем рестарте системы (логической системы).

Кроме базового каталога важным является блокирующий каталог, через который системой ведется учет свободных и занятых вычислительных модулей, а также синхронизация выдачи стандартного вывода параллельной задачи. При запуске параллельной задачи ее менеджер создает в этом каталоге подкаталоги с именами, соответствующими сетевым именам занимаемых задачей вычислительных модулей. При завершении параллельной задачи ее менеджер по освобождении занятых модулей удаляет соответствующие подкаталоги. Таким образом, наличие в блокирующем каталоге подкаталога с именем вычислительного модуля означает для системы управления прохождением задач то, что вычислительный модуль с данным именем занят. Администратор может пользоваться этим и оперативно выключать из счета те или иные модули путем создания в блокирующем каталоге соответствующих подкаталогов.

ВНИМАНИЕ! Если в определенных администратором логических системах есть общие вычислительные модули, то администратор должен назначить одинаковые блокирующие каталоги для этих логических систем.

Имя блокирующего каталога указывается в конфигурационном файле логической системы. Доступ на чтение и запись в блокирующий каталог должен бать предоставлен только суперпользователю.

1.3.3 Условия работы системы

Для нормального функционирования системы управления прохождением задач администратор должен сконфигурировать вычислительную установку так, чтобы выполнялись следующие условия:

1. На вычислительных модулях запретить автоматический запуск серверов telnetd и ftpd. Вход на узел должен быть разрешен только через ssh и только суперпользователю.

2. На вычислительных модулях НЕ ДОЛЖНЫ БЫТЬ СМОНТИРОВАНЫ ДОМАШНИЕ КАТАЛОГИ ПОЛЬЗОВАТЕЛЕЙ!!! При этом имена этих каталогов должны быть одинаковы на всех модулях и на управляющей ЭВМ.

3. На вычислительных модулях должен быть смонтирован каталог, содержащий клиентскую часть версии, MPI и прочие необходимые для непосредственного запуска задач компоненты. В дальнейшем предполагается, что имя этого каталога /common. Еще раз обращаем внимание на то, что домашние каталоги пользователей ни в коем случае не должны размещаться в этом каталоге и вообще быть смонтированы на модулях.

4. На вычислительных модулях должна быть включена авторизация службы rsh через файл /etc/hosts.equiv и через ~/.rhosts. При этом по умолчанию доступ на модули должен быть разрешен только с управляющей ЭВМ и только суперпользователю, для чего в домашнем каталоге суперпользователя на каждом узле должен находиться соответствующий файл .rhosts.

1.3.4 Конфигурационный файл системы

Главный файл конфигурации системы управления прохождением задач имеет имя /usr/runmvs/.grunmvs. Он состоит из нескольких секций, каждая секция - из нескольких строк. Строка начинается с имени параметра конфигурации, далее, через знак равенства, следует значение параметра. Первый символ строки ‘#’ означает комментарий. Примерный формат конфигурационного файла следующий:

# Это комментарий

# Следующая строка - название секции

# Порядок следования секций в файле не

# имеет значения

[Systems]

# Далее идет содержимое секции

# данная секция не обязательна,

# если нет логических систем

# Секция указывает, какие логические

# системы есть, и в каких файлах находятся

# их конфигурации

# Формат строки:

# имя_системы = имя_конфигурационного_файла

# В данном примере вводятся две логических системы –

# mpi и pvm с соответствующими конфигурационными

# файлами. Формат этих файлов полностью совпадает

# c главным файлом, за исключением того, что

# в конфигурационных файлах логических систем

# отсутствует (игнорируется) секция [Systems]

# Система mpi – конфигурация в текущем файле

mpi = /usr/runmvs/.grunmvs

pvm = /usr/runmvs/.pvm_conf

[General]

# Далее идет содержимое секции

# Следующая срока определяет имя

# блокирующего каталога,

# должен быть указан полный путь

lock_directory = /usr/runmvs/lock

# Следующая срока определяет имя

# базового каталога, содержащего информацию

# о пользователях и их задачах,

# должен быть указан полный путь

base_directory = /usr/runmvs

# Следующая срока определяет имя родительского каталога

# для изолированной среды пользователей,

# должен быть указан полный путь

user_root = /

# Следующая срока определяет имя файл-сервера,

# содержащего домашние каталоги пользователей

file_server = rscu_1

# Следующая срока определяет имя процесса-запускателя

# (mrun), должен быть указан полный путь

runner = /usr/runmvs/bin/mrun

# Следующая строка - название секции

# Данная секция описывает файлы

# подготовки и очистки модулей

[Run]

# Следующая строка определяет

# имя командного файла, который будет

# выполнен процессом mrun на управляющей ЭВМ

# перед запуском задачи

# Данный командный файл производит

# конфигурацию выделенных для задачи модулей,

# разрешая доступ к ним задаче пользователя

prepare_node = /usr/runmvs/bin/prepare_nodes

# Следующая строка определяет

# имя командного файла, который будет

# выполнен процессом mrun на управляющей ЭВМ

# после завершения задачи

# Данный командный файл производит

# очистку и реконфигурацию выделенных для задачи модулей,

# запрещая доступ к ним задаче пользователя

close_node = /usr/runmvs/bin/close_nodes

# Следующая строка - название секции

# Данная секция описывает настройки

# по защите информации в системе

[Security]

# Следующая строка определяет

# максимальный размер файла-паспорта задачи

# пользователя (в килобайтах)

max_image_size = 16

# Следующая строка определяет

# максимальное число файлов-папортов (включая стоящие в очереди),

# которое пользователь может держать на сервере

max_images_count = 24

# Следующая строка - название секции

# Данная секция описывает параметры сервера очередей

[Queue]

# Следующая строка определяет

# имя файла для сохранения идентификатора

# (pid) сервера очередей

qserver_pid = /usr/runmvs/.qserv_pid

# Следующая строка определяет

# имя файла-лога для сервера очередей

qserver_log = /usr/runmvs/qserv.log

# Следующая строка определяет

# идентификатор очереди сообщений к серверу

to_qserver = 12346

# Следующая строка определяет

# идентификатор очереди сообщений от сервера

from_qserver = 64321

# Следующая строка - название секции

# Данная секция описывает узлы системы

[Nodes]

# Каждая строка содержит имя узла и

# через «равно» - число процессоров на узле

rcsu_2= 1

rcsu_3= 1

rcsu_4= 1

rcsu_5= 1

rcsu_6= 1

rcsu_7= 1

rcsu_8= 1

rcsu_9= 1

rcsu_10= 1

rcsu_11= 1

rcsu_12= 1

rcsu_13= 1

rcsu_14= 1

rcsu_15= 1

rcsu_16= 1

# Следующая строка - название секции

# Данная секция содержит «белый список»

# пользователей, которым разрешен запуск задач

# Если эта секция отсутствует, то запуск

# разрешен всем пользователям

[WhiteList]

# Далее идет содержимое секции

# Формат строки следующий:

# пользователь = yes | no

# Если стоит yes, то пользователю разрешен запуск

# Если стоит no или пользователь отсутствует в списке,

# то запуск задач ему запрещен

user1 = yes

user2 = no

1.3.5 Правила фильтрации

Для управления доступом пользователей к различным компонентам системы МВС-1000/16, работающих в виде отдельных сетевых служб, администратор системы должен использовать имеющиеся в дистрибутиве списки правил фильтрации. Данные списки состоят из двух наборов файлов - отдельно для управляющей ЭВМ и отдельно для вычислительных модулей.

Списки правил фильтрации представляют собой командные shell-файлы, которые содержат вызовы программы ipchains. Данная программа является интерфейсом для управления правилами фильтрации ядра операционной системы Linux. Используя ipchains возможно добавление новых правил к списку имеющихся в системе, определения порядка следования используемых правил, удаление отдельных правил или просмотр списка установленных в системе правил фильтрации. За более подробной информацией о правилах использования программы ipchains необходимо обратиться к документации по данной программе.

Для обеспечения возможности использования правил фильтрации администратору необходимо сконфигурировать используемое ядро ОС Linux, включив в него поддержку правил фильтрации.

ЗАМЕЧАНИЕ. Конфигурирование ядра необходимо производить на всех машинах системы.

Для того чтобы проверить, поддерживает ли используемое ядро правила фильтрации, необходимо убедиться в наличии на данной ЭВМ файла с именем ip_fwchains, расположенного в каталоге /proc/net. Если указанный файл существует, не нужно производить дополнительную настройку используемого ядра. Если указанный файл отсутствует, необходимо переконфигурировать ядро. Для этого необходимо включить следующие параметры в меню Networking options настройки ядра:

· Network firewalls;

· Socket Filtering;

· IP: firewalling;

· IP: firewall packet netlink device.

После чего необходимо заново скомпилировать ядро и произвести перезагрузку данной ЭВМ. За более подробной информацией о конфигурации ядра обращайтесь к документации по установке и настройке ядра.

Поставляемый в составе дистрибутива набор содержит правила фильтрации, которые удовлетворяют большинству условий работы системы МВС-1000/16. Администратору, скорее всего, не придется вносить изменения в используемый по умолчанию набор правил фильтрации, однако если это будет необходимо, администратору настоятельно рекомендуется разобраться с принципами работы правил фильтрации. Некорректное добавление или изменение существующих правил фильтрации может привести к неправильной работе всей системы или отдельных ее модулей.

Поставляемые в составе дистрибутива правила разделены для управляющей ЭВМ и вычислительных модулей. Это вызвано отличиями в работы этих компонент вычислительной системы, поэтому не следует использовать правила фильтрации, предназначенные для управляющей ЭВМ, на вычислительных модулях, а правила фильтрации, предназначенные для вычислительных модулей, на управляющей ЭВМ.

При инсталляции правил фильтрации необходимо добавить их в начальную загрузку системы. Последовательность запуска системы с использованием правил фильтрации изложена в п. 2 Инструкция по установке системы управления прохождением задач.

1.4 Процессы системы управления прохождением задач

1.4.1 Сервер запросов runmvsd

Сервер запросов runmvsd – это программа с именем /usr/runmvs/bin/runmvsd, стандартный ввод и вывод которой связаны через демон inetd (xinetd) с портом № 27778. Runmvsd осуществляет авторизацию пользователя и обработку команд своего протокола. Для работы сервера необходимо наличие базового (рабочего) каталога, доступного только суперпользователю (имя задается в конфигурационном файле, но по умолчанию - /usr/runmvs). В этом каталоге сервер будет хранить служебную информацию об запущенных, выполненных задачах, очередях и т.п.

1.4.1.1 Протокол сервера runmvsd

1.4.1.1.1 Авторизация

Соединиться с сервером runmvsd можно, например, клиентом telnet, использовав порт 27778. После установления соединения с клиентом runmvsd ожидает ввода имени пользователя, не выдавая никакой информации. Имя вводится командой:

user <имя>

После этого runmvsd создает временный файл в домашнем каталоге пользователя, делает этот файл принадлежащим пользователю, устанавливает права на чтение этого файла только владельцу (т.е. пользователю), записывает в этот файл случайное 64-байтное число (ключ) и сообщает имя этого файла клиенту следующей строкой

file <имя_файла>

Для аутентификации клиент должен прочитать 64-байтный ключ из указанного файла и сообщить его серверу. Сервер проверяет подлинность ключа и в случае несовпадения доступ запрещается. При этом сервер runmvsd выдаст сообщение

Login incorrect

после чего соединение разрывается.

При совпадении ключей runmvsd удаляет временный файл и выдает приглашение

+ OK>

Данная последовательность символов является ключевой и означает, что сервер готов к вводу очередной команды. После ввода и выполнения команды runmvsd выдает ответ в следующем формате. Первая строка ответа - код завершения, 0 - успешно, не 0 - ошибка. Далее могут идти несколько строк сообщения (в случае нормального завершения - информационного, в случае ошибки - сообщения об ошибке). Далее, с новой строки, выдается приглашение - сервер готов к приему очередной команды.

1.4.1.1.2 Команды сервера runmvsd

mcpu

Выдать количество процессоров в системе.

mproc

Выдать количество свободных процессоров в системе.

system [имя_системы]

При отсутствии параметра выдать имя текущей логической системы. При задании параметра имя_системы переключиться на логическую систему с заданным именем. По этой команде сервер запросов выбирает базовый каталог указанной системы, а также подключается к очереди IPC сервера очередей указанной логической системы.

mqueuef [проц]

Поставить параллельную задачу в очередь. При этом сервером от клиента принимается паспорт параллельной задачи. Сначала сервер создает временный файл, при успешном создании сервер выдает нулевой код возврата и ожидает ввода паспорта параллельной задачи. Признак конца паспорта - ввод секции [End]. Нельзя ввести паспорт размером (Кб) больше, чем указано в параметре max_image_size, и поставить в очередь одному пользователю задач больше, чем указано в параметре max_images_count секции [Security] конфигурационного файла системы запуска /usr/runmvs/.grunmvs. При успешном приеме происходит постановка в очередь задачи и/или ее запуск. Параметр проц - количество процессоров, требуемых для задачи. Если этот параметр явно не специфицирован в паспорте задачи, его задание в команде обязательно. При задании этого параметра в команде он будет принят к исполнению в любом случае, вне зависимости от его спецификации в паспорте.

mps

Выдать список запущенных задач.

mps <имя_задачи>

Выдать информацию о задаче с данным именем. Команда выдаст информацию, даже если задача завершилась. Формат выдачи следующий. Первая строка - дата и время запуска (и завершения) задачи, вторая строка - имя каталога файлов стандартного ввода/вывода задачи, третья строка - pid процесса-менеджера задачи, последующие строки - имена узлов, на которых выполняется (выполнялась) задача и количество процессоров на этих узлах.

getoutput <имя_задачи> <тип>

Выдать стандартный вывод задачи с данным именем. Параметр тип может принимать два значения - log (выдать стандартный вывод менеджера задачи) и out (выдать стандартный вывод задачи).

mkill <имя_задачи>

Завершить задачу с данным именем. Имя задачи может быть маской (включать символы-джокеры и пр.) в Unix-формате. В этом случае команда будет применена ко всем задачам, имена которых удовлетворят заданной маске. После завершения задачи по этой команде, если не исчерпано число повторов, задача будет запущена вновь.

mterm <имя_задачи>

Завершить задачу с данным именем. Аналогично mkill, только задача будет завершена окончательно, без возможности повтора, даже если число повторов не исчерпано.

help

Выдать краткую информацию о сервере.

quit

Завершить работу и разорвать связь с клиентом.

Процесс runmvsd ведет протокол в файле /usr/runmvs/runmvsd.log. В этом файле отмечается, какой пользователь когда входил в систему и какие команды выполнял.

1.4.2 Сервер очередей qserver

1.4.2.1 Основные сведения

Без этого процесса не обходится ни один запуск задачи, поэтому qserver должен постоянно выполняться на управляющей ЭВМ для каждой определенной логической подсистемы. Каждый сервер очередей должен иметь свой базовый каталог, в котором он будет вести очередь параллельных задач. При инсталляции системы сервер очередей устанавливается в каталог /usr/runmvs/qserv, который в дальнейших примерах мы будем считать базовым для него. Запуск сервера очередей осуществляется командой

/usr/runmvs/qserv/bin/qserv [имя_системы] [&]

Заметим, что при вызове должен быть указан полный путь, т.к. именно по нему, путем вычета из строки вызова bin/qserv, сервер очередей определяет свой базовый каталог. Сервер очередей читает сразу после запуска главный конфигурационный файл системы с именем .grunmvs, который он ожидает увидеть в своем базовом каталоге.

ВНИМАНИЕ! При конфигурации сервера очередей администратор должен позаботиться о том, чтобы в базовом каталоге каждого сервера очередей находилась символическая ссылка на главный файл конфигурации системы управления прохождением задач /usr/runmvs/.grunmvs.

При задании параметра имя_системы сервер очередей переключается на указанную логическую систему. Если же параметр не задан, сервер очередей переключается на систему по умолчанию, конфигурация которой считывается из главного конфигурационного файла.

Далее сервер очередей перезаписывает файл, имя которого получается из значения параметра qserver_pid секции [Queue] конфигурационного файла выбранной логической системы. В этом файле сервер очередей сохраняет свой идентификатор процесса (pid). При старте qserver читает этот pid и определяет, есть ли такой процесс в системе. Если есть, то сервер очередей второй раз не запускается. Заметим, что таким же образом определяет наличие выполняющегося qserver'а и сервер запросов runmvsd.

Для связи с другими процессами системы управления прохождением задач qserver использует механизм IPC и две очереди IPC – к себе и от себя. Идентификаторы очередей IPC считываются из секции [Queue] конфигурационного файла логической системы.

Сервер очередей ведет протокол своей работы в файле лога, имя которого определяется из секции [Queue] конфигурационного файла логической системы.

ВНИМАНИЕ! Сервер очередей оперирует только с понятием «процессор», а не «многопроцессорный вычислительный модуль». Поскольку вычислительный модуль выделяется параллельной задаче целиком, то число реально занятых задачей процессоров может оказаться больше заказанного пользователем. После запуска задачи процесс-«запускатель» mrun сообщает серверу очередей реальное число занятых процессоров. В дальнейшем именно это число будет учитываться сервером очередей при операциях с параллельной задачей.

1.4.2.2 Система каталогов и специальных файлов сервера очередей

В базовом каталоге сервера очередей (по умолчанию - в /usr/runmvs/qserv) при установке должна быть создана система подкаталогов и файлов со следующими названиями и назначением:

src – каталог исходных текстов

bin – каталог исполняемых файлов

inf - каталог информационных файлов

sched - каталог расписаний режимов работы

status - файл состояния очереди и сервера

status_ - файл нового состояния (при переходе)

holdpr – файл, содержащий число заблокированных (неосвобожденных) процессоров

inf/qinfo - информационный файл сервера очередей

inf/qinfo_ - новый информационный файл (при создании)

sched/N - файлы расписаний, N – номер расписания

sched/src.N - файл задания соответствующего расписания

sched/N.old ,

sched/oldsrc.N - предыдущие версии соответствующих файлов

src/*.c - исходные тексты

src/qserv.h - параметры сервера

src/qqset.hc - параметры генерируемого расписания режимов

src/mkqq – командный файл получения исполняемого кода

src/mksched – командный файл получения нового расписания

Заметим, что несмотря на то, что расписаний в каталоге sched может быть много, сервер очередей принимает к исполнению расписание с номером 0. Соответствующий файл в каталоге sched должен быть символической ссылкой на файл с текущим расписанием. Сервер очередей распознает указанную ссылку и правильно определит номер расписания. Подробно процесс генерации расписаний описан в п. 3.2 Генерация расписания очереди.

1.4.2.3 Утилита сервера очередей

Вместе с сервером очередей поставляется программа-утилита с именем /usr/runmvs/qserv/bin/qutil. Как уже было отмечено, взаимодействие сервера очередей с внешними процессами осуществляется через очереди IPC.

1.4.2.4 Протокол и утилита взаимодействия с сервером очередей

Как было уже отмечено выше, сервер очередей взаимодействует с внешними процессами через очередь IPC. При этом сервер очередей читает запросы из одной очереди («к себе», to_qserver) и выдает ответы в другую очередь («от себя», from_qserver). Общий формат запроса следующий:

_TAG_ _PID_ _PARAMETERS_

Здесь:

_TAG_ - тип запроса

_PID_ - идентификатор процесса, выдавшего запрос

_PARAMETERS_ - параметры запроса

Ответ на запрос содержит код (нормальный – 0, ошибочный – не 0) и сообщение.

Ниже будут использоваться следующие обозначения:

_rep_pid_ - идентификатор процесса, которому необходимо выдать ответ

_task_pid_ - идентификатор процесса-менеджера задачи

_task_image_name_ - полное имя с паспортом задачи

_user_logname_ - имя пользователя

_brief_image_name_ - краткое имя паспорта задачи (имя задачи)

В описаниях сначала идет символическое имя сообщения-запроса, затем форматная строка запроса, содержащая код запроса и мета-имена параметров. Разделителем параметров может быть и перевод строки ('\n'). Смысл неописанных мета-имен должен быть понятен из краткого пояснительного текста, следующего за форматной строкой запроса.

Завершение конкретной задачи (_FIN_TASK_MSG_)

10 _task_pid_ _term_ _rest_proc_

При _term_= 1 любая задача просто исключается из очереди. При _term_= 0 обычная задача исключается из очереди, а фоновая задача и задача с повтором перемещаются в конец очереди с уменьшением общего времени счета и количества повторов, соответственно. При этом уменьшение общего времени решения фоновой задачи происходит на ближайшее число минут, которое кратно указанному кванту и больше реального времени счета. В лог-файл записывается строка, включающая следующую информацию: время завершения, имя пользователя, имя задачи, pid, количество процессоров, общее время счета и цена задачи. Сумма времени посчитанных пользователем задач корректируется с учетом окончательной цены задачи.
Если _rest_proc_ > 0, то количество доступных серверу очередей процессоров уменьшается на _rest_proc_. Отсутствие параметра эквивалентно его равенству 0. Количество захваченных процессоров сохраняется в специальном файле, и будет учтено даже при перезапуске сервера с очисткой состояния.

Запрос на продолжение конкретной задачи (_CONT_TASK_MSG_)

13 _rep_pid_ _task_pid_

Если фоновая задача может быть продолжена, то выдается ответное сообщение для процесса _rep_pid_, содержащее лишь код ответа 0. Иначе или, если задача не фоновая, код ответа 1. Предполагается, этот запрос выдается за несколько минут до истечения кванта задачи. Если ответное сообщение содержит 1, то задача должна быть снята, а сервер очередей - получить соответствующий (_FIN_TASK_MSG_) запрос на обработку ее завершения. Когда продолжить счет можно, то предполагается, что задача будет считаться еще квант, за несколько минут до истечения которого опять будет выдан запрос на продолжение.

Немедленный запуск задачи (_EXE_TASK_MSG_)

20 _rep_pid_ _task_image_name_

После чтения паспорта, если параметры задачи удовлетворяют установкам текущего режима, задача временно попадает в конец очереди, которая затем перепланируется. Если сервер очередей установил, что задача может быть запущена сразу, то осуществляется ее запуск, а иначе задача из очереди удаляется. В любом случае в очередь IPC выходных сообщений записывается текстовое ответное сообщение для процесса _rep_pid_, содержащее в первой строке 0 или код ошибки, а в следующих строках - диагностику, которая может быть и той, что приходит от процесса mrun. Если задача была запушена, то увеличивается количество и суммарное время задач пользователя. При нормальном запуске mrun передает серверу очередей идентификатор процесса-менеджера задачи, который сохраняется как один из параметров задачи наряду с временем старта.

Запуск задачи с постановкой ее в очередь (_Q_TASK_MSG_)

21 _rep_pid_ _task_image_name_

После чтения паспорта, если параметры задачи удовлетворяют установкам текущего режима, задача попадает в конец очереди, которая затем перепланируется. Если сервер очередей установил, что задача может быть запущена сразу, то осуществляется ее запуск, а иначе задача остается в очереди. В любом случае в очередь IPC выходных сообщений записывается текстовое ответное сообщение для процесса _rep_pid_, содержащее в первой строке 0 или код ошибки, а в следующих строках - диагностику, которая может быть и той, что приходит от процесса mrun. Если задача была запушена, то увеличивается количество и суммарное время задач пользователя, а когда задача просто осталась в очереди, увеличивается количество задач пользователя. При нормальном запуске mrun передает серверу очередей идентификатор процесса-менеджера задачи, который сохраняется как один из параметров задачи наряду с временем старта.

Запрос состояния очереди (_Q_INFO_MSG_)

30 _rep_pid_ _user_logname_ _out_file_name_

В файл с полным именем _out_file_name_ пишется текстовая информация о состоянии очереди. Объем информации зависит от прав пользователя, данных ему администратором при генерации расписания. В настоящий момент задействовано два бита, т.е. 4 типа выдачи: секретный, секретный расширенный, полный, полный расширенный. Информация о своих задачах и параметрах режимов выдается всегда полная. Информация о свободных процессорах и других пользователях - только в полных типах. Секретный тип сокращает информацию о задачах других пользователей до их количества, секретный расширенный - до времени счета и предполагаемого времени старта по каждой задаче, полный не показывает лишь имя задачи. На самом деле, происходит перепись строк из файла inf/qinfo (куда при смене состояния сервер очередей записывает полную информацию) в пользовательский файл, возможно, с удалением части текста.

Выдача параметров текущего режима (_GET_REG_INFO_)

31 _rep_pid_

Ответное сообщение:

e_time e_proc q_time q_proc

где
e_time - максимальное количество минут отладочных задач;
e_proc - количествов процессоров, резервируемых для отладочных задач;
q_time - максимальное количество минут пакетных задач;
q_proc - максимальное количество процессоров отладочных задач.

Удаление задачи из очереди (_DEL_TASK_MSG_)

33 _rep_pid_ _user_logname_/_brief_image_name_

Если задача не считается, то она просто удаляется из очереди с уменьшением количества задач пользователя. В любом случае в очередь выходных сообщений записывается текстовое ответное сообщение для процесса _rep_pid_, содержащее в первой строке 0 или код ошибки, а в следующих строках - диагностику.

Переключение на новое расписание (_SPEC_SCHED_MSG_)

40 _new_schedule_num_

Осуществляется переход на новое расписание, если такое существует. Затем происходит перепланирование очереди с новыми параметрами режимов, а также пользовательскими установками. Накопляемые значения сохраняются.

Изменение числа выделенных под задачи процессоров (_MOD_RGMS_MSG_)

42 [-]_proc_num_

При наличии "-" количество процессоров, выделенных под задачи очереди, уменьшается, а при его отсутствии — увеличивается на _proc_num_. При этом в режимах сначала уменьшаются до 0 количества процессоров, выделенных под отладочные задачи, а лишь потом — под пакетные. Увеличение происходит в обратном порядке, но не более величин, заданных в расписании. Если количество захваченных процессоров остается больше нуля, то оно сохраняется в специальном файле.
ВНИМАНИЕ! Сбой в момент выполнения запроса может приводить к рассогласованию информационных файлов и действительности, но перед запуском задачи наличие свободных процессоров контролируется дополнительно по блокирующему каталогу. Таким образом, возможно лишь ошибочное откладывание запуска. Для ликвидации рассогласования требуется вмешательство администратора.

Замораживание всех задач (_HOLD_MSG_)

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

Размораживание всех задач (_UNHOLD_MSG_)

Все задачи будут планироваться на запуск в обычном порядке.

Размораживание конкретной задачи (_HOT_TASK_MSG_)

47 _rep_pid_ _user_logname_/_brief_image_name_

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

В состав сервера очередей входит специальная программа-утилита с именем (по умолчанию) /usr/runmvs/qserv/bin/qutil, которая может быть использована для взаимодействия с сервером очередей через очереди IPC. Программа-утилита использует очереди IPC с номерами 12346 и 64321. Утилита должна вызываться всегда с полным путем, формат вызова:

/usr/runmvs/qserv/bin/qutil <TAG> [PARAMETERS]

Утилита передает серверу очередей запрос с номером TAG и указанными параметрами, определяемыми типом запроса. Программа-утилита получает от сервера очередей ответ на посланный запрос и передает его пользователю. Заметим, что идентификатор процесса (_rep_pid_) не указывается при вызове утилиты – программа добавляет его сама при необходимости. Например, если вы хотите удалить из очереди задачу task.1 пользователя user, то можно воспользоваться программой-утилитой следующим образом:

/usr/runmvs/qserv/bin/qutil 33 user/task.1

Как минимум в двух случаях программа-утилита совершенно необходима администратору – при динамической смене расписания и при восполнении числа процессоров. Динамическая смена расписания осуществляется вызовом

/usr/runmvs/qserv/bin/qutil 40 <номер_расписания>

Если по какой-либо причине часть вычислительных модулей были помечены в блокирующем каталоге, как занятые, и в определенный момент времени администратор решил «освободить» помеченные модули, то, после очистки блокирующего каталога необходимо сообщить серверу очередей, что освободилось определенное количество процессоров (не модулей!). Сделать это можно с помощью следующего вызова программы-утилиты:

/usr/runmvs/qserv/bin/qutil 42 <число_освободившихся_процессоров>

1.4.2.5 Журнал событий сервера очередей

Как уже было сказано выше, сервер очередей ведет журнал событий в специальном лог-файле, имя которого задается в конфигурационном файле системы (по умолчанию - /usr/runmvs/qserv.log). Администратору необходимо знать формат журнала событий, чтобы понимать ситуацию, в которой находится сервер очередей.

Файл журнала событий (лог-файл) состоит из строк, каждая строка – одно событие. Общий формат строки следующий:

<тип><дата время><информация>

Первым символом строки идет тип события, который может принимать следующие значения:

‘*’ - информационное сообщение

‘+’ - сообщение о движении задач в очереди

‘-‘ – сообщение об ошибке

‘!’ – важное системное сообщение

Рассмотрим основные события, заносимые в журнал.

!23.10.00 08:57:start free:10 total:15

Сообщение о старте сервера очередей с указанием общего числа (total) доступных процессоров и числа свободных на момент старта (free).

*23.10.00 08:57:New UserSum

Обнуление статистики счета пользователей с автоматическим выравниванием приоритетов.

*23.10.00 08:57: RCV: TAG PID PARAMETERS

Сообщение о приеме запроса с номером TAG и параметрами PARAMETERS из очереди IPC от процесса PID. Форматы запросов описаны в п. 1.4.2.4.

*23.10.00 08:57: SND: CODE PID

Сообщение о посылке ответа с кодом возврата CODE процессу PID.

+23.10.00 11:57:queue user:kugush task:gen.7 CPU:4 time:6000 quant:300

Сообщение о постановке в очередь задачи (task) gen.7 пользователя (user) kugush. Задача требует 4 процессора (CPU) на 6000 минут (time). Задача является фоновой с квантом (quant) 300 минут.

+23.10.00 13:43:run user:kugush task:gen.7 CPU:4 time:6000 quant:300 pid:559

Сообщение о запуске задачи (task) gen.7 пользователя (user) kugush. Задача требует 4 процессора (CPU) на 6000 минут (time). Задача является фоновой с квантом (quant) 300 минут. Процесс-менеджер задачи имеет идентификатор (pid) 559.

+23.10.00 14:35:stop pid:559

Сообщение о завершении задачи, процесс-менеджер которой имел идентификатор (pid) 559.

+19.10.00 18:14:delete user:norma task:mpi_go.mpi.7

Сообщение об удалении из очереди задачи (task) mpi_go.mpi.7 пользователя (user) norma.

-05.10.00 18:07:error action:run name:balabaev/e3.15 message:Error on open input image: No such file or directory

Сообщение об ошибке. В этих сообщениях после ключевого слова action идет название действия, при котором произошла ошибка:

run – запуск задачи

queue – постановка в очередь задачи

delete – удаление из очереди задачи

Далее, после name следует имя файла-паспорта задачи, а после message – диагностика.

!17.05.00 19:45:exit signal:2

Завершение работы сервера очередей по сигналу 2.

1.4.3 Процесс mrun

Процесс mrun непосредственно запускает задачу. Формат вызова следующий:

mrun <имя_файла_паспорта_задачи>

По умолчанию mrun размещается в /usr/runmvs/bin. Процесс mrun может быть разным для разных логических систем, его местонахождение описывается в файле конфигурации логической системы в секции [General].

Процесс mrun считывает данные из файла-паспорта задачи и запускает ее. Процесс запуска рассмотрим подробнее.

1.4.3.1 Как запускается и завершается параллельная задача

Cервер runmvsd при получении запроса на запуск параллельной задачи выполняет следующие действия:

- проверяет корректность паспорта задачи;

- формирует запрос на запуск задачи к процессу qserver и отправляет этот запрос в соответствующую очередь IPC;

- ожидает код ответа от qserver'а из соответствующей очереди IPC.

Процесс qserver, получив запрос, при возможности непосредственного запуска (ресурсы свободны), делает следующее:

- вызывает процесс mrun, передавая ему в качестве параметра имя файла с паспортом задачи; в паспорте задачи, помимо прочих характеристик указывается имя пользователя, который запускает задачу;

- ожидает от mrun код ответа и сообщение и, при положительном коде, делает запись о старте задачи в файл лога;

- передает процессу runmvsd код ответа и сообщение от mrun.

Процесс mrun, будучи вызванным, делает следующее:

- еще раз проверяет корректность данных паспорта задачи;

- определяет (из паспорта задачи) и переключается на логическую систему;

- определяет число свободных процессоров в системе и, если задача хочет больше процессоров, выдает ошибочный код запуска;

- осуществляет выделение вычислительных модулей задаче из числа свободных;

- блокирует процесс запуска, чтобы другой mrun одновременно не запустил задачу; для этого mrun создает подкаталог RunTask в блокирующем каталоге логической системы;

- порождает процесс-менеджер задачи (manager), сообщает ему параметры запуска;

- ожидает от менеджера ответ о состоянии запущенной задачи;

- освобождает процесс запуска, удаляя подкаталог RunTask в блокирующем каталоге логической системы;

- формирует и передает вызвавшей программе через стандартный вывод код возврата и сообщение.

Порожденный mrun'ом процесс-менеджер задачи осуществляет следующее:

1) Создает подкаталог с именем запущенной задачи в каталоге стандартного ввода/вывода, указанном в паспорте задачи.

2) Формирует в этом каталоге следующие файлы:

- .hosts – файл содержит список имен вычислительных модулей, на которых должна выполняться параллельная задача;

- output – файл, куда будет перенаправлен стандартный вывод параллельной задачи;

- manager.log – файл стандартного вывода процесса-менеджера;

- runmvs.bat – командный файл, полученный из секции [Batch] паспорта задачи, данный командный файл служит для инициализации запуска параллельной задачи и будет выполнен на вычислительном модуле, стоящим первым в списке .hosts (модуль node0).

3) Подготавливает вычислительные модули из .hosts к запуску задачи данного пользователя, для чего запускает командный файл, имя которого определяется из значения параметра prepare_node секции [Run] конфигурационного файла (по умолчанию это файл /usr/runmvs/bin/prepare_nodes). Данный командный файл:

- осуществляет преобразование сетевых имен вычислительных модулей;

- монтирует на каждом модуле домашний каталог пользователя;

- записывает на каждом модуле в файл /etc/hosts_equiv разрешение на доступ по rsh для пользователя задачи с модуля node0.

4) Помечает вычислительный модуль как занятый, для чего создает в блокирующем каталоге подкаталог с именем занятого модуля.

5) Формирует файл с информацией о запущенной задаче в каталоге подкаталоге run пользователя, запустившего задачу. Данный подкаталог, напомним (см. п. 1.3.2 Специальные каталоги системы), размещается в базовом каталоге логической подсистемы.

6) Выполняет на модуле node0 командный файл runmvs.bat.

7) Посылает сигнал mrun'у о успешном (SIGUSR1) или неуспешном (SIGUSR2) старте задачи.

8) Порождает процесс sleeper, контролирующий время счета задачи (см. п. 1.2 Взаимодействие процессов в системе управления прохождением задач).

9) Ожидает завершения командного файла runmvs.bat, которое будет означать «естественное» завершение параллельной задачи.

При любом завершении задачи (см. п. 1.2 Взаимодействие процессов в системе управления прохождением задач) менеджер выполняет следующие действия:

10) Очищает вычислительные модули от процессов пользователя, для чего для чего запускает командный файл, имя которого определяется из значения параметра close_node секции [Run] конфигурационного файла (по умолчанию это файл /usr/runmvs/bin/close_nodes). Данный командный файл:

- убирает на каждом модуле из файла /etc/hosts_equiv разрешение на доступ по rsh для пользователя задачи;

- завершает все процессы пользователя на вычислительном модуле;

- выполняет протокол подтверждения перезагрузки (см. п. 1.4.3.2), освобождая при этом вычислительные модули путем удаления соответствующих подкаталогов из блокирующего каталога.

11) Записывает время завершения задачи в файл запущенной задачи в каталоге run пользователя, а затем переносит этот файл в каталог done этого же пользователя.

12) Посылает в соответствующую очередь IPC сообщение процессу qserver о своем завершении, сообщая при этом число неосвобожденных (не подтвердивших перезагрузку) процессоров (НЕ модулей!).

Процесс-менеджер воспринимает только два сигнала – TERM и INT – и только от суперпользователя или от своего sleeper'а. Отличие этих сигналов см. п. 1.2.

1.4.3.2 Протокол подтверждения перезагрузки

ВНИМАНИЕ! По умолчанию при установке системы вступает в действие упрощенный вариант настоящего протокола. См. по тексту ниже.

Рис. 3. Протокол подтверждения перезагрузки

Рассмотрим протокол подтверждения перезагрузки, который служит для уведомления менеджера задачи о том, что вычислительный модуль действительно был перезагружен и может быть помечен как свободный в блокирующем каталоге.

В протоколе участвуют три процесса (см. рис. 3): менеджер задачи (manager), процесс free_node – на управляющей ЭВМ, и процесс send_free_msg на каждом вычислительном модуле.

Процесс send_free_msg – это программа, которая вызывается из командного файла send_reboot. Данный командный файл выполняется при окончании загрузки ОС Linux на вычислительном модуле и оформляется в процессе установки системы управления прохождением задач как часть процесса загрузки (init). Таким образом, send_free_msg вызывается после перезагрузки ОС на вычислительном модуле.

Процесс send_free_msg соединяется с управляющей ЭВМ по серверному порту 27780. С этим портом на управляющей ЭВМ через демон inetd (xinetd) связана программа free_node. Процесс free_node, порождаемый при соединении send_free_msg c управляющей ЭВМ, принимает от send_free_msg имя перезагруженного вычислительного модуля.

Далее процесс free_node читает главный конфигурационный файл системы /usr/runmvs/.grunmvs, определяет блокирующие каталоги всех логических систем, просматривает блокирующие каталоги с целью поиска подкаталога с именем перезагруженного модуля. Когда процесс free_node находит такой каталог, он открывает именованный программный канал (fifo) с менеджером параллельной задачи, выполнявшейся на перезагруженном модуле.

Именованные программные каналы с именем fifo создаются менеджером во всех подкаталогах блокирующего каталога, соответствующих выделенным параллельной задаче вычислительным модулям. После выдачи команд на перезагрузку вычислительных модулей, менеджер задачи начинает ждать сообщений из созданных им именованных каналов. Сообщения посылаются в именованный канал процессами free_node, автоматически порождаемыми при перезагрузке вычислительных модулей. Каждое сообщение содержит имя перезагруженного модуля. Получив это имя, менеджер выполняет действия по освобождению соответствующего модуля, т.е. уничтожает из блокирующего каталога подкаталог с именем модуля.

ВНИМАНИЕ! Если один или несколько вычислительных модулей по каким-либо причинам не перезагрузятся, то менеджер будет бесконечно долго ждать. Если администратор обнаруживает ждущего менеджера, он должен послать ему сигнал USR1. По этому сигналу менеджер прекращает ожидание перезагрузки и сообщает серверу очередей о завершении задачи. При этом менеджер передает число неосвобожденных процессоров на тех вычислительных модулях, которые не перезагрузились. В дальнейшем эти модули будут считаться занятыми в системе. Сервер очередей автоматически скорректирует число доступных для параллельных задач процессоров. После того, как администратор устранит причину сбоя при перезагрузке, он должен вручную удалить подкаталоги с именами отказавших модулей из соответствующего блокирующего каталога и выполнить действия п. 3.5.

ВНИМАНИЕ! По умолчанию после установки работает упрощенный протокол перезагрузки. Его отличие от приведенного выше заключается в том, что вычислительный модуль не перезагружается, на нем лишь уничтожаются все процессы, принадлежащие пользователю параллельной задачи. При этом на управляющей ЭВМ из скрипта close_nodes непосредственно вызываются программы free_node, которые соединяются с менеджером задачи описанным выше образом. Переход с одного варианта протокола на другой можно осущесвить, изменив следующие строки в командном файле /usr/runmvs/bin/close_nodes:

# Если следующую строку закомментировать,

# то выключится упрощенный протокол

( echo $host | /usr/runmvs/bin/free_node ) &

# Если следующую строку раскомментировать,

# то включится протокол с перезагрузкой

# /usr/bin/rsh $host /sbin/reboot

Будьте внимательны, т.к. закомментирована должна быть одна и только одна строка командного файла из двух приведенных. В противном случае система может вести себя некорректно!

2. Инструкция по установке системы управления прохождением задач

Установка производится суперпользователем.

1. Выполните условия, оговоренные в п. 1.3.3.

2. Раскройте архив setup.vX.tar.gz (например в каталог /setup), где X – номер версии.

3. На управляющей ЭВМ создайте каталог /usr/runmvs. Права на доступ к нему (и к его подкаталогам) должен иметь только суперпользователь

4. Создайте каталог /usr/runmvs/qserv

5. Создайте каталог /usr/runmvs/qserv/src

6. Скопируйте файлы из /setup/qserv/src в /usr/runmvs/qserv/src

7. Перейдите в /usr/runmvs/qserv/src

8. Выполните ./mkqq

9. Создайте каталог /usr/runmvs/bin, данный каталог должен быть в путях у суперпользователя.

10. Скопируйте файлы из /setup/runmvs/bin в /usr/runmvs/bin

11. Зарегистрируйте в системе сетевые службы runmvs и free_node, для чего вставьте в файл /etc/services следующие строки:

#имя_службы номер_порта/протокол

runmvs 27778/tcp

free_node 27780/tcp

12. Если используется демон inetd, то введите службы runmvs и free_node в его конфигурацию, для чего вставьте в файл /etc/inetd.conf следующие строки:

#имя_службы тип_соединения протокол флаг_wait пользователь путь имя

runmvs stream tcp nowait root /usr/runmvs/bin/runmvsd runmvsd

free_node stream tcp nowait root /usr/runmvs/bin/free_node free_node

Определите pid демона inetd командой

ps ax | grep inetd

и пошлите inetd сигнал для того, чтобы демон перечитал свою конфигурацию:

/bin/kill –s HUP inetd_pid

Здесь inetd_pid - pid демона inetd, определенный ранее.

13. Если используется демон xinetd, то введите службы runmvs и free_node в его конфигурацию, для чего скопируйте файлы из /setup/etc/xinetd.d в /etc/xinetd.d. После этого выполните:

/etc/init.d/xinetd stop

/etc/init.d/xinetd start

14. Создайте каталог runmvs/bin в том каталоге, который будет смонтирован на всех вычислительных модулях и будет виден всем пользователям (в нашем примере - /common). Каталог /common/runmvs/bin должен быть в начале путей у всех пользователей, для чего исправьте профайлы у существующих пользователей, а также в /etc/skel для будущих.

15. Скопируйте файлы из /setup/runmvs/client/bin в /common/runmvs/bin.

16. ВНИМАНИЕ!!! В каталоге /common/runmvs/bin находится файл mpirun. Именно этот файл должен использоваться для запуска пользователями MPI-программ. После записи каталога /common/runmvs/bin в пути пользователей убедитесь, что при запуске будет использоваться указанный mpirun, а не стандартный. Если MPI устанавливается в директорию, отличную от /common/mpich в файле mpirun требуется изменить значение переменной MPIR_HOME на имя этой директории.

17. Скопируйте образец конфигурационного файла системы из /setup/runmvs/.grunmvs в /usr/runmvs/.grunmvs. Внесите в файл /usr/runmvs/.grunmvs необходимые настройки согласно п. 1.3.4.

18. Создайте блокирующую директорию, указанную в конфигурационном файле /usr/runmvs/.grunmvs (по умолчанию - /usr/runmvs/lock). Определите права на любой доступ к ней только для суперпользователя.

19. В результате предыдущих шагов в каталоге /common должен находиться файл runmvs/bin/sendreboot. В этом файле в качестве значения переменной host поставьте сетевое имя управляющей ЭВМ. После этого НА КАЖДОМ вычислительном модуле системы скопируйте этот файл в /etc/rc.d/init.d и выполните

rshall /sbin/chkconfig --add sendreboot

20. Скопируйте файл пользовательских настроек /setup/runmvs/.crunmvs во все домашние каталоги существующих пользователей, а также в /etc/skel и поменяйте в нем параметры по умолчанию согласно образцу:

# Это комментарий

# Следующая строка - название секции

[General]

# Далее идет содержимое секции

# Следующая срока определяет имя каталога

# для временных файлов

# (где системе можно мусорить)

# Если имя не задано или задано неправильно

# система будет использовать каталог /tmp

tmp_directory = ~/runmvs

# Следующая срока определяет имя управляющей ЭВМ

host = rscu_1

21. Генерация расписаний для сервера очередей

Для генерации расписаний надо перейти в каталог /usr/runmvs/qserv/src. В текстовом редакторе в файле qqset.hc исправить по образцу параметры расписания режимов работы, учтя имеющиеся комментарии и установив нужные значения. Выполнить

./mksched <номер_расписания>

Убедитесь, что параметры режимов, которые выдались на экран, совпадают с заданными. Подробно процесс генерации расписаний описан в 3.2 Генерация расписания очереди.

22. Выполните:

ln –s /usr/runmvs/.grunmvs /usr/runmvs/qserv/.grunmvs

cd /usr/runmvs/qserv/sched; ln –fs <номер_расписания> 0

23. Установка правил фильтрации

Перед установкой правил фильтрации убедитесь в том, что ваша система поддерживает использование правил фильтрации. Для этого проверьте существование файла /proc/net/ip_fwchains. Если он существует, Вы можете использовать правила фильтрации, если нет, то необходимо произвести настройку ядра вашей машины для включения этой возможности. Для более подробной информации о настройке ядра смотрите документацию к вашей системе.

После того, как Вы убедились в поддержке правил фильтрации вашим ядром, определите уровень запуска системы. Для этого необходимо посмотреть файл /etc/inittab. Данный файл, кроме всего прочего, содержит параметр initdefault, определяющий уровень запуска по умолчанию.

После этого выполните следующие действия:

Для управляющей ЭВМ:

Скопируйте файлы, содержащие правила фильтрации в каталог /etc/rc.d/init.d.

cp /setup/filterrules/filterrules /etc/rc.d/init.d/filterrules

cp /setup/filterrules/norules /etc/rc.d/init.d/norules

Отредактируйте файл /etc/rc.d/init.d/filterrules, заменив адрес 192.168.11.50 адресом вашей управляющей машины. При необходимости Вы можете изменять или добавлять имеющиеся в файле правила фильтрации.
Перейдите в каталог загрузки.

cd /etc/rc.d/rcX.d. Где X – значение взятое из файла /etc/inittab.

Установите ссылки на файлы filterrules и norules.

ln -s ../init.d/filterrules S15filterrules

ln –s ../init/d/norules K90norules

Перезапустите систему.

Для вычислительных модулей. Выполняйте указанные действия для каждого модуля в отдельности:

Скопируйте файлы, содержащие правила фильтрации в каталог /etc/rc.d/init.d.

cp /setup/filterrules/modul/filterrules /etc/rc.d/init.d/filterrules

cp /setup/filterrules/modul/norules /etc/rc.d/init.d/norules

Отредактируйте файл /etc/rc.d/init.d/filterrules, заменив адрес 192.168.11.20 адресом модуля. При необходимости Вы можете изменять или добавлять имеющиеся в файле правила фильтрации.
Перейдите в каталог загрузки.

cd /etc/rc.d/rcX.d. Где X – значение взятое из файла /etc/inittab.

Установите ссылки на файлы filterrules и norules.

ln -s ../init.d/filterrules S70filterrules

ln –s ../init/d/norules K25norules

Перезапустите модуль.

3. Команды администратора

Большинство команд администратора выполняются с управляющей ЭВМ. Стандартное размещение этих команд – каталог /usr/runmvs/bin. Убедитесь, что этот каталог присутствует в путях у суперпользователя.

3.1 Просмотр очереди

Просмотр очереди осуществляется по команде

mqueue [<IPC_to_qserver> <IPC_from_qserver>]

или

mqinfo

или

more /usr/runmvs/qserv/inf/qinfo

Параметрами команды mqueue являются номера очередей IPC к серверу очередей и от него. Если параметры опущены, по умолчанию будут использованы номера 12346 и 64321 соответственно. Примерная информация, выдаваемая командой, выглядит следующим образом (для пользователя с именем ant):

Queue state at Wed Mar 22 12:40:07 2000

--- 22.03.00 07:30: total – 32 debug – 16/15, packet – 300, priority scale - (120 300 0 0 0)

tnet.2 : ant 0* 10 1200/15 ~10 Mon Mar 22 13:16:09 2000

tnet.7 : ant 1* 10 15/15 ~10 <:Mon Mar 22 13:31:09 2000

--- 22.03.00 19:00: total – 32 debug - 0/15, packet - 600, priority scale - (10000 0 0 0 0)

tnet.3 : ant 1* 24 500/500 ~312 <:Mon Mar 22 20:31:09 2000

--- 23.03.00 07:30: total – 32 debug - 16/15, packet - 300, priority scale - (120 300 0 0 0)

tnet.1 : ant 1* 1 15/15 ~~~ <:Mon Mar 20 20:31:09 2000

Free: 2 proc.

ant: run=0 wait=5/5 all=5/7 *1.00 Sr/Sf=0/0

Если очередь блокирована (заморожена), то это отображается словом HOLDED при выдаче:

Queue state at Wed Mar 22 12:40:07 2000

HOLDED

--- 22.03.00 07:30: total – 32 debug – 16/15, packet – 300, priority scale - (120 300 0 0 0)

tnet.7 : ant 1* 10 15/15 ~~~ <:Mon Mar 22 13:31:09 2000

--- 22.03.00 19:00: total – 32 debug - 0/15, packet - 600, priority scale - (10000 0 0 0 0)

tnet.3 : ant 1* 24 500/500 ~~~ <:Mon Mar 22 20:31:09 2000

--- 23.03.00 07:30: total – 32 debug - 16/15, packet - 300, priority scale - (120 300 0 0 0)

tnet.1 : ant 1* 1 15/15 ~~~ <:Mon Mar 20 20:31:09 2000

Информация о режимах начинается с ‘---‘ и содержит:

- дата и время включения режима;

- после total – общее число планируемых процессоров;

- после debug – количество процессоров, отведенное под отладочные задачи/максимальное время (в минутах) для отладочных задач;

- после packet – максимальное время (в минутах) для пакетных задач;

- после priority scale – шкала приоритетов.

Следующий пример демонстрирует режим, который включается 22 марта 2000 г. в 7 часов 30 минут и имеет следующие параметры: всего планируется 32 процессора, максимальное время для отладочных задач – 15 минут, для пакетных – 300 минут, при этом под отладочные задачи отведено 16 процессоров, эти 16 процессоров не могут занимать пакетные задачи, шкала приоритетов определяет два приоритета – высокий для пользователей, считавших менее 180 минут, и низкий - для всех остальных.

---22.03.00 07:30: total–32 debug-16/15, packet–300, priority scale-(180 0 0 0 0)

Информация о считающихся задачах содержит:

- имя задачи;

- имя пользователя;

- количество оставшихся повторов счета;

- количество процессоров, занимаемых задачей;

- остаток заказа общего времени счета в минутах;

- заказ кванта счета в минутах;

- количество минут до предполагаемого завершения задачи;

- предполагаемое время завершения.

Следующий пример демонстрирует считающуюся задачу img1.3 пользователя guest. Задача занимает 15 процессоров, считается последний раз (более повторов не будет), оставшееся время счета – 150 минут, задача фоновая с квантом 15 минут, будет перезапущена системой через 15 минут 2 августа 1999 года в 18 часов 3 минуты.

img1.3 : guest 0* 15 150/15 15 Mon Aug 2 18:03:16 1999

Информация о стоящих в очереди задачах отличается от информации о считающихся

задачах тем, что вместо количества минут до завершения выдается количество минут до предполагаемого старта, а вместо времени завершения — время постановки в очередь.

Например:

img1.2 : ant 1* 16 300/300 ~14 <:Mon Aug 2 18:00:50 1999

Если задача по расчетам сервера очередей должна была завершиться, а сигнал о завершении от менеджера не поступил, это отмечается в выдаче следующим образом:

img1.3 : guest 0* 15 150/15 finishing

ВНИМАНИЕ! Подобная выдача, как правило, означает, что при завершении задачи не отработал протокол подтверждения перезагрузки (см. п. 1.4.3.2). Следовательно, все или часть вычислительных модулей занятых задачей могут быть неисправны.

Задача может быть заморожена оператором или системой. В этом случае вместо времени, оставшегося до старта будет проставлено ~~~, например:

img1.2 : ant 1* 16 300/300 ~~~ <:Mon Aug 2 18:00:50 1999

Имеется информация о свободных процессорах в виде:

Free: 32 proc

Затем выдается суммарная информация по пользователю:

- login-имя;

- после run - количество считающихся задач;

- после wait - количество ждущих задач/ограничение на количество ждущих задач;

- после total - суммарное количество задач в очереди/ограничение на суммарное количество задач в очереди;

- коэффициент умножения при вычислении цены задачи;

- после Sr/Sf - суммарная стоимость считающихся задач/суммарная стоимость закончившихся задач;

Например,

guest: run=1 wait=0/1 ttl=1/1 *1.00 Sr/Sf=15/14

Отметим, что состояние очереди можно определить, прочитав файл inf/qinfo, находящийся в базовом каталоге сервера очередей (см. п. 1.4.2.2 Система каталогов и специальных файлов сервера очередей). При установке это файл с полным именем /usr/runmvs/qserv/inf/qinfo. В распоряжении администратора имеется командный файл mqinfo, читающий этот файл.

3.2 Генерация расписания очереди

Для генерации расписаний надо перейти в каталог src базового каталога сервера очередей (см. п. 1.4.2.2). Параметры режимов задаются путем редактирования файла qqset.hc. Данный файл представляет собой исходный текст программы генерации режимов на языке C, поэтому будьте внимательны при редактировании и не допускайте синтаксических ошибок. Рассмотрим поля этого файла, позволяющие изменять основные характеристики режимов работы сервера очередей.

Напоминаем, что сервер очередей оперирует с понятием «процессор», а не «вычислительный модуль», администратор должен это учитывать и правильно задавать параметры, величинами которых является число процессоров.

В начале файла определен макрос, обозначающий общее число процессоров в системе, отданных под планирование очередей:

#define total_proc 32

Заметим, что число планируемых процессоров может быть разным в разных режимах, но по умолчанию подставляется total_proc.

Далее идут три примерных шкалы приоритетов – для дневного режима (DayL), для ночного (NightL) и свободная (FreeL), делающая очереди неприоритетными:

static s_sumlmtT DayL = { 0.5, 60, 120, 360, 600 };

static s_sumlmtT NightL = { 720, 0, 0, 0, 0 };

static s_sumlmtT FreeL = {100000, 0, 0, 0, 0};

Как видно, шкала приоритетов – это переменная типа s_sumlmtT. Администратор может либо исправить примерные шкалы, либо определить свою.

Следующее имеющее значение поле – это вызов функции IRgm_date(), определяющей дату включения очередного режима. Функция IRgm_date() принимает два числовых параметра – месяц и число включения режима. При этом в распоряжении администратора имеются два джокера – Com, обозначающий любой месяц, и Day, обозначающий любой день. Если указать их вместе (вызвать IRgm_date(Com,Day)), то режим будет применяться в любой день.

ВНИМАНИЕ! После вызова IRgm_date() все установки режимов будут автоматически отнесены к дате, указанной в параметрах функции. Таким образом, более поздний (по тексту qqset.hc) вызов IRgm_date() перезаписывает параметры более раннего вызова. Поэтому вызов IRgm_date(Com,Day) и следующие за ним определения параметров планирования на каждый день должны стоять ПЕРВЫМИ по тексту. Последующие вызовы IRgm_date() будут определять параметры для конкретных дней или дат.

Кроме определения параметров для всех дней можно определить параметры для всех определенных дней недели, например, после вызова

IRgm_date(Com,Fri);

будут определены параметры для всех пятниц.

После вызова IRgm_date() должен следовать вызов функции IRgm_time(), определяющей время включения режима. В качестве параметров указываются час и минута включения. В отношении IRgm_time() действует то же правило, что и в отношении IRgm_date(): все параметры, указанные после вызова IRgm_time() будут отнесены к заданному в параметрах вызова времени.

После определения даты и времени включения режима идут определения основных характеристик режима. Вызов IRgm_proc(total_proc) определяет общее число процессоров, планируемых в данном режиме. Администратор может оставить total_proc, либо задать общее число планируемых процессоров непосредственно для конкретного режима.

Вызов IRgm_eproc(debug_proc) определяет число debug_proc процессоров, резервируемых под отладочные задачи (см. п. 1.1.2 Основные принципы построения очередей). Согласно принципам планирования пакетные и фоновые с большим квантом задачи не смогут в сумме занять процессоров больше, чем total_proc-debug_proc.

Вызов IRgm_etm(debug_task_time) определяет время debug_task_time отладочной задачи в минутах. Все задачи со временем выполнения или квантом (для фоновых задач), не превышающим debug_task_time, будут считаться отладочными в данном режиме и обладать правом занимать зарезервированные процессоры.

Вызов IRgm_qtm(packet_task_time) определяет время packet_task_time пакетной задачи в минутах. Любая задача со временем исполнения или квантом (для фоновых задач), превышающем packet_task_time, НЕ БУДЕТ включена в счет в данном режиме.

Вызов IRgm_sumlmt(Priority_Scale) определяет шкалу приоритетов для данного режима. Параметр Priority_Scale должен быть переменной типа s_sumlmtT, определенной выше по тексту qqset.hc. В качестве значения параметра можно использовать примерные шкалы DayL, NightL и FreeL.

После определения параметров всех режимов идет определение пользовательских настроек. Вызов IRgm_uname() определяет пользователя, для которого будут определяться настройки. В качестве параметра данная функция принимает строку, содержащую имя пользователя. Обратите внимание на необходимость заключения имени пользователя в кавычки, чтобы строка соответствовала синтаксическим требованиям языка C. Все настройки, помещенные после вызова IRgm_uname() будут отнесены к тому пользователю, чье имя указано в вызове. Если указать в качестве параметра IRgm_uname() значение com_user БЕЗ КАВЫЧЕК, то это будет означать определение настроек для всех пользователей.

Вызов IRgm_uscl(Rgm0) задает битовую шкалу, определяющую полноту информации, выдаваемой по команде mqinfo (см. Руководство пользователя). Если указать стандартную шкалу Rgm0, то пользователю будет выдаваться информация только о его собственных задачах. Для суперпользователя (после вызова IRgm_uname("root")) необходимо указать битовую шкалу, позволяющую получать полную информацию об очереди путем вызова

IRgm_uscl(ADV_INF_TAG | FULL_INF_TAG);

Вызов IRgm_umult() определяет цену минуты счета для пользователя. Значение, указанное в этом вызове, будет использоваться системой как множитель при подсчете реального времени выполнения задачи. Очевидно, путем задания цены времени можно влиять на приоритет пользователя. Будьте внимательны, параметром функции является вещественное, а не целое число, поэтому следует всегда указывать знак десятичной запятой. Например, вызов

IRgm_umult(1.);

определяет единичную цену задачи.

Вызовы IRgm_uttlt() и IRgm_uwaitt() определяют, соответственно, общее число задач и число одновременно планируемых задач пользователя. Пользователь не сможет поставить в очередь задач больше, чем указано в вызове IRgm_uttlt(), при этом планироваться из них будет столько задач, сколько указано в IRgm_uwaitt().

Запуск задач от имени суперпользователя целесообразно запретить, указав

IRgm_uttlt(0);

IRgm_uwaitt(0);

После редактирования файла qqset.hc для его трансляции и генерации расписания необходимо выполнить

./mksched <номер_расписания>

На экран будут выведены заданные администратором параметры. Необходимо убедиться, что они совпадают с заданными. При этом в каталоге sched базового каталога сервера очередей появится файл с именем номер_расписания, содержащий сгенерированное расписание. Одновременно будут сформированы следующие файлы (N – номер расписания):

sched/src.N – исходный файл qqset.hc

sched/N.old – предыдущее расписание с этим номером (если было)

sched/oldsrc.N – предыдущий исходный файл qqset.hc

Как уже упоминалось, сервер очередей принимает к исполнению расписание с номером 0. Соответствующий файл в каталоге sched базового каталога сервера очередей должен быть символической ссылкой на файл с текущим расписанием. Сервер очередей распознает указанную ссылку и правильно определит номер расписания.

3.2.1 Динамическая смена расписания

Поменять расписание без перезагрузки сервера очередей можно с помощью программы-утилиты:

/usr/runmvs/qserv/bin/qutil 40 <номер_расписания>

3.3 Удаление задачи из очереди

Удаление задачи из очереди осуществляется по команде mqdelete. Формат:

mqdelete <пользователь>/<задача> [<IPC_to_qserver> <IPC_from_qserver>]

Параметры IPC_to_qserver и IPC_from_qserver данной команды задают номера очередей IPC к серверу очередей и от него. Если эти параметры опущены, по умолчанию будут использованы номера 12346 и 64321 соответственно.

Если Вам надо удалить из очереди задачу task.12 пользователя shiva, то следует выполнить команду:

mqdelete shiva/task.12

3.4 Блокировка очереди

3.4.1 Блокировка (замораживание) очереди

Очередь может быть блокирована (заморожена) администратором по команде

mhold [<IPC_to_qserver> <IPC_from_qserver>]

Параметрами данной команды являются номера очередей IPC к серверу очередей и от него. Если параметры опущены, по умолчанию будут использованы номера 12346 и 64321 соответственно.

По этой команде запуск задач, стоящих в очереди и поступающих в нее, приостанавливается на неопределенное время. На экран будет выведено состояние блокированной очереди.

3.4.2 Разблокирование (размораживание) всей очереди

Очередь может быть разблокирована (разморожена) целиком по команде

munhold [<IPC_to_qserver> <IPC_from_qserver>]

По этой команде сервер очередей начнет планирование задач на запуск. На экран будет выведено новое состояние очереди.

3.4.3 Разблокирование конкретной задачи

Если очередь заблокирована, то можно разблокировать конкретную задачу по команде munhold (одну задачу за одну команду). Формат:

munhold <пользователь>/<задача> [<IPC_to_qserver> <IPC_from_qserver>]

Например, если Вам надо разморозить задачу tnet.2 пользователя LACIS, то следует выполнить команду:

munhold LACIS/tnet.2

Если необходимо срочно «протащить» через очередь какую-либо задачу, то действия администратора таковы:

- замораживаете всю очередь;

- размораживаете нужную задачу, убеждаетесь, что она либо запустилась, либо встала на первое место в текущем режиме;

- размораживаете всю очередь.

3.5 Сообщение серверу очередей об освободившихся процессорах

В процессе работы системы может возникнуть ситуация, когда часть вычислительных модулей осталась заблокированной (не были вычищены соответствующие подкаталоги блокирующего каталога). Основных причины может быть две – блокирование модулей администратором и сбой при отработке протокола подтверждения перезагрузки (см. п. 1.4.3.2). Когда администратор устранит сбойную ситуацию и разблокирует модули, удалив соответствующие подкаталоги из блокирующего каталога, необходимо сообщить серверу очередей, что часть процессоров освободилась. Сделать это можно с помощью программы-утилиты:

/usr/runmvs/qserv/bin/qutil 42 <число_освобожденных_процессоров>

3.6 Управление запущенными задачами

mtask - посмотреть выполняющиеся задачи

killtask manager_pid1 [manager_pid2]…]

termtask manager_pid1 [manager_pid2]…] - принудительно завершить задачи

stopwait manager_pid1 [manager_pid2]…] – выполняйте эту команду при долгом «зависании» задачи уже после команд killtask или termtask.

3.7 Очистка системы после перезагрузки

сlmvs- очистить систему прохождения задач. ВНИМАНИЕ!!! Данный скрипт очищает все каталоги системы прохождения задач, завершает все процессы, относящиеся к задачам, завершает сервер очередей и разблокирует все процессоры. Данный скрипт должен выполняться только, если все узлы вычислителя свободны от задач или только что перезагружены. Данный скрипт не очищает очереди. Кроме этого, администратор должен поставить в него правильное значение переменной LOCK_DIR, соответствующее значению параметра lock_directory секции [General] файла /usr/runmvs/.grunmvs.

clqueue - данный скрипт вызывает clmvs, после чего очищает и очереди.

	Параллельные вычисления в ИММ УрО РАН

НОВАЯ ВЕРСИЯ САЙТА New

1.4.1 Сервер запросов runmvsd

1.4.1.1 Протокол сервера runmvsd

1.4.1.1.2 Команды сервера runmvsd

1.4.2 Сервер очередей qserver

1.4.3 Процесс mrun