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

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

Есть две проблемы, которые всегда возникают, когда необходимо решать подобные задачи:

1. Первая: недостаток времени. Если задача выполняется в течение шести недель, было бы очень неплохо, если бы время ее счета сократилось до шести дней.

2. Вторая: недостаток памяти. Предположим, к примеру, мы решаем численно систему дифференциальных уравнений на разностной сетке. Размерность сетки всегда ограничена объемом оперативной памяти компьютера. Нет ничего невероятного в том, что увеличивая размерность разностной сетки (увеличивая детализацию) мы можем получить интересные тонкие эффекты, которые, хотя и описываются исходными уравнениями, но скрыты от нас слишком грубой сеткой.

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

3.3.1 Процесс декомпозиции

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

Существует широкий спектр методов декомпозиции задачи. На следующем рисунке представлена классификация таких методов.

Рисунок 3.2 - Классификация методов декомпозиции

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

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

Рисунок 3.3 - Пример реализации параллельной программе

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

Предположим наша задача сводится к применению некоего функционального оператора к большому массиву данных: S[i]=F(a[i]). Предположим также, что выполнение функции F над одним элементом массива занимает достаточно большое время и нам хотелось бы это время сократить. В этом случае мы можем попытаться представить исходную функцию как композицию нескольких фунуций: S(a[i])=I(H(R(a[i]). Произведя декомпозицию мы получим систему последовательных задач:

x=r(a[i]);

y=h(x);

b[i]=i(y);

Каждая из этих задач может быть выполнена на отдельном узле кластера. Как можно заметить общее время обработки одного элемента массива a[i] в результате не изменяется, а скорее немного увеличивается за счет межпроцессорных пересылок. Однако общее время обработки всего массива заметно снижается за счет того, что в нашем примере одновременно идет обработка сразу трех элементов массива.

У данного метода декомпозиции есть пара особенностей, о которых надо помнить.

Первая особенность состоит в том, что выход кластера на максимальную эффективность происходит не сразу после запуска задачи, а постепенно, по мере того, как происходит частичная обработка первого элемента массива. Второй и третий процессоры в нашем примере, которые отвечают за выполнение функций g(x) и f(y), будут простаивать до тех пор, пока не закончится выполнение функции h(a[1]) на первом процессоре. Третий процессор будет простаивать до окончания выполнения функции g(a[1]). По аналогичному сценарию, только в зеркальном отображении, происходит окончание работы.

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

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

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

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

3.3.2 Параллельная виртуальная машина кластера кафедры АИС

Так как в основе кластера АИС лежит параллельная система Beowulf, в качестве основы его вычислительной среды используем коммуникационную библиотеку PVM (Параллельная Виртуальная Машина).

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

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

Главная цель использования PVM - это повышение скорости вычислений за счет их параллельного выполнения. Функционирование PVM основано на механизмах обмена информацией между задачами, выполняемыми в ее среде. В этом отношении наиболее удобно реализовывать PVM в рамках многопроцессорного вычислительного комплекса, выделив виртуальной машине несколько процессоров и общее или индивидуальные (в зависимости от условий) ОЗУ. Использование PVM допустимо как на многопроцессорных компьютерах (SMP) так и на вычислительных комплексах, построенных по кластерной технологии.

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

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

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

Способ организации параллельного счета выглядит следующим образом. Сначала запускается одна задача (master), которая в коллективе задач будет играть функции координатора работ. Эта задача производит некоторые подготовительные действия, например инициализация начальных условий, после чего запускает остальные задачи (slaves), которым может соответствовать либо тот же исполняемый файл, либо разные исполняемые файлы. Такой вариант организации параллельных вычислений предпочтительнее при усложнении логики управления вычислительным процессом, а также когда алгоритмы, реализованные в разных задачах, существенно различаются или имеется большой объем операций (например, ввода - вывода), которые обслуживают вычислительный процесс в целом.

3.3.2.1 Взаимодействие задач с PVM

В системе PVM каждая задача, запущенная на некотором процессоре, идентифицируется целым числом, которое называется идентификатором задачи (TID) и по смыслу похоже на идентификатор процесса в операционной системе Linux. Система PVM автоматически поддерживает уникальность таких идентификаторов: копии одного исполняемого файла, запущенные параллельно на N процессорах PVM, создают N задач с разными TID.

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

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

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

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

Память для буферных массивов на передающей и приемной стороне выделяется динамически, следовательно, максимальный объем сообщений ограничивается только объемом доступной памяти. Если одна из задач, запущенных в PVM, не может получить требуемую память для общения с другими задачами, то она выдает пользователю соответствующее сообщение об ошибке ("cannot get memory"), но другие задачи об этом событии не извещаются и могут, например, продолжать посылать ей сообщения.

3.3.2.2 Управление задачами в PVM

Управление задачами в PVM осуществляется на основе некоторого набора функций. Существует два варианта (два стиля) написания параллельных задач для PVM. В первом варианте весь исполняемый на всех процессорах код пишется как одна большая задача. Соответственно на каждом процессоре запускается на исполнение один и тот же файл. Обычно в самом начале своей работы программы вызывает функцию call pvmfmytid(tid), возвращающую значение идентификатора задачи tid >= 0, которым может определяться выбор для выполнения той или иной части программы. Эта функция может вызываться более одного раза.

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

call pvmfspawn( task, flag, where, ntask, tids, numt )

task - имя исполняемого файла

INTEGER flag - опции запуска

where - указывает место запуска

INTEGER ntask - число запускаемых копий программы

INTEGER tids - массив значений tid для запущенных задач

Эта функция запускает в PVM ntask копий исполняемого файла с именем "task" с одинаковыми аргументами командной строки в массиве argv и возвращает число запущенных задач numt а также последовательность идентификаторов для запущенных задач. Второй вариант написания параллельной задачи заключается в том, что для каждого процессора пишутся свои собственные задачи, выполняющие различные действия, и создается маленькая программа, которая, используя функцию pvm_spawn, запускает все остальные задачи.

Исполняемый файл для функции pvm_spawn() должен находиться в строго определенном каталоге. Под Linux задача ищется в каталогах $PVM_ROOT/bin/$PVM_ARCH/ и $HOME/pvm3/bin/$PVM_ARCH. Задавать имя каталога в параметре "task" недопустимо.

В другом варианте исполняемый файл ищется (и запускается) не только на том компьютере, на котором работает вызвавшая pvm_spawn() задача, но в зависимости от параметров flag и where, на любом входящем в состав PVM. Например, если flag==0, то PVM сам выбирает, на какой из машин запускать новые задачи (главное, чтобы приложение было скомпилировано на этих машинах); а если flag & PvmMppFront > 0, то местом запуска будет выбран самый быстрый компьютер.

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

1. В FORTRANe flag может быть суммой следующих величин:

2. PVMDEFAULT=0 - PVM может выбрать любую машину для старта задачи

3. PVMHOST=1 - параметр where определяет машину для запуска

4. PVMARCH=2 - параметр where определяет тип архитектуры

5. PVMDEBUG=4 - процесс старует под отладчиком

6. PVMTRACE=8 - процесс генерирует PVM trace data.

Параметр where описывает на каких компьютерах кластера может быть запущена задача. Параметр является простой строковой переменной, в которую записано имя списка компьютеров. Списки компьютеров находятся в конфигурационных файлах системы PVM и формируются на этаме ее установки. Например в случае, когда в вашем кластере кроме консольной машины присутствует еще два компьютера: один класса P166 и другой класса P4, вы можете определить их в системе под именами "oldcomp" и "supercomp". И в зависимости от тех или иных условий, запускать свои задачи на какой-либо их этих машин кластера.

И, наконец, еще две функции, относящиеся к управлению задачами:

call pvmfkill( tid, info )

call pvmfexit( info )

Первая из них завершает выполнение задачи с идентификатором tid, возвращая при ошибке код ошибки info < 0. Отметим, что задача не может таким образом завершить свое выполнение. Вторая функция завершает работу PVM, запущенной пользователем, но при этом сама задача продолжает выполняться уже как обычная локальная задача и завершает работу обычным образом.

3.3.2.3 Передача сообщений в PVM

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

1. Первый шаг состоит в том, что буфер данных перед посылкой должен быть проинициализирован с использованием функций pvm_initsend() или pvm_mkbuf().

2. На втором шаге, пересылаемые данные должны быть "упакованы" в этот буфер. Для упаковки используется некоторе количество комбинаций вызовов функции pvm_pk*(). В FORTRANе упаковка данных производится подпрограмой pvmfpack().

3. Третий шаг заключается в пересылке данных адресатам. Для этой цели в зависимости от списка адресатов используется вызов функции pvm_send(), в параметрах которой указывается конкретный процесс-приемник, или функции pvm_mcast(), используемой для всенаправленной передачи (то есть всем процессам сразу).

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

- для приема любых сообщений

- для приема любых сообщений от определенного источника

- для приема любых сообщений с определенным message tag

- для приема любых сообщений с определенным message tag от определенного источника

Кроме того, существует функция для проверки факта доставки сообщения адресату.

Буфер сообщения:

call pvmfinitsend( encoding, bufid )

Если пользователь использует только один буфер сообщения (обычно так и делается), то единственная необходимая для работы с буфером функция это pvm_initsend(). Эта функция вызывается непосредственно перед упаковкой новой порции пересылаемых данных в буфер сообщения. Функция pvm_initsend освобождает буфер и создает новый для упаковки в него даных. Схема кодировки упаковываемых в буфер данных указывается заданием переменной encoding. Возвращаемое в переменную bufid значение является идентификатором буфера.

Переменная encoding может принимать следующие значения:

- PvmDataDefault XDR кодировка, используемая в PVM по умолчанию. Эта кодировка используется обычно в гетерогенных кластерах, когда PVM не может знать понимает ли принимающая сторона передаваемый формат данных. Например, когда данные передаются с Linux-машины на Windows-машину. В случае, когда в кластере используется только один тип операционной машины или когда пользователь уверен, что принимающая сторона поймет все правильно, следует использовать тип кодировки PvmDataRaw.

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

- PvmDataInPlace данные остаются на месте, не перемещаясь в буфер посылки. Этот тип кодировки можно использовать для снижения накладных расходов, связанных с перемещением данных в буфер. В этом случае буфер содержит только длины и указатели на передаваемые данные. Когда вызвана pvm_send(), данные копируются непосредственно с того места, где они асположены. Использование этой кодировки накладывает одно ограничение. Передаваемые данные не должны быть изменены между моментом, когда началась их упаковка и моментом окончания передачи буфера сообщения адресату. Однако, при использовании данного типа упаковки, имеется одно заметное преимущество. Функция упаковки pvm_initsend может быть вызвана только один раз в начале прогарммы. Например в начале работы программы мы можем упаковать данные из области перекрытия (см. главу "Декомпозиция данных") и передавать их множество раз по мере необходимости.

Упаковка данных. Для FORTRANа существует только одна функция, которая управляет упаковкой данных всех типов:

call pvmfpack( what, xp, nitem, stride, info )

В параметре what указывается тип упаковываемых данных. Параметр xp является первым элементом массива данных. Пареметры nitem и stride описаны выше. Параметр info - возвращаемое значение. Значения параметра what представлены в таблице 2.3:

Таблица 3.3 - Значение параметра what

Константы, соответствующие значениям параметра what определены в файле pvm3/include/fpvm3.h. Некоторые производители могут расширять этот список дополнительными данными, например INTEGER8, REAL16 и др.

Пример использования всех этих функций:

CALL PVMFINITSEND(PVMRAW, INFO)

CALL PVMFPACK( INTEGER4, NSIZE, 1, 1, INFO )

CALL PVMFPACK( STRING, `row 5 of NXN matrix', 19, 1, INFO )

CALL PVMFPACK( REAL8, A(5,1), NSIZE, NSIZE , INFO )

CALL PVMFSEND( TID, MSGTAG, INFO )

Прием и посылка данных

call pvmfsend( tid, msgtag, info )

call pvmfmcast( ntask, tids, msgtag, info )

Функция pvm_send() помечает сообщение тагом msgtag и выполняет немедленную пересылку данных процессу с соответствющим идентификатором tid.

Функция pvm_mcast() помечает сообщение тагом msgtag и выполняет немедленную пересылку данных все процессам, имеющим идентификаторы, совпадающими со значениями, хранящимися в массиве tids. Длина массива tids равна ntask.

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

call pvmfpsend( tid, msgtag, xp, cnt, type, info )

Эти функции упаковывают массив определенного параметром type типа в буфер и передают его процессу, идентифицированному параметром tid. В FORTRANе типы данных определены так же, как и для процедуры pvmfpack().

Система PVM содержит несколько методов для организации приема сообщений. Причем отсутствует соотыктствие функций. То есть нет такого ограничения, когда сообщение, посланное процедурой pvm_psend должно быть обязательно принято процедурой с именем тип pvm_precv. Вне зависимости от того, как было послано сообщение, принято оно может быть либым из возможных вариантов. То же замечание касается адресной и мультикастной (multicast) передачи.

Следующие процедуры осуществляют блокирующий прием сообщений:

call pvmfrecv( tid, msgtag, bufid )

Эти процедуры инициируют процесс ожидания поступления сообщения, помеченного тагом msgtag от процеса с идентификатором tid (если сообщение еще не пришло). В случае, когда значения параметров tid и/или msgtag равны -1, осуществляется ожидание сообщения от любого процесса и/или сообщения с любым тагом.

После того, как сообщение получено, эти процедуры возвращают управление вызвавшей их программе, передав в bufid идентификатор буфера, в который помещено полученное сообщение. Значение bufid<0 сигнализирует о возникшей ошибке.

Аналогом блокирующей функции являются функция

call pvmfnrecv( tid, msgtag, bufid )

Параметры и возвращаемое значение этой функции аналогичны используемым в блокирующей функции. Отличие заключается в том, что вызов pvm_nrecv не инициирует процесс ожидания сообщения. В случае, если ожидаемое сообщение еще не поступило, в bufid возвращается 0. Функция pvm_nrecv может быть вызвана в процессе счета неоднократно.

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

call pvmfprobe( tid, msgtag, bufid )

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

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

call pvmfprecv( tid, msgtag, xp, cnt, type, rtid, rtag, rcnt, info )

Эту функцию можно использовать для приема сообщений, в которых содержатся однотипные данные. Вызов этой функции инициирует процесс ожидания сообщения, помеченного тагом msgtag от процесса с идентификатором tid. По поступлении сообщения pvm_precv распаковывает данные общим объемом len * (size of data type) в буфер buf.

Типы данных в FORTRAN-программах такие же, как это дано в описании функции pvmfpack.

Описание параметров функций:

- tid ID процесса откуда мы ждем сообщение. "-1" означает "любой процесс".

- msgtag Ожидаемый таг сообщения. "-1" означает "любое сообщение".

- vp Указатель на массив (переменную) куда будут помещены полученные данные.

- xp Массив (переменная) куда будут помещены полученные данные. (FORTRAN)

- cnt Количество ожидаемых элементов указанного типа.

- type Тип получаемых данных (см. выше).

- rtid Возвращаемый параметр. ID процесса, откуда пришло сообщение.

- rtag Возвращаемый параметр. Таг (метка) полученного сообщения.

- rcnt Возвращаемый параметр. Длина полученного сообщения (кол-во элементов).

- info Содержит на выходе PvmOk если все нормально и отрицательное значение в случае ошибки.

Распаковка полученных данных

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

call pvmfunpack( what, xp, nitem, stride, info )

Параметр xp - массив, куда будут помещены распакованные данные.

Параметры nitem и stride имеют тот же смысл, что и в соответствующих функциях упаковки (см. выше).

Параметр what был так же описан выше.

Отладка.

По умолчанию только текст, выводимый родительской задачей (то есть той, которую вы сами запустили с терминала) окажется на экране. Стандартный вывод задач, запускаемых функцией pvm_spawn(), по умолчанию перенаправляется в LOG-файл исполняющей системы PVM ($PVM_TMP/pvml.*). Функция

call pvmfcatchout( onoff, info )

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

call pvmfcatchout (1, info);

call pvmfspawn (…

в родительской задаче весь вывод от всех запускаемых подзадач перенаправит на экран. При этом PVM гарантирует, что строки от разных задач не будут "налезать" одна на другую, и каждая строка будет предваряться идентификатором той задачи, которая ее вывела. Использование pvm_catchout() имеет два недостатка: а) между посылкой строки в файл или на экран из под-задачи и ее фактическим там появлением может быть задержка неизвестной заранее длительности, и, б) если объем выводимой диагностики от разных задач очень велик, очень трудно разобраться в поведении какой-то одной конкретной задачи.

3.3.2.4 Установка и администрирования PVM

Для установки PVM в системе необходимо создать каталог, где будет располагаться система PVM. Будем считать, что установка PVM в каталог /pvm3. В этот каталог необходимо распаковать архив с исходниками системы:

tar zxvf pvm3.3.4.tgz

Перед сборкой и запуском PVM необходимо установить переменную окружения $PVM_ROOT, указав в ней полный путь к каталогу, в котором хранится система. Если используется в качестве командной оболочки csh, необходимо добавить следующую строку в файл .cshrc:

setenv PVM_ROOT=/pvm3

Если же используете оболочки, которые используют .profile, например sh или ksh, или bash, которая использует .bashrc, тогда нужно добавить в соответствующий файл такую команду:

export PVM_ROOT=/pvm3

Так же необходимо определить другие переменные окружения, необходимые для функционирования PVM, добавив после команды определения PVM_ROOT содержимое соответствующих командной оболочке файлов: pvm3/lib/cshrc.stub, pvm3/lib/kshrc.stub или pvm3/lib/bashrc.stub.

По умолчанию PVM использует протокол rsh для общения с другими компьютерами кластера. Далее нужно заменить rsh на ssh, изменив файл /pvm3/conf/LINUX.def, прописав в переменной ARCHCFLAGS параметр RSHCOMMAND, определив для него полный путь к команде ssh (например /usr/bin/ssh). На кластере файл /pvm3/conf/LINUX.def выглядит так:

#

ARCHCFLAGS = -DSYSVSIGNAL -DNOWAIT3 -DRSHCOMMAND=\"/usr/bin/ssh\" \

-DNEEDENDIAN -DFDSETNOTSTRUCT -DHASERRORVARS \

-DCTIMEISTIMET -DSYSERRISCONST -DNOTMPNAM

ARCHDLIB =

ARCHDOBJ =

ARCHLIB =

HASRANLIB = t

AR = ar

PVM_ARCH = LINUX

MAKE = make

Для сборки и установки PVM, находясь в каталге /pvm3, необходимо выполнить команду make. По окончании ее работы система PVM готова к запуску. Следует отметить, что для уменьшения проблем, связанных с настройкой PVM на узлах кластера, на всех машинах кластера PVM следует устанавливать в один и тот же каталог.

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

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

В задачи системного администратора кластера, нужно либо разрешить каждому заинтересованному пользователю подключаться к кластеру под своим собственным login'ом, и запускать свою собственную параллельную виртуальную машину, либо определить в системе выделенного пользователя, под аккаунтом которого пользователи кластера могут подключаться к кластеру и выполнять под управлением одной единственной PVM свои задачи. Следует понимать, что одновременное присутствие в кластере нескольких параллельных виртуальных машин пропорционально снижает эффективное быстродействие каждой их них. Исключение составляет случай, когда эти параллельные виртуальные машины физически состоят из непересекающихся наборов узлов кластера.

Для кластера кафедры АИС необходимо выделить пользователя Admin_cluster, и под его аккаунтом можно запустить PVM на серверном компьютере.

Для запуска виртуальной машины необходимо выполнить команду pvm. Эта команда запускает консоль параллельной виртуальной машины PVM. Команда pvm перед запуском консоли проверяет наличие в системе демона pvmd, запущенного от имени пользователя, который выполняет команду pvm, и в случае отсутствия такового запускает его. Таким образом в системе может присутствовать несколько демонов pvmd (несколько параллельных виртуальных машин), принадлежащих разным пользователям. С другой стороны два пользователя, подключившихся к консоли кластера под одним именем, будут пользоваться одной и той же виртуальной машиной. Доступ пользователей к консоли под разными именами обеспечит безопасность для выполняемых программ. Поскольку запускаемые программы будут выполнятся под разными виртуальными машинами, то пользователи не смогут помешать друг другу, например снять с исполнения чужую задачу. С другой стороны, работа всех пользователей под одним login'ом обеспечит простоту администрирования запускаемых задач. В этом случае пользователь может быть лишен необходимости самостоятельно конфигурировать состав кластера. Однако это добавит риск неправомочного воздействия пользователем на чужие задачи. Пользователь может, например, остановить виртуальную машину командой halt, сняв тем самым с исполнения все запущенные в рамках этой виртуальной машины задачи. Каким образом обеспечить пользователям доступ к консоли кластера вы должны решить самостоятельно.

Запустив команду pvm, пользователь попадает в командную строку виртуальной машины. Список допустимых в PVM команд можно получить, выполнив команду help. Далее рассмотрены только те команды, которые будут постоянно необходимы для выполнения задач на параллельном компьютере под управлением PVM.

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

pvm>add node1

pvm>add 192.168.1.3

pvm>add node3.cluster.mydomain.org

Параметром этой команды может быть ip-адрес, краткое или полное доменное имя включаемого узла. При подключении дополнительного узла, виртуальная машина связывается с подключаемым компьютером по протоколу SSH для выполнения действий связанных с запуском демона pvmd на этом компьютере. Поэтому следует синхронизировать список пользователей на узлах кластера со списком пользователей консоли кластера. Если не предпринимать никаких действий, направленных на обеспечение беспарольного доступа по протоколу SSH на узла кластера с консоли кластера, то при добавлении каждого нового узла в виртуальную машину, система будет запрашивать пароль доступа. При отсутствии проблем, подключение нового узла выглядит на консоли так:

pvm>add node1

add node1

yuri@node1's password:

1 successful

HOST DTID

node1 80000

pvm>

Посмотреть список подключенных к виртуальной машине узлов можно выдав команду conf:

pvm> conf

conf

2 hosts, 1 data format

HOST DTID ARCH SPEED DSIG

server 40000 LINUX 1000 0x00408841

node1 80000 LINUX 1000 0x00408841

pvm>

Для каждой машины списка дана информация, включающая в себя имя машины (короткое или полное доменное имя, или ip-адрес) HOST, идентификатор задачи DTID демона PVM, название архитектуры подключаемой машины ARCH, некое число SPEED, отражающее скоростные характеристики машины и идентификатор самой виртуальной машины DSIG, который будет различен для виртуальных машин, запущенных разными пользователями.

Вместо того, чтобы вручную добавлять каждый узел кластера в виртуальную машину, можно при первом запуске pvm указать в качестве первого параметра команды имя текстового файла, в котором перечислены имена (краткие или полные доменные) или ip-адреса узлов кластера. Правило составления такого файла простое: один узел одна строка. В случае использования списка узлов, PVM самостоятельно выполнит подключение перечисленных в файле машин. Вероятно, правильным и удобным будет обеспечить беспарольный доступ по протоколу SSH к узлам кластера с консоли кластера и выполнение команды "pvm hostlist" из startup-файла пользователя (например .bashrc).

Следующее действие, которым систематически будет заниматься пользователь, находясь в виртуальной машине, это запуск параллельных задач. Запуск осуществляется командой spawn. В качестве параметра этой команды указывается название исполняемого файла, который следует запустить внутри виртуальной машины. Файл с таким названием ищется в каталоге /pvm3/bin/LINUX/.

pvm> spawn timing

spawn timing

1 successful

t40002

pvm>

В приведенном примере выполняется запуск программы "timing". В этом варианте программа запускается в фоновом режиме и весь вывод в STDOUT будет записываться в log-файл. Команду запуска можно модифицировать с тем, чтобы вывод в STDOUT от всех процессов задачи направлялся на консоль виртуальной машины. Для этого команда запуска и вывод программы на экране будут выглядеть так:

pvm>spawn -> hello

spawn -> hello

[1]

1 successful

t40004

[1:t40005] Message from slave process

[1:t40004] i'm t40004

[1:t40004] from t40005: hello, world from yis

[1:t40005] EOF

[1:t40004] EOF

[1] finished

pvm>

Для просмотра списка запущенных задач можно воспользоваться командой ps. Запуск с консоли этой команды без параметров покажет список процессов задач, которые запущены на консоли кластера. Используя параметр "-a", мы можем посмотреть, какие процессы запущены на всех узлах виртуальной машины. Пример:

pvm> ps -a

ps -a

HOST TID FLAG 0x COMMAND

server 40002 6/c,f timing

node1 80002 6/c,f timing_slave

pvm>

В примере мы видим, что запущенная нами задача timing осталась работать на консоли кластера "server" и породила на узле "node1" дочерний процесс timing_slave.

Для снятия процесса со счета можно воспользоваться командой kill, параметрами которой являются идентификаторы задач (TID) процессов, которые подлежат удалению из системы. Идентификаторы задач можно посмотреть с помощью ранее описанной команды ps. Так, для удаления из системы процессов "timing" и "timing_slave" из предыдущего примера, команда ps будет выглядеть следующим образом:

pvm> kill 40002 80002

Для удаления всех задач следует воспользоваться командой reset.

pvm> reset

Часто бывает, что не вся пользовательская работа должна проводится внутри виртуальной машины. Некоторые программы могут запускаться на локальной машине как обычные задачи. Например, визуализацию данных, получаемых в результате счета параллельной программы, можно осуществлять отдельной программой, которая может быть активна не все то время, когда идет счет, запускаться периодически. Такая программа может получать данные для визуализации через специальные файлы FIFO, известные так же как "именованные каналы". О такой методике мы поговорим ниже. В подобных случаях возникает необходимость завершить работу консоль виртуальной машины и выйти в обычную командную строку локальной операционной системы. Выход в операционную систему без остановки виртуальной машины и всех ее процессов осуществляется командой quit.

pvm> quit

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

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

pvm> halt

Результатом выполнения этой команды является, во-первых, "убивание" всех процессов виртуальной машины на всех присоединенных к ней узлах кластера (в том числе и на консоли кластера), во-вторых, остановка системы PVM на всех узлах кластера (отсоединение узлов), и, в заключение, остановка системы PVM на консоли кластера с выходом к командную строку локальной операционной системы.

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

3.4 Программное обеспечение для администрирование кластера кафедры АИС