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

Отказоустойчивость СХД АЭРОДИСК в условиях высокой нагрузки

Время на прочтение6 мин
Количество просмотров3.9K

Привет, Хабр. Начинаем серию статей с глубоким разбором функционала СХД АЭРОДИСК серии 5. Напомним, что в серию 5 входят СХД ВОСТОК-5 и ENGINE-5, которые работают на базе унифицированного ПО АЭРОДИСК A-CORE. С общим обзором данных железок можно ознакомиться в одной из предыдущих наших статей.

В этой статье речь пойдет об основе СХД – отказоустойчивости и производительности. Как работает, как правильно настраивать и какой результат можно получить.

Мы продемонстрируем работу отказоустойчивости СХД АЭРОДИСК на базе протокола ALUA в условиях высокой нагрузки. Смоделируем отказ активных путей и покажем переключение в режиме реального времени с оптимальных на неоптимальные пути в условиях высокой нагрузки. Более того, все то же самое и даже больше мы покажем в реальном времени на нашем следующем вебинаре Около-ИТ, который состоится 21 февраля 2023 в 15:00. Зарегистрироваться на вебинар можно по ссылке.

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

Для организации отказоустойчивости в системах АЭРОДИСК 5 используется протокол ALUA (Asymmetric Logical Units Access). Это протокол в спецификации SCSI, используемый для управления путями к логическим томам в современных СХД среднего уровня с асимметричным доступом.

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

Схема переключения отказа А/O путей на А/N
Схема переключения отказа А/O путей на А/N

Настраиваемся

Для демонстрации настроек и работы мы организовали следующий тестовый стенд:

  • Linux-сервер (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта – 1шт.

  • Коммутатор FC 16G – 1 шт.

  • СХД Аэродиск ENGINE-5 (2xIntel Xeon E5-1650 v4), 64 GB RAM, 2xFC-card 16G 2 port, 24xSAS SSD 1,8 TB) — 1 шт.

Схема подключения:

Физическая схема подключения стенда
Физическая схема подключения стенда

Теперь нам необходимо создать дисковые группы, в нашем случае это DDP. Используем все доступные SSD SAS диски в количестве 24 штук. Для создания перейдем в раздел «Подсистема хранения», далее «DDP» и «Создать группу».

Откроется форма создания дисковой группы. Важный момент при создании пула — перевести параметр «Поддержка ALUA» в состояние «Вкл», далее задаём название дисковой группы и выбираем то количество дисков, которое необходимо для использования.

После создания группы необходимо подготовить логические тома (LUN) под тестирование. В нашем случае мы создаем 4 логических тома для каждой группы DDP с уровнем защиты RAID-10 объемом 500 ГБ каждый.

Необходимо также обратить внимание, что в системе под использование ALUA можно выбрать два типа интерфейса: NTB или INTER. Данная реализация выбора связана с различными типами систем АЭРОДИСК. В случае нашего стенда в качестве интерконнекта используется NTB, поэтому выбираем его. Сменить тип используемого интерфейса можно в правом верхнем меню, выбрав «Engine-0»/ «Engine-1» и перейдя в пункт «Настройки».

Хотели бы обратить внимание, что с 5 версии для существующих дисковых групп возможно включение и отключение работы режима ALUA. Для этого необходимо выбрать имеющуюся группу RDG\DDP, зайти в нее и выбрать пункт «Выкл» или «Вкл» на параметре «Поддержка ALUA». Это будет работать только при условии, если отсутствует маппинг логических томов, принадлежащих к этой группе.

Все логические тома мы презентуем одному Линукс-хосту. Для инициализации томов необходимо использовать корректный файл multipath.conf. Файл можно скачать на портале с документацией, либо обратится в техническую поддержку с запросом.

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

В ходе тестирования будут выполняться следующие сценарии отказа путей СХД:

Отказ A/O путей при случайной нагрузке маленькими блоками 4k и переключение на A/N путь.

100%_read_4k_random

[global]

blocksize=4k

size=80%

direct=1

buffered=0

ioengine=libaio

iodepth=32

group_reporting

rw=randread

numjobs=1

runtime=1800

time_based=1

per_job_logs=0

log_avg_msec=30000

write_bw_log=/home/ubuntu/Result/4k-rand-read4_final.results

write_iops_log=/home/ubuntu/Result/4k-rand-read4_final.results

write_lat_log=/home/ubuntu/Result/4k-rand-read4_final.results

100%_write_4k_random

[global]

blocksize=4k

size=80%

direct=1

buffered=0

ioengine=libaio

iodepth=16

group_reporting

rw=randwrite

numjobs=2

runtime=1800

time_based=1

per_job_logs=0

log_avg_msec=30000

write_bw_log=/home/ubuntu/Result/4k-rand-write4-final.results

write_iops_log=/home/ubuntu/Result/4k-rand-write4-final.results

write_lat_log=/home/ubuntu/Result/4k-rand-write4-final.results

Отказ A/O путей при последовательной нагрузке большими блоками 128k и переключение на A/N путь.

100%_read_128k_seq

[global]

blocksize=128k

size=80%

direct=1

buffered=0

ioengine=libaio

iodepth=32

group_reporting

rw=read

numjobs=2

runtime=1800

time_based=1

per_job_logs=0

log_avg_msec=30000

write_bw_log=/home/ubuntu/Result/128k-seq-read-final.results

write_iops_log=/home/ubuntu/Result/128k-seq-read-final.results

write_lat_log=/home/ubuntu/Result2/128k-seq-read-final.results

100%_write_128k_seq

[global]

blocksize=128k

size=80%

direct=1

buffered=0

ioengine=libaio

iodepth=16

group_reporting

rw=write

numjobs=2

runtime=1800

time_based=1

per_job_logs=0

log_avg_msec=30000

write_bw_log=/home/ubuntu/Result2/128k-seq-write-final.results

write_iops_log=/home/ubuntu/Result2/128k-seq-write-final.results

write_lat_log=/home/ubuntu/Result2/128k-seq-write-final.results

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

В разделе «Производительность» можно настроить вывод утилизации и посмотреть скорость и передачу пакетов во время его работы.

Ниже приведены шаги тестирования по каждому шаблону:

  1. Созданы две группы DDP по 12 дисков SAS SSD.

  2. Созданы 4 логических тома на каждой группу по 500 ГБ и презентованы хосту

  3. Далее запускается каждый файл с параметрами нагрузки FIO, длительность теста 30 минут.

  4. После 10-минутного запуска нагрузки на контроллере Engine-0 отключаются одновременно 2 FC таргета, что позволит смоделировать отказ A/O путей.

  5. В течение 5-ти минут наблюдаем за параметрами iops, mb/sec, latency во время нагрузки, фиксируем результат.

  6. С 15-ой минуты восстанавливаем отключенные FC таргеты на контроллере Engine-0 и выполняем аналогичное отключение таргетов для соседней дисковой группы DDP, находящейся на контроллере Engine-1.

  7. После 20-ой минуты восстанавливаем отключенные FC таргеты, завершаем тестирование, фиксируем результаты.

Результаты тестирования

Случайная нагрузка маленькими блоками 4k, 100% чтение

CPU СХД 4k random read
CPU СХД 4k random read
RAM СХД 4k random read
RAM СХД 4k random read
IOPS 4k random read
IOPS 4k random read
Задержки 4k random read
Задержки 4k random read

Случайная нагрузка маленькими блоками 4k, 100% запись

CPU СХД 4k random write
CPU СХД 4k random write
RAM СХД 4k random write
RAM СХД 4k random write
IOPS 4k random write
IOPS 4k random write
Задержки 4k random write
Задержки 4k random write

Итак, мы видим, что средняя загрузка процессора составила 40-45%, средняя утилизация памяти - 30%. После 4-ого шага тестирования, а именно отказа оптимальных путей и переключения нагрузки через NTB интерфейс, есть просадка в скорости, задержки также возрастают, но остаются на приемлемом уровне для таких условий. Дисковая группа не пытается переключиться на соседний контроллер при потере FC соединения и находится на том же самом контроллере. Аналогичный тест для второй группы соседнего контроллера показал идентичные результаты.

Последовательная нагрузка блоком 128k, 100% чтение

CPU СХД 128k seq read
CPU СХД 128k seq read
RAM СХД 128k seq read
RAM СХД 128k seq read
MB/s 128k seq read
MB/s 128k seq read
Задержки 128k seq read
Задержки 128k seq read

Последовательная нагрузка блоком 128k, 100% запись

CPU СХД 128k seq write
CPU СХД 128k seq write
RAM СХД 128k seq write
RAM СХД 128k seq write
MB/s 128k seq write
MB/s 128k seq write
Задержки 128k seq write
Задержки 128k seq write

При последовательном характере нагрузки с блоком 128k мы видим более высокую утилизацию NTB интерфейса при отказе FC путей.  В обоих вариантах тестов нагрузка упирается практически в максимальную пропускную способность – в нашей конфигурации это 2x16Gb. Как и в предыдущих тестах при отключении FC таргетов группа остается на том же контроллере, где и была, вся нагрузка на логические тома идет по неоптимальным путям через интерфейс NTB при некритичнм снижении производительности.

Результаты и заключение

Сводная таблица результатов
Сводная таблица результатов

Итак, мы разобрали механизм отказоустойчивости СХД АЭРОДИСК на базе протокола ALUA, привели пример его оптимальной настройки, запустили высокую нагрузку и смоделировали ситуацию отказа путей к основному контроллеру. СХД осталась жива и показала себя, на наш субъективный взгляд, достойно. В качестве продолжения банкета этот и другие сценарии мы вживую разберем на нашем вебинаре Около-ИТ, который состоится 21 февраля 2023 в 15:00. Зарегистрироваться на вебинар можно по ссылке.

Всем спасибо, ждем вопросов, предложений, возражений и негодований.

Увидимся, как обычно, где-то Около-ИТ, до свидания!

Теги:
Хабы:
Всего голосов 4: ↑2 и ↓20
Комментарии15

Публикации

Информация

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