Кластерные системы

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-пакеты пройдут через коммутатор по всем виртуальным каналам, внутренняя таблица коммутатора примет правильный вид и в дальнейшем проблем с приемом пакетов не будет.