47965 (Основы параллельного программирования на кластере и разработка элективного курса «Администрирование в информационных системах и администрирование виртуальных машин»), страница 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-сеть построенную на отдельном (от других параллельных ей линий) комутаторе.

1.4 ОПЕРАЦИОНАЯ СИСТЕМА

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

Под Linux доступно огромное количество серверного ПО, компиляторов, библиотек, средств отладки и пр. Большое количество программного обеспечения имеется в свободном доступе, для многих программ есть исходные коды и обширная документация.

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