Комментарии 64
Это невероятно круто, пора учить эрланг.
НЛО прилетело и опубликовало эту надпись здесь
Они даже в статье упомянуты :) Есть еще много сходных проектов, и будет все больше и больше, я надеюсь.
НЛО прилетело и опубликовало эту надпись здесь
Для других языков, очевидно. Не всем интересно учить новый язык ради такой штуки, еще меньшему числу людей интересно набирать новый персонал и переписывать существующий код
А вот реализация для ЯП на котором ведется разработка может здорово подтолкнуть к переходу на подобную технологию. Особенно, если какой нибудь Амазон подхватит.
А вот реализация для ЯП на котором ведется разработка может здорово подтолкнуть к переходу на подобную технологию. Особенно, если какой нибудь Амазон подхватит.
Убрать OS из виртуалок — это закономерный эволюционный шаг для облаков. OS — это, в основном, менеджер ресурсов, облака добавляют свою специфику, для которой серверные OS не очень-то и подходят. Логичнее «размазать» функционал операционки по облаку, убрав таким образом ограничения по масштабированию и добавив функционала и управляемости. Как говорил Sun, царствие ему небесное: «наш компьютер — это сеть».
А раз уж Вам интересно веб-программирование, могу похвалить фреймворк Chicago Boss: github.com/evanmiller/ChicagoBoss
Спасибо, обязательно посмотрю. Но мое знание эрланга на данный момент ограничивается «слышал, что круто». Мне бы чего-нибудь совсем для новичков. Ну, учитывая, что опыт самого по себе программирования у меня есть (perl, ruby, javascript, php).
Erlang — язык без эзотерики, учится легко. Опыт многочисленных коллег говорит о том, что от полной несознанки до написания кода в проект у не боящегося клавиатуры разработчика проходит максимум недель шесть.
Шесть недель полного времени, или с учетом того, что у человека еще есть обычная работа?
С учетом неавральной текучки. Лев Валкин в своем незабываемом докладе упоминал даже меньшие сроки — lionet.info/pdf/2010-lev-walkin-erlang-experience.pdf
В общем, бывает по разному, но больше 6ти недель никогда не было…
В общем, бывает по разному, но больше 6ти недель никогда не было…
Erlang, несмотря на свою некоторую необычность синтаксиса, на удивление легок в усвоении. Для меня прогать на Erl — просто удовольствие, а самое главное практически любой код (особенно если он OTPшный) можно с ходу разобрать и понять как он работает. Такого нет ни в одном ЯП.
Наконец-то нашлось что изучить на праздниках!
А можно уточнить, idle приложение на таком эрланге так же как и linux-версия в пустом цикле занимается непонятно чем?
Я как-то на простаивающее приложение на erlang strace запустил — и был крайне удивлён тому срачу, который творится.
Я как-то на простаивающее приложение на erlang strace запустил — и был крайне удивлён тому срачу, который творится.
В Ling всякой этой суеты значительно поменьше — все-таки характер взаимодействия с окружением совершенно иной, да и сам по себе Ling — штука однопоточная, избавленная от необходимости жонглирования тредами.
НЛО прилетело и опубликовало эту надпись здесь
Я как раз смотрел, чем обычно занимается ядро, когда простаивает в зене. Ответ: только таймеры обновляет, да на события реагирует. А вот strace на первый попавшийся эрланговый простаивающий сервер показывает срач, какого ядро не видело — каждый тред имеет своим желанием проснуться и заснуть, причём несколько раз в секунду.
Если он с такой же скоростью насилует гипервизор гиперколлами, то ничего хорошего в этом нет.
Если он с такой же скоростью насилует гипервизор гиперколлами, то ничего хорошего в этом нет.
А зачем бы ему так так нехорошо поступать с гипервизором? Тем более, что тред там один, он же единственный.
Ну, видимо, по той же причине, почему он «так нехорошо» поступает в линуксе. А вот зачем он так поступает в линуксе (по сравнению с обычными приложениями, которые в серверном режиме epoll'ятся и молчат, пока что-нибудь не случится) — я не знаю.
В линуксе — это не «он», там Эриксоновский BEAM. Тут свой Erlang VM (aka Ling, что по-китайски значит «ноль»), от BEAM'а совершенно отдельный, ничего общего (помимо формата .beam файлов) с ним не имеющий.
Ну, надеюсь.
Кстати, а как у этой виртуалки с всем тем, что приличная виртуалка должна уметь делать? Балунинг, саспенд при миграции, поддержка memory hotplug, cpu hotplug и т.д…
Кстати, а как у этой виртуалки с всем тем, что приличная виртуалка должна уметь делать? Балунинг, саспенд при миграции, поддержка memory hotplug, cpu hotplug и т.д…
НЛО прилетело и опубликовало эту надпись здесь
TCP/IP внутри свой (сейчас — на базе LwIP), файловые системы импортируются по 9p, и по 9p же и экспортируются, для того чтобы наладить связь с внешней ФС гиперусилий прилагать не приходится — поднял инстанс (или несколько) diod'a (http://code.google.com/p/diod/) — и поехали.
Кое-что по списку не нужно — cpu hotplug, например, часть допиливается (memory hotplug), хотя ценность такого шага сомнительна. С малой стартовой латентностью бывает проще прибить ноду и запустить другую (или даже несколько), как это не непривычно звучит. С саспендом, по ходу, проблем не было — ВМ, в принципе, в курсе, что она работает не на реально железе, от этого отсутствует потребность в камланиях по обрботке аппаратных прерываний и тп. Без всех этих нюансов миграция становится значительно проще.
Мне кажется, что область применения приложения, которое надо убивать для изменения настроек, несколько ограничена. Например, у нас в продакте in-memory-database на эрланге, и если её «просто прибить», то она «просто не сохранит данные» на диск. Со всеми вытекающими.
Там же концепция «let it crash»
Это смотря как сделано. Вряд ли разумно делать базу без реплицирования, а с нормальным реплицированием прибивание/умирание — вполне себе штатаная ситуация.
Речь не про аварийные ситуации, а про изменение настроек. Надо добавить памяти — завершились, скачали заново 20-30Гб данных? Выглядит странно.
Особенно с учётом того, что нет никакой причины не поддерживать hotplug. Тем паче, что это даже не «hotplug», а просто трансфер дополнительных страниц памяти в домен.
Линукс из этого устраивает потанцульки с «memory hotplug» только из-за того, что есть готовая инфраструктура (железных серверов). В контексте «pure PV» это мало отличается от sbrk() для приложения.
Особенно с учётом того, что нет никакой причины не поддерживать hotplug. Тем паче, что это даже не «hotplug», а просто трансфер дополнительных страниц памяти в домен.
Линукс из этого устраивает потанцульки с «memory hotplug» только из-за того, что есть готовая инфраструктура (железных серверов). В контексте «pure PV» это мало отличается от sbrk() для приложения.
вот специально проверил: ничего не творится на простаивающем приложении, так что ваше приложение походу не простаивало.
Просто для проверки, strace с ключом -f запускался? strace -f -p <beam.smp-pid>, так?
нет, я запускал просто с -xp (-smp disabled не порождает дочерних процессов)
но и с -fxp разницы не вижу — idle процесс не делает никаких сисколов, с smp или без него
но и с -fxp разницы не вижу — idle процесс не делает никаких сисколов, с smp или без него
А вот это уже интересно. В каком приложении?
Я думал это наши криворукие товарищи сделали так, поставил первое попавшееся приложение (yaws) на эрланге из дебиановского репозитория. В нём срач практически повторился.
Вот strace для beam.smp при запущенном и простаивающем yaws'е (фрагмент):
[pid 23463] clock_gettime(CLOCK_MONOTONIC, <unfinished ...>
[pid 23448] waitpid(-1, <unfinished ...>
[pid 23463] <… clock_gettime resumed> {275666, 438284842}) = 0
[pid 23444] futex(0x8268d04, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...>
[pid 23463] gettimeofday({1356430887, 743888}, NULL) = 0
[pid 23442] read(6, <unfinished ...>
[pid 23463] clock_gettime(CLOCK_MONOTONIC, <unfinished ...>
[pid 23439] select(0, NULL, NULL, NULL, NULL <unfinished ...>
[pid 23463] <… clock_gettime resumed> {275666, 438552027}) = 0
[pid 23463] gettimeofday({1356430887, 744183}, NULL) = 0
[pid 23463] epoll_wait(3, {}, 256, 1310) = 0
[pid 23463] clock_gettime(CLOCK_MONOTONIC, {275667, 750678807}) = 0
[pid 23463] gettimeofday({1356430889, 56367}, NULL) = 0
[pid 23463] clock_gettime(CLOCK_MONOTONIC, {275667, 751163577}) = 0
[pid 23463] gettimeofday({1356430889, 56836}, NULL) = 0
[pid 23463] clock_gettime(CLOCK_MONOTONIC, {275667, 751557798}) = 0
[pid 23463] gettimeofday({1356430889, 57177}, NULL) = 0
[pid 23463] time(NULL) = 1356430889
[pid 23463] epoll_wait(3, {}, 256, 0) = 0
(повтор 100500 раз)
Я думал это наши криворукие товарищи сделали так, поставил первое попавшееся приложение (yaws) на эрланге из дебиановского репозитория. В нём срач практически повторился.
Вот strace для beam.smp при запущенном и простаивающем yaws'е (фрагмент):
[pid 23463] clock_gettime(CLOCK_MONOTONIC, <unfinished ...>
[pid 23448] waitpid(-1, <unfinished ...>
[pid 23463] <… clock_gettime resumed> {275666, 438284842}) = 0
[pid 23444] futex(0x8268d04, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...>
[pid 23463] gettimeofday({1356430887, 743888}, NULL) = 0
[pid 23442] read(6, <unfinished ...>
[pid 23463] clock_gettime(CLOCK_MONOTONIC, <unfinished ...>
[pid 23439] select(0, NULL, NULL, NULL, NULL <unfinished ...>
[pid 23463] <… clock_gettime resumed> {275666, 438552027}) = 0
[pid 23463] gettimeofday({1356430887, 744183}, NULL) = 0
[pid 23463] epoll_wait(3, {}, 256, 1310) = 0
[pid 23463] clock_gettime(CLOCK_MONOTONIC, {275667, 750678807}) = 0
[pid 23463] gettimeofday({1356430889, 56367}, NULL) = 0
[pid 23463] clock_gettime(CLOCK_MONOTONIC, {275667, 751163577}) = 0
[pid 23463] gettimeofday({1356430889, 56836}, NULL) = 0
[pid 23463] clock_gettime(CLOCK_MONOTONIC, {275667, 751557798}) = 0
[pid 23463] gettimeofday({1356430889, 57177}, NULL) = 0
[pid 23463] time(NULL) = 1356430889
[pid 23463] epoll_wait(3, {}, 256, 0) = 0
(повтор 100500 раз)
ну сейчас мы говорим о несколько разных вещах. idle приложение это то, которое ничего не делает (ну типа просто erl запустили, или timer:sleep(100000), или пустой цикл гоняем)
судя по strace в данном случае — это асинхронная работа с сокетами, делается именно так, как видно в логах (там в любом случае присутствует внешний луп, что бы генерировать события), если взять любое приложение с асинхронными сокетами, на любом языке — будет точно такая же картина (возьмите приложение с boost.asio или twisted, и там будет картинка 1 в 1), с poll будет еще красивее и чаще
судя по strace в данном случае — это асинхронная работа с сокетами, делается именно так, как видно в логах (там в любом случае присутствует внешний луп, что бы генерировать события), если взять любое приложение с асинхронными сокетами, на любом языке — будет точно такая же картина (возьмите приложение с boost.asio или twisted, и там будет картинка 1 в 1), с poll будет еще красивее и чаще
Я не понимаю, почему для использования epoll нужно всё время просыпаться. Тот же nginx, например, прекрасно спит пока что-нибудь в сокет не прилетит.
Более того, epoll для того и делался, чтобы не надо было всё время просыпаться и проверять «нет ли там чего нового».
ЗЫ Можно примеры приложений (кроме erlang) в которых подобная порнография наблюдается? А то я пока такое только у beam.smp видел.
Более того, epoll для того и делался, чтобы не надо было всё время просыпаться и проверять «нет ли там чего нового».
ЗЫ Можно примеры приложений (кроме erlang) в которых подобная порнография наблюдается? А то я пока такое только у beam.smp видел.
ну, из самого простого — nginx (натравливаем на слушающий спящий процесс, пид из netstat -lntp | grep nginx):
strace -xfp 17624
Process 17624 attached — interrupt to quit
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
тут конечно почище, но в целом тоже не фонтан (его то оптимизировали по сисколам), в эрланге еще таймер дергают.
strace -xfp 17624
Process 17624 attached — interrupt to quit
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
epoll_wait(7, {}, 512, 500) = 0
тут конечно почище, но в целом тоже не фонтан (его то оптимизировали по сисколам), в эрланге еще таймер дергают.
О, кстати, я только один воркер смотрел у nginx (master и первый, запущенный от пользователя www-data). У тех вообще тишь да гладь. У последующих воркеров — да, есть что-то подобное.
Спасибо за информацию, я буду меньше на эрланг хмуриться.
Спасибо за информацию, я буду меньше на эрланг хмуриться.
я так понимаю, у вас там довольно активно используют эрланг. собственно в рассылке есть попытки оптимизаций epoll_wait, типа erlang.org/pipermail/erlang-questions/2012-July/067871.html
но тут надо ясно себе представлять почему писалось именно так, как есть сейчас, и потом не
но тут надо ясно себе представлять почему писалось именно так, как есть сейчас, и потом не
Если accept_mutex отключить, то с любым количеством воркеров будет тишина. В случае одного воркера accept_mutex отключается автоматически.
accept_mutex_delay — и задает эти самые 500мс.
accept_mutex_delay — и задает эти самые 500мс.
однако есть еще:
en.wikipedia.org/wiki/Thundering_herd_problem
en.wikipedia.org/wiki/Thundering_herd_problem
Разумеется. Но вы выше написали "тут конечно почище, но в целом тоже не фонтан", а я объяснил от чего так, и что отключить, если хочется совсем чисто.
Если у вас по полчаса нету соединений, то перманентно спящие процессы, но пробуждающиеся разом, возможно более приемлимый вариант, чем периодически просыпающиеся, чтобы узнать, а не пора ли приниматься за работу.
Вопрос компромиссов. От nginx-а можно получить то поведение, которое хочется. Да и его рабочих процессов обычно запускают не более, чем ядер в системе.
Если у вас по полчаса нету соединений, то перманентно спящие процессы, но пробуждающиеся разом, возможно более приемлимый вариант, чем периодически просыпающиеся, чтобы узнать, а не пора ли приниматься за работу.
Вопрос компромиссов. От nginx-а можно получить то поведение, которое хочется. Да и его рабочих процессов обычно запускают не более, чем ядер в системе.
собственно если почитать man epoll_wait то можно увидеть, что четвертым параметром идет таймаут, в эрланге = 0, в nginx'e = 500 (в моей установке).
разница тут только в том, что в эрланге надо делать еще кучу работы, помимо того, что бы слушать сокеты, а в nginx — больше ничего делать не надо, и даже возможно можно и этот таймаут увеличить до несколько больших чисел (потеряв при этом скорость ответа, хотя на нагруженном сервере, это не важно — быстрее наберется количество эвентов, чем истечет таймаут, в общем не суть).
разница тут только в том, что в эрланге надо делать еще кучу работы, помимо того, что бы слушать сокеты, а в nginx — больше ничего делать не надо, и даже возможно можно и этот таймаут увеличить до несколько больших чисел (потеряв при этом скорость ответа, хотя на нагруженном сервере, это не важно — быстрее наберется количество эвентов, чем истечет таймаут, в общем не суть).
Вот меня это и смущает — почему приложение, которое работает веб-сервером должно делать «кучу работы, помимо того, чтобы слушать сокеты»? Я специально сравнивал yaws и nginx, которые оба веб-серверы.
в двух словах, дело получается в том, что приложение на эрланге, это не просто такая же штука, как и написанное приложение на C/CPP/python/etc, но и еще довольно навороченная виртуальная машина, которая делает много работы под капотом (в С приложение делает в принципе только то, что ты ему скажешь делать)
у Льва Валкина есть хорошие статьи на тему эрланга и специализированных задач lionet.livejournal.com/84884.html и lionet.livejournal.com/88113.html
у Льва Валкина есть хорошие статьи на тему эрланга и специализированных задач lionet.livejournal.com/84884.html и lionet.livejournal.com/88113.html
НЛО прилетело и опубликовало эту надпись здесь
Я пробовал Erlang on Xen — но пока к сожалению проект крайне сырой что выражается в:
— нету возможности установить бинарные дополнения
— файловая система только build-in что не совсем хорошо, ведь для облака нужно монтирование удаленной ФС как локальной
— нету API для получение внутренних системных структур — т.е. произвести интроспекцию
— (раньше) была проблема с 64-битным режимом — т.е. аллоцировании более 4GB RAM
P.S. жалко что автор проекта молчит на хабре, чата на сайте нету, и форума тоже
— нету возможности установить бинарные дополнения
— файловая система только build-in что не совсем хорошо, ведь для облака нужно монтирование удаленной ФС как локальной
— нету API для получение внутренних системных структур — т.е. произвести интроспекцию
— (раньше) была проблема с 64-битным режимом — т.е. аллоцировании более 4GB RAM
P.S. жалко что автор проекта молчит на хабре, чата на сайте нету, и форума тоже
Проект в активной разработке, естественно, многие фичи еще сыроваты, кое-что критичное вообще еще в паблик версии не выкатывалось — например межнодовое взаимодействие.
Форумы-чаты со временем будут, конечно же.
Форумы-чаты со временем будут, конечно же.
1. Совместимость обеспечивается только на уровне языка Erlang. Другие интерфейсы, такие как NIF или, тем более, Posix, добавить практически невозможно. Компоненты, которые их требуют, должны выполняться в отдельных Xen VM.
2. Файловая система полностью переработана. Она допускает гибкое монтирование удаленных и локальных систем. Подход похож на Plan9/Inferno. Новая файловая система включена в public Amazon AMI.
3. API для интроспекции есть, но не такой развитый как в BEAM и несовместимый с ним. Параметры в правом верхнем углу окна при работе с public AMI как раз показывают результаты интроспекции.
4. Основная версия сейчас — 64-битная (32-битная также поддерживается). Используется подход похожий на «half-word heap» в BEAM: память процессов ограничена 4Гб, но ETS данные могут использовать память свыше 4Гб. Мы ориентируемся на размер памяти инстанса — 512Мб.
Авторы активно пишут: vsovetov — ключевой человек в проекте.
2. Файловая система полностью переработана. Она допускает гибкое монтирование удаленных и локальных систем. Подход похож на Plan9/Inferno. Новая файловая система включена в public Amazon AMI.
3. API для интроспекции есть, но не такой развитый как в BEAM и несовместимый с ним. Параметры в правом верхнем углу окна при работе с public AMI как раз показывают результаты интроспекции.
4. Основная версия сейчас — 64-битная (32-битная также поддерживается). Используется подход похожий на «half-word heap» в BEAM: память процессов ограничена 4Гб, но ETS данные могут использовать память свыше 4Гб. Мы ориентируемся на размер памяти инстанса — 512Мб.
Авторы активно пишут: vsovetov — ключевой человек в проекте.
1) по поводу POSIX не думаете сделать псевдоэмуляцию? NIF думаю не очень нужен — в этом полностью согласен
2) где можно почитать про встроенную ФС? Также используется 9P
3) планируется ли поддержка кого-либо кроме Amazon — ведь не все же используют Public Cloud — и много у кого есть Private Cloud
4) по поводу интроспеции видно Я что-то упустил — посмотрю в будущем
5) какой уровень поддержки mnesia — можно ли там хранить более 4GB? Как с масштабируемостью на лету (on-the-fly) — например ресайз с 128MB до 4GB блоками по 128MB? (больше интересует рост вверх без остановки — благо Erlang это может)
Спасибо за пояснение :)
2) где можно почитать про встроенную ФС? Также используется 9P
3) планируется ли поддержка кого-либо кроме Amazon — ведь не все же используют Public Cloud — и много у кого есть Private Cloud
4) по поводу интроспеции видно Я что-то упустил — посмотрю в будущем
5) какой уровень поддержки mnesia — можно ли там хранить более 4GB? Как с масштабируемостью на лету (on-the-fly) — например ресайз с 128MB до 4GB блоками по 128MB? (больше интересует рост вверх без остановки — благо Erlang это может)
Спасибо за пояснение :)
Про псевдоэмуляцию не очень понятно. Поясните.
По ФС в Erlang on Xen должна появится публичная презентация. В Plan 9 карта монтирования разная для каждого процесса, также разрешены union mounts, в Linux — она глобальная и union mounts не поддерживаются. Erlang on Xen ближе к Plan 9.
Мы поддерживаем Xen. Поэтому для запуска инстансов можно использовать Amazon или любого другого провайдера, который использует Xen.
По mnesia данных нет. В данный момент несколько человек пытаются запускать разные известные приложения на Erlang on Xen, но Мнезии пока среди них нет.
По ФС в Erlang on Xen должна появится публичная презентация. В Plan 9 карта монтирования разная для каждого процесса, также разрешены union mounts, в Linux — она глобальная и union mounts не поддерживаются. Erlang on Xen ближе к Plan 9.
Мы поддерживаем Xen. Поэтому для запуска инстансов можно использовать Amazon или любого другого провайдера, который использует Xen.
По mnesia данных нет. В данный момент несколько человек пытаются запускать разные известные приложения на Erlang on Xen, но Мнезии пока среди них нет.
Псевдоэмуляция POSIX это — эмуляций функций как I/O (fopen), socket (bind, listen), Process (prctl, ...) и т.д. — поскольку EonX является псевдоОС — то поэтому сделать прямой проброс этих функций невозможен, поэтому имеет смысл сделать функции обертки которые могли быть реализовывать виртуальный функционал.
Кролик Bunny это хорошо — планируется ли двустронние сервисы? Как например есть в Inferno — когда сетевой объект ассоциирован с внутренним функционалом? Также вопрос безопасности — планируете реализовать также тикеты для авторизации по внутренней ФС?
По поводу системы сборки — не планируете ли упростить ее до вида — zip архива? т.е. к основному образу EonX в конец пристыковывается архив с исходными текстами, и дальше при загрузке виртуальное ядро монтирует zip как ro фрагмент fs и запускает главный файл исходя из манифеста приложения (Application)?
Также по поводу самой машины — как сейчас обстоят дела с erlpd (межнодное взаимодействие) — совместим ли с нативным erlang (BEAM или HiPE), если ли возможность НЕ на уровне Xen управлять статусом — start, stop, restart, suspen — и также мониторинг здоровья инстанца, например внутренних структур?
По mnesia могу предоставить примеры на тесты — т.к. мне проект интересен.
Кролик Bunny это хорошо — планируется ли двустронние сервисы? Как например есть в Inferno — когда сетевой объект ассоциирован с внутренним функционалом? Также вопрос безопасности — планируете реализовать также тикеты для авторизации по внутренней ФС?
По поводу системы сборки — не планируете ли упростить ее до вида — zip архива? т.е. к основному образу EonX в конец пристыковывается архив с исходными текстами, и дальше при загрузке виртуальное ядро монтирует zip как ro фрагмент fs и запускает главный файл исходя из манифеста приложения (Application)?
Также по поводу самой машины — как сейчас обстоят дела с erlpd (межнодное взаимодействие) — совместим ли с нативным erlang (BEAM или HiPE), если ли возможность НЕ на уровне Xen управлять статусом — start, stop, restart, suspen — и также мониторинг здоровья инстанца, например внутренних структур?
По mnesia могу предоставить примеры на тесты — т.к. мне проект интересен.
Такую эмуляцию мы не планируем. Мы предполагаем, что типичное приложение будет использовать сотни относительно короткоживущих инстансов. Некоторые из них могут выполнять код, который требует POSIX, используя Linux.
Большинство «файлов», которые раздаются по 9P, — синтетические. Например, каждый node экспортирует директорию /proc и запись в файл /proc/1 вызывает посылку сообщения процессу <0.1.0>. Для аутентификации мы используем MUNGE (монтирование из Linux) и MUMBLE (между нодами Erlang on Xen). Схема MUMBLE описана здесь.
Практически сборка образа так и происходит, только без использования компрессии. Есть и аналог манифеста приложения.
Уровень кластеризации прошел этап концепции и сейчас на стадии реализации. Межнодовое взаимодействие не будет совместимым с Erlang/OTP. Каждый инстанс будет напрямую общаться с cloud-стеком (интерфейс EC2).
Давайте вместе попробуем как работает mnesia. Перед тестами лучше обновить версию в build service. По этому вопросу лучше продолжить в почте.
Большинство «файлов», которые раздаются по 9P, — синтетические. Например, каждый node экспортирует директорию /proc и запись в файл /proc/1 вызывает посылку сообщения процессу <0.1.0>. Для аутентификации мы используем MUNGE (монтирование из Linux) и MUMBLE (между нодами Erlang on Xen). Схема MUMBLE описана здесь.
Практически сборка образа так и происходит, только без использования компрессии. Есть и аналог манифеста приложения.
Уровень кластеризации прошел этап концепции и сейчас на стадии реализации. Межнодовое взаимодействие не будет совместимым с Erlang/OTP. Каждый инстанс будет напрямую общаться с cloud-стеком (интерфейс EC2).
Давайте вместе попробуем как работает mnesia. Перед тестами лучше обновить версию в build service. По этому вопросу лучше продолжить в почте.
А жаль конечно… т.к. иначе продажа приложение подобного типа будет ограничена…
А будет ли интерфейс по экспорту объектов через 9P из нодов? т.е. например /proc/1/service1 к примеру — через gen_server или get_otp? (хотя возможно и другое именование).
MUMBLE хорош — но увы не шифрует трафик и это нехорошо, у Erlang такой проблемы насколько Я знаю нету.
Тут речь шла о том чтобы сделать простую сборку — т.е. отдавать людям ISO (условно) — чтобы они сами могли подсоединить обычное Erlang приложение (без правок) и попробовать.
По поводу нодового взаимодействия — почему-же? Я вот например очень ждал этой функции чтобы можно было писать распределенный Erlang приложения без проблем инфраструктуры + удаленная консоль на любой ноде. Интерфейс EC2 конечно не радует — т.к. хотститься на Amazon не всегда хорошо.
Предлагаю продолжить по Skype — мой ник такой-же.
А будет ли интерфейс по экспорту объектов через 9P из нодов? т.е. например /proc/1/service1 к примеру — через gen_server или get_otp? (хотя возможно и другое именование).
MUMBLE хорош — но увы не шифрует трафик и это нехорошо, у Erlang такой проблемы насколько Я знаю нету.
Тут речь шла о том чтобы сделать простую сборку — т.е. отдавать людям ISO (условно) — чтобы они сами могли подсоединить обычное Erlang приложение (без правок) и попробовать.
По поводу нодового взаимодействия — почему-же? Я вот например очень ждал этой функции чтобы можно было писать распределенный Erlang приложения без проблем инфраструктуры + удаленная консоль на любой ноде. Интерфейс EC2 конечно не радует — т.к. хотститься на Amazon не всегда хорошо.
Предлагаю продолжить по Skype — мой ник такой-же.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Erlang on Xen — запуск приложений Erlang на голом виртуальном железе