Кластер Comindware Platform. Восстановление после аварий

Экспериментальная функция

Представленная здесь функция находится на стадии разработки. См. «Поддержка экспериментальных функций».

Введение

Comindware Platform поддерживает кластерные конфигурации, которые обеспечивают высокую доступность, отказоустойчивость и горизонтальное масштабирование.

Здесь представлены рекомендации и процедуры восстановления ПО Comindware Platform в кластерных конфигурациях после сбоев.

Средства, обеспечивающие надежность и восстановление кластеров

Кластерная архитектура Comindware Platform позволяет восстанавливать систему благодаря следующим средствам:

  • проверка здоровья узлов: все узлы предоставляют эндпоинт api/health для мониторинга состояния;
  • автоматическое перераспределение трафика: балансировщик нагрузки должен автоматически исключать неисправные узлы;
  • резервные узлы: кластеры Apache Ignite, OpenSearch (Elasticsearch) и Apache Kafka обеспечивают избыточность во время восстановления;
  • распределённое хранилище: DFS обеспечивает сохранность и целостность резервных копий и файлов для всех узлов.

Стратегические принципы обеспечения надёжности системы

Подготовка к авариям

Чтобы оперативно восстанавливать систему в аварийных ситуациях, рекомендуется реализовать следующие меры:

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

Стратегия резервного копирования

Многоуровневый подход к резервному копированию

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

Различные периоды хранения данных (от 1 часа до 1 месяца) для каждого уровня позволяют сбалансировать требования к надёжности и стоимости хранения резервных копий:

  • Полные резервные копии всей системы (еженедельно для продуктивных систем, ежемесячно для тестовых) — обеспечивают точку восстановления для критических ситуаций.
  • Инкрементальные копии (ежедневно для всех систем) — минимизируют потерю данных при некритических сбоях.
  • Копии базы данных Comindware Platform (каждые 4–12 часов в зависимости от критичности) — обеспечивают быстрое восстановление конфигурации и данных экземпляра ПО в непредвиденных обстоятельствах.

Кроме того, следует применять различные подходы к резервному копированию в зависимости от контура, в котором эксплуатируется экземпляр системы.

Подходы к резервному копированию по контурам

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

  • Продуктивный контур
    • Полные копии: еженедельно (воскресенье), хранить 1 месяц.
    • Инкрементальные копии: ежедневно (00:00–03:00), хранить последние 15 копий.
    • Копии базы данных: не реже 1 раза в 4 часа, хранить не менее одного дня.
    • Автоматизация: VEEAM для полных и инкрементальных копий, платформа Comindware Platform для платформенных копий.
  • Предпродуктивный контур
    • Полные копии: ежемесячно, хранить 1 месяц.
    • Инкрементальные копии: ежедневно (00:00–03:00), хранить последние 15 копий.
    • Копии базы данных: каждые 12 часов, хранить последние 6 копий.
  • Тестовый контур
    • Полные копии: ежемесячно, хранение 1 месяц.
    • Инкрементальные копии: ежедневно (00:00–03:00), хранить последние 15 копий.
    • Копии базы данных: каждые 8 часов, хранить последние 4 копии.

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

Для обеспечения готовности к возможным авариям необходимо регулярно тестировать возможность восстановления системы.

Регулярное тестирование помогает:

  • выявить проблемы в процедурах восстановления до того, как ими придётся воспользоваться;
  • обучить команду порядку действий в нештатных ситуациях;
  • проверить актуальность резервных копий;
  • оценить время восстановления (RTO) и потенциальные потери данных (RPO).

Следует тестировать следующие сценарии восстановления:

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

См. Рекомендации по восстановлению кластера.

Мониторинг состояния системы

В любой конфигурации необходимо обеспечить непрерывный мониторинг работоспособности Comindware Platform в целом и каждого компонента в отдельности.

Эффективный мониторинг помогает:

  • предотвратить сбои до их возникновения;
  • оперативно диагностировать проблемы;
  • оценивать эффективность восстановительных процедур.

Следует предусмотреть следующие средства мониторинга:

  • автоматические уведомления о критических событиях;
  • регулярные проверки состояния компонентов;
  • журнал инцидентов;
  • Мониторинг резервного копирования.

Рекомендации по восстановлению кластера

Фактические пути и имена файлов

При выполнении инструкций будьте внимательны: указывайте фактические имена файлов и пути, которые используются в вашей системе.

Такие имена указаны в угловых скобках, например:

  • <instanceName> — имя экземпляра ПО;
  • <node-ip> — IP-адрес узла.

См. «Пути и содержимое директорий экземпляра ПО».

Общий порядок восстановления

При восстановлении кластера Comindware Platform соблюдайте рекомендованный порядок:

  1. Диагностика проблемы — определите причину сбоя и масштаб повреждений:

    • Проверьте состояние узла с помощью эндпоинта api/health, на работающих узлах он должен возвращать статус 200.
    • Проверьте журналы состояния экземпляра Comindware Platform (heartbeat_*.log).
    • Проверьте журналы Apache Ignite (igniteClient_*.log).
    • Проверьте состояние файловой системы.
    • Проверьте доступность сетевых ресурсов.
    • Проверьте состояние и топологию кластера Apache Ignite со всех узлов.

  2. Запланируйте восстановление:

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

  3. Выполните восстановление: следуйте процедурам для выбранной стратегии. См. Сценарии и порядок восстановления.

  4. Контролируйте работоспособность кластера в процессе и после восстановления:

    • Отслеживайте состояние всех компонентов и сервисов.
    • Контролируйте состояние и топологию кластера Apache Ignite.
    • Анализируйте файловые журналы на предмет наличия ошибок и предупреждений, которые могут помешать восстановлению.
    • Замеряйте производительность системы.
    • Будьте готовы к немедленному откату при необходимости.

Мониторинг во время восстановления

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

  • постоянно контролируйте эндпоинт api/health, на работающих узлах он должен возвращать статус 200;
  • анализируйте журналы состояния Comindware Platform (heartbeat_*.log);
  • контролируйте журнал Apache Ignite (igniteClient_*.log);
  • контролируйте состояние топологии кластера Apache Ignite со всех узлов во время восстановления;
  • контролируйте распределение нагрузки между узлами;
  • контролируйте синхронизацию данных между узлами.

Проверка после восстановления

  • Дождитесь сообщения об окончании ребалансировки кластера в журнале Apache Ignite (igniteClient_*.log):

    INFO Skipping rebalancing (nothing scheduled)

  • Проверьте результирующую топологию Apache Ignite с нескольких узлов.

Критичность компонентов

При планировании, конфигурировании и восстановлении системы следует учитывать значение каждого компонента для работоспособности системы:

  • критичные компоненты: узлы Comindware Platform, Apache Ignite, Apache Kafka, файловое хранилище — нарушение работоспособности может вывести систему из строя;
  • важные компоненты: OpenSearch (Elasticsearch) — нарушение работоспособности не выводит систему из строя;
  • вспомогательные компоненты: мониторинг, дополнительные сервисы — не влияют на состояние системы.

Сценарии и порядок восстановления

Полное восстановление кластера

Полное восстановление накладывает следующие ограничения:

  • требуется полная остановка кластера, система временно утрачивает работоспособность;
  • выполняется восстановление конфигурации и данных всех узлов из резервной копии;
  • кластер снова запускается в полном составе;
  • выполняется синхронизация данных между узлами, что занимает некоторое время;
  • производится последовательный запуск узлов с реконфигурацией кластера.

При отказе всех узлов кластера восстанавливайте его в указанном ниже порядке:

  1. Остановите все службы на каждом узле кластера в следующем порядке: NGINX → API Gateway → Comindware Platform → Apache Ignite.
  2. Восстановите из резервной копии данные и конфигурацию Comindware Platform и служб на одном или нескольких узлах.
  3. Настройте ссылки на общие файлы (например, директорию Scripts), расположенные в файловом хранилище.

  4. Проверьте файлы конфигурации на всех узлах:

    • /usr/share/comindware/configs/instance/<instanceName>.yml
    • /var/www/<instanceName>/adapterhost.yml
    • /var/www/<instanceName>/apigateway.yml
    • /var/www/<instanceName>/ignite.config

  5. Запустите все службы на каждом узле кластера в следующем порядке: Apache Ignite → Comindware Platform → API Gateway → NGINX.

  6. Включите узлы в топологию кластера.

  7. Проверьте синхронизацию данных между узлами: дождитесь сообщения об окончании ребалансировки в файле igniteClient_*.log Apache Ignite:

    INFO Skipping rebalancing (nothing scheduled)

  8. Активируйте кластер.

  9. Проверьте подключение каждого узла к сервисам Apache Kafka и OpenSearch (Elasticsearch).

  10. Проверьте работоспособность кластера:

    • убедитесь, что все узлы возвращают статус 200 на эндпоинте api/health;
    • проверьте время отклика всех узлов;
    • протестируйте балансировку нагрузки.

  11. Выполните проверку целостности данных и работоспособности системы в целом.

Восстановление одного узла кластера

Восстановление одного узла накладывает следующие ограничения:

  • не требуется полная остановка кластера, узел временно выводится из состава кластера;
  • выполняется восстановление конфигурации и данных узла из резервной по необходимости;
  • выполняется возврат узла в состав кластера;
  • выполняется синхронизация данных с другими узлами, что занимает некоторое время.

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

  1. Остановите все службы на узле в следующем порядке: API Gateway → Comindware Platform → Apache Ignite.
  2. Очистите локальную базу данных узла.
  3. Настройте ссылки на общие файлы (например, директорию Scripts), расположенные в файловом хранилище.

  4. Проверьте файлы конфигурации на всех узлах:

    • /usr/share/comindware/configs/instance/<instanceName>.yml
    • /var/www/<instanceName>/adapterhost.yml
    • /var/www/<instanceName>/apigateway.yml
    • /var/www/<instanceName>/ignite.config

  5. Запустите все службы на узле в следующем порядке: Apache Ignite → Comindware Platform → API Gateway.

  6. Выполните реконфигурацию кластера для подключения узла.

  7. Проверьте синхронизацию данных с остальными узлами: дождитесь сообщения об окончании ребалансировки в файле igniteClient_*.log Apache Ignite:

    INFO Skipping rebalancing (nothing scheduled)

  8. Проверьте подключение каждого узла к сервисам Apache Kafka, OpenSearch (Elasticsearch).

  9. Проверьте работоспособность кластера:

    • убедитесь, что все узлы возвращают статус 200 на эндпоинте api/health;
    • проверьте время отклика всех узлов;
    • протестируйте балансировку нагрузки.

  10. Выполните проверку целостности данных и работоспособности системы в целом.

Полезные приёмы

Проверка топологии кластера

  1. Проверьте подключение к Apache Ignite. Для этого выполните на восстановленном и соседнем узлах команду:

    bash /usr/share/ignite/bin/control.sh --baseline

  2. Удостоверьтесь, что топологии совпадают на всех узлах.

Проверка ребалансировки кластера

Удостоверьтесь, что в файле igniteClient_*.log Apache Ignite имеется сообщение об окончании ребалансировки:

``` 
INFO Skipping rebalancing (nothing scheduled) 
```

Блокировка запуска Comindware Platform до сборки кластера

В случае полного восстановления кластера следует заблокировать возможность запуска Comindware Platform до тех пор, пока кластер не будет собран после восстановления.

  1. Создайте файл hold.lock в директории базы данных. Этот файл служит для блокировки передачи запросов из веб-интерфейса Comindware Platform в БД Apache Ignite до завершения ребалансировки узлов.
  2. Удалите файл hold.lock, чтобы снова активировать кластер.

Проверка статуса узла Comindware Platform

  1. Убедитесь, что эндпоинт api/health возвращает статус 200. Проверяйте регулярно, например каждые 30 секунд.
  2. Проверьте время отклика (не должно превышать 5 секунд).
  3. Проанализируйте журналы на предмет ошибок.
  4. Проверьте синхронизацию данных между узлами.

Проверка статуса OpenSearch (Elasticsearch)

  • Используйте эндпоинт /_cluster/health для проверки состояния.
  • Проверяйте состояние индексов и их репликации.
  • Отслеживайте производительность поисковых запросов.

Проверка статуса Apache Kafka

  • Контролируйте состояние топиков и партиций.
  • Отслеживайте задержки обработки сообщений.
  • Контролируйте размер очередей сообщений.

Устранение неполадок

Типовые проблемы при восстановлении

  • Узел не подключается к кластеру Apache Ignite: проверьте сетевое соединение между узлами, конфигурацию Apache Ignite, сетевой экран и сетевые настройки.
  • Ошибки синхронизации данных: проверьте доступность NFS-сервера, права доступа к файлам, состояние дискового пространства, конфигурацию монтирования в /etc/fstab.
  • Проблемы с балансировщиком нагрузки: проверьте конфигурацию балансировщика, доступность эндпоинта api/health, настройки проверки состояния узлов.
  • Проблемы с NFS-монтированием: проверьте доступность NFS-сервера, настройки в /etc/fstab, права доступа к общим директориям.

Журналы для диагностики

В процессе диагностики состояния системы используйте следующие журналы:

  • Основные журналы Comindware Platform:
    • heartbeat_*.log — состояние экземпляра и процесс запуска
    • igniteClient_*.log — подключение к Apache Ignite и ребалансировка кластера
  • Журналы инфраструктуры:
    • Журналы Apache Ignite — состояние кластера хранилища данных.
    • Журналы OpenSearch (Elasticsearch) — состояние кластера журналирования транзакций.
    • Журналы Apache Kafka — состояние очередей сообщений.

Инструменты диагностики

В процессе диагностики состояния системы используйте следующие инструменты:

  • Проверка состояния узлов:

    curl -X GET "http://<node-ip>/api/health"

  • Проверка Apache Ignite:

    bash /usr/share/ignite/bin/control.sh --baseline

  • Проверка OpenSearch (Elasticsearch):

    curl -X GET "localhost:9200/_cluster/health?pretty"

  • Проверка Apache Kafka:

    kafka-topics.sh --bootstrap-server localhost:9092 --list

Практики, которых следует избегать

  • Не игнорируйте резервное копирование: нерегулярное или неправильное резервное копирование данных может осложнить восстановление системы после сбоя.
  • Не пропускайте тестирование восстановления: невыполнение регулярного тестирования процедур восстановления может привести к неготовности к авариям.
  • Не восстанавливайте несколько узлов одновременно: одновременное восстановление нескольких узлов может привести к конфликтам данных.
  • Не игнорируйте реконфигурацию кластера: после восстановления каждого узла необходимо синхронизировать данные в кластере.
  • Не нарушайте порядок остановки и запуска служб: неправильный порядок может привести к повреждению данных или неработоспособности кластера.
  • Не игнорируйте проверки целостности: всегда проверяйте целостность данных после восстановления.

Связанные статьи

‌ К началу

Номер Статьи: 5135
Размещено: Tue, Sep 23, 2025
Последнее обновление: Mon, Oct 6, 2025

Online URL: https://kb.comindware.ru/article/klaster-comindware-platform-vosstanovlenie-posle-avarij-5135.html