Сегодня я расскажу о гиперконвергентной платформе SharxBase. На Хабре еще не было обзора этого комплекса, и с этой несправедливостью было решено покончить. Нашей команде удалось протестировать решение «в бою», о результатах — ниже.
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-консоли.
Схема типового блока (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.
Функциональные возможности
При расширении портфолио гиперконвергентных решений мы провели совместно с вендором тесты на производительность и отказоустойчивость.
Тестирование производительности
Стенд тестирования представлял собой 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. Схема подключения приведена на рисунке.
Схема подключения серверов на тестовом стенде
Все функциональные возможности, описанные ранее, нашли своё подтверждение в результате проведенных функциональных тестов.
Тестирование дисковой подсистемы осуществлялось при помощи ПО 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.
Результаты тестирования данных типов представлены в таблице:
Хранилище обеспечивает особо высокие показатели производительности на последовательных операциях чтения и записи 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
