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

Введение

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

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

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

Виртуализация — сокрытие конкретной реализации за универсальным стандартизованным методом обращения к ресурсам / данным.

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

POZOR!

Uwaga! Achtung! Pozor!

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

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

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

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

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

FS -> LBA -> CHS

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

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

RAID

Следующий слой виртуализации, который за виртуализацию правда многие ошибочно не считают — это RAID (redundant array of inexpensive 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.

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

В самой первой полной реализации 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, сохраняя обратную архитектурную совместимость аж с 16 битным реальным режимом 8086, были способны исполнять свой код в 64 бита, и код ВМ в 64 бита, а вот код вложенной ВМ работа уже переходил в режиме совместимости в 32. Помимо всего прочего данную проблемы адресовали в процессорах с аппаратной виртуализацией, позволив виртуальным процессорам так же работать в “longmode”.

SMP

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

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

NUMA

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

У процессоров Intel Xeon Scalable v2 на 2019 внутренняя архитектура все еще остается SMP в пределах сокета, превращаясь в NUMA для других сокетов. У AMD процессоры Opteron имели архитектуру NUMA даже во времена Xeon SMP, а далее стали 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. Может показаться, что это прямое подключение к гипервизору, однако это не так. Прямой доступ к гипервизору отсутствует, что выгодно отличает этот тип гипервизора от гипервизоров второго типа в аспекте безопасности.

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

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

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

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

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

К гипервизорам данного типа относятся: почивший 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 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 / Росплатформа.

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

Автор: AntonVirtual

Источник