Привет, Хабр! Меня зовут Михаил Косцов, я руковожу практикой вычислительной инфраструктуры и систем резервного копирования в К2Тех. Сегодня расскажу о результатах тестирования отечественной СХД Аэродиск Engine AQ440. Это одно из российских решений класса midrange, которых сейчас становится все больше на рынке корпоративных систем хранения данных. СХД представлена в реестре Минпромторга, а ее производитель, компания Аэродиск, наверняка знаком многим из вас.

В последние годы на рынке появилось много отечественных решений, которые на бумаге выглядят впечатляюще, но на практике не всегда соответствуют заявленным характеристикам. Особенно это касается сложных систем вроде СХД, где нужно не просто собрать железо, но и создать надежное программное обеспечение. К тому же, метрокластер и репликация — функции высокого уровня, которые даже у зарубежных вендоров порой реализованы не идеально. Однако в случае Аэродиск Engine AQ440 результаты оказались интереснее, чем мы ожидали.

Мы решили проверить, насколько заявленная функциональность системы соответствует реальности, и как она справляется с различными сценариями использования. Честно говоря, начинали тестирование СХД от Аэродиск с небольшим скепсисом.

В этой статье расскажу о впечатлениях от системы, ее архитектуре, функциональности, производительности и отказоустойчивости. Мы протестировали All-Flash-конфигурацию, проверили работу метрокластера (функции, которой пока нет у других отечественных производителей СХД), и создали несколько аварийных ситуаций, чтобы оценить надежность системы.

Готовы узнать, как справляется российское решение с задачами корпоративного хранения данных? Давайте разбираться!

Спецификация оборудования

В этот раз мы тестировали СХД Аэродиск Engine AQ440 — двухконтроллерную систему хранения данных, созданную на аппаратной составляющей компании «Аквариус» и ПО от Аэродиск. Она умеет работать с FC/iSCSI/NFS/SMB-доступом, использует SAS-backend и технологии Thin Provisioning, Compression, Snap/Clone и др.

Краткое описание контроллерного шасси:

4U, 24 x 3.5''/2,5", 4 x CPU 16C/32T 2.10GHz/3.20GHz, 22MB, 512GB DDR4, 4 x 1/10GbE RJ45, 4 x SAS 12Gb, 2 x COM, 2 x VGA, 2 x IPMI, PSU: 1600W 1+1

В тестовой конфигурации стоят 24 SSD-диска по 1,92 ТБ каждый, а за внешние подключения отвечают адаптеры 25Gb Ethernet и FibreChannel 32G. Этот набор говорит сам за себя — явно хотели впечатлить производительностью. Что ж, проверим, насколько хорошо это решение на самом деле подходит для высоконагруженных задач хранения данных.

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

Внешний вид, первый осмотр

СХД занимает 4U в стойке, что для All-flash-системы выглядит несколько громоздко при емкости всего 24 диска. Отсеки СХД предназначены для накопителей формата LFF (3,5"), а SFF-накопители (2,5") устанавливаются туда с помощью специальных салазок. Однако у большого размера есть важное преимущество — возможность установить дополнительные интерфейсные карты с портами, что существенно расширяет варианты подключения к инфраструктуре.

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

СХД от Аэродиска идут только в двухконтроллерном варианте — это типично для систем хранения класса midrange. Согласно спецификации, система может быть оснащена различными процессорами — от 8 до 20 ядер, а если нужно что-то особенное, можно заказать и другие конфиги.

Для увеличения емкости к основному блоку можно подключить дополнительные полки расширения. В максимальной конфигурации система поддерживает до 608 накопителей. В нашей тестовой конфигурации полок расширения не было, но производитель предлагает несколько вариантов:

• 24 диска SAS 2,5″, 2U, 2xБП; 

• 24 диска SAS 2,5/3,5″, 4U, 2xБП; 

• 78 дисков SAS 2,5/3,5″, 4U, 2xБП; 

• 108 дисков SAS 2,5/3,5″, 4U, 2xБП.

Настройка и запуск СХД

ПО Аэродиск ВОСТОК развивается довольно бодро. За два месяца тестирования вышло 3 патча и новое большое обновление прошивки.

Настройка простая и подробно расписана в документации, никаких проблем не возникло. Запустили систему меньше чем за десять минут. Нам всего лишь пришлось подключиться к Ethernet-портам напрямую по SSH, а потом задать новые нужные адреса. Параметры доступа к системе (пароли и заводские IP-адреса) указаны в бумажном паспорте изделия. Вся остальная настройка и управление делается через веб-интерфейс, доступный по адресу любого из контроллеров.

Интерфейсы управления

Web-интерфейс

Интерфейс лаконичный и удобный, хотя до идеала ему немного не хватает единообразия. Где-то используются контекстные меню, где-то нет, причем не всегда понятно, где такая фишка вообще есть. Некоторые полезные разделы запрятаны глубоко внутри свойств объекта.

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

Командная строка (ssh)

При подключении к системе по SSH мы попадаем в оболочку, знакомую по процедуре первоначальной настройки. Здесь доступен скудный набор возможностей: встроенная подсказка выводит 30 команд, включая вызов справки, но ничего реально полезного там нет. Интерфейса командной строки для написания скриптов и автоматизации процессов тоже не завезли.

Техподдержка может подключиться по SSH с привилегированным доступом, получая расширенные права при необходимости (что мы и наблюдали на практике). А вот обычный пользователь не сможет нормально управлять СХД из командной строки — только через веб.

REST API

Для автоматизации здесь предусмотрен другой, более современный интерфейс — REST. По адресу http://<ip_контроллера>/api/docs доступен интерфейс Swagger UI, который описывает доступные REST API с примерами.

Этот интерфейс дает возможность создавать и удалять тома, а также маппить их на серверы. Правда, при тестировании мы обнаружили сбой: в нашей версии том, созданный через REST и подключенный к хосту, отображался в REST-интерфейсе и фактически работал, но в веб-интерфейсе почему-то не отображался. Удалять его пришлось также через REST. Вендор быстро открыл кейс по этому запросу и обещал внести изменения в один из ближайших патчей, если это будет необходимо.

Организация емкости и планирование

Аэродиск позволяет организовать емкость двумя способами:

1. RDG (Raid Distributed Group) — функциональный и универсальный вариант. Он поддерживает создание как блочных, так и файловых ресурсов, работает с дедупликацией и компрессией, а также позволяет создавать гибридные группы из SSD и жестких дисков.

2. DDP v1 (Dynamic Disk Pool) — вариант с меньшим количеством функций, который дает только блочный доступ (iSCSI / FC). Несмотря на меньшие возможности, он рекомендован для получения большей производительности, особенно в All-Flash системах. Если вам нужна скорость и только блочный доступ — берите его.

Выделение ресурсов для RDG, на наш взгляд, гораздо удобнее и проще. Тут можно сразу создавать тонкие тома, врубать дедупликацию и сжатие — в общем, все то, что мы ждем от пула и чего нет для DDP. Важный бонус RDG — возможность создавать файловые системы с доступом по SMB (CIFS), родному протоколу для Windows, и NFS. В DDP такой фишки нет вообще.

Второй тип выделения емкости — DDP — рекомендуют в основном для All-Flash систем. Мы провели эксперимент: взяли 12 дисков емкостью 1,92 ТБ каждый (примерно 1,7 TiB) и создали на этой группе 7 томов RAID0 по 3 TiB. Потом удалили через один 2-й, 4-й и 6-й тома, чтобы проверить, какого размера том мы сможем создать после этого.

Удаление части томов прошло успешно — DDP-пулы хорошо защитили нас от внутренней фрагментации и позволили расширить оставшиеся тома. Однако проявилась важная особенность, связанная с размещением тома: расширить том можно только за счет емкости тех дисков, на которых он изначально расположен. Использовать емкость с других дисков пула, на которых том изначально не размещался, увы, не получится. Это правило работает и для новых дисков, добавленных при расширении DDP-группы — они не дадут расширить уже существующие тома.

В качестве еще одного теста создали тонкое хранилище на 10 дисках в пуле из 24. И вот сюрприз — дальше его нельзя расширить. Для расширения система предлагает только остатки тех самых 10 дисков, на которых хранилище было создано изначально. Другие диски в списке не появляются, хотя в пуле большая часть емкости просто простаивает. И что удивительно — в том же пуле создать еще одно тонкое хранилище тоже нельзя. Пока Аэродиск Engine AQ440 не хватает гибкости в управлении дисковыми ресурсами.

Подключение серверов и балансировка ввода-вывода

С подключением серверов проблем не возникло, в интерфейсе все организовано логично и удобно: для серверов задается маппинг с возможностью ограничить, через какие порты СХД будут доступны тома.

С доступом по iSCSI тоже все хорошо. Единственный минус — за время тестирования так и не смогли настроить работу серверов с СХД по iSER (RDMA-расширение для iSCSI). Пытались разными способами, но так и не добились успеха. Позже производитель сообщил, что в состав нашей системы входили адаптеры без поддержки iSER. Если нужна работа этого протокола – стоит уточнять отдельно.

Мониторинг производительности

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

Хороший плюс системы — возможность интеграции с Grafana. Благодаря этому можно смотреть метрики в любом виде: через штатные панели или создав свои собственные.

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

Маппинг (предоставление тома серверу)

Текущая версия софта поддерживает два режима маппинга: старый и новый (помеченный как экспериментальный). Новый явно удобнее, и честно говоря, зачем вообще нужен старый — загадка. Мы погоняли тестовую нагрузку через vdbench и в один поток получили около 20K IOPS с низким временем отклика на чтение и относительно большим на запись, вероятно из-за фоновых операций инициализации.

При тестировании одиночного тома видно, что multipathing пашет как часы: нагрузка по путям размазывается равномерно. На графике sdc, sdd, sdg и sdh — это нагрузка по отдельным путям, а dm-0 — суммарная по всем каналам.

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

Наш том объемом 10 TiB потребовал 13,4 TiB из доступных 21,0 TiB, что дает эффективность использования емкости 75% для уровня 6+2. Все в рамках ожиданий, иные результаты были бы сюрпризом.

Локальная репликация (мгновенные снимки, клоны)

СХД предлагает два типа локальных реплик: мгновенные снимки (снэпшоты) и полные копии на заданный момент времени (снэпклоны).

Функций локальной репликации довольно много, но есть один нюанс — они работают и ведут себя немного по-разному в зависимости от типа конфигурации (RDG, DDP thick или DDP thin). Это заметно усложняет понимание того, что вообще происходит в системе. Приходится каждый раз вспоминать, какой у тебя тип пула и что с ним можно делать.

Удаленная репликация

Удаленная репликация работает в Аэродиск Engine AQ440 только поверх IP-протокола — поддержки Fibre Channel нет. Доступны как синхронный, так и асинхронный режимы.

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

Метрокластер — работа и сценарии отказа: первые заметные проблемы

Метрокластер — это уникальная фича данного продукта, которой нет у большинства отечественных аналогов. Среди азиатских решений на ум приходит СХД китайского вендора Maipu с поддержкой репликации в режиме active-active метрокластера. По сути, это технология, обеспечивающая катастрофоустойчивое развертывание СХД за счет географически разнесенного резервирования.

При сбое на одной из площадок метрокластер в СХД Аэродиска автоматом переключает синхронную репликацию с применением внешнего арбитра. Арбитр работает как виртуалка, размещенная в отдельном домене отказа. Режим метрокластера сам обрабатывает отказы СХД и делает реплицируемые ресурсы хранения доступными по iSCSI.

Метрокластер настраивается в дополнение к синхронной репликации. Суть настройки — предоставление томов через одинаковый VIP (Virtual IP Address) как target на двух СХД и подключение к арбитру. Работает это только для iSCSI, поскольку процесс идет через переключение IP-адресов таргетов между СХД. Настройка требует кучи шагов, но в доках все расписано подробно и четко, так что никаких проблем у нас не возникло.

Важный момент: подключать репликацию к метрокластеру, похоже, нужно с контроллера, на котором сидит VIP. Иначе операция просто не проходит — в первый раз мы на этом споткнулись.

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

Мы проверили кучу разных сценариев: отказ арбитра, отказ порта управления Primary Engine, недоступность Primary Engine, отказ репликационного линка, отказ портов данных и управления на Primary, а также полный крах системы. Системный журнал в этих случаях забивается тоннами сообщений об ssh-коммуникациях. Для диагностики это полезно, но серьезно мешает отслеживать другие важные события — приходится разгребать гору логов.

Серьезную проблему нашли при отказе портов данных на Primary — переключения не происходит, что приводит к недоступности данных. Производитель работает над решением данной проблемы. Если вам нужна защита от такого сценария, можно запросить у производителя возможность применения специальных настроек (например, перенос отслеживаемых интерфейсов на интерфейсы данных). Такие решения есть, но пока не стандартные, из коробки не доступны и в доках не описаны.

Аналогичные вопросы вызвал сценарий отказа всех портов управления на Primary (сценарий отказа коммутатора управления). В данном случае данные становятся временно недоступны. Производитель также работает над устранением проблемы. 

Отказоустойчивость, проверка сценариев сбоев

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

Отечественная СХД показала себя на уровне зарубежных аналогов. При отключении всех FC-путей одного контроллера система правильно переключила дисковую группу на другой контроллер (аналогичный сценарий сбоя при работе в режиме метрокластера вызывал вопросы). Сбои в подсистеме питания вообще никак не повлияли на производительность — выдернули один кабель или блок питания, график нагрузки даже не дрогнул, что и ожидалось.

Единственный недостаток — не очень информативная индикация неработающего компонента в интерфейсе. Проблемный элемент никак не выделяется. Рядом с ним просто пропадает зеленая метка. Было бы намного удобнее, если бы сломанный компонент как-то подсвечивался красным или выдавал явное предупреждение.

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

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

Осторожно, большие таблицы:

Выводы по результатам тестирования

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

Преимущества системы:

• высокая производительность (более 1 млн IOPS при условии использования достаточного числа серверов и портов);

• высокая функциональность по сравнению с другими отечественными СХД;

• удобный интерфейс управления и качественная документация;

• активное развитие и обновление;

• готовность производителя к взаимодействию и поддержке;

• поддержка и файлового, и блочного доступа.

Недостатки системы:

• закрытые внутренние механизмы и сервисные доступы, траблшутинг СХД невозможен без привлечения производителя;

• неполная реализация некоторых заявленных функций;

• нестандартная реализация некоторых функций по сравнению с решениями других производителей.

По результатам тестов и полученной информации мы оценили СХД по ряду критериев и пришли к следующим оценкам по десятибалльной шкале (где 10 - идеально/великолепно - недостижимый идеал).

Подводя итоги тестирования СХД Аэродиск Engine AQ440, можно сказать, что система оставила позитивные впечатления. Это универсальная СХД midrange-класса с хорошей функциональностью, большая часть которой удачно реализована и работает стабильно. Однако учитывая быстрые темпы развития продукта, рекомендуем тесно сотрудничать со специалистами производителя при внедрении и дополнительно тестировать новые функции в вашей конкретной инфраструктуре. Доверяй, но проверяй, как говорится.