Кластерные системы на основе ОС Linux. Построение учебного кластера

Выходом из создавшегося положения стали языки программирования, основанные на параллелизме данных. Первый из них, Fortran-D, появился в 1992 г. На смену ему пришел High Performance Fortran (HPF), представляющий собой расширение языка Fortran 90 и требующий от пользователя лишь указать распределение данных по процессорам. В остальном программа имеет последовательный вид (это, впрочем, не означает, что, придумывая алгоритм, не следует задумываться о присущем ему параллелизме). Транслятор самостоятельно распределяет вычисления по процессорам, выбирая в качестве узла, на котором следует производить вычисления, тот процессор, на котором будет использован результат вычисления выражения. При необходимости транслятор генерирует обращения к библиотеке передачи сообщений, например MPI. От компилятора HPF требуется тщательный анализ программы. Пользователь практически не имеет рычагов управления количеством пересылок, а поскольку инициализация каждой пересылки, независимо от объема передаваемой информации, - это десятки тысяч машинных тактов, качество получаемой программы от него зависит слабо. Язык HPF - вызов специалистам по оптимизации кода.

В языке программирования mpC - расширении ANSI C - принят компромиссный подход. Здесь пользователь распределяет не только данные, но и вычисления. Переменные и массивы распределяются по виртуальным сетям (networks) и подсетям, при этом в описаниях сетей указываются относительные мощности узлов и скорости связей между ними. В процессе выполнения mpC-программы система поддержки языка стремится максимально эффективно отобразить виртуальные сети на группы процессоров. В результате пользователь получает возможность равномерно нагружать узлы. Этот подход позволяет эффективно использовать гетерогенные сети и решать нерегулярные задачи, отличающиеся тем, что объем вычислений, производимых на каждом узле, выясняется динамически в процессе решения задачи. Этот язык позволяет избежать трудностей отладки, характерных для библиотек передачи сообщений. В то же время mpC достаточно прозрачный язык, и применяющий его программист сохраняет контроль за числом операций пересылок и объемами передаваемых данных. Относительная (по сравнению с MPI) простота программирования позволяет создавать программы и библиотеки функций, настраивающиеся на особенности конкретной вычислительной системы со своим числом процессоров и скоростями связей между ними. Такие программы не только мобильны, но и сохраняют свою эффективность при переносе с одной вычислительной системы на другую.

3. СОВРЕМЕННЫЕ ВАРИАНТЫ LINUX - КЛАСТЕРОВ.

3.1. BEOWULF.

Одним из проектов развития параллельных распределенных вычислений является Beowulf, целью которого является применение технологии распределенных вычислений на сетях кластеров широко распространенных персональных ЭВМ. Основанием для такого проекта являлась широкое распростанение ПЭВМ, их дешивизна и увеличившаяся в достаточной степени производительность. В результате выполнения этого проекта на различных задачах была продемонстрирована пиковая производительность кластеров из 16 ПЭВМ доходящая до 1 Гоп/сек и суммарная емкость дискового простанства существенно превышающая возможности сравнимых по стоимости единичных ЭВМ.

Проект возник в научно-космическом центре NASA - Goddard Space Flight Center (GSFC), точнее в созданном на его основе CESDIS (Center of Excellence in Space Data and Information Sciences).

Проект Beowulf начался летом 1994 года сборкой в GSFC 16-процессорного кластера (на процессорах 486DX4/100MHz, 16MB памяти и 3 сетевых адаптера на каждом узле, 3 "параллельных" Ethernet-кабеля по 10Mbit). Данный кластер, который и был назван "Beowulf", создавался как вычислительный ресурс проекта Earth and Space Sciences Project (ESS).

Beowulf это мультикомпьютерная архитектура, которая предназначена для проведения параллельных вычислений. Такая система обычно состоит из одного server node (сервера) и нескольких (в самом простом случае - одного) client nodes (клиента), которые соединены между собой сетью Ethernet. Параллельная структура Beowulf строится из обычных общеупотребимых аппаратных средств, таких как персональные компьютеры класса IBM PC, стандартные Ethernet-адаптеры и маршрутизаторы. Комплекс работает под операционной системой Linux. Отказ от использования каких-либо специальных hardware-компонентов делает архитектуру Beowulf легко воспроизводимой и имеющей уникальное соотношение быстродействие/стоимость В число программных компонентов Beowulf кроме ОС Linux входят так же Parallel Virtual Machine (PVM) и Message Passing Interface (MPI). Сервер кластера управляет работой всего кластера и обслуживает файловые системы клиентских машин. Машина-сервер выполняет так же роль консоли кластера и моста в остальной intranet/internet. Крупные системы Beowulf могут иметь больше одного сервера и/или иметь несколько узловых машин (клиентов), посвященных исключительно выполнению отдельных задач, например консоль кластера или станция мониторинга системы. В болшинстве случаев клиенты кластера - очень тупые и несамостоятельные машины. И чем тупее они, тем лучше для кластера. Клиенты конфигурируются и управляются сервером кластера и делают только то, что он им задает. В случае бездисковой конфигурации клиенты не знают даже их IP-адреса или имена до тех пор, пока пока их не установит сервер. Одно из главных отличий между Beowulf и Cluster of Workstations (COW) является то, что Beowulf ведет себя больше как одиночная машина нежели чем как много рабочих станций. В большинстве случаев клиенты не имеют мониторов и клавиатур и доступны только через remote login или, возможно, через serial terminal. Другими словами, клиентские машины кластера выступают в роли просто дополнительных процессоров и модулей памяти.

Beowulf это не специальный пакет программ, новая сетевая топология или новая версия ядра. Beowulf - это технология кластеризации Linux-машин, технология формирования виртуального параллельного суперкомпьютера. Хотя имеются много программных пакетов, таких как kernel modifications, PVM- и MPI-библиотеки, и средства конфигурации, делающие архитектуру Beowulf быстрее, легче в настройке, и намного более годным к употреблению, Вы можете построить машину класса Beowulf, используя только стандартную дистрибуцию Linux без каких-либо дополнительных пакетов программ. Если у Вас есть два сетевых компьютера с расшаренным через NFS файловой системой /home, и вы доверяете этим компьютерам запускать друг у друга remote shells (rsh), тогда можно сказать, что у Вас есть простейшая двухнодовая Beowulf машина.

Кластер состоит из отдельных машин (узлов) и объединяющей их сети (коммутатора). Кроме ОС, необходимо установить и настроить сетевые драйверы, компиляторы, ПО поддержки параллельного программирования и распределения вычислительной нагрузки.

3.2. MOSIX.

Mosix - это пакет кластерообразующих программ, предназначенный для расширения ядра Linux . Расширенное ядро позволяет создавать кластеры любых размеров на базе семейства x86, Pentium процессоров. Для запуска приложений в Mosix кластере не требуется их модификация или перекомпиляция , а также не нужны дополнительные библиотеки. Ядром Mosix управляют адаптивные алгоритмы распределения ресурсов, эти алгоритмы используют приоритетное перемещение процессов, чтобы назначать и переназначать процессы среди узлов, выбирая наилучший среди доступных узлов, по признаку наименьшей занятости. Проще говоря, Mosix распределяет процессы на разные узлы кластера, при этом процесс мигрирует на наименее занятый узел.

Mosix начинался на компьютерах PDP-11 в 1977/79 годах и назывался:"UNIX with Satellite Processors" в качестве ОС использовалась Bell Lab's Unix Level 6 В 1981-83/84 годах вышли две версии под названием MOS на PDP-11 и CADMUS/PCS MC68K под обновленной ОС Bell Lab's Unix 7 с BSD 4.1. В 1987/88 вышел NSMOS на NS32332 и ОС AT&T Unix system V release 2 Также в 1988 году появилась версия под VAX, для которой впервые было использовано название MOSIX, использовалась таже ОС что и для NSMOS Первая реализация на семействе X86/Pentium появилась в 1992/93 под BSD/OS. Новая реинкарнация на X86/Pentium вышла уже на LINUX в 1998/99.

Программный пакет openMosix позволяет превратить в кластер компьютеры под управлением GNU/Linux, объединённые в сеть. Такой кластер позволит автоматически балансировать нагрузку на узлах, при этом новые узлы могут присоединяться или покидать кластер без прерывания его работы. Нагрузка на узлы распределяется исходя из скорости соединения и мощностей процессоров.

Поскольку openMosix является частью ядра и полностью совместим с Linux, то и все пользовательские программы, файлы и прочие ресурсы будут работать также, как и раньше, без каких-либо изменений. Простой пользователь даже не заметит разницы между Linux и openMosix системой. В целом картину можно представить, как будто весь кластер работает как одна (быстрая) GNU/Linux система.

ОpenMosix представляет собой патч для ядра Linux, который, тем не менее, обеспечивает полную совместимость с платформой IA32. Благодаря внутреннему механизму балансировки нагрузки процессы могут мигрировать на другие узлы кластера. В результате получается выигрыш в производительности при использовании ресурсов нескольких машин. К тому же кластер постоянно самостоятельно пытается оптимизировать обработку процессов (естественно, что администратор системы может вмешаться в процесс автобалансировки в любое время).

Такой механизм прозрачной миграции процессов позволяет представить кластер как одну большую SMP-систему с множеством процессоров на доступных узлах кластера (конечно, следует учитывать и количество процессоров в двух и четырёх процессорных системах). К тому же openMosix предоставляет оптимизированную файловую систему (oMFS) для HPC-приложений, которая, в отличие от NFS, поддерживает кэширование, отметки о времени и ссылки.

Миграция процессов. ОpenMosix позволяет запустить процесс на одной машине, а потом обнаружить, что фактически он выполняется на другой машине кластера. Каждый процесс имеет свой собственный UHN, на котором он был создан.

Миграция означает, что процесс разделяется на две части: пользовательскую и системную. Пользовательская часть будет перемещена на другой узел, в то время как системная останется на UHN. Системная часть иногда называется представительским процессом: такой процесс отвечает за разрешение большинства системных вызовов. Задачей же openMosix является поддержка связи между этими двумя процессами.

Файловая система openMosix (oMFS).OMFS является частью openMosix и позволяет обеспечить доступ к удалённым файловым системам кластера точно также, как и к любым другим смонтированным файловым системам. Таким образом, можно, к примеру, файловые системы всех узлов смонтировать в /mfs, и в результате получится, что содержимое /home третьего узла доступно с любой машины в каталоге /mfs/3/home. И Mosix, и openMosix поддерживают кластерную файловую систему MFS с опцией DFSA (Direct File System Access), что позволяет получить доступ ко всем локальным и удалённым файловым системам узлов в Mosix или openMosix кластере.

4. РАЗВОРАЧИВАНИЕ LINUX КЛАСТЕРА НА БАЗЕ OPENMOSIX.

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

Пользовательские утилиты нужны для эффективного использования ядра openMosix. Они нужны для запуска/остановки демона миграции, файловой системы openMosix (MFS), для миграции задач на определённые узлы, а не на любые, и других задач, которые обычно достигаются при помощи старого доброго друга: интерфейса командной строки.

4.1. КОМПИЛЯЦИЯ ЯДРА.

Ядро и патч записываются в директорию /usr/src/, далее выполняется следующее.

cd /usr/src

tar vxjf kernel-source-2.4.19.tar.bz2

ln -s /usr/src/kernel-source-2.4.19 /usr/src/linux

mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20

cd /usr/src/linux-2.4.20

zcat openMosix-2.4.20-2.gz | patch -Np1

Eсли в системе нет zcat:

mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20

cd /usr/src/linux-2.4.20

gunzip openMosix-2.4.20-2.gz

cat openMosix-2.4.20-2 | patch -Np1

Eсли в системе нету cat:

mv /root/openMosix-2.4.20-2.gz /usr/src/linux-2.4.20

cd /usr/src/linux-2.4.20

patch -Np1 < openMosix-2.4.20-2

patch должна сейчас отобразить список пропатченных файлов исходников ядра.

Теперь компилируем это при помощи следующей последовательности действий:

make config

make dep

make dep

make bzImage

make modules

make modules_install

mv /usr/src/linux/arch/i386/boot/bzImage /boot/newkernel

После этого редактируется конфигурационный файл загрузчика, затем компьютер перезагружается. После перезагрузки компьютер является узлом кластера.

4.2 КОНФИГУРАЦИИ КЛАСТЕРА.

Для запуска openMosix, должен быть сконфигурирован файл /etc/openmosix.map, одинаковый на всех узлах. Файл /etc/openmosix.map содержит три, разделённых пробелами, поля:

openMosix-Node_ID IP-адрес(или имя хоста) Размер диапазона

Например, файл /etc/openmosix.map может выглядеть так:

1 192.168.1.1 1

2 192.168.1.2 1

3 192.168.1.3 1

4 192.168.1.4 1

ОpenMosix увеличивает последний байт IP-адреса узла согласно его openMosix-Node_ID. Если используется размер диапазона больше 1, то используются IP-адреса вместо имён хостов.

Если у узла есть более одного сетевого интерфейса, то он может быть сконфигурирован с опцией ALIAS в поле размера диапазона (что равносильно установке размера диапазона в 0), то есть:

1 192.168.1.1 1

2 192.168.1.2 1

3 192.168.1.3 1

4 192.168.1.4 1

4 192.168.10.10 ALIAS

Тут узел с openMosix-Node_ID 4 имеет два сетевых интерфейса (192.168.1.4 + 192.168.10.10), которые оба видны openMosix.

Перед стартом кластера нужно убедиться в том, что запущены одинаковые версии openMosix с одинаковыми конфигурациями на каждом узле кластера!

Запуск openMosix осуществляется утилитой setpe на каждом узле:

setpe -w -f /etc/openmosix.map

Инсталляция завершена: кластер запущен и работает.

4.3. НАСТРОЙКА ФАЙЛОВОЙ СИСТЕМЫ OMFS.

Для поддержки OMFS должна быть включена опция CONFIG_MOSIX_FS в конфигурации ядра. Если текущее ядро было скопировано без этой опции, то нужна перекомпиляция с этой включенной опцией.

Также UID (идентификаторы пользователей) и GID (идентификаторы групп) для всех файловых систем узлов кластера должны быть одинаковыми. Опция ядра CONFIG_MOSIX_DFSA является необязательной, но, конечно же, необходимой, если должна использоваться DFSA. Для того, чтобы смонтировать oMFS на кластере, необходима дополнительная запись на каждом узле в файле /etc/fstab.

а) Со включенной DFSA: mfs_mnt /mfs mfs dfsa=1 0 0

б) С выключенной DFSA: mfs_mnt/mfs mfs dfsa=0 0 0

Синтаксис fstab-записи:

[имя_устройства] [точка_монтирования] mfs defaults 0 0

После монтирования точки монтирования /mfs на каждом узле файловая система любого узла становится доступной через директорию /mfs/openMosix-Node_ID/.

С помощью нескольких символических ссылок все узлы кластера могут получить доступ к одним и тем же данным, например, /work на node1:

на узле node2: ln -s /mfs/1/work /work

на узле node3: ln -s /mfs/1/work /work

на узле node3: ln -s /mfs/1/work /work

Теперь на любом узле вы можете читать/писать из/в /work. Следующие специальные файлы и директории исключаются из доступа через oMFS:

Директория /proc - специальные файлы, которые не являются регулярными файлами, директориями или символическими ссылками (например, исключается /dev/hda1).

Создание ссылок, таких как: ln -s /mfs/1/mfs/1/usr или ln -s /mfs/1/mfs/3/usr, является неправильным.

Следующие системные вызовы поддерживаются без пересылки мигрировавшего процесса (который выполняет этот вызов на удалённом узле) назад на его UHN: read, readv, write, writev, readahead, lseek, llseek, open, creat, close, dup, dup2, fcntl/fcntl64, getdents, getdents64, old_readdir, fsync, fdatasync, chdir, fchdir, getcwd, stat, stat64, newstat, lstat, lstat64, newlstat, fstat, fstat64, newfstat, access, truncate, truncate64, ftruncate, ftruncate64, chmod, chown, chown16, lchown, lchown16, fchmod, fchown, fchown16, utime, utimes, symlink, readlink, mkdir, rmdir, link, unlink, rename.