1.4 ОПЕРАЦИОНАЯ СИСТЕМА
При выборе операционной системы следует основываться прежде всего на рекомендациях разработчиков программного обеспечения. Однако, если есть выбор, то при прочих равных условиях следует отдать предпочтение Linux.
Под Linux доступно огромное количество серверного ПО, компиляторов, библиотек, средств отладки и пр. Большое количество программного обеспечения имеется в свободном доступе, для многих программ есть исходные коды и обширная документация.
Плюсом Linux является "прозрачность" для пользователя и системного администратора, что позволяет быстрее и проще разрешать все возникающие проблемы.
Однако зацикливаться на выборе операционной системы не надо. Поскольку вы являетесь не системным администратором, а научным работником, операционная система для вас значит не больше, чем офис для бизнесмена. Основными вашими инструментами являются карандаш, бумага и транслятор с вашего любимого языка программирования. Кластерный суперкомпьютер есть не цель, но всего лишь средство для усовершенствования и оптимизации вашей основной работы.
Основой кластера является не операционная система, а коммуникационная среда (PVM, MPI), обеспечивающая возможность частям параллельной программы, выполняющимся на разных компьютерах, эффективно взаимодействовать между собой.
Рассмотренные ранее средства для построения кластера (PVM, MPI) имеют реализации как для операционных систем семейства UNIX (Linux, FreeBSD и т.п.), так и для систем фирмы Майкрософт. Поэтому, если вы испытываете непреодолимые трудности в отказе от Windows, то расстраиваться по этому поводу не надо. Кластер можно поднять и под Windows, причем трудозатраты на установку коммуникационной среды будут такими же как и в варианте с UNIX, то есть небольшими. Основная ваша трудность будет заключаться в том, чтобы научиться писать параллельные программы.
Однако, следует заметить, что подавляющее большинство более-меннее серьезных кластеров в мире работает все же в среде UNIX. Разбор преимуществ и недостатков того или иного семейства операционных систем выходит за рамки рассматриваемой нами темы. Поэтому я предлагаю просто поверить мне на слово, что лучшим выбором для вас будет Unix (Linux в частности).
Хочется отметить одни немаловажный аспект, проявляющийся при попытке перенести свою работу из Windows в Linux. Имеются в виду психологический и административный факторы. Человек, приходящий в мир Linux, испытывает чувство растерянности и неуверенности в том, что он сможет найти в новой системе привычные для него инструменты. Это, как если бы, человек с детства говорящий только на русском языке, выехал за границу. Кроме того, если вы примите решение о строительстве кластера на базе имеющегося у вас компьютерного класса, который используется в обучении студентов, вам неизбежно придется в той или иной степени менять учебный процесс.
Что касается психологии, то давно прошли те времена, когда работа в UNIX была уделом компьютерных гуру, разговаривающих на непонятном языке и пишущих программы в машинных кодах. Современный уровень развития Linux позволяет чувствовать себя пользователю не менее комфортно, чем в Windows. Более подробно об этом можно прочитать в этой статье. Статья посвящена несколько другой теме, но представление о том, что вас ждет в мире Linux, вы получить сможете.
В настоящее время основной операционной системой, используемой при проведении учебных занятий в вузах, является операционная система Windows. При всех достоинствах системы ей присущи некоторые недостатки, существенно затрудняющие ее использование. К таким недостаткам можно отнести:
малую защищенность системы от неквалифицированных действий пользователей (студентов);
подверженность системы различного рода "взломам" при сетевом использовании и подверженность вирусам;
неустойчивость работы системы, проявляющаяся в зависаниях и потере информации;
большая стоимость лицензий на использование систем;
закрытость операционной системы, затрудняющая написание учебных программ в ее среде и обучение;
большие требования к возможностям компьютера (память, быстродействие);
частая смена версий ОС (примерно каждые два года).
По поводу ломки учебных планов можно сказать следующее. Решение построить кластер на базе вычислительных мощностей имеющегося в наличии компьютерного класса может быть принято скорее всего на физических или математических факультетах ВУЗов. Целью обучения студентов на этих факультетах не ставится подготовка квалифицированных секретарей-референтов со знанием компьютера. Все же остальные цели компьютерной практики вполне могут быть достигнуты и при использовании операционной системы Linux. Жесткая ориентация на продукты фирмы Майкрософт в действительности не обоснована нуждами учебного процесса. Кроме того, ОС Linux вполне может сосуществовать с Windows на одном и том же компьютере и загружаться только по мере необходимости. Другое дело, что проблемой может встать наличие лаборантов, имеющих достаточный уровень квалификации в Linux.
Использование Linux в качестве базовой операционной системы в учебных классах кроме возможности построения кластера из имеющихся в классе компьютерах позволит:
более эффективно использовать имеющиеся вычислительные средства
снизить затраты на обслуживание всей системы (благодаря возможностям к гибкой настройки и четкого отслеживания прав доступа различных пользователей) решить проблемы с необходимостью приобретения лицензий на используемое ПО сделать работу компьютеров в сети и работу всего класса более надежной и устойчивой
1.5 ОРГАНИЗАЦИЯ КЛАСТЕРНОЙ СЕТИ
Сеть - это модульная и адаптируемая коммутационная система, которую можно настроить в соответствии с самыми различными требованиями. Ее модульность облегчает добавление новых компонентов или перемещение существующих, а адаптивность упрощает внесение изменений и усовершенствований. Сеть кластера Beowulf ничем принципиально не отличается от сети рабочих станций, поэтому в самом простом случае для построения кластера необходимы обычные сетевые карты и хабы/коммутаторы, какие использовались бы при обустройстве какого-нибудь компьютерного класса. Однако, в случае кластера имеется одна особенность. Сеть кластера в первую очередь предназначена не для связи машин, а для связи вычислительных процессов. Поэтому чем выше будет пропускная способность вашей сети, тем быстрее будут считаться параллельные задачи, запущенные на кластере, следовательно рабочие характеристики сети приобретают первостепенное значение.
Для построения вычислительных кластеров используют самое разнообразное сетевое оборудование. При этом, так как характеристики стандартных сетевых устройств заметно уступают характеристикам специализированных коммуникаций в "нормальных" MPP компьютерах, пропускная способность сети, связывающей узлы кластера, во многих случаях оказывается решающей для производительности кластера. Используемое сетевое оборудование характеризуют обычно двумя параметрами:
-Пропускная способность это скорость передачи данных между двумя узлами после того, как связь установлена. Производитель обычно заявляет пиковую пропускную способность, которая в 1.5-2 раза выше реально наблюдаемой в приложениях.
-Латентность это среднее время между вызовом функции передачи данных и самой передачей. Время затрачивается на адресацию информации, срабатывание промежуточных сетевых устройств, прочие накладные расходы, возникающие при передаче данных.
Приведем для сравнения параметры некоторых наиболее популярных сетевых устройств.
Сетевое оборудование Пиковая пропускная способность Латентность
1. FastEthernet 12.5 Mbyte/sec 150 sec
2. GigabitEthernet 125 Mbyte/sec 150 sec
3. Myrinet 160 Mbyte/sec 5 sec
4. SCI 400 Mbyte/sec (реально 100) 2.3 sec
5. cLAN 150 Mbyte/sec 30 sec
Фактически пропускная способность и латентность не только характеризуют кластер, но и ограничивают класс задач, которые могут эффективно решаться на нем. Так, если задача требует частой передачи данных, кластер, использующий сетевое оборудование с большой латентностью (например GigabitEthernet), будет большую часть времени тратить даже не на передачу данных между процессами, а на установление связи, в то время как узлы будут простаивать, и мы не получим значительного увеличения производительности. Впрочем, если пересылаются большие объемы данных, влияние периода латентности на эффективность кластера может снижаться за счет того, что сама передача потребует достаточно большого времени, может быть даже в разы больше периода латентности.
Для малобюджетных кластеров использование супербыстрых Myrinet, SCI, cLAN скорее всего может оказаться нереальным с финансовой точки зрения. Поэтому рассмотрим более дешевые решения. Использование для кластера 10Mbit-сети хотя и возможно, но малоприятно. В результате вы рискуете получить от использования кластера больше разочарований, чем реального увеличения эффективности вашей работы. Далее мы будем рассматривать оборудование для сетей от 100Mbit и выше.
Сетевые карты. В качестве сетевых адаптеров можно использовать любые имеющиеся в продаже карты, поддерживающие работу в стандартах 100BaseTx и GigabitEthernet. Что касается списка предпочтений, то можно порекомендовать в первую очередь 3Com. Среди других вариантов можно назвать Compex, Intel, Macronix, другие карты, поддерживаемые драйвером tulip, например карты на чипсетах DC21xxx. Особенно популярными при построении кластеров явяляются платы на базе микросхем Intel 21142/21143. Популярность этих карт вызвана бытующим мнением об их высокой производительности, в то время как их цена по сравнению с конкурирующими предложениями обычно довольно невелика. Что касается сетевых карт фирмы 3Com, то они имеют некоторые преимущества, заметно влияющие на производительность сетевых коммуникаций. Приведем лишь несколько примеров возможностей аппаратного обеспечения карт 3Com.
Разгрузка процессора при вычислении контрольных сумм TCP/UDP/IP. Освобождает центральный процессор от интенсивных вычислений контрольных сумм, выполняя их в самой сетевой плате. Тем самым повышается производительность системы и время жизни процессора.
Освобождение ЦП при восстановлении сегментированных пакетов TCP. Снижает нагрузку на центральный процессор, повышая производительность системы.
Объединение прерываний. Позволяет группировать несколько полученных пакетов. Оптимизирует вычислительную эффективность хост-компьютера, сокращая число прерываний и максимально освобождая процессорные ресурсы для работы приложений.
Режим Bus mastering DMA. Обеспечивает более эффективный обмен данными для снижения загрузки центрального процессора.
В любом случае, если вы не предполагаете использовать технологию связывания каналов (channel bonding), которая позволяет объединять несколько сетевых адаптеров в один скоростной виртуальный канал, то вы можете себя чувствовать достаточно свободно выбирая для покупки ту или иную карту. Практически все современные сетевые карты, имеющиеся сейчас в продаже, без проблем распознаются Linux'ом и нормально работают.
Для организации связанного канала (channel bonding) лучше всего выбрать сетевые карты Intel EtherExpress PRO/100, 3Com FastEthernet (например 3c905B, 3c905C) или какие-либо карты GigabitEthernet от 3Com или Intel. Так же интересным вариантом являются специализированные серверные сетевые карты, в которых имеется более одного Ethernet-порта. Примерами таких адаптеров могут быть Intel EtherExpress PRO/1000 MF Dual Port или 3Com Fast EtherLink Server Dual Port 3c982C-TXM , которые я без труда нашел на http://www.price.ru. Использование таких карт позволит занимать в компьютере вдвое меньше PCI-слотов и, соответственно, устанавливать вдвое больше сетевых карт для объединения их в связанный канал.
Коммутаторы. Вторым важным элементом сети кластера являются устройства коммутации сетевых каналов. При выборе коммутирующих устройств так же следует учитывать возможность использования channel bonding. В зависимости от того, будет ли использоваться технология связывания каналов при построении кластера, можно остановить свой выбор на различном сетевом оборудовании.
Коммутаторы и другие элементы сетевой структуры используются для обеспечения коммуникаций между процессорами, для поддержки параллельного программирования и различных функций управления. Для параллельного программирования (организации межпроцессного взаимодействия (Inter Process Communication, IPC) широко используется коммутатор Myrinet-2000 компании Myricom (http://www.myri.com) - очень быстрое, хорошо масштабируемое широкополосное устройство. Считается, что при увеличении числа подключенных узлов общая ширина полосы пропускания - как у всех коммутаторов с настоящей масштабируемостью - растет пропорционально, а латентность остается постоянной. Иными словами, полоса на каждом из путей одинакова, а число путей (направлений) зависит от количества узлов, при этом каждый узел имеет связь со всеми остальными узлами независимо от размера кластера. Например, полоса в расчете на направление может составлять 200 Мбайт/с в каждом направлении с латентностью в 6-8 мкс. Коммуникации между пользовательскими пространствами могут реализовываться на основе протоколов IP или GM при помощи ПО пользовательского уровня Myricom.
Если среда параллельных вычислений не требует повышенной интенсивности коммуникаций между процессорами, то могут использоваться менее дорогостоящие средства, скажем, Ethernet. В индивидуальном заказном проекте могут также применяться технологии GigaNet, SCI или ServerNet, а в будущем и InfiniBand.
Выбор коммутатора осуществляется прежде всего на основе его характеристик. В самом простом случае для построения сети каластера можно использовать простые хабы. Это решение, наиболее выгодное по цене, явялется самым неудачным в технологическом смысле. При использовании хабов не происходит маршрутизации пакетов передаваемых данных. Любой пакет, переданный в сеть, направляется абсолютно всем участникам сети. Каждая машина "слышит" все передающиеся в сети пакеты данных, вне зависимости от того, предназначен ли конкретный пакет для нее или нет. При активном межпроцессорном обмене это может приводить к перегрузке сети, увеличении числа коллизий и, как следствие, к снижению эффективного быстродействия параллельной машины. Например, если две пары узлов кластера одновременно обмениваются данными посредством 100Мбит хаба, то скорость их обмена падает вдвое. Для решения этой проблемы следует использовать более "продвинутое" сетевое оборудование - коммутаторы, которые позволяют устанавливать своего рода каналы связи между парами машин.
Если говорить, к примеру, о 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 равно сумме выбранных опций. Ниже перечисляются опции запуска задач.
В FORTRANe flag может быть суммой следующих величин:
PVMDEFAULT=0 - PVM может выбрать любую машину для старта задачи
PVMHOST=1 - параметр where определяет машину для запуска
PVMARCH=2 - параметр where определяет тип архитектуры
PVMDEBUG=4 - процесс старует под отладчиком
PVMTRACE=8 - процесс генерирует PVM trace data.
Параметр where описывает на каких компьютерах кластера может быть запущена задача. Параметр является простой строковой переменной, в которую записано имя списка компьютеров. Списки компьютеров находятся в конфигурационных файлах системы PVM и формируются на этаме ее установки. Например в случае, когда в вашем кластере кроме консольной машины присутствует еще два компьютера: один класса P166 и другой класса P4, вы можете определить их в системе под именами "oldcomp" и "supercomp". И в зависимости от тех или иных условий, запускать свои задачи на какой-либо их этих машин кластера.
И, наконец, еще две функции, относящиеся к управлению задачами.
call pvmfkill( tid, info )
call pvmfexit( info )
Первая из них завершает выполнение задачи с идентификатором tid, возвращая при ошибке код ошибки info < 0. Отметим, что задача не может таким образом завершить свое выполнение. Вторая функция завершает работу PVM, запущенной пользователем, но при этом сама задача продолжает выполняться уже как обычная локальная задача и завершает работу обычным образом.
1.6.3 Передача сообщений
Посылка сообщений в PVM предназначена для передачи данных между различными процессам и состоит из трех шагов. Во-первых, буфер данных перед посылкой должен быть проинициализирован с использованием функций pvm_initsend() или pvm_mkbuf(). Во-вторых, пересылаемые данные должны быть "упакованы" в этот буфер. Для упаковки используется некоторе количество комбинаций вызовов функции pvm_pk*(). В FORTRANе упаковка данных производится подпрограмой pvmfpack(). Третий шаг заключается в пересылке данных адресатам. Для этой цели в зависимости от списка адресатов используется вызов функции 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 может быть вызвана только один раз в начале прогарммы. Например в начале работы программы мы можем упаковать данные из области перекрытия (см. главу "Декомпозиция данных") и передавать их множество раз по мере необходимости.
1.6.4 Упаковка данных
Для FORTRANа существует только одна функция, которая управялет упаковкой данных всех типов.
call pvmfpack( what, xp, nitem, stride, info )
В пареметре what указывается тип упаковываемых данных. Параметр xp является первым элементом массива данных. Пареметры nitem и stride описаны выше. Параметр info - возвращаемое значение. Значения параметра what представлены в следующей таблице:
STRING 0 REAL4 4
BYTE1 1 COMPLEX8 5
INTEGER2 2 REAL8 6
INTEGER4 3 COMPLEX16 7
Константы, соответствующие значениям параметра 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 если все нормально и отрицательное значение в случае ошибки.
1.6.5 Распаковка полученных данных
Функции распаковки данных, записанных в приемном буфере, применяются в той же последовательности, в какой применялись функции упаковки данных в посылаемое сообщение.
call pvmfunpack( what, xp, nitem, stride, info )
Параметр xp - массив, куда будут помещены распакованные данные.
Параметры nitem и stride имеют тот же смысл, что и в соответствующих функциях упаковки (см. выше).
Параметр what был так же описан выше.
1.6.6 Отладка в PVM
По умолчанию только текст, выводимый родительской задачей (то есть той, которую вы сами запустили с терминала) окажется на экране. Стандартный вывод задач, запускаемых функцией pvm_spawn(), по умолчанию перенаправляется в LOG-файл исполняющей системы PVM ($PVM_TMP/pvml.*). Функция
call pvmfcatchout( onoff, info )
позволяет перенаправить его в любой другой открытый для записи файл, например, фрагмент
call pvmfcatchout (1, info);
call pvmfspawn (...
в родительской задаче весь вывод от всех запускаемых под-задач перенаправит на экран. При этом PVM гарантирует, что строки от разных задач не будут "налезать" одна на другую, и каждая строка будет предваряться идентификатором той задачи, которая ее вывела. Использование pvm_catchout() имеет два недостатка: а) между посылкой строки в файл или на экран из под-задачи и ее фактическим там появлением может быть задержка неизвестной заранее длительности, и, б) если объем выводимой диагностики от разных задач очень велик, очень трудно разобраться в поведении какой-то одной конкретной задачи.
1.6.7 Установка PVM
Установка системы PVM на компьютере, работающем под управлением операционной системы Linux достаточно проста и не требует каких либо длительных настроек. Cистема PVM распространяется бесплатно и в исходных кодах. Исходники PVM вы можете найти на этом сайте или непосредственно на сайте разработчиков по адресу http://www.netlib.org/pvm3/index.html.
Для установки 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
В дальнейшем будем считать, что виртуальная машина была собрана именно с такими изменениями, то есть с заменой rsh на ssh.
После изменения всего того перелогинтесь в систему, чтобы изменения, сделанные вами в профайлах вступили в силу.
Для сборки и установки PVM, находясь в каталге /pvm3, выполните команду make. По окончании ее работы система PVM готова к запуску. Следует отметить, что для уменьшения проблем, связаных с настройкой PVM на узлах кластера, на всех машинах кластера PVM следует устанавливать в один и тот же каталог.
Глава 2. Обучение будущих учителей сетевому администрированию
</0>
|
