Скачать 0.73 Mb.
|
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Государственное образовательное учреждение высшего профессионального образования Красноярский государственный педагогический университет им. В.П. Астафьева Институт математики, физики и информатики Факультет информатики Кафедра информатики и вычислительной техники Выпускная квалификационная работа Основы параллельного программирования на кластере и разработка элективного курса "Администрирование в информационных системах и администрирование виртуальных машин" Работу выполнил: Гончаров Иван Викторович (роспись) Научный руководитель: Шикунов Сергей Анатольевич к.ф.-м.н., доцент _____________(роспись) Рецензент: Прохоров Алексей Анатольевич ст.преподаватель _____________(роспись) Допущена к защите: Пак Н.И. д.п.н., профессор, зав. каф.ИВТ Оценка: Дата защиты (число, месяц, год) Красноярск 2008 Содержание Введение Глава 1. Кластерные системы 1.1 Структура Beowulf и параметры 1.2 Виртуальный скоростной канал, интерфейс 1.3 Устройство кластера 1.4 Операционная система1.5 Организация кластерной системы1.6 Параллельная виртуальная машина(PVM) 1.6.1 Взаимодействие задач в PVM 1.6.2 Управление задачами 1.6.3 Передача сообщений 1.6.4 Упаковка данных 1.6.5 Распаковка полученных данных 1.6.6 Отладка в PVM 1.6.7 Установка PVM Глава 2 Обучение будущих учителей сетевому администрированию 2.1 Анализ целесообразности обучения будущих учителей сетевому администрированию 2.2. Виртуальная машина для обучения 2.2.1. Анализ и выбор виртуальной машины для обучения 2.2.2. Инструкции по работе с рекомендуемым программным обеспечением
Заключение Список литературы Введение Сейчас в наших научных организациях и университетах, как правило, имеются энтузиасты бесплатного распространяемого ПО и специалисты по ОС Linux. В то же время парк более-менее современных персональных компьютеров в этих организациях имеется. Закономерно появилась идея создавния параллельных вычислительных систем из общедоступных компьютеров на базе процессоров Intel и недорогих Ethernet-сетей, установив на эти компьютеры Linux и, объединив с помощью одной из бесплатно распространяемых коммуникационных библиотек (PVM, а затем MPI) эти компьютеры в кластер. Оказалось, что на многих классах задач и при достаточном числе узлов такие системы дают производительность, сравнимую с той, что можно получить, используя дорогие суперкомпьютеры. При отсутствии высококвалифицированных параллельных программистов кластеры Beowulf создаются и используются людьми с минимальным опытом параллельного программирования. В самом деле, кластеры Beowulf обеспечивают университеты с ограниченными ресурсами хорошей платформой для изучения параллельного программирования и недорогой производительной вычислительной системой для ученых. Затраты на установку в университетах минмиальны: многие студенты заинтересованы в таких проектах и используют Linux на собственных компьютерах, установка кластера и написание параллельных программ является частью процесса обучения. Школьный учитель информатики проводит занятия в учебном компьютерном классе, в котором компьютеры объединены в локальную сеть, в подавляющем большинстве случаев, находящуюся под управлением операционной системы Windows. Такая ситуация требует, чтобы школьный учитель хотя бы на базовом уровне разбирался в администрировании таких сетей. Тем более, что и любознательность современных школьников, сталкивающихся с сетями разного уровня повсеместно, должна быть удовлетворена. Поэтому представляется полезным обеспечить будущим школьным учителям информатики возможность познакомиться с основами построения, функционирования и управления компьютерными сетями во время специальной подготовке в период прохождения базового обучения своей профессии. Существующие курсы подготовки студентов различных специальностей в этой области достаточно сложны и для получения первоначального представления нет необходимости их копировать. К тому же, курс для будущих школьных учителей информатики должен иметь более практическую направленность – чтобы будущие учителя могли попробовать управлять сетью и почувствовать, что это не является чрезмерно сложно, таинственно и непостижимо. Поэтому в таком курсе необходимо большое внимание уделить обеспечению возможности каждому учащемуся в достаточной степени попробовать себя в создании, настройке и администрировании компьютерной сетью. Единственной реальной возможностью в достаточной степени получить практические навыки такого сорта является организация для каждого учащегося на отдельном компьютере виртуальной сети из нескольких виртуальных компьютеров. Современное программное обеспечение позволяет применить виртуальные машины, что дает различным категориям пользователей - от начинающих до IT-специалистов - множество преимуществ. Это и повышенная безопасность работы, и простота развертывания новых платформ, и снижение стоимости владения. И потому не случайно сегодня виртуальные машины переживают второе рождение. На сегодняшний день существуют три наиболее популярных инструмента, предназначенных для создания виртуальных машин и управления ими: Virtual PC 2004 компании Microsoft, VMware Workstation от компании VMware и относительно "свежий" продукт - Parallels Workstation, созданный в компании Parallels. Поэтому в данной работе предлагается использовать одну из этих виртуальных машин для создания на отдельном компьютере виртуальной сети такой, чтобы учащийся мог персонально поработать со своей собственной сетью во время занятия в компьютерном классе. При этом в работе так же предлагается адаптировать существующие курсы обучения системному администрированию будущих "реальных" специалистов для нужд базового обучения будущих учителей информатики с учётом ограниченности возможностей виртуальных сетей реализуемых на виртуальной машине. В связи с вышесказанным в данной работе была поставлена следующая цель: исследовать возможность построения курса обучения основам системного администрирования для будущих учителей информатики на основе виртуальной локальной сети. При этом была выдвинута следующая гипотеза: возможно адаптировать существующие курсы обучения системному администрированию так, чтобы они были посильны и интересны студентам, обучающимся по специальности 030100 и могли быть проведены на виртуальных сетях, построенных на виртуальных машинах. Объектом исследования в данной работе являлся процесс базовой подготовки по информационным дисциплинам студентов, обучающихся по специальности 030100. Предметом исследования – возможность построения курса обучения основам системного администрирования удовлетворяющего цели и гипотезе исследования. Для выполнения поставленной цели было необходимо решить следующие задачи: - изучить кластерные системы, организацию кластерной системы, устройство кластера, сетевое обеспечение кластера; - изучить параллельную виртуальную машину(PVM), взаимодействие её задач, администрирование PVM. - Ознакомиться с возможностями виртуальных машин для построения виртуальных локальных сетей. - Выбрать одну из таких машин для реализации на ней предлагаемого курса и проанализировать ограничения на содержание курса, накладываемые ограничениями виртуальной сети. - Ознакомиться с типичными содержаниями курсов по системному администрированию и определить содержание курса. - Собрать материалы по теме "системное администрирование" и "построение сетей виртуальных машин", имеющие ценность для построения учебного курса и обучения. - Разработать инструкции по установке и использованию сетей виртуальных машин. - Разработать тематическое планирование и рабочую программу курса, позволяющие при проведении занятий по ним достичь заявленную цель и доказать заявленную гипотезу. - Разработать лабораторные работы, упражнения и контрольные вопросы по темам курса. В случае успешного выполнения задач и реализации цели данной работы ожидается получение следующих результатов: подтверждение положения о возможности построения курса обучения основам системного администрирования для студентов, обучающихся по специальности 030100, на основе виртуальной локальной сети, путём адаптации существующих курсов обучения системному администрированию так, чтобы они могли быть проведены на виртуальных сетях, построенных на виртуальных машинах. 1. Кластерные системы Параллельный кластер - это то, что вам не хватало для вашей работы. Возникает вопрос, из чего его делать и сколько компьютеров необходимо связать в кластер, чтобы затраченные усилия дали ощутимый результат. Кроме того хотелось бы понять какие компьютеры необходимы для кластера. 1.1 Структура Beowulf и параметры Сразу скажу, что кластер Beowulf - гетерогенная структура. В него могут входить самые разнообазные по параметрам компьютеры, построенные на различных аппаратных платформах, например Intel Pentium различных версий, Alpha, RISC-процессоры, Transmeta, 32-х и 64-х битовые процессоры. Более того, на компьютерах в кластере могут быть установлены самые различные системы: Linux, Windows, OS/2 WARP. Нашей целью будет построение кластера с минимальными усилиями. Поэтому, если вы хотите заниматься делом (сиречь научной работой), а не повышать свой профессионализм в области информационных технологий, о возможной гетерогенности кластера я предлагаю забыть. Будем считать, что аппаратная платформа комьютеров нашего будущего кластера однообразна. Что касается различия в параметрах (быстродействие, память, ...) у компьютеров, входящих в кластер, то это допустимо. Но в этом случае, вам придется учитывать эти различия при написании параллельных программ, распределяя объем счета в зависимости от возможности каждого отдельного компьютера. В противном случае кластер будет работать как система, состоящая из машин с минимальными рабочими параметрами. Как я уже говорил, построение кластера - не самоцель, а средство. Поэтому для минимизации усилий будем считать, что все компьютеры кластера одинаковы по своим рабочим характеристикам и управляются одной и той же операционной системой. За одним исключением, главный компьютер кластера, консоль кластера, может (но не должен) быть более мощной машиной. Начнем с самого простого, с выбора размера кластера. Поскольку кластер Beowulf - масштабируемая система, то вопрос количества узлов не является жизненно важным. По мере роста ваших аппетитов вы можете произвольно добавлять количество узлов в любое время. Если же вы для узлов будете использовать удаленную загрузку операционной системы по сети (о чем мы еще поговорим позже), то работы по добавлению узла кластера не выйдут за рамки технического подключения новой машины в сеть. Естественно вам придется еще немного изменить ваши программы, разбив их на большее количество параллельных подзадач, с тем чтобы иметь возможность использовать в процессе счета большее количество процессоров. Однако увлекаться количеством узлов не стоит. Самое узкое место в вашем кластере - это среда передачи данных между узлами, то есть пропускная способность используемой сети. Как видно эффективность нашего кластера зависит от числа узлов нелинейно. Собственно вид этой функции зависит от вида задачи, которая решается с помощью кластера. Приведенный рисунок более-менее корректно отображает положение дел с задачами типа решения уравнений газодинамики на больших сетках (но не только). В этом случае эффективность кластера растет до того момента, когда время передачи между узлами информации, необходимой для проведения одной итерации становится сравнимым со временем счета одной итерации. В других случаях, например для решения системы уравнений методом Монте-Карло или методом перебора, функция эффективности принимает линейный вид. То есть, чем больше машин в кластере, тем быстрее работает программа. Если же говорить о методе прогонки, то функция эффективности имеет максимум при количестве узлов равном единице и спадает до нуля обратно пропорционально росту количества узлов. Таким образом, можно порекомендовать при начальном построении кластера ограничится четырьмя узлами (одна консоль и три slave-ноды). С одной стороны, вы всегда при необходимости можете нарастить кластер, с другой стороны, меньшее количество узлов может дать не столь ощутимый результат, как ожидалось. Тем не менее, при пробемах с финансированием можно ограничится и двумя узлами. А если вы просто хотите попробовать, что такое есть кластер, можете обойтись вообще одним компьютером, с установленным на нем VMWare. 1.2 Виртуальный скоростной канал, интерфейс Рассмотрим более подробно каким образом из нескольких сетевых интерфейсов можно создать один виртуальный скоростной канал. Для увеличения эффективной пропускной способности сети кластера рекомендуется использовать так называемое "связывание каналов" или channel bonding. Это такой способ объединения узлов кластера в сеть, когда каждый узел подсоединяется к коммутатору более чем одним каналом. Чтобы достичь этого, узлы надо оснастить либо несколькими сетевыми платами, либо многопортовыми платами Fast Ethernet. Связать можно и гигабитные каналы. Связывание каналов аналогично режиму транкинга при соединении коммутаторов, который используется для увеличения скорости передачи данных между двумя или несколькими коммутаторами. Применение связывания каналов в узлах под управлением ОС Linux позволяет организовать равномерное распределение нагрузки приема/передачи между соответствующими каналами. Channel bonding пораждает некоторые проблемы связанные с выбором коммутаторов и их настройки. Коммутатор должен уметь работать со связанными каналами иначе могут происходить всевозможные ошибки при построении комутатором таблиц маршрутизации пакетов или таблиц MAC-адресов. То есть, как уже было упомянуто ранее, в качестве сетового оборудования надо выбирать такой ethernet switсh, который поддерживает для своих портов функции Link Aggregation или IEEE 802.3ad. Другим решением проблемы я вляется выбор коммутатора с возможностью поддержки режима виртуальных локальных сетей (VLAN). Применение VLAN призвано помочь избежать "дублирования" во внутренних таблицах коммутаторов MAC-адресов многопортовых сетевых плат. Впрочем, есть сообщения, что и поддержка VLAN не всегда помогает, вы можете попробовать этот вариант, но на свой страх и риск. Вместо использования специализированного сетевого оборудования, поддерживающего связывание каналов, можно разделить каналы с помощью двойного (тройного и т.д.) набора обычных хабов или свитчей на непересекающиеся сетевые сегменты таким образом, чтобы каждый канал образовывал свою собственную сеть, физически не связанную с сетями других каналов. Организация в системе сетевого итерфеса по методу channel bonding достаточно проста. Нужно только следовать одному правилу. Все присоединенные машины должны иметь одинаковый набор bonded networks, т.е. нельзя в одной машине использовать 2х100BaseTx, а в другой 10Base и 100BaseTx. Режим работы сетевых карт тоже должен быть однообразный. Другими словами, недопустим вариант, когда одна карта работает в full duplex, а другая в полудуплексном режиме. В каждой же отдельной машине можно устанавливать карты различных производителей, но работающие обязательно в одном стандарте. Channel bonding требует наличия как минимум двух физических подсетей. Но, при желании связанный канал можно построить на основе трех или более сетевых карт. Для связывания сетевых карт в один канал (одну виртуальную карту) необходимо либо скомпилировать ядро системы с поддержкой cannel bonding, либо загрузить в систему модуль ядра bonding.o. В Linux начиная с ядер 2.4.x channel bonding является стандартной включаемой опцией. Например в дистрибутиве Alt Linux Master 2.2 channel bonding поставляется в виде загружаемого модуля ядра. Для конфигурации связанного канала вам потребуется стандартная команда ifconfig и, возможно, дополнительная команда ifenslave. Программа 'ifenslave' копирует установки первого интерфейса на все остальные дополнительные интерфейсы. Этой же командой можно при желании какие-либо интерфейсы сконфигурировать в режиме Rx-only. Покажем процесс настройки channel bonding на примере использования двух сетевых карт. Сетевой интерфейс для первой карты должен быть заранее сконфигурен и полностью работоспособен. Для добавления в систему второй карты и объединения ее с первой в связанный канал требуется выполнить некоторые достаточно простые действия. Предварительно желательно остановть сетевые интерфейсы вашей системы выполнив команду /etc/rc.d/init.d/network stop После этого переходим собственно к конфигурации связанного канала. Для начала вам нужно изменить файл /etc/modules.conf, добавив в него следующую строчку. alias bond0 bonding Сделанное нами добавление говорит системе о том, что при загрузке необходимо загрузить модуль bonding.o, который узнается так же по алиасу bond0. Чтобы не перезагружать систему, вручную загрузим модуль: modprobe bonding Теперь идем в каталог /etc/sysconfig/network-scripts и переименовываем файл описания нашего первого интерфейса ifcfg-eth0 в ifcfg-bond0: cp ifcfg-eth0 ifcfg-bond0 Полученный нами файл ifcfg-bond0 мы должны отредактировать так, чтобы он принял примерно следующий вид: DEVICE=bond0 IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.1.0 BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no Естественно вы должны указать свои собственные ip-адрес, маску, адрес сети и broadcast вместо 192.168.1 и пр. Надо заметить, что мы не удаляли никакие строчки из этого файла, просто сделали изменения в нужных местах и может быть добавили что-то. Таким образом мы создали файл описания нашего виртуального сетевого интерфейса. Следующим шагом будет создание файлов описания для двух наших реальных физических интерфейсов eth0 и eth1, в которых мы укажем, что они входят в состав связанного канала. Файлы ifcfg-eth0 и ifcfg-eth1 у нас должны иметь следующее содержимое: файл ifcfg-eth0 файл ifcfg-eth1 ------------------------ --------------------------------- DEVICE=eth0 DEVICE=eth1 USERCTL=no USERCTL=no ONBOOT=yes ONBOOT=yes MASTER=bond0 MASTER=bond0 SLAVE=yes SLAVE=yes BOOTPROTO=none BOOTPROTO=none Теперь нам осталось только поднять сетевой интерфейс выполнив команду /etc/rc.d/init.d/network start Если дистрибутив вашей системы не позволяет применять master/slave нотификацию при конфигурации сетевых интерфейсов, то вам придется поднимать интерфейс связанного канала вручную, используя следующую последовательность команд: /sbin/ifconfig bond0 192.168.1.1 up netmask 255.255.255.0 /sbin/ifenslave bond0 eth0 /sbin/ifenslave bond0 eth1 Соответственно вместо 192.168.1.1 вы должны использовать тот ip-адрес, который вам нужен, и указать правильную маску подсети; приведенные выше строчки только пример. Чтобы не выполнять эти команды вручную каждый раз, запишите их в какой-нибудь startup-скрипт, например в /etc/rc.d/rc.local, или замените ими ту часть скрипта /etc/rc.d/init.d/network, которая отвественна за поднятие сетевого интерфейса. Как вы заметили, для ручного поднятия интерфейса мы использовали команду ifenslave. Это не стандартная системная команда. Программа ifenslave была разработана в рамках проекта Beowulf и вам придется скомпилировать ее из исходных кодов, которые вы можете взять непосредственно на сайте проекта http://beowulf.org/software/ifenslave.c или с сайта проекта Debian: ifenslave_0.07.orig.tar.gz, ifenslave_0.07-1.diff.gz. Естественно, все это вы можете найти в разделе Download этого сайта. Компиляция программы происходит следующей командой: gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave Не забудьте только положить полученный исполняемый файл в /usr/sbin. Если по каким то причинам вам нужно, чтобы все сетевые драйверы были загружены до загрузки bonding-драйвера, добавьте ниже приведенную строчку в файл /etc/modules.conf. Эта инструкция укажет системе, что в случае поднятия интерфейса bond0 утилита modprobe должна сначала загрузить драйверы для всех ваших сетевых интерфейсов. probeall bond0 eth0 eth1 bonding Собственно на этом настройка channel bonding закончена. Если сетевой интерфейс поднялся без ошибок, то проверить этот знаменательный факт можно используя обычную команду ifconfig. Запустив ее без параметров вы должны увидеть нечто подобное: [root]# /sbin/ifconfig bond0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:7224794 errors:0 dropped:0 overruns:0 frame:0 TX packets:3286647 errors:1 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:0 eth0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:3573025 errors:0 dropped:0 overruns:0 frame:0 TX packets:1643167 errors:1 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:100 Interrupt:10 Base address:0x1080 eth1 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:3651769 errors:0 dropped:0 overruns:0 frame:0 TX packets:1643480 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0x1400 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1110 errors:0 dropped:0 overruns:0 frame:0 TX packets:1110 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 Если вы увидели нечто подобное на экране монитора, можете себя поздравить, вы успешно сконфигурировали связанный канал. Как видите, ip- и MAC-адреса всех сетевых интерфейсов у нас получились одинаковыми. Чтобы switch мог нормально работать с таким каналом вам необходимо настроить Link Aggrigation. Как это делать вы можете прочитать в документации вашего коммутатора. Для разных моделей коммутатров и разных версий их программного обеспечения это может делаться по-разному. Поэтому в данной книге мы опустим вопросы настройки Link Aggrigation на коммутаторах. В интернете встречаются сообщения, что в некоторых случаях, после поднятия виртуального сетевого интерфейса дополнительные каналы не могут сразу принимать входящие покеты. Это может произойти по причине того, что новый MAC-адрес дополнительных каналов не прописывается физически в EPROM сетевой карты, в результате чего при старте компьютера свитч не знает о том, что этот MAC-адрес присоединен к более чем одному порту. Для того, чтобы сообщить свитчу правильный набор MAC-адресов достаточно нпосредственно после поднятия интерфейса выполнить несколько пингов. После того, как ICMP-пакеты пройдут через коммутатор по всем виртуальным каналам, внутренняя таблица коммутатора примет правильный вид и в дальнейшем проблем с приемом пакетов не будет. 1.3 Устройство кластера Кластер Beowulf состоит из отдельных машин (узлов) и объединяющей их сети (коммутатора). Кроме ОС, необходимо установить и настроить сетевые драйверы, компиляторы, ПО поддержки параллельного программирования и распределения вычислительной нагрузки. Узлы кластера. Подходящим выбором в данный момент являются системы на базе процессоров Intel Pentium 4. Стоит установить на каждый узел не менее 64-128MB оперативной памяти. Одну из машин следует выделить в качестве центральной (консоль кластера) куда можно (но не обязательно) установить достаточно большой жесткий диск, возможно более мощный процессор и больше памяти, чем на остальные (рабочие) узлы. Делать консоль кластера более мощной машиной имеет смысл, если вы захотите иметь на этом компьютере кроме интерфеса командной строки более удобное операционной окружение, например оконый менеджер (KDE, Gnome), оффисные программы, программы визуализации данных и т.п.. Имеет смысл обеспечить (защищенную) связь этой машины с внешним миром. Другими словами, сеть кластера (сеть состоящая их консоли кластера и рабочих узлов) топологически не должна находится внутри корпоративной сети. Если необходимо обеспечить доступ к консоли кластера из корпоративной сети и/или Интернет, то в этом случае, связь должна идти через отдельную сетевую карту, установленную в главном компьютере, и отдельный коммутатор. При комплектации рабочих узлов вполне возможно отказаться от жестких дисков - эти узлы будут загружать ОС через сеть с центральной машины, что, кроме экономии средств, позволяет сконфигурировать ОС и все необходимое ПО только один раз (на центральной машине). Если эти узлы не будут одновременно использоваться в качестве пользовательских рабочих мест, нет необходимости устанавливать на них видеокарты и мониторы. Возможна установка узлов в стойки (rackmounting), что позволит уменьшить место, занимаемое узлами, но будет стоить несколько дороже. Возможна организация кластеров на базе уже существующих сетей рабочих станций, то есть рабочие станции пользователей могут использоваться в качестве узлов кластера ночью и в нерабочие дни. Системы такого типа называют COW (Cluster of Workstations). В этом случае реальным представляется вариант, когда кластер строится на основе существующего компьютерного класса. Подобные классы уже имеются в большинстве учебных или научных учреждениях и обычно скомплектованы однотипными машинами, что и необходимо для кластера. Однако обычно такие компьютерные классы работают под операционной системой Windows и, вероятно, для замены ее на Unix придется решить вопросы административного плана и вопросы связанные с построением учебного процесса. Принципиальных препятствий для решения этих вопросов по-видимому нет, поскольку Unix (конкретно Linux) имеет все необходимое программное обеспечение для проведения учебного процесса или научной деятельности (компиляторы, средства разработки, офисные программы, программы работы с изображениями и визуализации данных, средства публикации (TeX)). Эта книга, например, большую часть времени писалась на консоли кластера в OpenOffice под управлением операционной системы Linux. Нельзя сказать, чтобы я испытывал при этом какую-либо ностальгию по старому доброму MS Word. По большому счету отказываться от Windows не обязательно. Коммуникационные библиотеки PVM, MPI имеются не только для UNIX, но и для Windows. Если установка в компьютерном классе UNIX-сети вызывает непреодолимую аллергическую реакцию у админов или преподавателей, можно оставить ту операционную систему, к которой вы привыкли. В принципе, для кластерных систем типа COW нет насущной необходимости останавливать кластер (и задачи на нем считаемые) на дневное (рабочее) время, когда за узловыми машинами работают пользователи. Работа параллельных программ конечно будет замедляться, но это не летально. Другое дело, если работа кластера будет заметно тормозить и затруднять работу пользователей. Сеть. В простейшем случае для связи между узлами кластера используется один сегмент Ethernet (10Mbit/sec на витой паре). Однако дешевизна такой сети, вследствие коллизий оборачивается большими накладными расходами на межпроцессорные обмены, а хорошую производительность такого кластера можно ожидать только на задачах с очень простой параллельной структурой и при очень редких взаимодействиях между процессами (например, перебор вариантов). Для получения хорошей производительности межпроцессорных обменов используют полнодуплексный Fast Ethernet на 100Mbit/sec или Gigabit Ethernet. При этом для уменьшения числа коллизий или устанавливают несколько "параллельных" сегментов Ethernet, или соединяют узлы кластера через коммутатор (switch). Под "параллельными" сегментами подразумевается такая структура сети, когда каждый узел кластера имеет более одной сетевой карты, которые с помощью специальных драйверов объединяются в один виртуальный сетевой интерфейс, имеющий суммарную пропускную способность. Для того, чтобы избежать проблем с конфигурированием такого виртуального интерфеса, следует использовать одинаковые сетевые карты на всех машинах кластера. Кроме того, каждая параллельная линия такого интерфеса должна представлять из себя Ethernet-сеть построенную на отдельном (от других параллельных ей линий) комутаторе. |
Руководство администраторами хостинга Системное администрирование, Администрирование сетей, Администрирование Linux, Администрирование серверов, Администрирование *nix,... |
Учебно-методический комплекс дисциплины «Администрирование информационных систем» Математическое обеспечение и администрирование информационных систем Форма подготовки (очная) |
||
Выпускная квалификационная работа «Разработка и экономическое обоснование... Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования |
Рабочая программа дисциплины б 27 проектирование мобильных систем... Целью освоения дисциплины является формирование у студентов теоретических основ и практических навыков программной разработки мобильных... |
||
• Руководство it-подразделением Высоконагруженные системы, Unix, Nginx, Kvm, Администрирование Linux, Zabbix, Системное администрирование |
Конспект лекций профессионального модуля пм. 02 Разработка и администрирование баз данных Тема 3 Основы разработки клиент-серверных приложений для работы в компьютерной сети |
||
Выпускная квалификационная работа Влияние информационных технологий на развитие социально-культурного сервиса и туризма |
Выпускная квалификационная работа бакалавра Теоретические основы формирования кредитной политики коммерческого банка |
||
Выпускная квалификационная работа На тему: «Разработка комплекса мероприятий по обеспечению информационной безопасности на предприятии» |
Технологии в деятельности социальных организаций выпускная квалификационная... Теоретические аспекты и правовые основы pr-деятельности в социальной работе 6 |
||
Пермский филиал Факультет бизнес-информатики Кафедра информационных... Данные гис – данные, полученные в результате геофизического исследования скважин. Синоним к термину «Каротажные данные» |
Курсовая работа по дисциплине «Логистика в транспортных системах» Теоретические основы грузоподъемных машин в транспортных системах |
||
Виталий Давудов Информационные системы и технологии Управление людьми, Сетевые технологии, Cisco ccnp, Системы виртуализации, Проектирование сетей, Телекоммуникации, Администрирование... |
Рабочая программа спецкурса Олимпиадное программирование 8 и класс... Рабочая программа элективного курса «Олимпиадное программирование» для 8 специализированного класса инженерно-технологической направленности... |
||
Выпускная квалификационная работа повышение надежности информационной... Студентки5 курса группы пи5 специальности «Прикладная информатика (в экономике)» Левченко Андрея Юрьевича |
Системное программирование Специальность 351500 – математическое обеспечение и администрирование информационных систем |
Поиск |