Привет, Хабр! Меня зовут Ольга Проскурякова, я лид направления тестирования в компании TData. Эта статья - моя первая публикация на Хабре. Буда рада поделиться своим опытом.

Платформа, которую разрабатывает TData – это комплексное решение для работы с большими данными: сбор, управление, хранение, визуализация и анализ. В центре платформы – десяток ключевых продуктов. Все они проходят проверку нашей командой тестировщиков. Сегодня я расскажу о том, как мы тестируем один из них.

Для наглядности опишу предметную область тестирования. Это продукт RT.Warehouse - массивно-параллельная СУБД для построения хранилищ данных, разработанная на базе Greenplum.

RT.Warehouse обеспечивает высокую степень производительности и отказоустойчивости благодаря гибкости горизонтального масштабирования, использованию в ядре продвинутого оптимизатора запросов и адаптации архитектуры для хранения и обработки больших массивов данных.

Важность интеграционного тестирование

В нашей платформе одним из ключевых компонентов является RT.ClusterManager - собственный оркестратор, который управляет развертыванием, конфигурацией и мониторингом кластеров. Но важно не только проверять его функциональность (например, создание провайдеров, кластеров или запуск операций), а также проводить полноценное интеграционное тестирование. Это позволит убедиться, что RT.ClusterManager корректно взаимодействует со всеми остальными продуктами, плагинами и инфраструктурными компонентами, с которыми он работает: от плагинов и настроек сети до систем резервного копирования и расширений. Это особенно важно для того, чтобы гарантировать стабильную работу системы в реальных условиях эксплуатации. Все компоненты должны «работать в связке», а возникающие сбои или несогласованности сразу обнаруживаться и устраняться. Объясню на примере связки продуктов: RT.ClusterManager - RT.Warehouse.

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

Подготовка к тестированию

Для начала тестирования нужно подготовить тестовую среду.

Создаем провайдера - виртуальную среду, в которую добавляем хосты. Эти хосты создаём автоматически с помощью джобы в GitLab CI, при этом сами задаём необходимые параметры для ОС, CPU, RAM и дисков. Затем запускам оркестратор RT.ClusterManager, который позволяет создать кластер, добавить провайдера, указать параметры ролей узлов, сети, компонентов. После всех этих операций устанавливаем плагин RT.Warehouse. И тестовая среда готова!)

Кстати, об автоматизации тестирования оркестратора RT.ClusterManager, есть отдельная статья моего коллеги Артёма, вот ссылка https://habr.com/ru/companies/rostelecom/articles/894074/ .

На скрине ниже показана настроенная тестовая среда в интерфейсе RT.ClusterManager.

А так выглядит логическая схема RT.ClusterManager с установленным кластером RT.Warehouse. Схема учитывает все особенности, которые я описала выше.

Тестовые сценарии

Расскажу о двух тестовых сценариях: масштабирование кластера и восстановление данных их бэкапа (Disaster Recovery).

Тестовый сценарий «Масштабирование кластера»

Цель сценария: проверить работоспособность системы после расширения кластера с добавлением новых хостов и сегментов.

1)    Выполняем следующие операции для выделения новых хостов для масштабирования:

· перед запуском расширения кластера, в настройках компонента Gp через UI нашего оркестратора указываем параметр add_segments_per_host=2 - добавляем два новых хоста;

· в настройках exp_segment_datadirs указываем пути для новых сегментов - по одному на каждый.

· в сервисы для сегментов Gp и Pxf - добавляем по 2 новых хоста.

2)  Запускаем операцию расширения через наш оркестратор и следим за процессом.

3)  После завершения в интерфейсе RT.ClusterManager проверяем статус операции расширения, статус «Завершено» - значит операция прошла успешно.

4)  Затем в терминале на мастере убеждаемся, что новые сегменты появились и все узлы доступны (gpstate -s).

5)   Далее выполняем бэкапы, чтобы убедиться, что система справляется. В терминале на мастере проверяем, что директория с бэкапом существует, и в ней находится созданный бэкап.

Вывод, который можно сделать по скриншотам: после расширения кластера с добавлением новых хостов и сегментов система работает стабильно и без потери данных.

Тестовый сценарий «Восстановление данных из бэкапа (Disaster Recovery)»

Цель: Проверить, что возможно восстановить данные из wal-g бэкапа  одного кластера на другом кластере для Disaster Recovery.

1)    Создаем бэкап на основном кластере:

·   На мастере создаем таблицу с тестовыми данными, чтобы в бэкапе были зафиксированы реальные данные;

·   В ClusterManager настраиваем параметры для создания walg_ backup:

o   В конфигурации выбираем хранилище - S3, указываем имя нашего бакета, адрес бакета, уровень логирования и прочие настройки. Применяем их через переконфигурацию кластера в оркестраторе.

o   Запускаем операцию «Run wal-g full backup».

·    После завершения операции проверяем логи, убеждаемся, что бэкап завершился успешно

·    Заходим в S3 и проверяем, что в бакете появились папки с бэкапом

2)   Восстанавливаем бэкап на резервном кластере

Тут нам важно проверить, что возможно восстановить данные из wal-g бэкапа одного кластера на другом кластере для Disaster Recovery в режиме «Высокой доступности», второй кластер будет выступать как запасной

Для этого создаем второй кластер (Disaster Recovery), предварительно настраивая его конфигурацию в ClusterManager

·    Запускаем операцию "Run wal-g restore from backup" (восстанавливаем из резервной копии). Обратите внимание: процедура выполняется для мастер-ноды второго кластера.

·    После завершения восстановления проверяем наличие таблицы командой:

o   таблица из бэкапа должна присутствовать, и она должна быть аналогична таблице с первого кластера

·    Также проверяем статус кластера командой "gpstate -s" мастер должен быть в рабочем состоянии

3)   Переконфигурируем кластер DR в полноценный рабочий кластер

На этом проверка не заканчивается, мы проверяем, что возможно после восстановления данных из wal-g бэкапа основного кластера на кластер Disaster Recovery переконфигурировать кластер Disaster Recovery в полноценный кластер и выполнять работу сервисов на нем. Для этого мы делаем кластер DR полноценным рабочим кластером.

·     В настройках второго кластера в ClusterManager меняем параметры Gp:

o   В поле хранилища указываем уникальное имя бакета;

o   Включаем настройку walg_archive_wal = true;

o   Убеждаемся, что настройка walg_restore_fix_gp_segment_configuration — false;

o   “Переконфигурируем” настройки. После этого кластер станет функционировать как полноценный рабочий.

·    Проверяем наличие таблицы из бэкапа, чтобы убедиться, что данные всё также доступны

·    Проверяем что мастер рабочий

4)   И дальше продолжаем проверять второй кластер на функциональность, проводим такие проверки, как установка расширений DiskQuota с тестами на лимиты, создание ролей, проверкой прав

 ·   Пробуем активировать standby через операцию «Activate standby» для перевода узла в активную роль

Хост standby стал активным мастером

·    И далее на нём добавляем cron задачу с помощью оркестратора. После успешного завершения операции проверяем в терминале на ноде мастера папку cd /etc/cron.d на наличие созданных файлов "rtcm_cronjob_%".

Вывод: такой подход помогает удостовериться, что восстановление данных из wal-g бэкапа успешно и что кластер DR готов к полноценной эксплуатации, а задания cron могут запускаться и выполнять задачи на standby-мастере.

Это лишь часть кейсов, которые мы проверяем в рамках тестирования RT.Warehouse. Помимо автоматизированных операций через RT.ClusterManager и ручных проверок в терминале, у нас есть множество других важных сценариев.

Сбор данных для анализа по результатам тестирования

Чтобы понять, как ведет себя система в разных сценариях, мы используем систематический сбор метрик по результатам тестирования. Это помогает нам улучшать качество наших продуктов.

Какие метрики мы отслеживаем:

·  Время выполнения операций - расширение, бэкапы, восстановление. Например, фиксируем, что расширение занимает 8 минут если больше 10-15, есть повод начать искать ошибки;

·  Ошибки и предупреждения – количество и систематичность ошибок при операциях расширения кластера, бэкапа, восстановления;

·  Доступность и отказоустойчивость - фиксируем, сколько занимает по времени переключение мастера и как реагирует система;

·  Работа расширений проверяем после изменений, продолжают ли работать кастомные модули, типа gp2gp_fdw;

·  Производительность и нагрузка - использование CPU, памяти, диска во время тяжелых операций (масштабирование кластера, бэкапы).

Для сбора метрик по использованию CPU и памяти мы используем Grafana, которая у нас работает на базе собственного продукта - RT.Monitoring.

Что нам даёт сбор таких метрик:

·   Быстро находить узкие места - например, замечаем, что расширение стало дольше при увеличении числа хостов;

·   Обнаруживать нестабильности - например, фиксируем рост ошибок при повторных переключениях мастера;

·   Делать выводы и быстро реагировать - если вдруг операция стала заниматься больше времени или ошибок стало больше, сразу ищем причину;

·   Отслеживать стабильность после обновлений - даже при простом тесте, например, расширении или бэкапе, важно понять: всё ли работает так же быстро, как раньше? Или появились задержки, задержка - значит, есть повод подумать, что что-то сломалось или некорректно работает.

 Вот пример таблицы, по которой мы ведём учёт метрик во время тестирования.

Это помогает нам взглянуть на проблему под другим углом, систематизировать ее и отслеживать. В итоге это позволяет проводить анализ проблемы на основе конкретных значений показателей и быстро принимать решения для ее устранения.

Надеюсь моя статья была полезна для вас.

Спасибо за внимание.