Оставить заявку
Все новости

Тест отказоустойчивости: сценарий отказа кластера

Farzoom Team

Параметры тестирования

Параметр Значение
Тестируемая система Платформа 8»
Версия 8.5.25-FZ
Дата проведения 07.10.2025
Время проведения 15:00 - 16:10 (МСК)

1. Краткий вывод

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

Система продемонстрировала высокую степень отказоустойчивости: вывод из строя 25% вычислительных мощностей не привел к остановке обработки процессов. После возвращения отказавшего кластера в строй наблюдался короткий период ребалансировки нагрузки (около 4 минут), после чего система полностью вернулась к штатным показателям производительности.

2. Цели тестирования

Бизнес-цель: Проверить соответствие системы требованиям к отказоустойчивости, необходимым для эксплуатации в продуктивной среде.

Техническая цель:

  • Подтвердить, что система продолжает обрабатывать запросы при выходе из строя одного из четырех кластеров.
  • Оценить влияние отказа на общую производительность.
  • Замерить время и характер восстановления системы после возвращения отказавшего кластера в пул балансировки.

3. Конфигурация стенда и методология

3.1. Тестовый стенд

Тестовая среда была развернута с использованием скриптов автоматизации Terraform и Ansible и состояла из федерации четырех независимых кластеров Платформы 8, управляемых интеллектуальным прокси-сервером.

3.2. Ограничения тестирования

Для обеспечения чистоты и повторяемости эксперимента, все задачи (service task) в тестовом бизнес-процессе обрабатывались воркером-заглушкой без искусственных задержек. Это позволило измерять производительность именно движка оркестрации, исключив влияние внешних систем.

3.3. Профиль нагрузки
Имя операции TPS SLA s. Errors % Completion ≥ от Creation
UC01_PostStartOneProcess 100 5 1% 85%

3.4. Схема процесса

schema.png

3.5. Сценарий тестирования

Тест проводился по следующему сценарию:

  1. Прогрев (15 минут): На систему подавалась умеренная нагрузка в 50 процессов в секунду (PPS) на протяжении 15 минут для стабилизации JVM и заполнения кэшей.

  2. Основной этап (60 минут):

    • На систему подавалась постоянная нагрузка в 70 PPS.
    • Имитация отказа (15:38): Один из четырех кластеров был принудительно выведен из эксплуатации.
    • Простой (11 минут): Кластер оставался недоступным в течение 11 минут.
    • Восстановление (15:49): Отказавший кластер был возвращен в работу и автоматически подхвачен прокси-балансировщиком.

4. Анализ результатов

4.1. Поведение системы во время отказа (15:38 - 15:49)

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

Пропускная способность: Как видно на графике Throughput, общая скорость создания и завершения процессов (Process instances creation/completion per second) не снизилась. Система продолжила стабильно обрабатывать 70 PPS, эффективно перераспределив нагрузку.

На графике пропускной способности видно, что в момент отказа (15:38) и во время простоя общая производительность системы оставалась стабильной. pps.png

Задержки (Latency): В период работы на трех кластерах задержки обработки оставались в пределах нормы, что свидетельствует об отсутствии деградации производительности на оставшихся узлах. duration.png

4.2. Поведение системы при восстановлении (после 15:49)

После возвращения отключенного кластера в строй система продемонстрировала способность к автоматическому самовосстановлению.

Ребалансировка: Алгоритм балансировки P2C определил восстановленный кластер как наименее нагруженный (0 активных соединений) и направил на него большую часть новых запросов.

Временная деградация: Этот резкий приток нагрузки вызвал кратковременный рост задержек на восстановленном узле, что видно на тепловой карте Overall Processing Latency в виде смещения цветовой палитры вверх.

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

На тепловой карте задержек виден кратковременный всплеск (смещение вверх) в момент возвращения кластера в строй (15:49), который быстро стабилизировался.

5. Выводы

Тест пройден успешно. Система Платформа 8 с федеративной архитектурой подтвердила свою высокую отказоустойчивость.

Ключевые выводы:

  1. Отказ 25% вычислительных мощностей не приводит к остановке системы.

  2. Система обладает эффективными механизмами самовосстановления, автоматически возвращая в работу восстановленные узлы и ребалансируя нагрузку без ручного вмешательства.

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

Графики

Process per partition processPerPartiotion.png Process queue size processQueueSize.png Throughput and Overall Processing Latency throughputAndHeatmap.png RocksDB rocksdb.png