При виртуализации инфраструктуры компании хотят получить надежное и гибко масштабируемое решение, которое, ко всему прочему, быстро развертывается и позволяет экономить ресурсы компании.
Долгое время при виртуализации для развертывания системы требовался физический сервер — управляющий узел, от которого зависели впоследствии создаваемые виртуальные машины в кластере. Сегодня этот способ также широко распространен, но имеет ряд особенностей, ограничивающих его применение в бизнес-среде.
Что не так с традиционным подходом
Классическая архитектура виртуальной среды подразумевает размещение и запуск изолированных виртуальных машин на гипервизоре и управление ими с помощью внешнего сервера. Для бизнеса такой подход более ресурсозатратен: поддержка работы гипервизоров требует дополнительного расхода серверных мощностей и электроэнергии. Помимо этого, приверженность традициям создает зависимость от физического сервера системы управления. Необходимо отдельно решать вопрос расширения ресурсов, резервирования и восстановления системы управления виртуализацией: если сервер упадет, в этом случае требуется ручное вмешательство.
Конечно, такой подход не лишен и преимуществ. К ним можно отнести изоляцию системы управления от повышенной нагрузки и сбоев на гипервизорах, потенциально большую защищенность за счет возможности размещения в отдельной сети. При этом виртуальные машины практически не влияют на саму систему управления.
Как виртуализируют сегодня
Сейчас в сфере виртуализации распространен подход, при котором наличие физического сервера для развертывания мощной инфраструктуры не требуется. Система работает прямо на виртуальной машине внутри кластера, который им же и управляется.
Это позволяет:
- сэкономить ресурсы — для платформы не потребуется отдельный сервер;
- повысить надежность системы — если платформа будет размещена в отказоустойчивом кластере, то при отказе узла с платформой ее работа будет восстановлена на другом узле;
- гибко масштабировать платформу — добавить ресурсы для сервера платформы можно будет как для обычной виртуальной машины.
VMmanager: теперь поддерживаем оба подхода
Наша флагманская платформа серверной виртуализации VMmanager позволяет построить архитектуру виртуальной среды без использования физического сервера — в апреле мы внесли в решение необходимые доработки.
Теперь она интегрирована в кластер в качестве мастер-VM, словно матрешка. Это позволяет гибко распределять общие ресурсы системы и управлять ими изнутри кластера.
Подход, при котором не используется внешняя система управления, в первую очередь подойдет заказчикам с малой и средней конфигурацией платформы. Также он будет интересен компаниям, которые планируют использовать HA-кластер VMmanager: в этом случае у администраторов появляется возможность резервировать систему управления без лишних действий.
После обновления расширение виртуальных ресурсов для системы управления можно выполнить быстро и легко, без необходимости замены или дополнительной покупки оборудования.
От традиций к новинкам: как оптимизировать инфраструктуру компании
В рамках текущей версии платформа переносится с физического сервера на виртуальную машину. Основные действия по переносу платформы на ВМ выполняет сервис vm-mover. При запуске переноса копируется в одноименную директорию на исходном сервере с платформой. При создании ВМ с платформой на нее устанавливается операционная система (ОС), совпадающая с системой исходного сервера. В текущей реализации VMmanager поддерживает такие ОС, как AlmaLinux 8, Astra Linux Special Edition 1.7.4 «Орел» и Astra Linux Special Edition 1.8.1 «Орел».
После переноса платформа будет доступна по новому IP-адресу, но при необходимости его можно сменить на адрес исходного сервера. Настройки доступа останутся прежними. Если платформа была установлена с лицензией для закрытого контура, то после переноса потребуется повторная активация лицензии.
Обратите внимание, что данные статистики, также как и резервные копии, не переносятся автоматически — администратор должен будет сделать это вручную.
Миграция мастер-VM между узлами не поддерживается балансировщиком, этот процесс тоже необходимо выполнять вручную.
Работоспособность мастер-VM контролирует сервис vm-agent. При возникновении сбоев сервис восстанавливает его. Если мастер-VM находится внутри отказоустойчивого кластера, то восстановление будет выполняться непосредственно сервисами кластера.
Поскольку все процессы полностью автоматизированы, администраторам не нужно самостоятельно отслеживать состояние платформы и восстанавливать ее работу вручную.
Более подробно о логике работы рассказали в документации.
Следите за нашими новостями, чтобы не пропустить обновления.
