Создание вычислительного кластера linux

Linux.yaroslavl.ru

2. Как,что и где.

4. Настройка

Теперь после перезапуска mosix ваша машина уже будет работать в кластере, что можно увидеть запустив монитор командой mon. В случае, если вы увидите в мониторе только свою машину или вообще не увидите никого, то, как говорится — надо рыть. Скорее всего у вас ошибка именно в /etc/mosix.map.
Ну вот, увидили, но не победили. Что дальше? А дальше очень просто 🙂 — нужно собрать утилиты для работы с измененным /proc из пакета mproc. В частности в этом пакете идет неплохая модификация top — mtop, в который добавили возможность отображения узла(node), сортировки по узлам, переноса процесса с текущего узла на другой и установления минимальной загрузки процессора узла, после которой процессы начинают мигрировать на другие MOSIX — узлы.
Запускаем mtop, выбираем понравившийся не спящий процесс (рекомендую запустить bzip) и смело давим клавишу «g» на вашей клавиатуре, после чего вводим на запрос PID выбранного в качестве жертвы процесса и затем — номер узла, куда мы хотим его отправить. А уже после этого внимательно посмотрите на результаты, отображаемые командой mon — та машина должна начать брать на себя нагрузку выбранного процесса.
А собственно mtop — в поле #N отображать номер узла, где он выполняется.
Но это еще не все — ведь вам правда не хочется отправлять на другие узлы процессы вручную? Мне не захотелось. У MOSIX есть неплохая встроенная балансировка внутри кластера, которая позволяет более-менее равномерно распределять нагрузку на все узлы. Ну а вот здесь нам придется потрудится. Для начала я расскажу, как сделать тонкую настройку (tune) для двух узлов кластера? в процессе которой MOSIX получает информацию о скоростях процессоров и сети:
Запомните раз и навсегда — tune можно выполнять только в single-mode. Иначе вы либо получите не совсем корректный результат, либо ваша машина может просто зависнуть.
Итак, выполняем tune. После перевода операционной системы в single — mode например командой init 1 или init S запускаем скрипт prep_tune, который поднимет cетевые
интерфейсы и запустит MOSIX. После этого на одной из машин запускаем tune, вводим ему номер другого узла для настройки и ждем результата — утилита должна выдать запрос на ввод шести чисел, полученных от выполнения команды tune -a на другом узле. Собственно операцию придется повторить на другом узле командой tune -a , а результат из шести чисел ввести на первый узел. После подобного тюнинга в вашей системе должен появится файл /etc/overheads, содержащий информацию для MOSIX в виде неких числовых данных. В случае, если по каким-то причинам tune не смог сделать его, просто скопируйте из текущего каталога файл mosix.cost в /etc/overheads. Это поможет ;-).
При тюнинге кластера из более чем двух машин нужно использовать утилиту, которая также поставляется с MOSIX — tune_kernel. Данная утилита позволяет
вам в более простом и привычном виде настроить кластер, ответив на несколько вопросов и проведя тюнинг с двумя машинами кластера.
Кстати, по собственному опыту могу сказать, что при настройке кластера я рекомендую вам не загружать сеть, а наоборот — приостановить все активные операции в локальной сети.

5. Управление кластером

mosctl — контроль над узлом. Позволяет изменять параметры узла — такие, как block, stay, lstay, delay и т.д
Давайте рассмотрим несколько параметров этой утилиты:
stay — позволяет останавливать миграцию процессов на другие узлы с текущей машины. Отменяется параметром nostay или -stay
lstay — запрещает только локальным процессам миграцию, а процессы с других машин могут продолжать это делать. Отменяется параметром nolstay или -lstay.
block — запрещает удаленным/гостевым процессам выполнятся на этом узле. Отменяется параметром noblock или -block.
bring — возвращает обратно все процессы с текущего узла выполняемые на других машинах кластера. Этот параметр может не срабатывать, пока мигрировавший процесс не получит прерывание от системы.
setdelay устанавливает время, после которого процесс начинает мигрировать.
Ведь согласитесь — в случае, если время выполнения процесса меньше секунды смысл переносить его на другие машины сети исчезает. Именно это время и выставляется утилитой mosctl с параметром setdecay. Пример:
mosctl setdecay 1 500 200
устанавливает время перехода на другие узлы 500 миллисекунд в случае, если процесс запущен как slow и 200 милисекунд для fast процессов. Обратите внимание, что параметр slow всегда должен быть больше или равен параметру fast.

mosrun — запускает приложение в кластере. например mosrun -e -j5 make запустит make на 5-ом узле кластера, при этом все его дочерние процессы будут также выполнятся на 5-ом узле. Правда здесь есть один нюанс, при чем довольно существенный:
в случае, если дочерние процессы выполняются быстрее чем установленная утилитой mosctl задержка (delay) то процесс не будет мигрировать на другие узлы кластера. у mosrun еще довольно много различных интересных параметров, но подробно узнать
о них вы сможете из руководства по этой утилите. (man mosrun)

mon — как мы уже знаем, это монитор кластера, который в псевдографическом виде отображает загрузку каждого рабочего узла вашего кластера, количество свободной и занятой памяти узлов и выдает много другой, не менее интересной информации.

mtop — модифицированная для использования на узлах кластера версия команды top. Отображает на экране динамическую информацию о процессах, запущенных на данном узле, и узлах, куда мигрировали ваши процессы.

mps — тоже модифицированная версия команды ps. Добавлено еще одно поле — номер узла, на который мигрировал процесс.

Вот на мой взгляд и все основные утилиты. На самом деле конешно можно обойтись даже без них. Например используя для контроля над кластером /proc/mosix.
Там кроме того, что можно найти основную информацию о настройках узла, процессах запущенных с других узлов и т.д.,а также поменять часть параметров.

6. Эксперементируем.

7. Использование

8. Заключение

В заключение хочу сказать, что в этой статье не рассмотрены все возможности MOSIX, т.к. я просто до них еще не добрался. Если доберусь — ждите продолжения. 🙂

Источник

Кластер? Легко!

Добрый день хабравчане, по роду своей деятельности нередко приходится работать с кластерными решения тех или иных программных продуктов. Но рассказывать о настройках какого либо программного продукта было бы не так информативно, поэтому поискав, и наткнувшись на сайт Юрия (за что ему огромное спасибо), я решил немножко развить эту тему и на конкретном примере посмотреть прирост производительности при вычислении числа Pi в кластерном исполнении.

Итак, у нас в наличии 4 сервера HP, из которых 3 сервера будут объединены в кластер, а один будет консолью управления. На всех серверах будет развернут Linux SLES 10 SP2 и openMPI, также будет организован беспарольный доступ по SSH между консолью и серверами.

Устанавливаем Linux с минимальными настройками системы, необходимые пакеты можно будет доставить позже. Обратим внимание на то, что архитектура компонентов всех узлов кластера должна быть идентична.
Загружаем пакет openMPI на узлы кластера, собираем и устанавливаем их.
./configure
make
make install

После установки openMPI следующим шагом нашей работы будет компиляция программы вычисления числа Pi на каждом узле кластера. Для этого нам понадобится пакет libopencdk, который присутствует в YAST’e и исходный код программы вычисления числа Pi (flops.f). После того как пакет установлен, а программа помещена в ту директорию, которая будет одинакова на всех узлах кластера и узле управления (консоли), приступаем к компиляции программы:
mpif77 flops.f -o flops

Устанавливаем беспарольный доступ по ssh, тут все просто:

1) Заходим на консоль кластера и генерируем rsa-ключ командой:
ssh-keygen -t rsa
2) Копируем публичный ключ консоли (root/.ssh/id_rsa.pub) на все узлы кластера, в моем случае:
scp /root/.ssh/id_rsa.pub server1:/root/.ssh
3) На каждом узле кластера создаем файл доступа:
cat id_rsa.pub >> authorized_keys
Беспарольный доступ готов.

Следующий шаг — формирование файла со списком узлов всех наших кластеров назовем его openmpi.host и положим его в папку с нашей тестовой программой расчета числа Pi. Узлы в файле можно указывать, как по именам, так и просто, по адресам. Например:
192.168.0.1
192.168.0.2
192.168.0.3
Serv1
Serv2
Serv3

Итак, настройка консоли и узлов кластера закончена, переходим к стадии тестирования:

Запускаем программу на 1 сервере, для этого на узле управления запускаем команду:
mpirun -hostfile /var/mpi/openmpi.host -np 1 var/mpi/flops

Где:
–np число узлов кластер используемых при вычислениях.
Calculation time (s) — время вычисления операций.
Cluster speed (MFLOPS) — количество операций с плавающей запятой в секунду.

Получаем следующий результат:

Calculation time = 4.3
Cluster speed = 418 MFLOPS

Добавим еще 1 сервер в кластер:
mpirun -hostfile /var/mpi/openmpi.host -np 2 var/mpi/flops

Получаем следующий результат:
Calculation time = 1.82
Cluster speed = 987 MFLOPS

Добавим последний, 3 сервер в кластер:
mpirun -hostfile /var/mpi/openmpi.host -np 3 var/mpi/flops

Получаем следующий результат:
Calculation time = 1.18
Cluster speed = 1530 MFLOPS

Время вычисления операций (секунды):

Количество операций с плавающей запятой в секунду (MFLOPS):

Проанализировав полученные данные, можно сделать вывод, что при добавлении нового узла в кластер, производительность всей системы в целом возрастает на (1/N) * 100%.

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

UPD: Спасибо за конструктивную критику uMg и 80×86, соответствующие изменения были внесены в статью.

Источник

Кластеры в Linux

Тема данной статьи — параллельные вычисления в Linux. В этой статье рассмотрены общие вопросы по организации кластеров, кластерное программное обеспечение, в частности PVM. В конце статьи вы найдете ссылки на дополнительную литературу по этому вопросу.

Общие сведения о кластерах

Сначала нужно вообще разобраться что же такое кластер. Как правило, кластер состоит из узлов (отдельных компьютеров) и объединяющей их сети. Для построения сети обычно используется технология Fast Ethernet (100Mbit/sec), но в простейшем случае (например, создание кластера в домашних условиях или в демонстративных целях) подойдет и один сегмент Ethernet на 10Mbit/sec.

Обычно кластеры используются научно-исследовательскими организациями для моделирования различного рода задач или проведения сложных расчетов. Цена суперкомпьютеров является недоступной большинства для организаций такого рода, поэтому появилась идея собрать свой «суперкомпьютер» из «подручного материала» — рабочих станций на базе процессоров Intel. Производительность процессоров производства Intel сейчас практически достигла уровня процессоров архитектуры RISC (процессоры Intel включая Pentium III используют архитектуру CISC, а P4 — VLIW).

Собираем свой кластер

Конфигурация узлов кластера зависит от задач, которые они будут выполнять. Если ваша цель — само создание кластера без решения каких-нибудь важных задач, подойдут и старенькие машины с 486-ым процессором (желательно DX2 или DX4). Для решения относительно важных задач подойдут компьютеры с процессорами Pentium II от 400Mhz или Pentium III (от 600Mhz).

Обратите внимание на объем оперативной памяти. В первом случае (486/демонстрация работы кластера) достаточным будет 16-32MB (желательно). Во втором — минимум 64Мб, рекомендуется 128Мб ОЗУ.
При использовании многопроцессорных машин объем ОЗУ желательно увеличить до уровня Nx64Mb, где N — это количество процессоров, то есть по 64Мб на каждый процессор. Обычно используются двухпроцессорные машины — в этом случае минимальный объем ОЗУ будет равен 126Мб, а рекомендуемый — 128Мб.

Один компьютер (узел) будет центральным. Желательно, чтобы он был более мощным, чем остальные узлы кластера. На нем нужно установить более мощный процессор, в два раза большим объем оперативной памяти, чем на остальных узлах (минимум 128Мб). Желательно на центральном компьютере использовать SCSI-диск, но подойдет и ATA133 / 7200 rpm. Лучше поставить быстрый SCSI, а на узлах вообще отказаться от жесткого диска — так будет дешевле. Все эти требования — желательные, но не обязательные.

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

Теперь поговорим о сети. Как я уже писал, желательно использовать Fast Ethernet. Если количество узлов довольно велико (от 20), для уменьшения коллизий необходимо разбить на отдельные сегменты или использовать для их соединения коммутатор (swith), а не повторитель (hub).
В некоторых случаях имеет смысл разбить сеть на сегменты даже при небольшом числе узлов (от 8), например, если вы используете Ethernet (10Mbit/sec).

При использовании Ethernet отказываться от жестких дисков не рекомендуется: кластер будет работать ужасно медленно, будет возникать огромное число коллизий.
Одним из самых эффективных решений для связи узлов кластера является использование 1.28GBit-ных коммутаторов Myrinet. Также можно использовать технологию Gigabit Ethernet.

Программное обеспечение

В качестве операционных систем можно использовать:

1. Linux
2. FreeBSD
3. Windows NT

Предпочтительнее использовать любую Unix-систему, так как именно эти операционные системы наиболее эффективнее используют сетевые ресурсы. Оптимальным решением является операционная система Linux — она бесплатна и довольно проста в настройке.

Можно использовать любую Linux-систему с версией ядра 2.2.* и выше. Я бы порекомендовал использовать шестую версию Linux RedHat, так как она нетребовательна к системным ресурсам (минимальная конфигурация — 486 33Mhz/8MB RAM/120MB HDD) и в состав дистрибутива входит относительно новое программное обеспечение по сравнению с версией 5.2, которую также можно использовать для построения кластера. Версия ядра, используемая этим дистрибутивом (RH 6), 2.2.5-15.

После установки и настройки (настройки сети) операционной системы нужно установить специальные компиляторы. Дело в том, что бесплатно распространяемые компиляторы gcc/g77/egcs не обеспечивают необходимого уровня оптимизации программ для процессоров Intel (PII, PIII). Рекомендуется использовать коммерческие компиляторы, например, входящие в проект PGI Workstation.
При использовании Windows NT как операционной системы кластера можно также выбрать компилятор компании Intel, оптимизированный для платформы Intel. Ознакомиться с этим компилятором вы можете на сайте http://developer.intel.com/ .

В первом и во втором случае доступны тестовые версии компиляторов. Shareware-версию пакета PGI вы можете скачать на сайте PGI Group — http://www.pgroup.com/register_home.html . А тестовую (14 дней) версию компилятора Intel можно скачать на сайте Intel.

После установки компиляторов нужно установить среду распределения задач. В этой статье я опишу работу со средой PVM, хотя доступны и другие средства — MPI , Condor .

MPI CHameleon представляет собой реализацию промышленного стандарта MPI 1.1. MPI CHameleon позволяет программам выполнятся внутри локальной системы или на сетевом кластере с использованием TCP-соединений.
Среда Condor обеспечивает равномерную нагрузку на кластер путем миграции процессов между несколькими машинами.

Я выбрал более простой вариант — PVM (Parallel Virtual Machine). PVM обеспечивает условия для выполнения одной (или нескольких — в большинстве случаем) задач на нескольких машинах. Другими словами PVM просто распределяет процессы на узлах кластера также как планировщик заданий операционной системы распределяет процессорное время для выполнения нескольких задач.
PVM может работать на следующих архитектурах:

Это дадеко не все архитектуры, которые поддерживает PVM. Список всех доступных архитектур вы найдете в документации pvm. Интересующие нас (точнее, доступные нам) архитектуры выделены жирным шрифтом.

Работа с «параллельной машиной» довольно проста. Нужно установить ее на всех машинах кластера. Мой «кластер» состоял из двух машин класса Pentium (100 и 150Mhz) с объемом ОЗУ по 32Мб и одной (центральной) Celeron 433 (128Mb). От сетевой загрузки я отказался из-за использование 10Mbit-го Ethernet’a. К тому же на всех узлах уже были установлены жесткие диски. На центральном была установлена ОС Linux Mandrake 7, а на вспомогательных машинах Linux RedHat 6.0 Hedwig. Я не устанавливал каких-нибудь коммерческих комплиляторов, а использовал те, которые входят в состав дистрибутива.
Кстати, PVM может работать и на платформе Windows 9x, но вот этого не рекомендую делать. Ради интереса я установил PVM для Windows 98. Скорость работы даже тестовых приложений (не говоря уже о реальных расчетах) была значительно ниже. То, что кластер работает медленнее было видно даже «невооруженным глазом». Скорее всего, это объясняется неэффективной работой Windows с сетью. К тому же, довольно часто весь кластер «зависал» даже при выполнении тестовых задач, которые входят в состав пакета PVM.

Использование PVM

PVM компилируется с помощью привычной тройки команды:
configure; make; make install

Перед запуском make установите переменную окружения PVM_ROOT. В этой переменной окружения нужно указать каталог, в котором находятся каталоги PVM (например, $HOME/pvm, если вы распаковали архив в свой домашний каталог). Еще одной важной переменной окружения является PVM_ARCH. В ней содержится название архитектуры операционной системы. Данная переменная должна устанавливаться автоматически, но если этого не произошло (как в моем случае), нужно установить архитектуру самостоятельно. При использовании Linux эта переменная должна содержать значение LINUX.

Как я уже писал, нужно установить PVM на всех узлах кластера. Вся параллельная машина состоит из демона pvmd и консоли pvm. Назначение опций запуска демона можно узнать, выполнив команду man pvmd. На центральной машине нужно запустить демон pvmd и выполнить команду:
pvm
Этим мы запустим консоль, с помощью которой мы будем управлять всем кластером.

После запуска консоли вы должны увидеть приглашение, которое свидетельствует о том, что кластер готов к работе:
pvm >
Введите команду conf для печати конфигурации кластера. Вы должны увидеть примерно это:
Листинг 1.
Из листинга 1 видно, что сейчас наш кластер состоит из одной машины — центрального узла, который работает под управлением Linux. Теперь самое время добавить в наш кластер еще два узла. Добавление узлов осуществляется с помощью команды:
add hostname
После успешного добавления узла в кластер он должен быть отображен в списке узлов кластера. Теперь уже можно запускать программы, которые поддерживают PVM. Примеры таких программ вы можете найти в каталоге $PVM_ROOT/bin/$PVM_ARCH/. В нашем случае это будет каталог /root/pvm/bin/LINUX (я установил pvm в каталог /root). Для начала запустим самую простую программу — hello. Прежде чем запустить ее, нужно сделать несколько замечаний:

1. Вы не можете запускать процессы прямо из консоли pvm. Консоль служит лишь для управления кластером.
2. Запуск задачи осуществляется обычным способом — из консоли операционной системы. Но «распараллеливаться» будут лишь те процессы, которые поддерживают pvm. С помощью команды spawn также можно породить задачу (см. ниже)

При запуске hello вы должны увидеть сообщение
hello, world from hostname ,
где hostname — это узел кластера. Другими словами все узлы кластера должны поприветствовать вас.

Более интересной является программа gexample. После запуска нужно ввести два аргумента: n и число процессоров. Не вдаваясь в математические подробности, она рассчитывает сумму от 1 до n и факториал числа n. Второй аргумент определяет количество процессоров, которые будут задействованы в вычислении. В нашем случае второй аргумент равен трем. Просмотреть список всех задач можно с помощью команды ps -a. Эту команду нужно вводить в консоли pvm, а не в консоли операционной системы! Породить задачу можно также с помощью команды spawn, которая подробно рассмотрена ниже. Назначение всех команд консоли pvm представлено в таблице 1.

Таблица 1.

Команда	Описание
add hostname	Добавляет узел в кластер
alias	Определяет псевдоним для команды
conf	Выводит текущую конфигурацию кластера
delete hostname	Удаляет узел из кластера
halt	Останавливает кластер (точнее завершает процесс pvmd — узлы при этом не выключаются, а продолжают работать)
help [command]	Выводит список всех команд или краткую справку по указанной команде
id	Выводит идентификатор процесса pvm (консоли)
jobs	Выводит список выполняемых задач
kill TID (task id)	«Убивает» задачу
mstat host, tid	Показывает состояние узлов
ps -a	Выводит список всех задач параллельной машины
pstat task-tid	Показывает состояние задачи
quit	Выход из консоли pvm
reset	Сброс — завершаются все задачи
setenv	Отображает или устанавливает переменные окружения
sig signum task	Посылает сигнал задаче
spawn [opt] a.out	Порождает задачу. Об этой команде мы поговорим подробнее после этой таблицы.
trace	Устанавливает/отображает маску трассировки событий. Более подробное объяснение вы найдете в документации.
unalias	Удаляет ранее созданный псевдоним команды
version	Отображает версию библиотеки libpvm

В таблице 1 я описал не все команды консоли pvm, обо всех остальных мы можете прочитать, введя команду man pvm.
Теперь рассмотрим некоторые команды подробнее. Начнем с самой простой — alias. С ее помощью можно определить псевдонимы для часто используемых команд, например
alias ? help
Теперь вместо команды help вы можете просто вводить ?

Команда id выводит идентификатор консоли pvm:

Команда mstat отображает состояние узла, например:

Подобно привычной нам команде ps, команда консоли pvm ps -a также используется для отображения всех выполняемых параллельной машиной задач:

Команда pstat выводит состояние задачи:

Вот теперь мы подошли к одной из самых интересных команд — spawn. Данная команда порождает задачу. С ее помощью можно указать некоторые параметры задачи, например, узел, на котором она должна выполняться.
spawn [opt] a.out
a.out — любой исполнимый бинарный файл — программа, которая даже не поддерживает библиотеку libpvm. Для таких программ также можно указать, на какой машине она будет выполняться. В среде Windows параметр a.out — это exe или com — файл.
Можно указать такие параметры команды spawn:

Таблица 2.

Параметр	Описание
-(count)	Число задач. По умолчанию — 1.
-(host)	Определяет узел, на котором будет выполняться задача
-(ARCH)	Задает архитектуру узлов, на которых будет выполняться задача.
-?	Включает отладку (debugging)
->	Перенаправляет стандартный вывод задачи на консоль
->file (*)	Перенаправляет стандартный вывод задачи в файл
->>file (*)	Дописывает стандартный вывод задачи в файл

(*) после знака > не должно быть пробела!

На этом я завершаю эту небольшую статью о Linux-кластерах. В следующих статьях мы поговорим о других кластерных проектах, в которых используется операционная система Linux. Список дополнительной литературы вы найдете ниже. Если что-нибудь непонятно, пишите — с удовольствием выслушаю ваши вопросы и комментарии, да и команду man тоже никто не отменял.

Источник