Общая теория и археология виртуализации x86

    Введение


    Авторский коллектив


    Автор: Антон Жбанков (AntonVirtual, cloudarchitect.cc)
    Со-авторы: Григорий Прялухин, Евгений Парфенов

    Общие понятия виртуализации


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

    Наверное, самым близким определением понятия “виртуализация” будет “абстрагирование” из объектно-ориентированного программирования. Или, если переводить на нормальный русский язык — это сокрытие реализации за абстрактным интерфейсом. Что, конечно, все сразу объяснило. Попробуем еще раз, но для тех, кто не изучал программирование.
    Виртуализация — сокрытие конкретной реализации за универсальным стандартизованным методом обращения к ресурсам / данным.

    Если попробовать применить на практике данное определение, то окажется, что оно вполне работает на совершенно неожиданных предметах. Скажем, часы. Вот были придуманы несколько тысяч лет назад солнечные часы, а в средневековье были придуманы механические. Что же там общего? Солнце и какие-то шестеренки? Бред какой-то. А потом кварцевые генераторы и все остальное.
    Суть в том, что мы имеем стандартный интерфейс — стрелочный или цифровой указатель, который в универсальной стандартной форме указывает текущее время. Но имеет ли для нас значение как конкретно реализован этот механизм внутри коробки, если время указывается с достаточной для нас точностью?
    — Позвольте, — можете сказать вы, — но я-то думал, что виртуализация про машины, процессоры там, и так далее!
    Да, она и про машины, и про процессоры, но это лишь частный случай. Давайте рассмотрим более широко, раз уж статья смело претендует на общую теорию.

    POZOR!


    Uwaga! Achtung! Pozor!


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

    Виды виртуализации


    Вернемся от совсем абстрактных понятий к более привычным нам любимым компьютерам.

    Виртуализация системы хранения данных


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

    FS -> LBA -> CHS


    Возьмем простейший случай с системой хранения на единичном жестком магнитном диске. Привычный нам формат работы с данными — это файлы, которые лежат на логическом диске. Файл можно открыть, прочитать, закрыть. Но такого объекта, как файл, физически попросту не существует — существует лишь способ обратиться к определенным блокам данных, используя способ адресации вида “диск:\папка1\папка2\файл”. Т.е. мы встречаемся с первым слоем виртуализации — из мнемонического и понятного человеку переводим все в системно-понятные адреса. В таблицах метаданных драйвер файловой системы ищет, что же там за блоки с данными, и мы получаем адрес в системе LBA (logical block addressing). В системе LBA блоки имеют фиксированный размер и идут друг за другом линейно, т.е. еще как-то это может иметь отношение к хранению данных на магнитной ленте, но жесткий диск-то устроен совершенно иначе! И здесь мы переходим на второй слой виртуализации — трансляции адресации LBA в CHS (cylinder / head / sector).

    image

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

    RAID


    Следующий слой виртуализации, который за виртуализацию правда многие ошибочно не считают — это RAID (redundant array of inexpensive/independent disks).

    Ключевая особенность RAID в контексте обсуждаемых понятий — не его способность защитить данные от выхода того или иного физического диска из строя. RAID обеспечивает второй уровень LBA-адресации поверх нескольких (иногда очень многих) независимых LBA-адресаций. Поскольку обращаться к RAID тому мы можем, независимо от уровня RAID, ровно так же, как и к одиночному диску без RAID, то можно с уверенность сказать:
    RAID — это виртуализация дисковой системы.

    Более того, RAID контроллер не просто создаёт один большой виртуальный диск из нескольких физических, а может создать произвольное их количество, добавив еще один слой виртуализации.

    Виртуализация представления


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

    Терминальные серверы, VDI и даже просто RDP через VPN к серверу — это все виртуализация сессий. Через стандартный интерфейс (монитор, клавиатура, мышь) мы работаем то ли с настоящей машиной, то ли с непонятным конструктом из виртуального десктопа на линкованном клоне с контейнеризованным приложением, из которого мы переносим данные через буфер в приложение с потоковой доставкой. Или нет, кто разберется, кроме того, кто проектировал?

    Введение в виртуализацию x86


    История и обзор работы процессоров


    Исполнение программ


    На первом занятии на спецкурсе по программированию Владимир Денисович Лелюх (земля ему пухом) говорил студентам: компьютер, несмотря на свое название, считать не умеет, он умеет делать вид, что умеет считать. Но если нечто выглядит как утка, ходит как утка и крякает как утка, с практической точки зрения это утка.

    Попробуем это запомнить для дальнейшего практического использования.

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

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

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

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

    Многозадачность


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

    Появляется псевдо-многозадачность — когда задача выполняется при непосредственном на нее переключении.

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

    И тут нам снова приходят на помощь прерывания + умение делать вид. Пользователю на самом деле неважно, чтобы они исполнялись строго одновременно, достаточно, чтобы так выглядело.
    Поэтому на прерывание таймера просто вешается обработчик, который начинает управлять тем, какой поток кода должен выполняться следующим. Если таймер срабатывает достаточно часто (скажем 15мс), то для пользователя все выглядит как параллельная работа. И так появляется современная вытесняющая многозадачность.

    Реальный режим


    Реальный режим процессора в рамках данной статьи можно охарактеризовать достаточно просто — вся память доступна всем. Любое приложение, в том числе малварь (malware, malicious software), может получить доступ куда угодно как на чтение, так и на запись.

    Это изначальный режим работы процессоров семейства Intel x86.

    Защищенный режим


    В 1982 году в процессоре Intel 80286 (далее просто 286) появилось нововведение — защищенный режим работы, принесший с собой нововведения в организации работы с памятью (например выделение типов сегментов памяти — код, данные, стек). Но самое главное, что принес 286 процессор в мир x86 — это концепцию колец защиты, которой мы пользуемся до сих пор.

    Концепция колец защиты изначально появилась в ОС Multics для мейнфрейма GE645 (1967 года) с частично программной реализацией, и полностью аппаратной уже в 1970 году в системе Honeywell 6180.

    image

    Основная идея колец защиты напоминает многоуровневые средневековые крепости, самое ценное лежит в самом центре за множественными стенами. В данном случае самое ценное — неограниченный прямой доступ к любой области оперативной памяти и контролю над всеми процессами. Ими обладают процессы, работающие в нулевом кольце защиты. За стеной, в первом кольце, работают менее важные процессы, как например драйверы устройств, а в самом последнем — пользовательские приложения. Принцип прост — изнутри можно выйти наружу, а вот снаружи внутрь запрещено. Т.е. никакой пользовательский процесс не может получить доступ к памяти ядра ОС, как это было возможно в реальном режиме ранее.

    В самой первой полной реализации Honeywell 6180 было реализовано 8 колец защиты, а вот в Intel решили упростить схему до 4, из которых на практике производители ОС стали использовать всего два — нулевое и третье.

    32bit


    В 1985 году вышел еще один чрезвычайно архитектурно важный процессор в линейке x86 — 80386 (далее 386), реализовавший 32-битную адресацию памяти и использовавший 32-битные команды. И разумеется, виртуализацию памяти. Как уже говорилось, виртуализация — это сокрытие фактической реализации через предоставление искусственных “виртуальных” ресурсов. В данном случае речь идет об адресации памяти. В рамках сегмента памяти своя собственная адресация, которая никак не связана с фактическим расположением ячеек памяти.
    Процессор оказался настолько востребованным, что выпускался до 2007 года.
    Архитектура в терминах Intel носит название IA32.

    64bit


    Разумеется, даже без виртуализации в середине 2000х индустрия уже вовсю упиралась в ограничения 32 бит. Существовали частичные обходные пути в виде PAE (Physical Address Extension), но усложняли и замедляли код. Переход на 64 бита был предрешен.

    AMD представила свою версию архитектуры, которую назвала AMD64. В Intel же возлагали надежды на платформу IA64 (Intel Architecture 64), которую мы также знаем под именем Itanium. Однако рынок встретил эту архитектуру без большого энтузиазма, и в итоге Intel были вынуждены реализовать собственную поддержку инструкций AMD64, которую сначал назвали EM64T, а потом просто Intel 64.

    В конечном итоге мы все знаем эту архитектуру как AMD64, x86-64, x86_64 или иногда встречается x64.

    Поскольку основное использование серверов на то время предполагалось в качестве физических, без виртуализации, то с первыми 64-битными процессорами в виртуализации случился технический курьез. В качестве лабораторных серверов часто использовались вложенные гипервизоры, далеко не все могли себе позволить несколько кластеров физических серверов. И в итоге оказывалось, что ВМ нагрузки во вложенном гипервизоре могла работать только в 32битном режиме.

    В первых x86-64 процессорах разработчики, сохраняя полную совместимость с 32-битным режимом работы, в режиме 64 бит выбросили значительную часть функциональности. В данном случае проблема была в сильном упрощении сегментации памяти. Была убрана возможность гарантировать неприкосновенность небольшого участка памяти в ВМ, в котором работал обработчик исключений гипервизора. Соответственно, гостевая ОС получала возможность его модифицировать.
    Впоследствии, AMD вернула возможность лимитирования сегментов, а Intel попросту дождалась введения аппаратной виртуализации.

    UMA


    Многопроцессорные системы x86 начали работу с режима UMA (Uniform Memory Access), в рамках которого расстояние от любого процессора (задержка на доступ к ячейке памяти) до любой планки памяти одинаково. В процессорах Intel данная схема работы сохранялась даже после появления многоядерных процессоров вплоть до поколения 54xx (Harpertown). Начиная с поколения 55xx (Nehalem) процессоры перешли на архитектуру NUMA.

    С точки зрения логики исполнения — это появление дополнительных аппаратных потоков, на которые можно назначить потоки кода для исполнения параллельно.

    NUMA


    NUMA (Non Uniform Memory Access) — архитектура с неравномерным доступом к памяти. В рамках данной архитектуры у каждого процессора существует своя локальная память, доступ к которой осуществляется напрямую с низкими задержками. Доступ к памяти других процессоров осуществляется опосредованно с более высокими задержками, что приводит к снижению производительности.

    У процессоров Intel Xeon Scalable v2 на 2019 внутренняя архитектура все еще остается UMA в пределах сокета, превращаясь в NUMA для других сокетов (хотя на самом деле нет, и только прикидывается). У AMD процессоры Opteron имели архитектуру NUMA даже во времена древнейших UMA Xeon, а далее стали NUMA даже внутри сокета вплоть до последнего поколения Rome, в котором вернулись к NUMA = сокет.

    Виртуальная машина


    Виртуальная машина (VM, от англ. virtual machine) — программная и/или аппаратная система, эмулирующая аппаратное обеспечение некоторой платформы (target — целевая, или гостевая платформа) и исполняющая программы для target-платформы на host-платформе (host — хост-платформа, платформа-хозяин), или виртуализирующая некоторую платформу и создающая на ней среды, изолирующие друг от друга программы и даже операционные системы. Wikipedia.
    Мы в данной статье будем говорить «виртуальная машина», подразумевая «системные виртуальные машины», позволяющие полностью имитировать все ресурсы и аппаратное обеспечение в виде программных конструктов.
    Существует два основных вида ПО создания виртуальных машин — с полной и соотв. неполной виртуализацией.

    Полная виртуализация — подход, при котором эмулируется вообще все аппаратное обеспечение, включая процессор. Позволяет создавать аппаратно независимые среды, и запускать например ОС и прикладное ПО для платформы x86 на системах SPARC, или всем известные эмуляторы Spectrum с процессором Z80 на привычных x86. Обратной стороной полной независимости являются высокие накладные расходы на виртуализацию процессора и низкая итоговая производительность.

    Неполная виртуализация — подход, при котором виртуализуются не 100% аппаратного обеспечения. Поскольку в индустрии наиболее распространена именно неполная виртуализация — мы будем говорить именно о ней. О платформах и технологиях системных виртуальных машин с неполной виртуализацией для архитектуры x86. В данном случае идет неполная виртуализация процессора, т.е. за исключением частичной подмены или сокрытия определенных системных вызовов, бинарный код виртуальной машины исполняется процессором напрямую.

    Программная виртуализация


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

    Но решилось все достаточно просто: поскольку для гипервизора гостевая ОС — просто набор страниц памяти с полным прямым доступом, а виртуальный процессор — просто очередь команд, то почему бы их не переписать? Прямо на лету гипервизор выбрасывает из очереди команд на исполнение на виртуальном процессоре все инструкции, требующие привилегий нулевого кольца, заменяя их на менее привилегированные. А вот результат работы этих инструкций подается ровно так же, как если бы гостевая ОС была в нулевом кольце. Таким образом виртуализовать можно вообще все что угодно, вплоть до полного отсутствия гостевой ОС.
    Именно такой подход был реализован командой разработчиков в 1999 году в продукте VMware Workstation, а далее в 2001 в серверных гипервизорах GSX (второго типа, как и Workstation) и ESX (первого типа).

    Паравиртуализация


    Паравиртуализация — это очень простая концепция, которая предполагает, что гостевая ОС знает, что она в виртуальной машине, и знает как можно обратиться к хостовой ОС за определенными системными функциями. Таким образом снимается проблема эмуляции нулевого кольца — гостевая ОС знает, что она не в нулевом и ведет себя соответственно.
    Паравиртуализация в x86 появилась в 2003 году вместе с проектом Linux Xen.

    Определенные паравиртуализованные функции реализованы и в гипервизорах с полной виртуализацией через специальные виртуальные драйверы в гостевых ОС, общающиеся с гипервизором для снижения накладных расходов на виртуализацию. Например, у VMware ESXi для ВМ есть паравиртуальный SCSI адаптер PVSCSI, позволяющий повысить общую производительность для ВМ с интенсивными дисковыми операциями, как например нагруженные СУБД. Драйверы для паравиртуальных устройств идут в дополнительных пакетах (например VMware Tools), либо уже включены в дистрибутивы Linux (open-vm-tools).

    Аппаратная виртуализация


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

    Проблема решилась очень простым способом — фирменные технологии аппаратной виртуализации Intel VT-x и AMD-V добавили, если отбросить глубокие технические детали, минус первое кольцо защиты для гипервизора. Таким образом наконец устанавливалась привычная для ОС ситуация работы в нулевом кольце.

    Типы гипервизоров


    Тип 2 (hosted)


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

    Примеры гипервизоров второго типа: VMware Workstation / Fusion, Oracle VM VirtualBox, Parallels Desktop, VMware Server (ex-GSX), Microsoft Virtual Server 2005

    Тип 1 (bare-metal)



    Гипервизоры первого типа не требуют ОС общего назначения, в отличие от предыдущих. Сам гипервизор представляют собой монолит, который управляет как распределением вычислительных ресурсов, так и операциями ввода-вывода. В нулевом кольце безопасности располагается микро-ядро, поверх которого работают все управляющие конструкции. В данной архитектуре гипервизор управляет распределением вычислительных ресурсов и сам контролирует все обращения виртуальных машин к устройствам. Первым гипервизором первого типа для x86 долгое время считался VMware ESX, хотя сейчас мы его отнесли бы к 1+. Единственным “честным” представителем этого типа на сегодня является VMware ESXi — наследник ESX, после того как тому откусили родительский раздел с RHEL.

    Для примера можно рассмотреть архитектуру ESXi. Команды управления гипервизором выполняются через API агента, который работает поверх VMkernel. Может показаться, что это прямое подключение к гипервизору, однако это не так. Прямой доступ к гипервизору отсутствует, что выгодно отличает этот тип гипервизора от гипервизоров второго типа в аспекте безопасности.

    image

    Недостатком здесь являются драйверы устройств: для обеспечения “тонкости” платформы и устранения излишних усложнений от версии к версии происходит ротация драйверов устройств, что делает физическую инфраструктуру зависимой от HCL (hardware compatibility list).

    Тип 1+ (Гибридный гипервизор)


    Гипервизоры гибридного типа (они же тип 1+, 1a, 1.5) характеризуются изоляцией базовой ОС в особую сущность, которая называется родительский раздел (parent partition в терминологии Microsoft Hyper-V) или родительский домен (domain dom0 в терминологии Xen). Так, после установки роли гипервизора, ядро переходит в режим поддержки виртуализации и за распределение ресурсов на хосте отвечает гипервизор. Но родительский раздел берет на себя функцию обработки обращений к драйверам устройств и операциям ввода-вывода.

    По сути, родительский раздел становится неким провайдером между всеми сущностями стека виртуализации. Данный подход удобен с точки зрения совместимости с оборудованием: не требуется вшивать в гипервизор драйверы устройств, как в случае с ESXi, а значит, список устройств сильно расширяется и слабее зависит от HCL. К достоинствам же можно отнести и разгрузку гипервизора от задачи обработки вызовов к драйверам устройств, тк все вызовы обрабатывает родительский раздел.

    Верхнеуровневая архитектура гипервизоров типа 1+ выглядит так:

    image

    К гипервизорам данного типа относятся: почивший VMware ESX, Microsoft Hyper-V, Xen-based гипервизоры (Citrix XenServer и реализации Xen в различных дистрибутивах Linux). Напомним, что Citrix XenServer – это немного урезанная RHEL-based OS, и ее версионность и функционал находились в прямой зависимости от текущей версии Red-Hat Enterprise Linux. В случае с другими реализациями Xen ситуация не сильно отличается: это то же ядро Linux в режиме гипервизора Xen и базовая ОС в домене dom0. Отсюда следует однозначный вывод, что Xen-based гипервизоры относятся к гибридному типу и не являются честными гипервизорами 1 типа.

    Основные технологии промышленных платформ


    За основу будет принята терминология VMware, как наиболее технологически развитой платформы виртуализации. В рамках данной статьи ограничимся только технологиями самих гипервизоров и базовой системы управления. Весь расширенный функционал, реализуемый дополнительными продуктами за дополнительные деньги, оставим за кадром. Технологии объединены в условные группы по основному назначению, как показалось автору, с которым вы имеете право не согласиться.

    SLA


    Здесь собраны технологии, главным образом влияющие на исполнение SLA по доступности (RPO / RTO).

    HA


    High Availability — технология обеспечения высокой доступности ВМ в кластере силами гипервизора. В случае смерти хоста происходит автоматический перезапуск ВМ на оставшихся в живых хостах. Эффект: минимизация RTO до времени таймаута HA + рестарта ОС / сервисов.

    FT


    Fault Tolerance — технология обеспечения непрерывной работы ВМ даже в случае смерти хоста. Создается теневая ВМ на втором хосте, полностью идентичная основной и повторяющая за ней инструкции. Таким образом разница в состояниях ВМ измеряется в десятках или сотнях миллисекунд, что для многих сервисов вполне приемлемо. При смерти хоста идет автоматическое переключение исполнения на теневую ВМ. Эффект: минимизация RTO до нуля.

    TCO


    Здесь собраны технологии, главным образом влияющие влияющие на TCO.

    vMotion


    vMotion — технология живой миграции точки исполнения ВМ с одного полностью исправного хоста на другой. При этом время переключения точки исполнения составляет менее таймаутов сетевых соединений, что позволяет считать миграцию живой, т.е. без прерывания в работе продуктивных сервисов. Эффект: снижение RTO до нуля для запланированных простоев для обслуживания серверов и, как следствие, частичная элиминация самих простоев.

    Storage vMotion


    Storage vMotion — технология живой миграции точки хранения ВМ с одного полностью исправного хранилища на другое. При этом работа с дисковой системой не прекращается, что позволяет считать миграцию живой. Эффект: снижение RTO до нуля для запланированных простоев для обслуживания СХД и, как следствие, частичная элиминация самих простоев.

    DPM


    Distributed Power Management — технология контроля уровня загрузки хостов и включения / выключения питания хостов по мере изменения нагрузки на кластер. Требует для своей работы DRS. Эффект: общее снижение энергопотребления.

    Distributed vSwitch


    Distributed vSwitch — технология централизованного управления сетевыми настройками виртуальных коммутаторов хостов. Эффект: снижение объема и сложности работ по переконфигурированию сетевой подсистемы, снижение рисков ошибки.

    EVC


    Enhanced vMotion Compatibility — технология, позволяющая маскировать для ВМ доступные инструкции процессора в автоматическом режиме. Применяется для выравнивания работы ВМ в неравномерном кластере по самому старому семейству процессоров, обеспечивая возможность миграции ВМ на любой хост. Эффект: экономия на сложности инфраструктуры при постепенном наращивании мощности / частично апгрейде кластеров.

    QoS


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

    vNUMA


    vNUMA — технология позволяющая сообщить гостевой ОС в ВМ виртуальную топологию NUMA для широких машин (vCPU или vRAM > узел NUMA). Эффект: отсутствие штрафа к производительности прикладного ПО, поддерживающего NUMA.

    Resource Pool


    Ресурсные пулы — технология объединения нескольких ВМ в единый пул ресурсов для контроля потребления или гарантии выделения ресурсов. Эффект: упрощение администрирования, обеспечение уровня обслуживания.

    Limit / Reserve


    Лимитирование и резервирование процессора / памяти позволяет ограничить выделение ресурсов, или наоборот гарантировать их выделение в ситуации дефицита и конкуренции для обеспечения обслуживания высокоприоритетных ВМ / пулов.

    DRS


    Dynamic Resource Scheduler — автоматическая балансировка ВМ по хостам в зависимости от нагрузки для снижения фрагментации ресурсов в кластере и обеспечения уровня обслуживания для ВМ. Требует поддержки vMotion.

    Storage IO Control


    Storage IO control — технология, позволяющая ограничить “шумного соседа”, низкоприоритетную машину с высокой дисковой нагрузкой, чтобы сохранить доступной производительность дорогостоящей системы хранения для продуктивной нагрузки. Как пример — система индексации / внутренний поисковик и продуктивная СУБД.

    Network IO Control


    Network IO Control — технология, позволяющая ограничить “шумного соседа”, низкоприоритетную машину с высокой сетевой нагрузкой.

    Storage Integration (VAAI etc)


    В раздел интеграции попадают две категории технологий:
    • Интеграция системы управления виртуализацией с системой управления СХД позволяет значительно упростить выделение и презентацию томов / шар СХД гипервизорам, снижая риски ошибок и сложность работ.
    • Интеграция на уровне протоколов — VAAI, ODX. Данные технологии позволяют разгрузить дисковую подсистему, передав часть стандартной нагрузки на откуп интеллектуальной СХД. Например, в эту категорию входят такие операции, как зануление блоков, клонирование ВМ и тд. За счет этого значительно разгружается канал до СХД, а операции с дисками сама СХД проводит более оптимальным образом.


    Security


    Microsegmentation


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

    Agentless AV


    Технология поддержки безагентных антивирусов. Вместо проверки агентами в гостевых ОС трафик дисковых операций ВМ направляется гипервизором на проверку в выделенную сервисную ВМ. Значительно снижает нагрузку на процессоры и дисковую систему, фактически убивая “антивирусные штормы”.

    Гиперконвергентные системы


    Конвергентные системы, как подсказывает название — системы с совмещением функций. И в данном случае имеется в виду совмещение функции хранения и исполнения ВМ. Вроде просто, но внезапно врывается маркетинг.

    Впервые с термином конвергентные системы на рынок врываются маркетологи. Под конвергентной системой продавались обычные классические серверы + СХД + коммутаторы. Просто под одним партномером. Или даже не продавались, а выпускалась бумага под названием “референсная архитектура”. Мы искренне порицаем этот подход и переходим к архитектурному рассмотрению.

    Архитектура


    Сохраняя конвергенцию как архитектурный принцип, получаем совмещение точки хранения и точки исполнения ВМ в единой системе.

    Конвергентная архитектура, иными словами, подразумевает использование одних и тех же аппаратных сервисов как для исполнения ВМ, так и для их хранения на локальных дисках. Ну а поскольку должна быть отказоустойчивость — в конвергентной архитектуре есть слой распределенной SDS.

    Получаем:

    • Классическая система — софт, СХД, коммутация и серверы идут из разных мест, совмещаются руками заказчика/интегратора. Отдельные контракты на поддержку.
    • Конвергентная система — все из одних рук, единая поддержка, единый партномер. Не путать с самосбором от одного вендора.

    И, получается, что термин под нашу конвергентную архитектуру уже занят. Ровно та же ситуация, что с супервизором.

    Гиперконвергентная система — конвергентная система с конвергентной архитектурой.
    Конечно же не обошлось и без второго пришествия маркетологов. Появились конвергентные системы в которых совмещения хранения не было, а есть выделенные узлы хранения под управлением распределенной SDS. Появился в рамках маркетинговых войн даже специальный термин disaggregated HCI (дизагрегированная гипервергентная инфраструктура). В частности, например, NetApp с подобной системной сначала довольно интенсивно воевали за право называть свою систему гиперконвергентной, но в итоге сдались. NetApp HCI на сегодня (конец 2019) — hybrid cloud infrastructure.

    Варианты реализации


    В силу того, что гиперконвергентные системы работают с виртуализацией, вариантов реализации собственно два с половиной.

    • 1. Модуль ядра. SDS работает как монолит в составе ядра гипервизора, например vSAN + ESXi
    • 1.5 Модуль родительского раздела. SDS работает как сервис в составе родительского раздела гипервизора, например S2D + Hyper-V
    • 2. Виртуальная машина. SDS реализована в виде выделенной виртуальной машины на каждом хосте. Nutanix, Cisco Hyperflex, HPE Simplivity.

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

    Контейнеры


    Контейнерная виртуализация, хотя технически различается очень сильно с полной виртуализацией, выглядит достаточно просто в структуре. Также, как и в сетевой модели OSI, вопрос в уровне. Контейнерная виртуализация находится уровнем выше — на уровне окружения приложения, а не на физике.

    Основная задача контейнерной виртуализации — поделить ОС на независимые кусочки, из которых изолированные приложения не смогли бы друг другу мешать. Полная виртуализация делит не ОС, а физический сервер.

    ВМ vs Контейнер


    Плюсы и минусы обоих подходов достаточно просты и прямо противоположны.

    Полная виртуализация (ВМ) дает полную независимость до уровня железа, включая полностью независимые ОС, дисковый и сетевой стеки. А с другой стороны каждое приложение, ведь мы же придерживаемся схемы 1 приложение = 1 сервер, требует своей ОС, своего дискового и сетевого стека. т.е. идет многократный расход ресурсов.

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

    В историческом разрезе в рамках x86 сначала были контейнеры для всего, вместе с физическими серверами. После появления полной виртуализации значимость контейнеров сильно упала почти на 15 лет, и в корпоративном мире воцарились толстые ВМ. Контейнеры в это время нашли себя у хостеров, предоставлявших сотни однотипных веб-серверов, где и была востребована их легковесность. Но в последние годы, примерно с 2015, контейнеры вернулись в корпоративную реальность в виде cloud-native приложений.

    Контейнеры 0.1


    chroot


    Прообразом контейнеров в 1979 явился chroot.

    “chroot — операция изменения корневого каталога в Unix-подобных операционных системах. Программа, запущенная с измененным корневым каталогом, будет иметь доступ только к файлам, содержащимся в данном каталоге.”

    Т.е. фактически изоляция только на уровне файловой системы, в остальном это просто обычный процесс в ОС.

    FreeBSD jail


    Значительно более продвинутой оказалась тюрьма от свободной BSD, появившаяся в 1999 году. Jail позволяла создавать полноценные виртуальные экземпляры ОС с собственными наборами приложений и конфигурационных файлов на основе базовой FreeBSD. Наверняка найдутся те, кто скажет — а что же jail делает в контейнерах, ведь это же паравиртуализация! И будут частично правы.

    Однако, до полноценной виртуализации (и ее варианта в виде паравиртуализации) jail не хватает возможности запускать ядро другой версии в гостевой ВМ и кластеризации с миграцией ВМ на другую хост систему.

    Solaris Zones


    Solaris Zones — технология виртуализации операционной системы (контейнерная виртуализация), появившаяся в 2004 в Sun Solaris. Основной принцип — низкие накладные расходы на виртуализацию.

    Не снискав особой популярности, перекочевала в OpenSolaris и дистрибутивы на ее основе, доступные и в 2019.

    Контейнеры 1.0


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

    Virtuozzo / OpenVZ


    Российская SWsoft в 2001 году представила свою первую версию контейнерной виртуализации Virtuozzo, нацеленной на рынок хостинг провайдеров. Благодаря целеустремленности и конкретной коммерческой целевой аудитории, продукт получился довольно удачным и получил популярность. Технологически в 2002 году была продемонстрирована одновременная работа 2500 контейнеров на 8 процессорном сервере.

    В 2005 году появилась открытая версия контейнеров Virtuozzo для Linux под названием OpenVZ. И практически стала золотым стандартом для организации VPS у хостероов.

    LXC


    LinuX Containers (LXC) — еще одна известная контейнерная виртуализация на основе namespaces и cgroups, появившаяся в 2008. Лежит в основе популярных ныне докеров и т.д.

    Контейнеры 1.1 (виртуализация приложений)


    Если остальные контейнеры призваны поделить базовую ОС на сегменты, то почему бы не оторвать этот слой системного и не упаковать его в единый ящик с приложением и со всем его окружением. А дальше этот готовый пакет можно запускать как обычное приложение пользовательского уровня.

    App-V


    Microsoft Application Virtualization (App-V), ранее Softricity SoftGrid — технология контейнеризации конкретных приложений (контейнер наоборот) в изолированной песочнице то Microsoft. В 2006 году Microsoft приобрела стартап Softricity, который фактически выворачивал контейнер наоборот.

    ThinApp


    VMware ThinApp (ранее Thinstall) — продукт для контейнеризации приложений от Jilt, приобретенной VMware в 2008 году. По оценкам VMware 90-95% всех упакованных приложений в мире использует именно эту технологию.

    Контейнеры 2.0


    История появления контейнеров 2.0 очень связана с изменением процесса разработки программного обеспечения. Стремление бизнеса уменьшить такой важный параметр как Time-to-market вынудило разработчиков пересмотреть подходы к созданию программных продуктов. На смену методологии разработки Waterfall (длинные релизные циклы, обновляется приложение целиком) приходит Agile (короткие, фиксированные по времени релизные циклы, независимо обновляются составные части приложения) и заставляет разработчиков разделять монолитные приложения на компоненты. Пока составные компоненты монолитных приложений все еще достаточно крупные и их не очень много их можно размещать и в виртуальных машинах, но когда одно приложение состоит из десятков или сотен компонент, то виртуальные машины уже не очень подходят. Дополнительно возникает и проблема версий вспомогательного софта, библиотек и зависимостей, часто бывает ситуация, когда разные компоненты требуют разных версий или по-разному настроенных переменных окружений. Такие компоненты приходится разносить на разные виртуальные машины, т.к. практически невозможно одновременно запустить несколько версий программного обеспечения в рамках одной ОС. Количество ВМ начинает лавинообразно расти. Тут на сцене и появляются контейнеры, позволяющие в рамках одной гостевой ОС создать несколько изолированных окружений для запуска компонент приложения. Контейнеризация приложений позволяет продолжить сегментацию монолитного приложения на еще более мелкие компоненты и перейти к парадигме одна задача = один компонент — контейнер, это и называется микросевисным походом, а каждый такой компонент — микросервис.

    Контейнер под капотом


    Если посмотреть на контейнер взглядом системного администратора, то это просто процессы в Linux у которых есть свои Pid’ы и т.д. Что позволяет обеспечить изоляцию процессов, работающих в контейнерах друг от друга и совместно потреблять ресурсы гостевой ОС? Два стандартных механизма, присутствующих в ядре любого современного дистрибутива Linux. Первый, Linux Namespaces, гарантирующий, что каждый процесс видит свое личное представление ОС (файловую систему, сетевые интерфейсы, hostname и т.д.) и второй, Linux Control Groups (cgroups), ограничивающий процесс в потреблении ресурсов гостевой ОС (CPU, память, сетевая полоса пропускания и т.д.).

    Linux Namespaces


    По умолчанию каждая Linux система содержит одно единственное пространство имен (Namespace). Все системные ресурсы, такие как файловые системы, идентификаторы процессов (Process IDs), идентификаторы пользователей (User IDs), сетевые интерфейсы принадлежат этому пространству имен. Но никто не мешает нам создать дополнительные пространства имен и перераспределить между ними системные ресурсы.

    Когда запускается новые процесс, он запускается в пространстве имен, системном-стандартном или одном из созданных. И этот процесс увидит только те ресурсы, которые доступны в используемом для запуска пространстве имен.

    Но не все так просто, каждый процесс принадлежит не одному единственному пространству имен, а одному пространству имен в каждой из категорий:

    • Mount (mnt)
    • Process ID (pid)
    • Network (net)
    • Inter-process communication (ipc)
    • UTS
    • User ID (user)

    Каждый из типов пространств имен изолирует соответствующую группу ресурсов. Например, пространство UTS определяет hostname и domain name видимые процессам. Таким образом два процесса внутри гостевой ОС могут считать, что они работают на разных серверах.

    Network пространство имен определяет видимость сетевых интерфейсов, процесс внутри увидит только интерфейсы принадлежащие этому пространству имен.

    Linux Control Groups (cgroups)


    Linux Control Groups (cgroups) – это механизм ядра (Kernel) Linux систем, ограничивающий потребление системных ресурсов процессами. Каждый процесс или группа процессов не сможет получить больше ресурсов (CPU, память, сетевая полоса пропускания и т.д.), чем выделено, и не сможет захватить «чужие» ресурсы – ресурсы соседних процессов.

    Docker


    Как было сказано выше, Docker не изобрели контейнеры как таковые. Контейнеры существуют уже много лет (в том числе и на базе LXC), но компания Docker сделала их очень популярными, создав первую систему, позволявшую легко и просто переносить контейнеры между разными машинами. Docker создала инструмент по созданию контейнеров — упаковке приложения и его зависимостей, и запуску контейнеров на любой Linux системе с установленным Docker.

    Важной особенностью Docker является переносимость не только самого приложения и его зависимостей между абсолютно разными дистрибутивами Linux, но и переносимость окружения и файловой системы. Например, контейнер, созданный в CentOS, может быть запущен на Ubuntu системе. При этом внутри запущенного контейнера файловая система будет унаследована от CentOS, и приложение будет считать, что оно работает поверх CentOS. Это чем то похоже на OVF образ виртуальной машины, но концепция Docker образа использует слои. Это означает, что при обновлении только части образа нет необходимости скачивать еще раз весь образ целиком, достаточно скачать только измененный слой, как если бы в OVF образе можно было бы обновить ОС, не обновляя целиком образ.

    Docker создал экосистему для создания, хранения, передачи и запуска контейнеров. В мире Docker есть три ключевых компонента:

    • Images — образ, это сущность, которая содержит ваше приложение, необходимое окружение и другие метаданные, необходимые для запуска контейнера;
    • Registers — репозиторий, место хранения Docker образов. Есть разнообразные репозитории, начиная от официального — hub.docker.com и заканчивая приватными, развернутыми в инфраструктуре компании;
    • Containers — контейнер, Linux контейнер, созданный из Docker образа. Как было сказано выше, это Linux процесс, работающий на Linux системе с установленным Docker, изолированный от других процессов и самой ОС.

    Рассмотрим жизненный цикл контейнера. Первоначально разработчик создает Docker образ со своим приложением (команда docker build), полностью с нуля или используя уже созданные образы как основу (вспоминаем про слои). Далее этот образ может быть запущен разработчиком прямо на его собственной машине или может быть перенесен на другую машину — сервер. Для удобства переносимости часто используют репозитории (команда docker push) — загружают образ в репозиторий. После этого образ можно будет скачать на любую другую машину или сервер (docker pull). И наконец создать из этого образа работающий контейнер (docker run).

    Kubernetes


    Как мы уже говорили, концепция микросервисов подразумевает разделения монолитных приложение на множество маленьких сервисов, обычно выполняющих одну единственную функцию. Хорошо когда таких сервисов десятки, ими еще можно управлять вручную через, например, Docker. Но что делать, когда таких сервисов становится сотни и тысячи? Кроме промышленной среды, нужна тестовая среда и дополнительные среды для разных версий продукта, т.е. умножаем на 2, на 3 или еще больше. С такими же проблемами столкнулись и Google, ее инженеры одни из первых начали использовать контейнеры в промышленных масштабах. Так и появился на свет Kubernetes (K8s), созданный под названием Borg в стенах Google продукт, позже отданный широкой общественности и переименованный.

    K8s — это система позволяющая легко развертывать, управлять и мониторить контейнеризированные приложения (микросервисы). Как мы уже знаем, для запуска контейнеров нам подходит любая Linux машина и контейнеры изолированы друг от друга, соответственно и K8s может управлять различными серверами с различным аппаратным обеспечением и под управлением различных Linux дистрибутивов. Все это помогает нам эффективно использовать имеющееся аппаратное обеспечение. Аналогично виртуализации, K8s предоставляет нам общий пул ресурсов для запуска, управления и мониторинга наших микросервисов.

    Поскольку эта статья рассчитана в основном на инженеров виртуализации, для общего понимания принципов работы и основных компонент K8s рекомендуем ознакомиться со статьей проводящей параллели между K8s и VMware vSphere: https://medium.com/@pryalukhin/kubernetes-introduction-for-vmware-users-232cc2f69c58

    История промышленной виртуализации x86


    VMware


    VMware появилась в 1998 году, начав с разработки гипервизора второго типа, позднее ставшего известным как VMware Workstation.

    На серверный рынок компания вышла в 2001 году с двумя гипервизорами — GSX (Ground Storm X, второго типа) и ESX (Elastic Sky X, первого типа). С течением времени перспективы второго типа в серверном применении стали очевидными, т.е. Никаким. И платный GSX сначала был превращен в бесплатный VMware Server, а затем и вовсе остановлен и похоронен.

    В 2003 появляются система централизованного управления Virtual Center, технологии vSMP и живой миграции виртуальных машин.

    В 2004 году VMware была приобретена ЕМС, гигантом в области СХД, но оставлена операционно независимой.

    В 2008 году, став де-факто стандартом индустрии, VMware стимулирует стремительный рост конкурентных предложений — Citrix, Microsoft и др. Становится понятной необходимость получить бесплатную версию гипервизора, что было невозможным — в качестве родительского раздела в ESX использовалась вполне коммерческая RHEL. Проект по замене RHEL на что-то более легкое и бесплатное получил свое воплощение в 2008 с системой busybox. Итог — всем известный на сегодня ESXi.

    Параллельно компания развивается путем внутренних проектов и поглощений стартапов. Несколько лет назад список продуктов VMware занимал пару страниц A4, поэтому скажем просто. VMware на 2019 до сих пор стандарт де-факто на рынке корпоративной полной виртуализации on-premise с рыночной долей более 70% и абсолютный технологический лидер, а подробное рассмотрение истории заслуживает отдельной очень большой статьи.

    Connectix


    Основанная в 1988 году Connectix занималась различными системными утилитами, пока не занялась виртуализацией. В 1997 году был создан первый продукт VirtualPC для Apple Macintosh, позволявший запускать Windows в виртуальной машине. Первая версия VirtualPC для Windows появилась в 2001 году.

    В 2003 году Microsoft выкупила VirtualPC и, по договоренности с Connectix, разработчики перешли в Microsoft. После этого Connectix закрылась.

    Формат дисков VHD (virtual hard disk) был разработан Connectix для VirtualPC, и в качестве напоминания об этом виртуальные диски машин Hyper-V содержат в своей сигнатуре “conectix”.
    VIrtual PC, как несложно догадаться, классический десктопный гипервизор второго типа.

    Microsoft


    Путь Microsoft в промышленную виртуализацию начался с покупки компании Connectix и ребрендинга Connectix Virtual PC в Microsoft Virtual PC 2004. Virtual PC развивался некоторое время, был включен под названием Windows Virtual PC в состав Windows 7. В Windows 8 и более поздних Virtual PC был заменен на десктопную версию Hyper-V.

    На основе Virtual PC был создан серверный гипервизор Virtual Server, просуществовавший до начала 2008 года. Ввиду очевидного технологического проигрыша перед VMware ESX было принято решение о сворачивании разработки гипервизора второго типа в пользу собственного гипервизора первого типа, которым стал Hyper-V. Существует неофициальное мнение в индустрии, что Hyper-V до удивления похож на Xen по архитектуре. Примерно так же, как и .Net на Java.
    — Вы конечно можете подумать, что Microsoft украла идею Java. Но это неправда, Microsoft ей вдохновилась! — (из выступления представителя Microsoft на презентации Windows 2003 Server)

    Из курьезных моментов можно отметить, что внутри Microsoft использование собственных продуктов по виртуализации в нулевых годах было, мягко говоря, опциональным. Существуют скриншоты Technet из статей по виртуализации, где явно присутствует в трее логотип VMware Tools. Также Марк Руссинович на Платформе 2009 в Москве проводил демонстрацию с VMware Workstation.

    Стремясь занять новые рынки, Microsoft создали собственное публичное облако Azure, использовав в качестве платформы сильно модифицированный Nano Server с Hyper-V, поддержкой S2D и SDN. Стоит отметить, что изначально, Azure в некоторых моментах сильно отставал от on-premise систем. Так например, поддержка виртуальных машин второго поколения (с поддержкой Secure Boot, загрузки с GPT-разделов, загрузки по PXE и т.д.) в Azure появилась только в 2018 году. В то время, как в On-Premise ВМ второго поколения известны еще с Windows Server 2012R2. То же касается портальных решений: до 2017 года в Azure и Windows Azure Pack (Multi-Tenancy решение для облаков, с поддержкой SDN и Shielded VM, пришедшее на смену System Center App Controller в 2013 году) использовали одинаковый дизайн портала. После того, как Microsoft объявила курс на публичные облака, Azure вырвался вперед по разработке и внедрению различных ноу-хау. Примерно с 2016 года можно наблюдать вполне закономерную картину: теперь все нововведения в Windows Server приходят из Azure, но никак не в обратную сторону. На это же указывает факт копирование частей документации из Azure в on-premise “как есть” (см. документацию по Azure SDN и Network Controller), что с одной стороны намекает на отношение к on-premise решениям, а с другой указывает на родство решений в части сущностей и архитектуры. Кто у кого списывал и как оно есть на самом деле — вопрос дискуссионный.

    В марте 2018 года Сатья Надела (CEO Microsoft) официально объявил, что приоритетом компании становится публичное облако. Что, очевидно, символизирует постепенное сворачивание и угасание продуктов серверной линейки для on-premise (впрочем, стагнация наблюдалась еще в 2016м году, но подтвердилась с первыми бетами Windows Server и остальных линеек on-premise продуктов), за исключением Azure Edge — минимально необходимой серверной инфраструктуры в офисе заказчика для сервисов, которые никак не могут быть вынесены в облако.

    Virtual Iron


    Основанная в 2003 году компания Virtual Iron предлагала коммерческую версию Xen и была одной из первых, кто предложил рынку полную поддержку аппаратной виртуализации.
    В 2009 была поглощена Oracle для развития собственной линейки виртуализации Oracle VM и расширения ее на x86. До этого Oracle VM предлагался только на платформе SPARC.

    Innotek


    В начале 2007 Innotek GmbH выпустила проприетарный десктопный гипервизор второго типа VirtualBox, бесплатный для некоммерческого использования. В том же году была выпущена версия с открытым исходным кодом.

    В 2008 году была поглощена компанией Sun, которая в 2010 в свою очередь была поглощена Oracle. Oracle сохранила бесплатное использование продукта в некоммерческих целях.
    VirtualBox поддерживает три формата виртуальных дисков — VDI (собственный), VMDK (VMware), VHD (Microsoft). В качестве хост ОС поддерживаются, Windows, macOS, Linux, Solaris и OpenSolaris. Известен форк VirtualBox для FreeBSD.

    IBM


    Мейнфрейм — это главный компьютер вычислительного центра с большим объемом внутренней и внешней памяти (для справки: в 60-х 1Мб памяти считался нереально большим объемом). Собственно, мейнфрейм и был вычислительным центром: первые компьютеры занимали целые машинные залы и состояли из огромных стоек. В наши дни это называется дата-центрами. Но в дата-центрах в одном машинном зале могут находится тысячи компьютеров, а на заре вычислительной техники один компьютер занимал целый зал. Каждая стойка реализовывала одно (!) устройство компьютера (отдельные стойки с памятью, отдельные стойки с устройствами хранения, отдельно – периферийные устройства). Ядром этой огромной машины была стойка с процессором – ее и называли основной, или мейнфреймом. После перехода на транзисторные интегральные схемы размер сего чуда научно-инженерной мысли существенно уменьшился, и под мейнфреймом стали понимать всю ЭВМ IBM и их аналоги.

    В 60-х годах XX века аренда вычислительных мощностей целого мейнфрейма, не говоря уже о его покупке, стоила огромных денег. Такую роскошь могли себе позволить очень немногие компании и институты. Аренда вычислительных мощностей была почасовая (прообраз современной модели Pay as you go в публичных облаках, не находите?). Доступ арендаторам для вычислений выдавался последовательно. Логичным решением было распараллелить вычислительные нагрузки и изолировать расчеты арендаторов друг от друга.

    Впервые идею изоляции нескольких инстансов операционных систем на одном мейнфрейме предложил Кембриджский научный центр IBM на базе мейнфрейма IBM System/360-67. Разработка называлась CP/CMS и, по сути, была первым гипервизором и предоставляла паравиртуализацию. CP (Control Program) – сам гипервизор, который создавал несколько независимых «виртуальных машин» (VM). CMS (изначально – Cambridge Monitor System, позже переименованная в Conversational Monitor System) представляла собой легкую однопользовательскую операционную систему. Любопытно, что CMS жива до и сих пор используется в мейнфреймах последнего поколения z/VM. Стоит отметить, что в то время и вплоть до 90-х под виртуальной машиной подразумевалось логическое разделение физических дисков (диски или устройства хранения были общими, хранилище под собственные нужды гипервизор не предусматривал) с выделенным куском виртуальной памяти и процессорного времени с использованием технологии Time-Sharing. Сетевого взаимодействия ВМ не предусматривали, тк ВМ того времени – это про вычисления и хранение данных, а не про их передачу. В этом смысле, ВМ того времени больше походили на контейнеры, чем на ВМ в современном понимании.

    Первый коммерческий гипервизор на базе CP/CMS под названием VM/370 появился в мейнфреймах серии System/370 2 августа 1972 года. Общее название этого семейства операционных систем – VM, и в рамках данного раздела под VM будет подразумеваться именно гипервизор IBM. Способность запускать несколько операционных систем одновременно, гарантируя стабильность системы и изоляцию пользователей друг от друга (ошибка в ОС одного пользователя не могла повлиять на вычисления другого пользователя) – была революционной и стала ключевым фактором коммерческого успеха VM/370. Любопытный факт: в то время в СССР усилиями НИИ ЭВМ (Минск) весьма успешно клонировали архитектуру System/370 и создали свой аналог VM/370 под названием ЕС ЭВМ (с поддержкой вложенной виртуализации! – для возможности разработки самой базовой ОС). Такие мейнфреймы использовались НИИ и оборонными предприятиями соцлагеря.

    80-е годы можно с уверенностью назвать «эрой мейнфреймов». VM имела успех у разработчиков операционных систем, под нее писались приложения и производились расчеты. Это было десятилетие, когда в мейнфреймах стала преобладать доля баз данных именно под управлением ОС VM. Одним из самых важных изменений стали логические разделы (Logical Partition Access Resources или LPAR), которые фактически обеспечили два уровня виртуализации. Теперь клиенты могли использовать один и тот же набор процессоров, устройств ввода-вывода и модемов в системах VM, работающих в разных LPAR и и позволяя мигрировать ресурсы из одной системы VM в другую. Это позволило ИТ-организации обеспечивать стабильную производительность, одновременно обрабатывая скачки рабочей нагрузки. Чтобы упорядочить растущую клиентскую базу, ОС VM разделилась на три отдельных продукта, доступных в конце 80-х:

    VM/SP – обычная многоцелевая операционная система виртуализации для серверов System z
    VM/SP HPO (High Performance Option) – высокопроизводительный вариант VM/SP для старших моделей серверов System z
    VM/XA (extended architecture) – вариант VM с поддержкой расширенной архитектуры S/370.

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

    Linux Xen


    Xen (произносится зен) — гипервизор, разработанный в компьютерной лаборатории Кембриджского университета под руководством Йена Прэтта (Ian Pratt) и распространяемый на условиях лицензии GPL. Первая публичная версия появилась в 2003 году. Впоследствии Йен продолжил работу над гипервизором в его коммерческой версии, основав компанию XenSource.
    В 2013 году Xen перешел под управление Linux Foundation.

    XenSource


    Просуществовав несколько лет на рынке с продуктами XenServer и XenEnterprise, в конце 2007 года была поглощена компанией Citrix.

    Citrix XenServer


    Поглотив XenSource за 500 млн долларов, Citrix не смогла в коммерческую сторону вопроса. А точнее, не особо в нее пыталась, не рассматривая XenServer в качестве основного продукта, и делая ставку на дешевизну перманентных лицензий. После откровенно провальных продаж на фоне сверхуспешного VMware ESX было принято решение о выпуске XenServer в мир бесплатно и с полным открытым кодом в 2009 году. Однако код проприетарной системы управления XenCenter не открывался.
    Нельзя не отметить интересное хронологическое совпадение инициатив Citrix и Microsoft в области промышленной виртуализации, при том, что компании всегда были очень близки.

    Несмотря на общее маркетинговое название, Citrix XenApp и XenDesktop не имеют никакого отношения к гипервизору Xen.

    Amazon


    Amazon представила свое публичное облачное предложение IaaS под названием EC2 (Elastic Compute) в 2006 году. Изначально платформа EC2 использовала гипервизор Xen, причем впоследствии Amazon разделила платформу на три части, в каждой из которой использовалась отдельная ветвь и версия гипервизора, чтобы минимизировать влияние ошибок в коде на доступность сервиса.

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

    Linux QEMU / KVM


    QEMU (Quick EMUlator) — универсальное ПО для эмуляции аппаратного обеспечения различных платформ, распространяемое по лицензии GPL v2. Помимо x86 поддерживаются также ARM, MIPS, RISC-V, PowerPC, SPARC, SPARC64. Обладая универсальностью платформы с полной виртуализацией QEMU не хватало производительности, сравнимой с невиртуализованной системой. Для ускорения работы QEMU на x86 предлагались два основных варианта, которые в конечном итоге были отвергнуты в пользу разработки KVM (Kernel-based Virtual Machine) от Qumranet.

    Говорим KVM — подразумеваем QEMU KVM, и соответственно получаем формат виртуальных дисков qcow2 (QEMU copy-on-write 2) для всех платформ на основе гипервизора KVM.
    Несмотря на то, что изначально QEMU работает как гипервизор второго типа, QEMU / KVM является гипервизором первого типа.

    Qumranet


    Израильская компания, бывший разработчик и основной спонсор гипервизора KVM и протокола SPICE. Основана в 2005 году, получила известность после включения KVM в состав ядра Linux. 4 сентября 2008 года поглощена корпорацией Red Hat.

    Red Hat


    Как и все производители дистрибутивов GNU/Linux, до 2010 года компания Red Hat встраивала в свои дистрибутивы поддержку гипервизора Xen. Однако, являясь крупным игроком на рынке и серьезным брендом, задумалась над собственной реализацией гипервизора. За основу был взят тогда еще ничем не примечательный, но перспективный гипервизор KVM. Первая версия Red Hat Enterprise Virtualization 2.2 (RHEV) была представлена в 2010 году с претензией побороться за кусок рынка VDI решений с Citrix и VMware за счет разработок компании Qumranet, поглощенной двумя годами ранее. Из коробки были доступны кластеры высокой доступности, Live Migration, средства М2М миграции (только для RHEL). Примечательно, что судя по документации того времени, Red Hat сохранили нотацию Xen при описании архитектуры решения.

    28 октября 2018 года компания IBM объявила о покупке Red Hat.

    OpenStack


    Исторически проект OpenStack появился как инициатива противопоставить что-то фактической монополии VMware в области тяжелой серверной виртуализации x86. Проект появился в 2010 благодаря совместным усилиям Rackspace Hosting (облачный провайдер) и NASA (открывшей код собственной платформы Nebula). Пикантности ситуации придал тот факт, что в 2012 году VMware присоединилась к управлению проектом OpenStack, вызвала волну негодования у активистов-основателей.

    С течением времени к проекту присоединялись Canonical (Ubuntu Linux), Debian, SUSE, Red Hat, HP, Oracle.

    Однако не все было гладко. В 2012 NASA вышла из проекта, сделав выбор в пользу AWS. В начале 2016 HPE полностью закрыла свой проект Helion на основе OpenStack.

    В рамках проекта OpenStack в качестве стандартного гипервизора принят KVM. Однако в силу модульности подхода система на основе OpenStack может быть реализована с использованием иных гипервизоров, оставляя от OpenStack например только систему управления.

    Существует значительный разброс мнений относительно проекта OpenStack от восторженного поклонения до серьезного скепсиса и жесткой критики. Критика не лишена оснований — были зафиксировано значительное количество проблем и потерь данных при использовании OpenStack. Что, впрочем, не мешает поклонникам все отрицать и ссылаться на криворукость при имплементации и эксплуатации систем.

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

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

    Nutanix AHV


    Nutanix с момента создания был продуктом и платформой исключительно под VMware vSphere. Однако частично из-за стремления расширить предложение для других гипервизоров, частично из-за политического кризиса в отношениях с VMware было принято решение о разработке собственного гипервизора, который завершил бы коробочную платформу и позволил отказаться от сторонних продуктов. В качестве собственного гипервизора был выбран KVM, который в рамках платформы получил название AHV (Acropolis HyperVisor).

    Parallels


    В 7 версии Virtuozzo компания перешла от собственного гипервизора на KVM.

    Proxmox


    Proxmox VE (Virtual Environment) — проект с открытым исходным кодом австрийской компании Proxmox Server Solutions GmbH на основе Debian Linux. Первый релиз был в 2008 году.
    В рамках продукта поддерживается контейнерная виртуализация LXC (ранее OpenVZ), и полная виртуализация с гипервизором KVM.

    Parallels / Virtuozzo / Росплатформа


    Основанная в 1999 году Сергеем Белоусовым компания SWsoft занялась софтом для управления хостингом. В 2003 году приобретается новосибирская компания-конкурент Plesk.

    В 2004 году SWsoft приобретает российскую компанию Parallels Николая Добровольского с ее продуктом Parallels Workstation (десктопный гипервизор второго типа под Windows).
    Объединенная компания оставляет себе имя Parallels и в скором времени взрывает рынок с Parallels Desktop для Mac (десктопный гипервизор второго типа под MacOS).

    В рамках серверной виртуализации продолжается фокус на хостинг провайдерах и датацентрах, а не корпоративное использование. В силу специфики именно этого рынка ключевым продуктом стали контейнеры Virtuozzo и OpenVZ, а не системные виртуальные машины. Впоследствии Parallels без особого успеха пытается выйти на рынок серверной корпоративной виртуализации с продуктом Parallels Bare Metal Server (впоследствии Parallels Hypervisor и Cloud Server, а затем Virtuozzo), добавляет гиперконвергентности со своим Cloud Storage. Продолжается работа над ПО автоматизации и оркестрации работы хостинг провайдеров.

    В 2015 году на основе продуктов по серверной виртуализации создается проект Росплатформа — технически (опустив юридические и организационные моменты) тот же Virtuozzo, только с измененными обоями и в реестре российского ПО. На основе ПО Росплатформа и оборудования Depo компания IBS создает пакетное гиперконвергентное предложение Скала-Р.

    До версии 7 Virtuozzo использовали гипервизор собственной разработки, в 7 версии был осуществлен переход на KVM. Соответственно, Росплатформа — тоже стала на основе KVM.
    После нескольких слияний, поглощений и ребрендингов складывается следующая картина к 2019 году.

    Parallels Desktop выделен в компанию Parallels и продан Corel. Вся автоматизация ушла в компанию Odin и продана IngramMicro. Серверная виртуализация осталась под брендом Virtuozzo / Росплатформа.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +2
      Вы упоминаете про «SMP» и «NUMA». Вообще, весь список какой-то странный, весь набит разнородными терминами.

      Термин «SMP» должен упоминаться вместе с «AsMP» (асимметричная многопроцессороность) и «MPP» (массово-параллельная процессорность). Эти три варианта описывают взаимодействие процессоров. При этом организация памяти у них м.б. любой из нижеперечисленных.

      Термин «SMP» должен упоминаться вместе с «UMA» (однородный доступ к памяти) и «NonMA» (полное отсутствие прямого доступа к памяти другоих процессоров); до кучи хорошо бы упомянуть «RDMA» (доступ к чужой памяти есть, не не прямой, а только копированием через DMA-контроллер). Это — три или четыре варианта организации памяти, но это не всё.

      Помимо общего доступа к памяти, есть ещё синхронизация кэшей — которая может были или не быть. Точнее, есть три варианта:
      1. Просто общий кэш. Для многочиповой системы общий кэш м.б. только внешним — а внутренний м.б. только раздельным.
      2. Раздельный кэш с автоматический синхронизацией (также может поддерживать считывание данных из чужого кэша — тогда говорят «кэш сделан проо архитектуре „NUMA“). Дико просаживает производительность на операциях записи.
      3. Раздельный кэш без синхронизации. Вынуждает использовать общую память в режиме, близком к NonMA — обмен данными через общую память сложный и дорогой.
      С т.з. доступа к памяти, первые два варианта — идентичны. Итого у нас получается пять (или шесть, если считать RDMA) вариантов работы с памятью. Все они могут сочетаться с любым вариантом взаимодействия процессоров.

      Вообще, надо помнить, что у процессоров всегда есть своя собственная внутренняя память, недоступная никому больше. Как минимум, это регистры — которые по своей сути тоже память, но быстрая и с особыми режимами доступа. Поэтому утверждать, что „SMP — это обязательно UMA“ нельзя, ибо видов памяти в современных компьютеров много (порядка чуть ли не дюжины), и они работают в разных режимах (UMA, NUMA или NonMA).




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

      Но сейчас я хочу поговорить не об архитектуре процессора, а о программной архитектуре — которую, как ни странно, навязывает аппаратура.

      Для начала — задача для IT-студентов:
      • Чтобы загрузить что-то с диска — надо обратиться к контроллеру диска. Контроллеры диска бывают очень разные — например. SCSI-контроллеры имеют совершенно разный ABI.
      • Чтобы выполнить запрос — драйвер (неважно какого устройства) д.б. загружен в память и инициализирован, причём ещё до первого к нему обращения.
      • Пока компьютер выключен — все драйверы (в т.ч. драйвер дискового контроллера) лежат на диске (в отдельном файле, как в Windows; или вкомпилированы все вместе в один файл вместе с ядром, как в Unix). (Этот пункт выделен, ибо он понадобится нам ниже.)
      Так каким же образом драйвер дискового контроллера может оказаться в памяти, если для его загрузки надо обратиться к контроллеру диска; а это можно сделать только через этот драйвер? (Этот вопрос я оставляю желающим на самостоятельное решение.)

      Так вот, ублюдочность архитектуры перснального компьютера — в т.ч. в том, что все операционки (кроме DOS и других операционок той поры) вынуждены тащить с собой все драйверы устройств, с которыми собираются работать. Это потому, что они предполагают работу на „голом железе“. А „голое железо“ — это стандарт именно персональных компьютеров.

      А вот если бы компьютер снабжался операционкой, зашитой в ПЗУ — его эволюция шла бы совершенно другими путями. Отличий было бы множество — начиная с того, что производители операционок не стали бы следовать рекомендации Билла Гейтса „надо как можно скорее выкинуть на рынок недоделанное говно и захватить рынок, убив конкурентов, которые долго и тщательно делают качественный продукт“. Хотя бы потому, что операционку в ПЗУ заменить сложно, ежедневно выпускать по дюжине обновлений (в т.ч. критические обновления безопасности) тут не получится.

      Кроме того, получили бы распространение бездисковые машины. Потому что не было бы необходимости ставить локальный жёсткий диск для загрузки операционки. И администрирование компьютерного парка в корпорациях стало бы намного легче.

      А ещё — при наличии операционки в ПЗУ, виртуализация появилась бы намного раньше. Просто потому, что при желании запустить на этом компьютере альтернативную операционку — её портировали бы не для рабты на голом железе, а с использованием уже имеющейся в ПЗУ операционке. При таком развитии компьютеров — никакой классической неполной виртуализации не могло возникнуть в принципе, ибо не было бы операционок, нуждающихся в ней. Была бы полная виртуализация для операционок с других платформ (если там была уродливая архитектура); и паравиртуализация.
        +4
        Насчёт ОС в ПЗУ — в итоге к этому и пришли (UEFI).
          +2
          А чем BIOS не ОС? Смысл в том что это не основная операционка.
          Кстати и первые драйвера для диска лежат там же — BIOS — basic input/output system.
            +1
            В каком-то смысле тоже ОС, но UEFI ещё более похож на большую ОС — можно зайти в консоль, запускать программы с внешних дисков и т.д.
          +1
          Спасибо, SMP / UMA поправил.
            +3
            >А вот если бы компьютер снабжался операционкой, зашитой в ПЗУ

            … то его убила бы та архитектура где такой геморрой пользователю не подсовывали бы.
              –1
              Gumanoid, CrzyDocTI:

              UEFI — это ни разу не операционка. Если бы она была операционкой — то под неё пписались бы программы, и люди работали бы в ней без дополнительной (загружаемой) операционки.

              Можно проверить, является ли UEFI операционкой с современными требованиями:
              1. Какие файловые системы поддерживает UEFI? Т.е. с каких файловых систем можно запускать внешние программы?
              2. Какой режим процессора поддерживает UEFI — реальный 8086, защищённы 286, защищённы 386, защищённы AMD-64?
              3. Как в UEFI с многозадачностью?
              4. Какие сетевые протоколы поддерживает UEFI? В частности, как там с настройкой IP-маршрутизации? С каких сетевых файловых систем можно запускать внешние программы?


              hjornson:

              У меня ощущение, что Вы вообще никогда не работали с компьютером. По кр.мере — не администрировали ни класс из нескольких компьютеров, ни даже свой собственный компьютер. Потому что если бы не так — то Вы бы знали, что самый страшный геморрой был при разрушении операционки (когда надо загружаться с внешнего носителя) и заражение операционки вирусом (где-то я читал, что вирусы с функцией заражения загрузки составляли 30% от числа вирусов и давали 90% случаев заражения компьютеров). Операционка в ПЗУ — избавлена от обеих проблем.
              А какой именно геморрой может создать операционка, записанная в ПЗУ — Вы скромно умолчали.

              Вообще, даво уже пора понимать, что успех той или иной системе на рнке (не только компьютерном, а практически везде) определяется не техническими характеристиками товара, а маркетингом. Исключения бывают, но очень редко — например, при создании карманных компьютеров, для которых *86 не годился вообще.
                +1
                Какие файловые системы поддерживает UEFI? Т.е. с каких файловых систем можно запускать внешние программы?
                Зависит от вендора, но все поддерживают FAT32 и многие — NTFS.

                Какой режим процессора поддерживает UEFI — реальный 8086, защищённы 286, защищённы 386, защищённы AMD-64?
                Либо защищённый 386, либо защищённый AMD-64. На большинстве новых систем — защищённый AMD-64.

                Как в UEFI с многозадачностью?
                Одно приложение общается с пользователем, но может быть сколько угодно фоновых. Один-в-один как в Android или iOS.

                Какие сетевые протоколы поддерживает UEFI?
                TCP/IP, как и везде.

                В частности, как там с настройкой IP-маршрутизации?
                Так же, как и в Android/iOS, если коротко.

                С каких сетевых файловых систем можно запускать внешние программы?
                С тех, которые предусмотрел вендор. Обычно это PXE.

                Как легко увидеть — никаких технических поводов не считать EFI операционкой нет. Вот совсем нет. Политические, социальные — да, возможно. Технически — это операционка. И довольно-таки сложная.

                А какой именно геморрой может создать операционка, записанная в ПЗУ — Вы скромно умолчали.
                Ну какой, какой. Обычный. Достаточно тупо удалить все переменные EFI — и всё, приехали. Очередно «кирпич». Так не должно бы быть, в теории. Но так есть. У дикого количества вендоров.
                  0
                  Добавлю про многозадачность еще: давно уже есть возможность использовать простаивающие при обычном запуске прошивки ядра для параллельного выполнения задач (к примеру, на Маках таким образом работает Internet Recovery, т.е. загрузка и проверка хешей кусков образа по 10Мб сделана параллельно и задействует все доступные ядра ЦП) через EfiMpServiceProtocol. В UEFI 2.7 похожий протокол добавили в PEI.

                  Ну и в качестве вишенки на торт: современные реализации EFI используют IOMMU, виртуальную память и разделение на ring-0 и ring-3 для изоляции опасных с точки зрения внешних атак драйверов, OptionROM'ов и приложений (слайды с презентации с BH).

                  Я сам не стал бы называть EFI полноценной ОС общего назначения (потому что чтобы стать таковой ей нужен EFI Shell), но не называть ее ОС совсем уже давно не получается даже с натяжкой. Я по прежнему считаю, что прошивка должна быть «создана, чтобы умирать», и потому большая часть нынешней спецификации UEFI в ней совершенно лишняя, и может быть без особых проблем заменена на Линукс или другую полноценную ОС, но у индустрии давно уже свое мнение на этот счет, не совпадающее с моим.
                    0
                    У индустрии нет единого мнения. EFI продавливает Intel, потому что это позволяет ему вкорячивать в EFI свои, делающие неизвестно что, блобы, которые, типа ох-как-нужны для его процессоров.

                    На не телефонах или там стиральных машиных, как вы знаете, ничего этого нет.

                    Google пытается с этим бороться, но в мире, где Intel доминирует — сделать это очень сложно.

                    Веселее всего ситуация с ARM'ом на серверах: с одной стороны вендоры пытаются продавливать EFI, так как к нему привыкли, с другой — производителям ARM'овском железа всё это нафиг не нужно.

                    В общем весёлые времена. Как обычно, да.
            +1
            Странно, что унификация доступа к памяти совсем никак не описана. Никак не описаны himem.sys emm386.exe и qemm386. Совсем не затронута компания QuartDesq и один из первых успешных гипервизоров для DOS.
            Без темы многозадачности и параллельного выполнения странно начинать тему виртуализации.
              +2
              Совсем не затронута компания QuartDesq и один из первых успешных гипервизоров для DOS.
              Поиск в Гугле находит это слово в интеренете ровно один раз — в вашем комменатрии. Вы из параллельной вселенной? Что за «гипервизор для DOS»?

              himem.sys — это, всё-таки, о другом совсем… может быть EMS? Digital Research (в нашей вселенной) реализовывала многозадачную систему на базе CP/M, где память виртуализовывалась на базе EMS… это близко к описанным вначале FS -> LBA -> CHS… но нельзя охватить необъятного — это уже будет не статья, а книга на полтысячи страниц, если попытаться охватить все подобные примеры. Это же просто вводная была, я так понимаю охватить вот совсем всё-всё задача не ставилась…
                +1
                С вашего поволения, немного развею туман веков над этим вопросом.
                Компания называлась Quarterdeck (полностью — Quarterdeck Office Systems), выпущенный ей продукт для виртуализации DOS (в котором можно было запускать несколько DOS VM в режиме виртуализации реального режима — V86) — DESQView.
                Спецификация EMS к виртуальнм машинам прямого отношения не имела: она описывала, как можно отображать в доступное адресное пространство объем памяти, больший, чем пресловутые 640К(в реальности — 1М, т.к. оставшиеся 384К были зарезервированы под адресное пространство для ПЗУ и памяти, используемой переферийными устройствами) — через специально отводимое перемещаемое по этой большей памяти «окно». Такие решения по расширеню адресуемой памяти в истории развития вычислительной техники возникали неоднократно (кто был первый — даже не знаю). К примеру, когда развитие ОС для x86 уперлось в ограничение 32бит адреса, то в Windows Server появилось аналогичная по своей сути спецификация доступа к памяти свыше 4ГБ — AWS.
                В случае EMS изначально предполагалось, что управление отображением будет реализовано специальной аппаратурой (размещенной вместе с дополнительной памятью на плате расширения или выполненной внутри чипсета). Однако уже упомянутая Quaterdeck научилась использовать вместо этой аппаратуры появившийся в 80386 режим виртуализации V86. Для этого она выпустила драйвер QEMM-386. Который тоже отчасти был чем-то вроде «одноместного гипервизора»: DOS после инициализации этого драйвера работала не в реальном, а в V86 режиме процессора, но — с прямым отображением почти всей памяти (виртуальные адреса были равны реальным) — кроме области окна, в которую этот драйвер отображал в соотвествии со спецификацией EMS имеющуюся в системе оперативную память, находящуюся над границей 640К.
                PS А ещё, кстати, гипервизором для DOS была и Windows(в расширенном режиме) — в ней DOS-окна запускались как раз в режиме V86.
                  0
                  продукт для виртуализации DOS (в котором можно было запускать несколько DOS VM в режиме виртуализации реального режима — V86) — DESQView.
                  Там нет «нескольких VM». Да, там происходит некоторая виртуализация DOS, но это не OS/2 и даже не Windows.

                  DESQView может работать на 80286 и даже 8086! Какие, к бесу, виртуальные машины???

                  Спецификация EMS к виртуальнм машинам прямого отношения не имела:
                  Имела-имела. Именно поверх EMS DESQview и виртуализировал DOS. А уже VM8086 использовался, чтобы реализовать EMS поверх расширенной памяти.

                  Однако уже упомянутая Quaterdeck научилась использовать вместо этой аппаратуры появившийся в 80386 режим виртуализации V86
                  Про CEMM от Compaq, вы, я так полагаю, не в курсе? Она поставлялась с первым IBM PC-совместимым компьютером на базе 80386.

                  PS А ещё, кстати, гипервизором для DOS была и Windows(в расширенном режиме) — в ней DOS-окна запускались как раз в режиме V86.
                  Тут уже начинается мухлёж с терминологией. Вот OS/2 — та, да, таки умела запустить любую версию DOS в окошке. Это можно назвать гипервизором. А вот DESQview и Windows… Тут всё сложнее. Фактически они делали с помощью EMS «клоны» одной и той версии DOS из которой они сами и запускались. И даже Windows 3.x, научившись использовать VM8086 напрямую… Всё равно делала лишь клоны (откуда и проблемы совместимости с DR-DOS). А вот Windows-95 — там уже был гипервизор… Но если система подхватывала вирус, то включался «режим совместимости с вирусом», такой же как в Windows 3.x — что сразу замечалось по нереальным тормозам…
                    +1
                    Там нет «нескольких VM». Да, там происходит некоторая виртуализация DOS, но это не OS/2 и даже не Windows.

                    «Некоторая виртуализация» заключалась в том, что эти копии DOS могли работать независимо дург от друга и параллельно, в режиме вытесняющей многозадачности. А то, что они использовали один и тот же код ядра, то это и в других гипервизорах встречалось: например, в VM/SP, где все VM с одной и той же хранимой системой (например, CMS) использовали один и тот же код ядра.
                    DESQView может работать на 80286 и даже 8086! Какие, к бесу, виртуальные машины???
                    Да, тут требуется уточнение: речь была конкретно о версии Desqview 386 (с которой я некогда реально работал).
                    Про CEMM от Compaq, вы, я так полагаю, не в курсе?

                    В курсе: как вы заметили, я отнюдь не утверждал, что Quaterdeck научилась это делать первая.
                    Тут уже начинается мухлёж с терминологией.
                    Факт состоит в том, что Desqview (равно как и Win3.x Extended mode) выполнял фукцию управляющего ПО, работавшего на уровне ниже ОС (DOS в конкретном случае), с более высокими привилегиями, и определявшего, что именно из аппаратуры и прерываний доступно вышележащей ОС — что обычно как раз и называется в наше время словом «гипервизор» (да, раньше такого слова не было, в VM/SP, к примеру, этот компонент именовался незатейливо: Control Program).
                    И даже Windows 3.x, научившись использовать VM8086 напрямую… Всё равно делала лишь клоны (откуда и проблемы совместимости с DR-DOS). А вот Windows-95 — там уже был гипервизор…
                    Windows 95 от Windows 3.x Extended Mode в этом плане архитектурно отличалась мало: и WIN386.EXE из Win3.x, и VMM32.VXD выполняли примерно одни и те же функции компонента Virtual Machine Manager: управление вытесняющей многозадачностью для VM (выполняющих DOS и системной, выпоняющей Windows), обработку прерываний, управление памятью… Подробности (которые сейчас представляют, разве что чисто исторический интерес) можно прочесть, например, в старой книге Шульмана «Неофициальная Windows 95». Ну, а режим совместимости — он был поблажкой именно ради совместимости с TSR(резидентными программами для DOS), работающим с обращениями к файловой системе и диску (которые были как полезные, ради которых эта проверка делалалсь, так и наоборот — то есть вирусы). А так, в принципе, Windows могла его и не включать, и работать с файловой системой, не используя код DOS (и Win 3.11 тоже могла, называлось это 32BFA, VxD под это в ней был, только им часто не пользовались, потому как в нем как раз упомянутого режима совместимости не было)
              0

              Это каким образом kvm 'первого типа', если это модуль ядра, уважащий все правила ядра? А амазон, вообще говоря, уже на всех парах на firecracker бежит.

                0
                Гипервизор второго типа работает в user space как обычное приложение поверх ОС общего назначения.
                  0

                  У вас какое-то извращённое представление о том, что такое "второй тип". Второй тип — это когда "сверху" ОС, т.е. ОС управляет памятью, правами доступа и т.д. kvm прекрасно во второй тип укладывается. Требование "userspace" я ни разу в описании гипервизоров не видел, хотя бы потому, что невозможно реализовать гипервизор в userspace, там можно сделать только эмулятор.

                    +1
                    Георгий, это у вас какие то свои термины и понимание того, что такое гипервизор.

                    Senior director, virtualization business at Red Hat:

                    “KVM is a bare-metal hypervisor (also known as Type I)”

                    It is a myth that KVM is not a Type-1 hypervisor. KVM converts Linux into a Type-1 hypervisor. There is only one kernel that is used (and that is the Linux kernel, which has KVM included). On the flip side, I can make an argument that Xen is not a Type-1 hypervisor, because the CPU and memory is scheduled by the hypervisor, but IO is scheduled by Dom0, which is a guest (so it's not bare metal). In the KVM architecture, the CPU, memory, and IO are scheduled by the Linux kernel with KVM.
                      0

                      Не могли бы вы посоветовать, что можно почитать по KVM? Интересует, в первую очередь, то, что скрыто под капотом. Пока натыкался лишь на довольно общие описания и обрывки подробной информации. В kernel/Documents/virt неплохо описаны некоторые вещи, но инфы маловато.

                      0

                      модуль ядра, конвертирующий ядро в гипервизор. Дерзко. Я думаю, это подтрунивание над xen'ом.


                      Очевидно, что kvm есть, что kvm нет, линукс как памятью управлял, так и управляет.

                0
                Однако, до полноценной виртуализации (и ее варианта в виде паравиртуализации) jail не хватает возможности запускать ядро другой версии в гостевой ВМ и кластеризации с миграцией ВМ на другую хост систему.

                Это не соответствует действительности. Во FreeBSD jails с успехом запускаются не только гостевые FreeBSD с другими версиями ядра, но и всевозможные Linux.

                  0
                  При полноценной виртуализации можно запускать любую x86 ОС, не только Linux.
                  Не подскажете где подробно рассказывается как именно запускается *всевозможный* Linux, в каком формате диски, как мигрировать с одного хоста на другой?
                    0

                    Начните со FreeBSD Handbook а далее, обычно, пользуются поиском.
                    Кластеризация и миграция не являются признаками "полноценной виртуализации" (чтобы вы под ней не имели ввиду).
                    Вообще, статья плохо структурирована и столь же плохо читается. Вероятно, это признак того что вы недостаточно сами разобрались в теме.
                    Я вам сходу указал на явно бросившееся в глаза ошибочное утверждение.
                    Кроме того, во FreeBSD есть ещё и bhyve.
                    https://www.bsdstore.ru/ru/articles/bhyve_vs_jails.html

                    +1
                    с другими версиями ядра

                    Ядро используется хостовое, и запустить вы сможете внутри jail только тот набор userspace приложений, который может работать с текущим хостовым ядром. Понятно, что это может быть и linux userspace, если хостовое ядро собрано с linux_enable=«YES».
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Антон, пишется Fibre Channel.
                        0
                        Потому что Л. Логика!

                        Fibre Channel использует Fiber кабели.

                        Постоянно их путаю.
                        +4
                        В статье есть досадный (IMHO) пробел: полностью отсутствует упоминание об аппаратной виртуализации реального режима в процессоре 80386 и его потомках и клонах (режим V86) и о его использовании для создания виртуальных DOS-машин в Windows 3.x и 9x/ME (а также — в уже упомянутой DesqView и других ОС для ПК).
                          +1
                          А какая VDM(Virtual DOS Machine) была в OS/2? Мало того что позволяла запускать любые версии DOS с образов дискет, так ещё искаропки в OS/2 шла 3.11 винда с прозрачной интеграцией в десктоп «хостовой» ОС. Мало того, в середине 90-х была микроядерная версия — OS/2 PowerPC Edition, как не сложно понять под архитектуру PowerPC, так вот в ней был и VDM и 3.11 винда и виртуализация x86 процессора…
                            0
                            Увы, да. Готовы восполнить этот пробел?
                            +3
                            Очень интересная статья для начинающих в этой теме, благодарю!
                              0

                              Хотелось бы немного более развернуто услышать про


                              "компьютер, несмотря на свое название, считать не умеет, он умеет делать вид, что умеет считать"


                              а то звучит как какой-то выпендрёж.


                              "Компьютер, а конкретно процессор, на самом деле ничего не исполняет — он всего лишь ожидает некоторых входных параметров в определенных местах, а после, посредством страшной черной магии, выдает некоторые результаты в определенных местах."


                              Опять же, звучит красиво для какого нибудь жёлтого журнала, а по сути — бред, т.к исполнение кода и состоит в том, что бы делать "… некоторых входных параметров в определенных местах, а после, посредством страшной черной магии, выдает некоторые результаты в определенных местах.", и называется это fetch/decode/execute/store циклом.

                                –4

                                P.S. хабр-сообщество в очередной раз показало себя со своей скотской стороны.
                                Спасибо за минусы в карму к предыдущему посту, где я только задал вопросы по существу.

                                0
                                Смотрите, в гипервизоре II ресурсами (память, ввод-вывод) управляет программное обеспечение установленное поверх операционной системы. Этому программному обеспечению выделяются ресурсы ровно так же как и для любого другого программного обеспечения — базы данных, сервера приложений и т. п. Далее, ПО виртуализации управляет полученными ресурсами, обеспечивая работу виртуальных машин. Например, выделение памяти для ВМ происходит программой виртуализации.
                                В KVM — управление ресурсами для обеспечения работы виртуальных машин выполняется ну уровне Linux. В этом смысле, Linux такой же гипервизор как VMware — не больше и меньше — гипервизор I типа.
                                  0
                                  Благодарю за статью!
                                  Отличный экскурс в историю развития современных продуктов. Прочитал всё на одном дыхании.
                                    0

                                    Большое спасибо! Прочитал с огромным удовольствием. Правда понадобилось два подхода, чтобы прочитать статью полностью.

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

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