или делаем кластер в домашних условиях.
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
