Что такое гипервизор: один сервер и несколько виртуальных машин

Один сервер — три отдельных рабочих окружения

Представим компанию, которой нужны сервер 1С, корпоративная почта и тестовый стенд. Можно поставить их в три ВМ на одном физическом хосте. У каждой своя гостевая ОС, настройки и виртуальные диски. Обновление тестового приложения не требует переустановки ОС почтового сервера.

Хост — физическая машина, предоставляющая ресурсы. Гость — запущенная ВМ со своей ОС. Гипервизор организует их работу и доступ к реальному оборудованию. Рамки на схеме — программное разделение, а не три независимых физических сервера.

Что находится внутри виртуальной машины

ВМ получает виртуальные устройства: vCPU, память, контроллер диска и сетевой адаптер. В неё устанавливают гостевую ОС — например Windows Server или Linux, а уже в неё приложение. Это отличается от контейнера, где в обычной Linux-схеме приложения используют общее ядро хоста.

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

Два подхода: серверная платформа и программа на рабочем компьютере

Гипервизоры первого типа работают на уровне серверного оборудования; примеры — Hyper-V, KVM и ESXi. Гипервизор второго типа, или hosted, запускается поверх существующей ОС; пример — Oracle VirtualBox.

Не определяйте тип по наличию окна Windows. Microsoft относит Hyper-V к первому типу, в том числе его архитектура не превращается в hosted только из-за графического интерфейса управления. KVM является частью Linux: простой рисунок «железо — гипервизор — ВМ» не передаёт всех деталей реализации.

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

Где берутся CPU и память

vCPU — виртуальный процессор, которому требуется реальное процессорное время. Он не обязательно закреплён за отдельным физическим ядром. Если несколько ВМ одновременно требуют больше CPU, чем доступно хосту, они ждут исполнения. Добавление vCPU в настройках не создаёт новые ядра в процессоре.

Условный расчёт RAM: у хоста 128 ГиБ. В плане оставлено 12 ГиБ платформе, ВМ 1С назначено 48, почте 16, тесту 8. Получается 128 − 12 − 48 − 16 − 8 = 44 ГиБ нераспределённого запаса. Это пример арифметики, а не рекомендация всегда оставлять ровно 12 ГиБ: потребность платформы, кэша и хранилища различается.

Для памяти и CPU действуют разные механизмы учёта. Возможности динамического управления или overcommit нельзя считать гарантией, что все гости одновременно получат требуемую физическую RAM без задержек. Для СУБД и чувствительных приложений режим памяти согласуют с рекомендациями поставщика и измерениями.

Как ВМ подключается к сети

Внутри гостевой ОС виден виртуальный сетевой адаптер. Он подключается к виртуальному коммутатору или мосту, а тот при необходимости выводит трафик через физическую сетевую карту. Обмен между ВМ на одном хосте может не выходить в физическую сеть.

Для гостя отдельно задают адресацию, маршруты и доступы. Разные ВМ не становятся изолированными друг от друга только из-за разных имён. Management платформы, пользовательский трафик, хранение и резервное копирование разделяют по проекту; VLAN требует согласованной настройки виртуальной и физической сети.

Пример ошибки: хост управляется, но ВМ не видна пользователям. Причина может быть в неверном виртуальном коммутаторе, VLAN, IP-адресе или правилах гостевой ОС. Успешный вход в веб-панель гипервизора не проверяет весь путь до приложения.

Где лежит виртуальный диск и почему может тормозить всё сразу

У ВМ отдельный виртуальный диск, но физическое хранение может быть общим. Если одновременно работают СУБД, копирование и тяжёлый тест, задержка общего массива влияет на всех. Перенос виртуальных дисков в разные папки не гарантирует независимую производительность.

Учитывают полезную ёмкость, IOPS, пропускную способность, задержки, надёжность накопителей и запас под служебные операции. Thin provisioning позволяет выделить виртуально больше, чем занято сейчас, но не создаёт свободные физические блоки. Рост данных и снимков способен заполнить хранилище.

Схему выбирают под требования: локальные диски, внешняя СХД, распределённое хранение или другой поддерживаемый вариант. RAID помогает пережить предусмотренные отказы дисков, но не защищает от любого удаления, шифрования, ошибки администратора или потери площадки.

Снимок, резервная копия и перенос — разные действия

• Снимок: точка состояния, обычно связанная с исходными дисками и цепочкой изменений. Полезен для ограниченного сценария, но не равен независимой копии.
• Резервная копия: сохранённые данные и конфигурация для восстановления, с согласованностью приложения и нужным сроком хранения.
• Миграция: перенос ВМ между ресурсами или платформами при выполнении условий совместимости.
• HA: механизм восстановления доступности, например перезапуск ВМ на другом узле.

Снимок на том же потерянном хранилище не поможет вернуть исчезнувший массив. Возврат снимка СУБД может затронуть актуальные данные и соседние системы. Согласованность копии проверяют с учётом гостевой ОС, приложения, guest agent и способа копирования.

Работающее восстановление проверяют отдельно: загрузка гостя, вход в приложение, актуальность данных и доступ пользователей. В статье о Proxmox Backup Server разобран один из вариантов организации копий.

Если физический сервер выключился

При потере одиночного хоста прекращают работу все размещённые на нём ВМ. Их программная раздельность не обеспечивает независимое питание, сеть и диски. Это главное ограничение консолидации: меньше оборудования, но больше приложений зависит от одного узла.

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

Live migration переносит работающую ВМ при выполнении условий. Она не может «доперенести» оперативную память с уже обесточенного сервера. Поддержка CPU, устройств, сети, хранилища и лицензий определяет, какие миграции доступны. Прикладную доступность во время обслуживания испытывают отдельно.

Как здесь связаны Docker и Kubernetes

Обычная схема: физический сервер → гипервизор → ВМ с Linux → контейнеры приложений. ВМ отделяет гостевую ОС от других гостей, а контейнеры внутри неё помогают поставлять и запускать приложения. Kubernetes может управлять контейнерными приложениями на нескольких таких узлах.

Если в одной ВМ запущены три Pod, они продолжают зависеть от этой ВМ. Если три ВМ находятся на одном физическом хосте, они зависят от этого хоста. В каждой схеме нужно отметить реальные общие точки отказа. Наглядные объяснения есть в статьях о Docker и Kubernetes.

Примеры технологий и платформ

Гипервизор и система управления — не всегда один продукт. KVM предоставляет механизм виртуализации Linux, а Proxmox VE объединяет KVM, управление ВМ, контейнеры и инфраструктурные функции. Hyper-V — технология Microsoft; ESXi используется в платформе VMware. VirtualBox часто применяют на рабочих компьютерах и в учебных сценариях.

Среди российских платформ — zVirt и РЕД ВИРТ / РЕД Виртуализация. Состав функций, права, поддержка оборудования и обновления проверяются для конкретной редакции и поставки. Российское происхождение не означает автоматическую совместимость со всем оборудованием и ПО.

Это примеры, а не рейтинг. Подробное сравнение платформ виртуализации уже вынесено в отдельную статью. Здесь важнее понять устройство и требования, с которыми следует подходить к выбору.

Что влияет на производительность виртуальной машины

• CPU: производительность ядра, доступное время, конкуренция гостей и топология NUMA.
• RAM: реальная потребность, физический запас, подкачка и режим управления памятью.
• Хранение: задержки, очереди, рост снимков и параллельное копирование.
• Сеть: путь трафика, драйвер виртуального адаптера, потери и ограничения.
• Гостевая ОС: поддерживаемые драйверы, интеграционные инструменты и настройки приложения.

Нет универсального правила «виртуализация всегда отнимает 10%» или «ВМ всегда медленнее физического сервера». Проверяют конкретную нагрузку и измеряют время нужных операций. Большой синтетический балл не гарантирует быстрое проведение документов 1С.

Смотрите и гостя, и хост. Низкий CPU внутри ВМ не исключает ожидание хранилища, конкуренцию за ресурсы или блокировку СУБД. Методика сравнения разобрана в статье о производительности 1С на гипервизорах.

Безопасность и лицензии

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

Лицензии учитывают слоями: сама платформа, гостевая ОС, СУБД и приложение. Бесплатная загрузка гипервизора не делает бесплатно лицензируемый Windows Server или 1С. Условия могут зависеть от ядер, серверов, ВМ и прав перемещения; их подтверждают по актуальной поставке.

Перенос или изменение виртуального оборудования может повлиять на программные лицензии и аппаратные ключи. Проброс USB, GPU и других устройств проверяют по совместимости и требованиям приложения. Такой доступ также способен ограничить перенос ВМ между узлами.

Арендованная ВМ в облаке: что скрыто от пользователя

Облачная ВМ также получает ресурсы вычисления, памяти, сети и хранения. Пользователь может управлять своей ОС, не администрируя физический гипервизор провайдера. Но граница ответственности зависит от услуги: аренда ресурсов и полное сопровождение приложения — разные договорённости.

До заказа уточняют производительность CPU, гарантии ресурсов, класс хранения, сеть, копии, способ восстановления и ограничения лицензий. Наличие панели с кнопкой «создать ВМ» не подтверждает HA или резервирование данных. Требования к приложению формулируют до сравнения цен.

Для небольшой компании облако может сократить заботы о собственном оборудовании; собственный контур может быть оправдан другими требованиями. Сравнение должно учитывать одинаковые нагрузки, доступность, данные и обслуживание, а не только размер RAM в двух тарифах.

Как безопасно познакомиться с ВМ

1. Выберите отдельный учебный компьютер или согласованный тестовый контур.
2. Проверьте требования платформы, архитектуру CPU, поддержку аппаратной виртуализации и свободные ресурсы.
3. Создайте ВМ: имя, vCPU, RAM, виртуальный диск и подходящая сеть.
4. Подключите официальный установочный ISO гостевой ОС и выполните её установку.
5. Установите поддерживаемые средства интеграции гостя, обновления и тестовое приложение.
6. Проверьте сеть, время, контрольную операцию, остановку и загрузку.
7. Сделайте копию нужным способом и восстановите её в отдельную ВМ.

Не начинайте знакомство с установщика серверной платформы на рабочий сервер: выбор целевого диска и сетевых параметров может изменить действующую систему. Приведённый порядок объясняет этапы; точные команды и совместимость берут из документации выбранной платформы.

Как посмотреть текущее окружение без изменения настроек

В Windows можно прочитать общие сведения:

Get-CimInstance Win32_ComputerSystem |
  Select-Object Manufacturer, Model, HypervisorPresent

Поле HypervisorPresent сообщает об обнаруженном гипервизоре. Это не полный аудит платформы и не самостоятельное доказательство, что перед вами гостевая ВМ: на физическом Windows-хосте также могут быть активны гипервизорные функции.

На сервере с установленным модулем Hyper-V и подходящими правами:

Get-VM |
  Select-Object Name, State, CPUUsage, MemoryAssigned

Get-VM показывает ВМ подключённого Hyper-V-хоста; MemoryAssigned выводится в байтах. На обычном компьютере без модуля эта команда может отсутствовать. Одна сводка не заменяет историю производительности.

В Linux полезны диагностические команды:

systemd-detect-virt
lscpu
lsblk

systemd-detect-virt определяет обнаруженную среду, включая некоторые контейнерные варианты. lscpu показывает представление CPU, lsblk — блочные устройства. Это не тест производительности и не доказательство типа физических дисков под облачной ВМ. Команды здесь иллюстративные; стенд виртуализации при подготовке статьи не разворачивался.

Что собрать перед выбором гипервизора

• Приложения, гостевые ОС, версии и требования поддержки.
• Обычная и пиковая нагрузка: CPU, RAM, диски, сеть.
• Допустимый простой, потеря изменений и сценарии восстановления.
• План роста и запас при обслуживании или отказе узла.
• Оборудование, устройства и совместимость драйверов.
• Система копирования, проверка восстановления и права администраторов.
• Лицензии, обновления, поддержка и ответственные.

Полезно сразу нарисовать: какие ВМ на каком хосте, где диски, откуда идут копии и что остаётся при отказе. Для кластера Proxmox отдельный практический пример есть в руководстве Proxmox VE и Ceph; это один вариант архитектуры, а не обязательная схема для всех.

Три типичные ошибки

Два шаблона для планирования

Поможем спроектировать и сопровождать виртуальную инфраструктуру

Вопросы и ответы