Тестируем отечественную систему виртуализации: ПК СВ «Брест»21.02.2024 16:30

Привет, Хабр!

Мой цикл статей о российских системах виртуализации понемногу подходит к концу. Сегодня будем разбирать возможности последнего участника эксперимента — ПК СВ «Брест». Посмотрим, как реализован заявленный производителем функционал, насколько удобно им пользоваться, и порассуждаем, для кого предназначена эта система.

Предыдущие материалы:

Кратко о ПК СВ «Брест»

Итак, что же известно об этом решении.

Программный комплекс «Средства виртуализации «Брест» (ПК СВ «Брест») — российская облачная платформа виртуализации со встроенными средствами защиты информации ОС Astra Linux Special Edition.

Разработчик ПК СВ «Брест» — ГК «Астра». Кстати, в портфель компании также входит другое решение, которое мне довелось тестировать, — VMmanager.

Как сообщает вендор, «Брест» подходит для развертывания частных и публичных облаков, в том числе распределенных, позволяет гибко управлять виртуальной инфраструктурой и ее компонентами, учетными записями пользователей и виртуальными машинами. 

Скриншот с сайта разработчика

Несмотря на то, что ПК СВ «Брест» — это решение для создания облаков, а такой класс решений не рассматривался в цикле, «Брест» довольно часто можно встретить как систему серверной виртуализации.

Функциональные возможности «Бреста» заявлены на странице продукта и в листовке. 

Что ж, давайте посмотрим, как они реализованы.

Результаты тестирования ПК СВ «Брест»

Кратко об условиях:

• В качестве тестовой среды выступает система виртуализации QEMU/KVM, на которой под «Брест» были подготовлены два сервера. Использовались дистрибутивы ОС Astra Linux SE 1.7.2 и Брест 3.2.

• Для тестирования выбрал самый простой сервисный режим (о режимах чуть ниже) и после установки добавил еще один узел. Интересно, что установка Бреста 3.2 поддерживается только на ОС Астра 1.7.2, тогда как актуальная версия ОС Астра — 1.7.5.

• В качестве общего СХД, как обычно, использовал iSCSI хранилище на базе TrueNAS, подключив его к узлам виртуализации как блочное устройство. 

• Тестирование проводилось без предварительного ознакомления с продуктом или какого-либо обучения. Разбираться со всеми нюансами приходилось по ходу установки и настройки. Результаты у инженера, который уже работал с системой, могут отличаться.

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

Установка продукта и настройка

Документация

Документация и база знаний — в открытом доступе. Найти инструкции по установке не составило труда, есть удобный поиск по выбранной версии продукта — им я часто пользовался в процессе тестирования. В документации также описан процесс создания и подготовки виртуальной машины KVM для тестового стенда Брест. Материалы доступны только на русском языке.

Установочные дистрибутивы ОС и самого «Бреста» были предоставлены для тестирования после обращения в ГК «Астра». В открытом доступе мне их найти не удалось, все-таки это коммерческие продукты.

Архитектура решения

«Брест» 3.2 — программный комплекс виртуализации от ГК «Астра» на базе открытой платформы OpenNebula 6.0.0.2.

При развертывании доступны два режима:

• Сервисный. В сервисном режиме все ВМ запускаются от имени служебного пользователя системы (oneadmin). В таком режиме нет необходимости устанавливать контроллер домена (FreeIPA) и включать сервер в домен. Авторизацию в веб-интерфейсе ПК СВ обеспечивает PAM-модуль службы apache2.

• Дискреционный. В дискреционном режиме обеспечивается дискреционное и мандатное разграничение доступа к облаку ресурсов и виртуальных машин. В таком режиме ВМ запускаются от имени доменного пользователя, авторизовавшегося в «Бресте». Для работы в дискреционном режиме необходимо, чтобы все серверы из состава ПК СВ входили в один домен FreeIPA.

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

Простота установки

Установку «Бреста» я выполнял впервые. На подготовку серверов ушло некоторое время — плюс-минус столько же, сколько потребовалось для других платформ. 

Установка оказалась простой и быстрой, выполнялась всего одной командой:

# apt install brestcloud-base

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

 Информационная панель выглядит красиво.

Возможность установки в открытом и закрытом контурах

В данном тестировании установка производилась в открытом контуре. Однако есть возможность установить «Брест» как в открытом контуре, так и в закрытом контуре/изолированной среде без доступа в интернет, так как установка производилась полностью из дистрибутивов ISO.

Управление гипервизором

Управление осуществляется централизованно через веб-интерфейс, а также с помощью командной строки утилитами one* из пакета opennebula-tools, однако для этого будет необходимо произвести предварительную настройку аутентификации на сервере управления с привязкой токена и переменных окружения.

Операции с виртуальными машинами

Установка виртуальной машины из ISO образа

Встроенных шаблонов, как у VMmanager 6, тут нет, но их можно создавать из предварительно загруженных ISO-образов. Есть отдельные хранилище образов и хранилище шаблонов.

В разделе образов также хранятся и образы дисков виртуальных машин. Это немного сбивает с толку, я не сразу понял, зачем они здесь. Но, как оказалось, это преднастроенные «болванки» дисков для новых ВМ.

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

Если до этого все было просто и быстро, то при создании первой ВМ пришлось основательно погрузиться в документацию — быстро и интуитивно не получилось. И это с учетом того, что на тот момент уже было подключено общее сетевое хранилище и еще требовалось добавить его в «Брест». Добавить его из интерфейса не получилось, пришлось создавать специальный файл конфигурации по инструкции из документации. 

Можно резюмировать, что создание виртуальной машины, конечно, работает, но не интуитивно понятно пользователю VMware. Причина такого поведения видится в особенностях работы OpenNebula.

Выбор метода эмуляции процессора

В настройках доступны следующие варианты эмуляции, их можно выбрать на уровне шаблона или в настройках ВМ.

Полный список вариантов:

Способы создания виртуальной машины

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

Базовые операции с виртуальной машиной

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

В параметрах присутствует более детальная информация по ВМ и более глубокие настройками.

Возможности установки Guest Agent

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

Из минусов — нельзя изменить пароль суперпользователя в гостевой ОС.

Клонирование виртуальной машины

Возможности клонирования ВМ я не нашел ни в интерфейсе, ни в документации. Судя по всему, его просто нет.

Снапшоты

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

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

Образ виртуальной машины

Доступно создание шаблона (образа) из виртуальной машины, при этом ВМ должна быть выключена. 

Группировка виртуальных машин

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

Живая миграция виртуальной машины

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

Горячее изменение ресурсов

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

Увеличение диска происходит без перезагрузки.

Способы подключения к виртуальной машине

Доступ к ВМ осуществляется по VNC из веб-интерфейса или клиента Virt Viewer, работает «из коробки», дополнительных настроек не требуется. 

Настройки сети

Различные типы эмуляции сетевых интерфейсов

В документации этой информации нет. Погуглив по OpenNebula, я пришел к выводу, что при создании сетевого интерфейса по умолчанию используется тип virtio, однако  доступно изменение эмуляции на e1000, rtl8139 через изменения параметров контекста в шаблоне ВМ. 

VLAN на узлах в формате Standard vSwitch

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

Это ограничение видится существенным в части удобства использования продукта. Было бы гораздо удобнее делать это из интерфейса.

Агрегация линий в формате Standard vSwitch

Поддерживается работа сетевых адаптеров в режиме агрегации и балансировки. Есть все стандартные режимы. Как и в предыдущем пункте, доступно только из консоли.

Сетевые настройки в формате распределенного коммутатора (Distributed vSwitch)

Реализация аналога VMware Distributed vSwitch возможна с помощью Open vSwitch. В моем примере я использовал стандартную настройку через линукс бридж. Есть возможность импортировать текущие настройки с узлов.

Поддержка функции сетевой фабрики

Аналога сетевой IP-фабрики в Бресте я не нашел. Теоретически, используя аналогию с другими производителями, фабрику возможно реализовать через Open vSwitch. Если кто-то из читателей обладает информацией об этом, поделитесь, пожалуйста, в комментариях. 

Настройки хранилища

Поддержка различных типов эмуляции дисков для виртуальной машины

При создании нового диска поддерживается Virtio/SATA/SCSI. Изменение доступно в веб-интерфейсе при редактировании параметров диска ВМ. По умолчанию используется тип virtio.

«Тонкие» и «толстые» диски

Тонкие диски доступны практически на всех типах доступных хранилищ, кроме толстого LVM. На моем стенде использовалось толстое хранилище LVM, но при этом я смог мигрировать диск в локальное хранилище с тонким диском.

Работа с SAN хранилищами

Есть поддержка SAN СХД (scsi/iscsi/FC/FCoE). Подключение выполняется частично из графического интерфейса, а также с помощью консоли на узле (добавление в параметров в файл конфигурации хранилищ). Настройки самого устройства и параметров multipath выполняются на уровне операционной системы узлов виртуализации.

Работа в гиперконвергентной среде

В документации есть сценарий гиперконвергентного варианта развертывания на базе SDS Ceph. 

Отказоустойчивость и эффективность

НА-кластер

Отказоустойчивость включается на уровне ВМ при соблюдении следующих условий:

• наличие в кластере минимум двух рабочих узлов виртуализации;  

• общее хранилище дисков ВМ, доступное на каждом из узлов;  

• поддержка со стороны узлов технологии IPMI (Intelligent Platform Management Interface), данные для авторизации по IPMI должны быть указаны в настройках каждого узла виртуализации;  

• для ВМ должен быть установлен признак отказоустойчивости (Высокая доступность).

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

Репликация виртуальных машин

В данном продукте функции репликации виртуальных машин мне найти не удалось.

Автоматическая балансировка виртуальных машин

Автоматической балансировки не нашел. Для ручной балансировки предлагается воспользоваться правилами Affinity и Anti-Affinity.

Системные настройки

Ролевой доступ

Есть возможность создания групп пользователей с разграничением доступа к различным разделам и возможностью задать квоты — индивидуальные или на группу. 

Доступные для использования вычислительные ресурсы выделяются тенанту (группе) в разделе «Квоты».

Интеграция с внешними каталогами

Возможна интеграция с FreeIPA, но для этого необходимо устанавливать «Брест» не в сервисном режиме, а в дискреционном, так как используются разные пакеты установки (apt install ​​brestcloud-ipa). Иными словами, интеграция есть, но не тестировалась.

Интеграция с почтовыми системами

Я не нашел возможности настроить уведомления пользователей по электронной почте на определенные события с ВМ/узлами или на появление ошибок в самом «Бресте».  

Скорей всего, разработчики отдали эти функции на откуп интеграции с Zabbix. Вот что удалось найти в документации:

ПК СВ «Брест» поддерживает интеграцию с системой мониторинга Zabbix для получения информации о функционировании облака, наряду с общесистемными метриками производительности узлов кластера.

Резервное копирование сервера управления

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

Мониторинг и удобство работы с системой

Удобство работы с системой

Если говорить об интерфейсе, то тут классический интерфейс OpenNebula с переводом на русский (правда, местами он отсутствовал).

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

Поскольку я использовал самый простой сценарий развертывания, я, скорее всего, не смог прочувствовать всё удобство «Бреста». Однако, судя по документации, многие действия выполняются не из интерфейса, а это, пожалуй, главное неудобство многих панелей управления виртуализацией.

Мониторинг системы

Помимо графиков в интерфейсе есть поддержка Zabbix, включая шаблоны. Нет встроенной системы уведомлений по почте. Кроме того, в самом интерфейсе нет уведомлений даже на случай падения сервера. Выключенная ВМ почему-то показывает не нулевую статистику использования ЦПУ/ОЗУ на текущий момент:

Подведем итоги

По традиции отдельно отмечу что в «Бресте» мне понравилось, а что нет.

Что понравилось:

• ПК СВ «Брест» позиционируется как защищенная система виртуализации. Во многих маркетинговых материалов делается акцент на вопросы информационной безопасности. Я согласен с этим акцентом, система очень плотно интегрирована со встроенными средствами защиты в операционную систему, а также имеет свои механизмы защиты.

• Следующий плюс является во много причиной предыдущего. ПК СВ «Брест» — это продукт ГК «Астра», которая также занимается разработкой операционной системы Astra Linux, а значит и адаптацией пакетов QEMU/KVM и libvirt. Это позволяет рассчитывать на нативную и полноценную поддержку виртуализации операционной системой.

• В рамках тестирования я проверял функции именно серверной виртуализации, но ПК СВ «Брест» позиционируется как облако. Я рассчитываю, что это означает наличие большого количества облачных функции, которые просто не удалось затронуть в рамках тестирования.

Что не понравилось:

• Для меня самыми существенными недостатками стали функциональные особенности. 

  • Во-первых, часть полезных функций не реализована вовсе (например, горячее изменение CPU и RAM). 

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

• Логика работы некоторых операций не привычна системному администратору VMware. Самый яркий пример — это процесс создания виртуальной машины.

Если вынести за скобки вопросы сертификации, информационной безопасности и облачного позиционирования, то мне не до конца понятно, для какого Заказчика предназначена система ПК СВ «Брест». Испытуемый проигрывает по функциям конкурентам на рынке, даже в сегменте систем, переиспользующих open source. Но на практике в 2024 году в России вопросы сертификации и информационной безопасности вынести за скобки нельзя, и тогда рынок этой системы становится чуть более понятным. Также следует еще раз оговориться, что ПК СВ «Брест» позиционируется для задач облачной виртуализации. Возможно, на том рынке это решение и «порвет» всех конкурентов, но это будет уже совсем другая история:)

Если у вас остались вопросы, задавайте их в комментариях, постараюсь ответить!

© Habrahabr.ru