Aerodisk в быту

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

СХД планировалось использовать под бэкапы. Требовалось по iSCSI, быстренько принять потоковую запись, аккуратно ее разложить на диски с некоей отказоустойчивостью, время от времени реплицировать данные куда-нить, ну и в случае чего вернуть данные при восстановлении из бэкапа. Если еще и дедуплицировать данные, то будет вообще хорошо. Функционал дедупликации и репликации покупается отдельно, учитывайте это при заказе. Кроме лицензионного ограничения есть ограничения по мощности. Для дедупа, сжатия и прочего требуется более мощный процессор чем идет в базе. Учитывайте что Dedup и compress идет в inline режиме.

Начало

Предпродажная подготовка у Аэродиска отличная. Перед покупкой все что могут расскажут, объяснят, помогут подобрать нужное решение. И это отлично, другие вендоры отдают эти вопросы на откуп ритейлерам или дистрибам, а у тех не всегда есть специалисты готовые грамотно составить ТЗ и тем более внятно ответить на вопросы по конкретному продукту. Надо отметить что инженеры Аэродиска достаточно честно говорят что может и чего не может их продукт. Говорить могут и на техническом языке и объяснить на пальцах. В ходе переговоров вы получаете больше информации о вашей будущей СХД и ожидания потом меньше расходятся с реальностью.

Hardware

По итогам согласований в руки попала модель Engine N2, с одним установленным контроллером. У Аэродиска есть деление Engine N1 одноконтроллерные шасси для простых СХД и Engine N2 для двуконтроллерных. Софт одинаковый, но у N1 понятно больше физических ограничений. Анбоксинга тоже не будет. Шасси от малоизвестного производителя, отличительной чертой является интегрированный BBU в блоки питания.

  • 24 bays 3.5′
  • 2 psu (BBU)
  • 4 U
  • 2 controller slots
  • все hot swap
Видно PSU, контроллер, все hotswap.

По поводу интегрированного в блоки питания батарейного блока. Взять ситуацию с обычными серверами. Если использовать аппаратный серверный raid в качестве DAS, то BBU очень помогает в работе кэша. Можно использовать кэш на запись и не переживать за сохранность данных, даже при потере питания контроллер их все равно сбросит на диски когда подадут питание. Разница в скорости работы дисковой подсистемы с кэшем и без просто огромна. Для современных СХД можно использовать либо NVDIMM либо батарейки в блоках питания. Аэродиск пошел интересным путем интеграции BBU в PSU. Eсли питание погаснет, СХД все равно успеет скинуть кэш на диски. Понятно что у всех есть внешний ИБП, который по идее должен дать время на штатное завершение работы всех сервисов, но от ошибок никто не застрахован и применение дополнительной защиты в таком важном деле как хранение данных это жирный плюс. Вопрос в возможных сроках эксплуатации. В современных аппаратных raid контроллерах используют конденсаторы + флеш, а не батарейки. Батарейки очень подвержены старению, через 2-3 года толку от них ноль. Что будет через 2-3 года с батарейками в СХД Аэродиск, неизвестно. Останется только уповать на то что они все еще работают. Хотя лучше чем вообще ничего. Возможно по этой причине большинство производителей СХД не используют такое решение с BBU, но NVDIMM стоит значительных денег.

Software

Привязки к конкретной железке у компании Аэродиск нет, они могут завтра выпустить решение на другом шасси, или вообще в виде виртуальном (vAir). Ведь это Software Defined Storage, главное это софт. Судя по тому что я понял используется допиленная ZFS, может еще что-то, обернутое в красивую Web-GUI. В софте, как и у других СХД, у вендора есть две противоположные задачи:

  • дать пользователю гибкое, настраиваемое решение
  • не дать пользователю выстрелить себе в ногу

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

СХД смонтировали, запустили, зашли в веб. Все быстро, отвлекаться на изучение мануалов некогда. Нужно сменить IP. Ok, сменили. Но сменить шлюз мы не можем, нельзя. Просто поля нет. Решение саппорта: использовать для настройки SSH.

Ок, мы не гордые. Но что-то странное в этом есть.

где-то тут должен быть gateway… ну должен же?

Идем дальше. Нужно создать массив и выдать его LUN’ом наружу. В качестве механизма создания массива нам предлагается 2 варианта:

  • Dynamic Disk Group (DDG). Диски нарезаются на chunks и выдаются в нужной вам форме. Можно сделать R10 для быстрой записи/чтения, а потом на этих же физических дисках сделать R5 для большей емкости. Такой функционал обычно присутствует у вендоров в моделях постарше и обычно говорит о том что СХД не entry level.
  • Raid Disk Group (RDG). Здесь все проще, аналог обычного raid. Берем диски, делаем R5, ну или R6. Ключевое здесь «или». Использовать диски просто как емкость и одновременно по разному разбивать одну и ту же группу дисков нельзя.

Что там под капотом в это время происходит не сильно интересует, главное чтобы работало. У Аэродиска достаточно хорошо описаны отличия DDG от RDG, здесь останавливаться не буду. В мануале указано что DDP рекомендуется для Full flash или ssd cached групп. А для обычных используйте RDG. Хотя DDG конечно более гибкий вариант и все уже как-то привыкли к гибкости SDS. У тех поддержки запросили какой вариант нам больше подходит, на всякий случай. Был рекомендован RDG. Ну чисто для сравнения создаем по очереди разные варианты. По факту получается что на DDG R10 сформированный LUN достаточно шустрый и по iops и по пропускной способности, а вот RDG просто не удается отформатировать. Форматирование 20 Tb LUN’а в файловую систему NTFS/REFS занимает больше часа, терпения не хватает. Обращаемся в тех саппорт — мол медленно очень форматируется логический том, что-то не так. Получаем ответ:

Это особенность файловой системы, идёт медленный формат если используются SAS-NL диски.

Вероятно намекали что нужно смотреть что покупаешь. Ну или не знаю что еще. Ок, ждем пока процесс форматирования закончится. Вдруг после особенного форматирования все взлетит? С утра тестируем раздел, не взлетело. Потоковая запись на:

  • DDG R10 2-4 Гбит/сек
  • RDG R10 0.1-0.3 Мбит/сек

Время на тестирование и решение проблем с вводом в эксплуатацию истекло, нужно запускать. DDG не рекомендован, но ведь работает! Ясно что дело в каких-то особенностях кеширования, т.к. RDG не потреблял кэша, а DDG потреблял. Значит запускаем DDG. Поначалу все ок, бэкапы заливаются и при этом target редко оказывается самым узким местом в системе, все довольны.

Все довольны. Почти…

Разница между R10 и R50 все же должна быть, и почему бы не сделать емкий медленный раздел для того что и так копируется медленно и быстрый раздел для того что нужно быстро скопировать? У нас же DDG, нужно пользоваться возможностями. Так и делается. Запускаются бэкапы, все идет отлично, можно спать спокойно.

С утра оказывается что не все так отлично, через 3 часа заливки на R50 СХД встала намертво, после ребута пропали дисковые группы со всеми данными. «Усе пропало шеу». Будь там критичные данные, это был бы дизастер. Причем на R10 те же данные ранее скопировались нормально, ничего не предвещало беды.

Техсапорт предложил не использовать DDG на медленных NL SAS дисках. Т.к. при переполнении кэшей система просто наглухо виснет с потерей данных. RDG говорят быстрее в вашем случае будет. Предлагают помощь в правильной настройке RDG. Ok, принимаем помощь. Может мануал плохо прочитали, может не обратили внимания на какой-нибудь ньюанс. Саппорт создает RDG, создает раздел, прикидывает LUN, запускаем форматирование и результат тот же. Медленное форматирование, видно что будет идти и идти и идти. Саппорт волшебными командами в ssh меняет настройки, все летает. Вновь созданный логический том прекрасно себя показывает при тестировании. Обещают что все будет отлично, на том и расходимся.

Полученный том не устраивает, нужно создать новый логический диск и новый том. Создаем уже сами, без саппорта, но скорость опять 100-300 мбит/сек!

Саппорт говорит: «В имеющей версии ПО оптимизация скорости луна только с помощью подключения специалистов тех поддержки.»

Нельзя так просто взять

и создать LUN

Нужно в тех поддержку обращаться каждый раз чтобы LUN создать!

Причем выясняется это не при первых обращениях, а после длительной переписки. Возвращаясь к вопросу о гибкости настроек и возможности выстрелить в себя, Аэродиск показывает себя не с лучшей стороны. Обещают в следующем релизе ПО исправиться. Но КАК, КАК можно такое продавать?

Из минусов хотелось бы в целом отметить:

  • отсутствие совместимости с SMI-S, не ждите что System Center увидит СХД и начнет нарезать на ней LUN’s.
  • Dedup только в inline режиме и даже его саппорт не предлагает использовать, думаю из соображений осторожности. И предлагает задействовать тот что в Veeam. Не ждите что Aerodisk заменит StoreOnce или DataDomain.
  • Непонятно что будет если на DDG с SSD cache вдруг пойдет ребилд нескольких дисков, могу предположить что повторится наша ситуация с потерей данных.
  • Невозможность самостоятельной настройки СХД, вам придется настраивать силами саппорта.
  • Многие простые вещи придется делать через SSH. Многим будет проще самим собрать box, накатить ZFS и ковырять его самостоятельно.

Читайте также:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Bitnami