Модуль горячего восстановления

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

Внимание

Использование модуля возможно только при развертывании Платформы в кластерном режиме.

Принцип работы

В архитектуре Платформы каждый сервер кластера:

  • Выполняет обработку сообщений.

  • Содержит собственные очереди сообщений.

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

Модуль горячего восстановления реализует модель репликации многие-ко-многим.

Общий алгоритм работы:

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

  2. Одновременно выполняется синхронная репликация сообщения в резервные очереди на других серверах кластера. Количество реплик определяется параметром faultTolerance.

  3. Все серверы кластера продолжают обрабатывать свои локальные очереди независимо друг от друга.

  4. Реплики сообщений, размещенные на других серверах, не обрабатываются до момента отказа сервера, на котором сообщение было зарегистрировано.

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

Какие данные резервируются

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

К резервируемым данным не относятся:

  • Данные внутренних сервисов Платформы.

  • Журналы событий и логирование обработки сообщений, включая данные, передаваемые на сервер аналитики.

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

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

Обработка сообщений модулем процессов выполняется поэтапно:

  1. Чтение сообщения из очереди для обработки (сообщение при этом остается в очереди).

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

  3. Завершение процесса и удаление сообщения из очереди.

При отказе сервера:

  • Все сообщения с отказавшего сервера считаются необработанными.

  • Обработка этих сообщений запускается на серверах, содержащих их резервные копии.

  • Обработка начинается заново с первого шага процесса.

  • Ранее выполненные внешние действия (например, отправка данных) не откатываются.

Гарантии и ограничения

Гарантии

  • Репликация сообщений между серверами выполняется синхронно.

  • Удаление данных из резервных очередей выполняется синхронно с удалением сообщений из соответствующих очередей серверов-источников.

Ограничения

  • Идемпотентность внешних систем не гарантируется.

  • Возможны дубли сообщений при отказе сервера в момент взаимодействия с внешними системами (например, с 1С или СУБД).

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

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

Настройка

Включение и настройка модуля горячего восстановления осуществляется в конфигурации кластера в режиме редактора конфигурации с помощью параметра faultTolerance.

Все параметры модуля располагаются в разделе hotRecoverySettingsGlobal.

Основные параметры:

  • faultTolerance (integer): количество реплик для каждого сообщения. Значение должно быть меньше количества рабочих серверов кластера. Значение 0 отключает модуль горячего восстановления.

  • nodes (Dictionary<Guid, List>): сопоставление серверов и их резервных серверов. Ключ — сервер, сообщения очередей которого реплицируются. Значение — список серверов, на которых будут размещаться резервные копии.

  • replicateByDefault (boolean): правило репликации по умолчанию для всех сервисов и систем. Если значение true, все сообщения в очередях сервисов и систем будут реплицироваться по умолчанию (кроме исключений в modules). Если значение false, все сообщения в очередях сервисов и систем не будут реплицироваться по умолчанию (кроме исключений в modules).

  • modules (Dictionary<Guid, bool>): исключения из правила replicateByDefault.

  • replicateOnlyWithinNodeGroup (boolean): ограничивает выбор резервных серверов рамками группы серверов.

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

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

  • Его очереди очищаются.

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

  • Обратная синхронизация сообщений не выполняется.

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

Мониторинг состояния

В Центре мониторинга (ЦМ) на вкладке Основные для каждого сервера отображается параметр Горячее восстановление.

Доступные показатели:

  • Состояние: текущее состояние модуля горячего восстановления.

  • FaultTolerance: актуальное значение параметра с учетом количества доступных серверов кластера.

  • Резервные серверы: список серверов, на которых размещены резервные копии очередей данного сервера.

  • Резервные очереди других серверов: количество реплик сообщений, размещенных на данном сервере.

Дополнительно

  • Все операции модуля горячего восстановления выполняются автоматически и не требуют участия администратора.

  • Необходимо обеспечить корректную синхронизацию времени UTC на всех серверах кластера.

  • Рекомендуемое количество серверов в кластере - 3.