Дипломная работа: Основы параллельного программирования на кластере и разработка элективного курса «Администрирование в информационных системах и администрирование виртуальных машин»

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

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

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

- Разработать инструкции по установке и использованию сетей виртуальных машин.

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

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

В случае успешного выполнения задач и реализации цели данной работы ожидается получение следующих результатов: подтверждение положения о возможности построения курса обучения основам системного администрирования для студентов, обучающихся по специальности 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/networkstop