Чем OpenStack отличается от VMware vSphere?

OpenStack не является прямым аналогом одного ESXi-хоста: это компоненты разных уровней. ESXi сопоставим по назначению со стеком QEMU/KVM/libvirt как слой исполнения виртуальных машин. vCenter Server и vSphere относятся к централизованному управлению виртуальной инфраструктурой, тогда как OpenStack строит распределённую плоскость управления частным IaaS-облаком. OpenStack предоставляет проекты, роли, квоты, API, каталог образов и механизмы контролируемого самообслуживания. В его типичной архитектуре Nova управляет жизненным циклом экземпляров, Neutron — сетями, Cinder — томами, а KVM запускает гостевые ОС на compute-узлах. При выборе нельзя заранее считать одну платформу дешевле, проще или надёжнее другой. Следует отдельно сопоставить поддержку оборудования и гостевых ОС, HA и миграции, сеть и хранение, интеграции, лицензирование, состав доступных VMware-компонентов и компетенции команды. Один vCenter сам по себе не означает наличие полного аналога OpenStack-проектов, квот и self-service.

Можно ли считать OpenStack гипервизором?

Нет. OpenStack — платформа управления частным облаком, которая принимает запросы через API, проверяет права и квоты, планирует размещение VM и координирует сеть, образы и хранение. Гостевой код он сам не исполняет: в типичной схеме VM запускает QEMU с ускорением KVM, а libvirt предоставляет интерфейс управления этим стеком.

Нужен ли OpenStack, если уже есть KVM-хосты?

Решение зависит не от числа KVM-серверов, а от модели предоставления ресурсов. OpenStack добавляет распределённую плоскость управления: сервисы идентификации, планирования, учёта ресурсов, сетей, образов и томов, а также базы данных, очереди сообщений и эксплуатационные процессы. Его имеет смысл внедрять, если внутренние команды постоянно создают тестовые или прикладные среды, инфраструктура выдаётся из CI/CD, нужны изоляция по проектам, роли, квоты и воспроизводимые операции через API. В таком случае KVM остаётся слоем исполнения VM, а OpenStack стандартизирует выдачу ресурсов. Если же парк VM небольшой, операции выполняют администраторы, а самообслуживание и API не требуются, OpenStack создаст дополнительные зависимости по control plane, сети и хранению без пропорциональной пользы. В этом сценарии обычно рассматривают vSphere, кластер Hyper-V, Proxmox VE либо решение централизованного управления поверх KVM/libvirt. Наличие HA, миграций и других кластерных функций проверяют для конкретного выбранного решения.

Почему VM не создаётся, хотя квота проекта не исчерпана?

Сначала нужно отличить ошибку квоты от ошибки размещения или подготовки зависимых ресурсов. Nova учитывает не только лимиты проекта, но и доступность запрошенных ресурсов, характеристики кандидатов из Placement и политики размещения. Поэтому экземпляр не будет считаться созданным, если подходящего compute-узла нет даже при свободной квоте. Далее проверяют, от имени какого проекта выполнен запрос и какие роли назначены пользователю: область действия токена и политики сервисов могут ограничивать доступ к образам, flavors, сетям или другим ресурсам. Затем анализируют сообщение API и идентификатор запроса. По нему смотрят журналы соответствующего компонента: Nova — для планирования и запуска, Neutron — для сетевых портов, Glance — для образа, Cinder — для создания или подключения постоянного тома. Если экземпляр остаётся в ошибочном состоянии, исправность compute-узла сама по себе не исключает проблему: создание VM зависит от согласованной работы нескольких сервисов и их backend-компонентов.

Гарантирует ли Cinder отказоустойчивость томов?

Нет. Cinder предоставляет единый API для создания и подключения блочных томов, но не делает локальные диски или внешнюю СХД отказоустойчивыми автоматически. Снапшоты, клонирование, репликация, QoS и восстановление зависят от конкретного backend-хранилища и его драйвера. Производительность, домены отказа и резервное восстановление нужно проектировать отдельно.

Применятся ли user data в VM без Cloud-Init?

Нет, не обязательно. OpenStack может передать метаданные и пользовательские данные при создании экземпляра, но гостевая ОС должна уметь их обработать. Cloud-Init обычно применяет такие параметры, как SSH-ключ, имя хоста и сетевая конфигурация. Если Cloud-Init или иной механизм обработки не подготовлен в образе, наличие user data не означает, что настройки будут применены.

OpenStack как частное облако поверх KVM: компоненты и границы выбора

OpenStack — платформа управления облаком, а не отдельный гипервизор. В типичной OpenStack-инфраструктуре KVM запускает виртуальные машины на вычислительных узлах, а OpenStack предоставляет пользователям и внутренним командам API, проекты, роли, квоты, сети, образы и хранилище. Такая облачная виртуализация оправдана при повторяемом самообслуживании и автоматизации; для небольшого числа VM, которыми управляют администраторы, обычный кластер виртуализации часто проще в эксплуатации.

OpenStack, KVM, QEMU и libvirt: разные уровни стека

Виртуализация — это создание изолированных логических ресурсов поверх физических серверов. OpenStack располагается выше слоя виртуализации: он принимает запросы на создание ресурсов, проверяет права и квоты, выбирает место размещения и координирует сервисы. Сам по себе он не исполняет гостевой код VM.

Назначение компонентов в распространённой связке OpenStack с KVM

Компонент	Уровень	Что делает
QEMU	Процесс VM и модель виртуального оборудования	Создаёт процесс виртуальной машины, эмулирует или предоставляет виртуальные устройства.
KVM	Подсистема ядра Linux	Использует аппаратную виртуализацию CPU и ускоряет выполнение гостевого кода.
libvirt	Интерфейс управления виртуализацией	Предоставляет API и службы, через которые можно управлять доменами QEMU/KVM, сетями и хранилищем.
Nova	Вычислительный сервис OpenStack	Управляет жизненным циклом экземпляров, планированием и взаимодействием с compute-узлами через драйверы.
OpenStack	Платформа частного облака	Объединяет вычисления, сети, образы, хранение, идентификацию и API в модель предоставления IaaS.

На compute-узле служба nova-compute обычно использует драйвер libvirt, который управляет связкой QEMU/KVM. Упрощённо путь таков: Nova поручает создать экземпляр, драйвер формирует описание домена, libvirt запускает QEMU, а QEMU использует KVM для аппаратно ускоренного исполнения гостевой ОС. Поэтому фраза «OpenStack работает на KVM» допустима как описание частой архитектуры, но не как универсальное свойство платформы.

Зависимость от релиза и способа развёртывания

Далее терминология и роли сервисов описаны по официальной документации OpenStack 2025.1 Epoxy. Поддерживаемые Nova compute drivers и варианты их сочетания с гипервизорами и виртуализаторами нужно проверять в руководстве Nova по гипервизорам для OpenStack 2025.1. Доступные сочетания и возможности также зависят от дистрибутива и способа развёртывания, поэтому перед проектированием нужно проверить документацию всех выбранных компонентов. OpenStack не следует считать платформой, работающей только с KVM.

Практическая установка и локальное управление KVM/QEMU/libvirt — отдельная задача: KVM, QEMU и libvirt в Linux: установка, VM, virsh и Guest Agent. OpenStack добавляет к этому стеку распределённую плоскость управления, многопользовательскую модель и сервисы инфраструктуры.

Сервисы OpenStack: путь от запроса до работающей VM

Сервисы разделены по задачам и взаимодействуют через API. Это позволяет независимо развивать и масштабировать части платформы, но требует согласованной эксплуатации: недоступность или неверная настройка одного сервиса может помешать созданию VM, даже если compute-узлы исправны.

Основные сервисы в типичном предоставлении виртуальной машины

Сервис	Роль	Граница ответственности
Keystone	Идентификация и доступ	Аутентифицирует пользователей и сервисы, выдаёт токены, связывает пользователей, проекты и роли.
Nova	Вычисления	Принимает запрос на экземпляр, планирует размещение и управляет жизненным циклом VM через compute driver.
Glance	Образы	Каталогизирует и предоставляет образы гостевых ОС; хранение файлов образов может быть организовано разными backend-способами.
OpenStack Placement	Учёт ресурсов	Ведёт сведения о доступных ресурсах, их характеристиках и распределениях; выдаёт Nova кандидатов, но не запускает VM.
Neutron	Сети	Предоставляет API сетей, подсетей, портов, маршрутизаторов и групп безопасности.
Cinder	Блочное хранение	Создаёт и подключает постоянные тома к экземплярам через драйверы систем хранения.

Neutron задаёт облачную модель сети через API, но сам факт наличия Neutron не определяет способ передачи трафика и полный набор сетевых функций. Реализация сетей, внешней связности, маршрутизации и политик зависит от ML2-драйвера, выбранного сетевого backend или SDN-решения, физической сети и архитектуры облака. Балансировку нагрузки обычно предоставляет отдельный сервис Octavia, а её возможности зависят от выбранного provider driver и инфраструктуры.

Аналогично Cinder даёт единый API томов, но возможности снапшотов, клонирования, типов томов, репликации, QoS и подключения определяет конкретный backend хранения и его драйвер. Cinder не превращает локальные диски серверов или внешнюю СХД в отказоустойчивое хранилище без отдельного проектирования.

Дополнительные компоненты не являются обязательным минимумом для каждого развёртывания. Horizon предоставляет веб-интерфейс поверх API, Heat оркестрирует наборы ресурсов по шаблонам, а Swift реализует объектное хранилище. Отсутствие Horizon не исключает работу через API и CLI; отсутствие Heat или Swift не отменяет работу Nova, Neutron и Cinder.

Как команда получает VM: проекты, роли, образы, flavor и квоты

В OpenStack пользователь не обязательно получает доступ к самим гипервизорам. Обычно ему назначают проект — логическую область владения ресурсами. Пользователь — это учётная запись, роль определяет разрешённые действия в проекте, а квота ограничивает потребление отдельных типов ресурсов. Точные наборы политик и прав определяются конфигурацией облака и политиками сервисов, а не только названием роли.

Пользователь выбирает проект. Keystone аутентифицирует его и выдаёт токен для API. Ожидаемый результат — запрос выполняется от имени конкретного проекта, а не от имени администратора всей инфраструктуры.
Пользователь выбирает образ и flavor. Образ из Glance содержит основу гостевой ОС. Flavor — шаблон вычислительных параметров экземпляра, обычно включающий vCPU, память и корневой диск; возможны дополнительные характеристики, заданные оператором облака.
Платформа проверяет ограничения. Nova и связанные сервисы учитывают квоты проекта, доступность запрошенных ресурсов и политики размещения. При превышении квоты или отсутствии подходящего кандидата экземпляр не должен считаться созданным: причину нужно искать в ответе API и журналах соответствующего сервиса.
Nova выбирает compute-узел. Планировщик использует сведения Placement о ресурсах и характеристиках, после чего задание на сборку экземпляра передаётся службе nova-compute выбранного узла.
Платформа готовит подключения и запускает VM. Nova координирует получение сетевой информации и портов Neutron, а при запросе постоянного тома — его создание или подключение через Cinder. После подготовки необходимых ресурсов nova-compute вызывает настроенный драйвер виртуализации для запуска VM. Детали последовательности зависят от способа загрузки экземпляра и конфигурации облака.
Гостевая ОС проходит начальную настройку. При подготовленном образе Cloud-Init может применить метаданные и пользовательские данные: например, ключ SSH, имя хоста или сетевую конфигурацию. Без Cloud-Init наличие user data ещё не означает, что гостевая ОС применит эти данные.

Что проверять после выдачи доступа команде

В типичной конфигурации пользователь должен видеть проекты, в которых ему назначены роли, а внутри выбранного проекта — доступные ему образы, flavors, сети и квоты с учётом политик сервисов. Если пользователь видит чужие ресурсы, не может создать VM при свободной квоте либо экземпляр остаётся в ошибочном состоянии, проверяют назначения проектов и ролей в Keystone, область действия токена, политики доступа сервисов, квоты и сообщения API, затем журналы Nova, Neutron, Glance или Cinder по идентификатору запроса.

Из каких слоёв состоит частное облако OpenStack

Типовые инфраструктурные слои OpenStack

Слой	Состав	Что нужно спроектировать
Control plane	API-сервисы, Keystone, планирование Nova, Placement, базы данных, очереди сообщений и связанные службы	Доступность управляющих компонентов, резервирование зависимостей, обновления, секреты, мониторинг и восстановление.
Compute	Физические серверы с `nova-compute`, выбранным драйвером и, часто, QEMU/KVM/libvirt	Профили CPU и памяти, совместимость оборудования, локальные ресурсы, размещение VM, обслуживание и запас ёмкости.
Сеть	Сеть управления, API, tenant-трафик, внешняя связность и backend Neutron	Разделение потоков, MTU, маршрутизация, адресация, физические uplink, безопасность и отказ доменов сети.
Хранение	Хранилище образов, корневых дисков по выбранной схеме и томов Cinder	Производительность, доступность, домены отказа, интеграция backend-драйверов, защита и восстановление данных.

Control plane можно отделять от compute-узлов или совмещать в ограниченных сценариях, но это архитектурный выбор с последствиями для изоляции ресурсов, обновлений и отказов. Универсального минимального числа серверов, CPU, RAM или сетевых интерфейсов для OpenStack нет: оно зависит от активных сервисов, требований к высокой доступности, backend-хранилища, сетевой схемы и профиля нагрузки.

Способ установки также не универсален. Средства развёртывания имеют собственные матрицы совместимости с релизами OpenStack, операционными системами и топологиями. Инструмент выбирают только после проверки его официального руководства и поддерживаемой версии для целевого релиза, а не потому, что какой-либо способ считается «стандартной» установкой OpenStack.

Когда OpenStack оправдан, а когда достаточно кластера виртуализации

Признаки обоснованного выбора OpenStack

Преимущества

✅Несколько команд или подразделений регулярно запрашивают изолированные ресурсы и должны управлять ими в границах проектов.
✅VM, сети и тома нужно создавать повторяемо через API, инфраструктуру как код и CI/CD, а не через индивидуальные заявки администраторам.
✅Нужны квоты, роли, каталог образов и контролируемое самообслуживание пользователей.
✅Вычислительные, сетевые и компоненты хранения требуется развивать или масштабировать как самостоятельные слои.
✅Есть команда, готовая сопровождать распределённую платформу, её зависимости, обновления и диагностику.

Недостатки

❌Небольшое число VM создаётся редко и почти всегда администраторами.
❌Главная задача — централизованно управлять несколькими хостами и VM, а не предоставлять внутренний IaaS-сервис.
❌Нет владельца облачной платформы, процессов поддержки API, мониторинга и управления изменениями.
❌Сеть и хранилище нельзя подготовить под выбранные backend-компоненты либо их эксплуатация не укладывается в компетенции команды.

Анти-паттерн: внедрять OpenStack только потому, что уже есть KVM-хосты

Несколько серверов с KVM не образуют частное облако автоматически. Если нет потребности в проектах, квотах, API и самообслуживании, добавление OpenStack создаёт control plane, сетевые и хранилищные зависимости без пропорциональной пользы. В таком случае кластер vSphere, Hyper-V, Proxmox VE либо решение централизованного управления поверх KVM/libvirt обычно легче сопровождать.

Выбор по характеру задачи

Сценарий	Что обычно подходит	Почему
Небольшой парк серверных VM, операции выполняет одна команда администраторов	vSphere, отказоустойчивый кластер Hyper-V, Proxmox VE или решение централизованного управления поверх KVM/libvirt	Нужны управление хостами и VM, а при необходимости — миграции и кластерные функции конкретной платформы, но не обязательно облачное самообслуживание. Наличие HA и миграций проверяют для выбранного состава решения.
Несколько внутренних команд регулярно создают тестовые и прикладные среды	OpenStack при наличии готовности к эксплуатации	Проекты, квоты, API и каталог образов позволяют стандартизировать выдачу ресурсов.
Постоянная автоматическая выдача инфраструктуры из конвейеров разработки	OpenStack или другое решение с подходящим API и моделью самообслуживания	Ценность создаёт не KVM сам по себе, а программно управляемое предоставление ресурсов.
Нужно сравнить платформы виртуализации в целом	Отдельный проект оценки	Сопоставляют не только гипервизор, но и поддержку, совместимость, миграции, HA, хранение, сеть, лицензирование и навыки команды.

Для сравнения VMware, Hyper-V, Proxmox VE, KVM/QEMU/libvirt и Xen по более широкому набору критериев используйте материал VMware, Hyper-V, Proxmox, KVM и Xen: выбор платформы виртуализации. Расчёт хостов, запаса при отказе, сети и хранилища относится к отдельному проектированию: Как спроектировать виртуальную инфраструктуру для продакшена и 1С.

OpenStack vs VMware: сравнивать нужно одинаковые уровни

Сравнение «OpenStack или один ESXi-хост» некорректно: это компоненты разных уровней. VMware ESXi — гипервизорный слой, сопоставимый по назначению со стеком QEMU/KVM/libvirt, хотя архитектуры и модель поставки различаются. vCenter Server и vSphere относятся к централизованному управлению виртуальной инфраструктурой. OpenStack — управляющая платформа частного IaaS-облака, которая включает модель проектов, квот, API и самообслуживания.

Корректные уровни сопоставления OpenStack и VMware

Уровень	OpenStack / KVM-экосистема	VMware-экосистема	Что сравнивать
Исполнение VM	QEMU/KVM, обычно под управлением libvirt	ESXi	Поддержку гостевых ОС и оборудования, сетевые и хранилищные возможности, производительность, операционные ограничения.
Централизованное управление	Сервисы OpenStack управляют ресурсами через собственную распределённую архитектуру	vCenter Server в составе vSphere	Управление хостами и VM, интеграции, эксплуатационные процессы, лицензирование и поддерживаемые кластерные функции.
Частное облако и самообслуживание	Проекты, роли, квоты, API, образы, автоматизация	Только тот набор VMware-компонентов и автоматизации, который в рассматриваемой версии действительно предоставляет аналогичные функции	Модель арендаторов, каталог услуг, выдачу ресурсов, политики, API и интеграцию с процессами организации.

Один vCenter не следует считать прямым эквивалентом OpenStack-проектов, квот и self-service-механизмов. В VMware-среде часть похожих возможностей может предоставляться дополнительными продуктами, пакетами, интеграциями или автоматизацией; состав и права использования необходимо проверять для конкретной версии и подписки. Это же относится к VMware HA, DRS, сетевым и хранилищным функциям: они не появляются из одного факта наличия ESXi или vCenter. О базовой роли vCenter и кластера — в статье VMware vSphere и vCenter Server: установка VCSA и добавление хостов, о HA и DRS — в VMware vSphere HA и DRS: перезапуск VM и балансировка ресурсов.

Поддержку, эксплуатационную модель и лицензирование сравнивают отдельно. Нельзя заранее утверждать, что OpenStack дешевле, проще масштабируется или автоматически надёжнее vSphere: итог зависит от архитектуры, коммерческих условий, состава интеграций, используемого оборудования и компетенций команды. Актуальные особенности VMware-лицензирования рассматриваются в Лицензирование VMware vSphere, ESXi и vCenter: редакции, подписки и ограничения.

Эксплуатационные затраты и риски до запуска проекта

Control plane и зависимости. Нужно обеспечить наблюдаемость API-сервисов, очередей сообщений, баз данных, балансировщиков и механизмов идентификации. Отказ control plane может не остановить уже работающие VM, но ограничить создание, изменение или восстановление ресурсов.
Сеть. Neutron требует согласования логической сети облака с физической фабрикой, внешними сетями, MTU, маршрутами, адресным планом и политиками доступа. Ошибки часто проявляются не при запуске VM, а при подключении tenant-сетей или внешней связности.
Хранение и данные. Образы, корневые диски и Cinder-тома имеют разные пути и backend-зависимости. Снапшоты, репликация и восстановление нужно проверять для выбранного backend, а не выводить из наличия API Cinder.
Обновления. Версии сервисов, ОС, драйверов, сетевого backend и СХД обновляют по совместимому плану. Нужны стенд или контролируемая среда проверки, регламент отката и понимание поддерживаемого пути обновления.
Безопасность плоскости управления. Keystone-политики, секреты сервисов, доступ к API, изоляция сетей управления и аудит действий требуют отдельной настройки. Изоляция VM не заменяет защиту control plane; общие принципы разобраны в Защита виртуальных машин: изоляция, шифрование и границы гипервизора.
Резервное копирование и DR. Высокая доступность сервисов, перезапуск VM и резервная копия данных решают разные задачи. Для критичных приложений отдельно определяют RPO, RTO, порядок восстановления и ответственность владельцев данных.
Компетенции и процессы. Команде нужны навыки Linux, сетей, хранилищ, API, диагностики распределённых сервисов и управления изменениями. Без этого преимущества самообслуживания переходят в неконтролируемое потребление ресурсов.

HA не возникает по умолчанию

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

Как принять решение о внедрении OpenStack

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

1
Зафиксируйте потребителей ресурсов
Перечислите команды, проекты и типы нагрузок, которые будут получать VM, сети и тома. Ожидаемый результат — понятна потребность в изоляции арендаторов и самообслуживании. Если почти все операции выполняет одна администраторская команда для ограниченного числа VM, оцените обычный кластер как основной вариант.
2
Проверьте повторяемость выдачи
Определите, какие ресурсы должны создаваться через API и шаблоны: экземпляры, сети, порты, тома, правила доступа. Ожидаемый результат — есть повторяемые сценарии, которые экономят ручные операции. Если каждый запрос уникален и редок, автоматизация OpenStack может не окупить сложность.
3
Выберите целевой релиз и способ развёртывания
Сверьте официальный жизненный цикл выбранного релиза OpenStack, совместимость ОС, compute drivers, сетевых и хранилищных backend-компонентов, а также поддерживаемые топологии выбранного инструмента развёртывания. Ожидаемый результат — зафиксирован совместимый стек. При несовместимости не компенсируйте её ручными обходами: замените компонент, релиз или способ развёртывания.
4
Спроектируйте границы control plane, сети и хранения
Отдельно определите домены отказа, потоки управления и tenant-трафика, внешние сети, хранение образов и Cinder-томов, а также зависимости control plane. Ожидаемый результат — для каждого слоя есть владелец, схема мониторинга и порядок восстановления. Если такой схемы нет, проект остаётся набором серверов, а не готовой облачной платформой.
5
Проведите пилот по пользовательскому пути
Проверьте не только запуск тестовой VM, но и полный путь: вход в проект, применение квоты, выдачу образа и flavor, создание сети, подключение тома, автоматизацию через API и удаление ресурсов. Ожидаемый результат — измеримый и воспроизводимый сценарий для внутренней команды. Отклонения локализуют по идентификаторам запросов в сервисах Keystone, Nova, Neutron, Glance, Placement и Cinder, а затем исправляют в соответствующем слое.

Термины в статье

Виртуализация: Технология абстрагирования физических вычислительных ресурсов, позволяющая создавать виртуальные серверы, хранилища, сети и другие логические ресурсы.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Виртуальная сеть: Виртуальная сеть — логическая сеть, реализованная программными средствами для связи ВМ и других виртуальных нагрузок между собой и, при необходимости, с физической сетью.
Высокая доступность: Высокая доступность (HA) — способность системы сохранять сервис или автоматически восстанавливать его с минимальным простоем при отказе компонентов.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Домен отказа: Домен отказа — группа компонентов с общей причиной недоступности, отказ которой может одновременно вывести из строя несколько копий данных или сервисов.
Имя хоста: Имя хоста — идентификатор узла в сети и операционной системе, используемый для отображения, журналирования и разрешения имени в IP-адрес при наличии DNS или hosts.
Системная служба: Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
Снимок состояния: Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
Частное облако: Частное облако — облачная среда для исключительного использования одной организацией с централизованным управлением и самообслуживанием пользователей.
Cinder: Cinder — служба блочного хранения OpenStack, создающая и подключающая виртуальным машинам постоянные тома через драйверы систем хранения.
Cloud-Init: Cloud-Init — система начальной настройки облачных экземпляров, применяющая метаданные и пользовательские данные при первом запуске виртуальной машины.
Glance: Glance — служба образов OpenStack, которая хранит, каталогизирует и предоставляет образы виртуальных машин другим компонентам облака через API.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
Heat: Heat — сервис оркестрации OpenStack, который по шаблону HOT или CloudFormation создаёт и связывает ресурсы облака в единый стек.
Horizon: Horizon — веб-панель управления OpenStack, предоставляющая графический доступ к проектам, ресурсам и сервисам через API облачной платформы.
Hyper-V: Платформа виртуализации Microsoft с гипервизором типа 1, доступная как роль Windows Server и компонент Windows 10/11 Pro, Enterprise и Education.
Keystone: Keystone — служба идентификации OpenStack, которая аутентифицирует пользователей и сервисы, выдаёт токены и управляет назначением ролей для доступа к проектам и API.
KVM: Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
libvirt: libvirt — открытый набор библиотек, API, служб и утилит для унифицированного управления ВМ, контейнерами, сетями и хранилищами на платформах виртуализации.
Neutron: Neutron — сервис сетей OpenStack, предоставляющий API для сетей, подсетей, портов, маршрутизаторов и правил групп безопасности; передачу трафика реализует выбранный сетевой backend.
Nova: Nova — вычислительная служба OpenStack для предоставления вычислительных экземпляров и управления ими через планировщик и драйверы; сама Nova не является гипервизором.
OpenStack: Открытая облачная платформа для построения публичных и частных IaaS облаков, управляющая вычислениями, хранением и сетями через API.
OpenStack Placement: OpenStack Placement — служба API OpenStack для учёта ресурсов, их характеристик и распределений; она выдаёт кандидатов планировщику, но не запускает виртуальные машины.
Proxmox: Открытая платформа серверной виртуализации на базе Debian, использующая QEMU/KVM для виртуальных машин и LXC для системных Linux-контейнеров.
QEMU: QEMU — открытый эмулятор вычислительных систем и монитор виртуальных машин; в Linux он может использовать KVM для виртуализации с аппаратным ускорением.
SSH: SSH — криптографический сетевой протокол для удалённого доступа и передачи данных, аутентифицирующий стороны и защищающий сеанс от перехвата.
Swift: Swift — распределённое объектное хранилище OpenStack, сохраняющее данные как объекты в контейнерах и предоставляющее доступ к ним через HTTP API.
vCPU: vCPU — виртуальный логический процессор, предоставляемый виртуальной машине; гипервизор планирует его выполнение на процессорных ресурсах хоста.
VMware: VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
Xen: Xen — гипервизор первого типа, работающий непосредственно на сервере и поддерживающий режимы виртуализации HVM, PV и PVH.