Ling: Erlang over Xen, no OS required
Viktor Sovietov
под Erlang VM немного лишняя и хорошо было бы пускать его на голом
железе, пусть даже и виртуальном, то вам будет интересен такой вот
проект:
Существуют похожие начинания для OCaml http://www.openmirage.org/
и Haskell http://halvm.org/
Dmitry Groshev
задать следующие вопросы, как мне кажется:
-когда/как можно пощупать?
-будете ли опенсорсить?
-сколько собираетесь брать денег?
2012/7/13 Viktor Sovietov <victor....@gmail.com>:
> --
> Страница рассылки: http://groups.google.com/group/erlang-russian
> Новости: http://erlanger.ru
> Написать письмо: erlang-...@googlegroups.com
> Отписаться: erlang-russia...@googlegroups.com
Max Lapshin
Что значит «No complex SMP - multi-core scheduling is done by the
hypervisor»? Куда пропала многоядерность?
Насколько отличается старт самих приложений? Ведь запустить сам erl —
плевое дело, а вот старт SASL-евых приложений занимает немало времени?
Я правильно понимаю, что nif-ов наверное уже не видать?
Viktor Sovietov
On 13 Лип, 00:06, Dmitry Groshev <lambdadmi...@gmail.com> wrote:
> Как я понимаю, вы -- разработчик. Соответственно, уместно было бы
На самом деле я дровишки подношу. Максим Харченко пишет весь код.
> задать следующие вопросы, как мне кажется:
> -когда/как можно пощупать?
можно черкнуть пару строк на in...@erlangonxen.org и договориться
> -будете ли опенсорсить?
> -сколько собираетесь брать денег?
Сие пока неведомо, поскольку как это будет монетизироваться - еще не
решено.
Sincerely,
--Victor
>
> 2012/7/13 Viktor Sovietov <victor.sove...@gmail.com>:
>
>
>
>
>
>
>
> > Если у вас хоть раз проскакивала мысль о том, что вся эта операционка
> > под Erlang VM немного лишняя и хорошо было бы пускать его на голом
> > железе, пусть даже и виртуальном, то вам будет интересен такой вот
> > проект:
>
> >http://erlangonxen.org/
>
> > Существуют похожие начинания для OCamlhttp://www.openmirage.org/
> > и Haskellhttp://halvm.org/
Dmitry Groshev
2012/7/13 Viktor Sovietov <victor....@gmail.com>:
Viktor Sovietov
On 13 Лип, 00:24, Max Lapshin <max.laps...@gmail.com> wrote:
> Как у вас получается, что <<No 'out of memory crashes' anymore>>?
Потому что VM другая :), эту ситуацию можно обработать до того, как
памяти совсем не станет.
> Что значит <<No complex SMP - multi-core scheduling is done by the
> hypervisor>>? Куда пропала многоядерность?
Ее в данной VM просто никто не делал. Поддержка SMP на виртуальном
железе - сомнительно полезная вещь. Схема "VM на ядро, zero-copy
передача сообщений между VMами" работает как минимум, не хуже.
> Насколько отличается старт самих приложений? Ведь запустить сам erl --
> плевое дело, а вот старт SASL-евых приложений занимает немало времени?
Приложения стартуют быстрее - это все-таки другой VM, там отсутствуют
некоторые legacy Ericsson-specific фокусы с трансляцией, которые
сильно замедляют загрузку модулей и запуск приложений, кроме того,
остается возможность сделать имидж уже с предкомпилированым и
предзагруженым приложением и стартовать совсем быстро.
> Я правильно понимаю, что nif-ов наверное уже не видать?
Пока нет, но впоследствии - пуркуа бы и не па? Да, HiPE тоже
отсутствует, конечно.
Sincerely,
--Victor
Max Lapshin
1) как осуществляется zero copy между VM? Как это выглядит
синтаксически из эрланга?
2) правильно ли я понял, что эта штука -- вместо ядра линукса и вы
вместо системных вызовов вставили API, предоставляемое некой libxen (я
не в курсе как запускается ядро в виртуалке, поэтому могу какую-то
глупость сказать)
3) если это как-то связано с Clustrx, то зачем нужна такая
конструкция, если не для запуска портов?
4) можно ли запустить ещё одну виртуалку из соседней? Или это вопрос
API супервизора?
Ну и наверное было бы неплохо как-то погонять это даже в виде бинарной
сборки с какими-то вкомпиленными ограничениями типа <<через 5 минут
сдохнуть>> или что-то ещё подобное.
Или в виде какого-то SaaS.
Viktor Sovietov
On 16 Лип, 17:48, Max Lapshin <max.laps...@gmail.com> wrote:
> Виктор, можете, пожалуйста, ещё пояснить:
>
> 1) как осуществляется zero copy между VM? Как это выглядит
> синтаксически из эрланга?
Изнутри все прозрачно, как и должно быть. В принципе, это стандартная
фишка Xen'a - передавать данные переназначением страниц физической
памяти между виртуалками, на том его ввод-вывод, в частности,
зиждется. Нынче так виртуалки общаются с dom0, а в перспективе так
будут пересылаться сообщения между нодами в рамках физического узла -
именно так можно избавиться от сложных SMP шедулеров.
> 2) правильно ли я понял, что эта штука -- вместо ядра линукса и вы
> вместо системных вызовов вставили API, предоставляемое некой libxen (я
> не в курсе как запускается ядро в виртуалке, поэтому могу какую-то
> глупость сказать)
На самом деле даже еще меньше. Эрлангу нужно совсем немного -
управление памятью у него свое, доступ к файловой системе сделан через
9P, и этого вполне достаточно, TCP/IP сейчас тоже через 9Р (через
Xen'овский виртуальный эзернет), но это временно, поскольку нужно по-
максимуму избавляться от требований к dom0, если хочется пускать
имиджи на том же Амазоне. В общем, от самого Xen`а совсем немного
нужно, в будущем достаточно просто будет тот же код прикрутить и на
другие супервизоры, поверх физического железа пускаться несколько
стремно, потому что всякие порты, прерывания, и прочая.
> 3) если это как-то связано с Clustrx, то зачем нужна такая
> конструкция, если не для запуска портов?
С Clustrx вообще не связано, во всяком случае, пока. Конструкция
изначально задумывалась для совсем эластичных приложений, вплоть до
старта VM в то время, когда запрос, который в этой VM должен
обслужиться уже принят фронтендом. Поскольку теория сера, а древо
жизни зеленеет вечно, нашлась еще пачка применений, и схема чем дальше
тем больше мне нравится. Для менеджмент стеков типа Clustrx, в
принципе, такая платформа тоже подходит, просто сейчас используется
другой подход для обеспечения эластичности, несколько более избыточный
- Clustrx пускает ноды с сервисами внутри lxc контейнеров.
> 4) можно ли запустить ещё одну виртуалку из соседней? Или это вопрос
> API супервизора?
Да. В идеале это должно быть полностью прозрачно для приложения и
управляться из супервизора (в рамках полномочий выданных приложению
клауд менеджментом). Такой подход откроет бы довольно интересные
перспективы для PaaS/SaaS провайдеров.
>
> Ну и наверное было бы неплохо как-то погонять это даже в виде бинарной
> сборки с какими-то вкомпиленными ограничениями типа <<через 5 минут
> сдохнуть>> или что-то ещё подобное.
Нынче готовится билдилка имиджей с пользовательским кодом внутре для
погоняния, по готовности будем бить в рельсу на твиттере.
> Или в виде какого-то SaaS.
Вот билдилка в таком виде и будет завернута. Наверное, на Амазоне.
Sincerely,
--Victor
Viktor Sovietov
Sincerely,
--Victor