Закрытие OpenMOSIX.

Линукс-капец?

Петицию против уже создали?

Многоядерные процессоры все-равно не смогут заменить тысячи и тысячи соединных друг с другом компьютеров. Жалко ;(

и чего, им никто не пользуется что ли ?

ClosedMOSIX

>и чего, им никто не пользуется что ли ?

Если кому-то надо - всегда можно форкнуть, благо лицензия GPL.

Очень жаль :(

RIP... Грустно... Весьма приятный был проект... Хотя, пожалуй, форк будет...

=(

Столь милое моему слуху имя "Моше" ("для своих я - Мойша", как говорил мой старенький дедуля в Хайфе") навевает мысли о свершившемся маленьком гешефте. А в силу тенденции M$ скупать и контрактить всех подряд, да ещё и с необходимостью всеми силами толкать "свисту кластер едишен" (хотя оно и так... для кластеров... епт) - это __очень, очень подозрительно__!

Прочитал "Закрытие..." и подумал, что OpenMOSIX собрались выпускать под закрытой лицензией. А он просто дуба врезал?

Действительно жалко. Много ядер на одном крестале это конечно гуд, но... связь с проектом не очевидна. IMHO

Опс, Линуксу капец!

>мнгоядерные процессоры.

Не осилили что-ли? Кстати, поправьте новость.

> OpenMOSIX является расширением ядра Linux, позволяющее запускать единый образ системы в распределенном окружении

А первопричина и вовсе в том что есть дешёвые многоядерные процессоры которые работают на SMP-ядрах версии 2.6, предлагаемая-же OpenMosix - для одноядерного ядра 2.4.

брррр... однопроцессорного...

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

Вывод - оно нам не надо, проект тупиковый, что поняли и эти товарищи.

Десятки тысяч? Покажите хоть где сотня используется!

Жаль. :-(

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

Кстати, совершенно зря!

Действительно, _сейчас_ NUMAподобные SMP решения на многоядерных процессорах дешевле и лучше кластерных, но еще пару лет назад все было наоборот. Никто не знает, что будет еще через несколько лет -- вполне возможно, что InfiniBand доведут до ума, как давно обещали...

ИМХО Причина какая-то не убедительная. Многоядерным процессорам не сравнится с кластерами. Ни по производительности, ни по цене. Или имеется ввиду,что трудно поддерживать кластеры из многоядерных систем?

>Из своих наблюдений - требуется гигабитная сетка, чтобы это более менее работало, иначе смысла в этом нет. На сотке прирост в производительности порядка 10 процентов при полной загруженной сетке.

>Вывод - оно нам не надо, проект тупиковый, что поняли и эти товарищи.

Гм.., затестил на 100мегабитке и сразу в тупиковые проекты..
Сразу бы купил гиговые ланки и кабель хороший дабы юзать это в полную мощь и не плакаца..

Кста - на всех форумаю, доках по проекту везде пишется, что ниже гиговых юзать что-то нет смысла..

зачем нужен этот OpenMOSIX, если есть тру версия на www.mosix.org?

Зачем это нужно, если есть plan9, в котором распределённость (в виде файлов) с точки зрения апликухи - одно удоволствие?

>Moshe Bar, лидер и основатель проекта, объявил о закрытии пректа 1 марта 2008 года. Списки рассылки будут закрыты в декабре 2007. Одной из основных причин называют мнгоядерные процессоры.

Нет не это.. проект попросту загнулся, а поддержка Линукса остановилась на ветке 2.4.х, потом они вновь продолжили, но ппц как не поспевают за выходами новых версий ядра, плюс портирование 2.4.х -> 2.6 у них идет очень тяжко..

Кста я этого Моше Бара видел, он приезжал преподавать у нас в универе кластерные вычисления, также приезжал проф. Амнон Барак (основатель оригинального MOSIX'a) тоже это же преподавал.. нам хотелось посмотреть на точки зрения 2-х людей. У Моше Бара точка зрения жирнее, выше, сильнее, но как оказалось терпения её не хватило..

>зачем нужен этот OpenMOSIX, если есть тру версия на www.mosix.org?

AFAIK это была попытка аспиранта (Бара) форкнуть проект профессора (Барака). Видимо ниасилил.

Кстати профессорский вариант уже умеет мигрировать сокеты (раньше только пайпы) и поддерживает до 32 процессоров(ядер) в одном узле

Как сделают поддержку x86_64 и IB можно будет пробовать в реальных приложениях.

Кстати где сейчас Барак работает ? Я слышал что в Австралии где то.

Да не будет линуксу капец. Если решили закрыть проект, значит либо действительно он нерациональный, либо они прочухали, что скоро что-то революционно-новое появится.

Кстати, имхо *BSD - родные братья линуксу, а наверняка в одной из них есть поддержка кластеров...

Так что вендекапец в любом случае - вантуз кластеры вообще ниасилит

mosix мало полезная, с умом вполне обходимая, и наконец никак не тянущая на enterprise, несмотря на все уважение к авторам.

>mosix мало полезная, с умом вполне обходимая, и наконец никак не тянущая на enterprise

Кому малополезная ? С каким умом куда обходимая ? В лес ? Про ентерпрайс воопще не понятно что имелось ввиду.

Короче Ваш камент я ниасилил ...

наверное всётаки Мойше Бар чуть чуть умнее тебя;) как думаешь?

>наверное всётаки Мойше Бар чуть чуть умнее тебя;) как думаешь?

нет, он просто неасилил проект.. трудности перехода 2.4.х -> 2.6, плюс новые версии 2.6-го выходят часто, они не успевают что-то адаптировать

> вполне возможно, что InfiniBand доведут до ума

Хотелось бы попробовать эту технологию, тем более начальство просит организовать "учебный" кластер. Что для этого надо купить (пожалуйста, с указанием конкретных моделей оборудования и примерных цен)?

Мы тестировали OpenMosix в 2004 году (для создания кластера из 50 машин для обсчета молекулярной динамики). Оказалось, что это по большей части тупиковый путь.

Для пользователя кластер Mosix выглядит как одна очень многопроцессорная машина. Однако, нельзя запустить процесс так, чтобы несколько потоков работали на разных узлах - это никакой InfiniBand не хватит для обеспечения когерентности.

Из важных фич Mosix предоставляет только возможности удобной коммуникации приложений и миграции процессов на незагруженые узлы. На практике, незагруженых узлов почти не бывает, так что миграция имеет очень ограниченую ценность. А проблема с коммуникациями решается с помощью MPI, который замечательно работает напрямую через InfiniBand с минимальным overhead'ом.

Кстати, в OpenMosix при миграции процесса данные сокетов должны пересылаться через старую машину. Простых решений для этого я не видел. Так что для High Availability тоже не очень-то Mosix подходит.

В общем, все это реально ограничивает кластеры Mosix'а где-то десятками машин. Купить 16-ядерную машину (4 четырехядерных процессора) скоро можно будет чуть ли не в любом магазине. Шестнадцатиядерные процессоры обещают где-то к 2010. Так что решение автора вполне понятно.

Ну а там где SMP не подходит - применяют специализированые кластеры.

У нас OpenMOSIX используется на небольшом 4-нодовом кластере с гигабитной сеткой. Ставили на "посмотреть" да так и оставили. Крутятся там Ansys да Matlab.

Особенного прироста производительности в сравнении с обычным SMP нет, так что, имхо, проект действительно свое отжил.

>Хотелось бы попробовать эту технологию, тем более начальство просит организовать "учебный" кластер. Что для этого надо купить (пожалуйста, с указанием конкретных моделей оборудования и примерных цен)?

1)HCA (host controller adapter) - грубо говоря сетевая карта - от $700 .. цены мугут сильно менятся от характеристик и производителя. Основные производители Mellanox, Qlogic, Voltaire,...

2)IB switch. Меньше чем на 24 порта не видел.От $4000 и сильно вверх., производители - Qlogic, Mellanox, Cisco, Flextronics, ...

3) IB кабеля 0.5 метра - $70 ... длиннее 15 метров не бывает

Оборудование бывает 1x(наверное уже устарело),4x(наиболее распространённое),12x и каждое из них соответственно бывает SDR - single data rate DDR - double data rate

Для примера 4x SDR на MPI в реальных приложениях даёт полосу пропускания (реально измеряемую) в 800 Мbyte/sec и задержки на уровне 4-5 мкс

Хех, с таким железом никакой *mosix не нужен.

>Хех, с таким железом никакой *mosix не нужен.

Не скажи. Мне иногда в Torque сильно не хватает мозиксовых фич с балансировкой нагрузки. Сейчас из за этого приходится пререписывать софтину чтобы перенести функции балансировки непосредственно в приложение. Раньше это тупо делал mosix.

AEP (*) (17.07.2007 10:54:45)

>> вполне возможно, что InfiniBand доведут до ума

> Хотелось бы попробовать эту технологию,...

sS более-менее подробно на этот вопрос ответил.

От себя добавлю: в Европе и Америке InfiniBand предоставляют "из коробки" большинство вендоров, торгующих кластерными решениями; большинство Линуховых дистрибутивов сейчас поддерживают InfiniBand тоже "из коробки". К сожалению, у приложений (особенно критично для MPI) имеется тенденция вместо RDMA (Remote Direct Memory Access) использовать более тяжелые протоколы, вплоть до TCP/IP over IB. Часто, например, LAM по умолчанию именно на TCP/IP настроен, хотя он давно уже умеет длинные сообщения по RDMA гонять.

По моим наблюдениям, IB не готова для больших (более сотни узлов) кластеров. Главная причина -- отсутствие динамической балансировки (маршрутизации). И стабильности пока не хватает. Но для небольших кластеров (до 24 узлов) оно очень даже юзабельно, особенно если ручками покрутить, ощутимо получше гигабитного Ethernetа, хотя и не в десятки раз, как должно было бы быть. Но по сравнению с, например, QsNET, значительно примитивнее (но гораздо дешевле).

>в Европе и Америке InfiniBand предоставляют "из коробки" большинство вендоров, торгующих кластерными решениями

У нас тоже.

>большинство Линуховых дистрибутивов сейчас поддерживают InfiniBand тоже "из коробки"

Но не в том объёме как хотелось бы. Ту же поддержку RDMA мне пришлось тащить с openfabrics.org благо оно всё действительно open.

>LAM по умолчанию именно на TCP/IP настроен, хотя он давно уже умеет длинные сообщения по RDMA гонять

Есть MVAPICH который специально для IB сделан.

>По моим наблюдениям, IB не готова для больших (более сотни узлов) кластеров

Делают и больше но там специальные (как правило заказные) коммутаторы. Вендоры же делают _коробочные_ коммутаторы до 144 портов (может быть уже и больше)

>Главная причина -- отсутствие динамической балансировки (маршрутизации)

Есть такое дело.

>хотя и не в десятки раз, как должно было бы быть

Но около того. Проверял netperf-ом. А по задержкам во все 30.

>И стабильности пока не хватает

А что у вас за проблемы со стабильностью ?

Да, забыл уточнить.

IB HCA втыкают либо в PCI-X либо в PCI-E

sS:

>>По моим наблюдениям, IB не готова для больших (более сотни узлов) кластеров

>Делают и больше но там специальные (как правило заказные) коммутаторы. Вендоры же делают _коробочные_ коммутаторы до 144 портов (может быть уже и больше)

Плохо оно работает. Я по долгу службы много тестировал некую софтину на разных кластерах, постоянно проблемы с IB. Особенно на нагруженных кластерах, когда мне выделяют пару десятков нод в эксклюзив, а на других продолжаются рассчеты -- IB иногда вообще проседает...

>>хотя и не в десятки раз, как должно было бы быть

> Но около того. Проверял netperf-ом.

Ну да, пинг-понг на пустом кластере 1.5GB/s при 3-4 ms задержки, знаю... Но в реальной работе средние показатели оказываются во много раз меньше.

>>И стабильности пока не хватает

> А что у вас за проблемы со стабильностью ?

Как-то отваливается иногда... Например, основной инструмент для одной задачи у нас сейчас около1000нодный кластер на 3000 вычислительных корок, DDR 4x IB. Параллельные задачи с более чем 14 процессами стабильно дохнут...

Кроме того, DDR чуть ли не полгода поднимали, не сами -- спецы из HP. С трудом допинали, но лучше не стало...

У тебя мейл в профиле рабочий? Могу ссылку послать.

гы.. IB не готова больше для больше 100 узлов? гы-гы.. скажите это cray.. ребята будут долго смеяться. в его XT3/XT4 больше 1К узлов..

>Плохо оно работает. Я по долгу службы много тестировал некую софтину на разных кластерах, постоянно проблемы с IB. Особенно на нагруженных кластерах, когда мне выделяют пару десятков нод в эксклюзив, а на других продолжаются рассчеты -- IB иногда вообще проседает..

А ну это 2+ несогласованные задачи. Тогда понятно.

У меня одна задача - один кластер (персональный на 40 корок) ;) IB там самое оно.

>Как-то отваливается иногда... Например, основной инструмент для одной задачи у нас сейчас около1000нодный кластер на 3000 вычислительных корок, DDR 4x IB. Параллельные задачи с более чем 14 процессами стабильно дохнут..

Странно конечно. Видимо действительно косяки с масштабируемостью на таком размере + куча несогласованых задач шлют всякий мусор в COMM_WORLD. Верю ;)

>Кроме того, DDR чуть ли не полгода поднимали, не сами -- спецы из HP

Однако ;)

>У тебя мейл в профиле рабочий? Могу ссылку послать.

Будет валидным с 1 августа ;)

sS (17.07.2007 18:40:03):

> У меня одна задача - один кластер (персональный на 40 корок) ;) IB там самое оно.

Да, совершенно согласен.

Кстати, основная проблема IB -- не столько MPI, сколько распределенная файловая система. Когда что-то типа Ластры гонит приличный траффик, который еще и конкурирует с MPI, то IB совсем тяжко становится. А если в качестве скретчей используются локальные диски, то проблема часто бывает в ГиперТранспорт + шины + дисковый контроллер + IB карта -- я наблюдал, как иногда оно все друг другу сильно мешает даже на маленьких кластерах.

>>У тебя мейл в профиле рабочий? Могу ссылку послать.

>Будет валидным с 1 августа ;)

Если хочешь, напиши на colonel_b@hotmail.com действующий емэйл, я скину некоторые ссылки по теме.

>Кстати, основная проблема IB -- не столько MPI, сколько распределенная файловая система. Когда что-то типа Ластры гонит приличный траффик, который еще и конкурирует с MPI, то IB совсем тяжко становится.

Это надо разносить однозначно. У меня к сожалению в блейды не влезли по 2 HCA, только один. Пришлось повесить PVFS2 на сдвоенный GigE. MPI бегает по IB отдельно, там на боевых задачах траффик почти на пределе IB. Причём задача таким образом сбалансирована чтобы уменьшить (точнее упорядочить) коллизии. Огоньки при этом на свитче прикрольно бегают "волнами". Можно дебажить задачу на синхронность обменов просто глядя на свитч ;)

>ГиперТранспорт + шины + дисковый контроллер + IB карта -- я наблюдал, как иногда оно все друг другу сильно мешает даже на маленьких кластерах.

Это будет мешать на любых по размерам если оптероны 1/2xxx а не 8xxx. В первых только один синхронный HT линк

>Если хочешь

Написал.

sS:

> Написал.

Аналогично.

Там проблемы с русским иногда почему-то случаются, тогда просто по ссылкам пройди, в самом тексте ничего важного я не написал.