Первый прототип: Unikernels как этап в эволюции Linux

    В начале июля группа инженеров из Red Hat и Бостонского университета выпустила whitepaper, в котором предложила сменить монолитное ядро Linux на архитектуру unikernels. Мы решили разобраться в материале и обсудить реакцию ИТ-комьюнити на это предложение.


    Фото — Eamonn Maguire — Unsplash

    Unikernels как альтернатива


    Известно, что Linux использует монолитное ядро. Оно управляет процессами, сетевыми функциями, периферией и доступом к файловой системе. Однако как пишут авторы статьи из Red Hat и Бостонского университета (стр.1), такая структура имеет свои недостатки. В частности, высокопроизводительные приложения вынуждены использовать фреймворки вроде DPDK и SPDK, чтобы получить беспрепятственный доступ к устройствам ввода/вывода в обход ядра.

    Определенные трудности возникают и в облаке. Для большей безопасности корпоративные приложения развертывают на отдельных виртуальных машинах. Каждая ВМ находится под управлением полновесной операционной системы. В результате вычислительные ресурсы серверов расходуются не самым оптимальным образом.

    Улучшить ситуацию может альтернативный подход — unikernels. Идея следующая — связать приложение с необходимыми библиотеками операционной системы и скомпилировать их в один бинарный файл. После этот «бинарник» можно использовать для загрузки системы. Такой подход дает возможность специализировать функциональность ОС под нужды конкретного приложения.

    Ресурсы такой системы расходуются эффективнее. Также unikernels обладают более высокой производительностью, по сравнению с монолитной архитектурой ядра. Причина — упрощение IO-путей, так как все данные и файлы размещаются в едином адресном пространстве. Также пропадает необходимость переключать контекст между пользовательским пространством и пространством ядра.

    Команда инженеров из Бостонского университета и Red Hat разработала прототип Linux на базе unikernels. Операционная система получила название Unikernel Linux (UKL).

    Что сделали инженеры


    Как заявляют разработчики (стр.3), они изменили всего одиннадцать и добавили двадцать новых строк кода в Linux kernel v5.0.5 и glibc. «Классическое» ядро сохранило работоспособность — пользователь может выбрать способ сборки (UKL или нет).

    Авторы создали небольшую UKL-библиотеку, в которой разместили специальные «заглушки», которые маскируют неиспользуемые системные вызовы. Также они модифицировали линкер ядра, чтобы определять новый тип сегментов, например TLS (thread local storage) из бинарников ELF. Еще был модифицирован процесс сборки, который теперь объединяет код приложения, glibc и UKL-библиотеку в один бинарный файл.

    Инженеры работают над исправлением ряда недостатков. Например, они планируют переместить TLS-память из пространства ядра и отказаться от vmalloc при управлении распределением памяти, чтобы упростить систему.

    Мнения


    Разработчики Red Hat говорят, что UKL может стать полноценной альтернативой для запуска процессов, работающих с аппаратным обеспечением напрямую (в обход ядра). Авторы оригинальной статьи заявляют (стр.2), что сервис кэширования memcached под unikernels работает на 200% быстрее, чем под Linux.

    В целом об инициативе авторов оригинальной статьи положительно отозвалось и ИТ-сообщество. Резиденты Hacker News отметили, что архитектура unikernels значительно повысит безопасность программной среды. В случае взлома приложения хакер получит доступ лишь к его бинарнику.


    Фото — Jack Young — Unsplash

    Один из резидентов Hacker News даже предложил радикальное решение — переписать ядро Linux под unikernels с нуля на Rust. По его словам, язык решит проблему с большим количеством багов, связанных с безопасностью памяти. Другой пользователь назвал идею хорошей, однако предложил подождать несколько лет, пока разработчики языка разберутся с нестабильностью библиотек. Хотя один энтузиаст уже пишет свою операционную систему на Rust. Исходники можно найти на GitHub.

    Другие реализации


    UKL — не единственная реализация операционной системы на базе unikernels. Например, похожее решение разрабатывает группа инженеров из Политехнического университета Виргинии, компании Qualcomm и Рейнско-Вестфальского технического университета Ахена в Германии. Их легковесное ядро называется HermiTux. Оно позволяет быстро запускать приложения поверх гипервизора — по словам авторов, время загрузки не превышает 0,1 сек. Потребление памяти в тестовом окружении составляет 9 Мбайт, что в десять раз меньше, чем у классического ядра Linux.

    Также имеет смысл отметить ОС MirageOS, разработанную на OCaml. Ядро может запускаться поверх гипервизоров Xen, KVM, BHyve и VMM (OpenBSD), а также на мобильных платформах. Система поддерживает несколько десятков библиотек на языке OCaml для выполнения сетевых операций (DNS, SSH, OpenFlow, HTTP, XMPP), работы с хранилищами и параллельной обработки данных. Можно сказать, что MirageOS — это один из первых успешных unikernels-проектов. Интересно, что его сайт с блогом также реализован как unikernel.

    Эти операционные системы уже используются в продакшн-средах многими организациями — например, Кембриджским университетом, IBM, Ericsson и Docker. Есть вероятность, что скоро к этим ОС присоединится новая — Unikernel Linux.



    О чем мы пишем в корпоративном блоге:

    ITGLOBAL.COM
    20,99
    IaaS, Managed IT, PCI DSS, Hybrid Cloud
    Поделиться публикацией

    Комментарии 45

      +6
      Хотя один энтузиаст уже пишет свою операционную систему на Rust.

      На самом деле много кто пишет ОС на Rust, но самая известная с довольно большой командой это:


      https://www.redox-os.org/

        +2
        Из известных ещё Fuchsia частично на Rust написана.
          +1
          Там только SDK для Rust. Тоже неплохо, но вроде никаких компонентов на Rust у них нету.
            0
            Я был под впечатлением, что Fuchsia частично на Rust написана, т.к. видел код на нём в исходниках.
            Например тынц, тынц, тынц и тынц. Ну и ещё много других мест находил.
            В ядре правда ничего на Rust я не нашёл.
            Не понятно также какой процент от общего количества исходников написан на Rust. Но можно попробовать посчитать.
              0
              В данном случае совершенно неважно какой процент написан на Rust. Нужно смотреть за динамикой. Вообще так-то кажется, что как раз для middleware OS Rust вообще подходит идеально: обычно там нет каких-то сильно хитрых алгоритмов (они в других местах системы сидят), но важно не напутать в [относительно] простом коде с правами доступа…

              Если Rust там приживётся и количество компонент на нём будет расти — ну это очень хороший признак.
                0
                Оценить объем использования Rust в Фуксии можно по этому списку измененных файлов BUILD.gn — «Switch Rust test deps to _test targets», вероятно это те «пакеты/библиотеки» что созданы на базе Rust. Более 100 файлов (BUILD.gn).

                Есть отдельная папка garnet/lib/rust/
          +2

          1) Насколько я знаю (поправьте меня, если я ошибаюсь) DPDK и сетевой стэк имеет более легковесный, чем стэк в ядре (который универсальный и все такое), а снижение накладных расходов на syscalls и копирование данных в пользовательское адресное пространство и обратно
          2) Т.е. вся их скомпилированная в один большой бинарь система исполняется в Ring 0? Минус накладные расходы на системные вызовы с переключениями контекста, сбросом буферов TLB и прочим. Минус безопасность. Нужно очень доверять запущенному приложению и быть уверенным, что оно не полезет в чужую память, не упадет и так далее. Вообще, вспоминается проект Microsoft Singularity.

            0
            Вообще, вспоминается проект Microsoft Singularity
            Там хотя бы защита на уровне языка была. Тут скорее Windows 9X и её «надёжность» стоит вспомнить…
              +1
              Да что уж там… Прямой доступ к железу, единое адресное пространство… Вспоминать надо MS-DOS…
              +7

              А какая чужая память, если это приложение — это все, что крутится на машине? Нет никакой чужой памяти.

                0

                Тут больше вопрос по использованию с докером

                  0

                  Так это вместо докера, судя по описанию. Одно приложение в мини-виртуалке

                    0

                    Так эта мини-виртуалка напрямую с железом действует, поверх какой-то ОС/гипервизора?

                      0
                      Если она напрямую с железом, то она уже не виртуалка. Насколько понимаю перформанс достигается там урезанием ядра, а не прямой работой с железом.
                        0
                        Идея следующая — связать приложение с необходимыми библиотеками операционной системы и скомпилировать их в один бинарный файл. После этот «бинарник» можно использовать для загрузки системы.
                        Получается, что ваше приложение превращается в часть ядра операционной системы.
                  0
                  Никто не предлагает отдавать любому приложению такой доступ, просто появляется возможность делать специализированные сборки ядра под некое приложение, как например сервер memcached или redis.
                  +7
                  Либо я не понял идею, либо это какая-то наркомания.
                  В целом об инициативе авторов оригинальной статьи положительно отозвалось и ИТ-сообщество. Резиденты Hacker News отметили, что архитектура unikernels значительно повысит безопасность программной среды. В случае взлома приложения хакер получит доступ лишь к его бинарнику.

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

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

                  Как это дело дебажить? Туда ж ни по ssh не зайти, ни логи почитать, ни прочие плюшки вроде syslog'а, нулевого даунтайма при обновлении не получить (без балансировки уровня выше), крона и прочего. В проде это гораздо ценее чем даже 100% к производительности и удаления некоторых уязвимостей (особый вопрос насколько это действительно улучшает безопасность).

                  Комментарий про раст и вовсе выглядит то ли издевкой, то ли сарказмом.

                  Для меня это все выглядит мертворожденным и я бы лучше рассмотрел другие способы достижения тех же целей (безопасность, эффективность).
                    +1
                    Вот меня упоминание в сабже раста тоже несколько смутило. Я люблю раст, но извините, это же практически сказать «переписать линукс на раст».
                      0
                      Как это дело дебажить? Туда ж ни по ssh не зайти, ни логи почитать, ни прочие плюшки вроде syslog'а, нулевого даунтайма при обновлении не получить (без балансировки уровня выше), крона и прочего.

                      Изучаю k8s сейчас, те же мысли. Так что… Может и взлететь, будет модной молодёжной технологией.
                        +2

                        Мне вот тоже интересно — какие же проблемы безопасности мы решаем? Уязвимости в ядре по-прежнему останутся уязвимостями, только теперь к ним добавятся уязвимости приложения (которых гораздо больше, чем уязвимостей в ядре), при этом каждая такая уязвимость, которая раньше осталась бы в user-space, теперь дает полный доступ к машине на уровне даже большем, чем root в user-space.

                          +1

                          Этот полный доступ много не даст когда там всего лишь одно приложение. Я предполагаю что про увеличение безопасности говорилось по сравнению с контейнерами.

                          +1
                          Вы кажется не улавливаете суть. Фактически, концепция unikernel меняет представление об организации вычислительного процесса. Это новая абстракция, которая уровнем выше чем процесс, и фактически объединяет совокупность процессов + «ядро», которые на самом деле реализуют один высокоуровневый сервис. Та же база данных как пример. Зачастую заводят целый физический сервер исключительно под БД. Но кроме самой БД туда входит ядро ОС, драйвера сетевого и дискового стека, сервисы, какие-то обслуживающие приложухи и утилиты, мониторинг тот же и т. д. плюс целый веер библиотек. Де факто, все они реализуют один мегасервис — БД. Вот идея unikernel это выделись весь этот зоопарк ПО который реализует БД и запаковать его в одно мегаприложение, попутно сняв по сути не особо нужную в таком случае изоляцию и тесно слинков и соптимизировав получившееся чудо. И вот это чудо — это что-то среднее между виртуальной машиной, контейнером и приложением.

                          С точки зрения надежности. Посмотрите на unikernel с перспективы вот этого вот конечного мегасервиса. Вам как клиенту без разницы почему оно крэшнулось. Из-за kernel panic или из-за ошибки в glibc или из-за бага в самой БД. Во всех случаях конечный результат один — сервис недоступен. Поэтому и нет особо большого смысла в изоляции между компонентами мегаприложения.

                          С точки зрения безопасности будет та же картина. Если ваше мегаприложение скомпрометировали со стороны «пользователя» — сервис попал к хакеру. Со стороны ядра — тоже самое. Да, есть всяческие нюансы, но в целом ситуация такая. Но! Как бы и с какой стороны не было скомпрометировано ваше мегаприложение, оно изолировано от других мегаприложений. То есть получив БД хакеру будет ну очень сложно пролезть в параллельно работающий на той же физической машине web-сервер. Даже если он смог залезть в «ядро» в БД.

                          Зато с точки зрения эффективности:
                          1) Низкий уровень абстракций ресурсов даваемых хостом unikernel-у позволяет всячески извращаться со стороны приложения (кастомные файловые системы и сетевые протоколы вам в руки).
                          2) Отсутствие изоляции может очень сильно снизить накладные расходы (в разы).
                          3) Тесная линковка и кросмодульная оптимизация может дать дополнительный прирост производительности.

                          Так что идея хоть и совершенно не новая (http://cnp.neclab.eu/projects/lightvm/lightvm.pdf) и корнями тянется вот аж сюда в 1995 год (https://pdos.csail.mit.edu/6.828/2008/readings/engler95exokernel.pdf), но вполне себе имеющая смысл. Особенно для всяких серверов и сложных апликух.

                          Однако! Говорить об unikernels как о замене того же монолита (Linux) имеет мало смысла. Потому что ОС смотрит как весь компьютер и думает как организовать вычисления на нем годным образом (мультиплексирование ресурсов, защита между приложениями и т.д.), а unikernel смотрит на отдельное, пусть и большое и сложное, приложение/сервис, и думает как бы это так получше его организовать.
                            0

                            То есть unikernels это, прежде всего, замена "одно универсальное ядро ОС на один специфический процесс" на "одно специфическое ядро ОС на один специфический процесс"? Замена универсальных ОС на голом железе или полной виртуализации путём выпиливания всего ненужного для конкретного приложения и, перевода ядра с приложением на один уровень защиты?

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

                                Но защита программиста самого от себя ведь все еще актуальна.
                                Теперь ошибка в сервисе который сидит рядом с главным и перепаковывает логи, чтобы послать в хранилище логов может уронить всю систему, или вызвать повреждение любых данных. Любая ошибка в программе может вызвать "kernel panic" или просто все наглухо повесить, если например "расстрелять" память потока ядра обслуживающего IRQ.

                                  0
                                  Ну это смотря на чем и как писать. Хотя, почему бы и нет? Какой смысл держать живым ядро, если приложение уже недоступно?
                                    0
                                    Ну это смотря на чем и как писать.

                                    Ну большинство VM "безопасных" языков программирования написаны на C/C++.


                                    Хотя, почему бы и нет?

                                    Эээ… Допустим вы крутите БД, она написана с учетом инварианта что ОС позволяет при падении БД быть уверенным, что либо данные совсем не записались, либо записались целиком. А теперь при возможности уронить вместе с БД ядро, у вас может произойти все что угодно при перезапуске БД,
                                    например потеря вообще всех данных из-за того что расстреляли память vfs и всего что ниже и она при перезапуске так синхронизировала кэш ФС,
                                    что даже fsck не может найти "концов".

                                    0
                                    Вы совершенно неверно поняли мысль, что «уровень защиты почти теряет смысл»
                            +2
                            А ещё в эмбедовке можно развернуться, где полноценная ОС — жирновато, а «всё сам» — грустновато
                              +1
                              Действительно, по описанию больше похоже на какую-то embedded RTOS статически скомпонованую с приложением. Только вот все вспомогательные демоны, для логов или для отладки нужно получается также встраивать непосредственно в приложение, ну или расширять возможности ОС.
                                0
                                Опоздали с идеей. Уже сделано :-) www.tockos.org/assets/papers/tock-sosp2017.pdf
                                +4
                                Думаю, что люди, которые сталкивались с 10Гбит Ethernet, 40Гбит Ethernet и пр. смотрят на эти вещи совсем по-другому. Когда приходится использовать механизмы zero-copy (PACKET_MMAP), то мечтаешь именно о чём-то типа этой Unikernel.
                                Linux ведь много где используется, в т.ч. для скоростного ввода-вывода со специального оборудования, никакого выхода в Сеть там нет, и на уязвимости, по большому счёту, наплевать, а самое главное — throughput и latency любой ценой.
                                  +1

                                  Предлагаю авторам не мелочиться и сразу идти в сторону baremetal. Механизмы безопасности вырезали, зачем оставлять HAL, вдруг оно тоже меделнно работает? А все баги просто лечить быстрым рестартом каждые 10 сек.

                                    +2
                                    Попахивает экзоядром, разве нет?
                                      +1
                                      Именно! Все unikernel-ы по сути тянуться из так называемых LibraryOS, которые в свою очередь происходят из идей экзоядра.
                                      0

                                      Что-то похожее уже мутят везде. Kata containers засунули докер в виртуалку, но тоже обрезанную со всех сторон. Есть и другие попытки скрестить контейнеры с виртуалками, пытаясь соединить хорошую изоляцию с хорошим перформансом. Думаю мы будем свидетелями еще многих опытов на эту тему.

                                        0

                                        В статье был упомянут MirageOS, но почему-то не упоминается проект IncludeOS который является более известным и мейнстримовым — с++ а не ocaml (советую посмотреть на ютюбе несколько докладов про includeos где также освещается общая тема unikernels, например в вопросе безопасности — https://youtu.be/t4etEwG2_LY?t=1810)

                                          +2
                                          Читаем внимательно:
                                          В частности, высокопроизводительные приложения вынуждены использовать фреймворки вроде DPDK и SPDK, чтобы получить беспрепятственный доступ к устройствам ввода/вывода в обход ядра.
                                          и
                                          Идея следующая — связать приложение с необходимыми библиотеками операционной системы и скомпилировать их в один бинарный файл. После этот «бинарник» можно использовать для загрузки системы. Такой подход дает возможность специализировать функциональность ОС под нужды конкретного приложения.
                                          Ну и каким же образом «компиляция всей системы в один файл» позволит «получить беспрепятственный доступ к устройствам ввода/вывода в обход ядра хост-системы»? А если такого доступа нет — то в чём вообще смысл?

                                          После этот «бинарник» можно использовать для загрузки системы.
                                          Образ вирт.машины — это бинарник. Ну и какая разница — лежит ли это дело в одном файле или в разных?
                                          В Windows — драйверы лежат в отдельных файлах. Это не мешает системе быть монолитной.

                                          Также unikernels обладают более высокой производительностью, по сравнению с монолитной архитектурой ядра. Причина — упрощение IO-путей, так как все данные и файлы размещаются в едином адресном пространстве.
                                          Судя по описанию — unikernels правильнее всего было бы назвать «супермонолитной системой», ибо там не только ядро монолитно, но и в ядро впихнуто одно приложение… или несколько…

                                          Вообще-то, смысл разделения ядра и приложений — в защите ядра от приложений и в защите приложений друг-от-друга. Если Вы предлагаете это отменить — то проще всего вернуться к DOS. Ну да, нужен новый DOS — 64-битный, с драйверами. Но это будет именно DOS, в т.ч. и с отсутствием защиты файлов от несанкционированного доступа.

                                          Авторы создали небольшую UKL-библиотеку, в которой разместили специальные «заглушки», которые маскируют неиспользуемые системные вызовы.
                                          Я ещё в 199*-е годы перекомпилировал ядро FreeBSD, удаляя из него ненужные мне компоненты. И никакой UKL-библиотеки мне не требовалось!

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

                                          Один из резидентов Hacker News даже предложил радикальное решение — переписать ядро Linux под unikernels с нуля на Rust. По его словам, язык решит проблему с большим количеством багов, связанных с безопасностью памяти.
                                          Идею переписать систему на безопасный язык — я добряю и приветствую. Однато, тут можно ожидать проблему с производительностью.

                                          легковесное ядро HermiTux позволяет быстро запускать приложения поверх гипервизора — по словам авторов, время загрузки не превышает 0,1 сек.
                                          Кажется, до кого-то начинает доходить, что внутри вирт.машины не нужно ядро, разработаное не для работы на голом железе, а для работы именно внутри вирт.машины. Т.е. большинство сист.вызовов приложения надо напрямую перенаправлять в хозяйскую систему, а не пытаться самостоятельно манипулировать аппаратурой.
                                            +1
                                            Если Вы предлагаете это отменить — то проще всего вернуться к DOS. Ну да, нужен новый DOS — 64-битный, с драйверами. Но это будет именно DOS, в т.ч. и с отсутствием защиты файлов от несанкционированного доступа.

                                            В какой-то мере, кажется, именно это и предлагается. Защита, может и будет, но на уровне прав доступа ФС, защита от ошибок программиста, от случайных попыток записать файл, который сам же объявил как RO. На голом железе — просто один процесс в нулевом кольце с прямым доступом к железу. На виртуалке для гипервизора — полноценная ОС, а внутри тот же один процесс в нулевом кольце с тем же прямым доступом к железу, но к виртуальному, с защитой на уровне гипервизора.

                                              0
                                              Вообще-то, смысл разделения ядра и приложений — в защите ядра от приложений и в защите приложений друг-от-друга. Если Вы предлагаете это отменить — то проще всего вернуться к DOS. Ну да, нужен новый DOS — 64-битный, с драйверами. Но это будет именно DOS, в т.ч. и с отсутствием защиты файлов от несанкционированного доступа.

                                              Haiku?
                                                0
                                                VolCh:
                                                Защита, может и будет, но на уровне прав доступа ФС, защита от ошибок программиста, от случайных попыток записать файл, который сам же объявил как RO.
                                                Тут есть более интересная проблема: Все современные файловые системы имеют буферизацию данных (кэш для чтения и для записи). А если программа работает в режиме ядра — она может случайно записать что-то в эти буферы; просто выставить неверное значение указателя и записать по этому адресу произвольное значение. Или можно записать произвольное значение в программный код драйвера файловой системы.

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

                                                Finnix:
                                                Haiku?
                                                Если Haiku не имеет защиты файлов — то она очень скоро станет благодатной средой для распространения вирусов. Т.е. «взлететь» эта система может — но как только она станет более-менее популярной, она рухнет с жуткими скандалами.
                                                А защита ядра от приложений и защита приложений друг-от-друга — я так понял, там присутствует в полноценном режиме вытесняющей многозадачности.
                                                  0
                                                  Если программа может случайно записать байтик «не туда», значит в программе ошибка. Чем запись мусора в код драйвера принципиально отличается от записи некорректных данных в файл или массив? Более того, пусть лучше система грохнется, чем программа будет незаметно подсовывать лажу.
                                                  Плюс, мне кажется, сейчас большинство контейнеризованных сервисов не используют файлы вообще.
                                                    0
                                                    Программы содержат ошибки. Поэтому хотелось бы иметь хоть какую-то защиту — пусть не от всего, но максимально возможную. Поэтому изоляция вычислительной подзадачи в виде отдельного процесса — намного лучше, чем запуск этой вычислительной подзадачи в режиме ядра.

                                                    Допустим, программа занимает адреса от 0 до 999, а ядро и драйверы — адреса от 1000 до 1999 (ну, числа условные). Допустим, в результате сбоя программа пишет по адресу 1477. Если программа изолирована в виде процесса — она реально грохнется. Если же программа работает в режиме ядра — она повредит код или данные ядра. Что лучше?
                                                    Понятно, что от обращения по адресу 666 такая защита не спасёт. Но хоть что-то…

                                                    Если «большинство контейнеризованных сервисов не используют файлы вообще», то что они используют?
                                                    Если базу данных — то как они к ней обращаются? И как Unikernels ускорит работу этих обращений?
                                                      +1
                                                      Если программа изолирована в виде процесса — она реально грохнется. Если же программа работает в режиме ядра — она повредит код или данные ядра. Что лучше?
                                                      Без разницы. В отсутствие процессов данные ядра имеют нулевую ценность.
                                                      что они используют?
                                                      S3 и подобное. Очереди, Logstash.
                                                      И как Unikernels ускорит работу этих обращений?
                                                      Сокеты, наверное, тоже ускорятся.
                                                      Помните суперкомпьютер на Малинках? В него бы Library OS легла идеально.
                                                        0
                                                        В отсутствие процессов — мы лишаемся вытесняющей многозадачности с защитой процессов. Т.е. на такую машину уже невозможно зайти по SSh и запустить программу анализа, которая подскажет нам, что там происходит. Это как в DOS.

                                                        Я не понял, как очереди могут заменить собой файлы. Это сильно разные сущности.
                                                        В принципе, вместо файлов можно использовать транзакционную СУБД. Во многих случаях это правильно. Но в других случаях — гибкости СУБД будет остро не хватать.

                                                        Я не понял, про какие сокеты Вы говорите. Как правило, через сокеты программа общается с программами, работающими на том же компьютере; при использовании вирт.машин — на той же вирт.машине. Но выше Вы предлагаете отказаться от многозадачности.

                                                        Смысл Library OS на «суперкомпьютере на Малинках» я не понял. В каком режиме это должно работать?

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

                                            Самое читаемое