Серверная виртуализация позволяет запускать несколько изолированных виртуальных машин на общей физической инфраструктуре, распределять вычислительные ресурсы между ними и управлять большим количеством серверов через единый программный слой. Такой подход применяется в корпоративных дата-центрах, частных облаках, инфраструктуре хостинг-провайдеров, тестовых средах и информационных системах организаций.
VMmanager - российская платформа централизованного управления серверной виртуализацией. Актуальная линейка VMmanager 6 предназначена для работы с виртуальными машинами и кластерами: через платформу администратор может объединять серверы, создавать ВМ, устанавливать на них операционные системы и выполнять другие операции с виртуальной инфраструктурой. Продукт включён в Единый реестр российского программного обеспечения.
Рассматривать подобную систему корректнее не как отдельный гипервизор, а как комплексный уровень управления инфраструктурой. В практической эксплуатации важны не только создание виртуальной машины, но и контроль физических узлов, сетей, IP-адресов, хранилищ, резервного копирования, доступа пользователей и отказоустойчивости.
Что представляет собой серверная виртуализация
При традиционной схеме на одном физическом сервере работает одна основная операционная система и связанный с ней набор приложений. При виртуализации вычислительные ресурсы сервера - процессорное время, оперативная память, дисковое пространство и сетевые интерфейсы - могут распределяться между несколькими независимыми виртуальными машинами.
Каждая ВМ воспринимается операционной системой как отдельный компьютер. Она получает виртуальные процессоры, память, диски и сетевые интерфейсы. При этом физические ресурсы предоставляет один или несколько серверов виртуализационной инфраструктуры.
Такой подход упрощает разделение нагрузок. Например, корпоративная информационная система, тестовый сервер и внутренний веб-сервис могут размещаться на отдельных ВМ без необходимости выделять каждой задаче отдельный физический компьютер.
Однако по мере роста инфраструктуры появляется другая задача - управление десятками или сотнями виртуальных машин и несколькими физическими хостами. Именно здесь используются платформы централизованного управления.
Роль VMmanager в инфраструктуре
VMmanager предоставляет единую точку управления виртуальной средой. Согласно документации разработчика, VMmanager 6 позволяет работать с несколькими кластерами, создавать виртуальные машины и выполнять установку операционных систем и сценариев на них.
Администратору при такой модели не требуется рассматривать каждый физический сервер как полностью независимый объект. Узлы объединяются в логические кластеры, после чего управление ресурсами выполняется на уровне платформы.
Это особенно заметно в больших инфраструктурах. При наличии одного гипервизора многие операции можно выполнять вручную. Когда физических серверов становится несколько десятков, ручная работа усложняет контроль конфигураций, размещение виртуальных машин и учёт ресурсов.
Централизованная платформа формирует более высокий уровень абстракции: администратор работает с ВМ, вычислительными узлами, сетями и хранилищами через одну систему.
Кластеры и физические узлы
Кластер виртуализации представляет собой группу серверов, используемых для размещения виртуальных машин. В актуальной документации vm-manager при создании кластера предусмотрен выбор технологии виртуализации, в том числе KVM; документация также описывает подключение физических узлов к созданному кластеру.
Узел - физический сервер с процессором, оперативной памятью, сетевыми интерфейсами и локальными либо подключёнными системами хранения. После включения узла в инфраструктуру его ресурсы становятся частью управляемой среды.
Преимущество кластерного подхода заключается прежде всего в организации инфраструктуры. Вместо набора разрозненных серверов появляется единая логическая среда, в которой проще отслеживать доступные ресурсы и состояние вычислительных узлов.
При проектировании необходимо учитывать, что фактическая масштабируемость определяется не только возможностями управляющей платформы. Ограничивающими факторами могут становиться сеть, производительность хранилища, архитектура серверов, характеристики процессоров и объём оперативной памяти.
Создание и управление виртуальными машинами
Одна из базовых задач платформы виртуализации - управление жизненным циклом ВМ. VMmanager предусматривает создание виртуальных машин по конфигурациям и образам, включение, выключение, перезагрузку и удаление ВМ, подключение дополнительных дисков и установку операционных систем. В документации также описаны управление IP-адресами, использование собственных ISO-образов и удалённый доступ.
При создании виртуальной машины задаётся набор ресурсов. В него входят виртуальные процессоры, объём памяти и дисковое пространство. В зависимости от архитектуры инфраструктуры применяются заранее подготовленные конфигурации, чтобы однотипные серверы получали одинаковые параметры.
Такой механизм удобен при массовом развертывании. Если организации регулярно нужны однотипные тестовые ВМ или провайдер предоставляет стандартные конфигурации виртуальных серверов, использование шаблонов уменьшает количество ручных операций.
При этом виртуальная машина остаётся обычным вычислительным ресурсом, которому требуется администрирование: обновление операционной системы, контроль доступа, резервное копирование и мониторинг приложений не исчезают только из-за перехода на виртуализацию.
Установка операционных систем и использование образов
При массовом развертывании ВМ ручная установка операционной системы на каждый экземпляр становится неудобной. Поэтому платформы виртуализации используют готовые шаблоны и образы.
VMmanager позволяет устанавливать операционные системы из подготовленных шаблонов и использовать собственные ISO-образы.
Для организации это означает возможность стандартизировать серверные конфигурации. Например, можно определить несколько типовых вариантов ВМ для различных информационных систем, а затем использовать их в качестве основы при создании новых экземпляров.
Стандартизация особенно важна для эксплуатации: чем меньше случайных различий между однотипными серверами, тем проще их обновлять, диагностировать и контролировать.
Перед внедрением желательно отдельно проверить перечень поддерживаемых гостевых ОС, совместимость конкретных версий и требования к автоматической установке. Эти параметры могут меняться по мере обновления платформы.
Управление сетями и IP-адресами
Виртуализация серверов невозможна без сетевой инфраструктуры. Каждая ВМ должна получить сетевое подключение, а часто и собственный IP-адрес.
В VMmanager предусмотрен встроенный механизм IPAM для управления адресным пространством. В официальной документации указано, что модуль работает с физическими сетями, пулами и отдельными IP-адресами, а при создании ВМ адрес может выделяться из заданного пула.
Это уменьшает объём ручного учёта адресов. В инфраструктуре с десятками машин таблица IP-адресов быстро становится неудобной: требуется понимать, какой адрес свободен, какой уже назначен и какому объекту он принадлежит.
Централизованный IPAM решает эту задачу на уровне платформы.
В более сложной инфраструктуре необходимо учитывать VLAN, маршрутизацию, физические интерфейсы, резервирование сетевых соединений и особенности используемого оборудования. Документация VMmanager также предусматривает настройку бондов - объединения нескольких физических интерфейсов в один логический интерфейс, что может применяться для повышения доступности и пропускной способности сетевого подключения.
Хранилище виртуальных машин
Диск виртуальной машины физически должен где-то храниться. Это может быть локальное хранилище конкретного узла или внешняя система хранения, доступная нескольким серверам.
Выбор архитектуры существенно влияет на возможности кластера. Локальные диски могут обеспечивать простую организацию и высокую производительность в некоторых сценариях, но внешнее либо распределённое хранилище позволяет реализовывать другие схемы работы с ВМ.
В актуальной документации VMmanager представлены разделы, посвящённые LVM и Ceph RBD, а также операциям с хранилищами.
Ceph может использоваться как распределённая система хранения данных для дисков виртуальных машин. Документация VMmanager отдельно описывает сценарий создания гиперконвергентного кластера с использованием Ceph.
Конкретный выбор системы хранения следует делать после оценки нагрузки. Для файлового сервера, базы данных, тестовой среды и высоконагруженного приложения требования к задержкам и количеству операций ввода-вывода могут существенно различаться.
Что означает масштабируемость платформы
Термин "масштабируемая платформа" означает возможность развивать инфраструктуру по мере изменения нагрузки. В простом случае организация начинает с нескольких физических узлов, а затем добавляет новые вычислительные ресурсы и виртуальные машины.
Однако масштабирование - это не только увеличение числа серверов. Необходимо одновременно учитывать производительность сети, хранилища и управляющих компонентов.
У VMmanager используется сервисная архитектура: официальная документация описывает отдельные компоненты для мониторинга ВМ и узлов, контроля ресурсов, работы с задачами, уведомлениями и отказоустойчивыми кластерами.
Для администратора внутреннее устройство платформы не обязательно должно быть основным объектом ежедневного управления, но понимание архитектуры важно при проектировании крупного развертывания и поиске причин неисправностей.
Масштабирование следует планировать заранее. Простое добавление вычислительного узла не поможет, если основным ограничением является перегруженная система хранения или недостаточная пропускная способность сети.
Отказоустойчивость виртуальной среды
Одно из важных направлений серверной виртуализации - повышение доступности сервисов. Если виртуальная машина работает только на одном физическом сервере и этот сервер полностью выходит из строя, размещённые на нём сервисы становятся недоступны.
В редакции VMmanager Infrastructure предусмотрена возможность настройки отказоустойчивых кластеров. Согласно документации разработчика, при потере узлом связи с другими узлами либо с подключённым хранилищем платформа может инициировать процесс аварийного восстановления и релокации виртуальных машин.
Для работы соответствующего механизма используются Corosync с Kronosnet, а также собственные сервисы платформы ha-agent и hawatch.
При этом понятие высокой доступности не означает абсолютного отсутствия простоев. Эффективность HA-схемы зависит от архитектуры хранения, сетей, количества узлов и корректности настройки.
Отказоустойчивость всей системы необходимо рассматривать целиком. Наличие HA для вычислительных узлов не компенсирует единственную незащищённую систему хранения или один сетевой коммутатор, отказ которого нарушит доступность всех компонентов.
Резервное копирование и высокая доступность - разные задачи
Высокую доступность иногда ошибочно воспринимают как замену резервному копированию. На практике это разные механизмы.
HA-кластер предназначен прежде всего для продолжения работы или восстановления ВМ при проблемах с инфраструктурным узлом. Резервная копия нужна для восстановления данных после удаления, повреждения файлов, программной ошибки или другого события, которое может затронуть содержимое самой виртуальной машины.
Документация VMmanager содержит отдельные разделы для ручного и автоматического создания резервных копий, хранилищ резервных копий и резервирования самой платформы.
Поэтому архитектура виртуализации должна включать самостоятельную стратегию резервирования. Желательно определять периодичность копирования, глубину хранения, расположение резервов и порядок проверки возможности восстановления.
Резервная копия, которую никогда не тестировали на восстановление, не даёт полной уверенности в работоспособности аварийного сценария.
Мониторинг ресурсов
Плотность размещения ВМ на физических серверах требует постоянного контроля ресурсов. Если несколько виртуальных машин одновременно начинают активно потреблять процессорное время, память или дисковый ввод-вывод, производительность может снизиться даже при формальном отсутствии аппаратного отказа.
В структуре VMmanager предусмотрены сервисы для мониторинга состояния виртуальных машин и узлов, а также контроля потребления ресурсов.
Для администратора полезны данные о загрузке процессоров, памяти, дисков и сетей. Их анализ позволяет выявлять перегруженные узлы и понимать, когда инфраструктуре требуется расширение.
Нужно учитывать и явление переподписки ресурсов, когда виртуальным машинам суммарно назначается больше потенциальных ресурсов, чем физически имеется у узла. Такой подход может быть допустим при непиковых нагрузках, но требует наблюдения за фактическим потреблением.
Иначе экономия вычислительных ресурсов превращается в конкуренцию между ВМ и нестабильную производительность.
Автоматизация и API
Платформа управления становится особенно полезной, когда инфраструктура интегрируется с другими информационными системами.
VMmanager располагает API, а официальная документация выделяет отдельный раздел для программного взаимодействия с платформой.
API позволяет автоматизировать операции, которые вручную выполнялись бы администратором через интерфейс. Например, внешняя система может инициировать создание или изменение инфраструктурного объекта согласно собственной бизнес-логике.
Подобные интеграции актуальны не только для хостинг-провайдеров. Корпоративная организация может использовать автоматизацию в сервисном портале, внутренней системе заявок или процессе подготовки тестовых окружений.
При этом автоматизация требует контроля прав доступа, журналирования и обработки ошибок. Если ошибочная команда выполняется вручную один раз, её последствия ограничены. Ошибка в массовом автоматическом сценарии способна затронуть сразу большое число объектов.
Разграничение доступа
В инфраструктуре среднего или крупного предприятия виртуализацией редко управляет только один человек. В системе могут работать администраторы платформы, специалисты эксплуатации, инженеры поддержки и пользователи отдельных ресурсов.
Разделение полномочий позволяет ограничить каждому сотруднику только те действия, которые необходимы для работы.
VMmanager предусматривает работу с ролями и механизмами идентификации пользователей. В документации сертифицированной редакции также описывается применение локальной и LDAP-аутентификации, а для централизованного управления идентификацией рассматривается интеграция со службой каталогов.
Такая организация доступа важна с точки зрения информационной безопасности: административные полномочия не должны автоматически предоставляться каждому пользователю виртуальной среды.
Конкретную модель ролей целесообразно проектировать до запуска системы в промышленную эксплуатацию.
VMmanager и российское программное обеспечение
Для организаций, которым важно происхождение программного обеспечения, существенным фактором является наличие продукта в Едином реестре российских программ.
VMmanager 6 присутствует в соответствующем реестре; это также отражено в каталоге совместимости российского ПО и документации производителя.
Статус российского программного продукта сам по себе не определяет техническую пригодность решения для конкретной инфраструктуры. При выборе по-прежнему необходимо проверить требования к производительности, совместимость оборудования, поддержку используемых ОС, схему лицензирования, возможности миграции и эксплуатационные процессы.
Для организаций с формальными требованиями к импортозамещению реестровый статус является отдельным критерием наряду с техническими характеристиками.
Сертифицированная редакция и информационная безопасность
Для информационных систем с установленными требованиями защиты имеет значение не только функциональность виртуализации, но и наличие соответствующих документов по безопасности.
Разработчик сообщает, что VMmanager получил сертификат ФСТЭК России № 4911 от 7 февраля 2025 года и имеет статус средства виртуализации 4-го класса защиты. Для сертифицированной версии существует отдельный комплект технической документации.
Это не означает, что установка продукта автоматически делает всю информационную систему соответствующей требованиям безопасности. Соответствие определяется архитектурой объекта, режимом эксплуатации, настройками, применяемыми средствами защиты и нормативными требованиями к конкретной системе.
При проектировании защищённого контура необходимо ориентироваться на сертифицированную конфигурацию и действующую документацию, а не переносить параметры обычной редакции без проверки.
Сценарий для корпоративного дата-центра
В корпоративной инфраструктуре VMmanager может выполнять роль единого уровня управления физическими узлами и виртуальными машинами.
Предприятие может выделить кластер для внутренних приложений, отдельный кластер для тестовой среды и, при необходимости, среду для сервисов с повышенными требованиями к доступности.
Такой подход помогает логически разделить нагрузки и стандартизировать жизненный цикл ВМ.
Вместо ручной подготовки нового физического сервера под каждую задачу администратор создаёт виртуальную машину требуемой конфигурации. После завершения проекта ресурс может быть освобождён или перераспределён.
При этом сама виртуализация не устраняет необходимость управлять приложениями. Ответственность просто делится между уровнями: платформа отвечает за виртуальную инфраструктуру, а операционные системы и приложения требуют собственного администрирования.
Сценарий для хостинговой инфраструктуры
У хостинг-провайдера характер нагрузки отличается от корпоративной среды. Здесь может потребоваться регулярно создавать и удалять большое количество виртуальных серверов для разных пользователей.
VMmanager позиционируется разработчиком в том числе для автоматизации инфраструктуры виртуального хостинга и централизованного управления виртуальной средой.
В этом случае особенно важны API, автоматическая выдача IP-адресов и стандартизированные конфигурации ВМ.
При проектировании необходимо учитывать изоляцию клиентов, ограничения потребления ресурсов и механизмы мониторинга. Количество созданных ВМ само по себе не является показателем эффективности: основное значение имеет стабильная работа физической инфраструктуры при фактической нагрузке.
Тестовые среды и разработка
Виртуализация удобна для разработки и тестирования программного обеспечения. Разработчику может требоваться несколько окружений с разными версиями операционных систем и приложений.
Создание отдельного физического сервера для каждого окружения обычно нерационально. Виртуальные машины можно создавать по мере необходимости и удалять после завершения испытаний.
Дополнительное преимущество заключается в воспроизводимости среды. Если используется стандартный шаблон, несколько команд разработки могут получать одинаковые базовые конфигурации.
При этом тестовые и продуктивные среды желательно логически и организационно разграничивать, поскольку экспериментальные нагрузки не должны влиять на критические информационные системы.
Что необходимо оценить до внедрения
Перед переходом на новую платформу виртуализации следует провести инвентаризацию существующей инфраструктуры. Необходимо определить количество физических серверов и ВМ, характеристики процессоров, объём памяти, дисковую нагрузку и сетевой трафик.
Затем оценивается совместимость оборудования и операционных систем с актуальной версией платформы.
Отдельный вопрос - хранилище. Необходимо решить, будет ли применяться локальная, внешняя или распределённая система, и определить требования к производительности и резервированию.
Также проектируется сеть: адресные пространства, VLAN, маршрутизация, резервные интерфейсы и доступ административного сегмента.
После технической части необходимо определить роли пользователей, порядок резервного копирования и сценарии действий при отказе.
Миграция существующих виртуальных машин
Переход с другой платформы виртуализации редко сводится к установке VMmanager и одномоментному переносу всех систем.
Необходимо классифицировать ВМ по критичности, используемым операционным системам, размеру дисков и допустимому времени простоя.
Пилотная миграция на небольшом количестве некритичных машин помогает выявить несовместимости до переноса продуктивных сервисов.
Особое внимание уделяют драйверам виртуального оборудования, сетевым настройкам и способу хранения дисков.
После переноса требуется проверить не только запуск операционной системы, но и фактическую работу приложения, сетевое взаимодействие, резервирование и мониторинг.
Экономика виртуальной инфраструктуры
Виртуализация может повысить коэффициент использования физического оборудования, однако оценивать проект только по количеству серверов некорректно.
В расчёт входят оборудование, системы хранения, сетевые устройства, лицензии, резервное копирование, техническая поддержка и трудозатраты специалистов.
Потребление электроэнергии и требования к охлаждению также имеют значение для собственного дата-центра.
С другой стороны, стандартизация управления может уменьшить количество рутинных операций и ускорить предоставление вычислительных ресурсов внутренним пользователям.
Поэтому экономический эффект следует оценивать для конкретной организации и на достаточном временном горизонте, а не считать его автоматическим свойством любой виртуализации.
На что обратить внимание при сравнении платформ
Сравнивать системы виртуализации имеет смысл по заранее составленному перечню требований.
Для одной организации ключевым фактором будет поддержка отказоустойчивого кластера, для другой - простота эксплуатации, для третьей - российское происхождение ПО и сертифицированная версия.
Важны совместимость оборудования, используемые технологии хранения, сетевые возможности, резервирование, API, управление правами и качество документации.
Следует учитывать и жизненный цикл продукта: периодичность обновлений, порядок установки новых версий и наличие технической поддержки.
Функция, указанная в описании платформы, ещё не означает её применимость в любой архитектуре. Поэтому перед промышленным внедрением разумно воспроизвести предполагаемый сценарий в тестовой среде.
Заключение
Российская масштабируемая платформа серверной виртуализации VMmanager представляет собой систему централизованного управления виртуальными машинами, вычислительными узлами, сетевыми ресурсами и связанными элементами инфраструктуры. Актуальная версия позволяет организовывать несколько кластеров, создавать ВМ, устанавливать операционные системы и использовать механизмы централизованного администрирования.
Для сетевого управления в платформе предусмотрен IPAM, а архитектура хранения может включать различные варианты, в том числе сценарии с Ceph. В редакции Infrastructure поддерживается построение отказоустойчивых кластеров с механизмом аварийного восстановления виртуальных машин.
VMmanager относится к российскому программному обеспечению и включён в Единый реестр российских программ. Для задач, в которых действуют специальные требования информационной безопасности, существует сертифицированная редакция VMmanager; разработчиком опубликована отдельная документация по её эксплуатации.
При этом выбор платформы серверной виртуализации нельзя основывать только на происхождении продукта или перечне функций. Необходимо учитывать характеристики существующего оборудования, архитектуру сети и хранилищ, требования к высокой доступности, резервному копированию, безопасности и будущему масштабированию.
VMmanager в таком контексте следует рассматривать как один из инструментов построения управляемой виртуальной инфраструктуры. Практическая пригодность решения определяется после технического обследования, тестового развёртывания и сопоставления возможностей актуальной версии платформы с требованиями конкретной организации.
