Сервер виртуализации: что это такое, принцип работы и выбор оборудования

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

Мы в Work System подбираем серверы для виртуализации под конкретную нагрузку: 1С, СУБД, VDI, корпоративные приложения, тестовые среды, резервное копирование. В таких проектах важно не просто купить мощный физический сервер, а проверить совместимость с гипервизором, рассчитать запас по памяти и I/O, продумать отказоустойчивость, сеть и хранение данных.

По данным VMware vSphere 8 Documentation от VMware, 2023, ESXi устанавливается напрямую на сервер и управляет CPU, памятью и I/O. Это базовая архитектура enterprise-виртуализации: сервер работает как ресурсный пул, а каждая виртуальная машина получает изолированную гостевую ОС и выделенные виртуальные ресурсы.

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

Такое серверное решение часто путают с VPS/VDS. VPS или VDS — это один виртуальный сервер с выделенными vCPU, RAM и диском, который пользователь получает от провайдера или администратора платформы. Сервер виртуализации — уровнем ниже: физическое оборудование, на котором могут работать несколько виртуальных серверов, несколько виртуальных машин, шаблоны ОС, тестовые контуры и продуктивные приложения. Терминология VPS/VDS исторически сложилась в хостинг-индустрии для обозначения арендуемых изолированных ВМ, тогда как сервер виртуализации — это инфраструктурный слой, которым управляет собственная IT-команда или интегратор.

По документации VMware vSphere Documentation от VMware, 2023, гипервизор предоставляет ВМ виртуальные CPU, диски и сетевые адаптеры. Виртуальный сервер не имеет прямого доступа к аппаратным устройствам: он видит виртуальный диск, виртуальную сетевую карту и виртуальный CPU, а доступ к реальному оборудованию контролирует гипервизор.

Практический вывод простой: если вы выбираете платформу под инфраструктуру виртуальных серверов, нужно оценивать не только параметры отдельной ВМ, а весь физический сервер, СХД, сеть, гипервизор и сценарии отказа. Типичная ошибка — считать, что «виртуальный» означает «не требующий железа». Каждый виртуальный сервер потребляет ресурсы физического сервера, и при пике несколько виртуальных машин могут начать конкурировать за CPU, RAM или дисковый ввод-вывод.

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

В архитектуре Type 1 гипервизор устанавливается на bare metal. По данным VMware vSphere 8 Documentation от VMware, 2023, ESXi напрямую взаимодействует с CPU, памятью и I/O-устройствами хоста. По Microsoft Hyper-V Documentation от Microsoft, 2024, Hyper-V тоже относится к гипервизорам первого типа: он планирует выполнение гостевых систем и изолирует их от аппаратного слоя через аппаратную виртуализацию процессора.

На низком уровне сервер работает так: гостевой код исполняется на физических ядрах CPU, но привилегированные операции перехватываются гипервизором. В Intel 64 and IA-32 Architectures Software Developer's Manual от Intel описан механизм VM-exit: при обращении гостевой ОС к управляющим регистрам, прерываниям или другим защищённым операциям управление передаётся гипервизору. В AMD64 Architecture Programmer's Manual от AMD аналогичные функции реализованы через AMD-V и структуры VMCB.

Память виртуальных машин изолируется через second-level address translation. У Intel это EPT (Extended Page Tables), у AMD — NPT (Nested Page Tables). Для ввода-вывода применяются Intel VT-d и AMD-Vi/IOMMU: устройство получает доступ только к разрешённым физическим адресам, а не ко всей памяти сервера. Это критично для безопасности, SR-IOV, passthrough-устройств и производительных сетевых адаптеров. Прерывания абстрагируются через virtual interrupt delivery: LAPIC/IOAPIC и interrupt remapping перехватываются гипервизором и доставляются гостю как виртуальные IRQ — без прямого доступа гостя к реальному контроллеру.

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

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

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

Гипервизоры Type 1 обычно применяются в enterprise из-за минимального слоя абстракции между аппаратным обеспечением и гостевой ОС. Гипервизоры Type 2 работают поверх хостовой операционной системы — это добавляет накладные расходы, но упрощает установку и управление. Контейнеры разделяют ядро ОС, поэтому не обеспечивают полную изоляцию гостевых операционных систем и не подходят для сценариев, где каждой нагрузке нужна собственная ОС. Дальше в статье мы фокусируемся на Type 1 и enterprise-платформах — именно они применяются для on-prem серверов виртуализации.

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

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

По материалу Work-Systems «ИТ-инфраструктура: что такое, состав, управление и требования», 2025, архитектура инфраструктуры включает серверы, СХД, сеть, операционные системы, гипервизоры, мониторинг и резервное копирование. Для виртуализации критичны не только CPU и RAM, но и каналы передачи данных, резервные копии, централизованное управление и физическая инфраструктура: ИБП, охлаждение, стойки.

Сервер виртуализации полезен в нескольких типовых сценариях:

• размещение корпоративных сервисов на нескольких виртуальных машинах;
• создание тестовых и dev-сред без закупки отдельного сервера;
• запуск серверов для 1С, СУБД, веб-приложений и внутренних систем;
• перенос устаревших физических серверов в виртуальную среду (P2V-миграция);
• построение HA-кластера с перезапуском ВМ на другом хосте;
• централизованное резервное копирование виртуальных машин;
• быстрый апгрейд инфраструктуры без привязки приложения к конкретному железу.

В проекте для промышленно-продовольственного кластера «Косино» наши инженеры помогли построить кластер виртуализации и хранения данных с учётом требований к снэпшотам, репликации, дедупликации, кластеризации и нарезке LUN. Заказчику было важно оптимизировать ресурсы будущей IT-инфраструктуры и сохранить моновендорное решение. В результате к интеграции рекомендовали платформу Huawei с ПО для виртуализации, бэкапов и коммутации.

Практическая рекомендация: сервер виртуализации оправдан, когда у компании есть несколько серверных ролей, требования к быстрому восстановлению или регулярная потребность запускать новые сервисы. Если нагрузка одна, предсказуемая и критична к bare-metal latency — иногда выгоднее оставить её на физическом сервере. Но это нужно проверять по профилю приложения.

Оптимизация аппаратных ресурсов достигается за счёт консолидации: вместо нескольких физических серверов компания использует один или несколько мощных серверов виртуализации. Экономия появляется не «автоматически», а после инвентаризации нагрузок, расчёта CPU/RAM/storage и проверки, какие виртуальные машины могут безопасно сосуществовать на одном хосте.

Универсальный коэффициент консолидации лучше не задавать заранее. Его рассчитывают по фактическим CPU, RAM, IOPS, latency и требованиям HA. Корректный подход — считать эффект для конкретной инфраструктуры: количество физических серверов, средняя и пиковая загрузка CPU, потребление RAM, IOPS, объём хранения, энергопотребление, требования к охлаждению и лицензии.

Методику можно описать так:

По данным «Импортозамещение ИТ-инфраструктуры» от IKS Media, 2024, переход начинается с инвентаризации ИТ-активов и зависимостей. Это особенно важно в российских проектах импортозамещения, где могут возникать проблемы совместимости серверов, СХД и зарубежных систем.

Типичная ошибка — переносить все физические серверы в виртуальные «один к одному» без анализа профиля нагрузки. Такой подход сохраняет старые перекосы: где-то простаивает память, где-то не хватает дискового I/O, а некоторые ВМ получают больше vCPU, чем реально используют. Лучше начинать с мониторинга за репрезентативный период — скажем, 2–4 недели — и проектировать серверы для виртуализации под фактическую нагрузку, а не под паспортные требования приложений.

Виртуализацию не стоит внедрять автоматически. Bare metal, облако или VPS могут оказаться рациональнее в следующих ситуациях:

• приложение критично к минимальной задержке и плохо переносит overhead гипервизора;
• нагрузка одна, стабильная и полностью занимает сервер — консолидировать нечего;
• нет компетенций по гипервизору, бэкапам и кластеру, а бюджет на обучение или аутсорс ограничен;
• бюджет не покрывает резервирование, СХД, лицензии и поддержку;
• требования ИБ запрещают смешивать контуры разных классов на одной физической платформе.

В таких случаях bare metal с аппаратным RAID и локальной репликацией может оказаться проще и надёжнее, а для тестовых задач хватит облачного VPS.

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

На аппаратном уровне изоляцию поддерживают Intel VT-x/VT-d, AMD-V/AMD-Vi, EPT/NPT и IOMMU. В Intel 64 and IA-32 Architectures Software Developer's Manual от Intel гостевые системы выполняются в специальных режимах, а привилегированные операции вызывают переход в гипервизор. В AMD64 Architecture Programmer's Manual от AMD аналогичный принцип используется для разделения гостевых контекстов и контроля доступа к памяти.

На сетевом уровне изоляция строится через VLAN, виртуальные коммутаторы, ACL, микросегментацию и отдельные контуры администрирования. Каждая виртуальная машина может находиться в своём сегменте сети, а трафик между сервисами регулируется политиками. В продуктивной среде это важнее, чем кажется: работающие виртуальные машины могут находиться на одном физическом сервере, но относиться к разным зонам безопасности.

Материал носит информационный характер и не заменяет официальных требований регуляторов и консультации профильного специалиста. При обработке персональных данных нужно учитывать 152-ФЗ «О персональных данных» и применимые приказы ФСТЭК по защите ИСПДн: разграничение доступа, регистрацию событий безопасности, защиту от несанкционированного доступа и контроль межконтурного взаимодействия. Для объектов критической информационной инфраструктуры дополнительно действует 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». По данным «Импортозамещение ИТ-инфраструктуры» от IKS Media, 2024, при смешении отечественных и зарубежных платформ виртуализации, СХД и ОС требуется обследование зависимостей, чтобы не нарушить сценарии безопасности и эксплуатации. Актуальный перечень сертифицированных средств защиты и программных платформ следует проверять в реестре ФСТЭК и реестре российского ПО Минцифры.

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

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

1. Составьте список ВМ. Для каждой виртуальной машины зафиксируйте ОС, приложение, vCPU, RAM, объём дисков и критичность.
2. Снимите фактическую нагрузку. Соберите данные за репрезентативный период: CPU peak, RAM usage, IOPS, latency, throughput.
3. Разделите ВМ по классам. Лёгкие сервисы, прикладные серверы, СУБД, 1С, VDI, тестовые среды — у каждого класса свой профиль потребления.
4. Рассчитайте CPU. Активные vCPU умножьте на коэффициент перекоммита, соответствующий классу нагрузки. Для тяжёлых СУБД и 1С начинайте ближе к 1:1.
5. Рассчитайте RAM. Суммируйте пиковое потребление ВМ, добавьте резерв гипервизора, резерв HA и запас на рост.
6. Рассчитайте storage. Объём данных плюс рост, плюс бэкапы, плюс требуемые IOPS и latency.
7. Проверьте HCL. Сервер, CPU, RAID/HBA, NIC, firmware, драйверы и версия гипервизора должны быть в списке совместимости вендора.

Итоговую конфигурацию нужно подтверждать мониторингом текущей инфраструктуры и тестом типовой нагрузки на пилотном хосте. Без этого шага даже грамотный расчёт остаётся теорией.

Сервер для виртуализации должен иметь совместимую с гипервизором платформу, процессоры с аппаратной виртуализацией, достаточный объём ECC-памяти, производительную дисковую подсистему и резервируемые сетевые интерфейсы. Выбор оборудования начинается не с бренда, а с профиля нагрузки: сколько виртуальных машин, какие приложения, какой I/O, какие требования к RPO/RTO и HA.

По VMware Compatibility Guide от VMware, 2024, для поддержки нужно проверять модель сервера, адаптеры, firmware и драйверы. Аналогичные требования предъявляет Microsoft Hyper-V Documentation от Microsoft, 2024. Несовместимое железо может работать в лаборатории, но выпадает из поддержки вендора — а это серьёзный риск для enterprise-среды.

Базовые требования к серверу виртуализации:

• процессоры Intel Xeon Scalable или AMD EPYC с Intel VT-x/VT-d либо AMD-V/AMD-Vi;
• ECC-память RDIMM или LRDIMM с запасом под рост и HA;
• дублируемые блоки питания;
• hot-swap вентиляторы и накопители;
• RAID-контроллер с battery-backed cache или flash-backed cache для классических RAID-сценариев;
• HBA/JBOD для программно-определяемых хранилищ;
• сетевые адаптеры 10GbE и выше; для migration и storage-трафика пропускную способность рассчитывают по объёму данных, SLA и типу хранилища;
• отдельные сети для управления, миграции, хранения и пользовательского трафика;
• совместимость с выбранным гипервизором и версией ОС.

По официальным спецификациям HPE ProLiant 2024–2025, HPE ProLiant DL380 Gen11 и DL385 Gen11 — 2P-серверы для корпоративных нагрузок виртуализации с Intel Xeon Scalable 5th Gen или AMD EPYC 9004 и поддержкой больших объёмов DDR5 ECC-памяти, вплоть до терабайтных конфигураций в зависимости от модели и комплектации. По материалам Dell PowerEdge 2024–2025, в enterprise-линейках PowerEdge для виртуализации применяются 2-сокетные платформы с DDR5 ECC RDIMM, RAID/NVMe-опциями и резервируемыми компонентами.

В наших проектах под отказоустойчивые кластеры мы обычно начинаем с матрицы нагрузок: CPU-профиль, потребление RAM, IOPS, latency, рост данных, требования к бэкапам и ограничения по поставкам. Для enterprise-клиентов это позволяет сравнивать Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem SR650 V3, Huawei FusionServer, Yadro и Аквариус не по абстрактной «мощности», а по совместимости, доступности комплектующих, TCO и поддержке в РФ.

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

Intel VT-x и AMD-V отвечают за аппаратную виртуализацию CPU. Intel VT-d и AMD-Vi/IOMMU нужны для виртуализации ввода-вывода, DMA-remapping, passthrough и SR-IOV. Эти механизмы описаны в Intel 64 and IA-32 Architectures Software Developer's Manual от Intel и AMD64 Architecture Programmer's Manual от AMD.

Для стартового sizing коэффициент vCPU:pCPU задают по профилю нагрузки и проверяют мониторингом CPU Ready/Wait. Ниже — инженерные ориентиры, а не универсальные нормативы. В конкретной среде соотношение нужно подтверждать по фактическим метрикам.

Практический вывод: количество виртуальных машин не равно требуемому количеству ядер. Нужно считать активные vCPU, пиковые окна и критичность приложений. Типичная ошибка — выделять каждой ВМ «с запасом» по 8–16 vCPU, не проверяя фактическую загрузку. Гипервизору затем сложнее планировать выполнение, а производительность, вопреки ожиданиям, падает.

RAM в сервере виртуализации почти всегда становится главным ограничителем плотности ВМ. Если на физическом сервере несколько виртуальных машин, каждая получает выделенный объём памяти, а гипервизор дополнительно резервирует RAM под собственные службы и управление.

Для серверов виртуализации нужны RDIMM или LRDIMM с ECC. По спецификациям Dell PowerEdge от Dell Technologies, 2024, и HPE ProLiant от HPE, 2024, enterprise-серверы используют ECC-память для обнаружения и исправления одиночных ошибок, а RDIMM/LRDIMM позволяют наращивать ёмкость и плотность модулей по сравнению с UDIMM. Для продуктивной виртуализации это базовое требование, а не опция.

Гипервизоры умеют оптимизировать использование памяти через memory ballooning и дедупликацию страниц. По VMware vSphere 8.0 Update 2 Documentation от VMware, 2024, ballooning возвращает неиспользуемую память гостевых ОС гипервизору через драйвер внутри гостя. Transparent Page Sharing дедуплицирует одинаковые страницы памяти, но в современных конфигурациях меж-ВМ TPS может быть ограничен или отключён политиками безопасности. Но есть нюанс: ballooning и TPS — это аварийные и вспомогательные механизмы. Закладывать их в расчётную ёмкость как гарантированную экономию нельзя.

Расчёт памяти лучше делать снизу вверх:

1. Составить список ВМ и их фактическое потребление RAM.
2. Добавить резерв под гипервизор (обычно 4–8 ГБ, зависит от платформы).
3. Учесть запас под HA: что произойдёт, если один хост кластера выйдет из строя.
4. Оставить резерв под рост и плановые обновления.
5. Не закладывать экономию от ballooning и TPS как гарантированную.

Пример: если на одном сервере планируется разместить контроллер домена, сервер приложений, несколько серверов 1С, SQL/PostgreSQL и служебные ВМ — память нужно считать по пиковому потреблению баз и приложений, а не по минимальным требованиям ОС. Для баз данных нехватка RAM часто уходит в дисковый I/O, и это сразу влияет на latency.

Дисковая подсистема и сеть определяют, насколько стабильно сервер работает с виртуальным диском, миграцией ВМ и внешним хранилищем. Для виртуализации важны не только объём дисков, но и IOPS, latency, тип контроллера, схема RAID или HBA, а также пропускная способность сетевых адаптеров.

По материалам Dell Technologies PowerEdge от Dell Technologies, 2024, NVMe-накопители описываются как низколатентные PCIe-устройства; SAS/SATA SSD уступают им по возможностям интерфейса, а HDD имеют более высокую задержку и меньшую производительность случайного доступа. Конкретные IOPS и latency зависят от размера блока, глубины очереди, числа линий PCIe и стенда тестирования — переносить маркетинговые цифры в проект без проверки нельзя. SATA HDD может применяться для архивных и низконагруженных задач, но для production ВМ с random I/O он часто становится узким местом.

Для классического локального хранилища применяют аппаратный RAID-контроллер с защищённым кэшем. Для программных хранилищ вроде Storage Spaces Direct подход другой: по Microsoft Windows Server 2022/2025 Storage Spaces Direct Documentation от Microsoft, 2024, накопители должны быть доступны системе через HBA или passthrough, а аппаратный RAID может мешать программному управлению дисками.

Сеть для сервера виртуализации нужно делить по типам трафика:

• управление гипервизором;
• трафик виртуальных машин;
• Live Migration или vMotion;
• iSCSI/NFS/NVMe-oF;
• бэкапы и репликация;
• кластерный heartbeat.

Минимальная раскладка портов для production-кластера из двух хостов: 2 порта на management и VM traffic, 2 порта на migration и storage. В малом офисе допустимо совмещение, но для кластеров с активными СУБД и частыми миграциями лучше закладывать 25GbE и отдельные коммутаторы для storage-трафика.

Практический вывод: создание виртуальных машин без расчёта storage и сети быстро приводит к «невидимому» узкому месту. CPU может быть свободен, RAM — с запасом, но пользователи видят задержки из-за дискового массива или перегруженного storage-сегмента.

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

CPU:
Требуемые pCPU ≥ Σ активных vCPU / допустимый коэффициент vCPU:pCPU

RAM:
Требуемая RAM = Σ пикового RAM ВМ + RAM гипервизора + резерв HA (N+1) + запас роста (обычно 15–25 % от суммы)

Storage:
Требуемый объём = Σ данных ВМ + snapshots + swap/temp + рост + резерв под бэкапы

IOPS:
Требуемые IOPS ≥ Σ пиковых IOPS критичных ВМ × коэффициент запаса (1,2–1,5)

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

Допустим, компании нужно разместить 10 ВМ: 2 контроллера домена (по 2 vCPU, 8 ГБ), 3 сервера приложений (по 4 vCPU, 16 ГБ), 2 ВМ 1С (по 4 vCPU, 32 ГБ), 1 SQL Server (8 vCPU, 64 ГБ), 1 файловый сервер (2 vCPU, 8 ГБ), 1 ВМ мониторинга (2 vCPU, 8 ГБ).

• Итого vCPU: 2×2 + 3×4 + 2×4 + 8 + 2 + 2 = 36 vCPU.
• При среднем коэффициенте ~2:1 (смешанная нагрузка): нужно ≥ 18 физических ядер. Два процессора по 16 ядер дают 32 pCPU — достаточно с запасом.
• RAM: (2×8) + (3×16) + (2×32) + 64 + 8 + 8 = 192 ГБ. Плюс ~8 ГБ на гипервизор, плюс резерв HA и роста ~20 % → ≈ 240 ГБ. Закладываем 256 ГБ.
• Storage: зависит от объёмов баз и файлового сервера; считаем IOPS по SQL и 1С отдельно, остальные ВМ — суммарно.

Это ориентир для одного хоста. Для HA-кластера N+1 нужно два таких хоста, каждый из которых выдержит всю нагрузку при отказе второго.

Конкретные модели и числа ядер подбираются по матрице нагрузок и HCL выбранного гипервизора. Наши инженеры используют эти профили как стартовую точку при расчёте конфигурации.

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

Классические варианты — VMware ESXi/vSphere, Microsoft Hyper-V и KVM-based решения. По VMware vSphere 8 Documentation от VMware, 2023, ESXi — bare-metal гипервизор первого типа. По Microsoft Hyper-V Documentation от Microsoft, 2024, Hyper-V интегрирован в Windows Server и управляется через Hyper-V Manager, Failover Cluster Manager, Windows Admin Center и PowerShell. KVM работает как модуль ядра Linux, а такие платформы, как Proxmox VE, добавляют web UI, CLI и API.

Ограничения по RAM на хост и vCPU на ВМ зависят от версии, редакции, лицензии и конфигурации хоста — их нужно проверять в support matrix конкретного релиза. Ориентироваться на обобщённую таблицу «лимитов вообще» не стоит.

Для выбора гипервизора полезно пройтись по чек-листу:

• какие лицензии и стоимость поддержки;
• есть ли сервер и компоненты в HCL;
• какие механизмы HA и live migration;
• как реализован backup API;
• поддержка SDS или внешней СХД;
• сертификация ФСТЭК (если требуется);
• наличие в реестре российского ПО;
• компетенции команды администраторов.

Для российских платформ важны совместимость и сертификация. По материалам CNews Analytics, 2025, и документации Orion soft, zVirt использует KVM и управляет кластерами через единый центр управления. По официальным материалам РУСТЭК Virtualization, 2024–2025, платформа тоже построена на KVM, поддерживает HA и live migration, а для сети заявлен распределённый коммутатор. Наличие сертификатов ФСТЭК у zVirt и РУСТЭК подтверждено, но класс защиты и уровень доверия необходимо сверять по актуальному реестру сертифицированных средств защиты ФСТЭК и комплекту поставки перед проектом.

По данным «Импортозамещение ИТ-инфраструктуры» от IKS Media, 2024, основные проблемы миграции связаны с несовместимостью российских серверов и СХД с зарубежными системами, изменением сценариев при переходе с Exchange и Active Directory, а также рисками для SCADA и специализированных контроллеров. Для закупщика это означает: мало выбрать гипервизор по функциональности — нужно провести пилот и проверить цепочку «сервер — СХД — сеть — ОС — СУБД — бэкап — мониторинг».

Практическая рекомендация: если инфраструктура уже работает на VMware или Hyper-V, миграцию на другую платформу нужно начинать с инвентаризации ВМ, зависимостей, драйверов, сетевых политик и бэкапов. Для новых проектов можно сразу закладывать KVM-based или российскую платформу, но только после проверки HCL и теста типовой нагрузки.

Отказоустойчивость — одна из главных причин внедрения виртуализации, но HA не появляется «из коробки». Его нужно проектировать.

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

Два узла. Классический вариант для SMB. При отказе одного узла второй принимает нагрузку. Для двухузлового кластера критичен quorum/witness — третий элемент, который определяет, какой узел «жив». В VMware это vCenter + witness, в Hyper-V — file share witness или облачный witness, в Proxmox — QDevice.

Три и более узлов. Обеспечивает N+1 с запасом: при отказе одного хоста оставшиеся два распределяют нагрузку. Для SDS-решений (vSAN, S2D, Ceph) три узла — минимум для репликации данных.
Ключевые принципы:

• N+1: в кластере должен быть резерв ресурсов, достаточный для перезапуска ВМ с отказавшего хоста.
• HA ≠ backup. HA защищает от простоя при отказе хоста, но не защищает от удаления файлов, шифрования данных или логической ошибки в БД. Бэкап — отдельный слой.
• Разделяйте single points of failure: один коммутатор, одна СХД, один контроллер RAID, один ИБП — каждый из них может остановить весь кластер.
• RPO/RTO определяются для каждого сервиса отдельно: для AD допустимо RPO 24 часа и RTO 1 час, для продуктивной 1С — RPO минуты и RTO минуты.

Перед запуском продуктивной среды полезно пройтись по чек-листу:

• Сервер и компоненты есть в HCL выбранного гипервизора.
• Обновлены BIOS/UEFI, firmware RAID/HBA и сетевых адаптеров до поддерживаемых версий.
• Включены Intel VT-x/VT-d или AMD-V/AMD-Vi в BIOS.
• Настроены отдельные сети управления, ВМ, миграции и хранения.
• Созданы datastore/LUN с нужной политикой RAID или SDS.
• Настроены роли доступа администраторов, включая MFA для консоли управления.
• Определены шаблоны ВМ и стандарты именования.
• Настроены бэкапы и проверено восстановление тестовой ВМ из резервной копии.
• Включён мониторинг CPU Ready, RAM pressure, latency и дисковых очередей.
• Задокументированы RPO/RTO и порядок действий при отказе хоста.

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

Из нашей инженерной практики: для 1С:Предприятие 8 в виртуализации критична высокая частота физических ядер и дисковая подсистема с low latency. Окончательный выбор нужно подтверждать тестированием конкретной базы и профиля пользователей, потому что результат зависит от релиза 1С, выбранной СУБД и характера нагрузки.

По данным «Импортозамещение ИТ-инфраструктуры» от IKS Media, 2024, при выборе платформы нужно анализировать зависимости между СУБД, виртуализацией и сетью; проблемы совместимости названы ключевым риском для баз данных и приложений. Для 1С это особенно актуально: серверы могут быть правильно сконфигурированы по CPU, но слабая СХД или перегруженная сеть даст задержки в транзакциях и регламентных заданиях.

Для виртуализации 1С мы рекомендуем проверять:

• базовую и turbo-частоту физических ядер;
• количество активных пользователей и фоновых заданий;
• тип СУБД: MS SQL Server или PostgreSQL (разные требования к RAM, диску и обслуживанию);
• объём RAM под СУБД и кэш;
• IOPS и latency хранилища на реальных блоках;
• отдельные дисковые группы или LUN под данные, логи и temp;
• сеть между сервером приложений, СУБД и СХД;
• политику vCPU:pCPU ближе к 1:1 для тяжёлой базы;
• резерв под пиковые периоды: закрытие месяца, отчётность, обмены.

Для 1С важно разделять роли: сервер приложений 1С, СУБД и терминальные серверы/RDS — это разные ВМ с разными профилями нагрузки. Смешивать их на одном vCPU-пуле без приоритизации нежелательно.

Что нельзя делать с 1С в виртуализации:

• overcommit CPU на хосте с тяжёлой базой;
• хранить данные СУБД на общих медленных HDD;
• запускать бэкап в рабочее окно без throttle;
• размещать шумные ВМ (тестовые среды, антивирусное сканирование) рядом с продуктивной СУБД без контроля ресурсов.

В проекте для КазКонтракт Трейд наша команда за 1 месяц создала отказоустойчивый кластер 1С и СУБД на базе оборудования Dell с монтажом и настройкой по техническому заданию. После внедрения среднее время выполнения типовых бизнес-операций сократилось на 50 %, а инфраструктура подготовила заказчика к росту парка техники с 300 до 1 000 единиц и запуску новых направлений перевозок. Этот пример показывает, почему серверы для 1С нельзя подбирать только по числу пользователей: нужны отказоустойчивость, совместимость, запас по СУБД и понятная схема масштабирования.

При подготовке ТЗ и сравнении коммерческих предложений полезно задать поставщику следующие вопросы:

• Есть ли выбранная модель сервера в HCL целевого гипервизора?
• Какие версии firmware и драйверов поддерживаются и протестированы?
• Какой резерв по RAM и дисковым слотам заложен для масштабирования?
• Как реализованы бэкапы и восстановление ВМ в предлагаемой архитектуре?
• Выдержит ли кластер отказ одного хоста при текущем sizing?
• Как разделены сети management, storage и migration?
• Какие компоненты доступны для замены в РФ, каковы сроки поставки?
• Какая поддержка доступна после внедрения: SLA, NBD, 4-часовая реакция?
• Учтены ли требования 44-ФЗ/223-ФЗ по нейтральности характеристик и эквивалентности?
• Есть ли опыт пилотного тестирования аналогичной конфигурации?

Для тех, кто переходит от планирования к действию, приводим укрупнённый порядок шагов:

1. Инвентаризация: собрать список всех серверов, ВМ, приложений и зависимостей.
2. Сбор метрик: запустить мониторинг CPU, RAM, IOPS, latency и сетевого трафика за 2–4 недели.
3. Выбор гипервизора: по критериям лицензирования, HCL, HA, backup API, компетенций команды и регуляторных требований.
4. Проверка HCL: сервер, NIC, RAID/HBA, firmware, драйверы — всё должно быть в списке совместимости.
5. Проектирование сети и storage: разнести типы трафика, выбрать RAID/HBA или SDS, рассчитать IOPS.
6. Пилот: развернуть 2–3 тестовых ВМ, прогнать типовую нагрузку, проверить latency, CPU Ready, бэкап и восстановление.
7. Миграция тестовых ВМ: перенести некритичные сервисы, проверить работоспособность.
8. Миграция продуктивных сервисов: начинать с менее критичных, заканчивать СУБД и 1С.
9. Тест восстановления: проверить RPO/RTO на реальных данных.
10. Ввод в эксплуатацию и мониторинг: CPU Ready, RAM pressure, datastore latency, packet drops, backup success rate.

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

Если вы планируете внедрение сервера виртуализации или модернизацию текущей инфраструктуры, рекомендуем следующий порядок:

1. Соберите список всех ВМ и серверных ролей.
2. Снимите метрики CPU, RAM, IOPS и latency за 2–4 недели.
3. Определите RPO/RTO для каждого сервиса.
4. Проверьте совместимость целевого оборудования с HCL гипервизора.
5. Запросите расчёт конфигурации у инженеров Work System — мы подберём серверы, СХД, сеть и лицензии под ваш профиль нагрузки, проведём пилот и поможем с миграцией.