Общая теория и археология виртуализации 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-подобных операционных системах. Программа, запущенная с измененным корневым каталогом, будет иметь доступ только к файла
