Привет, Хабр. Начинаем серию статей с глубоким разбором функционала СХД АЭРОДИСК серии 5. Напомним, что в серию 5 входят СХД ВОСТОК-5 и ENGINE-5, которые работают на базе унифицированного ПО АЭРОДИСК A-CORE. С общим обзором данных железок можно ознакомиться в одной из предыдущих наших статей.
В этой статье речь пойдет об основе СХД – отказоустойчивости и производительности. Как работает, как правильно настраивать и какой результат можно получить.
Мы продемонстрируем работу отказоустойчивости СХД АЭРОДИСК на базе протокола ALUA в условиях высокой нагрузки. Смоделируем отказ активных путей и покажем переключение в режиме реального времени с оптимальных на неоптимальные пути в условиях высокой нагрузки. Более того, все то же самое и даже больше мы покажем в реальном времени на нашем следующем вебинаре Около-ИТ, который состоится 21 февраля 2023 в 15:00. Зарегистрироваться на вебинар можно по ссылке.
Немного матчасти
Для организации отказоустойчивости в системах АЭРОДИСК 5 используется протокол ALUA (Asymmetric Logical Units Access). Это протокол в спецификации SCSI, используемый для управления путями к логическим томам в современных СХД среднего уровня с асимметричным доступом.
Для логических томов со включенным режимом Active/Active - ALUA часть путей контроллера являются активными/оптимальными, а часть — активными/неоптимальными. Контроллер с оптимальными путями выполняет роль владельца логического тома. В случае отказа оптимальных путей для хождения трафика используются неоптимальные пути, которые задействуют интерконнект между двух контроллеров СХД. Схематично это выглядит следующим образом.
Настраиваемся
Для демонстрации настроек и работы мы организовали следующий тестовый стенд:
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 интерфейс.
В разделе «Производительность» можно настроить вывод утилизации и посмотреть скорость и передачу пакетов во время его работы.
Ниже приведены шаги тестирования по каждому шаблону:
Созданы две группы DDP по 12 дисков SAS SSD.
Созданы 4 логических тома на каждой группу по 500 ГБ и презентованы хосту
Далее запускается каждый файл с параметрами нагрузки FIO, длительность теста 30 минут.
После 10-минутного запуска нагрузки на контроллере Engine-0 отключаются одновременно 2 FC таргета, что позволит смоделировать отказ A/O путей.
В течение 5-ти минут наблюдаем за параметрами iops, mb/sec, latency во время нагрузки, фиксируем результат.
С 15-ой минуты восстанавливаем отключенные FC таргеты на контроллере Engine-0 и выполняем аналогичное отключение таргетов для соседней дисковой группы DDP, находящейся на контроллере Engine-1.
После 20-ой минуты восстанавливаем отключенные FC таргеты, завершаем тестирование, фиксируем результаты.
Результаты тестирования
Случайная нагрузка маленькими блоками 4k, 100% чтение
Случайная нагрузка маленькими блоками 4k, 100% запись
Итак, мы видим, что средняя загрузка процессора составила 40-45%, средняя утилизация памяти - 30%. После 4-ого шага тестирования, а именно отказа оптимальных путей и переключения нагрузки через NTB интерфейс, есть просадка в скорости, задержки также возрастают, но остаются на приемлемом уровне для таких условий. Дисковая группа не пытается переключиться на соседний контроллер при потере FC соединения и находится на том же самом контроллере. Аналогичный тест для второй группы соседнего контроллера показал идентичные результаты.
Последовательная нагрузка блоком 128k, 100% чтение
Последовательная нагрузка блоком 128k, 100% запись
При последовательном характере нагрузки с блоком 128k мы видим более высокую утилизацию NTB интерфейса при отказе FC путей. В обоих вариантах тестов нагрузка упирается практически в максимальную пропускную способность – в нашей конфигурации это 2x16Gb. Как и в предыдущих тестах при отключении FC таргетов группа остается на том же контроллере, где и была, вся нагрузка на логические тома идет по неоптимальным путям через интерфейс NTB при некритичнм снижении производительности.
Результаты и заключение
Итак, мы разобрали механизм отказоустойчивости СХД АЭРОДИСК на базе протокола ALUA, привели пример его оптимальной настройки, запустили высокую нагрузку и смоделировали ситуацию отказа путей к основному контроллеру. СХД осталась жива и показала себя, на наш субъективный взгляд, достойно. В качестве продолжения банкета этот и другие сценарии мы вживую разберем на нашем вебинаре Около-ИТ, который состоится 21 февраля 2023 в 15:00. Зарегистрироваться на вебинар можно по ссылке.
Всем спасибо, ждем вопросов, предложений, возражений и негодований.
Увидимся, как обычно, где-то Около-ИТ, до свидания!
