Отказоустойчивость
Определение координатора в кластере
В конфигурации Кластера в параметре coordinators пользователь может перечислить идентификаторы серверов-координаторов. При отказе сервера-координатора, один из работающих серверов кластера автоматически станет координатором.
При запуске кластера(выполнении apply) определение координатора выполняется по полю в конфигурации кластера:
Если параметр пустой, то кластер сам определяет координатора по текущей схеме.
Если параметр заполнен, то кластер пытается сделать координатором один из указанных в массиве серверов, беря их в порядке следования в параметре. Если все не отвечают, то определяем следующего в соответствии с предыдущим пунктом.
Алгоритм действия сервера при получении новой конфигурации кластера:
Вычислить, кто должен быть координатором по полученной схеме НовыйКоординатор.
Если Я-текущийКоординатор == НовыйКоординатор => применить схему как сейчас.
Иначе если НовыйКоординатор жив => отправить схему ему, самому ничего не делать. Новый координатор ее сохраняет, обрабатывает и рассылает остальным машинам в кластере.
Выполнять предыдущие пункты, пока координатор не будет определен.
Приоритетность при выборе координатора
При выборе координатора учитываются следующие моменты:
Если в кеше есть адрес предыдущего координатора, начинаем опрос с него.
Если в кеше ничего нет - CS отправляет запрос на получение адреса или идентификатора координатора на первую попавшуюся машину кластера.
Если машина доступна, то она сообщает адрес координатора. В этом случае конфигурацию отправляем по полученному адресу и кешируем в памяти адрес, кому последнему отправляли конфигурацию для этого кластера.
Если машина недоступна или не ответила до наступления таймаута, то отправляем запрос по очереди на остальные машины.
Если ни одна из машин не сообщает координатора, то высылаем информацию на первую, дальше работает алгоритм из предыдущего пункта.
Если ни одна из машин не доступна, помещаем в очередь и при попытке отправки повторяем все шаги, перечисленные выше.
Перенаправление веб-сервисов
Все используемые порты для публикации веб-сервисов и веб-страниц должны быть уникальны в пределах кластера.
На всех серверах кластера выполняется публикация всех зарегистрированных веб-систем и веб-приложений (UI). Если в кластере несколько серверов, то обслуживание каждого сервиса выполняется только одном из серверов, а на остальных серверах кластера выполняется перенаправление на рабочий URL.
Перенаправление процессов с перегруженного сервера
Механизм перенаправления предназначен для стабилизации работы кластера при критической нагрузке на сервис процессов. Он используется как защитный механизм и не заменяет штатную балансировку.
Все параметры механизма задаются в разделе nodeParams кластера.
Название параметра |
Имя параметра |
Default |
Min |
Максимальное количество новых сообщений в очереди модуля процессов |
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": []//Список приоритетных серверов при перераспределении, в порядке убывания
}