Кластер 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 в целом и каждого компонента в отдельности.

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

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

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

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

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

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

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

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

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

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

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

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

Остановите все службы на каждом узле кластера в следующем порядке: NGINX → API Gateway → Comindware Platform → Apache Ignite.
Восстановите из резервной копии данные и конфигурацию Comindware Platform и служб на одном или нескольких узлах.
Настройте ссылки на общие файлы (например, директорию Scripts), расположенные в файловом хранилище.
Проверьте файлы конфигурации на всех узлах:
- /usr/share/comindware/configs/instance/<instanceName>.yml
- /var/www/<instanceName>/adapterhost.yml
- /var/www/<instanceName>/apigateway.yml
- /var/www/<instanceName>/ignite.config
Запустите все службы на каждом узле кластера в следующем порядке: Apache Ignite → Comindware Platform → API Gateway → NGINX.
Включите узлы в топологию кластера.
Проверьте синхронизацию данных между узлами: дождитесь сообщения об окончании ребалансировки в файле igniteClient_*.log Apache Ignite:
INFO Skipping rebalancing (nothing scheduled)
Активируйте кластер.
Проверьте подключение каждого узла к сервисам Apache Kafka и OpenSearch (Elasticsearch).
Проверьте работоспособность кластера:
- убедитесь, что все узлы возвращают статус 200 на эндпоинте api/health;
- проверьте время отклика всех узлов;
- протестируйте балансировку нагрузки.
Выполните проверку целостности данных и работоспособности системы в целом.

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

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

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

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

Остановите все службы на узле в следующем порядке: API Gateway → Comindware Platform → Apache Ignite.
Очистите локальную базу данных узла.
Настройте ссылки на общие файлы (например, директорию Scripts), расположенные в файловом хранилище.
Проверьте файлы конфигурации на всех узлах:
- /usr/share/comindware/configs/instance/<instanceName>.yml
- /var/www/<instanceName>/adapterhost.yml
- /var/www/<instanceName>/apigateway.yml
- /var/www/<instanceName>/ignite.config
Запустите все службы на узле в следующем порядке: Apache Ignite → Comindware Platform → API Gateway.
Выполните реконфигурацию кластера для подключения узла.
Проверьте синхронизацию данных с остальными узлами: дождитесь сообщения об окончании ребалансировки в файле igniteClient_*.log Apache Ignite:
INFO Skipping rebalancing (nothing scheduled)
Проверьте подключение каждого узла к сервисам Apache Kafka, OpenSearch (Elasticsearch).
Проверьте работоспособность кластера:
- убедитесь, что все узлы возвращают статус 200 на эндпоинте api/health;
- проверьте время отклика всех узлов;
- протестируйте балансировку нагрузки.
Выполните проверку целостности данных и работоспособности системы в целом.

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

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

Проверьте подключение к Apache Ignite. Для этого выполните на восстановленном и соседнем узлах команду:
bash /usr/share/ignite/bin/control.sh --baseline
Удостоверьтесь, что топологии совпадают на всех узлах.

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

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

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

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

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

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

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

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

Проверка статуса 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 

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

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