Выйти из системы

Сменить пользователя

Numa vServer: тестирование платформы виртуализации

В прошлом материале мы поговорили о российской платформе виртуализации Numa vServer — лицензировании, документации, сертификации, преимуществах и недостатках.

Сегодня мы вместе с вами протестируем функционал платформы «в бою» на версии Numa vServer: 1.1.1beta и Numa Collider: 1.2 «Максимальная».

Установка

Устанавливаем ОС согласно документу «Руководство администратора. Установка, настройка Numa vServer».

После установки ОС на хост при первом логине видим puid хоста, который отправляем в техническую поддержку вендора с заявкой для получения лицензии.

В ответ техническая поддержка предоставляет файл лицензии вида:

Для переноса файла лицензии на сервер преобразовываем его в .iso образ, а затем загружаем через консоль IPMI:

После перезагрузки весь функционал ОС становится активным.

Настраиваем сетевой интерфейс управления (mgmt). При необходимости использования VLAN на менеджмент интерфейсе – читаем КВ базы знаний Numa.

Чтобы активировать механизм отказоустойчивости (High Availability, HA), нужно настроить агрегацию на физических интерфейсах до (!) включения функции HA. Один из способов – создать bond на master-хосте, добавить в пул ресурсов 2 ведомых хоста, и перезагрузить их.

Устанавливаем Numa Collider, который поставляется в виде виртуальной машины формата .xva, предназначенной для развертывания и работы на сервере Numa vServer.

Добавляем хранилище через соответствующий пункт в интерфейсе Numa Collider. Заполняем необходимые параметры, выбираем тип хранилища и устройство.

Создаём пул ресурсов, который включает в себя серверы Numa vServer, соединённые друг с другом в общую единицу, на которой возможно развертывание, запуск и исполнение виртуальных машин (ВМ). При использовании общего хранилища, пул ресурсов позволяет виртуальным машинам работать с любым сервером Numa vServer, имеющим достаточный для функционирования ВМ объем оперативной памяти, и в дальнейшем динамически перемещаться между серверами Numa vServer с минимальными простоями.

При сбое отдельного сервера администратор может перезапустить отказавшую ВМ на другом сервере того же пула ресурсов. Если для пула включен механизм обеспечения высокой доступности (High Availability, HA), то в случае отказа сервера ВМ будут автоматически перемещены на работающий сервер. Для одного пула ресурсов поддерживаются до 64 серверов.

Важно!

Преимущества пулов (например, возможность динамически выбирать, на каком хосте Numa vServer запускать ВМ) доступны только при наличии хотя бы одного хранилища данных с общим доступом для членов пула.

Если возможно, необходимо отложить создание пула до тех пор, пока подобное хранилище не станет доступно

Создаём пул ресурсов из командной строки. Чтобы объединить в пул сервера 1, 2 и 3 (если сервер 1, например, является мастером), заходим в консоли серверов 2 и 3, и выполняем команду:

xe pool-join master-address=<host1 IP-address> master-username <administrator_username> master-password=<password>

Проверка функционала платформы

Загрузка серверов виртуализации Numa vServer и сервера управления Numa Collider работают штатно.

Проверяем НА: имитируем отключение мастер-хоста из IPMI. ВМ, которые были на мастере, включая Numa Collider, переключились на доступные хосты. Веб-интерфейс восстановился спустя ~5 минут. ВМ, находившиеся на других хостах, продолжили работать штатно. Master в пуле был перевыбран.

При выключении ВМ под защитой HA из Numa Collider – она останется выключенной. Если же сделать power off внутри ОС – машина будет перезапущена.

Проверяем функционирование системы разграничения доступа

Интеграция с LDAP работает, на тестовом стенде используем Active Directory:

Встроенная система оповещений/мониторинга по e-mail работает исправно.

Возможно настроить SNMP на хостах с ОС vServer и их мониторинг по обычным метрикам из zabbix-шаблона «Template OS Linux». 

Запрашиваем у вендора информацию о возможности настройки Zabbix для Numa Collider с возможностью мониторинга метрик системы виртуализации. Получаем инструкцию по настройке и шаблон для версии Zabbix 7.0 в формате yaml. Вендор уточнил, что шаблон находится в тестовом режиме и на более раннюю версию Zabbix не импортируется. 

Взаимодействие осуществляется по HTTP API. Чтобы шаблон функционировал, получаем токен аутентификации с Numa Collider. Для ставим на машину менеджер пакетов npm (менеджер пакетов, входящий в состав Node.js), а затем устанавливаем утилиту xo-cli:

После добавления токена в макрос узла Numa Collider в Zabbix и отработки обнаружения появились данные:

Проверяем механизм создания шаблонов ВМ

Шаблон можно создать:

  • на основе ВМ
  • на основе снимка ВМ (снапшота)

На основе снапшота

Для начала создаем снимок на целевой ВМ:

Выбираем нужный снимок, в выпадающем меню выбираем «Копировать в шаблон», после чего начинается его создание. ВМ из шаблона разворачивается примерно 1 минуту.

На основе ВМ

Чтобы создать шаблон на основе ВМ, нужно её выключить. После создания шаблона эта ВМ будет удалена. При создании шаблона создаются толстые диски (thick).

Механизм изменения ресурсов виртуальной машины работает исправно.

Проверяем Hot Add vCPU

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

Уровень производительности измеряли с помощью бэнчмарка в CPU-Z. Он вырос пропорционально добавленным ресурсам.

Проверяем Hot Add RAM

ОЗУ для ВМ выделяется по формуле:

0 <= Static RAM Min <= Dynamic RAM Min <= Dynamic RAM Max <= Static RAM Max

Как и в случае с vCPU, предельные значения RAM задаются при выключенной ВМ.

Объем ОЗУ, отображаемый в гостевой ОС, равен Static RAM Max. Ограничение осуществляется за счет работы с параметрами Dynamic RAM. При их изменении с помощью balloon-драйвера гипервизор будет управлять доступной для ВМ памятью.

Проверяем Hot Add Disk

Диск можно расширить, только отключив его от ВМ. То есть, расширить диск, на котором находится ОС, на горячую – нельзя.

Вендор подтвердил:

Проверяем механизм живой миграции

Живая миграция в безагентном режиме работает только на Linux. Однако, вендор рекомендует ставить vServer Tools на КАЖДУЮ ВМ.

Протестировали возможность миграции с хранилища на хранилище – ВМ остались включенными. HA включается только на Default хранилище, так как при включении на только что добавленном storage repository, который не был хранилищем по умолчанию – задача завершается ошибкой. При переключении HA на старом хранилище остались 2 виртуальных диска под метаданные и heartbeat, удалить которые было возможно только при выключении HA.

Проверяем механизм многофакторной аутентификации через One-Time Password. Воспользовались Я.Ключ, отсканировали QR. При следующем входе, после успешного ввода логина и пароля, запрашивают код с приложения на телефоне.

Проверяем механизм централизованного управления виртуальными сетями — работает в пределах пула ресурсов. Созданные в Numa Collider сети передаются на хосты в кластере.

Проверяем миграцию из VMware

Для импорта ВМ из vCenter нужно:

1.  Убедиться в отсутствии снапшотов на ВМ.

2. Запустить ВМ, удалить на ней VMware Tools, затем установить vServer Tools, перезапустить ВМ.

3. Выключить импортируемую ВМ.

4. Настроить вкладки импорта в Numa Collider и дождаться завершения процесса

Если выбрана опция «тонкий диск», первая часть импорта не отображается в диспетчере задач, после её окончания начинается вторая, которая до этого момента отображается на «0%» выполнения.

Когда устанавливали Xen агент на ВМ в среде VMware, по завершению возникла ошибка «installation failed». При этом в службах ОС агент был в статусе «Running».

Самостоятельно перезагрузили ВМ, провели импорт. После миграции машины в Numa и первого запуска появилось окно с оповещением о необходимости перезагрузки от агента Xen, после чего гостевой агент стал виден системой.

Встроенная система резервного копирования функционирует исправно. Запускаем создание полной резервной копии:

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

Есть возможность настраивать полный, инкрементный бэкап, создавать снапшоты по расписанию (в том числе с RAM), восстанавливать (в том числе и отдельные файлы из дельта резервных копий), а также – проводить непрерывную репликацию:

Механизм клонирования ВМ работает штатно:

Проверяем Multipathing

На момент тестирования хранилище подключено по FC, multipath активен на всех хостах по 4 путям:

Для одного из хостов поочередно выключаем FC-порты для имитации выхода из строя. ВМ продолжили работать в штатном режиме.

Однако, в интерфейсе Numa Collider спустя несколько минут после отключения порта по-прежнему отображаются все пути.

Проверяем работоспособность импортных и отечественных операционных систем в среде Numa, разворачиваем ВМ с ОС:

  • Windows Server 2019
  • Ubuntu 22.04
  • RED OS 8
  • Astra Linux
  • Alt Linux

Проверяем работу механизма affinity rules

Affinity/anti-affinity правила работают только при включении ВМ.

Для anti-affinity правил между ВМ — для ВМ необходимо назначать метки.

После назначения меток в настройках плагина «Load Balancer» необходимо указать заданную метку.

Интеграции с внешними СРК

Из отечественного — КиберБэкап. Работает в агентском режиме.

Из зарубежного с XAPI работают Veeam, Commvault, Vinchin.

Проверяем SDN 

Удалось создать сеть VxLAN, 2 машины, добавленные в 1 сегмент, были взаимосвязаны между собой, но недоступны извне.

SDN функционал работает. Создали 2 сегмента сети, в которых дали ВМ одинаковую адресацию. Результат: машины внутри сегментов видят друг друга, между разными сегментами связности нет.

Особенности, найденные в процессе тестирования

Не рекомендуется миграция без vServer Tools

Без vServer Tools не работает живая миграция машин с ОС Windows, в случае с Linux — работает. Несмотря на то, что на уровне ядра Linux есть ограниченная поддержка Xen, вендор настоятельно рекомендует ставить агенты, в том числе, на Linux. 

Также невозможно произвести миграцию ВМ без ОС.

Зависание консоли ВМ после смены сети

При смене сети на виртуальной машине с ОС Windows в веб-интефейсе Numa зависает консоль ВМ. Вендор проблему подтвердил — на текущий момент есть временное решение:

Перед сменой/отключением/удалением сетевого интерфейса, необходимо выключить его в Windows  («Панель управления»>»Сеть и  Интернет»>»Центр управления сетями и общим доступом»>»Изменение  параметров адаптера»). 

Однако, если внутри ОС Windows выполнить выключение а затем включение сетевого интерфейса – ВМ тоже зависает.

Чтобы предотвратить это, необходимо:

  1. Отключить интерфейс из настроек адаптера внутри ОС
  2. Отключить интерфейс в панели «Сеть» веб-интерфейса «Нума»
  3. Подключить интерфейс
  4. Подключить интерфейс внутри ОС

Сбои в работе балансировщика нагрузки

Обновление истекшей лицензии на Numa Collider

В случае, если будет просрочена пробная лицензия на Numa Collider – в текущей версии обновить её невозможно. Нужно развернуть новый экземпляр ВМ Numa Collider, а в таком случае будут потеряны задания резервного копирования, настройки пространств и плагинов. В таком случае можно будет сделать импорт конфигурации, если вы предварительно сделали её резервную копию.

О том, как разворачивали кластер в SpaceVM с 0 — рассказывали тут.

Если у вас остались вопросы по работе Numa vServer — просто заполните форму, мы свяжемся с вами.