Q, хабряне! На связи Максим Тучков, инженер по разработке ПО в YADRO. Хочу рассказать об уровнях тестирования  RAID-массива T-RAID — одного из общих компонентов семейства TATLIN — на всех уровнях интеграции. Пройдем путь от компонентного тестирования на виртуальных машинах с легковесным образом до комплексного системного тестирования на железном окружении. И вместе разберемся, сколько нужно специалистов, чтобы уверенно сказать: «T-RAID работает так, как должен».

За время работы мы с командой выпускали минорные и мажорные релизы T-RAID как в составе систем хранения данных, так и в качестве отдельного компонента. Мне довелось поучаствовать в компонентном, интеграционном и системном тестированиях, пара задач была направлена на тестирование производительности, некоторые имитировали сервисные процедуры. 

Всякий раз новая область тестирования открывала для меня не столько новый принцип взаимодействия с T-RAID, сколько новые критерии приемки, инструменты и сценарии тестирования. Я проследил, как меняется тестирование T-RAID на каждом из уровней, и собрал опыт в этой статье.

Предметная область. Жизненный цикл T-RAID

Начнем с того, что такое T-RAID. Для простоты визуализируем:

На картинке видим такие сущности:

• Initiator — опциональный поставщик данных, использующий СХД. Инициатором может быть все, что потребляет сетевые диски: от хоста до гипервизора.

• SP-0 и SP-1 — два контроллера хранения данных, работающих в режиме Active-Active. У каждой ноды на борту стоит модуль ядра T-RAID.

• Diskbay — дисковая полка, отображаемая в файловой системе контроллеров хранения.

Так, T-RAID — это кластерно-ориентированный модуль ядра Linux. Его задача — обеспечивать отказоустойчивое хранение данных в соответствии с концепцией RAID (Redundant Array of Independent Disks). 

Модуль вступает в работу задолго до полной инициализации СХД, ведь часть ее внутренних сервисов использует T-RAID. Создается кластерный пул, где функционируют тома, с распределенным хранилищем etcd, disk based heartbeat, статистикой и прочим.

Когда СХД загружена и готова к работе, T-RAID используется по прямому назначению: по запросу клиента поверх дисков строятся пулы, на пулах тома, которые выполняют функцию прослойки для следующего компонента СХД — Data Services.

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

Уровни тестирования: инструменты, цели, сценарии, особенности

Как только T-RAID собирается в кластере, сразу несколько команд получают готовый объект тестирования. Голый T-RAID, развернутый на виртуальных машинах или полноценных серверах, берется в работу командами comp-tests и perf-tests. Чем шире образ и больше компонентов, тем больше команд присоединяются к тестированию: cit (component integration tests / sys-tests), datapath hardware complex tests, sit (system integration tests), uat (user acceptance tests).

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

Comp-tests: компонентное тестирование

Как я писал выше, для тестирования на компонентном уровне не нужен родительский продукт, хотя большинство сценариев тестирования ориентированы на него. Поэтому ранее описанная конфигурация упрощается: весь кластер (инициатор и контроллеры хранения) строится из виртуальных машин, а дисковая полка эмулируется через нарезку физических накопителей. Разливаемый образ сокращается до одного T-RAID.

Примечание: иногда разрабатываемые в T-RAID фичи требуют железных, а не виртуальных серверов.

В результате получаем конкретный набор функциональных областей и базовых сценариев к ним: 

Далее начинается самое интересное: комбинирование функциональных областей, в том числе с привлечением сторонних инструментов. Например, одно дело просто проверить удаление диска из пула, но совершенно другое —  сделать это во время активно идущей сессии чтения или записи. А в системах хранения данных так происходит почти всегда. 

Посмотрим, какие дополнительные инструменты могут пригодиться:

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

1. Создать пул, тома.

2. Начать сессию записи.

3. Поставить задержки на запись в диск (на одном контроллере хранения или сразу на двух).

4. Дождаться установки флага, сигнализирующего о готовности удалить диск.

5. Удалить диск.

6. Запустить фоновый процесс recovery.

7. Дождаться его завершения.

8. Запустить контрольную сессию чтения для проверки целостности записанных данных. 

Важно отметить, что часть описанных в сценарии действий не выполняется непосредственно T-RAID, поскольку в родительских продуктах для этого есть компонент Control Path. Таким образом, на уровне component tests в T-RAID проверяют корректность реакций модуля ядра в различных условиях и соблюдение контракта целостности и доступности данных. 

Perf-tests: тестирование производительности

Главная задача любого RAID-массива — повысить отказоустойчивость и производительность чтения и записи с помощью некоторого множества дисков. Если с отказоустойчивостью все понятно, то как RAID может повысить производительность? Один из ответов на поверхности: параллелизм в выполнении I/O-операций. Однако это ускорение приходит к нам по умолчанию, когда начинаем использовать RAID. 

Есть и неочевидный ответ: исходники, с которыми работает T-RAID, — диски. Разумеется, диски бывают разные: HDD, SSD, NVMe (для T-RAID — rotational или non_rotational). Пул, построенный на NVMe-дисках будет работать быстрее пула на HDD-дисках, но и стоить будет дороже. Возможность менять тип девайса не только влияет на скорость работы с данными, но и приводит к появлению совершенно неочевидных вещей, таких как ratelimiter только на пулах с ротационными девайсами.

Каждая новая сущность в datapath, фоновый процесс или даже сбоящий диск могут стать узким местом. Поиском таких узких мест, а также глобальным замером быстродействия T-RAID и занимается команда perf-tests. Окружение сильно напоминает используемое в компонентном тестировании, однако наличие железных серверов — обязательное предусловие тестирования.

Первыми и самыми главными в списке перформанс-сценариев стоят тесты с null_blk (программный драйвер, позволяющий пренебречь скоростью дисков). Так, во внимание берется базовый оверхед T-RAID, производительность CRPC-сервисов, работа в деградировавшем состоянии. Режим passthrough — пересылка запросов на соседний контроллер в силу невозможности выполнить операцию на текущем, работа с уже известными мониторами (recovery, scrubber и т.д.). Во всех этих сценариях нам важно убедиться, что мы не упираемся в возможности железа.

Следующие сценарии определяют максимальную пропускную способность вместе с дисками. Обнаружив целевое значение, можно делать выводы, как она меняется в условиях работы сторонних объектов — например, фоновых процессов. Стоит отметить, что не только диски влияют на эту скорость, но и схема защиты данных. 

Подробнее о схемах защиты данных читайте в статье о том, как устроен T-RAID.

Дальше по списку тестирования идут нагрузки: последовательный или случайный I/O, выровненный или невыровненный (последний приводит к операциям read-modify-write). Тестирование по размеру блока, глубине очереди и еще очень многим различным параметрам. А на закуску — тесты с фоновыми процессами. Всегда важно проверять, интрузивны они или нет.

Отдельно стоят тесты, ориентированные на системы хранения данных. Так, в TATLIN.ARCHIVE упор делается на HDD-диски, в TATLIN.AFA — на длинные цепочки (например, 14+2).

Итак, для тестирования производительности мы используем инструменты fio, null_blk, iostat и mpstat, а также анализиуем следующие метрики:

• IOPS и МБ/с;

• среднюю задержку + p95/p99/p99.9;

• наличие ошибок ввода и вывода;

• общий перфоманс (I/O-статистика).

Components integration tests: системные тесты

Все последующие уровни тестирования будут содержать полный образ TATLIN.UNIFIED и TATLIN.AFA, которые мы также научились разливать на виртуальных машина.

По части T-RAID на этом уровне существуют свои функциональные области, однако сценарии становятся end-to-end, а критерием приемки — в первую очередь вывод утилиты tatlin-cli, которая предустановлена на контроллерах хранения. Например, пул, на котором работает фоновый процесс recovery, должен иметь состояние Recovering, а в отсутствие диска в пуле утилита непременно сообщит об этом. 

Еще одной отличительной особенностью уровня системных тестов является использование REST-запросов. Сервисов на системе много, они активно взаимодействуют друг с другом, значит, и тесты должны учитывать возможные расхождения в реакции в зависимости от поведения компонента T-RAID. Например, выставление T-RAID на диске флага pre_fail сигнализирует ControlPath о необходимости безвозвратно удалить диск из пула: важно, чтобы сервис health больше никогда не доверял этому диску.

Итого, на уровне интеграции компонентов среди сценариев есть:

• удаление дисков под нагрузкой;

• удаление и возврат дисков с обнуленными данными;

• запуск монитора recovery после замены диска;

• работа кластера в passthrough-режиме в отсутствие дисков.

С новыми сценариями приходят и новые критерии приемки. Нам уже не так важно, долго ли работал recovery и были ли у него проблемы в ходе починки блоков. Важно, чтобы пользователь всегда был оповещен, в каком состоянии находится система.

К уже известным инструментам fio, make-it-fail на этом уровне добавляется crm (cluster resource manager) и активное использование curl.

Datapath complex tests, system integration tests, service procedures: комплексные ручные и автотесты на железе

На следующих уровнях тестирования за редким исключение уже не используются виртуальные машины в качестве эмулятора СХД. Собирается полноценный TATLIN.UNIFIED Gen1 или Gen2, TATLIN.AFA, с которым проводится работа. В данном разделе я позволил себе объединить активности из разных команд, ввиду того что они идут бок о бок. Так, ручной тестировщик из SIT нередко использует автотесты из библиотеки для предварительных условий своих проверок. Например, создать пул, предельное количество ресурсов, экспортировать их и начать сессию активного I/O, затем выполнить свою неавтоматизируемую или сложно автоматизируемую проверку: отключить SAS кабели от одного из контроллеров хранения.

В большой библиотеке автотестов, о которой писала Наташа Грязнова писала в статье, собраны пересечения всевозможных функциональных областей, среди которых, разумеется, есть T-RAID-специфичные сценарии.

В подборке можно обнаружить:

• долгоиграющие автотесты фонового процесса recovery во время дополнительных фейловеров (например, ребут контроллера хранения);

• удаление диска с одного или двух контроллеров в отсутствие одного или двух RDMA-кабелей;

• мультифейловеры в отсутствие кластерных дисков;

• проверка на отсутствие остановки I/O (например, в случае удаления диска).

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

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

Критерием же здесь, помимо упомянутого корректного вывода утилиты tatlin-cli становится состояние кластера в целом: не отвалились ли пути, пока мы писали, не просели ли IOPS, все ли протоколы ввода/вывода позволили экспортировать ресурсы. Ну а среди инструментов — уже упомянутые fio, make-it-fail, tatlin-cli, curl.

User acceptance tests: приемочное тестирование

За несколько недель до релиза T-RAID ждет прожарка приемочными тестами. Особенность тестирования продуктов семейства TATLIN — многодневная сессия чтения и записи, во время которой выполняют failover-сценарии. За такую сессию СХД переживает:

• удаление кластерного диска;

• удаление data-дисков (блочный ресурс);

• удаление data-дисков (файловый ресурс);

• работу Recovery;

• замену кластерного диска;

• поочередный ребут контроллеров хранения.

Одновременно с этим идет активный мониторинг со стороны Zabbix или Grafana, поэтому в любой момент могут начать собираться логи. В таких сценариях нам важно удостовериться в равномерности нагрузки, корректности журнала событий, отказоустойчивости системы в целом. А инструменты могут быть любыми: от bash-скриптов и автотестов на Python до гипервизора VMware ESXi.

Стоит ли использовать такой подход в тестировании?

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

Общность зависимостей — вот, что определяет будет ли сценарий упущен или проверен дважды, будет ли тестирование избыточным или достаточным. Научившись ужимать комплексные сценарии на железе до 30-секундных автотестов, мы ускорили процесс отладки в десятки раз, а для валидации фикса data corrupt разработчику не приходится ожидать прогона длиной в десятки часов, даже если он был обнаружен именно в таком тесте. 

Я посчитал: на данный момент более 70 QA-инженеров вносят вклад в обеспечение качества T-RAID. Присоединяйтесь к команде тестирования!