Hyper v сколько оперативной памяти
Hyper-V предъявляют определенные требования к оборудованию, а некоторые функции Hyper-V имеют дополнительные требования. Используйте сведения в этой статье, чтобы решить, какие требования должны соответствовать системам, чтобы можно было использовать Hyper-V в соответствии с планом. затем просмотрите каталог сервера Windows. помните, что требования для Hyper-V превышают общие минимальные требования для Windows Server 2016, так как для среды виртуализации требуются дополнительные вычислительные ресурсы.
Если вы уже используете Hyper-V, скорее всего, вы можете использовать имеющееся оборудование. общие требования к оборудованию значительно не изменились Windows Server 2012 R2. Но вам потребуется более новое оборудование для использования экранированных виртуальных машин или назначения дискретных устройств. Эти функции полагаются на конкретную аппаратную поддержку, как описано ниже. В отличие от этого, основное различие в оборудовании заключается в том, что вместо него требуется преобразование адресов второго уровня (SLAT).
Подробные сведения о максимальной поддерживаемые конфигурации для Hyper-V, например количество виртуальные машины в разделе Планирование масштабируемость Hyper-V в Windows Server 2016. список операционных систем, которые можно запустить на виртуальных машинах, см. в статье поддерживаемые Windows гостевые операционные системы для Hyper-V на Windows Server.
Требования к оборудованию
Хотя в этом документе не приводится полный список оборудования, совместимого с Hyper-V, укажем следующие обязательные требования:
- 64-разрядный процессор с поддержкой преобразования адресов второго уровня (SLAT).
- Поддержка расширения режима мониторинга виртуальной машины (технология VT-x на компьютерах с процессорами Intel).
- Не менее 4 ГБ оперативной памяти. Так как виртуальные машины и узел Hyper-V используют память совместно, необходимо обеспечить достаточный объем памяти для обработки предполагаемой рабочей нагрузки на виртуальной машине.
В BIOS системы необходимо включить следующие компоненты.
- Virtualization Technology (Технология виртуализации) — может иметь другое название в зависимости от производителя системной платы.
- Предотвращение исполнения данных на основе оборудования.
Отдельное назначение устройств
Требования к узлу аналогичны существующим требованиям к функции SR-IOV в Hyper-V.
Процессор должен иметь либо расширенную таблицу страниц Intel (EPT), либо таблицу вложенных страниц AMD (НПТ).
Набор микросхем должен иметь следующие компоненты:
Перераспределение прерываний. Технология Intel VT-d с возможностью повторного сопоставления прерываний (VT-D2) или любой другой версией модуля управления памятью ввода-вывода AMD (ввод-вывод ММУ).
Повторное сопоставление DMA. Технология Intel VT-d с недействительными в очереди или любыми ММУами AMD ввода-вывода.
Службы контроля доступа (ACS) на корневых портах PCI Express.
таблицы встроенного по должны предоставлять мму ввода-вывода для гипервизора Windows. Обратите внимание, что эта функция может быть отключена в UEFI или BIOS. Инструкции см. в документации по оборудованию или обратитесь к изготовителю оборудования.
Устройствам требуется GPU или энергонезависимый объем памяти (NVMe). Для GPU только некоторые устройства поддерживают дискретное назначение устройств. Чтобы проверить, ознакомьтесь с документацией по оборудованию или обратитесь к изготовителю оборудования. Дополнительные сведения об этой функции, включая способы ее использования и рекомендации, см. в блоге по виртуализации в разделе Post "дискретное назначение устройств--описание и фон".
Проверка совместимости оборудования
После проверки требований к операционной системе и оборудованию, описанных выше, проверьте совместимость оборудования в Windows, открыв сеанс PowerShell или окно командной строки (cmd.exe). Для этого введите systeminfo, а затем просмотрите раздел требований к Hyper-V. Если все указанные требования Hyper-V имеют значение Yes, ваша система поддерживает роль Hyper-V. Если хотя бы один элемент имеет значение No, проверьте указанные выше требования и внесите необходимые изменения.
Проверка требований Hyper-V
откройте Windows PowerShell или командную строку и введите:
Перейдите к разделу "требования Hyper-V", чтобы просмотреть отчет.
Требования к операционной системе
Роль Hyper-V можно включить в таких версиях Windows 10:
- Windows 10 Корпоративная
- Windows 10 Pro
- Windows 10 для образовательных учреждений
Роль Hyper-V невозможно установить в следующих версиях:
- Windows 10 Домашняя
- Windows 10 Mobile
- Windows 10 Mobile Корпоративная
ОС Windows 10 Домашняя можно обновить до версии Windows 10 Pro. Для этого перейдите в раздел Параметры>Обновление и безопасность>Активация. Здесь вы можете посетить Магазин Windows и приобрести обновление.
Общие требования
Независимо от возможностей Hyper-V, которые вы хотите использовать, вам потребуется:
64-разрядный процессор с преобразованием адресов второго уровня (SLAT). чтобы установить компоненты виртуализации Hyper-V, такие как Windows гипервизор, процессор должен иметь SLAT. Однако не требуется устанавливать такие средства управления Hyper-V, как подключение к виртуальной машине (VMConnect), диспетчер Hyper-V и командлеты Hyper-V для Windows PowerShell. См. раздел "как проверить требования Hyper-V" ниже, чтобы узнать, имеет ли процессор SLAT.
Расширения режима мониторинга виртуальной машины
Достаточный объем памяти — план не менее 4 ГБ ОЗУ. Больше памяти лучше. Вам потребуется достаточно памяти для узла и всех виртуальных машин, которые будут выполняться одновременно.
Поддержка виртуализации включена в BIOS или UEFI:
Виртуализация с использованием оборудования. Эта возможность доступна в процессорах, которые включают в себя процессоры с поддержкой технологии виртуализации Intel (Intel VT) или AMD (AMD-V).
Должна быть доступна и включена технология аппаратного предотвращения выполнения данных (DEP). Для систем Intel это бит XD (выполнение отключения бита). Для систем AMD это бит NX (без бита исполнения).
Правильное изменение размера памяти для дочерних секций
Размер памяти виртуальной машины следует масштабировать как обычно для серверных приложений на физическом компьютере. Его необходимо изменить, чтобы правильно обрабатывалась ожидаемая нагрузка в обычном и пиковом времени, так как недостаток памяти может значительно увеличить время ответа, а также использование процессора или операций ввода-вывода.
можно включить динамическая память, чтобы разрешить Windows динамически изменять размер памяти виртуальной машины. В случае динамическая память, если приложения на виртуальной машине испытывают проблемы с большим объемом выделения памяти, можно увеличить размер файла подкачки для виртуальной машины, чтобы обеспечить временное резервное копирование, а динамическая память реагировать на нехватку памяти.
Дополнительные сведения о динамическая память см. в разделе обзор Динамическая память Hyper-v и в статье Динамическая память по настройке Hyper-v.
при выполнении Windows в дочернем разделе можно использовать следующие счетчики производительности в дочернем разделе, чтобы определить, испытывает ли дочерний раздел недостаток памяти и, скорее всего, будет работать лучше с более высоким размером памяти виртуальной машины.
Счетчик производительности | Рекомендуемое пороговое значение |
---|---|
Память — Байты резерва резервного кэша | Сумма резервных байт в резервном кэше, а также свободных и нулевых байт списка страниц должны составлять 200 МБ или больше в системах с 1 ГБ и 300 МБ или больше в системах с 2 ГБ или более видимой ОЗУ. |
Память — байты свободной страницы без & списка | Сумма резервных байт в резервном кэше, а также свободных и нулевых байт списка страниц должны составлять 200 МБ или больше в системах с 1 ГБ и 300 МБ или больше в системах с 2 ГБ или более видимой ОЗУ. |
Память — ввод страниц/с | Среднее значение в 1-часовом периоде меньше 10. |
Окончательная проверка
Если все требования к ОС, оборудованию и совместимости соблюдены, сведения о Hyper-V отобразятся на панели управления в окне "Включение или отключение компонентов Windows". Будет доступно два варианта.
- Платформа Hyper-V.
- Средства управления Hyper-V
Гипервизор делает виртуальную машину гостевой физической памяти для изоляции виртуальных машин друг от друга и предоставляет непрерывное (нулевое) пространство памяти для каждой гостевой операционной системы, как и в случае невиртуализованных систем.
Требования к конкретным функциям
Ниже приведены требования для дискретного назначения устройств и экранированных виртуальных машин. описание этих функций см. в статье новые возможности Hyper-V на Windows Server.
Правильное изменение размера памяти для корневого раздела
Корневой раздел должен иметь достаточно памяти для предоставления таких служб, как виртуализация ввода-вывода, моментальный снимок виртуальной машины и управление для поддержки дочерних секций.
Hyper-V в Windows Server 2016 отслеживает работоспособность операционной системы управления корневого раздела в среде выполнения, чтобы определить, сколько памяти может быть безопасно выделено дочерним секциям, сохраняя при этом высокий уровень производительности и надежности корневого раздела.
Прежде, чем строить инфраструктуру на базе виртуализации, и, тем более – вводить ее в промышленную эксплуатацию, необходимо позаботиться о том, чтобы ресурсы системы использовались наиболее эффективно, и производительность была максимальной. В этом цикле статей я дам рекомендации о том, как оптимизировать систему по производительности – как со стороны хоста, так и со стороны виртуальных машин.
Начнем с хоста
- Процессор
- Память
- Дисковая подсистема
- Сетевая подсистема
Процессор – сердце компьютера
- Сколько ставить процессоров?
- Сколько нужно ядер?
- Их скоростные характеристики?
- Требуется больше лицензий на ПО – как на сами ОС, так и на ПО управления (SCVMM, SCCM, SCOM, etc.)
- Возрастают затраты на администрирование – три сервера вместо одного
- Три сервера потребляют больше энергии, а значит – выделяют больше тепла, и занимают больше места в стойке, чем один сервер, пусть и более мощный.
- Hyper-V Hypervisor Virtual Processor, % Total Run Time — этот счетчик отображает загрузку виртуальных процессоров. Можно задать отображение суммарной загрузки всех процессоров для запущенных виртуальных машин, а можно выбрать конкретный виртуальный процессор конкретной виртуальной машины.
- Hyper-V Hypervisor Root Virtual Processor, % Total Run Time – а этот счетчик показывает загрузку выбранных логических процессоров задачами, не связанными с Hyper-V.
Памяти много не бывает
- Сколько виртуальных машин будет запущено, и сколько памяти им понадобится? Объем памяти, необходимый каждой виртуальной машине зависит от задач, которые она будет выполнять. Подход тот же самый, что и для обычных серверов, но память виртуальным машинам можно выделять более гибко – не 1024 Мб, а, к примеру, 900 Мб.
- Хостовой ОС тоже нужна память. Рекомендуется оставлять как минимум 512 Мб свободной памяти на нужды гипервизора и самой хостовой ОС. Если объем свободной памяти опустится ниже 32 Мб – система не даст запустить больше ни одной виртуальной машины, пока память не освободится. Кроме этого, в хостовой ОС могут выполняться какие-то другие задачи, помимо виртуализации. Хотя это и крайне не рекомендуется, но факт все же имеет место быть, и это необходимо учитывать.
- Другие виртуальные машины (для сценариев Live Migration). Если инфраструктура планируется на базе отказоустойчивого кластера, то необходимо на каждом из хостов предусмотреть дополнительные объемы памяти. Дело в том, что виртуальные машины могут перемещаться с одного хоста на другой в случае ручного перемещения (Live Migration), или же в случае отказа одного из хостов. Если на хосте будет недостаточно памяти для запуска перемещаемых виртуальных машин – то они попросту не смогут на нем запуститься. Поэтому на этапе проектирования надо предусмотреть «неприкосновенный запас» в размере 50-100% от необходимого объема памяти. Возможно, ситуация немного улучшится с выходом Windows Server 2008 R2 SP1, в который входят технологии динамического распределения памяти, но точно я смогу сказать лишь тогда, когда сам это протестирую.
Жесткие диски: сколько их надо?
- RAID 0 – «массив с чередованием». Информация пишется блоками («страйпами») одновременно на несколько дисков. Благодаря этому чтение и запись больших объемов информации происходит значительно быстрее, чем с одного диска, и тем быстрее, чем больше дисков в массиве. Но есть один большой недостаток: низкая надежность. Выход из строя любого из дисков приведет к полной потере информации. Поэтому на практике RAID 0 используется достаточно редко. Один из примеров – промежуточное хранилище резервных копий в модели «Disk-to-disk-to-tape», когда надежность не так важна, как быстродействие.
- RAID 1 – «зеркалирование». При такой модели информация записывается одновременно на несколько дисков, причем содержимое всех дисков абсолютно идентично. Скорость записи и чтения не выше, чем для одиночного диска, но намного выше надежность: выход из строя одного диска не приведет к потере информации. Недостаток лишь один: высокая стоимость – там, где хватает и одного диска – приходится ставить два и более. Смысл имеет в тех случаях, когда надежность имеет решающее значение.
- RAID 4 и RAID 5 – «чередование с контролем четности». Предстваляет собой некую «золотую середину» между RAID 0 и RAID 1. Смысл состоит в том, что информация хранится на дисках как и в случае RAID 0 — блоками с чередованием, но помимо этого вычисляются контрольные суммы хранимых данных. В случае отказа одного из дисков – недостающие данные автоматически вычисляются по имеющимся данным и контрольным суммам. Разумеется, это приводит к снижению производительности, но в то же время данные не теряются, и при замене сбойного диска вся информация восстанавливается (этот процесс называется перестройкой массива). Потеря данных произойдет только при отказе двух и более дисков. Такие массивы отличаются тем, что скорость записи у них значительно ниже, чем скорость чтения. Происходит так из-за того, что при записи блока данных происходит вычисление контрольной суммы и запись ее на диск. RAID 4 и RAID 5 отличаются тем, что в RAID 4 контрольные суммы записываются на отдельный диск, а в RAID 5 – хранятся на всех дисках массива вместе с данными. В любом случае, для организации такого массива нужно N дисков для хранения данных плюс один диск. В отличие от RAID 1 и RAID 10, где количество дисков просто удваивается.
- RAID 6 – он же RAID DP, double-parity, двойная четность. То же самое, что и RAID 5, но контрольные суммы вычисляются два раза, с использованием различных алгоритмов. Хотя дисков здесь требуется уже не N+1, как с RAID 5, а N+2, зато такой массив может пережить даже одновременный отказ двух дисков. Встречается относительно редко, как правило – в системах хранения данных Enterprise-уровня, к примеру – NetApp.
- RAID 10 – «гибрид» RAID 0 и RAID 1. Представляет собой RAID 0 из нескольких RAID 1 (и тогда называется RAID 0+1) или наоборот – RAID 1 из нескольких RAID 0 (RAID 1+0). Отличается наивысшей производительностью, как по записи, так и по чтению, но в то же время отличается и высокой стоимостью – так как дисков требуется в 2 раза больше, чем необходимо для хранения данных.
- Physical Disk, % Disk Read Time
- Physical Disk, % Disk Write Time
- Physical Disk, % Idle Time
- Physical Disk, Avg. Disk Read Queue Length
- Physical Disk, Avg. Disk Write Queue Length
Сетевая подсистема
- Сколько виртуальных машин будет запущено одновременно, и какова будет нагрузка на сеть?
- Какова пропускная способность сети?
- Используются ли системы хранения данных с интерфейсом iSCSI?
- Есть ли у сервера аппаратные средства удаленного управления, не зависимые от установленной ОС (к примеру – HP iLO или Dell DRAC)?
На уровне хоста
Для серверов, у которых нет аппаратных средств удаленного управления рекомендуется один из сетевых интерфейсов оставлять незадействованным в виртуальных сетях, исключительно для задач управления. Это сильно снизит риск ситуации, когда при чрезмерной утилизации или же из-за неправильных настроек сетевого интерфейса пропадает возможность удаленного управления сервером. Сделать это можно либо на этапе инсталляции роли Hyper-V, сняв галочку с одного из сетевых интерфейсов, либо же после инсталляции – удалив виртуальную сеть, привязанную к сетевому интерфейсу, который будет использоваться для управления.
Кроме этого, на уровне хоста прямо таки необходимо установить как можно более «свежие» драйверы для сетевых адаптеров. Это нужно для того, чтобы воспользоваться специальными функциями сетевых адаптеров – VLAN, Teaming, TCP Offloading, VMQ (при условии, что сами сетевые адаптеры это поддерживают – как правило, это специализированные серверные сетевые адаптеры).
Сетевые нагрузки
iSCSI
Если планируется использовать системы хранения данных с интерфейсом iSCSI – крайне рекомендуется выделить для работы iSCSI отдельный сетевой интерфейс, а то и два – для работы MPIO. Если LUN’ы будут монтироваться в хостовой ОС – то нужно просто оставить один или два интерфейса не привязанными к виртуальным сетям. Если же iSCSI-инициаторы будут работать внутри виртуальных машин – для них нужно создать одну или две отдельных виртуальных сети, которые будут использоваться исключительно для трафика iSCSI.
VLAN-тегирование
VLAN-тегирование (IEEE 802.1q) означает «маркировку» сетевых пакетов специальным маркером (тегом), благодаря которому пакет может быть ассоциирован с определенной виртуальной сетью (VLAN). При этом хосты, принадлежащие к разным VLAN, будут находиться в разных широковещательных доменах, хотя и подключаться физически к одному и тому же оборудованию. Виртуальные сетевые адаптеры в Hyper-V так же поддерживают тегирование VLAN. Для этого нужно зайти в свойства виртуального адаптера в настройках виртуальной машины и прописать там соответствующий VLAN ID.
Активное оборудование
Рекомендации для хостовой ОС
- Меньший объем обновлений
- Меньшая поверхность атаки для потенциальных злоумышленников
- Меньшая нагрузка на процессор и память в родительской партиции
Запуск других приложений в хостовой ОС
Запуск в гостевой ОС сторонних (не имеющих отношения к Hyper-V) приложений, а так же установка других серверных ролей помимо Hyper-V может привести к сильному падению производительности, а так же к снижению стабильности. Дело в том, что из-за особенностей архитектуры Hyper-V, все взаимодействие виртуальных машин с устройствами проходит через родительскую партицию. Поэтому высокие нагрузки или «падение в синий экран» в родительской партиции обязательно приведут к падению производительности или просто к «падению» всех запущенных виртуальных машин. Сюда же можно (и нужно) отнести антивирусное ПО. Нужно ли оно вообще на хосте, который не будет заниматься ничем, кроме, собственно, виртуализации – это, конечно, тот еще вопрос. Тем не менее, если антивирус все же установлен – первое, что необходимо сделать – исключить из списка проверки все папки, где могут находиться файлы виртуальных машин. В противном случае, при сканировании может замедлиться производительность, а если в каком-нибудь VHD-файле обнаружится что-то похожее на вирус – то при попытке лечения антивирусный пакет может испортить сам VHD. Подобные случаи наблюдались и с базами MS Exchange, и потому первая рекомендация – не ставить вообще на серверах Exchange файловые антивирусы, а если и ставить – то добавить папки с базами в исключения.
Рекомендации для виртуальных машин
Шаги, которые необходимы предпринять для повышения производительности самих виртуальных машин – зависят от приложений, которые будут на них выполняться. У Microsoft имеются рекомендации (best practices) для каждого из приложений – Exchange, SQL Server, IIS, и других. Аналогичные рекомендации существуют для ПО других вендоров. Здесь я дам лишь общие рекомендации, не зависящие от конкретного ПО.
Здесь будет рассказано, почему нужно устанавливать Integration Services в гостевой ОС, как упростить развертывание новых виртуальных машин с помощью библиотеки VHD, и как поддерживать эти VHD в актуальном состоянии с выпуском новых патчей.
Сервисы интеграции
- Windows 2000 Server SP4
- Windows Server 2003 SP2
- Windows Server 2008
- Windows XP SP2, SP3
- Windows Vista SP1
- SUSE Linux Enterprise Server 10 SP3 / 11
- Red Hat Enterprise Linux 5.2 – 5.5
- IDE-контроллер – заменяет собой эмулируемый IDE-контроллер, что повышает скорость доступа к дискам
- SCSI-контроллер – является полностью синтетическим устройством и требует для работы обязательной установки интеграционных сервисов. К каждому SCSI-контроллеру можно подключить до 64 дисков, самих контроллеров может быть до 4 на каждую виртуальную машину.
- Сетевой адаптер – имеет более высокую производительность, чем эмулируемый (Legacy Network Adapter), и поддерживает особые функции, такие, как VMQ.
- Видео и мышь – повышают удобство управления виртуальной машиной через ее консоль.
- Operating System Shutdown – возможность корректного завершения работы гостевой ОС без логина в нее. Аналогично нажатию кнопки Power на корпусе ATX.
- Time Synchronization – ясно из названия – синхронизация системного времени между хостовой и гостевой ОС.
- Data Exchange – обмен ключами реестра между гостевой и хостовой ОС. Таким образом, к примеру, гостевая ОС может определить имя хоста, на котором она запущена. Эта возможность доступна только для гостевых ОС семейства MS Windows.
- Heartbeat – специальный сервис, периодически отправляющий специальные сигналы, означающие, что с виртуальной машиной все в порядке. Если гостевая ОС по какой-то причине, например, зависнет – она перестанет отправлять Heartbeat, и это может служить сигналом, к примеру, для автоматической перезагрузки.
- Online Backup – представляет из себя VSS Writer, позволяющий в любой момент получить консистентную резервную копию данных виртуальной машины. При запуске резервного копирования через VSS приложения, запущенные на виртуальной машине автоматически сбрасывают данные на диск, и потому бэкап получается консистентным.
Sysprep: создаем мастер-образ
- Создать новую виртуальную машину
- Произвести установку ОС, сервисов интеграции, всех доступных обновлений системы и дополнительного ПО, если таковое необходимо
- Подготовить установленную ОС с помощью утилиты Sysprep, которая удалит информацию о пользователе, ключе продукта и уникальный идентификатор (SID).
Оффлайн-установка обновлений
- Виртуальная машина разворачивается на специальном, выбираемом с помощью SCVMM, хосте – так называемый maintenance host.
- Виртуальная машина запускается, и на ней производится установка всех необходимых обновлений.
- Виртуальная машина останавливается, и VHD-файл возвращается в библиотеку уже с установленными обновлениями.
Заключение
Я дал некоторые рекомендации по настройке хостов и самих виртуальных машин, позволяющей достичь оптимального уровня производительности. Буду надеяться, что для кого-то эта информация окажется полезной.
Всем занять свои места! Задраить люки! Приготовиться к погружению!
В этой статье я попытаюсь рассказать об архитектуре Hyper-V еще подробнее, чем я сделал это ранее.
Что же такое – Hyper-V?
Hyper-V – это одна из технологий виртуализации серверов, позволяющая запускать на одном физическом сервере множество виртуальных ОС. Эти ОС именуются «гостевыми», а ОС, установленная на физическом сервере – «хостовой». Каждая гостевая операционная система запускается в своем изолированном окружении, и «думает», что работает на отдельном компьютере. О существовании других гостевых ОС и хостовой ОС они «не знают».
Эти изолированные окружения именуются «виртуальными машинами» (или сокращенно — ВМ). Виртуальные машины реализуются программно, и предоставляют гостевой ОС и приложениям доступ к аппаратным ресурсам сервера посредством гипервизора и виртуальных устройств. Как уже было сказано, гостевая ОС ведет себя так, как будто полностью контролирует физический сервер, и не имеет представления о существовании других виртуальных машин. Так же эти виртуальные окружения могут именоваться «партициями» (не путать с разделами на жестких дисках).
Впервые появившись в составе Windows Server 2008, ныне Hyper-V существует в виде самостоятельного продукта Hyper-V Server (де-факто являющегося сильно урезанной Windows Server 2008), и в новой версии – R2 – вышедшего на рынок систем виртуализации Enterprise-класса. Версия R2 поддерживает некоторые новые функции, и речь в статье пойдет именно об этой версии.
Гипервизор
Термин «гипервизор» уходит корнями в 1972 год, когда компания IBM реализовала виртуализацию в своих мэйнфреймах System/370. Это стало прорывом в ИТ, поскольку позволило обойти архитектурные ограничения и высокую цену использования мэйнфреймов.
Гипервизор – это платформа виртуализации, позволяющая запускать на одном физическом компьютере несколько операционных систем. Именно гипервизор предоставляет изолированное окружение для каждой виртуальной машины, и именно он предоставляет гостевым ОС доступ к аппаратному обеспечению компьютера.
Гипервизоры можно разделить на два типа по способу запуска (на «голом железе» или внутри ОС) и на два типа по архитектуре (монолитная и микроядерная).
Гипервизор 1 рода
Гипервизор 1 типа запускается непосредственно на физическом «железе» и управляет им самостоятельно. Гостевые ОС, запущенные внутри виртуальных машин, располагаются уровнем выше, как показано на рис.1.
Рис.1 Гипервизор 1 рода запускается на «голом железе».
- Microsoft Hyper-V
- VMware ESX Server
- Citrix XenServer
Гипервизор 2 рода
В отличие от 1 рода, гипервизор 2 рода запускается внутри хостовой ОС (см. рис.2).
Рис.2 Гипервизор 2 рода запускается внутри гостевых ОС
Виртуальные машины при этом запускаются в пользовательском пространстве хостовой ОС, что не самым лучшим образом сказывается на производительности.
Примерами гипервизоров 2 рода служат MS Virtual Server и VMware Server, а так же продукты десктопной виртуализации – MS VirtualPC и VMware Workstation.
Монолитный гипервизор
Гипервизоры монолитной архитектуры включают драйверы аппаратных устройств в свой код (см. рис. 3).
Рис. 3. Монолитная архитектура
- Более высокую (теоретически) производительность из-за нахождения драйверов в пространстве гипервизора
- Более высокую надежность, так как сбои в работе управляющей ОС (в терминах VMware – «Service Console») не приведет к сбою всех запущенных виртуальных машин.
- Поддерживается только то оборудование, драйверы на которое имеются в гипервизоре. Из-за этого вендор гипервизора должен тесно сотрудничать с вендорами оборудования, чтобы драйвера для работы всего нового оборудования с гипервизором вовремя писались и добавлялись в код гипервизора. По той же причине при переходе на новую аппаратную платформу может понадобиться переход на другую версию гипервизора, и наоборот – при переходе на новую версию гипервизора может понадобиться смена аппаратной платформы, поскольку старое оборудование уже не поддерживается.
- Потенциально более низкая безопасность – из-за включения в гипервизор стороннего кода в виде драйверов устройств. Поскольку код драйверов выполняется в пространстве гипервизора, существует теоретическая возможность воспользоваться уязвимостью в коде и получить контроль как над хостовой ОС, так и над всеми гостевыми.
Микроядерная архитектура
При микроядерной архитектуре драйверы устройств работают внутри хостовой ОС.
Хостовая ОС в этом случае запускается в таком же виртуальном окружении, как и все ВМ, и именуется «родительской партицией». Все остальные окружения, соответственно – «дочерние». Единственная разница между родительской и дочерними партициями состоит в том, что только родительская партиция имеет непосредственный доступ к оборудованию сервера. Выделением памяти же и планировкой процессорного времени занимается сам гипервизор.
Рис. 4. Микроядерная архитектура
- Не требуются драйвера, «заточенные» под гипервизор. Гипервизор микроядерной архитектуры совместим с любым оборудованием, имеющим драйверы для ОС родительской партиции.
- Поскольку драйверы выполняются внутри родительской партиции – у гипервизора остается больше времени на более важные задачи – управление памятью и работу планировщика.
- Более высокая безопасность. Гипервизор не содержит постороннего кода, соответственно и возможностей для атаки на него становится меньше.
Архитектура Hyper-V
На рис.5 показаны основные элементы архитектуры Hyper-V.
Рис.5 Архитектура Hyper-V
Как видно из рисунка, гипервизор работает на следующем уровне после железа – что характерно для гипервизоров 1 рода. Уровнем выше гипервизора работают родительская и дочерние партиции. Партиции в данном случае – это области изоляции, внутри которых работают операционные системы. Не нужно путать их, к примеру, с разделами на жестком диске. В родительской партиции запускается хостовая ОС (Windows Server 2008 R2) и стек виртуализации. Так же именно из родительской партиции происходит управление внешними устройствами, а так же дочерними партициями. Дочерние же партиции, как легко догадаться – создаются из родительской партиции и предназначены для запуска гостевых ОС. Все партиции связаны с гипервизором через интерфейс гипервызовов, предоставляющий операционным системам специальный API. Если кого-то из разработчиков интересуют подробности API гипервызовов — информация имеется в MSDN.
Родительская партиция
- Создание, удаление и управление дочерними партициями, в том числе и удаленное, посредством WMI-провайдера.
- Управление доступом к аппаратным устройствам, за исключением выделения процессорного времени и памяти – этим занимается гипервизор.
- Управление питанием и обработка аппаратных ошибок, если таковые возникают.
Рис.6 Компоненты родительской партиции Hyper-V
Стек виртуализации
- Служба управления виртуальными машинами (VMMS)
- Рабочие процессы виртуальных машин (VMWP)
- Виртуальные устройства
- Драйвер виртуальной инфраструктуры (VID)
- Библиотека интерфейсов гипервизора
- Управление состоянием виртуальных машин (включено/выключено)
- Добавление/удаление виртуальных устройств
- Управление моментальными снимками
- Starting
- Active
- Not Active
- Taking Snapshot
- Applying Snapshot
- Deleting Snapshot
- Merging Disk
Рабочий процесс виртуальной машины (VMWP)
Для управления виртуальной машиной из родительской партиции запускается особый процесс – рабочий процесс виртуальной машины (VMWP). Процесс этот работает на уровне пользователя. Для каждой запущенной виртуальной машины служба VMMS запускает отдельный рабочий процесс. Это позволяет изолировать виртуальные машины друг от друга. Для повышения безопасности, рабочие процессы запускаются под встроенным пользовательским аккаунтом Network Service.
Процесс VMWP используется для управления соответствующей виртуальной машиной. В его задачи входит:
Создание, конфигурация и запуск виртуальной машины
Пауза и продолжение работы (Pause/Resume)
Сохранение и восстановление состояния (Save/Restore State)
Создание моментальных снимков (снапшотов)
Кроме того, именно рабочий процесс эмулирует виртуальную материнскую плату (VMB), которая используется для предоставления памяти гостевой ОС, управления прерываниями и виртуальными устройствами.
Виртуальные устройства
- Эмулируемые устройства – эмулируют определенные аппаратные устройства, такие, к примеру, как видеоадаптер VESA. Эмулируемых устройств достаточно много, к примеру: BIOS, DMA, APIC, шины ISA и PCI, контроллеры прерываний, таймеры, управление питанием, контроллеры последовательных портов, системный динамик, контроллер PS/2 клавиатуры и мыши, эмулируемый (Legacy) Ethernet-адаптер (DEC/Intel 21140), FDD, IDE-контроллер и видеоадаптер VESA/VGA. Именно поэтому для загрузки гостевой ОС может использоваться только виртуальный IDE-контроллер, а не SCSI, который является синтетическим устройством.
- Синтетические устройства – не эмулируют реально существующие в природе железки. Примерами служат синтетический видеоадаптер, устройства взаимодействия с человеком (HID), сетевой адаптер, SCSI-контроллер, синтетический контроллер прерывания и контроллер памяти. Синтетические устройства могут использоваться только при условии установки компонент интеграции в гостевой ОС. Синтетические устройства обращаются к аппаратным устройствам сервера посредством провайдеров служб виртуализации, работающих в родительской партиции. Обращение идет через виртуальную шину VMBus, что намного быстрее, чем эмуляция физических устройств.
Драйвер виртуальной инфраструктуры (VID)
Драйвер виртуальной инфраструктуры (vid.sys) работает на уровне ядра и осуществляет управление партициями, виртуальными процессорами и памятью. Так же этот драйвер является промежуточным звеном между гипервизором и компонентами стека виртуализации уровня пользователя.
Библиотека интерфейса гипервизора
Библиотека интерфейса гипервизора (WinHv.sys) – это DLL уровня ядра, которая загружается как в хостовой, так и в гостевых ОС, при условии установки компонент интеграции. Эта библиотека предоставляет интерфейс гипервызовов, использующийся для взаимодействия ОС и гипервизора.
Провайдеры служб виртуализации (VSP)
Провайдеры служб виртуализации работают в родительской партиции и предоставляют гостевым ОС доступ к аппаратным устройствам через клиент служб виртуализации (VSC). Связь между VSP и VSC осуществляется через виртуальную шину VMBus.
Шина виртуальных машин (VMBus)
Назначение VMBus состоит в предоставлении высокоскоростного доступа между родительской и дочерними партициями, в то время как остальные способы доступа значительно медленнее из-за высоких накладных расходах при эмуляции устройств.
Если гостевая ОС не поддерживает работу интеграционных компонент – приходится использовать эмуляцию устройств. Это означает, что гипервизору приходится перехватывать вызовы гостевых ОС и перенаправлять их к эмулируемым устройствам, которые, напоминаю, эмулируются рабочим процессом виртуальной машины. Поскольку рабочий процесс запускается в пространстве пользователя, использование эмулируемых устройств приводит к значительному снижению производительности по сравнению с использованием VMBus. Именно поэтому рекомендуется устанавливать компоненты интеграции сразу же после установки гостевой ОС.
Как уже было сказано, при использовании VMBus взаимодействие между хостовой и гостевой ОС происходит по клиент-серверной модели. В родительской партиции запущены провайдеры служб виртуализации (VSP), которые являются серверной частью, а в дочерних партициях – клиентская часть – VSC. VSC перенаправляет запросы гостевой ОС через VMBus к VSP в родительской партиции, а сам VSP переадресовывает запрос драйверу устройства. Этот процесс взаимодействия абсолютно прозрачен для гостевой ОС.
Дочерние партиции
Вернемся к нашему рисунку с архитектурой Hyper-V, только немного сократим его, поскольку нас интересуют лишь дочерние партиции.
Рис. 7 Дочерние партиции
- ОС Windows, с установленными компонентами интеграции (в нашем случае – Windows 7)
- ОС не из семейства Windows, но поддерживающая компоненты интеграции (Red Hat Enterprise Linux в нашем случае)
- ОС, не поддерживающие компоненты интеграции (например, FreeBSD).
ОС Windows с установленными компонентами интеграции
- Клиенты служб виртуализации. VSC представляют собой синтетические устройства, позволяющие осуществлять доступ к физическим устройствам посредством VMBus через VSP. VSC появляются в системе только после установки компонент интеграции, и позволяют использовать синтетические устройства. Без установки интеграционных компонент гостевая ОС может использовать только эмулируемые устройства. ОС Windows 7 и Windows Server 2008 R2 включает в себя компоненты интеграции, так что их не нужно устанавливать дополнительно.
- Улучшения. Под этим имеются в виду модификации в коде ОС чтобы обеспечить работу ОС с гипервизором и тем самым повысить эффективность ее работы в виртуальной среде. Эти модификации касаются дисковой, сетевой, графической подсистем и подсистемы ввода-вывода. Windows Server 2008 R2 и Windows 7 уже содержат в себе необходимые модификации, на другие поддерживаемые ОС для этого необходимо установить компоненты интеграции.
- Heartbeat – помогает определить, отвечает ли дочерняя партиция на запросы из родительской.
- Обмен ключами реестра – позволяет обмениваться ключами реестра между дочерней и родительской партицией.
- Синхронизация времени между хостовой и гостевой ОС
- Завершение работы гостевой ОС
- Служба теневого копирования томов (VSS), позволяющая получать консистентные резервные копии.
ОС не из семейства Windows, но поддерживающая компоненты интеграции
Существуют так же ОС, не относящиеся к семейству Windows, но поддерживающие компоненты интеграции.На данный момент – это только SUSE Linux Enterprise Server и Red Hat Enterprise Linux. Такие ОС при установке компонент интеграции используют VSC сторонних разработчиков для взаимодействия с VSC по VMBus и доступа к оборудованию. Компоненты интеграции для Linux разработаны компанией Microsoft совместно с Citrix и доступны для загрузки в Microsoft Download Center. Поскольку компоненты интеграции для Linux были выпущены под лицензией GPL v2, ведутся работы по интеграции их в ядро Linux через Linux Driver Project, что позволит значительно расширить список поддерживаемых гостевых ОС.
Вместо заключения
На этом я, пожалуй, закончу свою вторую статью, посвященную архитектуре Hyper-V. Предыдущая статья вызвала у некоторых читателей вопросы, и надеюсь, что теперь я на них ответил.
Надеюсь, что чтение не было слишком скучным. Я достаточно часто использовал «академический язык», но это было необходимо, поскольку тематика статьи предполагает очень большой объем теории и практически нуль целых нуль десятых практики.
Выражаю огромную благодарность Mitch Tulloch и Microsoft Virtualization Team. На основе их книги Understanding Microsoft Virtualization Solutions и была подготовлена статья.
Экранированные виртуальные машины
Эти виртуальные машины полагаются на безопасность на основе виртуализации и доступны начиная с Windows Server 2016.
Требования к узлу :
UEFI 2.3.1 c — поддерживает безопасную, измеряемую загрузку
Следующие два являются необязательными для безопасности на основе виртуализации в целом, но требуются для размещения, если требуется обеспечить защиту с помощью этих функций:
TPM версии 2.0 — защищает активы безопасности платформы
IOMMU (Intel VT-D) — позволяет гипервизору обеспечивать защиту прямого доступа к памяти (DMA)
Технология Hyper-V доступна в 64-разрядных версиях Windows 10 Pro, Корпоративная и для образовательных учреждений. Для Hyper-V требуется функция преобразования адресов второго уровня (SLAT). Она есть в текущем поколении 64-разрядных процессоров Intel и AMD.
На узле, имеющем 4 ГБ оперативной памяти, можно запустить три-четыре базовые виртуальные машины, однако для большего числа виртуальных машин потребуется больше ресурсов. Кроме того, можно создать мощные виртуальные машины с 32 процессорами и 512 ГБ ОЗУ в зависимости от оборудования.
Читайте также: