Comments 77
Думаю, не мешало бы добавить в статью ссылку на официальный мануал: http://kerrighed.org/wiki/index.php/Virtual_images_instructions
Кстати, можете подробнее написать как будет использоваться оперативная память и жесткий диск при такой схеме?
жесткий диск по умолчанию на узлах вообще не трогается.
сами же узлы доступаются ко всем дисковым ресурсам по nfs, в том числе и к "/".
память у каждого узла своя.
память используемая процессом не может растянуться по разным узлам — если система посчитала, что надо мигрировать процесс на менее нагруженный узел, то процесс мигрирует со всей своей памятью на новое место жительства.
ДИСКЛАЙМЕР. я вообще лет 5 уже не пользовался никакими SSI, может поменялось чего-нибудь уже! :)
сами же узлы доступаются ко всем дисковым ресурсам по nfs, в том числе и к "/".
память у каждого узла своя.
память используемая процессом не может растянуться по разным узлам — если система посчитала, что надо мигрировать процесс на менее нагруженный узел, то процесс мигрирует со всей своей памятью на новое место жительства.
ДИСКЛАЙМЕР. я вообще лет 5 уже не пользовался никакими SSI, может поменялось чего-нибудь уже! :)
я думал, что kerrighed для балансировочных кластеров. в любом случае, спасибо за труды
я пользовался в прошлом сугубо для HPC
есть мануалы?
мануалы чего? Kerrighed? OpenSSI? или их приложения к HPC?
тогда для своих HPC я успешно пользовался не Kerrighed, а вот этим:
openssi.org/cgi-bin/view?page=openssi.html
тогда для своих HPC я успешно пользовался не Kerrighed, а вот этим:
openssi.org/cgi-bin/view?page=openssi.html
Много ли места занимает последняя убунта на винте и долго ли будет качаться на 2-мегабитном канале?
кажется мой ответ вам пришился не туда :)
habrahabr.ru/blogs/linux/113387/#comment_3641247
habrahabr.ru/blogs/linux/113387/#comment_3641247
А когда можно будет начинать этим пользоваться? И, возможно, уже есть рабочие версии для других дистрибутивов?
пользоваться можно как Kerrighed так и OpenSSI уже давно. Для меня почему-то всегда был самым удобным вариантом использования: «поставил пакет на текущей системе и получил SSI»
а в реалии часто приходилось наоборот: отдельно сначала ставить чистенький линукс, потом на нём SSI поднимать, а потом уже пакеты доставлять.
а в реалии часто приходилось наоборот: отдельно сначала ставить чистенький линукс, потом на нём SSI поднимать, а потом уже пакеты доставлять.
UFO just landed and posted this here
… В процессе оно подтаскивает на / ещё кучу всего и упирается в 4 гига…
Сейчас вынужденно пересел с EEE 1000 с его 8+32 гигами на ЕЕЕ 900 с его 4+16 и всё это наблюдаю не по-наслышке…
На первом — традиционно /, на втором — home, в итоге постоянное нытьё при обновлениях «ой, а у вас на диске места мало! Давайте запустим прогу для показа что у нас и как забито?!»…
Правда на днях по совету знакомых снёс старые версии ядер- получил + 500 мегов места — вроде хоть теперь хватает…
Сейчас вынужденно пересел с EEE 1000 с его 8+32 гигами на ЕЕЕ 900 с его 4+16 и всё это наблюдаю не по-наслышке…
На первом — традиционно /, на втором — home, в итоге постоянное нытьё при обновлениях «ой, а у вас на диске места мало! Давайте запустим прогу для показа что у нас и как забито?!»…
Правда на днях по совету знакомых снёс старые версии ядер- получил + 500 мегов места — вроде хоть теперь хватает…
Хорошо, а как у этой штуки с хитрыми интерконнектами вроде Infiniband? Вообще, какие приемущества относительно классического Beowulf?
Beowulf не только не обязывает к SSI, но даже декларирует в рекомендательном тоне.
Просто работает вместе как-то в сети у вас N Линуксов — значит Beowulf. Скучно :)
Просто работает вместе как-то в сети у вас N Линуксов — значит Beowulf. Скучно :)
Ну вот мы сейчас используем почти классический беовульф — несколько сотен линуксов, соединенных Infiniband. А эта штука мне представляется как некая виртуальная MP-система. Умеет она ходить по инфинибэнду?
с Infiniband сам не работал.
если поверх Infiniband можно использовать вместо Ethernet, и по нему весь TCP/IP стек бегает как по Ethernet, то должно работать.
ваш беовульф наверное на MPI или PVM? — это то, чего я *очень* не хотел и почему я собственно и стал пробовать OpenSSI :)
если поверх Infiniband можно использовать вместо Ethernet, и по нему весь TCP/IP стек бегает как по Ethernet, то должно работать.
ваш беовульф наверное на MPI или PVM? — это то, чего я *очень* не хотел и почему я собственно и стал пробовать OpenSSI :)
MPI, вестимо. IP-over-IB есть конечно, хотя и медленнее чем RDMA. Собственно смысл IB слегка теряется без таких фишек как RDMA.
> MPI
так я и думал :)
моё мирощущение таково, что люди в 90% имеют задачи со слабо связанными вычислениями (loosely coupled computations). Однако, из-за отсутствия под рукой нормальной инфраструктуры для распараллеливания этого широчайшего и одновременно простейшего семейства вычислений, люди невольно вовлекаются в тяжеловесные MPI/PVM решения.
так я и думал :)
моё мирощущение таково, что люди в 90% имеют задачи со слабо связанными вычислениями (loosely coupled computations). Однако, из-за отсутствия под рукой нормальной инфраструктуры для распараллеливания этого широчайшего и одновременно простейшего семейства вычислений, люди невольно вовлекаются в тяжеловесные MPI/PVM решения.
Большое спасибо!
Никогда раньше и не думал, что построение кластеров может быть НАСТОЛЬКО простым, как настройка апача или немногим сложнее.
А машина-донор, я так понимаю, самая главная в этом кластере? она управляет процессами? Что будет, если ее отключить? Можно ли поиметь рабочую станцию на машине-акцепторе, независимо от ее включенности в кластер? Не могли бы вы привести примеры приложений, где такой кластер использовать лучше всего? Т.е. для каких задач подходит эта архитектура? Буду признателен, если ответите хотя бы на часть вопросов.
Никогда раньше и не думал, что построение кластеров может быть НАСТОЛЬКО простым, как настройка апача или немногим сложнее.
А машина-донор, я так понимаю, самая главная в этом кластере? она управляет процессами? Что будет, если ее отключить? Можно ли поиметь рабочую станцию на машине-акцепторе, независимо от ее включенности в кластер? Не могли бы вы привести примеры приложений, где такой кластер использовать лучше всего? Т.е. для каких задач подходит эта архитектура? Буду признателен, если ответите хотя бы на часть вопросов.
настройка апача может стать делом всей жизни… а OpenSSI у меня поднимался на ура уже на второй день и я толком не трогал уже настройки!
как пойдет с Kerrighed не знаю. Посмотрим :)
как пойдет с Kerrighed не знаю. Посмотрим :)
> А машина-донор, я так понимаю, самая главная в этом кластере? она управляет процессами?
нет, все машины более менее равноправны.
> Что будет, если ее отключить?
это как kill -9 процессов, которые бегали на ней :)
> Можно ли поиметь рабочую станцию на машине-акцепторе, независимо от ее включенности в кластер?
хм… не знаю :)
> Не могли бы вы привести примеры приложений, где такой кластер использовать лучше всего? Т.е. для каких задач подходит эта архитектура? Буду признателен, если ответите хотя бы на часть вопросов.
я пользовался успешно в протеомике (молекулярная биология). сейчас другие нужды.
любые loosely coupled computations отлично приживаются на SSI, например переборные задачи. переводя на простой язык, если вы какой-нибудь хакер или ищете чего-нибудь там в космосе — то SSI самое то :)
З.Ы. сорри, надо убежать на час
нет, все машины более менее равноправны.
> Что будет, если ее отключить?
это как kill -9 процессов, которые бегали на ней :)
> Можно ли поиметь рабочую станцию на машине-акцепторе, независимо от ее включенности в кластер?
хм… не знаю :)
> Не могли бы вы привести примеры приложений, где такой кластер использовать лучше всего? Т.е. для каких задач подходит эта архитектура? Буду признателен, если ответите хотя бы на часть вопросов.
я пользовался успешно в протеомике (молекулярная биология). сейчас другие нужды.
любые loosely coupled computations отлично приживаются на SSI, например переборные задачи. переводя на простой язык, если вы какой-нибудь хакер или ищете чего-нибудь там в космосе — то SSI самое то :)
З.Ы. сорри, надо убежать на час
если вы про первичную инсталяцию на «Компьютере №1», то вопрос слишком банальный/утилитарный.
Но, если я правильно улавливаю ход вашей мысли, вы прикидываете, сколько времени нужно бездисковому узлу чтобы загрузиться через Ethernet с донора? — Раньше это было практически столько же сколько и с диска. Но я не удивлюсь, если это произойдет даже быстрее :)
В самом деле, ведь самым естесственным образом на «Компьютере №1» все файлы нужные для загрузки закэшированы в системе. А пересылка их прямо из RAM по Ethernet (особенно если он у вас гигабитный) кууууда быстрее, чем считывание с диска — на чём собственно и держатся SAN-носители.
Но, если я правильно улавливаю ход вашей мысли, вы прикидываете, сколько времени нужно бездисковому узлу чтобы загрузиться через Ethernet с донора? — Раньше это было практически столько же сколько и с диска. Но я не удивлюсь, если это произойдет даже быстрее :)
В самом деле, ведь самым естесственным образом на «Компьютере №1» все файлы нужные для загрузки закэшированы в системе. А пересылка их прямо из RAM по Ethernet (особенно если он у вас гигабитный) кууууда быстрее, чем считывание с диска — на чём собственно и держатся SAN-носители.
Какая путаница… Кластер != компьютер с кучей ядер. То, что вы говорите реализуется с помощью NUMA. А это всего лишь загрузка по сети с DRBD.
SSI — это когда ваш кластер выглядит как компьютер с кучей ядер. Где путаница?
NUMA — это парадигма доступа к памяти, не только нерегламентирующая миграцию процессов, но даже не аппелирующая к процессам. Раз уж вы не любите путаницы, то будьте последовательны :)
NUMA — это парадигма доступа к памяти, не только нерегламентирующая миграцию процессов, но даже не аппелирующая к процессам. Раз уж вы не любите путаницы, то будьте последовательны :)
В слове «компьютер с кучей ядер».
Вот описание, openssi.org/cgi-bin/view?page=features.html, тут вполне ясно описано, who is who. Это не NSMP (NUMA), это исключительно эмуляция некоторых аспектов.
Вы не сможете иметь полноценную имитацию (N)SMP, это будет лишь запуск приложений на разных компьютерах с единой нумерацией всего.
Разница с NUMA примерно такая же, как разница между Xen'ом и chroot'ом. Определённое сходство есть, но результаты и технологии — разные.
Вот описание, openssi.org/cgi-bin/view?page=features.html, тут вполне ясно описано, who is who. Это не NSMP (NUMA), это исключительно эмуляция некоторых аспектов.
Вы не сможете иметь полноценную имитацию (N)SMP, это будет лишь запуск приложений на разных компьютерах с единой нумерацией всего.
Разница с NUMA примерно такая же, как разница между Xen'ом и chroot'ом. Определённое сходство есть, но результаты и технологии — разные.
а можете дать ссылку / ppa для ubuntu 10.10? Хочу потестить
к концу недели должна бы появиться.
а пока есть лишь эти дебы: kerrighed.org/debian
но эти пакеты — ненамерянная утечка. они предназначались для проекта по EU-гранту XtreemOS
а пока есть лишь эти дебы: kerrighed.org/debian
но эти пакеты — ненамерянная утечка. они предназначались для проекта по EU-гранту XtreemOS
Как печально живется людям из-за того, что когда-то они не приняли Plan9, а теперь не принимают Erlang.
Для тех, кто в танке: единственный теоретический профит от такой инсталляции в межнодовом IPC. Растянуть на 100500 камней желаемый мускуль может быть, и получится, но без использования RDMA вся эта поделка будет неистово тормозить из-за сетевых задержек. С использованием RDMA (который, к слову, доступен исключительно на не столь уж и дешевых железках) тормозов будет меньше, но они все же будут.
В результате я так и не понял, какова практическая польза от такого продукта кроме Proof-of-concept. Заранее спасибо за ваши объяснения.
Для тех, кто в танке: единственный теоретический профит от такой инсталляции в межнодовом IPC. Растянуть на 100500 камней желаемый мускуль может быть, и получится, но без использования RDMA вся эта поделка будет неистово тормозить из-за сетевых задержек. С использованием RDMA (который, к слову, доступен исключительно на не столь уж и дешевых железках) тормозов будет меньше, но они все же будут.
В результате я так и не понял, какова практическая польза от такого продукта кроме Proof-of-concept. Заранее спасибо за ваши объяснения.
UFO just landed and posted this here
в будущем, мне кажется, востребованы не костыли типа SSI, а нормальные тулкиты для разработки софта. Сейчас существуют Erlang/OTP, Scala, может быть, еще что-то.
Кластеризоваться должен софт, а не платформа, другими словами. Это мое мнение.
P.S. Тем временем люди портировали хорошую вещь на распространенную платформу. Кластер можно строить хоть сейчас из компов и телефонов. Осталось написать софт согласно парадигме Let it crash.
P.P.S. Так где же будущее? Когда-то, может быть, на SSI или прямо сейчас на OTP?
Кластеризоваться должен софт, а не платформа, другими словами. Это мое мнение.
P.S. Тем временем люди портировали хорошую вещь на распространенную платформу. Кластер можно строить хоть сейчас из компов и телефонов. Осталось написать софт согласно парадигме Let it crash.
P.P.S. Так где же будущее? Когда-то, может быть, на SSI или прямо сейчас на OTP?
UFO just landed and posted this here
> в будущем, мне кажется, востребованы не костыли типа SSI, а нормальные тулкиты для разработки софта.
ну, раз уж вы такую планку берёте, то заклеймите уж наконец интел — не первое десятилетие на рынке, а даже про «ерундовое 1Кило-ядро» для нормальных людей у них и речь даже не идёт. Всё кормят нас костылями по паре-другой ядер…
> Кластеризоваться должен софт, а не платформа, другими словами. Это мое мнение.
да, так было удобно. но только до тех пор, пока не познакомишься с реальным многоязычным миром, когда всё это «счастье» надо как-то заставить работать вместе :)
ну, раз уж вы такую планку берёте, то заклеймите уж наконец интел — не первое десятилетие на рынке, а даже про «ерундовое 1Кило-ядро» для нормальных людей у них и речь даже не идёт. Всё кормят нас костылями по паре-другой ядер…
> Кластеризоваться должен софт, а не платформа, другими словами. Это мое мнение.
да, так было удобно. но только до тех пор, пока не познакомишься с реальным многоязычным миром, когда всё это «счастье» надо как-то заставить работать вместе :)
скажу честно, тема HA меня не интересовала.
могу подсказать откуда начать копать по OpenSSI: wiki.openssi.org/go/FAQ
(ctrl-f High-availability)
а вот старенькая HA-пэйпа по Kerrighed:
xcr.cenit.latech.edu/hapcw2004/presentation/HAPCW04-Kerrighed.pdf
у обоих SSI-имплементаций HA ставится если и не во главу угла, то и не в чулан задвинут :)
могу подсказать откуда начать копать по OpenSSI: wiki.openssi.org/go/FAQ
(ctrl-f High-availability)
а вот старенькая HA-пэйпа по Kerrighed:
xcr.cenit.latech.edu/hapcw2004/presentation/HAPCW04-Kerrighed.pdf
у обоих SSI-имплементаций HA ставится если и не во главу угла, то и не в чулан задвинут :)
UFO just landed and posted this here
упс, sorry, за ковбойство.
аббревиатура HA практически не имеет разночтений в контексте кластеров и SSI:
en.wikipedia.org/wiki/High_availability
аббревиатура HA практически не имеет разночтений в контексте кластеров и SSI:
en.wikipedia.org/wiki/High_availability
могу сказать как было в моём случае. у меня были тяжелые вычисления. CPU-bound. на обсчёт одних проектов уходили сутки. других почти неделя. после каждого обсчёта делается анализ, корректировка и обсчёт заново.
можете себе представить какой был цикл, и сколько правок можно было успеть. всё было писано в С++, вполне себе оптимизировано. Дальше оптимизировать было себе дороже (код «тяжелел», время затраченное на оптимизации уже давало мизерный выигрыш в результате)
у меня был выбор: пойти на все тяжкие и жениться на PVM/MPI или искать более легкоподъмных решений — и я нашёл в лице OpenSSI.
В результате у меня до появилось около 20 параллельно работающих ядер. То, что обсчитывалось сутки, теперь обсчитывалось за часы. Я успевал делать коррекции несколько раз на день. Проекты, которые должны были «сыграть в ящик» из-за того, что обсчитывались почти неделю получили билет в жизнь. Всё это невероятно изменило режим R&D.
а PoC всем были до задницы, там результаты были нужны :)
можете себе представить какой был цикл, и сколько правок можно было успеть. всё было писано в С++, вполне себе оптимизировано. Дальше оптимизировать было себе дороже (код «тяжелел», время затраченное на оптимизации уже давало мизерный выигрыш в результате)
у меня был выбор: пойти на все тяжкие и жениться на PVM/MPI или искать более легкоподъмных решений — и я нашёл в лице OpenSSI.
В результате у меня до появилось около 20 параллельно работающих ядер. То, что обсчитывалось сутки, теперь обсчитывалось за часы. Я успевал делать коррекции несколько раз на день. Проекты, которые должны были «сыграть в ящик» из-за того, что обсчитывались почти неделю получили билет в жизнь. Всё это невероятно изменило режим R&D.
а PoC всем были до задницы, там результаты были нужны :)
Я правильно понимаю, что между машинами будут раскидываться именно несвязанные между собой процессы? Если java-машина считает в многопоточке, то она толку от этих 100 процессоров не получит? Извините, если вопро глупый.
P.S. Я знаю про gridgain и terracota на всяк случай.
P.S. Я знаю про gridgain и terracota на всяк случай.
Собственно, а что получится в итоге:
— один компьютер (какой, 1 или 2) с двойными ресурсами (процессоры, память, винты)?
— один компьютер с двумя терминалами (клавы, мышки, видео)?
— два компьютера, способных балансировать нагрузку между собой (один сейчас свободен, а другому что-то нужно и перекидывает на второй часть задач)?
— ещё что-то?
— один компьютер (какой, 1 или 2) с двойными ресурсами (процессоры, память, винты)?
— один компьютер с двумя терминалами (клавы, мышки, видео)?
— два компьютера, способных балансировать нагрузку между собой (один сейчас свободен, а другому что-то нужно и перекидывает на второй часть задач)?
— ещё что-то?
Подскажите, такой layout можно использовать для билл-сервера, для распараллеливания компиляции? Используем maven + scala + flex
Компилировать там вообще здорово будет, ведь компиляторы, как правило, однопоточны. В говнолинуксах даже без SSI умеют, distcc называется.
как только что ответил stolen, компилировать там действительно будет приятно, но не столько потому, что компиляторы однопоточны (хотя это действительно будет упрощать миграцию), а потому, что make, который используется чаще всего как верхнеуровневое средство для компиляции, имеет с давних времен опцию "-j", которая отлично ложится на SSI. Проверено :)
а будет ли maven хорошо делать то, что делает «make -j N» — скажите мне, пожалуйста, мне это тоже интересно :)
а будет ли maven хорошо делать то, что делает «make -j N» — скажите мне, пожалуйста, мне это тоже интересно :)
Интересно, поможет ли при рендере из Blender 3d… У нас основной затык в том, что кончается оперативная память…
Правильно ли я понимаю, что из репозитория можно взять только для натти?
память на один процесс не увеличится. но если блендер может обсчитывать ваш проект по кускам, где каждый кусок не требует уже так много памяти и обсчитывается независимым процессом, тогда вполне вероятно и поможет.
для проверки вы можете не дожидаться дебианизированных пакетов, а поднять Kerrighed в простой форме с виртуальных образов как описано на сайте. Можете поэксперементировать с OpenSSI.
для проверки вы можете не дожидаться дебианизированных пакетов, а поднять Kerrighed в простой форме с виртуальных образов как описано на сайте. Можете поэксперементировать с OpenSSI.
А вот вопрос, может и не совсем в тему. Имеется множество процессов работающих с одним буфером памяти. Буфер памяти, что то вроде NoSQL БД типа ключ-значение. Мне не нужна миграция процессов по хостам. Мне нужно только, что бы это буфер был доступен с любого хоста, любым процессом. Такое возможно? Теоретически понимаю, что да. Может, есть готовые решения, что бы не изобретать собственный велосипед.
если я правильно понимаю, Kerrighed и OpenSSI обладают этим свойством:
en.wikipedia.org/wiki/Distributed_shared_memory
но деталей и гарантий дать не могу. вам стоит в их майллистах спросить.
en.wikipedia.org/wiki/Distributed_shared_memory
но деталей и гарантий дать не могу. вам стоит в их майллистах спросить.
А почему бы обычную реляционную базу данных не использовать?
вместо NoSQL?.. — с нетерпеньем жду, что ответит Yak52
:D
:D
Ну или если так уж хочется любую NoSQL, Membase там какой-нибудь или Cassandra?..
Потому что задача для NoSQL СУБД. Если кратко, то это буфер ( Объем, порядка 20 тыс. записей. Каждая запись 100 байт.) для оперативных данных, который заполняется раз в секунду процессом-писателем, с тем же интервалом модифицируется несколькими процессами и считывается третьими процессами, для передачи во внешнюю систему.
Как над другим вариантом решения, если важна производительность, то можно подумать над MPI или чем-нибудь более современным и попроще, ZMQ какой-нибудь например…
Можно в корпоративной сети компании ночью поднимать такой класетер для каких-нибудь мега-задач.
Спасибо за наводку, очень интересно
Спасибо за наводку, очень интересно
Такой вот вопросец от не разбирающегося:
А машины должны быть совместимы по железу?
Допустим у меня один вменяемый сервер и несколько слабеньких рабочих станций. Процессоры разные.
Есть ли возможность их объединить таким образом?
А машины должны быть совместимы по железу?
Допустим у меня один вменяемый сервер и несколько слабеньких рабочих станций. Процессоры разные.
Есть ли возможность их объединить таким образом?
да, машины могут быть разными. но уже если донор — 64битный линукс, то буть добр везде его и принимай.
у меня в своё время как-то было, что я в OpenSSI кластер втыкнул среди сильных машин совсем уж слабую. Так если на неё переезжал какой-нибудь требовательный процесс, то все обсчёты из-за свопинга на слабенькой машине частенько тормозились. Ну тут надо уж глаза открывать
у меня в своё время как-то было, что я в OpenSSI кластер втыкнул среди сильных машин совсем уж слабую. Так если на неё переезжал какой-нибудь требовательный процесс, то все обсчёты из-за свопинга на слабенькой машине частенько тормозились. Ну тут надо уж глаза открывать
Sign up to leave a comment.
Хорошая новость для тех, кому нужен HPC, HA и просто SSI-кластер, наконец