Компания Intel опубликовала (https://clearlinux.org/blogs/announcing-intel%C2%A...) значительный выпуск инструментария Clear Containers 3.0 (https://clearlinux.org/features/intel%C2%AE-clear-...), предоставляющего средства для управления контейнерами, для изоляции которых используется гипервизор KVM и встроенные в процессоры Intel механизмы виртуализации Intel VT и SR-IOV (https://www.intel.com/content/dam/doc/application-note/pci-s...). Код поставляется (https://github.com/clearcontainers) под лицензией Apache 2.0.
Новый выпуск примечателен кардинальной переработкой кодовой базы и рефакторингом архитектуры проекта (https://github.com/clearcontainers/runtime/blob/7fc11d5fa157...).
Инструментарий и компоненты runtime переписаны на языке Go (ранее использовался язык Си). Проведена большая работа по улучшению интеграции Clear Containers в сформировавшуюся экосистему контейнерной изоляции, в том числе расширены средства для задействования в проекте кода, используемого в контейнерах на базе namespaces и cgroups.
Функции для обеспечения работы аппаратно виртуализированных контейнеров вынесены в модульную и независящую от типа гипервизора библиотеку virtcontainers. Новая реализация runtime (cc-runtime (https://github.com/clearcontainers/runtime)) построена поверх библиотеки virtcontainers и приведена к полной совместимости со спецификацией OCI (https://www.opennet.me/opennews/art.shtml?num=46889), определяющей унифицированный формат образов контейнеров и runtime-компонентов, что позволяет использовать cc-runtime совместно с Docker в качестве прозрачной замены runc. Кроме того обеспечена поддержка прослойки CRI-O (https://github.com/kubernetes-incubator/cri-o) для использования cc-runtime в кластере на базе Kubernetes.
В состав добавлен выполняемый внутри контейнера агент cc-agent на базе libcontainer, который заменил собой hyperstart и позволяет применять политики ограничения доступа SELinux и фильтры seccomp в гостевых окружениях на базе Clear Containers. Для повышения производительности ввода/вывода и достижения полного соответствия спецификациям POSIX в контейнерах Clear Containers также предоставлена возможность использования бэкенда virtio-blk. Расширены возможности вложенной виртуализации, которые позволяют выполнять немодифициованные контейнеры Clear в окружениях HyperV и VMware. Для взаимодействия между компонентами cc-shim, cc-proxy и cc-runtime реализован новый упрощённый протокол.
По сравнению с традиционными контейнерами на базе пространств имён применение гипервизора позволяет добиться более высокого уровня безопасности, защищающего от совершения атак через эксплуатацию уязвимостей в ядре Linux. По сравнению с системами полноценной виртуализации в Clear Containers удалось минимизировать время запуска изолированного окружения и снизить потребление памяти, приблизив эти показатели к характеристикам обычных контейнеров. К окружениям Clear применимы традиционные для контейнеров методы управления и развёртывания, в том числе можно на лету запускать упакованные в виртуальные окружения приложения, в моменты, когда в них возникает необходимость.
Внутри виртуального окружений Clear, которое запускается гипервизором, используется специально оптимизированное ядро Linux, содержащее только минимальный набор необходимых возможностей. Системное окружение включает в себя только демон инициализации на базе systemd и агент cc-agent. Агент обеспечивает выполнение определённых пользователем образов контейнера в формате OCI. В одном виртуальном окружении Clear может запускаться один или несколько пользовательских контейнеров (для контейнеров Docker для каждого контейнера создаётся отдельная виртуальная машина). Для каждого контейнера внутри виртуального окружения создаются отдельные пространства имён (NS, UTS, IPC и PID), т.е. запускаемое поверх гипервизора окружение Clear служит плацдармом для вложенного запуска контейнеров. Работа пользовательских контейнеров обеспечивается при помощи cc-runtime.
В условиях выполнения большого числа типовых окружений, накладные расходы на каждое последующее окружение составляет 18-20 Мб, что даёт возможность уместить 3500 виртуальных машин на сервере с 128 Гб ОЗУ. Для уменьшения потребления памяти применяется механизм DAX (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) (прямой доступ к ФС в обход страничного кэша без применения уровня блочных устройств), а для дедупликации одинаковых областей памяти применяется технология KSM (https://github.com/clearcontainers/proxy/blob/master/docs/ks...) (Kernel Shared Memory), что позволяет организовать совместное использование ресурсов хост-системы и подключить к разным гостевым системам общий шаблон системного окружения. Начиная с выпуска 3.0 в Clear Containers также предоставляются средства регулирования активации процесса выявления дубликатов (KSM throttling (https://github.com/clearcontainers/proxy/blob/master/docs/ks...)).URL: https://01.org/blogs/alleelan/2017/announcing-intel%C2&...
Новость: http://www.opennet.me/opennews/art.shtml?num=47252
чому не православный Rust?
Потому что он недостаточно правослаен и чуть более чем правоверен.
Потому что пишет прагматичные кодеры из intelа, а не неосиляторы плюсов из тоpмозиллы.
Прагматичные пишут на С, очень прагматичные пишут на Ассемблере.
перфокарты же!
Ты знаешь разницу между языком программирования и носителем данных?
машинные коды. писать в машинных кодах, то еще удовольствие
Ну это мы еще на калькуляторе Электроника Б3-34 делали.
> Ну это мы еще на калькуляторе Электроника Б3-34 делали.Контейнерную изоляцию на калькуляторах?
Да вы монстры!
Насколько я помню, в Rust как выпилили простые легковесные потоки, так и не впилили обратно. А без оных, оно и не очень нужно.
Лол кек чебурек. И зачем нужны легковесные потоки в управлялке контейнерами?
Ты ещё спроси: "а зачем они вообще нужны?!?!?!??!".
Зачем мне это спрашивать?
> RustRust'у уже 7 лет, а единственное что "на нём" было написано - это очередной "вскукарек" в комментариях
>> Rust
> Rust'у уже 7 лет, а единственное что "на нём" было написано -
> это очередной "вскукарек" в комментарияхНа нем вообще-то целая Redox написана. А вот что написано на go акромя всякой санной прикладухе - это еще большой вопрос.
типичный pet-проект у которого 0 пользователей
>А вот что написано на go акромя всякой санной прикладухе - это еще большой вопрос.писать системный софт на языке со сборкой мусора. Ловите наркомана!
А с malloc/new не проблема?
https://wiki.mozilla.org/Quantum
Quantum - замена Gecko, но Gecko пока никуда не делся, так что ещё не готово
Там же написано, что это не замена. Они внедряют наработки в текущий gecko. Например, движок CSS https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en.../.
На rust написано низкоуровневое ядро хранилища файлов в Dropbox. Правда, высокоуровневая кластерная обвязка на Go.
Go потому что рулит.
***, серьезно? Ещё одна компания решила реализовать управление контейнерами на языке в котором нельзя нормально выполнить fork подготовив под него контекст?..
Видимо, в этом такой же смысл, как писать на "эзотерических" языках программирования.
Некоторые до сих пор пишут под виндовс... а там с форком вообще беда...
Для того, чтобы запустить сервис под systemd не нужны эти доисторические кривляния с форками.
Гы, форк нужен не только чтобы запускать сервис,посмотри на работающий nginx, например. Сможешь такое сделать на systemd?
тсс, а то потеринг вызов примет
открою страшную тайну: в самом systemd используется fork
дорогой аноним, вот объясни мне тёмному - зачем тебе fork? форкаться на каждый контейнер? но это ведь не для hello world'ов на домашней тачке анонима, это для серьёзных людей, у которых и 10к контейнеров может быть, и 100к, и 1кк. ты представляешь, дорогой аноним, что будет с серваком при 1кк процессов? а миллион горутин - дело обычное в highload.
Как будто этот твой горУтин умеет что-то большее, чем позволяет ядро. Чем POSIX thread не угодили, ну кроме не осиляторства?
Posix thread требует больше памяти чем потоки, в остальном не плох.
> ты представляешь, дорогой аноним, что будет с серваком при 1кк процессов?Ммм, и что будет? Объясни мне тёмному как вырастет производительность от того что кучу задач еще и оберткой обернуть? Не очень понимаю. Потому что возможностьей непосредственно железа недостаточно чтобы корректно управлять параллельным выполнением всей этой кучи?
Присоединяюсь к вопросу
man context switching. передача контроля от одного процесса другому -- это определённый оверхед. и при тысячах процессов наступает ой. от того и c10k problem.
> передача контроля от одного процесса другому -- это определённый оверхед. и при тысячах
> процессов наступает ойне хотел бы тебя огорчать, но context switching, как явствует из названия, не совсем переводится как "передача контроля от одного процесса другому", а вот process switching тебе таки придется делать, потому что процессоров у тебя все равно не тысячи. Это не "передача контроля", а просто запуск процесса на процессоре. То есть - загрузить селекторы, загрузить регистры, включая IP. Подождать отмерянное время (система отмеряния - одна из самых сложных хреновин в подобных задачах), прервать процесс, сохранить регистры, перезагрузить селекторы и регистры для другого процесса - и так каждый квант времени. Потому что процессов таки больше чем ядер, а выполняться они должны более-менее параллельно.
Можешь попытаться выполнять эту процедуру вручную, без всякого context switching вообще, но вообще-то современный процессор умеет делать ее полу-автоматически, и делает он это вполне эффективно, его не злые враги-вредители проектировали именно для многозадачной работы.
Только вот чудес не бывает, и если на каждое физически существующее ядро у тебя приедет очередь из нескольких сотен процессов - работать твоя система будет очень и очень медленно, чем ты их не распределяй. Заметим, тут ни слова об оверхеде - он есть, но на фоне самого факта очереди на исполнение - незначителен (тысяча процессов - это всего лишь табличка из тысячи строк, как бы ни был неудачно построен процесс ее сканирования, основное время уйдет не на это)
во-первых, открываем гугль про "context switching" -> "A context switch (also sometimes referred to as a process switch or a task switch)" и не спорим про терминологию.во-вторых, видел когда-нибудь несколько тысяч активных httpd-процессов? я видел, не надо мне рассказывать, что "оверхед незначителен", оно всё просто впадает в кому.
> во-первых, открываем гугль про "context switching"с каких пор мусор из гугля является авторитетным мнением? Его такие же как ты писали, не видящие разницы.
> во-вторых, видел когда-нибудь несколько тысяч активных httpd-процессов?
я их когда-то в молодости по паре раз за ночь видел, и чего? Причем бы тут clear containers?
> не надо мне рассказывать, что "оверхед незначителен", оно всё просто впадает в кому.
тебе не пришло в голову, что оно впадает в кому из-за необходимости обработать одновременно тысчонку запросов одним физическим процессором, а вовсе не из-за мистического "context switching"? И хоть ты вдоль их обрабатывай, хоть поперек, результат будет одинаков. Более того - банальное блокирование новых запросов обычно вполне себе быстро выводит такую систему из "комы", если там не успела память кончиться или какие-нибудь внутриядерные структуры.
Забавно, что тебе даже не приходит в голову подумать, что начинается это лавинное нарастание процессов чаще всего именно из-за того, что какой-то _один_ процесс (или несколько однотипных, роботы обычно пачками ходят) задумывается слишком надолго (лочит базу, или просто тупит). То есть все из-за той же банальной нехватки мощности - на _содержательный_ процесс/ы, а не на процесс управления процессами.
> тебе не пришло в голову, что оно впадает в кому из-за необходимости обработать одновременно тысчонку запросов одним физическим процессором, а вовсе не из-за мистического "context switching"?погугли уже c10k problem и не позорься.
переключение контекста происходит в сотни раз дольше, чем вызов - возврат в рамках одного процесса; см. П.И.Рудаков, К.Г.Финогенов "программируем на языке ассемблера IBM PC" часть 3 ст.67 "Переключение задач"; кстати много понятных картинок в этой книжке, и на русском.
> переключение контекста происходит в сотни раз дольше, чем вызовпроблема в том, что содержательный процесс после этого, не поверишь, норовит сам исполняться - и это не сотни тиков, а сотни тысяч-миллионы до следующего context-switch, который, чаще всего, еще и будет вызван не планировщиком, а самим процессом. Поэтому оверхеда в размере 0.01% ты бы даже и не заметил. На практике, к сожалению, банально "переключать контексты" получится, если у тебя ровно двухзадачная система (какие-то академические "true-rt"-os так и делали). А в реальности добавляется еще и оверхед от планировщика, и, хотя это место во всех современных системах вылизано круче чем у кота яйца, одних диссертаций десятками защищено на эти темы, там, к сожалению, далеко даже и не 0.1, и еще и имеет свойство нелинейно расти при увеличении числа процессов (что логично - при 1000 на ядро у тебя все равно система мертво повиснет, оптимизировать надо случай 10-300, когда есть еще шансы разойтись по-хорошему, если процессы короткоживущие)
а книжка для начинающих была и ничего, только устарела лет на 20, а материалы авторы собирали еще раньше, в самое неблагодарное время, когда часть команд процессора интел раздавал под nda.
Ололо. Дорогой leap42, расскажите же мне, как работают контейнеры, не создавая процессы.
Ты действительно веришь в то, что стандартная библиотека go не позволяет создавать процессы, или просто прикидываешься идиотом?
Т.е. там будут все контейнеры в одном процессе и этим вашим гарутиным что-то делаться? Круто. Хочу реально увидеть 100к контейнеров и шоб все в одном процессе. Надеюсь в этих ваших хайлоадах такой процесс не умрет, а то ведь там 100л контейнеров внутри.
У нас в с++ тоже есть контейнеры: std::vector, std::map, std::list и всякие другие. Можно делать миллиарды их прямо в одном потоке без всяких там горутин.
зачетный вброс, прямо поржали
А у нас с другой стороны, в Го, например, есть сборка мусора, так что контейнеры вовремя вывозят машиной. Платим по стандартному тарифу без всяких там плюсов.
вообще то в go есть fork, но только это не тот fork из libc. Вопрос в другом, вам кто то запрещает пользоваться сисколы в го?
> Вопрос в другом, вам кто то запрещает пользоваться сисколы в го?fork() - это, мягко говоря, не совсем сисколл. (самое смешное, что в линуксе fork даже не вызывает кернельный fork, он вызывает clone)
форкнутая go -программа, вероятнее всего, немедленно закончит свое существование по sig11, несовместимом с жизнью.
ну это вы про glibc. Я вообще веду к тому что отсутствие в go форка к которому мы привыкли в си не является непреодолимой проблемой.
> Я вообще веду к тому что отсутствие в go форка к которому мы привыкли в си
> не является непреодолимой проблемой.это смотря что на нем делать - если просто контейнер (или любой другой процесс) запустить (то есть нужен аналог только fork || exec по сути) - то никаких проблем, хоть действительно напрямую два сисколла дергай. Да и штатный механизм там вполне себе есть.
Если нужен юникс-стайл в виде мастер-процесса и пачки потомков, которыми надо управлять, а не просто запустить и забыть - то, скорее всего, ничего не получится, придется либо переизобретать колесо, либо использовать принятые в языке конструкции, наплевав на эффективность.
> что даёт возможность уместить 3500 виртуальных машин на сервере с 128 Гб ОЗУ37мб на машину, это только накладные расходы, вообщем маркетинговая чушня, как обычно.
CoW? Не, не слышал.
Что случится когда все виртуалки запустят по процессу обработки с различными данными на входе? Могу предположить что часть из них тупо выгрузится из-за отсутсвия рамы.
> Что случится когда все виртуалки запустят по процессу обработки с различными данными на
> входе?ровно то же самое, что случилось бы, если бы процессы запускались просто в одной системе - плюс 35 мегабайт сверху. Разумеется, это если верить интелу. Что довольно таки небольшая плата за возможность изолировать эти процессы напрочь (судя по словам о поддержке SR-IOV, которое, кстати, авторам перевода на заметку, (пара)виртуализация сетевой карты, а не фича процессора, там даже сетевую можно изолированную каждому выдать)
существующие альтернативы жрут в лучшем случае первые сотни (либо здравствуй вероятность очередного рута "непривиллегированного" контейнера, заделавшегося рутом уже на хосте - и жрут при этом все равно не 35)
в общем, если бы я где-то упирался в доступную виртуалкам память, имело бы смысл на такое посмотреть.
128 гб накладных расходов на 3500 процессов обработки данных? Спасибо, но нам такое не нужно.
> 128 гб накладных расходов на 3500 процессов обработки данных? Спасибо, но нам
> такое не нужно.ну, значит, "вам не нужно", живите без изоляции этих процессов или с ее бесполезной имитацией (впрочем, тоже небесплатной). Стесняюсь спросить - а сами процессы-то у вас, что, даже и того не потребляют? А что они тогда вообще делают?
Я слабо себе представляю область применимости таких контейнеров ровно по противоположной причине - у меня никогда не было процессорной мощности на 3500 процессов которые на самом деле что-то делают. Я даже не очень представляю, что бы это такое вообще могло быть.
конечно слышал, вот только CoW c изолированными окружениями работает не так как вы себе это представляете.
Откуда ты так хорошо знаешь, что я себе представляю?
Там чуть пониже цитату привели, рекомендую ознакомиться.
О запуске графических приложениях, полагаю, не может быть и речи?
Посмотрел доки и так и не понял, память может свободно разделяться между контейнерами или нет? Т.е. пусть у нас 4 ГБ памяти всего, два контейнера, сейчас один потребляет 1 ГБ, а второй 2 ГБ, потом первый потребляет 2 ГБ, а второй 1 ГБ - без переконфигурации. Потому что overcommiting + memory ballooning на виртуалках все равно не дает такой эффективности, как общая память между контейнерами (ну а лимиты навешать никогда не проблема).Еще смущает, что на https://lwn.net/Articles/644675/ в комментариях утверждают, что непонятно, как добиться заявленного оверхеда в 20 МБ на контейнер, по факту выходит 60.
по той же ссылке на lwn.net написано:>[оверквотинг удален]
>in the ext4 filesystem. If your storage is visible as regular memory to the host CPU, DAX
>enables the system to do execute-in-place of files stored there. In other words, when
>using DAX, you bypass the page cache and virtual-memory subsystem completely. For
>applications that use mmap(), this means a true zero-copy approach, and for code that
>uses the read() system call (or equivalent) you will have only one copy of the data. DAX
>was originally designed for fast flash-like storage that shows up as memory to the CPU;
>but in a virtual-machine environment, this type of storage is easy to emulate. All we
>need to do on the host is map the disk image file into the guest's physical memory, and
>use a small device driver in the guest kernel that exposes this memory region to the
>kernel as a DAX-ready block device.На всякий случай еще раз повторю:
> For applications that use mmap(), this means a true zero-copy approach, and for code
> that uses the read() system call (or equivalent) you will have only one copy of the data.
Я это видел, но не вижу тут ответа на вопрос.Во-первых, мне в целом без разницы, zero-copy или нет - интересует, освобождаемая программой в таком контейнере память тут же возвращается в хост-систему и доступна другим контейнерам или нет?
Во-вторых, а что с обычным malloc (когда размер аллокации недостаточен, чтобы он переключался на mmap).
Для тех кто не понял цифры. 128гб это и есть объем накладных расходов 3500 виртуалок.
Калькулятор не осилил?
Выложите свои вычисления, нам всем очень интересно будет посмотреть.
> Для тех кто не понял цифры. 128гб это и есть объем накладных
> расходов 3500 виртуалок.Как-то не так я, видимо, истолковал фразу
> уместить 3500 виртуальных машин на сервере с 128 Гб ОЗУ.Или всё-таки ты?