Работать на одной машине уже не модно
или делаем кластер в домашних условиях.

1. Введение

Многие из вас имеют в локальной сети несколько Linux машин, с практически всегда свободным процессором. Также многие слышали о системах, в которых машины объеденяются в один суперкомпьютер. Но реально мало кто пробовал проводить такие эксперименты у себя на работе или дома. Давайте попробуем вместе собрать небольшой кластер. Построив кластер вы сможете реально ускорить выполнение части задач. Например компиляцию или одновременную работу нескольких ресурсоемких процессов. В этой статье я постараюсь рассказать вам как можно без особых усилий объеденить машины своей локальной сети в единый кластер на базе MOSIX.

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

MOSIX - это патч для ядра Linux с комплектом утилит, который позволяет процессам с вашей машины переходить (мигрировать) на другие узлы локальной сети. Взять его можно по адресу HTTP://www.mosix.cs.huji.ac.il а распространяется он в исходных кодах под лицензией GPL. Патчи существуют для всех ядер из стабильной ветки Linux.

3. Установка программного обеспечения.

В начале установки хочу порекомендовать вам забирать с узла MOSIX не только его, но и сопутствующие утилиты - mproc, mexec и др.
В архиве MOSIX есть установочный скрипт mosix_install. Не забудьте в обязательном порядке распаковать исходные коды ядра в /usr/src/linux-*.*.*, например как сделал я - в /usr/src/linux-2.2.13 далее запускаете mosix_install и отвечаете на все его вопросы, указав ему свой менеджер загрузки (LILO), путь к исходникам ядра и уровни запуска.
При настройке ядра включите опции CONFIG_MOSIX, CONFIG_BINFMT_ELF и CONFIG_PROC_FS. Все эти опции подробно описаны в руководстве по установке MOSIX.
Установили? Ну что же - перегружайте ваш Linux с новым ядром, название которого очень будет похоже на mosix-2.2.13.

4. Настройка

Изначально установленный MOSIX совершенно не знает, какие у вас машины в сети и с кем ему соеденятся. Ну а настраивается это очень просто. Если вы только поставили mosix и если ваш дистрибутив - SuSE или RedHat - совместимый, то заходите в каталог /etc/rc.d/init.d и давайте команду mosix start. При первом запуске этот скрипт просит вас настроить MOSIX и запускает текстовый редактор для создания файла /etc/mosix.map, в котором находится список узлов вашего кластера. Туда прописываем: в случае, если у вас всего две-три машины и их IP-адреса следуют
друг за другом по номерации пишем так:

Номер узла IP количество узлов с текущего
______________________________________
1 10.152.1.1 5

Где первый параметр обозначает номер начального узла, второй - IP адрес первого узла и последний - количество узлов с текущего. Т.е. сейчас у нас в кластере олучается пять узлов, IP адреса который заканчиваются на 1, 2, 3, 4 и 5.
Или другой пример:

Номер узла      IP      количество узлов с текущего
______________________________________
1       10.152.1.1      1
2       10.150.1.55     2
4       10.150.1.223    1

В этой конфигурации мы получим следующий расклад:
IP 1-ого узла 10.150.1.1
IP 2-ого узла 10.150.1.55
IP 3-ого узла 10.150.1.56
IP 4-ого узла 10.150.1.223
Теперь нужно на всех машинах будущего кластера установить MOSIX и создать везде одинаковый конфигурационный файл /etc/mosix.map .

Теперь после перезапуска 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. Эксперементируем.

    К сожалению, мне не удалось заставить выполнятся какой-то один процесс одновременно на нескольких узлах. Максимум, чего я достиг в процессе экспериментов с кластером-использование для выполнения ресурсоемких процессов на другом узле.
    Давайте рассмотрим один из примеров:
Допустим, что у нас в кластере работают две машины (два узла), один из которых с номером 1 (366 Celeron), другой - с номером 5(PIII450). Экспериментировать мы будем на 5-ом узле. 1-й узел в это время простаивал. ;-)
    Итак, запускаем на 5-м узле утилиту crark для подбора пароля к rar архиву.Если кто из вас пробовал работать с подобными утилитами, то он должен знать, что процесс подбора пароля "кушает" до 99 процентов процессора. Ну что же - после запуска мы наблюдаем, что процесс остается на этом, 5-ом узле. Разумно - ведь именно у этого узла производительность превышает 1-й узел почти в два раза.
Далее мы просто запустили сборку kde 2.0. Смотрим таблицу процессов и видим, что crark успешно мигрировал на 1-й узел, освободив процессор и память (да, да - память точно также освобождается) для make. А как только make закончил свою работу - crark вернулся обратно, на родной ему 5-й узел.
Интересный эффект получается, если crark запускать на более медленном 1-м узле.
Там мы наблюдаем практически противоположный результат - процесс сразу-же мигрирует на 5-й, более быстрый узел. При этом он возвращается обратно, когда хозяин пятого компьютера начинает какие-то действия с системой.

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

Давайте в конце разберемся, зачем и как мы можем использовать кластер в своей повседневной жизни.
Для начала нужно раз и навсегда запомнить - кластер выгоден только в том случае, когда в вашей сети есть энное количество машин, которые частенько простаивают и вы хотите использовать их ресурсы например для сборки KDE или для любых серьезных процессов. Ведь благодаря кластеру из 10 машин можно одновременно
компилировать до 10 тяжелых программ на том-же C++. Или подбирать какой-то пароль,
не прекращая ни на секунду этого процесса независимо от нагрузки на ваш компьютер.
Да и вообще - это просто интересно ;-).

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

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

Anton Farygin aka Rider
29.12.1999г
http://linux.ru.net