После недавних дискуссий о том, какой гипервизор лучше, возникла идея выписать функциональность современных систем виртуализации без привязки к конкретным названиям. Это не сравнение «кто лучше», это ответ на вопрос «что можно сделать с помощью виртуализации?», общий обзор возможностей промышленной виртуализации.
Так как гипервизор полностью контролирует виртуальные машины, он может специфичным образом управлять процессом работы машины.
Различные системы виртуализации предлагают несколько методов исполнения кода (полная эмуляция в список не включена, так как не используется в промышленной виртуализации):
В реальности паравиртуализированные драйвера используются и в HVM и в binary rewriting (их часто называют guest tools), т.к. именно в операциях ввода/вывода паравиртуализация существенно обгоняет по производительности все остальные методы.
Все без исключения гипервизоры умеют выполнять операцию «паузы» (suspend/pause) для виртуальной машины. В этом режиме работа машины приостанавливается, возможно, с сохранением данных памяти на диск и продолжением работы после «восстановления» (resume).
Общепринятой фичей является понятие миграции — переноса виртуальной машины с одного компьютера на другой. Бывает оффлайновой (выключили на одном компьютере, включили на втором) и онлайновой (обычно называется live, т.е. «живая миграция») без выключения. В реальности реализуется с помощью suspend на одной машине и resume на другой c некоторой оптимизацией процесса переноса данных (сначала переносятся данные, потом машина саспендится и переносятся изменившиеся данные с момента начала миграции, после чего запускается новая машина на новом хосте).
Так же в зене обещана (и, вроде, почти доведена до продакта) технология параллельного исполнения одной машины на двух и более хостах (Remus), позволяющая продолжать работу виртуальной машины в случае отказа одного из серверов без перерывов/перезагрузок.
Классическая модель виртуализации подразумевает выделение фиксированного объёма памяти гостевой машине, изменение возможно только после её «выключения».
Современные системы могут реализовывать функционал ручного или автоматического изменения объёма оперативной памяти для гостевой системы.
Существуют следующие методы управления памятью:
Некоторые гипервизоры позволяют обеспечить доступ виртуальной машины к реальному оборудованию (причём, разным виртуальным машинам, к разному оборудованию).
Так же они могут обеспечивать эмуляцию оборудования, в том числе и отсутствующего на компьютере. Наиболее важные из устройств — сетевой адаптер и диск рассматриваются отдельно; среди остального: видеоадаптеры (даже с 3D), USB, последовательные/параллельные порты, таймеры, вотчдоги.
Для этого используется одна из следующих технологий:
Сетевые устройства обычно реализуются либо на третьем, либо на втором уровне абстракции. Создаваемый виртуальный сетевой интерфейс имеет два конца — в виртуальной машине и в гипервизоре/управляющем домене/программе виртуализации. Трафик из гостя передаётся в неизменном виде в хозяина (без всяких танцев с перепосылками, согласованием скоростей и т.д.). А дальше начинаются достаточно существенные сложности.
В настоящий момент, за вычетом систем, эмулирующих сетевой интерфейс на третьем уровне (уровень IP-адресов, например, openvz), все остальные системы предоставляют следующий набор возможностей:
В некоторых системах виртуализации разделяют отдельно случай бриджинга сетевого интерфейса виртуальной машины с физическим сетевым интерфейсом и наличие виртуального коммутатора.
Вообще, сеть виртуальных машин доставляет особую головную боль при миграции. Все существующие продакт системы с бриджингом интерфейсов разрешают прозрачную живую миграцию машин только в одном сегменте сети, требует особых ухищрений (fake ARP) для оповещения вышестоящих коммутаторов о смене порта для коммутации трафика.
В настоящий момент разработана довольно интересная система — open vSwitch, позволяющая вынести задачу определения пути прохождения пакета на open-flow контроллер — возможно, она позволит существенно расширить фунционал виртуальных сетей. Впрочем, open flow и vSwitch немного в стороне от темы (и я попробую рассказать о них чуть позже).
Это вторая крайне важная веха в работе виртуальных машин. Жёсткий диск (точнее, блочное устройство для хранения информации) является второй, а может даже и первой, по важности компонентой виртуализации. Производительность дисковой подсистемы является критичной для оценки производительности системы виртуализации. Большой оверхед (накладные расходы) на процессор и память будут пережиты более спокойно, чем оверхед на дисковые операции.
Современные системы виртуализации предлагают несколько подходов. Первый — в предоставлении виртуальной машины готовой файловой системы. Накладные расходы при этом стремятся к нулю (специфично для openvz). Второй — в эмуляции блочного устройства (без всяких рюшечек вроде смарта и SCSI команд). Блочное устройство из виртуальной машины привязывается либо к физическому устройству (диску, разделу, логическому тому LVM), либо к файлу (через loopback device или прямой эмуляцией блочных операций «внутри» файла).
Дополнительной возможностью является использование гипервизором сетевого хранилища — в этом случае процесс миграции очень прост: на одном хосте машину паузят, на втором продолжают. Без перекачки каких-либо данных между хостами.
При этом большинство систем, при условии, что блочное устройство нижележащего уровня это поддерживает (LVM, file), предоставляют возможность менять размер виртуального блочного устройства на ходу. Что с одной стороны очень удобно, с другой — гостевые ОС пока к этому совершенно не готовы. Разумеется, все системы поддерживают добавление/удаление на ходу самих блочных устройств.
Функции дедупликации обычно возлагаются на нижележащего провайдера блочных устройств, хотя, например, openvz позволяет использовать copy-on-write режим использования «шаблона контейнера», а XCP позволяет делать цепочку блочных устройств с copy-on-write зависимостями друг от друга. Это с одной стороны замедляет производительность, с другой позволяет существенно экономить место. Разумеется, многие системы позволяют выделять место на диске on-demand (напр.,VMWare, XCP) — файл, соответствующий блочному устройству создаётся как sparsed (или имеет специфичный формат с поддержкой «пропуска» пустых мест).
Доступ к дискам может контролироваться по скорости, по приоритету одного устройства (или виртуальной машины) относительно другой. У VMWare анонсирована замечательная возможность контролировать количество операций ввода-вывода, обеспечивая малую задержку в обслуживании всех гостей, притормаживая самых жрущих из них.
Выделенные дисковые устройства могут быть общими между несколькими гостями (при использовании файловых систем, которые к этому готовы, например, GFS), что позволяет реализовывать с лёгкостью кластеры с общим хранилищем.
Поскольку гипервизор полностью контролирует доступ гостя к носителю, появляется возможность создавать снапшоты дисков (да и самих виртуальных машин), строить дерево снапшотов (кто из кого происходит) с возможностью же с лёгкостью между ними переключаться (обычно в эти снапшоты ещё включается состояние оперативной памяти виртуальной машины).
Аналогично же реализуются бэкапы. Проще всего реализуется бэкап методом копирования диска бэкапируемой системы — это обычный том, файл или LV-раздел, который легко скопировать, в том числе на ходу. Для Windows обычно предоставляется возможность оповестить shadowcopy о необходимости подготовиться к бэкапу.
В некоторых системах предусмотрен механизм сообщения между гостевой системой и гипервизором (точнее, управляющей ОС), позволяющий передавать информацию вне зависимости от работоспособности сети.
Есть экспериментальные наработки (не готовы к продакту) по «самомиграции» гостевой системы.
Идут работы по стандартизации взаимодействия между гипервизорами. Например, предложен XVA формат, как независимый от платформы формат для экспорта/импорта виртуальных машин. Формат VHD мог бы претендовать на универсальность, если бы не несколько несовместимых между собой форматов под одним и тем же расширением.
Большинство систем виртуализации предоставляет возможность «конвертировать» виртуальные машины конкурентов. (однако, я не видел ни одной системы живой миграции, которая бы позволила на ходу мигрировать машину между разными системами, и я даже не видел каких-либо набросков на эту тему).
Большинство гипервизоров предоставляют тот или иной механизм оценки загрузки хоста (показывая текущие значения и историю этих значений). Некоторые предоставляют возможность точного аккаунтинга потреблённых ресурсов в виде абсолютного числа тиков, иопов, мегабайт, сетевых пакетов и т.д. (насколько я знаю, это есть только в Xen, и только в виде недокументированных фич).
Большинство систем последнего поколения позволяют объединять несколько виртуализирующих машин в единую структуру (облако, пул и т.д.), либо предоставляя инфраструктуру для управления нагрузкой, либо предоставляя сразу же готовый сервис управления нагрузкой на каждый сервер в инфраструктуре. Это осуществляется во-первых автоматическим выбором «где запускать следующую машину», во-вторых автоматической миграцией гостей для равномерной загрузки хозяев. Заодно поддерживается и простейший fault-tolerance (high avability), при использовании совместного сетевого хранилища — если один хозяин с пачкой виртуальных машин умер, то виртуальные машины будут запущены на других хозяевах, входящих в инфраструктуру.
Если я упустил какие-то существенные фичи какой-то из систем, говорите, допишу
Исполнение кода
Так как гипервизор полностью контролирует виртуальные машины, он может специфичным образом управлять процессом работы машины.
Различные системы виртуализации предлагают несколько методов исполнения кода (полная эмуляция в список не включена, так как не используется в промышленной виртуализации):
- binary rewriting. Этот подход использует VMWare и Connectix Virtual PC (куплен microsoft) при виртуализации на хосте без аппаратной виртуализации. Гипервизор (виртуализатор) просматривает исполняемый код и помечает инструкции, требующие «виртуализации» брейкпоинтами и эмулирующий (виртуализирующий) только такие инструкции.
- Аппаратная виртуализация. Старинная технология для Alpha и System/360, относительно новая технология для amd64/i386. Вводит подобие ring -1, на котором исполняется гипервизор, управляющий машинами благодаря набору инструкций по виртуализации. Технологии intel и amd слегка различаются, amd предлагает возможность программировать контроллер памяти (на процессоре) для снижения вычислительной нагрузки на виртуализацию (nested pages), интел реализовала это как отдельную технологию EPT. Активно используется в продакте для запуска «чужих систем» в VMWare, Xen HVM, KVM, HyperV
- Паравиртуализация. В этом случае ядро гостевой системы «виртуализируется» на этапе компиляции. userspace практически не меняется. Гостевая система сотрудничает с гипервизором и осуществляет все привилегированные вызовы через гипервизор. Само ядро гостевой системы работает не на ring0, а на ring1, так что взбунтовавшийся гость не сможет помешать гипервизору. Используется для виртуализации opensource систем в xen (PV режим) и openvz (openvz в каком-то смысле уникальный, т.к. «гостевого» ядра там просто нет, он ближе к jail, чем к виртуализации, хотя определённую сильную изоляцию всё-таки обеспечивает).
- Контейнерная виртуализация. Позволяет изолировать множества процессов по «контейнерам», каждый из которых имеет доступ только к процессам из своего контейнера. Находится на тонкой грани между виртуализацией, bsd jail и просто хорошо написанной системой изоляции процессов в ОС друг от друга. Используется общий менеджер памяти, одно и то же ядро
В реальности паравиртуализированные драйвера используются и в HVM и в binary rewriting (их часто называют guest tools), т.к. именно в операциях ввода/вывода паравиртуализация существенно обгоняет по производительности все остальные методы.
Все без исключения гипервизоры умеют выполнять операцию «паузы» (suspend/pause) для виртуальной машины. В этом режиме работа машины приостанавливается, возможно, с сохранением данных памяти на диск и продолжением работы после «восстановления» (resume).
Общепринятой фичей является понятие миграции — переноса виртуальной машины с одного компьютера на другой. Бывает оффлайновой (выключили на одном компьютере, включили на втором) и онлайновой (обычно называется live, т.е. «живая миграция») без выключения. В реальности реализуется с помощью suspend на одной машине и resume на другой c некоторой оптимизацией процесса переноса данных (сначала переносятся данные, потом машина саспендится и переносятся изменившиеся данные с момента начала миграции, после чего запускается новая машина на новом хосте).
Так же в зене обещана (и, вроде, почти доведена до продакта) технология параллельного исполнения одной машины на двух и более хостах (Remus), позволяющая продолжать работу виртуальной машины в случае отказа одного из серверов без перерывов/перезагрузок.
Управление памятью
Классическая модель виртуализации подразумевает выделение фиксированного объёма памяти гостевой машине, изменение возможно только после её «выключения».
Современные системы могут реализовывать функционал ручного или автоматического изменения объёма оперативной памяти для гостевой системы.
Существуют следующие методы управления памятью:
- ballooning. Общепринятый механизм (как минимум, xen и hyperv, вроде, есть у VMWare) Суть идеи проста: специальный модуль в гостевой системе запрашивает память у гостевой системы и отдаёт её гипервизору. В нужный момент он забирает память у гипервизора и отдаёт её гостевой системе. Главная фича — возможность отдавать простаивающую память виртуальной машины обратно.
- Memory hot-plug. Добавление памяти на ходу. Поддерживается в hyper-v в будущих sp для windows server (в релизе пока нет), в xen 4.1 (в linux 2.6.32). Представляет собой добавление памяти, похожее на аппаратный hotplug. Позволяет добавить память «на ходу» в живой сервер без перезагрузки. Альтернативой этому методу является preinflated balloon, когда гипервизор запускает машину с уже «ненулевым» balloon, который можно «сдувать» по мере надобности. memory hot-unplug есть пока что только в linux'е (работает или нет пока не могу сказать). Вероятнее всего, в ближайшее время MS допилит винды и для unplug'а.
- Common memory. Специфично для openvz, память берётся из общего пула, виртуальные машины ограничиваются лишь искусственным лимитом в виде числа, который можно менять на ходу. Самый гибкий механизм, однако, специфичный для openvz и имеющий некоторые неприятные эффекты с учётом памяти.
- Memory compression. Память гостя «сжимается» (алгоритмами компрессии), что в некоторых случаях получить некоторый дополнительный объём. Пенальти: задержка на чтение и запись, нагрузка на процессор со стороны гипервизора.
- Page deduplication. Если страницы памяти совпадают, то они не хранятся дважды, а одна из них делается ссылкой на другую. Хорошо работает в случае запуска нескольких виртуальных машин одновременно с одинаковым комплектом ПО (и одинаковыми версиями). Секции кода совпадают и дедуплицируются. Для данных малоэффективно, картинку портят ещё дисковые кеши, которые у каждой машины свои (и которые норовят занимать всю свободную память). Разумеется, проверка на дубликаты (рассчёт хеша для страницы памяти) операция не бесплатная.
- NUMA — возможность расширять память вируальной машины в объёме большем, чем есть на сервере. Технология сырая и не совсем мейнстримовая (я глубоко не копал, так что подробнее не расскажу)
- memory overcommitment/memory oversell — технология анонсирования виртуальным машинам объёма памяти, большем, чем есть на самом деле (например, обещание 10 виртуальным машинам по 2Гб при наличии всего 16Гб). Технология основывается на идее, что ни одна виртуальная машина в штатном режиме не использует всю память на 100%.
- Общий swap, позволяющий выгружать частично память виртуальных машин на диск.
Периферийные устройства
Некоторые гипервизоры позволяют обеспечить доступ виртуальной машины к реальному оборудованию (причём, разным виртуальным машинам, к разному оборудованию).
Так же они могут обеспечивать эмуляцию оборудования, в том числе и отсутствующего на компьютере. Наиболее важные из устройств — сетевой адаптер и диск рассматриваются отдельно; среди остального: видеоадаптеры (даже с 3D), USB, последовательные/параллельные порты, таймеры, вотчдоги.
Для этого используется одна из следующих технологий:
- эмуляция реально существующих устройств (медленно)
- Прямой доступ к устройству (т.к. «проброс», passthrough) в гостевую машину.
- IOMMU (аппаратная трансляция адресов страниц, используемых для DMA, позволяющая разделять оперативную память, используемую устройствами, между виртуальными машинами). В Intel называется VT-d (не путать с VT aka vanderpool, которая технология для ring -1 в процессоре).
- Создание паравиртуальных устройств, реализующих минимум функционала (собственно, два основных класса — блочные устройства и сетевые разобраны ниже).
Сетевые устройства
Сетевые устройства обычно реализуются либо на третьем, либо на втором уровне абстракции. Создаваемый виртуальный сетевой интерфейс имеет два конца — в виртуальной машине и в гипервизоре/управляющем домене/программе виртуализации. Трафик из гостя передаётся в неизменном виде в хозяина (без всяких танцев с перепосылками, согласованием скоростей и т.д.). А дальше начинаются достаточно существенные сложности.
В настоящий момент, за вычетом систем, эмулирующих сетевой интерфейс на третьем уровне (уровень IP-адресов, например, openvz), все остальные системы предоставляют следующий набор возможностей:
- Бриджинг (2ой уровень) интерфейса с одним или несколькими физическими интерфейсами.
- Создание локальной сети между хостом и гостями (одним или несколькими) без выхода в реальную сеть. Примечательно тем, что в этом случае сеть существует в чисто виртуальном смысле и не имеет привязки к «живым» сетям
- Маршрутизация/NAT трафика гостевой системы. Частный случай вышеупомянутого метода, с включенной для виртуального интерфейса маршрутизацией (и NAT/PAT)
- Энкапсулирование трафика в GRE/VLAN и отправка на аппаратные коммутаторы/маршрутизаторы
В некоторых системах виртуализации разделяют отдельно случай бриджинга сетевого интерфейса виртуальной машины с физическим сетевым интерфейсом и наличие виртуального коммутатора.
Вообще, сеть виртуальных машин доставляет особую головную боль при миграции. Все существующие продакт системы с бриджингом интерфейсов разрешают прозрачную живую миграцию машин только в одном сегменте сети, требует особых ухищрений (fake ARP) для оповещения вышестоящих коммутаторов о смене порта для коммутации трафика.
В настоящий момент разработана довольно интересная система — open vSwitch, позволяющая вынести задачу определения пути прохождения пакета на open-flow контроллер — возможно, она позволит существенно расширить фунционал виртуальных сетей. Впрочем, open flow и vSwitch немного в стороне от темы (и я попробую рассказать о них чуть позже).
Дисковые (блочные) устройства
Это вторая крайне важная веха в работе виртуальных машин. Жёсткий диск (точнее, блочное устройство для хранения информации) является второй, а может даже и первой, по важности компонентой виртуализации. Производительность дисковой подсистемы является критичной для оценки производительности системы виртуализации. Большой оверхед (накладные расходы) на процессор и память будут пережиты более спокойно, чем оверхед на дисковые операции.
Современные системы виртуализации предлагают несколько подходов. Первый — в предоставлении виртуальной машины готовой файловой системы. Накладные расходы при этом стремятся к нулю (специфично для openvz). Второй — в эмуляции блочного устройства (без всяких рюшечек вроде смарта и SCSI команд). Блочное устройство из виртуальной машины привязывается либо к физическому устройству (диску, разделу, логическому тому LVM), либо к файлу (через loopback device или прямой эмуляцией блочных операций «внутри» файла).
Дополнительной возможностью является использование гипервизором сетевого хранилища — в этом случае процесс миграции очень прост: на одном хосте машину паузят, на втором продолжают. Без перекачки каких-либо данных между хостами.
При этом большинство систем, при условии, что блочное устройство нижележащего уровня это поддерживает (LVM, file), предоставляют возможность менять размер виртуального блочного устройства на ходу. Что с одной стороны очень удобно, с другой — гостевые ОС пока к этому совершенно не готовы. Разумеется, все системы поддерживают добавление/удаление на ходу самих блочных устройств.
Функции дедупликации обычно возлагаются на нижележащего провайдера блочных устройств, хотя, например, openvz позволяет использовать copy-on-write режим использования «шаблона контейнера», а XCP позволяет делать цепочку блочных устройств с copy-on-write зависимостями друг от друга. Это с одной стороны замедляет производительность, с другой позволяет существенно экономить место. Разумеется, многие системы позволяют выделять место на диске on-demand (напр.,VMWare, XCP) — файл, соответствующий блочному устройству создаётся как sparsed (или имеет специфичный формат с поддержкой «пропуска» пустых мест).
Доступ к дискам может контролироваться по скорости, по приоритету одного устройства (или виртуальной машины) относительно другой. У VMWare анонсирована замечательная возможность контролировать количество операций ввода-вывода, обеспечивая малую задержку в обслуживании всех гостей, притормаживая самых жрущих из них.
Выделенные дисковые устройства могут быть общими между несколькими гостями (при использовании файловых систем, которые к этому готовы, например, GFS), что позволяет реализовывать с лёгкостью кластеры с общим хранилищем.
Поскольку гипервизор полностью контролирует доступ гостя к носителю, появляется возможность создавать снапшоты дисков (да и самих виртуальных машин), строить дерево снапшотов (кто из кого происходит) с возможностью же с лёгкостью между ними переключаться (обычно в эти снапшоты ещё включается состояние оперативной памяти виртуальной машины).
Аналогично же реализуются бэкапы. Проще всего реализуется бэкап методом копирования диска бэкапируемой системы — это обычный том, файл или LV-раздел, который легко скопировать, в том числе на ходу. Для Windows обычно предоставляется возможность оповестить shadowcopy о необходимости подготовиться к бэкапу.
Взаимодействие между гипервизором и гостем
В некоторых системах предусмотрен механизм сообщения между гостевой системой и гипервизором (точнее, управляющей ОС), позволяющий передавать информацию вне зависимости от работоспособности сети.
Есть экспериментальные наработки (не готовы к продакту) по «самомиграции» гостевой системы.
Кросс-совместимость
Идут работы по стандартизации взаимодействия между гипервизорами. Например, предложен XVA формат, как независимый от платформы формат для экспорта/импорта виртуальных машин. Формат VHD мог бы претендовать на универсальность, если бы не несколько несовместимых между собой форматов под одним и тем же расширением.
Большинство систем виртуализации предоставляет возможность «конвертировать» виртуальные машины конкурентов. (однако, я не видел ни одной системы живой миграции, которая бы позволила на ходу мигрировать машину между разными системами, и я даже не видел каких-либо набросков на эту тему).
Аккаунтинг
Большинство гипервизоров предоставляют тот или иной механизм оценки загрузки хоста (показывая текущие значения и историю этих значений). Некоторые предоставляют возможность точного аккаунтинга потреблённых ресурсов в виде абсолютного числа тиков, иопов, мегабайт, сетевых пакетов и т.д. (насколько я знаю, это есть только в Xen, и только в виде недокументированных фич).
Объединение и управление
Большинство систем последнего поколения позволяют объединять несколько виртуализирующих машин в единую структуру (облако, пул и т.д.), либо предоставляя инфраструктуру для управления нагрузкой, либо предоставляя сразу же готовый сервис управления нагрузкой на каждый сервер в инфраструктуре. Это осуществляется во-первых автоматическим выбором «где запускать следующую машину», во-вторых автоматической миграцией гостей для равномерной загрузки хозяев. Заодно поддерживается и простейший fault-tolerance (high avability), при использовании совместного сетевого хранилища — если один хозяин с пачкой виртуальных машин умер, то виртуальные машины будут запущены на других хозяевах, входящих в инфраструктуру.
Если я упустил какие-то существенные фичи какой-то из систем, говорите, допишу
