Мы продолжаем вас знакомить с российскими системами хранения данных AERODISK ENGINE N-серии. Предыдущая – вводная – статья находится здесь. Также у ребят появился свой YouTube канал с обучающими видео по настройке и работе с системой. А еще перед новым годом Аэродиск запустил промо-программу, в рамках которой можно купить СХД со скидкой до 60%! Предложение, на наш взгляд, отличное.

В этот раз Аэродиск нам предоставил систему хранения ENGINE N2 в All-flash конфигурации для самостоятельного изучения и настройки, и мы поделимся этим опытом.
В рамках знакомства с ENGINE мы сделаем цикл из 3-х статей:

1. Базовая настройка
2. Краш тесты
3. Нагрузочные тесты

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

Итак, что мы имеем:

• Двухконтроллерная СХД AERODISK ENGINE N2 с адаптерами FC-8G и Ethernet 10G
• 16 SSD-дисков
• 8 HDD дисков
• Физический сервер с Виндой 2012, который подключен через SAN-коммутаторы (FC и Ethernet) к СХД
• Рабочая документация к СХД, а также светлые головы и прямые руки наших инженеров.

Резонный вопрос, зачем тут HDD диски, ведь нынче в тренде All-Flash? Дело в том, что задачи под гибридное хранилище (SSD+HDD) как возникали, так и продолжают возникать, поэтому мы попросили Аэродиск добавить в олфлэш-хранилку минимальное количество HDD дисков, чтобы проверить функционал гибридных групп. Сейчас мы будем настраивать СХД, а в следующей статье сделаем большой тест производительности.

Распаковка

В руках у нас оказалась вот эта коробка. Как говорит производитель, в ней 40 ТБ с производительностью 300 000 IOPS. Звучит интригующе, будем проверять.



Распаковываем и видим следующее:



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



Спереди видим слоты под 24 диска, сзади – модульные контроллеры и блоки питания. На контроллерах установлены FC-порты, Ethernet-порты (обычный RJ-45 и 10 гигабитный на оптике), а также SAS-порты для подключения дисковых полок. То, что все типы популярных портов ввода-вывода есть в одной коробке – несомненный плюс. Все задублировано, значит, может меняться на горячую, и поэтому с работой в режиме нон-стоп проблем, по идее, быть не должно. Но мы проверим.





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

Монтируем СХД в стойку, подключаем к серверу через коммутаторы (и FC, и Ethernet), включаем СХД и начинаем настройку. Подключение можем осуществить через командную строку по SSH или Web. С командной строкой будем разбираться позже, сразу идем в веб-интерфейс:



На дашборде видим общую текущую нагрузку на два контроллера, состояние кластера и сенсоров. Слева – основное меню, справа вверху – логон меню, там же задаем время и меняем пароль. Слева вверху – полезная информационная панель, на которой отображаются статусы «здоровья» различных компонентов СХД. Если что-то не так, можно сразу щёлкнуть по проблеме, и система сама отправит тебя в нужное меню. Снизу лог, в котором отображаются последние операции.
В целом, все удобно и логично. Переходим к настройке СХД.

Настраиваем группы хранения

По документации ENGINE может отдаваться наружу по следующим протоколам:

• FC и iSCSI (блочка)
• NFSv4 и SMBv3 (файлы)

Есть, конечно, ещё FTP и AFP, но это уже, на наш взгляд, экзотика, и в рамках этой статьи это рассмотрено не будет (но если очень надо, пишите, попробуем, расскажем).

Имеем два типа дисковых групп: RDG, который умеет отдавать блочку и файлы и DDP, который умеет отдавать только блочку (и специально заточен под неё). В прошлой нашей статье про Аэродиск было приведено подробное описание и сценарии применения RDG и DDP. Поскольку RDG больше нашпигован полезными функциями, будем настраивать его. К DDP мы вернемся в следующей статье, когда надо будет тестировать различные сценарии производительности.

Создаем группу хранения RDG

Делаем гибридную группу из 4-х SSD дисков (2 под кэш, 2 под тиринг с уровнем RAID-10 и 7 HDD дисков уровнем RAID-6P (тройная четность). В итоге получаем быстрый «верхний» уровень на SSD и медленный, но очень надежный «нижний» уровень из HDD.

Процесс создания группы вопросов у нас не вызвал, состоит из двух этапов, в начале создается основной «нижний», а потом на него накидываются «верхние» уровни. По ходу создания можно включить дедупликацию и компрессию (включаем). Также нас сразу предупреждают о том, сколько дисков автозамены у нас останется для нештатных ситуаций. Один диск оставляем для автозамены, чтобы протестировать этот механизм.



После создания видим «скелет» нашей рэйд-группы. Выглядит наглядно и удобно:



Также после создания группы можно добавить дисков на любой из уровней в специальном меню:



Группа создана. В свойствах самой группы есть вкладки с LUN-ами и шарами:



Оттуда же пошли создавать LUN. В процессе создания LUN-а нам предлагают различные опции. Из явно полезных отметим возможность создания «тонкого» LUN-а, свой размер блока на конкретный LUN (очень полезно для различных типов нагрузки) и возможность отдельно на каждый LUN включить или выключить дедупликацию и компрессию. Делаем «тонкий» LUN с дедупом и компрессией. LUN создан:



С созданным LUN-ом можно делать много разных операций. После того, как LUN отдадим серверу, мы их проверим.



Теперь создаем файловые ресурсы. Процесс создания NFS и SMB мало чем отличается от создания LUN-а, также можно выбрать индивидуальный блок, «тонкость» или «толстость», но есть и отличие. Задать индивидуальное включение дедупликации и компрессии на файловый ресурс нельзя, то есть настройка будет браться с родительского объекта. Таким образом если хотим, чтобы на файловые шары работала дедупликация и компрессия это нужно включать на уровне RDG. В принципе это ОК, но менее гибко, чем с LUN-ами.

Также отдельная тема — это настройка доступа к файловым ресурсам. Для NFS предусмотрено разграничение доступа (на чтение и/или запись) по IP-адресам и/или пользователям.



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



Итак, создали два файловых ресурса: NFS и SMB.





После создания смотрим, какие операции мы можем выполнить. В принципе, все то же самое, что и с LUN-ами: изменение размеров, снэпшоты, тип доступа и т.д. Теперь задача отдать эти созданные ресурсы хосту.

Начнем с LUN-а

LUN мы можем отдать по iSCSI и/или FC. Это не опечатка, судя по документации Аэродиска, действительно, есть возможность отдать один LUN одновременно и по FC, и iSCSI. Зачем это нужно не очень понятно, но вендор говорит, что эта функция может пригодиться для диагностики. Ну, допустим, так. В любом случае мы будем делать «по-старинке» и один LUN отдадим по FC, а другой по iSCSI. Чтобы заново ничего не создавать, сделаем клон существующего LUNа.
Описывать процесс настройки SAN-коммутаторов мы не будем, он не отличается от настройки для других СХД. Отметим, что на портале поддержки Аэродиска в базе знаний есть примеры настройки различных вариантов SAN-коммутаторов, что, безусловно, плюс в карму вендора.

Делаем маппинг LUN-а по FC

Идем в инициаторы, видим, что с хоста прилетели WWN-ы инициаторов. Создаем таргет на СХД, связываем таргеты и инициаторы в группу устройств.



Выбираем нужный LUN и делаем маппинг через созданную группу устройств.



В приложении руководства администратора есть отдельный гайд, как правильно презентовать ресурсы СХД по каждому из протоколов с настройками для популярных ОС. Презентация LUN-а по FC особых вопросов не вызвала. В ОС CentOS предварительно должен быть установлен пакет device-mapper-multipath. Хост-сервер в итоге увидел блочное устройство, понял, что это AERODISK.



Кстати, в процессе маппинга обнаружили полезную вещь. Можно задать руками LUN ID. По умолчанию этот ID присваивается по порядку автоматически, но иногда возникают ситуации, когда его надо указывать руками. Например, для SAN boot (загрузка ОС с LUN-а СХД), а также в больших ЦОД-ах, где много разных СХД, а ещё больше LUN-ов с них. Там LUN ID служит для корректного учета и быстрого поиска. На наш взгляд функция – мастхэв и мастюз.

Теперь проверяем – видим, что LUN доступен с двух активных контроллеров (второй как неоптимальный путь – классическая ALUA).



Форматируем LUN в NTFS получаем диск «D».

Переходим к iSCSI

Создаем еще один LUN на той же дисковой группе. С презентацией по iSCSI пришлось потрудиться. Дело в том, что для iSCSI, кроме таргета, инициатора и их связи есть ещё одна дополнительная сущность — HA-ресурс. HA-ресурс — это виртуальный интерфейс, на который вешается виртуальный IP (VIP), который смотрит одновременно на два (или более) физических Ethernet-интерфейса на двух разных контроллерах и служит для отказоустойчивости. Схематично это выглядит так:



HA-ресурс привязывается к конкретной RDG. На туже группу можно привязать еще один HA-ресурс и отдать с него VIP в другую подсеть (может в жизни пригодиться).

В итоге разобрались. Создали HA-ресурс, поставили iSCSI-инициатор в винду, скопировали имя инициатора (IQN) винды. Далее создали iSCSI-таргет на СХД и связали таргет с инициатором.



Подключили LUN в винду. Отформатировали, создали диск D.

Подключаем файловые ресурсы

Этот процесс максимально простой, что с SMB, что с NFS. Единственный момент, на Windows нужно поставить штатный NFS-клиент. Все эти нюансы описаны в документации. Файловый доступ также требует HA-ресурс. Мы его создали на предыдущем шаге, поэтому будем использовать тот же.
Обе наши файловые шары подключаем с в Windows с помощью сетевого диска, соответственно, G и E.

Заключение

На этом можно сказать, что базовая настройка СХД выполнена, дальше уже пойдут тесты на надежность СХД. Если взять общее время, которое мы затратили на базовую настройку, периодически подглядывая в документацию, то получилось примерно минут 30-35, 10 из которых провозились с iSCSI. По нашему опыту это очень даже недолго (на некоторых СХД именитых вендоров аналогичные операции занимали несколько часов), поэтому можно сказать, что система достаточно проста в освоении, логична и удобная для администратора.