Тестируем SharxBase, программно-аппаратную платформу виртуализации от российского вендора SharxDC

в 13:26, , рубрики: SharxBase, SharxDC, Блог компании Инфосистемы Джет, виртуализация, гиперконвергентные платформы, дата-центр, СХД, тестирование, хранение данных, цод

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

image

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

О продукте

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

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

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

Для организации распределенного отказоустойчивого хранилища используются flash-накопители (SSD и/или NVMe). В качестве среды передачи данных используется Ethernet. Для передачи трафика СХД требуется использовать выделенные сетевые интерфейсы — не менее двух интерфейсов 25 GbE. Службы, обеспечивающие работу распределенного хранилища, выполняются на каждом сервере, входящем в кластер, и используют часть его вычислительных ресурсов. Объем ресурсов зависит от количества и объема установленных накопителей, в среднем накладные расходы составляют 34 ГБ ОЗУ на хост. Подключение к распределенному хранилищу происходит через протокол блочного доступа iSCS. Для обеспечения отказоустойчивости поддерживается двух- или трехкратное резервирование данных. Для продуктивных инсталляций производитель рекомендует использовать трехкратное резервирование. На текущий момент из технологий оптимизации хранения поддерживается только тонкое выделение дискового пространства (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: создание виртуального маршрутизатора для передачи трафика между виртуальными сетями. Создание групп безопасности (Security Groups) на встроенном в гипервизор МСЭ, которые ограничивают трафик от/к ВМ.

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

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

Мониторинг

Мониторинг 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 и инфраструктурные сервисы.

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

Автор: JetHabr

Источник

* - обязательные к заполнению поля