Как собрать простенький кластер ?

Берем в руки parallelknoppix или clusterknoppix... :)

ща придет ленин с грустной историей о злых линуксойдах-программерах которые не принимают его патчи.

<offtop> Как только увидел страничку, сразу бросилась в глаза ссылка на рассуждения некоего Мартина Флинка о преимуществе использования Linux в бизнесе. </offtop>

Who runs Condor anyway? MOSIX I run!

Да уж совсем небольшая статья, общие слова только. Так я и не понял из статьи чем DRBL лучше Stateless Linux и ему подобных систем.

OPENMosix

как как... спросите гугль! http://www.google.com/search?hs=UwE&hl=en&lr=&safe=off&client...

> Так я и не понял из статьи чем DRBL лучше Stateless Linux и ему
> подобных систем.

просто еще один вариант решения
если правильно помню юниксвей означает что всегда есть более одного способа сделать что либо %)

фтопку -- use MPICH

Не корректное сравнение, поскольку у М$ тоже имеется свои N-цать способов скопировать файл из каталога в каталог. В каком-то вузе по т.н. "информатике" студеозусов заставляли сдавать зачет с демонстрацией "всех возможных" способов копирования и вставки текста, скажем, из ноутпэда в ворд.

Необходимо заодно написать статью "Зачем собирать маленький кластер"

Простой кластер, ОС для дураков, UNIX для чайников, майнфрейм для дебилов :-)

задолбали ананимусы

>Необходимо заодно написать статью "Зачем собирать маленький кластер"
Чтобы эффективно использовать имеющиеся вычислительные ресурсы.

>если правильно помню юниксвей означает что всегда есть более одного способа сделать что либо

Г-н Дятлов путает Unix и Perl?

Тайное братство анонимных вычислителей? Опять ищем зеленых человечков?

Кстати, недвано видел кнжку под названием "Юникс для полных идиотов".

> фтопку -- use MPICH

Мсье мазохист?

Нисколько, именно 'ф топке' место поделиям типа OpenMosix. Это сколько травы выкурить нужно чтобы придумать сделать из кластера недоSMP.

что там не так?

>> Необходимо заодно написать статью "Зачем собирать маленький кластер" > Чтобы эффективно использовать имеющиеся вычислительные ресурсы.

прям как в старые добрые 80-ые экономим "машинное время" :)

Основная идея проекта mosix: берем группу машин под Linux, накатываем на ядро патчи, после чего процессы одной машины могут свободно "гулять" по кластеру. Естественно, вслед за процессами мигрируют и все связанные ресурсы процесса. Есть планировщик, который пытается оптимально разложить процессы по машинам.

Накладные расходы на все это хозяйство немерянные -- около года назад прогонял тесты Linpack на 4 узлах (8 CPU), с сетью SCI, получил суммарную производительность ажно на 150% от пика одного процессора. Реальный расчетный софт выдает еще более "рекордные" показатели.

Изначально, проект предназначался для распараллеливания на кластерах унаследованного ПО работающего только на SMP. Правда, по прошествии некоторого времени об изначальной цели проекта забыли и стали кричать о "single cluster system image", "true cluster solution" и так далее. Даже, помнится, пытались в mainstream ядра эти патчи запихнуть, но, увы, не вышло.

Если мне кто-нибудь объяснит, нафига это все нужно для реальных применений, буду очень признателен.

Ну не так все печально - после наложения пачей надо взять рашпиль и поработать над конфигурацией. Поставить распределенную ФС все ноды кластера. Ну, и если надо то поставить какой-нить враппер на предмет коллективного IP. У меня, например, на 8ми нодах при кодировани видео производительность болталась на уровне 700% (по FPS).

Само собой свич и карточки нужны 1Gb - делать на сотке - анон.

> Если мне кто-нибудь объяснит, нафига это все нужно для реальных применений, буду очень признателен.

Коллега, не уверен, что понял Вас правильно... Ежели это был не реальный вопрос, а сарказм - то сорри. Существует куча задач, которые невозможно в разумные сроки решить на одной, даже очень шустрой и оченьSMP-машине. Если Linux стоит на шлюзе в Инет, то распараллеливания не требуется. А вот, например, нам сейчас очень не хватает мощности при закрытии периода или перепроведении данных в 1С. Если бы работу можно было разделить между несколькими серверами - был бы просто праздник. Или "тяжёлые" ERP-системы - типа SAP, Oracle, JDEdwards или та же Axapta. Они работают не по двух, а по трёхуровневой схеме: клиент - сервер_приложений - сервер_БД. И если количество серверов можно плодить до бесконечности (работают независимо друг от друга), то сервер_БД, если он один, рано или поздно станет "бутылочным горлом". Single System Image - это было как минимум на VAX и Alpha (раньше не застал, не знаю). Весьма удобная штука: не нужно конфигурировать каждый узл кластера отдельно, образ операционки везде одинаковый. Если для подключения нового узла у HP-UX требовалосьна каждую новую ноду "с нуля" ставить ОС и накатывать те патчи, которыми проапдейжены остальные участникикластера, то на Tru64 UNIX (DEC) нужно было только сказать, откуда брать уже имеющийся образ. По опыту скажу, что очень облегчает администрирование. Сейчас SSI - фактически стандарт.

По-моему, присутствует путаница в терминах -- SSI не заключается в _идентичности_ конфигурации узлов кластера. Само собой, что все железо+настройки оного должны быть одинаковые иначе сопровождение всего этого хозяйства превратится в тихий ужас.

SSI, насколько знаю, это единый _экземпляр_ операционной системы на распределенном железе (или, в случае Mosix -- единый для пользователя). То есть ядро создает видимость управления всеми узлами кластера как одним целым. В случае SMP или Numa это оправдано, но в случае кластера, накладные расходы, ИМХО, слишком высоки.

В случае трёхзвенных приложений, Mosix опять не у дел. Дело в том, что грамотно написанная трёхзвенка не зависит от местоположения компонентов бизнес-логики (среднее звено), то есть можно спокойно разложить наиболее требовательные к ресурсам EJB/COM+ компоненты по отдельным серверам и все будет нормально. Насколько знаю, тяжелые СУБД также не подразумевают наличия всей системы на одной машине, посему так же можно поступить и с уровнем БД.

На мой взгляд, на 8 CPU данная задача должна выдавать больший прирост производительности. Синхронизации/обмены между процессами минимальны (взять кадр, распаковать, запаковать, записать).

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

В моем тесте Mosix обмены осуществлялись через Dolphin SCI, то есть со скоростью 2-3 GBit/s и латентностями на несколько порядков ниже чем Ethernet. Хотя, повторю, OpenMosix я смотрел около года назад, возможно, что-то изменилось в лучшую сторону.

Я говорю о mosix - openmosix работает от случая к случаю.

P.S. Задачи со сложной логикой как раз гораздо хуже распаралеливаются: поэтому ждать от них хорошей нагрузки кластера/SMP не стоит. Все зависит от того как написана задача. Как правило, мало кто уделяет внимание этому аспекту при написании. Наличие тридов еще не значит их паралельного исполнения 8) Как говорят математики - это условие необходимое, но не достаточное.

Совершенно верно. Чаще всего большие кластера и строят именно под тяжелые "числодробильные" задачи со сложным взаимодействием процессов, для которых является критичным скорость и латентность сетевого соединения. В этом случае, потери производительности "на Mosix" просто недопустимы.

Hint: прирост производительности на 20% на простеньком кластере из 128 CPU приводит к экономии 18000 процессорных часов каждый месяц.

Вопрос: сколько просить у руководства прибавку к зарплате за такую экономию? ;-)

Спросите у гугла! http://www.google.com.ua/search?q=%D0%BA%D0%B0%D0%BA+%D0%B3%D1%80%D0%BE%D0%BC...

А почему некоторые хохлы такие долбоебы? Это как-то связано с непомерным потреблением сала?

"А почему некоторые хохлы такие долбоебы? Это как-то связано с непомерным потреблением сала?" http://antigreen.org/bioreactor/

Много метана с них не получить. :(

Duraki vy vse :(

> Сейчас SSI - фактически стандарт.

Скажите, а кто его поддерживает, кроме Tru64 и VMS/OpenVMS?

>Если мне кто-нибудь объяснит, нафига это все нужно для реальных применений, буду очень признателен.

Перед тем как чего-то делать желательно понять что ты хочешь получить.

hint: PVMPOV к примеру на MOSIX-кластере масштабируется почти линейно, а то что сильносвязанная задача, которая изначально заточена под SMP (shared mem model) демонстрирует недеЦкий оверхед на кластере, который по жизни заточен под MP model не есть проблема кластера.

PS: какой был MPI в Linpack-е (mpich, lame или от производителя SCI железяки) и с каким девайсом (ch_*) если это был MPICH он был собран ?

> Перед тем как чего-то делать желательно понять что ты хочешь получить.

Я хочу получить _жизненный_ пример использования Mosix в HPC

> PVMPOV к примеру на MOSIX-кластере масштабируется почти линейно,

алгоритмы povray по определению должны масштабироваться линейно (за исключением сцен с glow-эффектами) -- внимательно смотреть опции SR/ER/SC/EC.

Не понимаю я аргумент: несмотря на то что без Mosix задача X работает хорошо, на Mosix она тоже работает неплохо. Зачем тогда Mosix?

> какой был MPI в Linpack-е

Естественно, SCI-MPICH (тот который сейчас MP-MPICH).

>Не понимаю я аргумент: несмотря на то что без Mosix задача X работает хорошо, на Mosix она тоже работает неплохо. Зачем тогда Mosix?

1) Прозрачная SSI абстракция (исключительно для удобства юзеров а не для скорости)

2) Гетерогенные кластеры (зоопарк из узлов с различным числом различных камней и даже на различной среде передачи, правда для этого нужно будет такой кластер оттюнить, см. man tune)

3) Кластеры с более чем одной задачей или задачей со сложной декомпозицией.

А кто-нибудь пробовал это чудо от Билла (бету) http://www.microsoft.com/windowsserver2003/ccs/default.mspx ?

> Прозрачная SSI абстракция (исключительно для удобства юзеров а не для скорости)

Допустим, хотя, IMHO, ничего удобнее для пользователя чем интерфейс PBS пока не придумали. Опять же, всё очень сильно зависит от того, сколько за это удобство приходится платить производительностью.

> Гетерогенные кластеры

Ужас. И как вы себе это представляете? Если есть гипотетический расчетный софт в котором можно настроить такие моменты как разная скорость обменов между процессами/потоками, то _зачем_ нам наворачивать сверху Mosix? Если алгоритм решения задачи не учитывает специфику железа на котором работает, то никакие эмпирические методики нам не помогут.

Настройка производительности кластера с идентичным узлами и единой средой передачи может занять не один месяц экспериментов с софтом (даже дизассемблировать иногда приходится). И в результате получаются весьма забавные результаты, например, вдруг выясняется, что рекомендуемые параметры решателя (например, декомпозиции) вовсе не наилучшие, а совсем наоборот. И как тут поведет себя Mosix? Сама все настроит и разложит по кластеру как нужно?

> Кластеры с более чем одной задачей или задачей со сложной декомпозицией.

Я думал, мы не обсуждаем рабочие станции. А по поводу декомпозиции... Покажите мне коммерческий расчетный продукт который не умеет сам делить задачу на куски и использовать для распараллеливания MPI или PVM.

Например вот: http://www.ansys.com/industries/tm-15-stage-compressor.htm -- 32 млн. узлов расчетной сетки, 37 гигабайт памяти. Mosix там нафиг не нужен -- все делает софт.

Вот и получается, что у Mosix реального применения просто нет -- или на поиграться, либо худо-бедно пускать устаревшие софтины чтобы хоть как-то считались на кластерах.