Нужна ли высокая доступность для виртуализации разработки?

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

Должен ли тестовый контур полностью повторять продакшен?

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

Можно ли размещать продакшен на одном хосте?

Одиночный хост может быть рациональным для небольшой или некритичной нагрузки, если бизнес принимает риск простоя. Однако снимок VM не заменяет резервное копирование и не защищает от отказа самого хоста, его локального хранилища или ошибок данных в гостевой системе. Если продакшен должен автоматически восстанавливать критичные VM после отказа узла, обычно требуется несколько совместимых хостов, централизованное управление, подходящие сеть и хранилище. Расчёт должен подтвердить, что после исключения одного узла оставшихся ресурсов CPU, RAM, хранилища и сети достаточно для критичных VM. Также заранее определяют приоритет восстановления сервисов и проверяют план восстановления.

Обеспечивает ли HA непрерывную работу сервера 1С?

HA виртуализации решает задачу восстановления VM после отказа узла, а не непрерывности прикладного сервиса. При перезапуске VM с сервером 1С или СУБД гостевая ОС и приложение запускаются заново, поэтому пользователи теряют активные подключения, а выполнявшиеся операции прерываются. Для требований к непрерывной доступности необходимы отдельные механизмы на уровне приложения: например, отказоустойчивость СУБД или несколько экземпляров веб-сервиса. Также HA не устраняет автоматически отказ общего хранилища или сети, ошибку данных внутри гостевой ОС и неверную конфигурацию. Поэтому для критичных сервисов нужно отдельно определить допустимый простой, RTO, RPO, порядок восстановления и зависимости между компонентами.

Что проверить перед выбором платформы виртуализации?

Сначала проверьте совместимость серверов, CPU, сетевых и storage-адаптеров, версий firmware и целевого релиза гипервизора по HCL платформы. Отдельно подтвердите лицензии и права на централизованное управление, миграцию, HA, репликацию и нужные компоненты хранения.

Как спроектировать виртуальную инфраструктуру для продакшена и 1С

Q: Нужно ли проверять сеть между сервером 1С и СУБД в разных VM?

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

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

С чего начать: карточка каждой нагрузки

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

Минимальный набор исходных данных для расчёта

Сервис или роль	Что зафиксировать	Зачем это нужно
Назначение и владелец	Приложение, среда, ответственный, число пользователей или транзакций	Позволяет отличить временный стенд от критичной бизнес-нагрузки
Критичность и простой	Допустимый простой, целевые RTO и RPO, допустимо ли ручное восстановление	Определяет необходимость нескольких узлов, HA и отдельного плана восстановления
CPU	Пиковое и обычное потребление, длительность пиков, сезонность	Даёт основу для назначения vCPU и расчёта конкуренции на хостах
Память	Рабочее потребление, пики, paging внутри ОС, необходимость фиксированного объёма	Позволяет оценить физическую RAM без расчёта только по минимальным настройкам VM
Диски	Полезная ёмкость, темп роста, IOPS, чтение/запись, задержка, последовательный или случайный профиль	Разделяет задачу объёма и задачу производительности хранилища
Сеть	Пиковый трафик, направления, VLAN, внешние зависимости, чувствительность к задержке	Нужна для выбора пропускной способности и разделения потоков
Зависимости	СУБД, Active Directory, файловые ресурсы, лицензирующие серверы, внешние API	Позволяет не принять за отказоустойчивый сервис VM, зависящую от одиночного компонента
Лицензии и совместимость	Лицензирование ОС, СУБД, приложений, гипервизора и оборудования	Исключает архитектуру, которую нельзя легально использовать или поддерживать

Порядок проектирования виртуальной инфраструктуры

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

1
Разделите сервисы по средам и критичности
Отдельно отметьте продакшен, разработку, тестирование, учебные стенды и временные задачи. Для каждой роли зафиксируйте допустимый простой и последствия недоступности. Результат — понятно, какие VM можно остановить для обслуживания, а какие должны быть восстановлены после отказа узла. Если владелец сервиса не может назвать допустимый простой, зафиксируйте это как нерешённое требование, а не подменяйте его предположением.
2
Соберите фактические пики
Для существующих серверов возьмите историю наблюдений за период, включающий штатные пики: закрытие периода, массовые входы пользователей, регламентные задания, резервное копирование, обновления и отчёты. Для новых систем запросите профиль у разработчика или поставщика и пометьте его как прогноз. Результат — для каждой нагрузки известны не только средние, но и пиковые CPU, RAM, дисковая активность и сеть. Если данных нет, сначала разверните пилот или заложите контролируемую возможность расширения.
3
Назначьте стартовые ресурсы VM
Назначайте vCPU и память по наблюдаемому рабочему профилю и документированным требованиям гостевой ОС и приложения. Размер виртуального диска рассчитывайте из текущих данных, роста, служебного пространства и операций платформы. Результат — у каждой VM есть обоснованный стартовый профиль, а не одинаковая типовая конфигурация. Если приложение не укладывается в прогноз, проверяйте отдельно CPU, память, задержки хранилища и сеть, а не увеличивайте все параметры одновременно.
4
Сложите потребление и добавьте сценарии отказа
Сначала посчитайте одновременную рабочую нагрузку, затем отдельно добавьте пики, плановое обслуживание, рост и — для HA — размещение VM отказавшего узла на оставшихся хостах. Результат — известна требуемая полезная ёмкость кластера и её распределение по узлам. Если после исключения одного хоста критичные VM не помещаются, кластер не имеет достаточного резерва для заявленного сценария.
5
Проверьте технические и лицензионные ограничения до закупки
Сверьте серверы, CPU, сетевые и storage-адаптеры, версии firmware и целевой релиз гипервизора с Hardware Compatibility List выбранной платформы. Отдельно проверьте права на централизованное управление, миграцию, HA, репликацию и нужные компоненты хранения. Результат — есть перечень поддерживаемых сочетаний и требуемых лицензий. Если компонент отсутствует в HCL или условия лицензии не подтверждены, не включайте его в поддерживаемую целевую архитектуру без альтернативы.

Как перевести нагрузку в CPU, память, хранилище и сеть

vCPU — это не выделенное физическое ядро, а виртуальный логический процессор, который гипервизор планирует на CPU хоста. Поэтому сумма назначенных vCPU не равна автоматически требуемому числу ядер. Для расчёта важны одновременный спрос, длительность пиков и чувствительность приложения к задержке планирования. Увеличивать число vCPU «на всякий случай» не следует: крупной VM может быть сложнее получить нужное процессорное время.

Память планируют по фактическому рабочему набору приложений и гостевой ОС, а не только по установленному минимуму. Для критичных VM отдельно учитывают память СУБД, файлового кэша, Java-процессов и иных потребителей, которые могут занимать RAM длительно. Свободная память внутри гостя сама по себе не доказывает, что объём можно безопасно уменьшить: ОС использует её для кэша.

У хранилища две независимые характеристики: ёмкость и производительность. Ёмкость включает виртуальные диски, рост данных, журналы, временные файлы, образы, а также место, требуемое операциями платформы. Производительность описывают IOPS, соотношением чтения и записи, размером и случайностью операций, пропускной способностью и задержкой. Для VMware логический контейнер размещения файлов VM называется datastore; он не равен одному физическому диску. О вариантах размещения VM в этой платформе — в статье «Datastore и VMware vSAN: как организовать хранение виртуальных машин».

Сеть считают по потокам, а не только по числу портов: управление хостами, трафик VM, доступ к хранилищу, резервное копирование и миграция имеют разные профили. Live Migration — перенос работающей VM между хостами — обычно требует предсказуемой связности и пропускной способности; она не должна незаметно вытеснять критичный пользовательский трафик. Подходы к логическому и физическому разделению потоков разобраны в статье «Сети виртуальных машин в ESXi, Hyper-V и Proxmox VE».

Расчёт выполняют для общего временного окна и повторяют для нормального режима, обслуживания и заявленных отказов

Ресурс	Как получить требование	Что проверить
CPU	За один и тот же пиковый интервал определите фактически занятые процессорные ресурсы каждой нагрузки и сложите спрос одновременно работающих сервисов. При переходе на другое поколение CPU используйте результаты испытания приложения или сопоставимый тест, а не сравнение только по числу ядер и частоте.	После размещения VM и исключения заявленного отказавшего узла не возникает неприемлемой задержки планирования; учтены ресурсы гипервизора и служебных компонентов.
RAM	Сложите рабочие наборы гостевых ОС и приложений в совместный пик, отдельно учтите VM с фиксированной памятью, затем добавьте память гипервизора, управляющих компонентов и резерв для заявленного сценария отказа.	Расчёт не опирается на вытеснение памяти или paging как на штатный способ получить аварийную ёмкость.
Ёмкость хранилища	Сложите текущие данные, прогноз роста, журналы, временные данные, образы и пространство для снимков и служебных операций. Сначала получите требуемую полезную ёмкость, затем переведите её в сырую по правилам защиты и эффективности выбранного хранилища.	Расчёт сохраняет рабочий свободный запас и не считает дедупликацию, сжатие или thin provisioning гарантированным источником места без измерений.
Производительность хранилища	Суммируйте IOPS и пропускную способность нагрузок, активных в один период, сохраняя их размеры операций и долю чтения и записи.	Требуемая задержка выдерживается не только в нормальном режиме, но и в предусмотренных проектом режимах отказа, восстановления или перестроения хранилища.
Сеть	Для каждого физического пути сложите одновременные потоки VM, хранения, резервного копирования, управления и миграции с учётом протокольных накладных расходов.	После отказа предусмотренного канала оставшейся полосы достаточно, а служебный трафик не вытесняет критичные потоки.

Не суммируйте только минимально назначенные ресурсы

Overcommitment CPU, памяти или хранилища допустим только как осознанное следствие измеренного неполного одновременного потребления. Особенно опасно считать свободной ёмкостью thin-provisioned хранилища весь номинальный размер виртуальных дисков: при фактическом заполнении места может не хватить для работы VM или служебных операций. Детали наблюдения за метриками и признаками конкуренции — в статье «Производительность виртуализации: ресурсы VM, overcommitment, метрики и поиск узких мест».

Один хост или кластер из нескольких узлов

Одиночный хост рационален для обучения, лаборатории, разработки, некритичного тестового контура и небольшой нагрузки, если согласован простой при отказе сервера, его локального хранилища, рабочей сети или электропитания. Он остаётся единой точкой отказа для всех размещённых VM. Для него заранее определяют RPO и RTO, место хранения резервных копий и порядок восстановления на заменённом либо временном оборудовании; снимок VM не заменяет такую защиту.

Если продакшен должен автоматически восстановить VM после отказа узла, обычно проектируют несколько совместимых хостов, централизованное управление, необходимые сети и хранилище, соответствующее архитектуре выбранной платформы. Число узлов выбирают проверкой каждого заявленного отказа: поочерёдно исключают узел и убеждаются, что оставшихся CPU, RAM, производительности хранилища и сетевых путей достаточно для критичных VM с учётом ограничений их размещения. Два узла могут быть достаточны только тогда, когда выбранная платформа поддерживает такую топологию, решён вопрос кворума или свидетеля и после отказа одного узла второй выдерживает требуемую нагрузку. N+1 описывает резерв на отказ одного узла, но не заменяет проверку конкретной топологии и общих компонентов.

Высокая доступность VM обычно означает обнаружение сбоя и попытку запустить её на другом узле. Гостевая ОС и приложение при этом перезапускаются, поэтому сервис прерывается. Непрерывность работы требует отдельной отказоустойчивости на уровне приложения, например кластера СУБД или нескольких экземпляров веб-сервиса. HA также не устраняет автоматически отказ общего хранилища, общей сети, ошибку данных в госте или неверную конфигурацию.

Условные сценарии без универсальной плотности VM

Сценарий	Рациональная схема	Что принять заранее
Учебная лаборатория	Один хост или локальные настольные среды; VM можно пересоздавать из шаблонов	Допустимый простой, ограниченная ёмкость, сохранение учебных материалов отдельно от хоста
Некритичный тестовый контур	Один хост либо несколько узлов, если нужны проверки миграции или совместимости	Окна остановки, возможность воспроизведения стенда, изоляция от продакшена
Продакшен с восстановлением при отказе узла	Несколько совместимых хостов с запасом на отказ, подходящими сетью и хранилищем	Какие VM восстанавливаются первыми, N+1-ёмкость, RTO/RPO и проверяемый план восстановления

HA, миграция и репликация решают разные задачи

Живая миграция уменьшает простой при плановом обслуживании; HA перезапускает VM после отказа узла; репликация может помочь переключиться на другую площадку или отдельный сервер, но её допустимая потеря последних изменений зависит от режима и интервала репликации. Ни один из механизмов сам по себе не заменяет резервное копирование. Различия операций миграции, P2V и V2V описаны в статье «Миграция виртуальных машин: live migration, V2V и P2V».

Запас на пики, обслуживание, рост и отказ

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

CPU: оставьте возможность обслужить одновременные пики критичных сервисов и нагрузку после отказа узла, если это требование заявлено.
RAM: учитывайте постоянное потребление критичных VM и не рассчитывайте аварийную ёмкость на агрессивном вытеснении памяти.
Хранилище: резервируйте не только место под данные, но и рабочий запас для роста, журналов, снимков и операций восстановления; контролируйте фактическое занятие thin-provisioned дисков.
IOPS и задержка: проверяйте суммарную конкуренцию VM в один и тот же период, а не производительность одного диска в изоляции.
Сеть: оцените одновременный трафик пользователей, хранилища, миграций и служебных задач; VLAN разделяет трафик логически, но не создаёт дополнительную физическую полосу.
Обслуживание: убедитесь, что при выводе одного узла в обслуживание критичные VM можно разместить на остальных, либо явно согласуйте остановку части сервисов.

Виртуализация сервера 1С и СУБД

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

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

Перед утверждением проекта сверяйте актуальные системные требования и рекомендации фирмы «1С» для используемой версии серверной части, а также документацию выбранной СУБД и ОС. Не переносите требования одной версии платформы 1С или одного варианта СУБД на другой. Если предполагается разделение сервера 1С и СУБД по VM, проверяйте задержку и пропускную способность сети между ними в условиях ожидаемого пика.

HA гипервизора не делает 1С непрерывно доступной

Перезапуск VM с сервером 1С или СУБД после отказа хоста прервёт активные сеансы и транзакции. Требования к доступности данных, переключению СУБД и поведению клиентских подключений проектируют на уровне приложения и СУБД отдельно от HA кластера виртуализации.

Чем отличаются лаборатория, разработка, тесты, продакшен и облачная модель

Среда	Приоритет проектирования	Типичная ошибка или лишнее усложнение
Лаборатория и обучение	Простота, низкая стоимость, возможность быстро пересоздать стенд	Кластерная архитектура, резервирование всех компонентов и сложные процессы эксплуатации без требования к доступности
Разработка	Повторяемость окружений, изоляция команд, быстрый выпуск VM и шаблонов	Производственные данные и полномасштабная отказоустойчивость каждой временной VM
Тестирование	Воспроизводимость, контроль версий, сходство с тестируемой частью продакшена	Предположение, что стенд обязан копировать весь продакшен, если цель теста этого не требует
Продакшен	Предсказуемая производительность, управляемое обслуживание, восстановление и контроль изменений	Непроверенный overcommitment и одиночные общие точки отказа для критичных сервисов
Частное или гибридное облако	Модель предоставления ресурсов, самообслуживание, квоты, интеграция площадок и процессов	Вывод, что сам гипервизор автоматически создаёт облако или решает вопросы доступности

Частное облако и гибридная облачная схема описывают прежде всего модель размещения и предоставления ресурсов, а не свойство конкретного гипервизора. Гибридная схема добавляет требования к каналам связи, идентификации, размещению данных, стоимости исходящего трафика и процедурам аварийного переключения. OpenStack и другие облачные управляющие слои не отменяют расчёт вычислений, хранилища и сети; границы его применения рассмотрены в статье «OpenStack как частное облако поверх KVM».

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

Выбор платформы виртуализации делают после фиксации сценария, а не по одному названию функции. Централизованное управление, миграция, HA, балансировка и репликация могут требовать отдельных компонентов, совместимого хранилища, нескольких узлов или определённой редакции и подписки. Для целевого проекта зафиксируйте продукт, релиз, редакцию или подписку, дату проверки и официальные источники: документацию VMware vSphere и VMware Compatibility Guide, документацию Microsoft Hyper-V и Microsoft Product Terms, руководство администратора Proxmox VE. Техническая доступность функции не подтверждает право её использования или наличие поддержки. Состав функций, условия лицензирования и поставки меняются, поэтому внутренние статьи и прежние спецификации не заменяют проверку актуальных официальных материалов перед закупкой.

Например, в экосистеме VMware перенос включённой VM между ESXi-хостами называется vMotion, но техническое наличие ESXi не подтверждает право и готовность использовать эту функцию: нужны совместимые хосты, подходящая инфраструктура и права конкретного пакета. VMware HA и DRS также решают разные задачи. Их предпосылки и проверка кластера описаны в статье «VMware vSphere HA и DRS: автоматический перезапуск VM и балансировка ресурсов», а актуальная модель поставки — в материале о лицензировании VMware vSphere, ESXi и vCenter.

Для Hyper-V живая миграция, Storage Migration, Replica и отказоустойчивый кластер — отдельные механизмы с разными целями и предпосылками; их нельзя считать взаимозаменяемыми. Для Proxmox VE сам кластер также не включает HA автоматически: требуются устойчивый quorum, подходящее размещение дисков и запас ресурсов. Практические границы этих сценариев описаны в статьях о Hyper-V Live Migration, Replica и HA и о VM, LXC, кластере и HA в Proxmox VE. Детальное сравнение платформ — в отдельной статье.

Зависимость от версии и вендора

Названия функций, пунктов BIOS/UEFI, меню, кнопок, статусов и точные инфраструктурные требования зависят от модели сервера, поколения, релиза гипервизора, firmware, утилиты управления и лицензии. Для целевой конфигурации сверяйте официальные руководства производителя сервера и документацию выбранной платформы; универсального пути в BIOS/UEFI нет. Общий порядок проверки расширений CPU приведён в статье «Как включить Intel VT-x, AMD-V и IOMMU в BIOS/UEFI сервера».

Контрольный лист перед утверждением конфигурации

1
Подтвердите модель нагрузки
Проверьте, что для каждой критичной VM известны пики CPU, памяти, дисковой активности, сети, рост и зависимости. Результат — нет строк с ресурсами, назначенными только по шаблону. Если есть неподтверждённые оценки, выделите их в реестре рисков и предусмотрите пилот или запас на расширение.
2
Проверьте сценарий отказа
Мысленно исключите один хост, общий компонент хранения или сеть управления — в пределах заявленной архитектуры — и определите, какие сервисы должны восстановиться, где они запустятся и в каком порядке. Результат — расчёт ёмкости соответствует заявленному RTO. Если ответом является ручное восстановление, это должно быть согласованным свойством среды, а не скрытым ограничением.
3
Сверьте совместимость
Для выбранного релиза проверьте в официальном HCL модель сервера, CPU, контроллеры, сетевые и storage-адаптеры, драйверы и firmware. Результат — все критичные компоненты имеют подтверждённое поддерживаемое сочетание. При несовпадении выбирайте поддерживаемый релиз, адаптер или серверную конфигурацию.
4
Сверьте лицензии и функции
Сопоставьте требуемые функции с конкретной редакцией, подпиской или лицензией: управление, миграцию, HA, репликацию, хранение, ОС, СУБД и приложения. Результат — в спецификации есть не только серверы, но и необходимые права использования. Если функция не входит в подтверждённый состав, измените архитектуру или набор лицензий до запуска проекта.
5
Определите проверку после внедрения
Запланируйте контролируемую проверку запуска критичных VM, сетевой связности, производительности в характерный период, восстановления и процедуры обслуживания на некритичной нагрузке. Результат — проект подтверждается наблюдаемым поведением, а не только успешной установкой гипервизора. Если тест не проходит, сначала локализуйте ограничение по ресурсам, сети, хранилищу или совместимости; не изменяйте параметры наугад.

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

Виртуализация: Технология абстрагирования физических вычислительных ресурсов, позволяющая создавать виртуальные серверы, хранилища, сети и другие логические ресурсы.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Высокая доступность: Высокая доступность (HA) — способность системы сохранять сервис или автоматически восстанавливать его с минимальным простоем при отказе компонентов.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Гиперконвергентная инфраструктура: Гиперконвергентная инфраструктура — архитектура кластера, объединяющая вычисления, хранение и виртуализацию на узлах с локальными дисками под единым программным управлением.
Лимит ресурсов: Лимит ресурсов — верхняя граница потребления процессора, памяти или другого ресурса виртуальной машиной либо группой, действующая даже при наличии свободной ёмкости.
Резервирование ресурсов: Резервирование ресурсов — настройка минимальной доли CPU, памяти или иных ресурсов, которую гипервизор выделяет виртуальной машине или пулу при конкуренции.
Снимок состояния: Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
Физический диск: Физический диск — отдельный HDD, SSD или иной накопитель, распознанный RAID-контроллером как член массива либо как независимое устройство.
Хост виртуализации: Хост виртуализации — физический сервер или вычислительная система, на которой работает гипервизор и размещаются виртуальные машины; его CPU, память, сеть и хранилище распределяются между гостями.
Частное облако: Частное облако — облачная среда для исключительного использования одной организацией с централизованным управлением и самообслуживанием пользователей.
Datastore: Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
DRS: Функция VMware vSphere для управления размещением ВМ в кластере и балансировки ресурсов хостов с помощью рекомендаций или автоматических миграций vMotion.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
Hardware Compatibility List: Hardware Compatibility List — перечень проверенных сочетаний оборудования и ПО, определяющий конфигурации, поддерживаемые для заданной платформы или продукта.
Hyper-V: Платформа виртуализации Microsoft с гипервизором типа 1, доступная как роль Windows Server и компонент Windows 10/11 Pro, Enterprise и Education.
IOPS: IOPS — число завершённых операций ввода-вывода в секунду, которое накопитель, RAID-массив или СХД обеспечивает при заданном профиле нагрузки.
Live Migration: Перенос работающей виртуальной машины между хостами без выключения гостевой ОС; переключение обычно вызывает краткую паузу, а сохранение соединений зависит от сети и платформы.
OpenStack: Открытая облачная платформа для построения публичных и частных IaaS облаков, управляющая вычислениями, хранением и сетями через API.
Overcommitment: Практика назначения виртуальным машинам суммарно большего объема CPU, памяти или хранилища, чем физически доступно хосту, в расчете на неполное одновременное потребление.
P2V: P2V — перенос установленной ОС, приложений и данных с физического сервера в виртуальную машину с адаптацией системы к виртуальному оборудованию.
Proxmox: Открытая платформа серверной виртуализации на базе Debian, использующая QEMU/KVM для виртуальных машин и LXC для системных Linux-контейнеров.
Storage Migration: Storage Migration — механизм Hyper-V для переноса файлов работающей виртуальной машины между хранилищами без смены хоста, на котором она выполняется.
V2V: V2V — перенос существующей виртуальной машины с одной платформы виртуализации на другую с преобразованием дисков и конфигурации под целевой гипервизор.
vCPU: vCPU — виртуальный логический процессор, предоставляемый виртуальной машине; гипервизор планирует его выполнение на процессорных ресурсах хоста.
vMotion: Технология VMware vSphere для переноса включённой виртуальной машины между хостами ESXi без выключения гостевой ОС; при переключении возможна краткая пауза.
VMware: VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
VMware ESXi: VMware ESXi — гипервизор типа 1, устанавливаемый непосредственно на совместимый физический сервер для запуска и управления виртуальными машинами.
vSphere: Платформа виртуализации VMware, включающая гипервизор ESXi и средства управления vCenter для корпоративной инфраструктуры