The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Intel представил инструментарий Clear Containers 3.0, переписанный на языке Go

23.09.2017 11:50

Компания Intel опубликовала значительный выпуск инструментария Clear Containers 3.0, предоставляющего средства для управления контейнерами, для изоляции которых используется гипервизор KVM и встроенные в процессоры Intel механизмы виртуализации Intel VT и SR-IOV. Код поставляется под лицензией Apache 2.0.

Новый выпуск примечателен кардинальной переработкой кодовой базы и рефакторингом архитектуры проекта. Инструментарий и компоненты runtime переписаны на языке Go (ранее использовался язык Си). Проведена большая работа по улучшению интеграции Clear Containers в сформировавшуюся экосистему контейнерной изоляции, в том числе расширены средства для задействования в проекте кода, используемого в контейнерах на базе namespaces и cgroups.

Функции для обеспечения работы аппаратно виртуализированных контейнеров вынесены в модульную и независящую от типа гипервизора библиотеку virtcontainers. Новая реализация runtime (cc-runtime) построена поверх библиотеки virtcontainers и приведена к полной совместимости со спецификацией OCI, определяющей унифицированный формат образов контейнеров и runtime-компонентов, что позволяет использовать cc-runtime совместно с Docker в качестве прозрачной замены runc. Кроме того обеспечена поддержка прослойки 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 (прямой доступ к ФС в обход страничного кэша без применения уровня блочных устройств), а для дедупликации одинаковых областей памяти применяется технология KSM (Kernel Shared Memory), что позволяет организовать совместное использование ресурсов хост-системы и подключить к разным гостевым системам общий шаблон системного окружения. Начиная с выпуска 3.0 в Clear Containers также предоставляются средства регулирования активации процесса выявления дубликатов (KSM throttling).

  1. Главная ссылка к новости (https://01.org/blogs/alleelan/...)
  2. OpenNews: Intel представил Clear Linux с контейнерами приложений на базе виртуализации
  3. OpenNews: SUSE и openSUSE представили Kubic, платформу для развёртывания контейнерной инфраструктуры
  4. OpenNews: Компания Oracle открыла код инструментария для изолированных контейнеров
  5. OpenNews: Утверждена единая спецификация для образов и runtime изолированных контейнеров
  6. OpenNews: Выпуск системы управления контейнерами LXC 2.1
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/47252-clear
Ключевые слова: clear, linux, intel, container, golang
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (68) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, фребсдоюзрнемогунайтивыход (?), 12:30, 23/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    чому не православный Rust?
     
     
  • 2.2, bircoph (ok), 12:42, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что он недостаточно правослаен и чуть более чем правоверен.
     
  • 2.3, Аноним (-), 12:43, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Потому что пишет прагматичные кодеры из intelа, а не неосиляторы плюсов из тоpмозиллы.
     
     
  • 3.10, VINRARUS (ok), 15:15, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Прагматичные пишут на С, очень прагматичные пишут на Ассемблере.
     
     
  • 4.11, Аноним (-), 15:28, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    перфокарты же!
     
     
  • 5.24, Аноним (-), 18:18, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Ты знаешь разницу между языком программирования и носителем данных?
     
  • 5.27, jh (?), 18:29, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    машинные коды. писать в машинных кодах, то еще удовольствие
     
     
  • 6.34, Sup (?), 21:45, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну это мы еще на калькуляторе Электроника Б3-34 делали.
     
     
  • 7.58, Аноним (-), 07:23, 25/09/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Ну это мы еще на калькуляторе Электроника Б3-34 делали.

    Контейнерную изоляцию на калькуляторах?
    Да вы монстры!

     
  • 2.4, Аноним (-), 12:58, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я помню, в Rust как выпилили простые легковесные потоки, так и не впилили обратно. А без оных, оно и не очень нужно.
     
     
  • 3.6, Аноним (-), 14:04, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Лол кек чебурек. И зачем нужны легковесные потоки в управлялке контейнерами?
     
     
  • 4.64, Аноним (-), 08:41, 26/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ты ещё спроси: "а зачем они вообще нужны?!?!?!??!".
     
     
  • 5.65, Аноним (-), 12:36, 26/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем мне это спрашивать?
     
  • 2.14, leap42 (ok), 16:38, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Rust

    Rust'у уже 7 лет, а единственное что "на нём" было написано - это очередной "вскукарек" в комментариях

     
     
  • 3.17, Аноним (-), 16:57, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> Rust
    > Rust'у уже 7 лет, а единственное что "на нём" было написано -
    > это очередной "вскукарек" в комментариях

    На нем вообще-то целая Redox написана. А вот что написано на go акромя всякой санной прикладухе - это еще большой вопрос.

     
     
  • 4.45, leap42 (ok), 04:02, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    типичный pet-проект у которого 0 пользователей
     
  • 4.54, Аноним (-), 16:20, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >А вот что написано на go акромя всякой санной прикладухе - это еще большой вопрос.  

    писать системный софт на языке со сборкой мусора. Ловите наркомана!

     
     
  • 5.71, Аноним (-), 16:36, 28/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А с malloc/new не проблема?
     
  • 3.28, Вы забыли заполнить поле Name (?), 19:33, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://wiki.mozilla.org/Quantum
     
     
  • 4.46, leap42 (ok), 04:04, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Quantum - замена Gecko, но Gecko пока никуда не делся, так что ещё не готово
     
     
  • 5.56, Вы забыли заполнить поле Name (?), 20:51, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Там же написано, что это не замена. Они внедряют наработки в текущий gecko. Например, движок CSS https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-a
     
  • 3.59, funny.falcon (?), 08:22, 25/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На rust написано низкоуровневое ядро хранилища файлов в Dropbox. Правда, высокоуровневая кластерная обвязка на Go.
     
  • 2.60, Аноним (-), 08:36, 25/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Go потому что рулит.
     

  • 1.5, Аноним (-), 13:13, 23/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    ***, серьезно? Ещё одна компания решила реализовать управление контейнерами на языке в котором нельзя нормально выполнить fork подготовив под него контекст?..
     
     
  • 2.7, Аноним (-), 14:05, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Видимо, в этом такой же смысл, как писать на "эзотерических" языках программирования.
     
  • 2.8, Аноним (-), 14:52, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Некоторые до сих пор пишут под виндовс... а там с форком вообще беда...
     
  • 2.9, anonymous (??), 15:00, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Для того, чтобы запустить сервис под systemd не нужны эти доисторические кривляния с форками.
     
     
  • 3.12, Аноним (-), 15:39, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Гы, форк нужен не только чтобы запускать сервис,посмотри на работающий nginx, например. Сможешь такое сделать на systemd?
     
     
  • 4.13, Анонимы (?), 15:52, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    тсс, а то потеринг вызов примет
     
  • 3.55, Аноним (-), 16:24, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    открою страшную тайну: в самом systemd используется fork
     
  • 2.15, leap42 (ok), 16:46, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    дорогой аноним, вот объясни мне тёмному - зачем тебе fork? форкаться на каждый контейнер? но это ведь не для hello world'ов на домашней тачке анонима, это для серьёзных людей, у которых и 10к контейнеров может быть, и 100к, и 1кк. ты представляешь, дорогой аноним, что будет с серваком при 1кк процессов? а миллион горутин - дело обычное в highload.
     
     
  • 3.16, Аноним (-), 16:55, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Как будто этот твой горУтин умеет что-то большее, чем позволяет ядро. Чем POSIX thread не угодили, ну кроме не осиляторства?
     
     
  • 4.51, анон (?), 12:51, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Posix thread требует больше памяти чем потоки, в остальном не плох.
     
  • 3.18, Аноним (-), 16:58, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > ты представляешь, дорогой аноним, что будет с серваком при 1кк процессов?

    Ммм, и что будет? Объясни мне тёмному как вырастет производительность от того что кучу задач еще и оберткой обернуть? Не очень понимаю. Потому что возможностьей непосредственно железа недостаточно чтобы корректно управлять параллельным выполнением всей этой кучи?

     
     
  • 4.40, Онаним (?), 00:47, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Присоединяюсь к вопросу
     
     
  • 5.57, й (?), 22:18, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    man context switching. передача контроля от одного процесса другому -- это определённый оверхед. и при тысячах процессов наступает ой. от того и c10k problem.
     
     
  • 6.61, пох (?), 18:59, 25/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > передача контроля от одного процесса другому -- это определённый оверхед. и при тысячах
    > процессов наступает ой

    не хотел бы тебя огорчать, но context switching, как явствует из названия, не совсем переводится как "передача контроля от одного процесса другому", а вот process switching тебе таки придется делать, потому что процессоров у тебя все равно не тысячи. Это не "передача контроля", а просто запуск процесса на процессоре. То есть - загрузить селекторы, загрузить регистры, включая IP. Подождать отмерянное время (система отмеряния - одна из самых сложных хреновин в подобных задачах), прервать процесс, сохранить регистры, перезагрузить селекторы и регистры для другого процесса - и так каждый квант времени. Потому что процессов таки больше чем ядер, а выполняться они должны более-менее параллельно.

    Можешь попытаться выполнять эту процедуру вручную, без всякого context switching вообще, но вообще-то современный процессор умеет делать ее полу-автоматически, и делает он это вполне эффективно, его не злые враги-вредители проектировали именно для многозадачной работы.

    Только вот чудес не бывает, и если на каждое физически существующее ядро у тебя приедет очередь из нескольких сотен процессов - работать твоя система будет очень и очень медленно, чем ты их не распределяй. Заметим, тут ни слова об оверхеде - он есть, но на фоне самого факта очереди на исполнение - незначителен (тысяча процессов - это всего лишь табличка из тысячи строк, как бы ни был неудачно построен процесс ее сканирования, основное время уйдет не на это)

     
     
  • 7.62, й (?), 19:10, 25/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    во-первых, открываем гугль про "context switching" -> "A context switch (also sometimes referred to as a process switch or a task switch)" и не спорим про терминологию.

    во-вторых, видел когда-нибудь несколько тысяч активных httpd-процессов? я видел, не надо мне рассказывать, что "оверхед незначителен", оно всё просто впадает в кому.

     
     
  • 8.68, пох (?), 23:29, 26/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    с каких пор мусор из гугля является авторитетным мнением Его такие же как ты пи... текст свёрнут, показать
     
     
  • 9.70, й (?), 12:11, 27/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    погугли уже c10k problem и не позорься ... текст свёрнут, показать
     
  • 4.69, nonemo (?), 11:13, 27/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    переключение контекста происходит в сотни раз дольше, чем вызов - возврат в рамках одного процесса; см. П.И.Рудаков, К.Г.Финогенов "программируем на языке ассемблера IBM PC" часть 3 ст.67 "Переключение задач"; кстати много понятных картинок в этой книжке, и на русском.
     
     
  • 5.72, пох (?), 16:02, 30/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > переключение контекста происходит в сотни раз дольше, чем вызов

    проблема в том, что содержательный процесс после этого, не поверишь, норовит сам исполняться - и это не сотни тиков, а сотни тысяч-миллионы до следующего context-switch, который, чаще всего, еще и будет вызван не планировщиком, а самим процессом. Поэтому оверхеда в размере 0.01% ты бы даже и не заметил. На практике, к сожалению, банально "переключать контексты" получится, если у тебя ровно двухзадачная система (какие-то академические "true-rt"-os так и делали). А в реальности добавляется еще и оверхед от планировщика, и, хотя это место во всех современных системах вылизано круче чем у кота яйца, одних диссертаций десятками защищено на эти темы, там, к сожалению, далеко даже и не 0.1, и еще и имеет свойство нелинейно расти при увеличении числа процессов (что логично - при 1000 на ядро у тебя все равно система мертво повиснет, оптимизировать надо случай 10-300, когда есть еще шансы разойтись по-хорошему, если процессы короткоживущие)

    а книжка для начинающих была и ничего, только устарела лет на 20, а материалы авторы собирали еще раньше, в самое неблагодарное время, когда часть команд процессора интел раздавал под nda.

     
  • 3.19, Аноним (-), 17:20, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Ололо. Дорогой leap42, расскажите же мне, как работают контейнеры, не создавая процессы.
     
     
  • 4.32, Ordu (ok), 20:22, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ты действительно веришь в то, что стандартная библиотека go не позволяет создавать процессы, или просто прикидываешься идиотом?
     
  • 3.31, Аноним (-), 19:58, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Т.е. там будут все контейнеры в одном процессе и этим вашим гарутиным что-то делаться? Круто. Хочу реально увидеть 100к контейнеров и шоб все в одном процессе. Надеюсь в этих ваших хайлоадах такой процесс не умрет, а то ведь там 100л контейнеров внутри.
     
     
  • 4.39, Аноним (-), 00:26, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У нас в с++ тоже есть контейнеры: std::vector, std::map, std::list и всякие другие. Можно делать миллиарды их прямо в одном потоке без всяких там горутин.
     
     
  • 5.48, Аноним (-), 08:03, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    зачетный вброс, прямо поржали
     
  • 5.67, Добрый анон (?), 18:32, 26/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А у нас с другой стороны, в Го, например, есть сборка мусора, так что контейнеры вовремя вывозят машиной. Платим по стандартному тарифу без всяких там плюсов.
     
  • 2.22, Аноним (-), 17:45, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    вообще то в go есть fork, но только это не тот fork из libc. Вопрос в другом, вам кто то запрещает пользоваться сисколы в го?
     
     
  • 3.29, ваш К.О. (?), 19:40, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Вопрос в другом, вам кто то запрещает пользоваться сисколы в го?

    fork() - это, мягко говоря, не совсем сисколл. (самое смешное, что в линуксе fork даже не вызывает кернельный fork, он вызывает clone)
    форкнутая go -программа, вероятнее всего, немедленно закончит свое существование по sig11, несовместимом с жизнью.

     
     
  • 4.41, Аноним (-), 02:09, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    ну это вы про glibc. Я вообще веду к тому что отсутствие в go форка к которому мы привыкли в си не является непреодолимой проблемой.
     
     
  • 5.52, . (?), 14:28, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Я вообще веду к тому что отсутствие в go форка к которому мы привыкли в си
    > не является непреодолимой проблемой.

    это смотря что на нем делать - если просто контейнер (или любой другой процесс) запустить (то есть нужен аналог только fork || exec по сути) - то никаких проблем, хоть действительно напрямую два сисколла дергай. Да и штатный механизм там вполне себе есть.
    Если нужен юникс-стайл в виде мастер-процесса и пачки потомков, которыми надо управлять, а не просто запустить и забыть - то, скорее всего, ничего не получится, придется либо переизобретать колесо, либо использовать принятые в языке конструкции, наплевав на эффективность.

     

  • 1.21, Аноним (-), 17:37, 23/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > что даёт возможность уместить 3500 виртуальных машин на сервере с 128 Гб ОЗУ

    37мб на машину, это только накладные расходы, вообщем маркетинговая чушня, как обычно.

     
     
  • 2.26, Аноним (-), 18:26, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    CoW? Не, не слышал.
     
     
  • 3.33, ksksfcc (?), 20:27, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Что случится когда все виртуалки запустят по процессу обработки с различными данными на входе? Могу предположить что часть из них тупо выгрузится из-за отсутсвия рамы.
     
     
  • 4.37, пох (?), 22:42, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Что случится когда все виртуалки запустят по процессу обработки с различными данными на
    > входе?

    ровно то же самое, что случилось бы, если бы процессы запускались просто в одной системе - плюс 35 мегабайт сверху. Разумеется, это если верить интелу. Что довольно таки небольшая плата за возможность изолировать эти процессы напрочь (судя по словам о поддержке SR-IOV, которое, кстати, авторам перевода на заметку, (пара)виртуализация сетевой карты, а не фича процессора, там даже сетевую можно изолированную каждому выдать)  

    существующие альтернативы жрут в лучшем случае первые сотни (либо здравствуй вероятность очередного рута "непривиллегированного" контейнера, заделавшегося рутом уже на хосте - и жрут при этом все равно не 35)

    в общем, если бы я где-то упирался в доступную виртуалкам память, имело бы смысл на такое посмотреть.

     
     
  • 5.43, Аноним (-), 03:03, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    128 гб накладных расходов на 3500 процессов обработки данных? Спасибо, но нам такое не нужно.
     
     
  • 6.53, пох (?), 14:35, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > 128 гб накладных расходов на 3500 процессов обработки данных? Спасибо, но нам
    > такое не нужно.

    ну, значит, "вам не нужно", живите без изоляции этих процессов или с ее бесполезной имитацией (впрочем, тоже небесплатной). Стесняюсь спросить - а сами процессы-то у вас, что, даже и того не потребляют? А что они тогда вообще делают?

    Я слабо себе представляю область применимости таких контейнеров ровно по противоположной причине - у меня никогда не было процессорной мощности на 3500 процессов которые на самом деле что-то делают. Я даже не очень представляю, что бы это такое вообще могло быть.

     
  • 3.42, Аноним (-), 02:12, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    конечно слышал, вот только CoW c изолированными окружениями работает не так как вы себе это представляете.
     
     
  • 4.49, Аноним (-), 10:20, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Откуда ты так хорошо знаешь, что я себе представляю?
    Там чуть пониже цитату привели, рекомендую ознакомиться.
     

  • 1.25, Аноним (-), 18:26, 23/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    О запуске графических приложениях, полагаю, не может быть и речи?
     
  • 1.36, Stax (ok), 22:38, 23/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Посмотрел доки и так и не понял, память может свободно разделяться между контейнерами или нет? Т.е. пусть у нас 4 ГБ памяти всего, два контейнера, сейчас один потребляет 1 ГБ, а второй 2 ГБ, потом первый потребляет 2 ГБ, а второй 1 ГБ - без переконфигурации. Потому что overcommiting + memory ballooning на виртуалках все равно не дает такой эффективности, как общая память между контейнерами (ну а лимиты навешать никогда не проблема).

    Еще смущает, что на https://lwn.net/Articles/644675/ в комментариях утверждают, что непонятно, как добиться заявленного оверхеда в 20 МБ на контейнер, по факту выходит 60.

     
     
  • 2.38, Аноним (-), 23:16, 23/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    по той же ссылке на lwn net написано gt оверквотинг удален На всякий случай е... большой текст свёрнут, показать
     
     
  • 3.66, Stax (ok), 18:05, 26/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Я это видел, но не вижу тут ответа на вопрос.

    Во-первых, мне в целом без разницы, zero-copy или нет - интересует, освобождаемая программой в таком контейнере память тут же возвращается в хост-систему и доступна другим контейнерам или нет?
    Во-вторых, а что с обычным malloc (когда размер аллокации недостаточен, чтобы он переключался на mmap).

     

  • 1.44, Аноним (-), 03:06, 24/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Для тех кто не понял цифры. 128гб это и есть объем накладных расходов 3500 виртуалок.
     
     
  • 2.47, Аноним (-), 04:27, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Калькулятор не осилил?
     
     
  • 3.63, jsjf (?), 20:47, 25/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Выложите свои вычисления, нам всем очень интересно будет посмотреть.
     
  • 2.50, Аноним (-), 10:23, 24/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Для тех кто не понял цифры. 128гб это и есть объем накладных
    > расходов 3500 виртуалок.

    Как-то не так я, видимо, истолковал фразу
    > уместить 3500 виртуальных машин на сервере с 128 Гб ОЗУ.

    Или всё-таки ты?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру