Комментарии 44
Авторы обещают, что с ней «в доли секунды можно запускать легковесные микровиртуальные машины (microVMs) в невиртуализированной среде, получив преимущества и традиционных ВМ — в виде безопасности и изоляции рабочих нагрузок, и контейнеров — в виде эффективного использования ресурсов».
Я могу ошибаться, но мне это напомнило OpenVZ.
Это, скорее, [серверный|облачный] Qubes OS.
Ну и OpenVZ мертв уже, да.
Я не совсем понимаю как firecracker может быть гипервизором, что он работает поверх kvm. Гипервизор на гипервизоре можно запустить, но производительность будет ужасная. Здесь же речь идёт об "оркестраторе" по типу докера, но с другим типом полезной нагрузки (т.е. здесь схожесть с openvz).
Вопрос ещё и в том имеет ли эта технология смысл для end-user'а. Т.е. если это всего лишь прослойка, которая позволяет эффективно запускать lambda/serverless, то с большой степенью уверенности могу сказать, что мне пофигу, что у них под капотом: docker, rocket, kata или "тонкие" ВМ… Работает и нормально.
КМК пользователю это в первую очередь выгодно, выгоднее чем самим AWS — Ваше ПО наиболее изолированно, чем оно было бы изолированно, например, в Docker-контейнере, при этом Вы не платите за ВМ сполна, т.к. Вы кушаете меньше ресурсов хост-машины.
Если Вы не чувствуете разницу между виртуализацией и контейнеризацией и для вас это всё на уровне «работает и нормально» — печально.
с точки зрения Ops — несомненно чувствую. С точки зрения архитектора (и слабых мест того или иного решения) — тоже. С точки зрения Dev (побыстрее выкатить фичи и чтоб стабильно работало) — знаете, но внезапно (!) действительно разницы нет.
К тому же речь шла именно про отдельный, изолированный случай — lambda. В остальном я сам способен решить, что мне в текущий момент времени интереснее — полноценные ВМ или контейнеры.
Ваше ПО наиболее изолированно, чем оно было бы изолированно, например, в Docker-контейнере,
а технологически можете аргументировать? Уже были прецеденты, когда docker-изоляция «протекала». В первую очередь — по производительности. Например, habr.com/company/southbridge/blog/429788
В целом, ВМ тоже могут давать схожие эффекты в случае неравномерной нагрузки и тем более — оверселлинга по ресурсам (не знаю грешит ли этим AWS, но вот местечковые провайдеры таким страдают).
Ну если вы считаете, что после выливки кода ваш конвейер закончился — то да, вы правы. А так ваши ошибки в коде в случае KVM более изолированы от хостовой системы.
Насчёт конвейера — он закончится только в момент вывода программной компоненты из эксплуатации.
А так ваши ошибки в коде в случае KVM более изолированы от хостовой системы.
При условии выполнения каждой лямбды в отдельной "микроВМ" — скорее соглашусь. Но если там поверх ещё докер навернут (а почему нет?). Или если брать изоляцию между каждым инстансом firecracker
А что мне технологически аргументировать? На соседей разделяется nf_conntrack, разделяется энтропия, разделяется etc…
С точки зрения Dev (побыстрее выкатить фичи и чтоб стабильно работало) — знаете, но внезапно (!) действительно разницы нет.
На моей машине всё работает. (с) Но ладно, да, с точки зрения Dev разницы никакой. Если только не… команда состоит не из 1,5 землекопа, а там начинается игра в футбол, которая зря потратит время всем: «это виноват Dev!» — «не, это Ops'ы косячат!»
При решении каждой конкретной задачи можно решить какой уровень изоляции нужен. Главное понимать trade-off и в какой момент абстракция «потечёт».
Касательно dev/prod-контуров — их полностью идентичными не сделать по разным причинам (экономические, технологические и пр.). Да и не всегда нужно, чтобы dev был точной копией.
Касательно firecracker — это очень интересный вопрос как его предлагает использовать Амазон. Условно, если они представляют его как легковесную замену ВМ, чтобы запускать лямбды (т.е. все инкапсулировано и скрыто от пользователя платформы), то это очень интересное решение. Но ещё и интересно технологически — будет ли firecracker хостинг только лишь одну лямбду, например, или их коллекцию? Или может даже лямбды разных пользователей. Короче — посмотрим.
Здесь же речь идёт об «оркестраторе» по типу докера, но с другим типом полезной нагрузки (т.е. здесь схожесть с openvz).
Нет тут никакого оркестратора. Тут один процесс Firecracker — одна ВМ. Плюс API. Оркестратор нужно сверху прикручивать через API. Причем тут OpenVZ вообще не понятно.
Изолирование процесса Firecracker с помощью cgroups и seccomp BPF
ОК. Т.е. ничего нового на самом деле не сказано ) те же qemu/kvm можно было засунуть в cgroups.
Всё что ему нужно от KVM — это изоляция процесса + прямое выполнение инструкций на хостовом железе (в изоляции от других процессов, разумеется), т.е. с точки зрения гостя у него процессор хоста, но это всё что гостю может быть видно из железа.
cgroups/seccomp нужны исключительно для того чтобы никто не выбрался дальше, ведь фактически Firecracker нужно только read/write и ещё несколько простых и сравнительно безопасных системных вызовов, в то время как QEMU нужно гораздо больше для нормальной работы, и его гораздо сложнее изолировать.
Таким образом, роль самого Firecracker заключается только в инициализации и реализации обмена данными с хостом (на уровне файлов/сокетов для virtio устройств), больше ни к чему гость не имеет доступа и соответственно навредить вряд ли сможет (разве что поедая ресурсы — но от этого как раз спасут cgroups).
В общем, я бы назвал это UML на стероидах.
Но смысла в этом оверхеде всё равно нет (он не такой уж и незначительный), если можно отдать block device.
В то же время «прямой» доступ через virtblk — это просто проброс на уровне read()/write(), вероятно даже с прямым доступом к памяти гостя со стороны хоста. Оверхед конечно останется, но ощутимо меньший.
Теперь умножим это на много VM на одном физическом хосте — и получим ужасную картину с оверхедом в случае NBD + гость может воспользоваться уязвимостью со стороны NBD сервера на хосте (если таковая обнаружится).
Разработчики стремятся к минимализму, включая в продукт только самое необходимое и обеспечивая тем самым минимальные расходы на память, а заодно и уменьшая возможности для потенциальных уязвимостей.
Итог всего этого простой — дико переусложненная экосистема и оверинжиниринг всего и вся.
Ох, сколько уже их было, этих супер-быстрых, в следствии своей супер-минималистичности же, гипервизоров, которые в бенчмарках, то есть в тестах, писанных самими же разработчиками, в надцать раз быстрее qemu-kvm и в эти же надцать раз безопаснее и проще.
К примеру тот же freeBSD-шный bhyve…
Хотя это совсем другая песня, тем более что не на растения писанная.
Так вот: сколько уже их было видимо-невидимо (на опеннете что не месяц — новость о новом гипервизоров), да только ни один не выстрелил, потому что всем, по какой-то невиданной причине, почему-то оказывается очень нужна эмуляция всевозможного оборудования, всякие миграции и т.д. и т.п., а тут нам что же предлагают..? — аппаратную клавиатуру с одной кнопкой!
Зачем вообще нужна эта кнопка в таком кейсе? Уже бы тушили питание посредством bios-uefi, если они там, конечно, есть.
PS: простите мне мой сарказм, просто я больше 10 лет наблюдаю как qemu все закапывают...
потому что всем, по какой-то невиданной причине, почему-то оказывается очень нужна эмуляция всевозможного оборудования
Основная причина по которой используют qemu/kvm для хостинга (VPS & co) — это изоляция, а не эмуляция. В случае с qemu это большой оверхед (там много лишнего), поэтому минималистический гипервизор который дает только изоляцию, сеть и block-device, при этом способный выполнять любое ядро — это реальная тема, потому что это всё что нужно большинству контейнеров.
Уже бы тушили питание посредством bios-uefi
Тушить питание не проблема, проблема надёжно и безопасно дать OS знать что пора делать graceful shutdown, ACPI/UEFI etc тут явно будет перебором — клавиатуру эмулировать проще на порядок.
Основная причина по которой используют qemu/kvm для хостинга (VPS & co) — это изоляция, а не эмуляция.
Соглашусь.
Требования для хостинга простые:
— поддержка популярных операционных систем (linux, windows, freebsd различных дистрибутивов и версий)
— поддержка блочных устройств, сети, GPU акселлерации (опционально).
И по идее все… Получатеся, что действительно конфигурация ВМ на хостинга она, в целом, стандартизирована. Плюс еще на хостингах обычно используется закрытый перечень типов железа.
В отличии от запуска гипервизора с ПОЛНЫМ пробросом аппаратного обеспечения на рабочей машине разработчика или пользователя, где действительно нужно тянуть возможность поддержки всех фич и разного типа железа (те же USB пробросы )))
к тому же полноценная изоляция сейчас возможна только как часть виртуализации. и там qemu. или vmware. или даже hyper-v. но никак не гипервизор с поддержкой одной кнопки…
это я перефразировал себя же.
HRы и recruiters, теперь ваш ход…
С 1 декабря Firecracker во всех DevOps вакансиях, опыт от 5 лет.
Всё почти как обещано — CPU на уровне 95% от хоста (прикидывается ксеоном), а вот с сетью и диском — на полной загрузке жрёт CPU хоста просто безбожно. Сеткой даёт около 30 Gbits/s с хостом (на i7-6700). Впрочем, с qemu ситуация несколько хуже, оверхед там поболе будет, но это зависит.
В остальном — гипервизор как гипервизор, нужно просто юзать. Привлекает то что это один статический экзешник, никакого инсталла, простой API. Расстраивает что нет годного UI (пока), хотя они вроде уже запилили поддержку в containerd.
Если Proxmox это подхватит (рядом с QEMU) — может неплохая альтернатива lxc получится (в плане изоляции как минимум).
Сильно I/O loaded штуки в нём гонять будет накладно (как, впрочем, и в qemu/docker), но «стандартный пакет» для в основном ожидающих задач (веб-сервера & co) вполне сойдёт.
В AWS представили Firecracker — «микровиртуализацию» для Linux