LINUX.ORG.RU

mklinux-v7.0-mk2

 , mklinux, ,


0

2

Представлен первый публичный выпуск проекта Multikernel Linux mklinux-v7.0-mk2, развивающего вариант ядра Linux, дополненный возможностью выполнения нескольких независимых экземпляров ядра на одном физическом компьютере без использования гипервизора и виртуализации. Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам и может использоваться для запуска отдельных изолированных системных окружений. Первый выпуск основан на ядре Linux 7.0 и содержит сборочную настройку CONFIG_MULTIKERNEL, при отключении которой ядро становится полностью аналогично штатному ядру 7.0. Из архитектур CPU пока поддерживается только x86_64.

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

Хостовое ядро обеспечивает распределение имеющихся CPU, памяти и PCI-устройств между параллельно работающими дополнительными экземплярами ядра. Каждый экземпляр выполняется на отдельном выделенном ядре CPU, работает с закреплёнными за ним устройствами и имеет доступ к выделенной области физической памяти. Одновременное выполнение нескольких ядер осуществляется без виртуализации, используя SMP-обработчик, распределяющий доступные CPU. Поддерживается динамическое выделение ресурсов запускаемым окружениям и обеспечение предсказуемой производительности.

Благодаря исключению свойственных виртуализации накладных расходов, производительность при использовании Multikernel оценивается как близкая к производительности выполнения на отдельном оборудовании. При использовании Multikernel отсутствует стадия передачи управления между виртуальными машинами (VM exit), не используются страницы памяти второго уровня, отдельная модель устройств и трансляция IOMMU. При сравнении с гипервизором KVM при использовании Multikernel отмечается повышение производительности различных системных вызовов и функций от 1.07 до 2.5 раз (fork + exit — 1.07x, write() — 1.39x, AF_UNIX — 1.55x, Pipe — 2.18x, переключение контекста — 2.50x), пропускная способность и задержки при работе с памятью находятся на одном уровне.

>>> Подробности на OpenNET

★★

Проверено: dataman ()
Последнее исправление: cetjs2 (всего исправлений: 4)

Я ж правильно понимаю, что это прикольная штука, но она практически во всем уступает «специализированным аналогам», т.к. не изолируешь в должной степени ресурсы при таком подходе…?

Sm0ke85
()

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

legolegs ★★★★★
()
Ответ на: комментарий от legolegs

Хостовое ядро обеспечивает распределение имеющихся CPU, памяти и PCI-устройств между параллельно работающими дополнительными экземплярами ядра. Каждый экземпляр выполняется на отдельном выделенном ядре CPU, работает с закреплёнными за ним устройствами и имеет доступ к выделенной области физической памяти

По идее, за этим должно следить хостовое ядро

hippi90 ★★★★★
()

Каждый экземпляр выполняется на отдельном выделенном ядре CPU

Сколько ядер процессора, столько экземпляров ядра линукс можно запустить, так получается?

Вспомнил:

Представлен открытый гипервизор Jailhouse 0.7, развиваемый компанией Siemens

https://www.opennet.ru/opennews/art.shtml?num=46492

Гипервизор реализован в виде модуля для ядра Linux и обеспечивает виртуализацию на уровне ядра. Для управления изоляцией используются предоставляемые современными CPU аппаратные механизмы виртуализации. Отличительными особенностями Jailhouse являются легковесная реализация и ориентация на привязку виртуальных машин к фиксированному CPU, области ОЗУ и аппаратным устройствам. Такой подход позволяет на одном физическом многопроцессорном сервере обеспечить работу нескольких независимых виртуальных окружений, каждое из которых закреплено за своим процессорным ядром.

С 2013 по 2020 год новости выходили

https://www.opennet.ru/keywords/jailhouse.html

(На опеннете в комментариях уже вспомнили jailhouse)

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 3)

Чуваки переизобрели Xen, значительно ухудшив безопасность за счёт игнорирования аппаратной поддержки ради сомнительной выгоды на микробенчмарках. Уж лучше б очередной форк иксов навайбкодили.

zabbal ★★★☆☆
()

прикладная реалдизация давней темы: давайте вставим в виртуальность еще одну виртуальность чтобы можно виртуализровать виртуальность, пока виртуализируешь виртуальность… (с) тачка на прокачку.

вместо качественности кода сделали многоголового горыныча: одна голова пьёт - все остальные мучаются похмельем…
куда в следующий раз виртуализацию впиховывать будём ??

pfg ★★★★★
()
Ответ на: комментарий от dobro

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

ugoday ★★★★★
()
Ответ на: комментарий от pfg

вместо качественности кода сделали многоголового горыныча: одна голова пьёт - все остальные мучаются похмельем…

куда в следующий раз виртуализацию впиховывать будём ??

Что у вас совсем фантазии нет? Теперь нужно многожопого горыныча делать.

ugoday ★★★★★
()

Интересная штука. Понятно что это развитие контейнеров, вместе с тем это маленький шажочек к микроядерной архитектуре.

necroromnt
()

выполнения нескольких независимых экземпляров ядра на одном физическом компьютере без использования гипервизора

Очередной ядерный сепаратизм «без царя в голове» :)

quickquest ★★★★★
()
Ответ на: комментарий от ugoday

Примерно об этом и подумал. Кейс с кучей ядер, собранных под конкретные оч. узкие задачи.

dobro
()
Ответ на: комментарий от Xintrea

Насколько я понял из описания, тем что хуже с безопасностью(все ядра имеют полный доступ к железу), но проще с настройкой(не нужно заранее продумывать архитектуру сервера/выделять ресурсы под хостовое ядро на этапе установки) так как конфигурится «на лету».

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

А миграцию процессов с одного железа на другое так же легко осуществить, как с контейнерами или виртуальной машиной?

VIT ★★★
()
Последнее исправление: VIT (всего исправлений: 1)
Ответ на: комментарий от VIT

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

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

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

VIT ★★★
()
Ответ на: комментарий от VIT

Но насколько я понял из описания, все экземпляры будут одной версии. Т.е. вариант для разработчиков тоже не подходит.

shell-script ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.