Сегодня большинство ИТ-систем строится на технологиях виртуализации, которые позволяют запускать несколько изолированных сред на одном физическом сервере.
Основой этой технологии является гипервизор — программный слой, который управляет виртуальными машинами и распределяет между ними доступные вычислительные ресурсы.
Содержание:
- Что такое гипервизор
- Что такое виртуализация
- Что такое средства виртуализации
- Как работает гипервизор
- Типы гипервизоров
- Чем отличаются гипервизоры первого и второго типа
- Методы виртуализации
- Гипервизоры и контейнеры: в чем разница
- Где применяются гипервизоры и что это дает бизнесу
- Ограничения и риски гипервизоров
- Безопасность виртуальной среды
- Современные тенденции в области виртуализации
- Базовые гипервизоры и технологии виртуализации
- Как выбрать платформу виртуализации
- Эффективное управление ИТ-инфраструктурой с помощью платформы виртуализации SpaceVM
- Советы экспертов Space
- Главное по теме
Что такое гипервизор
Гипервизор — это программный слой, который абстрагирует физические ресурсы сервера (процессор, память, диски, сеть) и распределяет их между виртуальными машинами. Он перехватывает обращения каждой ВМ к оборудованию и обрабатывает их так, что несколько изолированных операционных систем работают на одном физическом сервере одновременно.
По сути, этот компонент создает буфер между «железом» сервера (CPU, RAM, накопителями, сетевыми картами) и гостевыми операционными системами. В результате каждая ВМ «думает», что работает на выделенном ПК, хотя фактически делит физические ресурсы с соседями. Можно сказать, что гипервизор дирижирует виртуализацией: решает, какую долю процессорного времени, памяти и дискового ввода-вывода получит каждая среда.
Алексей Мензовитый, директор SpaceVM: «Гипервизор — ключевой слой виртуализации, который позволяет одному физическому серверу одновременно работать как несколько независимых систем.»
В итоге бизнес получает инструмент для экономии на оборудовании и тонкой настройки балансировки нагрузок.
Что такое виртуализация
Виртуализация делит физические ресурсы сервера — процессор, память, диски и сеть — между несколькими автономными логическими средами.
Если объяснять просто: один физический сервер нарезается на несколько независимых сегментов, каждый из которых ведет себя как автономный компьютер. Эти сегменты — виртуальные машины, обладающие собственными ОС, стеком приложений и конфигурациями.
При этом каждая виртуальная машина полностью изолирована от остальных, поэтому сбой или зависание одной из них не влияет на работу соседних.
Что такое средства виртуализации
Средства виртуализации — программные и аппаратные инструменты, которые обслуживают виртуальные машины на всём цикле: создание, запуск, наблюдение, обновление, вывод из эксплуатации.
Средства виртуализации делятся на два уровня. На нижнем находятся базовые компоненты, которые напрямую работают с оборудованием и управляют виртуальными машинами. На верхнем: платформы, которые объединяют эти компоненты в единый продукт.
Базовые компоненты:
Гипервизоры. Слой, который напрямую взаимодействует с оборудованием и распределяет ресурсы между ВМ. Создает и исполняет виртуальные среды.
Системы управления виртуальной инфраструктурой. Панель, из которой администратор управляет парком ВМ, кластерами и узлами: настраивает политики, отслеживает состояние, балансирует нагрузку.
Средства оркестрации. Автоматизируют рутину: развертывание ВМ, масштабирование, адаптацию инфраструктуры под нагрузку.
Платформы виртуализации и облачные платформы объединяют гипервизор, систему управления и оркестрацию в один продукт. Они добавляют сетевые сервисы, хранилища и выдачу ресурсов по запросу (self-service). Именно платформа, а не отдельный компонент, становится тем «единым окном», из которого ИТ-отдел управляет всей инфраструктурой.
Как работает гипервизор
Занимая позицию посредника между физическим «железом» и гостевыми ОС, гипервизор берет на себя ряд критических функций:
- диспетчеризацию процессорных ядер;
- выделение оперативной памяти;
- маршрутизацию запросов к сетевым адаптерам и дисковым контроллерам;
- обеспечение жесткой изоляции ВМ друг от друга.
Когда гостевая ОС пытается выполнить привилегированную инструкцию – обратиться к памяти, диску или сетевой карте, она не получает прямого доступа к оборудованию. Гипервизор перехватывает это обращение. Часть операций он обрабатывает программно, а часть с помощью аппаратных расширений процессора (Intel VT-x, AMD-V) передает напрямую CPU – это снижает накладные расходы. Так каждая виртуальная машина работает с виртуальным «железом», не пересекаясь с соседями и не затрагивая физический сервер.
При чувствительной операции процессор выходит из режима виртуальной машины (VM exit) и передаёт управление гипервизору: тот проверяет действие и возвращает управление гостевой системе.
Расширенные таблицы страниц Intel EPT и вложенные таблицы AMD NPT ускоряют преобразование адресов гостевой памяти в адреса физической памяти хоста. Для крупных ВМ учитывают архитектуру неоднородного доступа к памяти (NUMA): обращение к удалённой памяти обходится дороже, чем к локальной.
Устройства гипервизор предоставляет тремя способами: программной эмуляцией, паравиртуализированными драйверами или прямой передачей. Драйверы VirtIO ускоряют дисковые и сетевые операции. При прямой передаче блок управления памятью устройств ввода-вывода (IOMMU) ограничивает доступ оборудования к памяти, а SR-IOV разделяет один физический адаптер на несколько виртуальных функций.
В итоге каждая ВМ работает так, будто владеет эксклюзивным компьютером, хотя фактически лишь арендует часть общего физического сервера.
Типы гипервизоров
Классификация гипервизоров базируется на их особенностях и месте в технологическом стеке.
Гипервизор первого типа
Гипервизоры типа 1 (bare-metal) устанавливаются непосредственно на серверное оборудование, без базовой ОС под ними. Гипервизор сам планирует процессорное время, распределяет память и обслуживает ввод-вывод.
Обращения ВМ идут к оборудованию без промежуточного слоя, поэтому накладные расходы ниже, чем у второго типа. Такая архитектура сокращает и поверхность атаки: в ней нет служб, драйверов и пользовательского окружения универсальной ОС.
Гипервизор второго типа
Гипервизоры второго типа (hosted) работают как приложения поверх базовой операционной системы и обращаются к оборудованию через её драйверы и системные вызовы.
Дополнительный слой добавляет накладные расходы, а стабильность ВМ зависит от хостовой ОС: её обновление или зависание затрагивает все запущенные машины. Такой формат применяют для локального тестирования, обучения и разработки.
Гипервизор гибридного типа
Гибридная архитектура совмещает черты обоих типов: ядро гипервизора работает непосредственно на оборудовании, а управление, драйверы и сервисные функции выполняет отдельная привилегированная ОС.
Так устроен Hyper-V: гипервизор запускается до Windows, а Windows Server становится родительским разделом и предоставляет драйверы оборудования. По той же схеме работает Xen — подробнее в разделе о базовых гипервизорах.
Прямой доступ к процессору и памяти сохраняет производительность первого типа, а привилегированная ОС снимает задачу поддержки драйверов для всей номенклатуры оборудования.
Чем отличаются гипервизоры первого и второго типа
| Критерий | Первый тип | Второй тип |
| Установка | На оборудование | Поверх хостовой ОС |
| Доступ к оборудованию | Напрямую | Через драйверы хостовой ОС |
| Накладные расходы | Ниже | Выше |
| Поверхность атаки | Только гипервизор | Гипервизор и хостовая ОС |
| Сценарии | ЦОД, продуктивные нагрузки | Тестирование, обучение, разработка |
Методы виртуализации
Тип гипервизора отвечает на вопрос «где он установлен». Метод виртуализации же отвечает на другой вопрос: «как именно он создает виртуальную машину». Это две независимые характеристики: гипервизор первого типа может использовать любой из методов ниже.
По способу доступа к процессору
Аппаратная виртуализация
В основе аппаратной виртуализации лежат расширения процессора Intel VT-x и AMD-V. Переключение контекстов выполняет процессор, поэтому накладные расходы держатся на уровне единиц процентов.
Программная виртуализация
Программная эмуляция не требует аппаратных расширений CPU. Гипервизор транслирует инструкции гостевой ОС и эмулирует устройства программно. ВМ запускается на оборудовании без расширений виртуализации, но производительность падает в разы.
По работе с гостевой ОС
Паравиртуализация
При паравиртуализации гостевые ОС модифицируются таким образом, чтобы «понимать» свое виртуальное происхождение. Они общаются с гипервизором напрямую, используя специальные интерфейсы, минуя этапы полной эмуляции оборудования.
Прирост заметнее всего на дисковых и сетевых операциях. Взамен нужны образы ОС с поддержкой этого режима, что сужает список совместимых систем.
Полная виртуализация
Гипервизор эмулирует полный набор оборудования, поэтому гостевая ОС не отличает виртуальную среду от физической.
Метод запускает немодифицированные гостевые ОС, включая устаревшие и проприетарные. Плата — постоянная трансляция привилегированных инструкций, которая нагружает процессор хоста.
Гипервизоры и контейнеры: в чем разница
Гипервизор виртуализует оборудование: каждая ВМ получает собственное ядро ОС. Контейнер виртуализует операционную систему — процессы делят одно ядро хоста. Отсюда расходятся характеристики: собственное ядро даёт жёсткую границу изоляции, но требует памяти и времени на запуск. Общее ядро экономит и то и другое, но граница между контейнерами слабее.
| Критерий | Виртуальная машина | Контейнер |
| Ядро | Собственное | Общее с хостом |
| Изоляция | Аппаратная, на уровне гипервизора | Программная, на уровне ядра ОС |
| Потребление ресурсов | Выше | Ниже |
| Запуск | Обычно дольше | Обычно быстрее |
| Совместимость | Разные гостевые ОС | Зависит от ядра хоста |
| Задачи | Серверы, базы данных, изолированные системы | Микросервисы и приложения |
Разные гостевые ОС, устаревшие приложения, требования к изоляции по регламенту — задача для виртуальных машин. Однотипные stateless-сервисы, частые обновления, горизонтальное масштабирование — для контейнеров. Смешанная инфраструктура встречается чаще, чем чистая: контейнерную платформу разворачивают внутри ВМ, где гипервизор отвечает за изоляцию и перенос между узлами, а оркестратор — за жизненный цикл приложений.
Алексей Мензовитый, директор SpaceVM: «Виртуализация стала основой современной IT-архитектуры, потому что позволяет превращать один сервер в целый набор независимых вычислительных сред.»
Где применяются гипервизоры и что это дает бизнесу
Консолидация серверов. Вместо парка машин под каждый сервис — несколько узлов с десятками ВМ. Утилизация физического сервера в невиртуализованной среде редко превышает 15%, при консолидации выходит на 60–70%. Экономия идёт не только на закупке, но и на стойко-местах, питании и охлаждении.
Тестовые и учебные среды. Шаблон ВМ разворачивается за минуты, снимок откатывает состояние после неудачного теста. Отдельное железо под стенды не нужно.
Аварийное восстановление. Виртуальная машина — это файлы: их реплицируют на резервную площадку и запускают там при отказе основной. Восстановление физического сервера требует совместимого оборудования, восстановление ВМ — нет.
Частные облака и виртуальные рабочие места. Платформа выдаёт ресурсы по заявке, подразделения получают мощности без закупки под каждый проект.
Дополнительно платформа даёт единую точку управления парком машин и автоматический перезапуск ВМ на исправных узлах при отказе оборудования.
Ограничения и риски гипервизоров
Виртуализация добавляет и собственные ограничения. Слой гипервизора отнимает часть производительности. Инфраструктура усложняется: администратору нужны компетенции в кластеризации, сетях и хранилищах, а ошибка в конфигурации одного узла выводит из строя десятки сервисов сразу.
Чрезмерная переподписка ресурсов — назначение виртуальным машинам большего суммарного объёма процессоров или памяти, чем физически доступно на хосте, — вызывает конкуренцию за мощности и нестабильную производительность.
Снимок виртуальной машины не заменяет резервную копию. Он фиксирует состояние виртуального диска, зависит от исходных данных и подходит для кратковременного отката перед изменениями. Резервные копии хранят отдельно и регулярно проверяют восстановление.
Прямая передача сетевых карт, графических ускорителей или контроллеров уменьшает задержки, но может ограничить перенос работающих ВМ между узлами.
Безопасность виртуальной среды
У виртуальной инфраструктуры два слоя риска, которых нет у физических серверов.
Плоскость управления. Учётные записи, REST API, консоли и службы администрирования дают доступ сразу ко всем ВМ, сетям и хранилищам кластера. Компрометация одной административной учётки равна компрометации всей инфраструктуры. Плоскость управления выносят в отдельную сеть, закрывают многофакторной аутентификацией, раздают права по минимуму и пишут аудит всех действий.
Побег из виртуальной машины. Уязвимость в гипервизоре или эмуляторе устройств позволяет коду из гостевой ОС выйти за границу ВМ и получить доступ к хосту или соседним машинам. Основная защита — своевременное обновление гипервизора: такие уязвимости закрывают патчами, и разрыв между публикацией и установкой определяет риск.
Остальные меры:
- сегментация виртуальных сетей — сбой или взлом в одном сегменте не открывает доступ к соседним;
- Secure Boot и vTPM — контроль целостности загрузки гостевой ОС и хранение ключей шифрования;
- IOMMU при прямой передаче устройств — ограничивает область памяти, к которой обращается физическое устройство, иначе оно читает память всего хоста;
- шифрование каналов миграции — при переносе память ВМ идёт по сети в открытом виде, включая ключи и пароли;
- резервные копии на отдельном хранилище с проверкой восстановления;
- контроль снимков — снимок содержит состояние памяти и диска, поэтому его хранят и удаляют по тем же правилам, что и данные внутри ВМ.
Современные тенденции в области виртуализации
Уход зарубежных вендоров перевёл миграцию из разряда стратегических решений в плановые проекты: инфраструктура на vSphere остаётся без обновлений и поддержки, а требования импортозамещения закрывают закупку нереестрового ПО в госсекторе и на объектах КИИ.
Виртуализация и контейнеры перестали конкурировать: типовая схема — кластер Kubernetes внутри виртуальных машин, где гипервизор даёт изоляцию и живую миграцию, а оркестратор управляет приложениями.
Управление уходит в код: платформы отдают REST API, конфигурации хранятся в репозитории и применяются через OpenTofu или Ansible.
Базовые гипервизоры и технологии виртуализации
KVM
KVM (Kernel-based Virtual Machine) — это модуль ядра Linux. После его загрузки ядро само выполняет функции гипервизора первого типа: планирует виртуальные процессоры, изолирует адресные пространства ВМ и обрабатывает их обращения к оборудованию.
KVM опирается на аппаратные расширения виртуализации Intel VT-x и AMD-V. Переключение контекстов и трансляцию адресов выполняет процессор, а не программный слой, поэтому накладные расходы остаются на уровне единиц процентов.
QEMU
QEMU — эмулятор устройств и процессорных архитектур. В паре с KVM он берёт на себя то, что модуль ядра не делает: воспроизводит дисковые контроллеры, сетевые адаптеры, видеоустройства и BIOS виртуальной машины, пока вычисления идут через KVM напрямую на процессоре.
Без KVM QEMU транслирует инструкции программно и запускает образы, собранные под ARM, MIPS или другие архитектуры, на процессорах x86. Скорость при этом падает в разы — такой режим применяют для разработки и отладки, а не для продуктивных нагрузок.
Xen
Xen — гипервизор с доменной архитектурой. Первым загружается сам гипервизор, затем привилегированный домен Dom0: он держит драйверы оборудования и обслуживает операции управления, а гостевые системы работают в непривилегированных доменах DomU.
Такое разделение ограничивает последствия сбоя драйвера: отказ в Dom0 не даёт прямого доступа к памяти гостевых доменов.
Как выбрать платформу виртуализации
Подбор оптимального стека виртуализации — это всегда компромисс между задачами бизнеса, бюджетом и текущим ИТ-ландшафтом. Важно, чтобы решение органично вписалось в существующую архитектуру.
Совместимость с существующей ИТ-инфраструктурой
Аудит совместимости начинается с анализа текущего парка: какие ОС используются, как построена сеть, какое оборудование стоит в стойках. Здесь важно проверить, с какими протоколами хранения работает платформа (NFS, iSCSI, FC) — если она поддерживает уже используемые в компании, миграция обойдётся без замены СХД. Отдельно стоит уточнить интеграцию со службой каталогов (AD, LDAP) для единой аутентификации и наличие REST API для связки со сторонними системами и автоматизации. Платформа, закрывающая эти пункты, встраивается в имеющийся парк без перестроения всей ИТ-системы.
Поддержка необходимых функций и масштабирования
Планировать нужно на горизонт роста, поэтому у платформы стоит заранее выяснить предельный размер кластера — сколько хостов и виртуальных машин он объединяет. Этот потолок показывает, хватит ли решения на несколько лет вперёд или инфраструктура упрётся в ограничения раньше срока. Важны и механизмы непрерывной работы: высокая доступность (HA), которая перезапускает ВМ на исправных узлах при отказе оборудования, и миграция работающих машин между узлами без остановки сервисов. Возможность добавлять узлы без остановки кластера обеспечивает рост без простоев.
Стоимость владения и техническая поддержка
Считать нужно не цену лицензии, а совокупную стоимость владения на 3–5 лет. Первым делом стоит разобрать модель лицензирования: платит компания за физические хосты, за процессорные ядра или за число виртуальных машин. От этого зависит, вырастут ли расходы при увеличении плотности ВМ на сервере — при лицензировании по хостам плотность можно наращивать без доплат. В стоимость владения также входят обновления, сопровождение, миграция с текущей платформы и обучение администраторов. Для российского заказчика отдельный вес имеет техподдержка: язык, часовой пояс и гарантия сопровождения — после ухода зарубежных вендоров возможность получить помощь на русском языке нередко решает больше, чем первоначальная экономия на лицензии.
Наличие сертификатов соответствия и уровней доверия
Для госсектора и объектов критической информационной инфраструктуры (КИИ) соответствие требованиям — не преимущество, а обязательное условие допуска. Здесь проверяют два разных основания. Первое — включение платформы в Единый реестр российских программ: без него ПО нельзя закупать по правилам импортозамещения. Второе — сертификаты ФСТЭК и уровень доверия, которые требуются, если система обрабатывает защищаемую информацию или относится к значимым объектам КИИ. Эти основания не взаимозаменяемы: реестровый статус решает вопрос закупки, сертификация — вопрос допуска к обработке данных.
До закупки проводят пилотное внедрение и проверяют на нём:
- запуск, остановку и миграцию виртуальных машин;
- работу кластера при отказе узла;
- восстановление из резервной копии;
- обновление кластера без остановки сервисов;
- разграничение прав;
- совместимость с имеющимися сетями и хранилищами.
Итоговый выбор опирают на испытания реальных приложений, а не на длину списка функций.
Эффективное управление ИТ-инфраструктурой с помощью платформы виртуализации SpaceVM
SpaceVM — российская платформа серверной виртуализации на базе гипервизора KVM, включённая в Единый реестр российских программ (запись №16085). Реестровый статус позволяет закупать платформу в госсекторе и на объектах КИИ, где действует требование об отечественном ПО.
Платформа управляет вычислениями, хранилищами и сетью из единой панели. Администратор работает с кластерами и виртуальными машинами через один интерфейс, а также через REST API — для автоматизации и интеграции со сторонними системами. Поддерживается аутентификация через AD и LDAP, мониторинг по SNMP.
- Отказоустойчивость и непрерывность работы. Кластерная архитектура с механизмом высокой доступности (HA) перезапускает виртуальные машины на исправных узлах при отказе оборудования. Живая миграция (live migration) переносит работающие ВМ между узлами кластера без остановки — это позволяет обслуживать оборудование, не прерывая сервисы.
- Масштабирование. Один кластер SpaceVM объединяет до 96 хостов и до 8 000 виртуальных машин. Узлы добавляются по мере роста нагрузки, поэтому инфраструктуру можно наращивать под задачи бизнеса без замены платформы.
- Поддержка хранилищ. SpaceVM работает с протоколами NFS, iSCSI, FC и файловой системой GFS2 — платформа встраивается в имеющуюся систему хранения без её перестроения.
- Лицензирование по хостам. Стоимость зависит от числа физических узлов, а не от количества виртуальных машин или ядер. При росте плотности ВМ на хосте затраты на лицензии не увеличиваются — это делает расходы предсказуемыми на горизонте планирования.
- Миграция с зарубежных платформ. После ухода Broadcom с российского рынка обновления и поддержка VMware vSphere недоступны, поэтому перенос инфраструктуры стал плановой задачей. SpaceVM переносит виртуальные машины с vSphere; исходная ВМ останавливается на время переноса — этот простой закладывают в план работ.
Советы экспертов Space
- Резервируйте под отказоустойчивость минимум N+1 узел в кластере — при отказе одного хоста его ВМ перезапустятся на свободных мощностях, а не встанут.
- Держите утилизацию CPU и RAM узла в пределах 70–80%: оставшийся запас нужен для миграции ВМ при обслуживании и пиковых нагрузок.
- Планируйте окно обслуживания заранее: живая миграция переносит работающие ВМ без остановки, но перенос с внешних платформ (VMware) требует простоя — его закладывают в регламент.
- Разносите узлы одного кластера по разным стойкам и источникам питания — отказ стойки не должен уронить весь кластер.
- Настройте мониторинг не постфактум, а до вывода в продакшен: пороги по CPU, памяти, дисковому I/O и состоянию узлов.
Главное по теме
- гипервизор перехватывает обращения ВМ к оборудованию и распределяет процессорное время, память и ввод-вывод;
- тип определяет место установки, метод виртуализации — способ создания ВМ; это независимые характеристики;
- ВМ изолируются жёстче контейнеров за счёт отдельного ядра, контейнеры стартуют быстрее за счёт общего;
- платформу выбирают по совместимости, потолку кластера, модели лицензирования и реестровому статусу;
- SpaceVM (реестр №16085) объединяет гипервизор KVM, управление кластерами и сетью.
Алексей Мензовитый
Директор SpaceVM
