Всем привет! Этой статьей компания AERODISK открывает блог на Хабре. Ура, товарищи!

В предыдущих статьях на Хабре были рассмотрены вопросы об архитектуре и базовой настройке СХД. В этой статье мы рассмотрим вопрос, который ранее не был освещен, но его часто задавали – об отказоустойчивости СХД AERODISK ENGINE. Наша команда будет делать все, чтобы СХД AERODISK перестала работать, т.е. ломать её.

Так получилось, что статьи об истории нашей компании, о наших продуктах, а также пример успешного внедрения уже висят на Хабре, за что огромное спасибо нашим партнерам — компаниям TS Solution и Softline.

Поэтому я не буду тут тренировать навыки copy-paste management-а, а просто дам ссылки на оригиналы этих статей:

• Статья №1. Об истории компании и архитектуре системы хранения AERODISK ENGINE
• Статья №2. О том, как быстро настроить СХД AERODISK ENGINE
• Статья №3. Интересный проект о внедрении большого видеонаблюдения под ЧМ по футболу 2018 в рамках проекта Безопасный город

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

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

В каждом Центре компетенции мы установим полноценный демо-стенд из системы хранения AERODISK и физического сервера, на котором нашим преподавателем будет проводиться очное обучение. Расписание работы Центров компетенции будем публиковать по факту их появления, но уже сейчас мы открыли центр в Нижнем Новгороде и на очереди город Краснодар. Записаться на обучение можно по ссылкам ниже. Привожу известную на данный момент информацию о городах и датах:

• Нижний Новгород (УЖЕ РАБОТАЕТ – записаться можно тут https://aerodisk.promo/nn/);
  до 16 апреля 2019 года можно посетить центр в любое рабочее время, а 16-ого апреля 2019 года будет организован большой обучающий курс.
• Краснодар (СКОРО ОТКРЫТИЕ – записаться можно тут https://aerodisk.promo/krsnd/ );
  С 9 по 25 апреля 2019 года можно посетить центр в любое рабочее время, а 25-ого апреля 2019 года будет организован большой обучающий курс.
• Екатеринбург (СКОРО ОТКРЫТИЕ, следите за информацией на нашем сайте или на Хабре);
  май-июнь 2019 года.
• Новосибирск (следите за информацией на нашем сайте или на Хабре);
  октябрь 2019 года.
• Красноярск (следите за информацией на нашем сайте или на Хабре);
  ноябрь 2019 года.

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

Все. С маркетингом завязали, переходим к технике!

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

Краш-тесты СХД AERODISK ENGINE N2, проверка на прочность

ACHTUNG! Прочитав статью, вы можете сказать: ну, конечно же, вендор сам себя проверит так, чтобы все отработало «на ура», тепличные условия и т.п. Отвечу: ничего подобного! В отличие от наших зарубежных конкурентов мы находимся здесь, близко к вам, и к нам всегда можно прийти (в Москву или любой ЦК) и протестировать нашу СХД любым способом. Таким образом, подгонять результаты под идеальную картину мира нам особого смысла нет, т.к. нас очень легко проверить. Для тех кому лень ходить у кого нет времени, можем организовать удаленное тестирование. Специальная лаба у нас для этого есть. Обращайтесь.

ACHTUNG-2! Данный тест не носит характер нагрузочного, т.к. тут нас волнует только отказоустойчивость. Через пару недель мы подготовим более мощный стенд и проведем нагрузочное тестирование СХД, опубликовав результаты тут (кстати, пожелания к тестам принимаются).

Итак, поехали ломать.

Тестовый стенд

Наш стенд состоит из следующего железа:

• 1 x СХД Aerodisk Engine N2 (2 контроллера, 64ГБ кэш, 8xFC портов 8Гб/с, 4xEthernet порта 10Гб/с SFP+, 4xEthernet порта 1Гб/с); в СХД установлены следующие диски:
• 4 x SAS SSD диска 900 GB;
• 12 x SAS 10k дисков 1,2 TB;
• 1 x Физический сервер с Windows Server 2016 (2xXeon E5 2667 v3, 96ГБ RAM, 2xFC порта 8Гб/с, 2xEthernet порта 10Гб/с SFP+);
• 2 x SAN 8G коммутатора;
• 2 x LAN 10G коммутатора;

Мы подключили сервер к СХД через коммутаторы и по FC, и по Ethernet 10G. Схема стенда ниже.

На Windows Server установлены необходимые нам компоненты, такие как MPIO и iSCSI initiator.
На FC коммутаторах настроены зоны, на LAN коммутаторах настроены соответствующие VLAN-ы и установлен MTU 9000 на портах СХД, коммутаторах и хосте (как всё это делать – описано в нашей документации, поэтому тут этот процесс расписывать не будем).

Методика тестирования

План краш-тестов такой:

• Проверка отказа FC и Ethernet портов.
• Проверка отказа питания.
• Проверка отказа контроллера.
• Проверка отказа диска в группе/пуле.

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

Конфиг IOmeter следующий:

• Чтение/Запись – 70/30
• Блок – 128k (решили мочить СХД большими блоками)
• Количество потоков – 128 (что очень похоже на продуктивную нагрузку)
• Full Random
• Количество Worker-ов – 4 (2 для FC, 2 для iSCSI)

1. Убедиться, что синтетическая нагрузка и процесс копирования не прервутся и не вызовут ошибок при различных вариантах отказа.
2. Убедиться, что процесс переключения портов, контроллеров и пр. в достаточной степени автоматизирован и не требует действий администратора при отказах (то есть при failover-ах, о failback-ах речь, понятно, не идет).
3. Убедиться в корректности отображения информации в логах.

Подготовка хоста и СХД

На СХД мы настроили блочный доступ с использованием портов FC и Ethernet (FC и iSCSI, соответственно). Как это делать, ребята из TS Solution подробно описали в предыдущей статье (https://habr.com/ru/company/tssolution/blog/432876/). Ну и, конечно, мануалы и курсы никто не отменял.

Мы настроили гибридную группу, использовав все имеющиеся у нас диски. 2 ССД диска добавлены в кэш, 2 ССД диска добавлены как дополнительный уровень хранения (Online-tier). 12 SAS10k дисков мы сгруппировали в RAID-60P (тройная четность), для того, чтобы проверить выход из строя сразу трех дисков в группе. Один диск оставили для автозамены.

Подключили два LUN-а (один по FC, один по iSCSI).

Владельцем обоих LUN-ов является контроллер Engine-0

Начинаем тест

Включаем IOMETER с конфигом выше.

Фиксируем пропускную способность 1.8 ГБ/с и задержки 3 миллисекунды. Ошибок (Total Error Count) нет.

В это же время с локального диска "C" нашего хоста параллельно запускаем копирование двух больших файлов по 100GB на FC и iSCSI LUN-ы СХД (диски E и G в винде), задействовав другие интерфейсы.

Вверху процесс копирования на LUN FC, внизу на iSCSI.

Тест № 1. Отключение портов ввода-вывода

Подходим к СХД сзади))) и легким движением руки выдергиваем все FC и Ethernet 10G кабели из контроллера Engine-0. Как будто уборщица со шваброй прошла мимо и решила помыть пол как раз там, где валялись сопли лежали кабели (т.е. контроллер остается работать, но порты ввода-вывода умерли).

Смотрим на IOMETER и копирование файлов. Пропускная способность упала до 0,5 ГБ/с, но довольно быстро вернулась на прежний уровень (примерно за 4-5 секунд). Ошибок нет.

Копирование файлов не остановилось, просадка в скорости есть, но совсем некритична (с 840 МБ/с упала до 720 МБ/с). Копирование не остановилось.

Смотрим в логи СХД и видим сообщение о недоступности портов и автоматическом переезде группы.

Также информационная панель нам подсказывает, что не очень все хорошо с портами FC.

Отказ портов ввода-вывода СХД пережила успешно.

Тест № 2. Отключение контроллера СХД

Почти сразу (предварительно воткнув обратно кабели обратно в СХД) мы решили добить СХД, выдернув контроллер из шасси.

Опять подходим к СХД сзади (нам понравилось))) и на этот раз выдергиваем контроллер Engine-1, который в этот момент является владельцем RDG (на который переехала группа).

Ситуация в IOmeter следующая. Ввод вывод остановился примерно на 5 секунд. Ошибки не копятся.

После 5 секунд ввод-вывод возобновился, примерно с теми же показателями пропускной способности, но с задержками в 35 миллисекунд (задержки исправились примерно через пару минут). Как видно из скриншотов, значение Total error count – 0, то есть ошибок записи или чтения не было.

Смотрим на копирование наших файлов. Как видно, оно не прервалось, была небольшая просадка производительности, но в целом все вернулось на те же ~ 800 МБ/с.

Идем на СХД и видим там ругань в информационной панели о том, что контроллер Engine-1 недоступен (конечно, мы же его грохнули).

Также видим аналогичную запись в логах.

Отказ контроллера СХД пережила также успешно.

Тест № 3. Отключение блока питания.

Копирование файлов мы на всякий случай запустили заново, а IOMETER не останавливали.
Дергаем БП-шник.

На СХД добавился еще один алерт в информационной панели.

Также в меню сенсоров видим, что сенсоры, связанные с выдернутым блоком питания, покраснели.

СХД продолжает работать. Отказ БП-шника никак не влияет на работу СХД, с точки зрения хоста скорость копирования и показатели IOMETER-а остались без изменений.

Тест на отказ питания пройден успешно.

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

Тест № 4. Отказ трёх дисков в группе

Перед этим тестом мы выполнили дополнительный подготовительный шаг. Дело в том, что в СХД ENGINE предусмотрена очень полезная штука — разные политики ребилда (перестроения). Ранее TS Solution писал об этой фиче, но напомним её суть. Администратор СХД может указать приоритет выделения ресурсов при перестроении. Либо в сторону производительности ввода-вывода, то есть дольше ребилд, но нет просадки производительности. Либо в сторону скорости ребилда, но производительность будет снижена. Либо сбалансированный вариант. Поскольку производительность СХД во время ребилда дисковой группы – это всегда головная боль админа, мы будем тестировать политику с уклоном в сторону производительности ввода-вывода и в ущерб скорости ребилда.

Теперь проверим отказ дисков. Также включаем запись на LUN-ы (файлы и IOMETER). Поскольку у нас группа с тройной четностью (RAID-60P), значит, система должна выдержать отказ трех дисков, а после отказа должна сработать автозамена, один диск должен встать в RDG на место одного из отказавших, и на него должен начаться ребилд.

Начинаем. Для начала через интерфейс СХД подсветим диски, которые хотим выдернуть (чтобы не промахнуться и не дернуть диск автозамены).

Проверяем индикацию на железе. Все ОК, видим подсвеченные три диска.

И выдергиваем эти три диска.

Смотрим что на хосте. А там… ничего особенного не произошло.

Показатели копирования (они выше, чем в начале, т.к. прогрелся кэш) и IOMETER-а при выдергивании дисков и старте ребилда сильно не меняются (в пределах 5-10%).

Смотрим, что на СХД.

В статусе группы видим, что пошел процесс перестроения и он близок к завершению.

В скелете RDG видно, что 2 диска в красном статусе, а один уже заменился. Диска автозамены больше нет, он заменил собой 3-ий отказавший диск. Ребилд выполнялся несколько минут, запись файлов при отказе 3-х дисков не прервалась, производительность ввода-вывода особо не менялась.

Тест на отказ дисков однозначно прошел успешно.

Заключение

На этом насилие над СХД мы решили прекратить. Подводим итоги:

• Проверка отказа FC портов — успешно
• Проверка отказа Ethernet портов – успешно
• Проверка отказа контроллера — успешно
• Проверка отказа питания — успешно
• Проверка отказа диска в группе\пуле — успешно

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

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

• Нижний Новгород (УЖЕ РАБОТАЕТ – записаться можно тут https://aerodisk.promo/nn/);
  до 16 апреля 2019 года можно посетить центр в любое рабочее время, а 16-ого апреля 2019 года будет организован большой обучающий курс.
• Краснодар (СКОРО ОТКРЫТИЕ – записаться можно тут https://aerodisk.promo/krsnd/ );
  С 9 по 25 апреля 2019 года можно посетить центр в любое рабочее время, а 25-ого апреля 2019 года будет организован большой обучающий курс.
• Екатеринбург (СКОРО ОТКРЫТИЕ, следите за информацией на нашем сайте или на Хабре);
  май-июнь 2019 года.
• Новосибирск (следите за информацией на нашем сайте или на Хабре);
  октябрь 2019 года.
• Красноярск (следите за информацией на нашем сайте или на Хабре);
  ноябрь 2019 года.