Особенности национальной виртуализации на SharxBase
После ухода из России компании VMware и других крупнейших мировых поставщиков решений виртуализации и облачной инфраструктуры, появилась срочная задача найти альтернативу привычным инструментам. В процессе поиска команда Linx исследовала одно из доступных на российском рынке решений ― программно-аппаратную платформу виртуализации SharxBase. Делимся своими впечатлениями.
Новая перспектива
Большинство участников рынка и госструктур планируют переход на отечественные решения в ближайшей перспективе. Сегодня в этом сегменте рынка представлено около 20 вариантов решений для построения платформы виртуализации российской разработки. Но все они выступают в роли «догоняющих». Бизнесу необходима функциональность, которую предлагали ушедшие компании, но ее пока ни у кого нет ― по крайней мере на все 100%.
Создать аналоги сложных программных продуктов, которые разрабатывались глобальными корпорациями десятилетиями, невозможно за 1–2 года Тем не менее, движение в этом направлении есть.
Для Linx одной из актуальных на сегодняшний день задач стал выбор отечественной платформы для построения частных облаков. Такие запросы стали поступать от заказчиков, вступивших на путь импортозамещения и при этом планирующих перенести свою инфраструктуру в облако. Одним из заинтересовавших нас решений стала платформа SharxBase.
SharxBase ― это гиперконвергентное решение, построенное на серверах x86_64 архитектуры стандартного форм-фактора с установленными в них твердотельными дисками (SSD или NVMe), высокопроизводительными процессорами и сетевой картой 10 Гбит/с, 25 Гбит/с или 40 Гбит/с.
Плюсы и минусы
Начнем с плюсов: это российский продукт, который внесен в реестр отечественного ПО и имеет сертификат ФСТЭК 4-го уровня, что позволяет использовать его для размещения ГИС, ИСПДн до первого класса включительно, а также КИИ.
Система достаточно зрелая, поскольку появилась на рынке еще в 2018 году. Вендор предоставляет техподдержку 24×7.
Собственный фреймворк для построения логических кластеров и отсутствие выделенных функциональных ролей серверов обеспечивают отказоустойчивость, а интеграция вычислительных мощностей и распределенного хранилища в единую программно-управляемую среду делает возможным централизованную управление платформой.
SharxBase поддерживает создание мультитенантных кластеров до 62 узлов, что позволяет эффективно управлять ИТ-ландшафтом для различных клиентов или подразделений, соблюдая их индивидуальные технические требования.
Высокопроизводительное хранение: SDS-решения, позволяющее хранить данные в трех экземплярах.
Что можно делать на базе системы:
через графический интерфейс управлять ресурсами и виртуальными машинами;
создавать виртуальные машины из шаблонов;
создавать квоты ресурсов в изолированном контуре с персонифицированным доступом тенанта в данный контур и возможностью управлять распределением выданных квот;
гибко масштабировать квоту тенанта;
без выключения виртуального сервера расширять и добавлять виртуальные дисковые ресурсы (CPU/RAM ― только для выключенной ВМ);
создавать снэпшот/восстанавливать из снэпшотов, без остановки виртуальной машины;
осуществлять горячую миграцию виртуальных машин между хостами;
выполнять автоматический перезапуск виртуальной машины в случае полного отказа гипервизора на другом гипервизоре.
Каких функций у платформы нет:
механизма распределения нагрузки;
мониторинга производительности;
интеграции с системами внешнего резервного копирования.
Другие особенности:
для синхронизации распределенного хранилища и обеспечения сервиса имен системе нужны внешние серверы NTP и DNS;
не получится провести качественную диагностику: возможности интеграции с внешними системами мониторинга позволяют лишь получить сигнал о проблеме, которую потом придется искать самостоятельно в интерфейсах платформы;
интерфейс избыточен по сравнению с функционалом. В основе SharxBase ПО с открытым и закрытым кодом. В интерфейсе системы осталось много лишних элементов, которые неактивны или работают некорректно. Перед провайдером встает выбор: открыть пользователю минимум функций, либо выдать расширенные права доступа. Во втором случае в интерфейсе появляются кнопки, нажатие на которые может привести к непредсказуемым результатам. Кастомизировать или убрать эти функции невозможно ― только объяснить клиенту, с чем можно работать, а с чем нет.
Как это выглядит
Интерфейс, как видим, построен на OpenNebula, что сближает SharxBase с «Брестом» и «Горизонтом», но, конечно, есть отличия.
Так выглядит экран общей загрузки кластера:
Для создания ВМ есть заранее установленные шаблоны:
А вот так они выглядят в целом, опции группировки по папкам пока не предусмотрено:
Кластеризация ВМ в SharxBase полностью своя, и служебные базы данных не «разъезжаются», как в классической Nebula при интенсивном использовании инфраструктуры. Реализовано тегирование ВМ для их группировки по нужным параметрам и дальнейшей работы:
Есть опция просмотра графиков производительности каждой ВМ:
Доступно создание снэпшотов для восстановления исходного состояния ВМ:
Можно отслеживать историю событий ВМ:
Отдельно можно просматривать хранилища данных, отслеживать их занятость. Все они ― блочные устройства внутри хостов, распределенные по всему кластеру, что позволяет осуществлять достаточно простой переезд ВМ между узлами:
С точки зрения сети можно быстро получать доступ к структуре виртуальных сетей и их распределению:
При необходимости можно использовать правила межсетевого экранирования:
MPM-модуль используется для отслеживания состояния платформы и позволяет обнаружить визуально проблемы с компонентами вычислительного кластера.
Так выглядит состояние использования накопителей:
Здесь же можно мониторить состояние блоков питания и сетевых карт:
Еще одно отличие SharxBase: разработан отдельный компонент, позволяющий вносить в систему настройки в соответствии с требованиями ФСТЭК:
Это позволяет детально отслеживать действия пользователей в рамках их учетных записей, поднимать логи из архивов, управлять учетными записями, их блокировками и т.д.
Наконец, опция создания виртуального ЦОДа позволяет подтягивать в себя пул ресурсов в соответствии с ИС определенных клиентов, разграничивая их между собой.
Выглядит виртуальный ЦОД так:
Установка и поддержка вендора
SharxBase ― закрытая система, которая не предусматривает самостоятельную установку и настройку. Инсталляцию выполняют специалисты технической поддержки SharxDC. Они же предоставляют список требований к оборудованию и настройкам интерфейсов. Инженеры вендора проверяют совместимость дисков и контроллеров с системой, а затем разворачивают платформу.
3 рабочих дня занимает настройка комплекса на 3 хоста, если заранее предоставить инженерам SharxDC доступ во все необходимые логические и физические сети.
Специалисты вендора проводят обучение сотрудников заказчика, для эффективной подготовки специалист должен иметь опыт работы с платформами виртуализации, а также базовые знания администрирования Linux
При эксплуатации платформы заказчик выступает в роли оператора платформы, имеет возможность управления учетными записями, квотами, образами дисков и ОС, виртуальными машинами и сетями.
При этом добавление и вывод вычислительных узлов, дисков, интеграция со службами каталогов, а также траблшутинг платформы остаются в руках технических специалистов SharxDC.
Сценарии виртуализации
На основе своего опыта мы выделили несколько основных сценариев использования SharxBase.
Первый ― создание инфраструктуры виртуализации для виртуальных ЦОД.
Второй ― использование SharxBase как элемента изолированной ИТ-инфраструктуры. Такие решения называют Silo («силос») или «столб». Они используются в случаях, когда заказчику нужен определенный набор функций.
Вендор или интегратор устанавливает оборудование, разворачивает платформу виртуализации с ВМ и запускает приложение. SharxBase позволяет создавать такие закрытые решения с возможностью масштабирования элементов. Для внешнего мониторинга можно установить стороннее ПО (Prometheus, Zabbix).
SharxBase лучше подходит для статичных ИТ-ландшафтов, где редко меняется число виртуальных серверов. Типичный клиент ― промышленное предприятие с несколькими десятками серверов, параметры которых меняются довольно редко, а нагрузка на виртуальные машины стабильна и предсказуема.
При необходимости платформа позволяет увеличивать или уменьшать число серверов гипервизоров, но возможности делать это самостоятельно нет ― процедура выполняется исключительно вендором.
Миграция с SharxBase на другие платформы виртуализации возможна, но затруднительна, так как требует конвертации дисков ВМ из одного формата в другой. При этом возникает длительный простой сервиса.
Кроме того при наличии установленных в ОС специфических драйверов и приложений конвертированная ВМ может не запуститься.
Итого
По нашей предварительной оценке, в SharxBase сегодня реализовано около 30% привычного уровня функциональности инструментов ведущих мировых вендоров. Система, безусловно, нуждается в дальнейшем развитии, однако, по нашим оценкам, имеющегося на сегодняшний день функционала вполне достаточно, чтобы удовлетворять потребности 50–60% корпоративных клиентов в том, что касается возможностей виртуализации ИТ-инфраструктуры.
Алексей Медведев, руководитель отдела по облачным сервисам Linx
Антон Бахвалов, облачный инженер Linx
