Куча дисков еще не T-RAID: как один компонент проходит через руки десятков тестировщиков

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

Мой опыт включает изолированное тестирование T-RAID и его проверку в составе комплексных релизов СХД TATLIN.UNIFIED. За моими плечами вклад в компонентное, интеграционное, системное тестирования, тестирование производительности и проверку сервисных процедур продукта. Из раза в раз новая область тестирования открывала для меня не столько новый принцип взаимодействия с T-RAID, сколько новые критерии приемки, инструменты и сценарии тестирования. Я проследил, как меняется тестирование T-RAID на каждом из уровней, и собрал свой опыт в этой статье.

Если вы никогда не слышали о T-RAID, советую начать со статьи «Как устроен T-RAID — RAID-массив в СХД TATLIN».

Предметная область тестирования

Прежде чем начать, давайте синхронизируем термины: что представляет собой T-RAID для QA-инженера.

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

• Задача T-RAID: обеспечить отказоустойчивое хранение данных и доступ к ним.

После загрузки модуль T-RAID позволяет создавать дисковые пулы и тома — целевые блочные устройства. Тома T-RAID могут использоваться как самостоятельно, так и совместно с другими datapath-компонентами СХД для построения более сложных сущностей, например, файловых ресурсов, ресурсов с in-memory cache, ресурсов с косвенной адресацией. Или же использоваться для служебных целей самой СХД, например, для хранения внутренней продуктовой конфигурации. 

 Узнать больше о ресурсах с косвенной адресацией в СХД TATLIN.UNIFIED можно в статье «Снапшоты, клоны и не только: как устроен и что умеет маппер в СХД TATLIN».

Попробуем визуализировать:

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

• Initiator — пользователь СХД, находящийся на оборудовании заказчика. Он использует блочные устройства СХД (Volume 1, Volume 2), подключая их по стандартным протоколам FC (Fibre Channel) / iSCSI / NVME. После подключения такого сетевого диска к себе он может запускать свои приложения (базы данных, гипервизоры, файловые шары). В качестве бонуса есть возможность создавать и подключать файловые ресурсы по протоколам NFS/SMB.

• SP-0 и SP-1 — контроллеры хранения СХД, на которых работает T-RAID и все остальные продуктовые компоненты. Объединены в кластер через высокоскоростной интерконнект в виде пары RDMA-интерфейсов.

• Diskbay — дисковый модуль расширения или просто полка с дисками. Каждый диск в полке виден на каждой из нод в кластере.

Таким образом, путь I/O-запроса в продуктовой СХД выглядит так:

1. Пользовательское приложение формирует запрос к данным на инициаторе.

2. Сформированный запрос через механизмы multipath и протоколы доступа к данным FC/iSCSI/NVMe-oF попадает на один из контроллеров хранения SP0 или SP1.

3. Верхнеуровневые компоненты datapath обрабатывают входящий запрос и формируют I/O-запрос в T-RAID.

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

Как мы видим, чтобы достичь T-RAID, запросу надо пройти через слои-компоненты. Компоненты СХД построены так, что их можно тестировать по отдельности: через моки и заглушки различные слои продукта возможно развернуть без привлечения других. Мы называем это «тестированием снизу вверх» или «тестированием сверху вниз» — в зависимости от того, что заглушаем. T-RAID без проблем запускается как без верхнеуровневых слоев datapath-компонентов, так и без слоя управления системой, его можно тестировать независимо от них.

Команды как уровни тестирования

После сборки компонента T-RAID наблюдаем классический пайплайн его проверки: в зависимости от события (открытие PR в репозиториях T-RAID, nightly-тестирование, релиз компонента T-RAID или релиз СХД) формируются требования к полноте образа для тестирования. Чем больше компонентов в сборке, тем больше команд подключается. Посмотрим на наши команды в разрезе уровней тестирования:

• Сomp-tests (component tests) — команды компонентного тестирования, по одной на каждый компонент СХД. Нашу команду упрощенно называют T-RAID QA. Все команды компонентного тестирования работают бок о бок с разработчиками, мы не исключение. В нашем пользовании как виртуальные машины, так и физические серверы, на которые в основном разливается легковесный образ с T-RAID и минимальным окружением.

• Сit (component integration tests) — команда интеграционного тестирования компонентов. В зоне ответственности команды — интеграция между компонентами: проверка соблюдения контрактов, отсутствие узких мест. Это первый уровень тестирования, где работают с полным или частичным образом TATLIN, но пока еще на виртуальных машинах.

• St, sit (system tests, system integration tests) — команды комплексного системного тестирования на железе, st-auto и sit-manual QA. Команды часто работают вместе, поэтому я позволил себе мысленно объединить их в одну команду системного тестирования st. На этом уровне собирается полноценный TATLIN в том виде, в котором он поставляется клиенту. Исполняются автоматизированные end-to-end-сценарии на целевом железе, а также ручное тестирование по сценариям, которые невозможно автоматизировать. Эта же команда занимается тестированием сервисных процедур: замены диска, замены одного из серверов СХД.

• Uat (user acceptance tests) — команда приемочного тестирования. Они выполняют сложные сценарии, максимально приближенные к реальному использованию системы. Это может быть многодневная сессия чтения и записи, во время которой в системе методично проверяют несколько failover-сценариев подряд.

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

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

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

Для тестирования T-RAID на компонентном уровне не нужно ничего кроме самого T-RAID. Так как T-RAID — это модуль ядра ОС, для его тестирования потребуется разместить этот модуль на виртуальной машине (ВМ). Стандартная конфигурация включает как минимум три ВМ с минимальным окружением и используется для проверки, которая подтверждает, что компонент работает согласно заложенной архитектурной логике. Кроме того, эта среда в силу своей компактности наиболее удобна для интеграции инструментов анализа: трейсинга, оценки покрытия кода.

Простые тесты можно разбить на функциональные области. Давайте рассмотрим список таких областей со сценариями использования:

• Действия с пулами и ресурсами. Создать, удалить, стартовать пул или том, добавить диск в пул, расширить том.

• Действия с фоновыми процессами T-RAID. Восстановить массив при потере дисков (recovery), защитить от деградации данных на дисках со временем (scrubber).

• Действия с протоколами интерконнекта. Создать условия для работы внутренних интерконнект-сервисов T-RAID.

• Взаимодействие через внешний API. Проверить экспортируемую сторонним компонентам функцию библиотеки, которая позволяет взаимодействовать с T-RAID, получить информацию о пуле, выполнить аллокацию тома.

• Отказоустойчивые сценарии. Проверить отказ контроллера хранения.

Далее начинается самое интересное: комбинирование функциональных областей. Одно дело просто проверить удаление диска из пула, но совершенно другое — сделать это во время активно идущей сессии чтения/записи. Для чего это нужно? Ответ прост: T-RAID — сложный компонент, и проверить часть требований можно, только совместив функциональные области тестирования друг с другом. Разберемся, как базовые сценарии собираются в более сложный. Ниже привел сценарий тестирования вывода сбойного диска из пула под нагрузкой:

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

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

3. Поставить задержки и ошибки на запись в выбранный диск на одном контроллере хранения или сразу на двух.

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

5. Удалить диск из пула.

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

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

8. Убедиться, что recovery успешно восстановил требуемую избыточность данных.

9. Убедиться, что ошибок в сессии записи не произошло.

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

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

В завершение этой части поговорим, какие основные инструменты мы используем в команде comp-test.

Все автотесты написаны на Python 3 с использованием тестового фреймворка pytest. Результаты тестирования визуализируем через Allure Report, а для управления тестовыми кампаниями мы используем TestY TMS — систему управления тестированием с открытым исходным кодом, которую делают наши коллеги из YADRO.

Если вы не знакомы с TestY, оставляю для вас пару полезных ссылок:

• TMS на замену TestRail: писали для себя, а выложили в open source

• Улучшение навигации и рост производительности: что изменилось в системе управления тестированием TestY 2.0

Components integration tests: интеграционное тестирование

Мы протестировали T-RAID, но где гарантия, что ожидаемое поведение для внешних компонентов осталось штатным? Для продуктов эти проверки обеспечивает команда Components integration tests (CIT). На плечах CIT множество разнообразных и интересных (с точки зрения конечного продукта) задач, однако остановимся лишь на тех, что касаются T-RAID.

Если уровнем ниже у нас был голый T-RAID, то отныне мы работаем с полноценным образом TATLIN во все том же виртуальном окружении. В работу берутся уже новые сущности — пользовательские пулы. Пользовательские пулы — T-RAID-пулы «в продуктовой обертке», со всеми дополнительными сущностями и обвязками от системы управления СХД и от других компонентов системы.

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

1. Создать пул, тома, ресурсы (в этот раз через продуктовую утилиту tatlin-cli или REST-сервисы).

2. Презентовать ресурсы на инициаторов.

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

4. Установить ошибки на запись в диск (на одном контроллере хранения или сразу на двух).

5. Дождаться смены статуса диска с последующим автоматическим удалением диска из пула.

6. Проверить состояние пула.

7. Убедиться в том, что фоновый процесс recovery запущен.

8. Убедиться в изменении статуса пула (recovering).

9. Дождаться завершения процесса recovery.

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

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

На этом этапе набор инструментов становится лаконичнее. Из ранее упомянутых средств используются fio и fail_make_request. К ним добавляется базовый инструментарий для работы с REST API, а также обертки для официальных CLI-утилит TATLIN — тех самых, которые в дальнейшем будут применяться на стороне заказчика.

System tests & System integration tests: системное тестирование

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

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

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

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

• удаление диска с одного или двух контроллеров в отсутствие одного или двух межнодных кабелей;

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

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

Отныне нам недостаточно того, что сценарий отработал на интеграции нескольких компонентов. Нам важно, чтобы в любой момент система оставалась на плаву. Например, именно на этом этапе проверяем валидность hot-plug: TATLIN обнаруживает и начинает работу с диском, вставленным «на горячую». Также именно здесь проверяются сервисные процедуры — набор пошаговых инструкций для сервисных случаев.

Это ключевой этап тестирования для T-RAID, поскольку верификация смещается в сторону реального окружения конечного продукта. Здесь проверяется функционирование модуля на физических HDD и SSD, а также на масштабных пулах, состоящих из сотен дисков. В частности, этап позволяет оценить реакцию системы на работу с массивами сверхбольшой емкости, а это петабайты данных.

Логическим продолжением этапа становится longevity-тестирование, оценивающее надежность системы на дистанции. Это непрерывный двух- или трехнедельный тест под нагрузкой, имитирующей реальную эксплуатацию. Чтобы усложнить условия, на системе один или несколько раз в день исполняют failover-сценарии.

Состав тестового инструментария на этом этапе почти не расширяется, однако набор утилит растет в пользу платформенных решений. Основное расширение стека происходит за счет подключения внешних систем автоматизации и контроля: платформа виртуализации VMware, которая может быть полезна в проверке валидности экспорта Raw Device Mapping, и системы мониторинга Zabbix, отвечающие за утилизацию ресурсов.

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

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

На этом уровне исключены тривиальные сценарии или стандартное интеграционное тестирование. Тест-аналитики UAT формируют программу испытаний на основе реального опыта эксплуатации: они анализируют инциденты со стороны клиентов на прошлых версиях ПО и актуальный список дефектов. Результатом становятся сложные сценарии с пересечением негативных событий. В качестве примера можно привести одновременную деградацию нескольких накопителей в сочетании с нештатной перезагрузкой контроллера или циклическим отключением питания СХД.

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

• Запускаем многодневную сессию чтения-записи.

• Удаляем один из дисков системного пула.

• Заменяем второй диск системного пула.

• Удаляем из системы диски блочных ресурсов.

• Удаляем из системы диски файловых ресурсов.

• Отрываем кабель интерконнекта.

• Оцениваем работу recovery на каждом из пулов, как пользовательских, так и системных.

• Поочередно перезапускаем контроллеры хранения.

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

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

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

В случае изолированного тестирования T-RAID важный акцент делается на синтетические тесты для фокусной проверки отдельных подсистем модуля. Для достижения этой цели создаются пулы на nullblk-дисках, что позволяет нам пренебречь скоростью дисков. А также пишутся отдельные диагностические утилиты, создающие нагрузку в определенном месте T-RAID. В результате такого тестирования мы можем оценить базовый оверхед T-RAID при работе с блочными устройствами в различных сценариях, производительность его различных кластерных RPC-сервисов, а также детально исследовать работу его фоновых процессов (recovery, scrubber, balancer). Во всех этих измерениях нам важно убедиться, что мы детально понимаем характер нагрузки и упираемся не в программные дефекты, а ограничены лишь аппаратными возможностями собранного тестового стенда.

В следующих сценариях определяют максимальную пропускную способность на реальных дисках (HDD и SSD) на различных видах нагрузки: последовательный или случайный I/O, выровненный или невыровненный относительно геометрии данных T-RAID. Эти измерения позволяют получить нам отправную точку — производительность T-RAID на реальных дисках, но с полностью исключенным влиянием других компонентов. Эти данные используются как сами по себе для раннего обнаружения регрессий производительности в T-RAID, так и в качестве референсных значений для других тестов.

В случае тестирования общей производительности СХД продуктовой нагрузке подвергается весь комплекс. Помимо T-RAID, в нагрузке здесь участвуют и другие datapath-компоненты, а также особенности железа продукта: рассадки сервисов СХД на отдельные процессорные ядра, power-management-комплексы. На данном этапе измеряются финальные E2E-значения производительности от инициатора до диска, которые и увидит заказчик СХД. Результаты такого тестирования также весьма полезны для T-RAID. Знание референсных значений, полученных ранее, позволяет сравнить производительность и масштабируемость «голого» T-RAID и T-RAID в полной продуктовой сборке. Значения в продукте могут отличаться как в худшую сторону, когда в полной картине создались неблагоприятные условия для оптимальной работы T-RAID. И в лучшую, когда верхние datapath-слои могли оптимизировать паттерн работы с T-RAID. Здесь в полной мере раскрывается богатый мир perf-R&D.

Команда perf-tests также занимается сценариями на стыке функциональных областей, например, замерами скорости ребилда данных при замене диска под активной пользовательской нагрузкой. Инженеры вносят активный вклад в «тюнинг» параметров datapath, подбирают рекомендованные параметры для работы с нашими СХД: размер I/O-блока, глубина очереди записи/чтения, количество сессий iSCSI/FC и прочее. Эта же команда дает окончательный ответ на вопрос: «Подходит ли СХД по требованиям производительности к сценарию использования X с параметрами Y?»

Команда оперирует как классическими инструментами тестирования производительности — fio, sysstat, blktrace, flamegraph, ebpf, — так и собственным фреймворком автоматизации перформанс-тестов.

Чего мы добились?

Любой достаточно душный тестировщик точно скажет, чего мы не добились: полного тестового покрытия! Тем не менее многогранность взглядов на одни и те же компоненты большой системы компенсирует многие пробелы в тестовом покрытии. Комплексный подход в тестировании наделяет каждый релиз TATLIN стабильностью. Мы не верим в мифы о 100% тестовом покрытии, мы защищаем продукт от критических уязвимостей и инцидентов, а это гораздо важнее абстрактных процентов.

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

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

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

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