47965 (588510), страница 4
Текст из файла (страница 4)
Если говорить, к примеру, о 100Мбит сети, то задачей комутатора является обеспечение пропускной способности 100 Мбит/с одновременно для всех n/2 соединений между парами портов n-портового коммутатора. Теоретически коммутатор должен это гарантировать, но на практике производители оборудования весьма часто идут на упрощение электронной начинки своей продукции, как с целью удешевления, так и с целью максимального увеличения числа портов. В последнем случае при распараллеливании могут возникать конфликты на уровне Fast Ethernet, что снижает скорость обмена сообщениями и соответственно эффективность распараллеливания.
По моему личному опыту таблица приоритетов при выборе сетевого коммуникатора для построения сети кластера может выглядеть так: Cisco Catalist, 3Com SuperStack 3, Compex Switch. Ну и на последнем месте стоят самые дешевые хабы различных производителей, таких как Compex или 3Com.
Конечно, принимая решение о выборе коммутатора, необходимо учесть и другие их характеристики, в том числе цену. Хорошая продукция и стоит дороже. Так, отличные коммутаторы Cisco Catalyst (например, известная модель 5000, имеющая большее число портов и поддерживающая возможность связывания каналов) имеют более высокую цену, чем оборудование не столь "именитых" фирм.
Не все коммутаторы могут обеспечить возможность применения связанных каналов. Если вы предполагаете использовать channel bonding для увеличения пропускной способности вашей сети, то необходимо с особой тщательностью подходить к выбору коммутатроа. Обычные хабы в этом случае отпадают сразу. Проблема в связывании каналов заключается в том, что пр наличии channel bonding у вас появляется две или несколько сетевых карт с одинаоквым MAC-адресом. В обычном режиме работы коммутатор либо просто "сойдет с ума", либо будет интенсивно перестраивать свои внутренние таблицы портов, переназначая ваш MAC-адрес с одного порта на другой. Это может привести либо к полной неработоспособности канала, либо к значительным потерям пакетов и существенному снижению производительности сети. Для обеспечения нормальной работы таких связанных каналов в коммутаторе должны быть предусмотрены функции Link Aggrigation или, по другому, работа в стандарте IEEE 802.3ad. При покупке коммутатора внимательно читайте прилагаемые спецификаци и ищите эти магические словосочетания. Не все коммутаторы, имеющие функцию Link Aggrigation, позволяют применять ее для всех портов. Например, существуют модели, которые имеют 12/24 100Мбит и два гигабитных порта. В таких моделях Link Aggrigation можно настроить только для гигабитных портов, используя их для связи между двумя коммутаторами. Ясно, что такие модели не применимы для наших целей. Поэтому консультации со специалистами при покупке коммутатора обязательны.
В качестве примеров коммутатором, позволяющих настроить Link Aggrigation, можно упомянуть Cisco Catalist 2900 series, Cisco Catalist 3500 series, Cisco Catalist 5000 series, 3Com SuperStack 3 4950, 4400 и др. Следует отметить, что наличие или отсутствие функций Link Aggrigation зависит не только от модели коммутатора, но и от версии его программного обеспечения.
1.6 Параллельная виртуальная машина(PVM)
Основой вычислительной среды кластера Beowulf является параллельная вирутальная машина PVM. PVM (Параллельная Виртуальная Машина) - это пакет программ, который позволяет использовать связанный в локальную сеть набор разнородных компьютеров, работающих под операционной системой Unix, как один большой параллельный компьютер. Таким образом, проблема больших вычислений может быть весьма эффективно решена за счет использования совокупной мощности и памяти большого числа компьютеров. Пакет программ PVM легко переносится на любую платформу. Исходные тексты, свободно распространяемые netlib, был скомпилирован на компьютерах начиная от laptop и до CRAY.
Параллельную виртуальную машину можно определить как часть средств реального вычислительного комплекса (процессоры, память, периферийные устройства и т.д.), предназначенную для выполнения множества задач, участвующих в получении общего результата вычислений. В общем случае число задач может превосходить число процессоров, включенных в PVM. Кроме того, в состав PVM можно включать довольно разнородные вычислительные машины, несовместимые по системам команд и форматам данных. Иначе говоря, Параллельной Виртуальной Машиной может стать как отдельно взятый ПК, так и локальная сеть, включающая в себя суперкомпьютеры с параллельной архитектурой, универсальные ЭВМ, графические рабочие станции и все те же маломощные ПК. Важно лишь, чтобы о включаемых в PVM вычислительных средствах имелась информация в используемом программном обеспечении PVM. Благодаря этому программному обеспечению пользователь может считать, что он общается с одной вычислительной машиной, в которой возможно параллельное выполнение множества задач.
PVM позволяет пользователям использовать существующие аппаратные средства, для решения намного более сложных задач при минимальной дополнительной стоимости. Сотни исследовательских групп во всем мире используют PVM, чтобы решить важные научные, технические, и медицинские проблемы, а так же используют PVM как образовательный инструмент, для преподавания параллельного программирования. В настоящее время, PVM стал де факто стандартом для распределенных вычислений.
Главная цель использования PVM - это повышение скорости вычислений за счет их параллельного выполнения. Функционирование PVM основано на механизмах обмена информацией между задачами, выполняемыми в ее среде. В этом отношении наиболее удобно реализовывать PVM в рамках многопроцессорного вычислительного комплекса, выделив виртуальной машине несколько процессоров и общее или индивидуальные (в зависимости от условий) ОЗУ. Использование PVM доспустимо как на многопроцессорных компьютерах (SMP) так и на вычислительных комплексах, построенных по кластерной технологии. При использовании PVM, как правило, значительно упрощаются проблемы быстрого информационного обмена между задачами, а также проблемы согласования форматов представления данных между задачами, выполняемыми на разных процессорах
Эффективное программирование для PVM начинается с того, что алгоритм вычислений следует адаптировать к составу PVM и к ее характеристикам. Это очень творческая задача, которая во многих случаях должна решаться программистом. Кроме задачи распараллеливания вычислений с необходимостью возникает и задача управления вычислительным процессом, координации действий задач - участников этого процесса. Иногда для управления приходится создавать специальную задачу, которая сама не участвуя в вычислениях, обеспечивает согласованную работу остальных задач - вычислителей.
Ранее вскользь упоминалось, что при параллельных вычислениях необходимо программировать специальные действия по координации работы задач, такие как процессы запуска задач на процессорах кластера, управление обменом данных между задачами и пр. Также следует четко определить "область деятельности" для каждой задачи.
Наиболее простой и популярный способ организации параллельного счета выглядит следующим образом. Сначала запускается одна задача (master), которая в коллективе задач будет играть функции координатора работ. Эта задача производит некоторые подготовительные действия, например инициализация начальных условий, после чего запускает остальные задачи (slaves), которым может соответствовать либо тот же исполняемый файл, либо разные исполняемые файлы. Такой вариант организации параллельных вычислений предпочтительнее при усложнении логики управления вычислительным процессом, а также когда алгоритмы, реализованные в разных задачах, существенно различаются или имеется большой объем операций (например, ввода - вывода), которые обслуживают вычислительный процесс в целом.
1.6.1 Взаимодействие задач в PVM
В системе PVM каждая задача, запущенная на некотором процессоре, идентифицируется целым числом, которое называется идентификатором задачи (TID) и по смыслу похоже на идентификатор процесса в операционной системе Unix. Система PVM автоматически поддерживает уникальность таких идентификаторов: копии одного исполняемого файла, запущенные параллельно на N процессорах PVM, создают N задач с разными TID.
По стандарту принятому в PVM для взаимодействия задач считается, что в пределах одной PVM любая задача может передавать сообщения любой другой задаче, причем, размеры и число таких сообщений в принципе не ограничены. Это предположение существенно упрощает реализацию PVM на конкретных вычислительных комплексах, т.к. при этом контроль переполнения буферных устройств и массивов остается в ведении операционных систем и с программиста снимается одна лишняя забота.
Для повышения эффективности межзадачного обмена информацией предусмотрено использование нескольких алгоритмов. В частности, можно использовать алгоритм блокированной передачи, при котором функция "Послать сообщение" возвращает значение (т.е. завершает работу) только после того как получена положительная или отрицательная квитанция от получателя сообщения. Такой алгоритм передачи с ожиданием уведомления о доставке предпочтителен в тех случаях, когда длинное сообщение передается несколькими порциями, а также при обмене командами, последовательность выполнения которых во времени дорлжна быть строго фиксированной.
При использовании неблокированных алгоритмов передачи и приема сообщений уменьшаются простои процессоров, вызванные ожиданием реакции "собеседника". Особенно большой эффект это дает на приемной стороне при неизвестном времени прихода сообщения. Можно организовать работу приемного процессора так, чтобы он в ожидании сообщения выполнял текущую работу, лишь время от времени опрашивая приемный буфер.
Существенным является то обстоятельство, что при передаче последовательности сообщение от одной задачи к другой порядок приема сообщение всегда совпадает с порядком их передачи. Более того, если до обращения к функции "принять сообщение" в приемный буфер принимающей задачи записано несколько сообщений, то функция "принять сообщение" возвратит ссылку на первое принятое сообщение.
Память для буферных массивов на передающей и приемной стороне выделяется динамически, следовательно, максимальный объем сообщений ограничивается только объемом доступной памяти. Если одна из задач, запущенных в PVM, не может получить требуемую память для общения с другими задачами, то она выдает пользователю соответствующее сообщение об ошибке ("cannot get memory"), но другие задачи об этом событии не извещаются и могут, например, продолжать посылать ей сообщения.
1.6.2 Управление задачами
Управление задачами в 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 а также последовательность идентификаторов для запущенных задач. Причем, если numt Второй вариант написания параллельной задачи заключается в том, что для каждого процессора пишутся свои собственные задачи, выполняющие различные действия, и создается маленькая программа, которая, используя функцию pvm_spawn запускает все остальные задачи.
Исполняемый файл для функции pvm_spawn() должен находиться в строго определенном каталоге. Под Unix задача ищется в каталогах $PVM_ROOT/bin/$PVM_ARCH/ и $HOME/pvm3/bin/$PVM_ARCH. Задавать имя каталога в параметре "task" недопустимо.
Но это не единственный способ. В другом варианте исполняемый файл ищется (и запускается) не только на том компьютере, на котором работает вызвавшая pvm_spawn() задача, но в зависимости от параметров flag и where, на любом входящем в состав PVM. Например, если flag==0, то PVM сам выбирает, на какой из машин запускать новые задачи (главное, чтобы приложение было скомпилировано на этих машинах); а если flag & PvmMppFront > 0, то местом запуска будет выбран самый быстрый компьютер.
Значением параметра flag задается набор опций для запускаемых задач. Каждой опции сответствует целое неотрицательное число, и значение flag равно сумме выбранных опций. Ниже перечисляются опции запуска задач.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
