Отказоустойчивость

Определение координатора в кластере 

Список приоритетных координаторов 

Приоритетные координаторы – это серверы, которые система в первую очередь рассмотрит в качестве нового координатора кластера. За их настройку отвечает параметр кластера coordinators.

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

Если параметр заполнен, то система выбирает координатора из списка приоритетных, а остальные серверы рассматривает в роли координатора только при недоступности всех серверов, указанных в списке.

Примечание

Порядок перечисления серверов в параметре coordinators не влияет выбор нового координатора.

Порядок определения координатора зависит от сценария.

Сценарий 1. Определение координатора при первом применении конфигурации 

Если конфигурация применяется впервые (например, после первой установки Платформы), то система выбирает координатора по следующим правилам.

Координатором становится мастер-сервер, если:

Параметр coordinators не заполнен (настройка по умолчанию).
Параметр coordinators заполнен, и Id мастер-сервера указан среди приоритетных координаторов.

Координатором становится сервер из списка приоритетных координаторов, если:

Параметр coordinators заполнен, и Id мастер-сервера не указан среди приоритетных координаторов.

Примечание

Если необходимо, чтобы мастер-сервер не выполнял роль координатора при штатной работе, то заполните параметр coordinators, но не добавляйте в него Id мастер-сервера.

Сценарий 2. Определение координатора при изменении конфигурации 

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

Координатор не меняется в следующих случаях:

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

Координатор меняется в следующих случаях:

Параметр coordinators был добавлен в новую конфигурацию, и Id текущего координатора не указан в списке приоритетных.
Параметр coordinators был изменен в новой конфигурации, и Id текущего координатора был удален из списка приоритетных.

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

Сценарий 3. Определение нового координатора, если текущий вышел из строя 

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

Серверы, указанные в параметре coordinators.
Серверы, не указанные в параметре coordinators – если недоступны все серверы из списка приоритетных координаторов.

Алгоритм выбора координатора и отправки новой конфигурации 

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

Если сервер доступен, то он сообщает адрес координатора. В этом случае система отправляет конфигурацию по полученному адресу и сохраняет адрес в памяти.

Если сервер недоступен или не ответил до наступления таймаута, то система поочередно отправляет запрос на остальные серверы кластера.

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

Алгоритм действий сервера при получении новой конфигурации кластера 

Каждый сервер вычисляет, какой из серверов должен быть координатором по полученной схеме (Новый координатор).
Если текущий сервер является Новым координатором, то он применяет новую схему. Если текущий сервер не является Новым координатором, то он направляет схему Новому координатору (если Новый координатор доступен).
После получения схемы Новый координатор сохраняет ее, обрабатывает и рассылает остальным серверам кластера.
Перечисленные действия выполняются до момента успешного применения новой схемы на всех серверах кластера.

Перенаправление веб-сервисов 

Все используемые порты для публикации веб-сервисов и веб-страниц должны быть уникальны в пределах кластера.

На всех серверах кластера выполняется публикация всех зарегистрированных веб-систем и веб-приложений (UI). Если в кластере несколько серверов, то обслуживание каждого сервиса выполняется только одном из серверов, а на остальных серверах кластера выполняется перенаправление на рабочий URL.

Перенаправление процессов с перегруженного сервера 

Настройка механизма 

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

Настройки механизма задаются в блоке параметров кластера nodeParams:

maxUnprocessedQueueLength: максимальное количество новых сообщений в очереди модуля процессов. Значение по умолчанию 200, минимальное значение 10.
excessUnprocessedQueuePercent: процент превышения количества новых сообщений. Значение по умолчанию 50, минимальное значение 5.
maxOtherMachinesQueueLength: максимальный размер очереди сообщений для отправки на другие машины. Если параметр не задан в конфигурации, то система использует значение по умолчанию 200.
collingOffPeriodMs: период охлаждения сообщения, в мс. Если параметр не задан в конфигурации, то система использует значение по умолчанию 30000 (30 секунд).

Параметры maxOtherMachinesQueueLength и collingOffPeriodMs по умолчанию скрыты в конфигурации.

Алгоритм работы механизма 

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

превышен критический порог нагрузки;

доступен менее загруженный сервер;

не превышен лимит MaxOtherMachinesQueueLength;

сообщение не находится в периоде охлаждения;

на принимающем сервере запущен сервис процессов.

Примечание

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

Шаг 1. Определение критической нагрузки

Каждые 20 секунд серверы кластера опрашивают друг друга для определения уровня загрузки сервиса процессов. В журнале фиксируются записи вида:

VERBOSE ALL NodeWorkloadCollector - Запрос загрузки очереди сервиса процессов ...

VERBOSE ALL NodeWorkloadCollector - Получена загрузка очереди сервиса процессов ... : 0%

Критический порог рассчитывается по формуле:

maxUnprocessedQueueLength + (maxUnprocessedQueueLength * excessUnprocessedQueuePercent/100)

При значениях по умолчанию: 200 + (200 * 50 / 100) = 300

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

Шаг 2. Принятие решения о перераспределении

Если текущий сервер перегружен:

выбирается менее загруженный сервер кластера;

часть сообщений передается на него для обработки.

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

Шаг 3. Контроль очереди отправки на другие машины

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

Пример записи в журнале:

Загрузка сервера [...] превышает допустимую.

В очереди сообщений: 71, лимит: 33.

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

В очереди сообщений: 293, лимит: 50.

Приостанавливаем распределение сообщений.

Это предотвращает ситуацию, когда перегруженный сервер начинает дополнительно нагружать другие сервера.

Шаг 4. Очередь обработки сообщений с других машин (fromOther)

Для обработки межузловых сообщений используется отдельная очередь: Очередь обработки сообщений с других машин (fromOther).

Особенности:

является отдельной сущностью;

не входит в общий репозиторий очередей;

хранится в каталоге Data\DatareonNodeManager;

создается при старте сервера;

принимает сообщения независимо от выполнения apply.

Это изолирует межузловой обмен от основной очереди обработки.

Шаг 5. Период охлаждения (CollingOffPeriodMs)

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

Проблема, которую решает параметр

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

Сервер 1 перегружен → отправляет сообщения на Сервер 2.

Сервер 2 в момент получения становится перегруженным.

Сервер 2 пытается отправить сообщение обратно на Сервер 1.

Если нагрузка на Сервере 1 уже снизилась — сообщение отправляется обратно.

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

Как работает механизм охлаждения

Если сообщение возвращается в очередь из-за перераспределения нагрузки, для него устанавливается период охлаждения. В журнале фиксируется запись:

Для сообщения {message} установлен период охлаждения до {date}, отменяем отправку при распределении нагрузки

До истечения периода охлаждения сообщение:

не участвует в повторном распределении;

остается в локальной очереди.

После истечения времени:

сервер повторно оценивает нагрузку;

если исходный сервер больше не перегружен — сообщение может быть отправлено;

если нагрузка сохраняется — сообщение обрабатывается локально.

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

Регистрация перенаправлений 

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

Формат сообщения:

Перенаправление для {EntityIdСистемы\Сервиса, ИмяСервиса\Системы} установлено по адресу {Address}:{Port}

Распределение сервисов и внешних систем 

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

"allocationOptions": {
    "$type": "DT.ClusterConfiguration.Allocation.AllocationOptions, DT_Core",
    "auto": true, //Автоматическое перераспределение сервисов и систем
    "checkPeriodSecond": 300, //Интервал проверки распределения сервисов и систем на серверах
    "moveStandByServer": false, //Перераспределять сервисы и системы у которых указан сервер в конфигурации
    "useDbConnectAddress": true, //Использовать адрес СУБД сервера банков и адаптеров при распределении между серверами
    "useNodePriorityList": false, //Использовать список приоритетных серверов при распределении сервисов
    "nodePriorityList": []//Список приоритетных серверов при перераспределении, в порядке убывания
}