> но все вместе они смогут сделать больше, чем одна двухъядерная машина

проще сдать весь этот хлам на металлолом и купить четырехъядерную машину

>Если у вас есть 32 старых однопроцессорных компьютера

уже смешно.

А я-то думал куда мне деть мои 32 старых компа...

А также не только на старых однопроцессорных компьютерах, но и на КПК, смартфонах, и прочих ЕС ЭВМ http://ru.inferno-os.wikia.com/wiki/%D0%9F%D1%80%D0%BE%D1%81%D1%82%D0%BE%D0%B9_%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80_Grid

Т.е. 32 компа немногим лучше, чем одна двухядерная машина?

> Т.е. 32 компа немногим лучше, чем одна двухядерная машина?

Скорее хуже, если нет своей АЭС.

/me пошел делать кластер из 133 и 166 машинок

у нас в европе элекричество дорогое. так что лесом эту хрень

лучше купить один мощный комп.

А счет за киловатт-часы кто будет оплачивать?

Это развёртывать можно разве что в университетах, где тачки одинаковые...

> Если у вас есть 32 старых однопроцессорных компьютера

Возможно Вы серьезно больны.

Да.

Боюсь серверные двухканальные сетевухи будут стоить дороже этого хлама, а на обычных делать смысла нет -- пересылки всё сожрут.

> лучше купить один мощный комп.

А лучше 32 мощных компа :)

> Боюсь серверные двухканальные сетевухи будут стоить дороже этого хлама, а на обычных делать смысла нет -- пересылки всё сожрут.

Именно поэтому по ссылке упоминается InfiniBand...

Вот тут тоже про кластеры.

http://www.linux.org.ru/jump-message.jsp?msgid=3975837&cid=3976364

>компов

Это главная? Или толксы?

>Если у вас есть 32 старых однопроцессорных компьютера

Поменяйте их на один новый

>Да, у них всего по одному ядру, но все вместе они смогут сделать больше, чем одна двухъядерная машина.

Потребить электричества уж точно. А без должного распараллеливания нужных процессов такой кластер будет совершенно бесполезен.

чОрт, у меня есть только всего один старый комп. Я смогу сделать из него кластер, который обделает все 10-ядерные ксеноны?..

Хм, интересная статья, не знал что есть готовые дистрибутивы заточенные под это.

А о том, как приготовить офигический ужин на двоих из 7 протухших сарделек там не пишут?

а почему вы интересуетесь?

Пишут как сделать ужин, а протухшие или свежие сардельки туда резать - Вам решать :D

А по делу мне кажется что статья вполне ничего. Как ознакомительная по кластерным дистрам. Кстати, Beowulf-подобные решения вполне могут быть востребованы в тех же универах для обучения. У нас было такое дело что пришел новый класс, старый так тоже вполне себе ничего был. Там оптероны 4-процовые стояли. И их "утилизировали" подобным способом.

> чОрт, у меня есть только всего один старый комп. Я смогу сделать из него кластер, который обделает все 10-ядерные ксеноны?..

и питцот галагенок

всё, бегу докупать ещё 31 однопроцессорный комп, и я буду круче чем сосед со своим 2 ядерным ноутбуком!!!! вот я его натяну! ( а электричество.. это уже мелочи.. главное куда деть эти 32 компа?)

только сегодня думал что надо почитать про кластеры линуксовые ^_^

но

>Если у вас есть 32 старых однопроцессорных компьютер

facepalm

Слово "старых" явно лишнее в названии статьи...

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

О! У меня! У меня есть!!1111111 Вся кладовка в офисе ими завалена (на полном серьёзе, раньше юзались как ТК, потом перешли на ТК от HP) - выбросить жалко, применить некуда...

Интересно, если их все в кластер собрать - на них tomboy пойдёт?

>Если у вас есть 32 старых однопроцессорных компьютера

Еще ж не пятница. Вот как надо писать новости, эх!

Самая идея совершенно бредовая, но очень типичная для нищебродского отечественного IT. Дело-то ведь не в том, чтобы сэкономить за счёт использования кластера - да Боже упаси, эксплуатация скоренько сожрёт денег больше, чем любой Гаргантюа с Пантагрюэлем вместе взятые, - НЕТ, дело в том, чтобы уложиться в текущий бюджет, чтобы, например, обучение начальника каким-нибудь основам CRM/BPM не пошло прахом из-за покупки нового дорогого мощного сервера. Народ в организациях просто боиться тратиться единовременно на крупные суммы. Лучше вот 10 раз по 30 рублей, чем один раз аж 100 капиталовыложить! И все прекрасно понимают, что кластер из хлама - это бесполезно и бесцельно, впустую потраченное время специалистов (которое тоже чего-то ПО ИДЕЕ должно бы стоить), это неоправданно высокие затраты электроэнергии, это на порядки более геморройные и менее диагностируемые проблемы с железом, это место в серверной в конце-концов (и оно тоже денег стоит), но ё-моё, вы ж посмотрите, господин гавнюк, то мы бы купили IBM P-серии (кошмарно дорогой, аж два ваших отпуска в Европе!), а так - мы такие умные, погладщьте нас по головке и увеличьте фонд на обучение, уйму денег вам сэкономим, старую серверную рухлядь соберём в ультрамодное словечко - HA-кластер (НА - это, правда, не высокодоступный значит, это просто наше русское классическое НА {ТУДА_ТО}) и будем круче яиц, сваренных в крутую на процессорах этих 32-х машинок. УРА! Все счастливы, углекислый газ выделяется, парниковый эффект усиливается, скоро все будем жить на Канарах или хотя бы просто на острове посреди Мирового Океана - все вместе, начальнека, все вместе, в тесноте, да не в обиде...

p.s. Ъ юзают http://xcpu.org/ !111 или вообще чистую plan9!111

как пел Евгений Гудзь, "серебряные зайцы водят хоровод". теперь я знаю, он про гленду ;)

Нифигасе высер... А если я четыре сервака на кореквадах в кластер хочу, чтоб аппсервер мог не 3000 а 10000 соединений одновременных обслуживать? А тестироваться/практиковаться на чём?

Хорошая, годная статья.

Спасибо, Виктор Алексеевич. Хорошая, годная статья.

Я бы переименовал в "Как собрать обогреватель".
В принципе лето заканчивается, скоро будет актуально.

Виндовый ботнет и то выглядит перспективнее для всяких расчетов, чем старая рухлядь (еще и 32 шутки). И тише будет.

Чтобы аппсервер мог больше соединений обслуживать, прежде всего замените аппсервер на бэкенды, написанные на C и веб-фронтенды на Perl! Java-сервера приложений 80% времени своей работы тупо жрут процессорное время и память. Дай какой-нибудь веб-сфере сказать "Hello, world!", она и на это потратит столько же тактов, сколько в каком-нибудь 1970-ом году тртилось на расчёт полёта космической ракеты. У меня как у ASM-програмиста подобные вещи ничего, кроме отвращения, не вызывают... Ну и собственно очень редко узким местом является именно процессор, гораздо чаще это всё-таки ввод-вывод, ну а коли у вас все ноды кластера наверняка будут подключены к одной полке и делить одно на всех внешнее ethernet-подключение, то о каком трёхкратном росте производительности может идти речь?

>Чтобы аппсервер мог больше соединений обслуживать, прежде всего замените аппсервер на бэкенды, написанные на C и веб-фронтенды на Perl!

А потом выйдите на улицу на перекур и узнайте, что Землю сто лет назад захватили серо-зеленые жабокрылы.

32 * 300 Watt одной машины ~~ 9kWat хорошенький обогреватель, всё равно аля <Как из 32 студентов инженеров первоеурсников сделать 1 крутого админа>

Аппсервер не на жабе.

Используется принцип - нечто среднее между ВЕБ-приложением и десктоп-приложением.

Ясно, респект на самом деле, а что за продукт, если не секрет, на чём писан? Собственная разработка?

>что Землю сто лет назад захватили серо-зеленые жабокрылы
И Kill Em All? Неплохой шутер получится, а главное, что в итоге всё равно восторжествует справедливость, зелёные стандарты, энергосберегающие и те же шустрые программы на C во вставками на Асме. Ведь победить Жабокрыла очень легко - достаточно загнать его в ближайшую яму и забросать камнями, а потом сделать ему DDoS. А всё потому, что жабокрылы только плавают хорошо, но вообще ни разу не летают.

Продукт - изначально внутрикорпоративное ПО для риэлторской фирмы. Сейчас думаем его продвигать на внешний рынок. В виде законченного процесса управления риэлторским предприятием, плюс функции МЛС.

Писано на С++/Qt+WebKit (некоторые модули, в частности используемые для геренации отчётов и реализации мониторингов используют плюсы и удобство ВЕБ-представления), и PHP (серверная часть. Да-да, гнобите сколько хотите но ТАМ оно РЕАЛЬНО ОЧЕНЬ УДОБНО, и быстро).

> Пишут как сделать ужин, а протухшие или свежие сардельки туда резать - Вам решать :D

+500

А если есть три двухпроцессорных и два однопроцессорных, пролетаю?

А вообще, подскажите мне пожалуйста бытовое применение вычислительных мощностей, в частности кластера?

>У меня как у ASM-програмиста подобные вещи ничего, кроме отвращения, не вызывают...

мне одному вспомнился vsl? ;)

А под каким соусом он мог вспомниться? "Эх, вот бы пришел Профессор и вправил тебе мозги"?

Статистика показывает, что "узкими местами" по производительности в современных бизнес-приложениях - является достаточно малое количество мест всей программной конструкции. - Потому что программа часто ждет ввода пользователя, или тот же Java-код (опирающийся на нативные модули на С++) - показывает идентичную, как и на С++, производительность.

Программный код, состоящий из сотен модулей-подсистем - может быть неэффективен из-за недостаточной квалификации программиста, или от того, например, что в процессе разработки изменялись бизнес-требования (обычное дело) и поэтому все недостаточно оптимизировано.

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

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

Часто прирост может дать - сравнительно небольшое увеличение ОЗУ (для того же Оракла), например. И цена этого ОЗУ - будет несопоставимо ниже, в 100 раз ниже, чем написать все на Ассемблере.

Типичный пример ассемблерного коня в вакууме. ;)

Кластера всегда будут кластерами, если нужна отказоустойчивость, доступность и не геморройность при восстановлении, то кластера правильный выбор. Так, что товарищи не в ту сторону смотрите... PS все нужные приложения, которые могут повлиять на работу конторы, раскидываю по кластерам, и уже неоднократно спасало ситуацию. Будем дальше изучать.....