Сегодня я расскажу о гиперконвергентной платформе SharxBase. На Хабре еще не было обзора этого комплекса, и с этой несправедливостью было решено покончить. Нашей команде удалось протестировать решение «в бою», о результатах — ниже.

image

P.S. Под катом много таблиц, реальных цифр и прочего «мяса». Для любителей погрузиться в суть — welcome!

О продукте


Платформа SharxBase построена на базе серверов производства Intel и программного обеспечения открытых проектов OpenNebula и StorPool. Поставляется в виде коробочного решения, включающего в себя серверное оборудование с предустановленным ПО виртуализации и распределенного хранения.

Для заказа доступна одна из четырех базовых типовых конфигураций — Small, Medium, Large, Storage, — которые различаются объемом доступных вычислительных ресурсов (процессоров, оперативной памяти) и дискового пространства. Серверы выполнены в виде модулей: типовое шасси высотой 2RU, в которое может быть установлено до четырех серверов, для установки в стандартную 19" серверную стойку. Платформа поддерживает как горизонтальное масштабирование путем увеличения числа узлов, так и вертикальное, путем увеличения объема оперативной памяти в узлах, установки дополнительных накопителей и плат расширения. На текущий момент поддерживается установка сетевых адаптеров, модулей контроля загрузки, NVMe накопителей.

Архитектура хранилища


Для организации распределенного отказоустойчивого хранилища используются flash-накопители (SSD и/или NVMe). В качестве среды передачи данных используется Ethernet. Для передачи трафика СХД требуется использовать выделенные сетевые интерфейсы — не менее двух интерфейсов 25 GbE. Службы, обеспечивающие работу распределенного хранилища, выполняются на каждом сервере, входящем в кластер, и используют часть его вычислительных ресурсов. Объем ресурсов зависит от количества и объема установленных накопителей, в среднем накладные расходы составляют 34 ГБ ОЗУ на хост. Подключение к распределенному хранилищу происходит через протокол блочного доступа iSCSI. Для обеспечения отказоустойчивости поддерживается двух- или трехкратное резервирование данных. Для продуктивных инсталляций производитель рекомендует использовать трехкратное резервирование. На текущий момент из технологий оптимизации хранения поддерживается только тонкое выделение дискового пространства (thin provisioning). Дедупликация и компрессия данных средствами распределенного хранилища не поддерживаются. В будущих версиях заявлена поддержка erasure coding.

Виртуализация


Для запуска виртуальной машины (ВМ) используется гипервизор KVM. Поддерживаются все основные функциональные возможности по их созданию и управлению:

  • создание ВМ с нуля с указанием требуемой аппаратной конфигурации (процессорные ядра, объем ОЗУ, количество и размер виртуальных дисков, количество сетевых адаптеров и др.);
  • клонирование ВМ из существующей или шаблона;
  • создание мгновенного снимка (снапшота), удаление снимка, откат изменений, сделанных в ВМ с момента создания снимка;
  • изменение аппаратной конфигурации ранее созданной ВМ, включая подключение или отключение виртуального диска или сетевого адаптера для включенной ВМ (hotplug / hot unplug);
  • миграция ВМ между серверами виртуализации;
  • мониторинг состояния ВМ, включая мониторинг загрузки вычислительных ресурсов и виртуальных дисков (текущий размер, объем ввода-вывода в МБ/с или в IOPS);
  • планирование операций с ВМ по расписанию (включение, выключение, создание мгновенного снимка и т.д.);
  • подключение и управление ВМ через протоколы VNC или SPICE из web-консоли.

image
Схема типового блока (4 узла)

Управление платформой выполняется из графического интерфейса или командной строки (локально или удаленно при подключении по SSH), а также через публичный API.

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

Помимо поддержки серверной виртуализации в SharxBase реализована возможность создания программно-конфигурируемых ЦОД и частных облачных инфраструктур. В качестве примера таких функций можно отметить:

  • управление правами доступа на основании членства пользователя в группах и списках контроля доступа (ACL): разным группам пользователей могут быть назначены права, ограничивающие доступ к компонентам виртуальной инфраструктуры;
  • ведение учета потребления ресурсов (accounting): процессоров, оперативной памяти, дисковых ресурсов;
  • оценка стоимости потребления вычислительных ресурсов (showback) в условных единицах на основании потребленных ресурсов и их цены;
  • базовые возможности IPAM (IP Address Management): автоматическое назначение IP адресов для сетевых интерфейсов ВМ из заранее определенного диапазона;
  • базовые возможности SDN: создание виртуального маршрутизатора для передачи трафика между виртуальными сетями.

С использованием разработанного модуля защиты информации в SharxBase реализованы дополнительные меры обеспечения ИБ системы управления платформой: настраиваемые требования к паролям учётных записей пользователей (сложность, длина, длительность использования, повторяемость и др.), блокировка пользователей, управление текущими сеансами доступа к консоли управления, регистрация событий и др. Программное обеспечение внесено в Реестр российского программного обеспечения (номер 4445). Получено положительное заключение испытательной лаборатории об успешно завершенных сертификационных испытаниях программного обеспечения SharxBase в системе сертификации ФСТЭК РФ по 4 уровню контроля отсутствия НДВ, а также на соответствие ТУ (выполнение требований по защите сред виртуализации) до 1 класса ГИС /1 уровня защищенности ИСПДн включительно. Получение сертификата соответствия требованиям в системе сертификации средств защиты информации №РОСС RU.0001.01БИ00 (ФСТЭК РФ) ожидается в декабре 2018 года.

Детальное описание функциональных возможностей приведено далее в таблице.

Мониторинг


Мониторинг SharxBase предоставляет доступ к расширенной информации о состоянии платформы, настройке оповещений и аналитики состояния платформы.
Подсистема мониторинга представляет собой распределенную систему, установленную на каждом из узлов кластера и предоставляющую данные о состоянии платформы системе управления виртуализацией.

Подсистема мониторинга в режиме реального времени производит сбор информации о ресурсах платформы, таких как:

Серверные узлы Блоки питания Коммутаторы Виртуальные машины Распределенное хранилище данных
— Серийный номер блока
— Серийный номер узла и материнской платы
— Температура блока и узла
— Модель и нагрузка ЦПУ
— Номера слотов, частоту, размер и доступность ОЗУ
— Адрес узла и хранилища
— Скорость вращения вентиляторов охлаждения
— Состояние сетевого адаптера
— Серийный номер сетевого адаптера
— Состояние диска и его системную информацию
— Серийный номер блока питания
— Состояние блока питания и его нагрузка
— Модель коммутатора
— Состояние коммутатора и его портов
— Скорость вращения вентиляторов охлаждения
— Статус вентиляторов охлаждения
— Отображение списка VLAN
— Нагрузка ЦПУ
— Нагрузка ОЗУ
— Нагрузка сети
— Состояние виртуальной машины
— Скорость записи/чтения диска
— Скорость входящих/исходящих соединений
— Отображение свободного/занятого пространства
— Состояние дисков
— Занятое пространство на диске
— Ошибки дисков

Промежуточные итоги


К преимуществам решения можно отнести:

  • возможность поставки в организации, находящихся в санкционных списках;
  • решение базируется на проекте OpenNebula, который давно и активно развивается;
  • поддержка всех необходимых функций в части серверной виртуализации, достаточных для небольших и средних инсталляций (до 128 хостов);
  • наличие модуля защиты информации, обеспечивающего реализацию требований регуляторов в области защиты информации.

К недостаткам решения можно отнести:

  • меньшие функциональные возможности по сравнению с другими HCI решениями на рынке (например, Dell VxRail, Nutanix);
  • ограниченная поддержка со стороны систем резервного копирования (на текущий момент заявлена поддержка Veritas NetBackup);
  • часть задач по администрированию выполняется из консоли и не доступны через web.

Функциональные возможности


image
image
image
image

При расширении портфолио гиперконвергентных решений мы провели совместно с вендором тесты на производительность и отказоустойчивость.

Тестирование производительности


Стенд тестирования представлял собой 4х узловой кластер из серверов Intel HNS2600TP. Конфигурация всех серверов являлась идентичной. Серверы имели следующие аппаратные характеристики:

  • модель сервера – Intel HNS2600TP;
  • два процессора Intel Xeon E5-2650 v4 (12 ядер с тактовой частотой 2.2 ГГц и поддержкой Hyper Threading);
  • 256 ГБ оперативной памяти (для запуска ВМ доступно 224 ГБ памяти);
  • сетевой адаптер с 2-я портами QSFP+ со скоростью передачи данных 40 Гбит/с;
  • один RAID контроллер LSI SAS3008;
  • 6 SATA SSD накопителей Intel DC S3700 объемом 800 ГБ каждый;
  • два блока питания номинальной мощностью 1600 Вт каждый.
  • на серверах установлено ПО виртуализации SharxBase v1.5.

Все серверы подключались к сетевому коммутатору Mellanox. Схема подключения приведена на рисунке.

image
Схема подключения серверов на тестовом стенде

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

Тестирование дисковой подсистемы осуществлялось при помощи ПО Vdbench версии 5.04.06. На каждом физическом сервере было создано по одной ВМ с ОС Linux с 8 vCPU, 16 ГБ ОЗУ. Для тестирования на каждой ВМ было создано по 8 виртуальных дисков объемом 100 ГБ каждый.

В ходе тестов проверялись следующие типы нагрузок:

  • (Backup) 0% Random, 100% Read, 64 KB block size, 1 Outstanding IO;
  • (Restore) 0% Random, 100% Write, 64 KB block size, 1 Outstanding IO;
  • (Typical) 100% Random, 70% Read, 4 KB block size, 4 Outstanding IO;
  • (VDI) 100% Random, 20% Read, 4 KB block size, 8 Outstanding IO;
  • (OLTP) 100% Random, 70% Read, 8 KB block size, 4 Outstanding IO.

Результаты тестирования данных типов представлены в таблице:

image
image
image
Хранилище обеспечивает особо высокие показатели производительности на последовательных операциях чтения и записи 8295,71 МБ и 2966,16 МБ соответственно. Производительность хранилища при типовой нагрузке (случайный ввод-вывод блоками 4КБ с 70% чтения) достигает 133977,94 IOPS при средней задержке ввода-вывода в 1,91 мс, и снижается при увеличении соотношения операций записи к операциям чтения.

Тестирование отказоустойчивости


Данные тесты позволяли удостовериться, что отказ одного из компонентов системы не приводит к остановке всей системы.
Тест Детали теста Комментарии
Отказ диска в пуле хранения данных 14:00 – система работает в штатном режиме;
14:11 – отключение первого SSD в Server 1;
14:12 – в консоли управления платформой отображается отказ SSD;
14:21 – отключение первого SSD в Server 2;
14:35 – в консоли управления платформой отображается отказ двух SSD;
14:38 – возвращение дисков в серверы 1 и 2. LED индикаторы на SSD не отображаются;
14:40 – инженер через CLI выполнил добавление SSD в хранилище;
14:50 – в консоли управления платформой отображаются как работающие;
15:00 – синхронизация компонентов дисков ВМ завершена;
Система отработала отказ штатно. Показатель отказоустойчивости соответствует заявленному.
Отказ сети 15:02 – система работает в штатном режиме;
15:17 – отключение одного из двух портов Server 1;
15:17 – потеря одного Echo запроса до IP адреса веб-консоли (изолированный сервер выполнял роль лидера), ВМ, работающая на сервере, доступна по сети;
15:18 – отключение второго порта на Server 1, ВМ и консоль управления сервером стали недоступны;
15:20 – ВМ перезапустилась на узле Server 3;
15:26 – сетевые интерфейсы Server 1 подключены, сервер вернулся в кластер;
15:35 – синхронизация компонентов дисков ВМ завершена;
Система отработала отказ штатно.
Отказ одного физического сервера 15:35 – система работает в штатном режиме;
15:36 – выключение Server 3 через команду poweroff в IPMI нтерфейсе;
15:38 – тестовая ВМ перезагрузилась на Server 1;
15:40 – включение Server 3;
15:43 – работа сервера восстановлена;
15:47 – синхронизация завершена.
Система отработала отказ штатно.

Итоги тестирования


Платформа SharxBase обеспечивает высокий уровень доступности и отказоустойчивости при выходе из строя одного любого основного аппаратного компонента. Из-за троекратного резервирования для дисковой подсистемы платформа гарантирует доступность и сохранность данных при двойном отказе.

К недостаткам платформы можно отнести высокие требования к дисковому пространству, вызванные необходимостью хранить и синхронизировать три полные копии данных, и отсутствие механизмов более эффективной утилизации дискового пространства, таких как дедупликация, компрессия или erasure coding.

По результатам всех проведенных тестов можно сделать выводы о том, что гиперконвергентная платформа SharxBase способна обеспечивать высокий уровень доступности и производительности для различного типа нагрузок, включая OLTP системы, VDI и инфраструктурные сервисы.

Илья Куйкин,
Ведущий инженер-проектировщик вычислительных комплексов,
«Инфосистемы Джет»

Комментарии (6)


  1. Hardened
    07.11.2018 20:50

    Из обзора не очень понятно, что привнёс российский вендор в решение и кодовую базу. Благодаря чему получен номер в реестре Российского ПО? Какие меры реализованы для соответствия УЗ1?


    1. JetHabr Автор
      09.11.2018 11:01

      Добрый день! Ответ от вендора:
      Перечисленные в статье компоненты использованы в конечном решении, но функциональность платформы обеспечивается не только данными компонентами, но и другими модулями собственной разработки компании.
      Для обеспечения ИБ реализованы в разработанном модуле защиты информации настраиваемые гибкие требования к паролям учётных записей пользователей, блокировка, управление сеансами доступа к консоли управления, регистрация событий и др.
      Получено положительное заключение испытательной лаборатории об успешно завершённых сертификационных испытаниях. Получение сертификата соответствия требованиям в системе сертификации средств защиты информации ФСТЭК РФ — в начале 2019 года.


  1. GilevVyacheslav
    08.11.2018 07:29

    вот только это было строить на умирающем SAS, почему не U.2?
    взяли не свое железо, поставили не свое ПО, ограничили в бэкапах… я так понимаю снова был общий смысл просто денег сэкономить


    1. JetHabr Автор
      09.11.2018 11:00

      Добрый день! Ответ от вендора:
      В качестве платформы данной версии ПАК используется оборудование Intel, шасси которого укомплектовано дисками SAS SSD. U.2 используется в качестве системного диска.
      На текущий момент перечень поддерживаемых аппаратных платформ и устройств хранения шире. Например, серверные платформы Huawei, Dell, Lenovo. Диски SAS SSD, U.2 SSD и NVMe.


  1. vesper-bot
    08.11.2018 10:36

    Как насчет подобного тестирования этой SharxBase? В первом приближении она обгоняет Nutanix CE в полтора раза по скорости и в 4 раза по IOPS, зато по цене несравнима — Nutanix CE бесплатен, плюс распространяется в виде софта, а не appliance'ов. (Плюс ещё нюанс работы Nutanix CE с дисками NVMe — текущая версия отдает их в виде дисков типа SAS вместо проброса в виде PCIe, что накладывает лишние 2-4 раза потерь, но в тестах могла использоваться предыдущая версия, в которой NVMe работали как устройства PCIe) Возможно, имеет смысл ещё сравнить графики с Storage Spaces Direct — по этим оценкам проигрыш на 4k random write сценарии SharxBase ему составляет десять раз, но есть нюанс — там в тестах сеть 100Гбит/с и куда более мощные процессоры (4х16 против 2х12 здесь), причем их использование достигало огромных 85% во время этого теста.

    Как я понимаю, весь смысл этого ПО — в слове «сертифицировано».


    1. JetHabr Автор
      08.11.2018 17:40

      Спасибо за комментарий!
      На текущем этапе мы не ставили себе задачу сравнивать решение от Sharx с другими существующими платформами. Нас в первую очередь интересовала зрелость данного решения и возможность его применения для ряда задач, требующих гиперконвергентных решений. Тестирования было не про «как сертифицировано?», а про «как работает?».
      Но спасибо за наводку, мы подготовим сравнение различных решений и обязательно его опубликуем.