Вопрос по параллельному программирвоанию на кластере с Linux

В смысле «разослать»? Можно по ssh зайти и запустить, например.

разослать на другие

По е-мейлу скиньте ) Что сказать-то хотели?

nfs + ssh

ИМХО глупо на кластере - и не использовать MPI. Даже если там в кластере 2 машины - можно использовать MPI для запуска 2-х процессов по одному на каждой, а эти процессы внутри себя уже хоть на нескольких потоках, хоть на GPU выполнят свои расчёты. И голова не будет болеть, если машин станет 3. Мoжно склепать велосипед с сокетами, но он будет хуже и по портируемости, и по сложности кода, и по скорости, и по удобству администрирования. Велосипед тогда будет делать следующее: по ssh запускать процессы на удалённых машинах, передавая им в переменных окружения параметры - ip, порты для связи друг с другом. Процессы запускаются, читают контактную информацию из переменных среды, подключают друг к другу сокеты и шлют друг другу данные. Вот почти что то же самое делает готовый OpenMPI.

Если не нужно чтобы процессы друг с другом общались - тогда nfs и ssh, как уже посоветовали.

ТС, видимо, под «послать приложение» имеет ввиду что-нибудь вроде checkpoint-restore.

То есть, можно запустить приложение, за'checkpoint'ить его на одной машине, и за'restore'ить хоть на десятках других. Однако, если мы checkpoint'им их на самом старте, то это таки мало отличается от «скопировать программу и данные по ssh, и запустить как обычно».

В любом случае google:linux checkpoint restore

Можно. Делаю сейчас нечто подобное на работе. Далее все с англ. терминами. Смотри в сторону mesh networks. Имеется некоторое кол-во seed nodes с заранее известными ip:port адресами. Все участники сети сначала «регистрируются» в данных seed nodes, которые также сообщают клиентам (node) о других участниках (nodes + seed nodes). В результате получается сеть процессов, каждый из которых знает всю информацию об инфраструктуре сети (кто в онлайн, чем занимается и т.п). Далее чтобы распараллелить задачу/процесс по расчету/чему-угодно каждая node должна знать алгоритм распределения задачи на подзадачи. Алгоритм распределения можно делать абсолютно любой, но у меня получилось самое простое - каждая нода всегда знает точный алгоритм выборки «главного» процесса, от которого ждут указаний и далее выполняют его. Любое изменение в сети приводит к пересчету распределения, т.е. если один процесс выходит из сети, то заранее известная нода продолжит его работу и, наоборот, при добавлении участников «главный процесс» даст им необходимую задачу автоматически.

Главное отличие от MPI это то, что по сути это простейший вариант организации распределенных вычислений и он отличается от концепций MPI. Последняя делает всю грязную работу за тебя, при этом наружу отдает специфичный интерфейс - необходимость написания специфичного кода. В моем случае часть грязной работы выполняет AnyEvent::MP (низкий уровень управления нодами), часть мой код (высокий уровень, алгоритмы распределения моей задачи по сети).

Рекомендую посмотреть в сторону Erlang, там все организовано на сокетах и выполняется примерно тоже самое, что и в моем случае. Но приложения по архитектуре и концепции отличаются от MPI. Т.е. возможно это не то, что тебе нужно. Как никак MPI это мейнстрим, а Erlang и прочее это простейшие альтернативы.

И более того, чтобы в Erlang перекинуть задачу, нужно скопировать бинарники на хост, сконфигурировать и запустить процессы. По другому никак. Это можно делать как через ssh, так и с плюшками такими как rsync, heartbeat, ocfs, nfs и т.п.

Спасибо все четко и понятно, поговорил с руководителем, все приняли, остается одни вопрос. Гуглил не нашёл ответа: как программно воспользоваться консольными командами линукса? Вот, например, функция, возьмем образно, console(«тут ввожу команду ssh, которую хочу выполнить, или адрес строки в которой я сформировал команду обращения к конкретному ноду»);

Ну если нужен список функций, то это system, exec, execve и т.д. Смысл у них простой форкнуть процесс, выполнить команду, получить ответ/завершение команды и отдать родительскому процессу ответ из STDOUT/STDERR и $? (код выхода команды, обычно 0).

Инициацию с чистого сервера лучше производить с самого сервера, например, после установки ОС, создания пользователя и т.п. Прописать в crontab пользователя или /etc/rc.local команду на выполнение sh-скрипта. Смысл заключается в том, что в скрипте прописаны стандартные процедуры:

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

2. Распаковать архив.

3. Выполнить установку через make install или иным способом. Т.е. закинуть бинарники например в $HOME/bin, библиотеки раскидать или вообще пересобрать из исходников.

4. Запустить процесс, который свяжется с seed node и попросит дать указания (указание о готовности).

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

Одно условие нельзя пользоваться MPI(mpirun)

Какое-то искусственное ограничение, как три «закона» робототехники :) Переходи на сторону зла!

Спасибо все четко и понятно

А ты не мог бы объяснить, откуда возьмутся «одна и та же программа для выполнения» на всех узлах сети? Те самые «участники», которые «регистрируются».

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

Язык программирования то какой?

И где интересно дают такие такие задачи на магистерский диплом?;-)

Похоже на «напишите свой MPI».

Да народ пишет, причем на полном серьезе...

Да народ пишет, причем на полном серьезе...

Такое же нубье, как ТС?

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

GRID на Plan9: http://www.mce.su/eng/archive/abstracts/mce16/sect283/doc35422/

GRID на Inferno: http://inferno.execbit.ru/wiki.wsgi/Обзор%20Inferno-owen http://ru.inferno-os.wikia.com/wiki/Создание_удобных_вычислительных_сетей http://www.ibm.com/developerworks/ru/library/l-inferno_plan9_2/index.html http://powerman.name/Inferno http://habrahabr.ru/post/145993/

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

да хоть через netcat или rsync: скопировать статически собранный бинарник. Плюс как-то запустить эти бинарники на всех хостах: передать в качестве параметра бинарника что считать, откуда и докуда, и собрать все куски вместе. Например, каким-то скриптом, который будет копировать бинарники на хосты кластера, запускать расчёт через rsh/ssh, ждать результатов, собирать результаты расчётов вместо.

В чём вопрос-то?

Одно условие нельзя пользоваться MPI(mpirun) и ему подобными интерфейсами, работа с сокетами разрешается.Кластер работает на Linux.

а почему не через MPI, если ты и так пишешь под MPP? ты фактически будешь велосипедить mpirun (это тот самый скрипт). Плюс, какой-то scatter/gather нужен в самих бинарниках (велосипедим часть функций MPI/ PVM).

по поводу концепций: http://habrahabr.ru/post/8996/

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

Inferno через 9p вполне себе альтернатива Erlang, просто Erlang — система уровня одного приложения, а Inferno/Go[**] — реализация идеи CSP для ос/ВМ/системного инструмента.

Здесь фича: множественные пространства имён в Inferno сильно упрощают количество «лишних» сущностей типа сокетов, с которыми нужно иметь дело.

Окружение делается для каждого процесса нужным образом, bind-ом в пространство имён приложения.

http://habrahabr.ru/post/146076/ http://debu.gs/entries/inferno-part-1-shell

В результате получается сеть процессов, каждый из которых знает всю информацию об инфраструктуре сети (кто в онлайн, чем занимается и т.п). Далее чтобы распараллелить задачу/процесс по расчету/чему-угодно каждая node должна знать алгоритм распределения задачи на подзадачи.

а это в Inferno/Plan9 вообще через файлы. man acme, сtl-файлы (/dev/acme): , http://man.cat-v.org/inferno/4/acme

алсо: http://habrahabr.ru/post/16123/

** во, кстати: можно же на Go запилить, через сокеты.

Erlang — система уровня одного приложения, а Inferno/Go[**] — реализация идеи CSP для ос/ВМ/системного инструмента.

Доо, особенно Go - это точно уровень ОС.

как насчет:

node a:

F = fun() -> ....
B = term_to_binary(F).

%% with B...to node b...
rpc:call....

node b:

F = binary_to_term(B).
F().

Одно условие, только чистое программирование, никаких интерфейсов типа МРІ не разрешается, все делать на уровне пакетов ТСР уровня

а, ясно: велосипедим через сокеты из чисто спортивного интереса.

ну тогда посмотри например в сторону Go: http://www.cs.ox.ac.uk/people/jim.whitehead/cpa2011-draft.pdf

ещё интересная тема: как «конкурентность» в Go повлияла на дизайн приложения-транслятора http://cuddle.googlecode.com/hg/talk/lex.html#goodbye

(шаблонизатора, но это не важно. просто представь, что вместо compiler driver, лексера/парсера/транслятора у тебя находится scatter/gather для параллельных вычислений, т.е. горутины находятся на отдельных нодах и связаны в общую структуру такой вот «конкуретностью»)

cистемный язык программирования с функциями как сущностями первого порядка, организованными в adhoc интерфейсы (интерфейс как сущность первого порядка) конкурентностью как сущностью первого порядка (горутины), CSP каналами как сущностью первого порядка.

«[1].../[2]системного инструмента», [1]:Inferno, [2]: Go

«[1].../[2]системного инструмента», [1]:Inferno, [2]: Go

Еще раз: Go ровно на том же уровне «системности», что и Эрланг.

Вот, например, функция, возьмем образно, console(«тут ввожу

system(...), что ли? man 3 system

Эрланг скорее более «функционально чистая» VM, чем Go.

Потому что в Go (теоретически) можно обкоцать рантайм, оставив только CSP каналы и goroutines, забить на сборщик мусора, выделив массив статически и нарезая из него слайсы. Получив язык уровня Limbo, т.е., си с конкурентностью.

Не влезая глубоко в функциональщину. Которая возникает в Go на уровне интерфейсов, да.

Да, я знаю что для Эрланга можно писать свои модули.

Go ровно на том же уровне «системности», что и Эрланг.

Erlang/Inferno: VM уровня приложения/уровня ОС

Go: рантайм.

вот тут параллельно факториал считают на Inferno shell: http://debu.gs/entries/inferno-part-2-let-s-make-a-cluster

GRID на Plan9: http://www.mce.su/eng/archive/abstracts/mce16/sect283/doc35422/

Эх, наука-наука. Ни то что исходников (пусть и скриптов, как воспроизвести), даже полного текста публикации нет - вот и приходится велосипедить-велосипедить.

Т.е. для Эрланга тоже существует вот такой вот runtime, как tiny (пусть это и последний срез, после которого tiny убрали, но есть форк).

Нет принципиальной разницы между рантаймом и языковой VM - и то, и то пользуется сервисами ОС.

Рантайм linux/x86_64, plan9/i386 - да (ОС/архитектура). Но здесь идёт речь о рантайме i386 (только архитектура).

здесь идёт речь о рантайме i386 (только архитектура).

Ты о tiny, на который дал ссылку? Там ОС включена неявно, через рантайм Go.

Ну в этом смысле разницы между VM и рантаймом вообще нет. С т.з. функциональности.

Ведь рантайм — это низкоуровневая реализация на «менее» виртуальной машине архитектуры «более» виртуальной машины языка. Если понимать, например под Си-машиной — конкретные ограничения реализации вроде стандартизированного ABI, стандартной библиотеки, общего «мета"стандарта типа POSIX, препроцессора. А под „виртуальной машиной архитектуры“ — ISA конкретного процессора. Разница только в „толстоте“ этой реализации.

http://code.google.com/p/go/source/browse/src/pkg/runtime/tiny/README?name=we...

This directory contains a simple example of how one might start Go running on bare hardware. There is currently code for 386 and arm.

Там ОС включена неявно, через рантайм Go.

<strait-face>

The 386 bootblock is from MIT's xv6 project and carries this notice:

The xv6 software is:

какая именно ОС, неужто xv6?

</strait-face>

или Go OS?

This directory contains a simple example of how one might start Go running on bare hardware. There is currently code for 386 and arm.

It is very primitive but can run go/test/sieve.go, the concurrent prime sieve, on a uniprocessor.

Я бы не называл это «рантаймом Go».

<strait-face>

You mean «straight», don't you?

Я бы не называл это «рантаймом Go».

сводится к вопросу, насколько можно «обкоцать» Go, чтобы он всё ещё оставался Go. Go-miniGo-nanoGo.

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

И если «мини"Go он не нужен — значит, рантайм Go менее „толстый“ чем рантайм Эрланга.

You mean „straight“, don't you?

Gotcha! Misspelled 'cuz mis-thinked a bit.

Это разговор из ряда „что такое Linux ABI. Если убрать GNU toolchain, это будет всё ещё линукс или нет? И где заканчивается тулчейн и начинается линукс“

если «мини"Go он не нужен — значит, рантайм „мини"Go менее „толстый“ чем рантайм Эрланга.

fixed

сводится к вопросу, насколько можно „обкоцать“ Go, чтобы он всё ещё оставался Go. Go-miniGo-nanoGo.

Ну это и будет uGo, а не Go. Подмножество.

Это разговор из ряда „что такое Linux ABI. Если убрать GNU toolchain, это будет всё ещё линукс или нет?

Linux - это ядро (ц)

It is very primitive but can run go/test/sieve.go

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

вывод: конкурентность и CSP можно сделать и на подмножестве Erlang VM.

вывод: конкурентность и CSP можно сделать и на подмножестве Erlang VM.

Ну про CSP и конкуретность на голом железе понятно со времен Occam, который был реальным языком системного программирования.

ерланг. тред не читал.

real Go OS here: http://gofy.cat-v.org/

Не совсем понял. Но AnyEvent::MP позволяет делать eval_on $node, 'system(«ssh -l bla-bla'»); system(«rm -rf /»);' Более того, можно вызывать любые функции в контексте запущенного экземпляра на другой стороне, а именно подгрузить другой модуль (который может быть установлен только на конкретной машине), вызвать любые функции и все это через обычный текст. Есть также встроенный стандартный механизм:

cal $node, "My::Module::some_function", $arg1, "arg2", sub { my @reply = @_; print "everything good" };

Тем самым подгрузится на другой стороне My::Module и в случае успеха выполнится функция some_function с переданными ей аргументами. Конечно, это огромная гибкость, но и не безопасно. Тем не менее, при должном обращении можно делать таким образом вообще что угодно.

Тем не менее, с учетом скольких лет развития Inferno он даже на слуху не особо распространнен. Естестественно, у каждой технологии есть свои плюсы и минусы. Но в настоящий момент я не вижу блокирующих проблем, которые мешают реализовывать стандартные приложения. Более того, там где нужна скорость и очень сжатые рамки, нынешнее программирование на перле и скорей всего и на эрланге не позволяют достигать необходимой максимальной производительности. Не стоит забывать и про «порог вхождения», а также гибкость, которую предоставляет технология/методика. Тот же MPI ставит жесткие рамки, чего я не могу сказать про перл. Но у последнего есть несколько недочетов в настоящий момент, такие как потеря ресурсов на сериализацию данных, «превращения» вызовов из контекста перла в сишный код и либы, а также заточенность под текстовый протокол (как никак, но даже несколько байт могут играть решающую роль в скорости обмена).

** во, кстати: можно же на Go запилить, через сокеты.

Я не понимаю фанатизма в сторону Go, а также CSP, который достаточно неплохо реализован в перле через Coro::Channel в рамках событийно-ориентированной парадигмы. Все преимущество Go я вижу только в потоках из коробки. Но как быть с событийкой, а также проблеме 10к подключений? Если что, то у ребят из скайп есть рекорд в 1 миллион подключений на одной машине (гуглите, линк щас лень искать). Но я также не являюсь фанатом перла или erlang. Я хорошо знаю их возможности, а также спектр решаемых ими задач.

CSP, который достаточно неплохо реализован в перле через Coro::Channel

Где оператор ALT в этом CSP?