Как стать автором
Обновить
31.85
Рейтинг
АЭРОДИСК
Российский разработчик СХД и систем виртуализации

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

Блог компании АЭРОДИСК Системное администрирование *Серверное администрирование *Хранение данных *Хранилища данных *


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


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


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


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



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


Поэтому, чтобы упростить задачу по обучению ИТ-специалистов, этот год мы решили посвятить бесплатному образованию. Для этого во многих крупных городах России мы открываем сеть Центров компетенции 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. Схема стенда ниже.


image

На 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 года.
Теги:
Хабы:
Всего голосов 11: ↑11 и ↓0 +11
Просмотры 4.9K
Комментарии Комментарии 20

Информация

Дата основания
Местоположение
Россия
Сайт
aerodisk.ru
Численность
31–50 человек
Дата регистрации
Представитель
Вячеслав Володкович