Введение

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

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

Основные принципы обновления кластера

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

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

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

1. Технологическое окно: для обновления выберите время, когда кластер наименее нагружен.
2. Перенаправьте нагрузку: перед началом обновления перенаправьте весь трафик с обновляемого узла.
3. Обновляйте узлы поочерёдно по одному: обновляйте один узел, пока остальные продолжают работать.

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

• Запланируйте обновление:
• Выберите для обновления период минимальной нагрузки на систему.
• Заблаговременно уведомьте пользователей о предстоящих работах.
• Подготовьте план отката на случай проблем.
• Протестируйте обновление в изолированной среде:
• Создайте тестовую копию кластера.
• Протестируйте обновления.
• Проверьте совместимость обновлённого кластера с существующими данными.
• Контролируйте работоспособность кластера в процессе обновления:
• Отслеживайте состояние всех компонентов и сервисов.
• Замеряйте производительность системы.
• Будьте готовы к немедленному откату при необходимости.

Ключевые этапы обновления

Подготовка к обновлению

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

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

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

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

• Дождитесь сообщения об окончании ребалансировки кластера.
• Найдите в журнале igniteClent*.log сообщение INFO Skipping rebalancing (nothing scheduled).
• Проверьте результирующую топологию Apache Ignite.

Архитектура кластера

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

• cmw-node0 — основной узел пользовательского трафика.
• cmw-node1 — узел мониторинга и поиска.
• cmw-node2 — узел поиска и обработки данных.
• cmw-node3 — основной узел трафика интеграций.

Распределение нагрузки

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

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

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

Например:

Компоненты узлов Comindware Platform

Каждый узел Comindware Platform содержит следующие компоненты:

• Core — экземпляр ПО Comindware Platform.
• Adapters — адаптеры для интеграции с внешними системами.
• Async — асинхронные обработчики, которые выполняют фоновые задачи.
• Apache Ignite — распределённое хранилище данных. Отдельный кластер, см. «Инфраструктура данных».
• NGINX — обратный прокси-сервер, который обрабатывает HTTP-запросы.
• Apache Kafka — брокер сообщений, который обеспечивает межсервисное взаимодействие. Отдельный кластер или облачный сервис.

Пример обновления кластера из четырёх узлов без простоя

Рассмотрим пример обновления кластера Comindware Platform из четырёх узлов без прерывания работы пользователей и интеграций.

Этап 1. Снятие трафика с обновляемого узла

Перенаправим трафик с обновляемого узла cmw-node0 на другие узлы.

1. Удостоверьтесь, что балансировщик верно настроен и при отключении узла трафик будет распределен на остальные узлы.
2. Уберите узел cmw-node0 из списка узлов для балансировки нагрузки.

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

   • Убедитесь, что все запросы обрабатывают оставшиеся узлы.
   • Проверьте, что cmw-node0 не получает новый трафик.
   • Проконтролируйте производительность остальных узлов под увеличенной нагрузкой.

Этап 2. Обновление одного узла

Обновим ПО на выведенном из эксплуатации узле cmw-node0 без влияния на работу системы.

1. Все последующие команды следует выполнять от имени суперпользователя root. Для этого введите команду:

   sudo -s 
   

   или

   su - 
   

2. Скопируйте и распакуйте дистрибутив на общее хранилище и выдайте права на исполнение скриптов. Эту же общую директорию используйте для обновления последующих узлов.

   # Пример: общая директория /mnt/cmw_dist на всех узлах 
   cp </path/to/>X.X-release-ru-<versionNumber>.<osName>.tar.gz /mnt/cmw_dist/ 
   cd /mnt/cmw_dist 
   tar -xf X.X-release-ru-<versionNumber>.<osName>.tar.gz 
   cd /mnt/cmw_dist/CMW*<versionNumber>/scripts/ 
   chmod +x *.sh 
   

3. Установите версию (подготовка версии на узле):

   ./version_install.sh 
   

4. Остановите на узле cmw-node0 сервисы, затрагиваемые обновлением:

   systemctl stop comindware<instanceName> 
   systemctl stop apigateway<instanceName> 
   systemctl stop adapterhost<instanceName> 
   

5. С помощью команды systemctl status <serviceName> удостоверьтесь, что службы остановлены.

6. Выполните обновление экземпляра ПО (укажите имя экземпляра и путь к установленной версии):

   ./instance_upgrade.sh -n=<instanceName> -vp=/var/www/.cmw_version/<versionNumber> 
   

7. Настройте конфигурацию обновлённого ПО (при необходимости) и запустите сервисы:

   systemctl start comindware<instanceName> 
   systemctl start apigateway<instanceName> 
   systemctl start adapterhost<instanceName> 
   

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

   • Убедитесь, что эндпоинт api/health на cmw-node0 выдаёт статус 200.
   • Проверьте подключение к кластеру Apache Ignite.
   • Проверьте корректное завершение ребалансировки.
   • Войдите в систему, откройте несколько списков и карточек объектов.
   • Проверьте работоспособность Apache Kafka: открытие диаграмм процессов, чатов/обсуждений, списка адаптеров и каналов связей.
   • Проверьте OpenSearch (Elasticsearch): историю изменений объектов и процессов.
   • Проверьте работу с файлами: загрузку и скачивание.
   • Проконтролируйте синхронизацию данных с другими узлами.
   • Проанализируйте журналы на предмет наличия ошибок.

9. Балансировщик автоматически включит обновлённый узел в кластер, когда обнаружит статус 200 на эндпоинте api/health на cmw-node0.

Этап 3. Обновление остальных узлов

Аналогично обновлению cmw-node0 обновим оставшиеся узлы cmw-node1, cmw-node2 и cmw-node3 без влияния на работу системы.

1. Выведите обновляемый узел из состава кластера.
2. Выполните обновление ПО.
3. Настройте конфигурацию обновлённого ПО.
4. Запустите сервисы после обновления.
5. Проверьте работоспособность после обновления посредством инструментов мониторинга.
6. Введите обновлённый узел в состав кластера.

Мониторинг и контроль кластера

В процессе и после обновления узлов кластера контролируйте состояние его компонентов:

• Эндпоинт api/health
• Контролируйте состояние узлов Comindware Platform:
  • Статус 200 OK — узел работает корректно.
  • Время отклика не должно превышать 5 секунд.
  • Проверяйте регулярно, например каждые 30 секунд.
• Распределённое хранилище данных Apache Ignite
  • Обеспечивает репликацию данных между узлами, высокую доступность и производительность обработки данных.
  • Проверяйте топологию кластера.
  • Отслеживайте состояние репликации данных.
  • Контролируйте производительность операций чтения и записи.
• Шина сообщений Apache Kafka Обеспечивает межсервисное взаимодействие.
  • Контролируйте состояние топиков и партиций.
  • Отслеживайте задержки обработки сообщений.
  • Проверяйте размер очередей сообщений.
• Хранилище журналов событий OpenSearch (Elasticsearch)
  • Обеспечивает сбор, индексирование и обработку журналов распределённых событий
  • Контролируйте состояние с помощью эндпоинта /_cluster/health.
  • Проверяйте состояние индексов и их репликации.
  • Отслеживайте производительность обработки поисковых запросов.
• Распределённая файловая система (DFS)
  • Общее хранилище файлов может быть реализовано на NFS или S3.
  • Обеспечивает хранение загружаемых пользовательских файлов и других бинарных данных.
  • Контролируйте доступность ресурсов, задержки, пропускную способность, свободное место и квоты.

Оповещения

Настройте оповещения о следующих критических событиях:

• Отказ узла приложения — статус api/health отличается от 200.
• Превышение пороговых значений производительности.
• Ошибки Apache Ignite, Apache Kafka или OpenSearch (Elasticsearch).
• Проблемы с балансировкой нагрузки.
• Критические ошибки в системных журналах.

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

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

• Prometheus + Grafana: мониторинг показателей и визуализация данных.
• Loki: агрегация и анализ журналов.
• Zabbix: комплексный мониторинг инфраструктуры.

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

Для обеспечения оптимальной производительности, минимизации рисков простоев и повышения надёжности, доступности и отказоустойчивости Comindware Platform соблюдайте следующие рекомендации:

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