разработчик
0,0
рейтинг
24 декабря 2012 в 18:06

Разработка → Erlang on Xen — запуск приложений Erlang на голом виртуальном железе

Erlang on Xen позволяет запускать приложения Erlang без операционной системы, на голом гипервизоре Xen. От момента запуска VM до начала работы приложения проходит всего 50 миллисекунд — в 100-1000 раз меньше, чем нужно для запуска привычного сочетания Linux+Erlang, а размер образа машины составляет лишь около 1 Мб. Это позволяет добиться практически мгновенного масштабирования, вплоть до запуска экземпляра VM после того, как пришёл запрос от клиента.

Отказ от прослойки в виде ОС общего назначения даёт возможность упростить администрирование и обеспечить лучшую безопасность и масштабирование, благодаря значительно меньшему времени жизни виртуальной машины и отсутствию лишней универсальной функциональности ОС.

Лежащая в основе Erlang on Xen виртуальная машина Ling показывает производительность, сравнимую со стандартной для Erlang VM BEAM (Bogdan/Björn’s Erlang Abstract Machine).

Исходники Erlang on Xen пока не доступны, хотя авторы не исключают возможности их публикации в будущем. Монетизацией и лицензированием будет заниматься специально созданная для этого компания Cloudozer, на сайте которой можно ознакомиться с планами по развитию технологии на ближайшие несколько лет. Попробовать Erlang on Xen в действии можно уже сейчас на Amazon EC2, запустив готовый образ, который включает в себя VM Ling 0.2.0, некоторые базовые библиотеки, веб-сервер cowboy и тестовое приложение «tryling». Кроме того, на сайте можно построить кастомизированный образ для Xen под конкретное приложение.

Erlang on Xen — не единственный, но, пожалуй, самый активный проект подобного рода, хотя его пока пишет единственный разработчик — Максим Харченко (я пригласил его на Хабр, чтобы он смог поучаствовать в обсуждении — mkharch). У Oracle есть полузаброшенный аналогичный проект Maxine для Java Virtual Machine (бывший Guest VM), были попытки реализовать отдельно стоящую VM для Haskell, были многочисленные Лисп-машины (а так же более поздние попытки совместить ядро ОС и интерпретаторы диалектов лиспа), экзоядро для работы поверх Xen Mirage. Можно вспомнить и первые потребительские микрокомпьютеры, на которых в качестве ОС использовался интерпретатор языка Basic.

Ссылки и видео




Доклад Максима Харченко на конференции Erlang Factory в Сан-Франциско в марте 2012 года



Краткий обзор и ответы на вопросы Виктора Советова (@vsovetov), ментора проекта Erlang on Xen:



Илья Сименко @ilya42
карма
526,7
рейтинг 0,0
разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (64)

  • +16
    Это невероятно круто, пора учить эрланг.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Они даже в статье упомянуты :) Есть еще много сходных проектов, и будет все больше и больше, я надеюсь.
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            Для других языков, очевидно. Не всем интересно учить новый язык ради такой штуки, еще меньшему числу людей интересно набирать новый персонал и переписывать существующий код

            А вот реализация для ЯП на котором ведется разработка может здорово подтолкнуть к переходу на подобную технологию. Особенно, если какой нибудь Амазон подхватит.
          • +12
            Убрать OS из виртуалок — это закономерный эволюционный шаг для облаков. OS — это, в основном, менеджер ресурсов, облака добавляют свою специфику, для которой серверные OS не очень-то и подходят. Логичнее «размазать» функционал операционки по облаку, убрав таким образом ограничения по масштабированию и добавив функционала и управляемости. Как говорил Sun, царствие ему небесное: «наш компьютер — это сеть».
    • 0
      А раз уж Вам интересно веб-программирование, могу похвалить фреймворк Chicago Boss: github.com/evanmiller/ChicagoBoss
      • 0
        Спасибо, обязательно посмотрю. Но мое знание эрланга на данный момент ограничивается «слышал, что круто». Мне бы чего-нибудь совсем для новичков. Ну, учитывая, что опыт самого по себе программирования у меня есть (perl, ruby, javascript, php).
        • 0
        • 0
          Erlang — язык без эзотерики, учится легко. Опыт многочисленных коллег говорит о том, что от полной несознанки до написания кода в проект у не боящегося клавиатуры разработчика проходит максимум недель шесть.
          • 0
            Шесть недель полного времени, или с учетом того, что у человека еще есть обычная работа?
            • +1
              С учетом неавральной текучки. Лев Валкин в своем незабываемом докладе упоминал даже меньшие сроки — lionet.info/pdf/2010-lev-walkin-erlang-experience.pdf
              В общем, бывает по разному, но больше 6ти недель никогда не было…
              • +1
                Спасибо. Как тут уже писали, будет что поизучать на праздниках.
                • +1
                  Ага, welcome to the club
          • 0
            Erlang, несмотря на свою некоторую необычность синтаксиса, на удивление легок в усвоении. Для меня прогать на Erl — просто удовольствие, а самое главное практически любой код (особенно если он OTPшный) можно с ходу разобрать и понять как он работает. Такого нет ни в одном ЯП.
            • 0
              Да, весьма читабельный язык.
            • 0
              Если до этого вообще функциональные языки не щупал, то сначала башню сносит капитально. После С++ месяц меня накрывало. Потом втянулся. И даже радуешься потом таким конструкциям а ля qsort в 2 строчки.
  • +5
    Наконец-то нашлось что изучить на праздниках!
  • +1
    А можно уточнить, idle приложение на таком эрланге так же как и linux-версия в пустом цикле занимается непонятно чем?

    Я как-то на простаивающее приложение на erlang strace запустил — и был крайне удивлён тому срачу, который творится.
    • +3
      В Ling всякой этой суеты значительно поменьше — все-таки характер взаимодействия с окружением совершенно иной, да и сам по себе Ling — штука однопоточная, избавленная от необходимости жонглирования тредами.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +4
        Я как раз смотрел, чем обычно занимается ядро, когда простаивает в зене. Ответ: только таймеры обновляет, да на события реагирует. А вот strace на первый попавшийся эрланговый простаивающий сервер показывает срач, какого ядро не видело — каждый тред имеет своим желанием проснуться и заснуть, причём несколько раз в секунду.

        Если он с такой же скоростью насилует гипервизор гиперколлами, то ничего хорошего в этом нет.
        • 0
          А зачем бы ему так так нехорошо поступать с гипервизором? Тем более, что тред там один, он же единственный.
          • 0
            Ну, видимо, по той же причине, почему он «так нехорошо» поступает в линуксе. А вот зачем он так поступает в линуксе (по сравнению с обычными приложениями, которые в серверном режиме epoll'ятся и молчат, пока что-нибудь не случится) — я не знаю.
            • +2
              В линуксе — это не «он», там Эриксоновский BEAM. Тут свой Erlang VM (aka Ling, что по-китайски значит «ноль»), от BEAM'а совершенно отдельный, ничего общего (помимо формата .beam файлов) с ним не имеющий.
              • +1
                Ну, надеюсь.

                Кстати, а как у этой виртуалки с всем тем, что приличная виртуалка должна уметь делать? Балунинг, саспенд при миграции, поддержка memory hotplug, cpu hotplug и т.д…
                • +2
                  Мне еще интересно, как у нее дела с более банальными вещами — filesystem, tcp/ip… но судя по ссылкам, она все пробрасывает в хост.
                  • 0
                    TCP/IP внутри свой (сейчас — на базе LwIP), файловые системы импортируются по 9p, и по 9p же и экспортируются, для того чтобы наладить связь с внешней ФС гиперусилий прилагать не приходится — поднял инстанс (или несколько) diod'a (http://code.google.com/p/diod/) — и поехали.
                    • 0
                      чтобы все работало из коробки нужно тогда соответственно чтобы при установки EonX ставились и дополнения под 9P — поскольку сейчас это только как внешние модули возможно
                    • 0
                      Имел опыт с LwIP на микроконтроллере. Это редкостный шлак.
                      • +1
                        Новая версия lwIP (1.4.0), использованная в LING, значительно лучше предыдущих. lwIP — это хорошый баланс между сложностью и фунциональностью (но не идеальный). Мы также планируем написать TCP/IP на чистом Эрланге и сравнить.
                • 0
                  Кое-что по списку не нужно — cpu hotplug, например, часть допиливается (memory hotplug), хотя ценность такого шага сомнительна. С малой стартовой латентностью бывает проще прибить ноду и запустить другую (или даже несколько), как это не непривычно звучит. С саспендом, по ходу, проблем не было — ВМ, в принципе, в курсе, что она работает не на реально железе, от этого отсутствует потребность в камланиях по обрботке аппаратных прерываний и тп. Без всех этих нюансов миграция становится значительно проще.
                  • 0
                    Мне кажется, что область применения приложения, которое надо убивать для изменения настроек, несколько ограничена. Например, у нас в продакте in-memory-database на эрланге, и если её «просто прибить», то она «просто не сохранит данные» на диск. Со всеми вытекающими.
                    • 0
                      Там же концепция «let it crash»
                    • 0
                      Это смотря как сделано. Вряд ли разумно делать базу без реплицирования, а с нормальным реплицированием прибивание/умирание — вполне себе штатаная ситуация.
                      • 0
                        Речь не про аварийные ситуации, а про изменение настроек. Надо добавить памяти — завершились, скачали заново 20-30Гб данных? Выглядит странно.

                        Особенно с учётом того, что нет никакой причины не поддерживать hotplug. Тем паче, что это даже не «hotplug», а просто трансфер дополнительных страниц памяти в домен.

                        Линукс из этого устраивает потанцульки с «memory hotplug» только из-за того, что есть готовая инфраструктура (железных серверов). В контексте «pure PV» это мало отличается от sbrk() для приложения.
                        • 0
                          Memory hotplug будет, просто он не самый приоритетный.
    • 0
      вот специально проверил: ничего не творится на простаивающем приложении, так что ваше приложение походу не простаивало.
      • +1
        Просто для проверки, strace с ключом -f запускался? strace -f -p <beam.smp-pid>, так?
        • 0
          нет, я запускал просто с -xp (-smp disabled не порождает дочерних процессов)
          но и с -fxp разницы не вижу — idle процесс не делает никаких сисколов, с smp или без него
          • 0
            А вот это уже интересно. В каком приложении?

            Я думал это наши криворукие товарищи сделали так, поставил первое попавшееся приложение (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 раз)
            • 0
              ну сейчас мы говорим о несколько разных вещах. idle приложение это то, которое ничего не делает (ну типа просто erl запустили, или timer:sleep(100000), или пустой цикл гоняем)

              судя по strace в данном случае — это асинхронная работа с сокетами, делается именно так, как видно в логах (там в любом случае присутствует внешний луп, что бы генерировать события), если взять любое приложение с асинхронными сокетами, на любом языке — будет точно такая же картина (возьмите приложение с boost.asio или twisted, и там будет картинка 1 в 1), с poll будет еще красивее и чаще
              • 0
                Я не понимаю, почему для использования epoll нужно всё время просыпаться. Тот же nginx, например, прекрасно спит пока что-нибудь в сокет не прилетит.

                Более того, epoll для того и делался, чтобы не надо было всё время просыпаться и проверять «нет ли там чего нового».

                ЗЫ Можно примеры приложений (кроме erlang) в которых подобная порнография наблюдается? А то я пока такое только у beam.smp видел.
                • +1
                  ну, из самого простого — 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

                  тут конечно почище, но в целом тоже не фонтан (его то оптимизировали по сисколам), в эрланге еще таймер дергают.
                  • 0
                    О, кстати, я только один воркер смотрел у nginx (master и первый, запущенный от пользователя www-data). У тех вообще тишь да гладь. У последующих воркеров — да, есть что-то подобное.

                    Спасибо за информацию, я буду меньше на эрланг хмуриться.
                    • 0
                      я так понимаю, у вас там довольно активно используют эрланг. собственно в рассылке есть попытки оптимизаций epoll_wait, типа erlang.org/pipermail/erlang-questions/2012-July/067871.html

                      но тут надо ясно себе представлять почему писалось именно так, как есть сейчас, и потом не
                    • +1
                      Если accept_mutex отключить, то с любым количеством воркеров будет тишина. В случае одного воркера accept_mutex отключается автоматически.

                      accept_mutex_delay — и задает эти самые 500мс.
                      • 0
                        однако есть еще:
                        en.wikipedia.org/wiki/Thundering_herd_problem
                        • +1
                          Разумеется. Но вы выше написали "тут конечно почище, но в целом тоже не фонтан", а я объяснил от чего так, и что отключить, если хочется совсем чисто.

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

                          Вопрос компромиссов. От nginx-а можно получить то поведение, которое хочется. Да и его рабочих процессов обычно запускают не более, чем ядер в системе.
                • 0
                  собственно если почитать man epoll_wait то можно увидеть, что четвертым параметром идет таймаут, в эрланге = 0, в nginx'e = 500 (в моей установке).

                  разница тут только в том, что в эрланге надо делать еще кучу работы, помимо того, что бы слушать сокеты, а в nginx — больше ничего делать не надо, и даже возможно можно и этот таймаут увеличить до несколько больших чисел (потеряв при этом скорость ответа, хотя на нагруженном сервере, это не важно — быстрее наберется количество эвентов, чем истечет таймаут, в общем не суть).
                  • 0
                    Вот меня это и смущает — почему приложение, которое работает веб-сервером должно делать «кучу работы, помимо того, чтобы слушать сокеты»? Я специально сравнивал yaws и nginx, которые оба веб-серверы.
                    • 0
                      в двух словах, дело получается в том, что приложение на эрланге, это не просто такая же штука, как и написанное приложение на C/CPP/python/etc, но и еще довольно навороченная виртуальная машина, которая делает много работы под капотом (в С приложение делает в принципе только то, что ты ему скажешь делать)

                      у Льва Валкина есть хорошие статьи на тему эрланга и специализированных задач lionet.livejournal.com/84884.html и lionet.livejournal.com/88113.html
  • +3
    Ну вот… теперь придется снова его покрутить… два раза у меня с Эрлангом не срослось, хотя ко мне прилетели из-за рубежа несколько ортодоксальных книг по языку. Но уж больно моя подкорка сопротивляется… даже не синтаксису, скорее — положениям. Но я все-равно уважаю язык.
    • 0
      Я пробовал Erlang on Xen — но пока к сожалению проект крайне сырой что выражается в:
      — нету возможности установить бинарные дополнения
      — файловая система только build-in что не совсем хорошо, ведь для облака нужно монтирование удаленной ФС как локальной
      — нету API для получение внутренних системных структур — т.е. произвести интроспекцию
      — (раньше) была проблема с 64-битным режимом — т.е. аллоцировании более 4GB RAM
      P.S. жалко что автор проекта молчит на хабре, чата на сайте нету, и форума тоже
      • +1
        Проект в активной разработке, естественно, многие фичи еще сыроваты, кое-что критичное вообще еще в паблик версии не выкатывалось — например межнодовое взаимодействие.
        Форумы-чаты со временем будут, конечно же.
      • 0
        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 — ключевой человек в проекте.
        • +1
          1) по поводу POSIX не думаете сделать псевдоэмуляцию? NIF думаю не очень нужен — в этом полностью согласен
          2) где можно почитать про встроенную ФС? Также используется 9P
          3) планируется ли поддержка кого-либо кроме Amazon — ведь не все же используют Public Cloud — и много у кого есть Private Cloud
          4) по поводу интроспеции видно Я что-то упустил — посмотрю в будущем
          5) какой уровень поддержки mnesia — можно ли там хранить более 4GB? Как с масштабируемостью на лету (on-the-fly) — например ресайз с 128MB до 4GB блоками по 128MB? (больше интересует рост вверх без остановки — благо Erlang это может)

          Спасибо за пояснение :)
          • +1
            Про псевдоэмуляцию не очень понятно. Поясните.

            По ФС в Erlang on Xen должна появится публичная презентация. В Plan 9 карта монтирования разная для каждого процесса, также разрешены union mounts, в Linux — она глобальная и union mounts не поддерживаются. Erlang on Xen ближе к Plan 9.

            Мы поддерживаем Xen. Поэтому для запуска инстансов можно использовать Amazon или любого другого провайдера, который использует Xen.

            По mnesia данных нет. В данный момент несколько человек пытаются запускать разные известные приложения на Erlang on Xen, но Мнезии пока среди них нет.
            • +1
              Псевдоэмуляция 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 могу предоставить примеры на тесты — т.к. мне проект интересен.
              • +1
                Такую эмуляцию мы не планируем. Мы предполагаем, что типичное приложение будет использовать сотни относительно короткоживущих инстансов. Некоторые из них могут выполнять код, который требует POSIX, используя Linux.

                Большинство «файлов», которые раздаются по 9P, — синтетические. Например, каждый node экспортирует директорию /proc и запись в файл /proc/1 вызывает посылку сообщения процессу <0.1.0>. Для аутентификации мы используем MUNGE (монтирование из Linux) и MUMBLE (между нодами Erlang on Xen). Схема MUMBLE описана здесь.

                Практически сборка образа так и происходит, только без использования компрессии. Есть и аналог манифеста приложения.

                Уровень кластеризации прошел этап концепции и сейчас на стадии реализации. Межнодовое взаимодействие не будет совместимым с Erlang/OTP. Каждый инстанс будет напрямую общаться с cloud-стеком (интерфейс EC2).

                Давайте вместе попробуем как работает mnesia. Перед тестами лучше обновить версию в build service. По этому вопросу лучше продолжить в почте.
                • 0
                  А жаль конечно… т.к. иначе продажа приложение подобного типа будет ограничена…

                  А будет ли интерфейс по экспорту объектов через 9P из нодов? т.е. например /proc/1/service1 к примеру — через gen_server или get_otp? (хотя возможно и другое именование).
                  MUMBLE хорош — но увы не шифрует трафик и это нехорошо, у Erlang такой проблемы насколько Я знаю нету.

                  Тут речь шла о том чтобы сделать простую сборку — т.е. отдавать людям ISO (условно) — чтобы они сами могли подсоединить обычное Erlang приложение (без правок) и попробовать.

                  По поводу нодового взаимодействия — почему-же? Я вот например очень ждал этой функции чтобы можно было писать распределенный Erlang приложения без проблем инфраструктуры + удаленная консоль на любой ноде. Интерфейс EC2 конечно не радует — т.к. хотститься на Amazon не всегда хорошо.

                  Предлагаю продолжить по Skype — мой ник такой-же.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      В смысле в тэги к статье? Добавил.
      • НЛО прилетело и опубликовало эту надпись здесь

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