Mosix 1.0 для Linux 2.4

интересно, если поставить это как сервер для X терминалов, будет жизнеспособно? на офисных задачах особенно?

Для X-терминалов есть chooser, зачем же тут кластер?

>Для X-терминалов есть chooser, зачем же тут кластер?

можно подробнее?

Если в двух словах, то есть XDM (X Display Manager), который занимается раздачей X-host'ов X-терминалам, а при помощи chooser'а на X-терминал выводится менюха, предлагающая выбрать X-host из имеющихся в наличии.

2Oxonian: В Иерусалимском Университете ( там где зародился Мозикс, до
того как Амнон Барак и Моше Бар выкупили проект у университета )
на одном!! кластере Мозикса работали сотни студентов.

Там правда, был установлен предшественник Мозикса для БСД - "Амос".

На сегодняшний день в университете есть 2 кластера - "Амос" для студентов и Мозикс кластер для Исследований и Разработок.

Моше Бар использует Мозикс дома ( www.moelabs.org )

На офисных задачах... Мозикс ,в отличие от Беовульфа, не требует портирования ПО, и умеет делать load balansing для обычных аппликаций.

Технология process migration и clustered file system работают очень хорошо.

> Для X-терминалов есть chooser, зачем же тут кластер?
очевидно - для бОльшего числа пользователей

Однако, для числодробильных задач такой "кластер" абсолютно неприменим. Тут требуется ручное разпараллеливание, на PVM3 или MPI.

> На офисных задачах... Мозикс ,в отличие от Беовульфа, не требует
> портирования ПО, и умеет делать load balansing для обычных аппликаций.
ну собственно, что и вопрошалось. Beowolf - вычислительный кластер и мало подходит для применения "как очень большой компьютер".

я в общем прочитал, что есть на сайте. невыясненным осталось две вещи - можно ли на этом построить территориально разнесенный кластер (они там ethernet предлагают применять непонятно по каким соображениям - я так понимаю это можно заменить ATM) и есть ли возможность перестартовать задачу на другом узле кластера в случае повисания того, на котором она выполнялась? (опять же, понятно что это можно руками сделать, но поддержка такого watchdog была бы полезнее "внутри" системы).

> Технология process migration и clustered file system работают очень хорошо.
это на личном опыте? можно тогда как-то ознакомится?

>>Планировщик процессов Mosix автоматически распределяет процессы по узлам кластера для его наиболее эффективного использования.

Мне кажется, что немного не так. Я только что его ставил смотрел. Правда кластер был из двух машин всего :)) Мне показалось, что он даже одну задачу пытается выполнять на нескольких машинах. Во всяком случае это следует из показаний его проги "mon".

Умная штука. Такой пример.

Если процесс требует интенсивной передачи данных, а сеть с нагрузкой не справляется в силу особенностей (Ethernet), он выполняет этот процесс на локальной машине, даже если ему сказать например runon 2 make.

Если же процесс занимается интенсивными вычислениями, а данных ганяет мало, он нормально распределяется по кластеру.

Мозилла чего то не запускалась, а вот нетшкаф - все пучком.

Еще make ничем не отличался от make -j2 например.

Немного станный у него mosix.map, а так ничего. Прикольно. Где его только использовать можно мне не совсем ясно.

> Однако, для числодробильных задач такой "кластер" абсолютно
> неприменим. Тут требуется ручное разпараллеливание, на PVM3 или MPI.
вопрос как раз в применении Mosix для задач общего назначения

to Banshee (*) (2001-05-06 14:54:43.0) Поделись впечатлениями на тему что будет, если одну из машин убрать на горячую, (выдернуть сетевой шнурок например). Что при этом произойдет с процессами, например с тем же нетшкафом. еще вопрос, сквид как себя чувствует, если он действительно сумеет распаралелить поиск в кеше то это было бы здорово.

Я пробовал MOSIX на университетском кластере (14 узлов, FastEthernet).
Даже патчи на него писал ;)
По поводу обрыва связи -- если вырубить машину (у нас такое случалось,
когда под нагрузкой ложился этот хренов OfficeConnect) то все процессы
которые были смигрированы на другие узлы становятся, естественно dead.
Но в целом кластер сам по себе не падает. Есть возможность вывести из
работы машину -- достаточно непольших пассов с /proc/чегототам, чтобы
все процессы с нее оперативно съехали. Так-же можно заставить процессы
собраться обратно на машину с которой все это было запущено.
Что приятно, все машины взаимно независимы и процессы вобще могут
ничего не знать о том, что их куда-то мигрировали.
Что неприятно (по этой причине я и перестал его использовать),
большинство системных вызовов должны выполняться всетаки "на родине",
а некоторые из них даже приводят к миграции процесса домой :(
С введением "виртуальной" FS и "мигрирующий сокетов" оно вроде как
должно стать полегче, но к тому времени как оно стало хоть немного
стабильно, все наши программы (а кластер используется только как
числодробилка) уже хорошо раобтали и при статическом разбиении, по
этому более новые версии я не тестировал :(
P.S. по поводу ATM -- я думаю будет работать на всем, на чем ходит IP.
Pasha.K

> Технология process migration и clustered file system работают очень хорошо.
это на личном опыте? можно тогда как-то ознакомится?

Это из долгих бесед с одним из разработчиков и наблюдения за кластерами в huji.

Если я правильно понял - достаточно использовать fork для распределения вычислений? И вопрос еще один - у "кластера" есть свой IP адрес? то есть он может работать к один компьютер для внешних компьютеров.

Насчет make для mosix - вроде бы есть програмка mosixmake или что-то в этом духе.

> еще вопрос, сквид как себя чувствует, если он действительно сумеет распаралелить поиск в кеше то это было бы здорово.

ifconfig, ты опять не в кассу попал. Во-первых, в сам по себе squid заложена возможность создавать кластер из кешей (sibling/parent), а во вторых mosix не занимается распараллеливанием процессов, он только распределяет процессы по узлам. Потому большой и толстый single-threaded shquid так и будет жить на одном узле в одном процессе.

to maxcom. возможность parent/sibling это известно, вот тока алгоритм работы сего видать ты не потрудился изучить. Это позволяет строить иерархию кешей но ни вкоей мере не убыстряет скорость работы самого кеша. т.е кеши работают последовательно а не паралельно. А насчет "не в кассу" это ты зря, не уподобляйся РУТУ...

2eda: У кластера столько IP, сколько в нем узлов ;)
Можно форкаться на любом узле и процессы поползут туда, где жизнь
легче ;)
При этом они совершенно об этом знать не будут.

Pasha.K

Скажите, так можно ли использовать mosix для построения кластеров, который будет заниматься только "числодроблением", или для этого есть что-то другое. И возможна ли полноценая работа на таком кластере, скажем полгода, без перезагрузки на 10Mb сетке.

Ой, только не надо про полгода для числодробилки, там это ну совсем
ни к чему. Правда если у вас есть задача, которая будет считать
полгода + полное отсутствие механизмов восстановления, то... ;)
А самое разумное применение mosix в числодробилке -- это если задача
не позволяе заранее планировать объем вычислений для каждой своей
части (мы же параллельную программу пишем, да ?). Тогда режем ее на
большее (желателно кратное) кол-во частей чем у нас есть процессоров и
запускаем все это в свободное плавание на mosix-кластере. При этом
если один из процессов начнет тормозить работу (ну, там сетка у него
измельчилась, точность урезалась, или что там в задаче может быть), то
система справится с этим самостоятельно, просто с узла где этот вредный
процесс работает, часть процессов по быстрому съедет, освобождая
ресурсы. Если у вас самосогласованная задача (а иначе зачем вам
кластер ?), то считаться она будет со скоростью самого медленного
процесса. Помноженной на кол-во узлов правда ;)
Mosix просто позволяет без особых напрягов мозговой мышцы организовать
балансировку нагрузки. Что не отменяет правда того факта, что ручная
оптимизация все равно рулит ;)

Pasha.K

Для числодробилки лучше пускать кластер по типу beowulf с MPI или чем-то подобным.