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

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

В конфигурации Кластера в параметре coordinators пользователь может перечислить идентификаторы серверов-координаторов. При отказе сервера-координатора, один из работающих серверов кластера автоматически станет координатором.

При запуске кластера(выполнении apply) определение координатора выполняется по полю в конфигурации кластера:

  • Если параметр пустой, то кластер сам определяет координатора по текущей схеме.

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

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

  • Вычислить, кто должен быть координатором по полученной схеме НовыйКоординатор.

  • Если Я-текущийКоординатор == НовыйКоординатор => применить схему как сейчас.

  • Иначе если НовыйКоординатор жив => отправить схему ему, самому ничего не делать. Новый координатор ее сохраняет, обрабатывает и рассылает остальным машинам в кластере.

  • Выполнять предыдущие пункты, пока координатор не будет определен.

Приоритетность при выборе координатора

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

  • Если в кеше есть адрес предыдущего координатора, начинаем опрос с него.

  • Если в кеше ничего нет - CS отправляет запрос на получение адреса или идентификатора координатора на первую попавшуюся машину кластера.

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

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

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

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

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

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

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

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

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

Название параметра

Имя параметра

Default

Min

Максимальное количество в очереди новых для модуля процессов

maxUnprocessedQueueLength

200

10

% превышения количества в очереди новых для модуля процессов

excessUnprocessedQueuePercent

50

5

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

2020-11-12 18:29:15,410 [121] VERBOSE ALL NodeWorkloadCollector - Запрос загрузки очереди сервиса процессов f9a8517a-6dc4-473a-9eb6-35752bc8dfa5 с машины (a833296d-41b6-4a43-8b2d-1a20c174435a, server-address:7800) 2020-11-12 18:29:15,430 [121] VERBOSE ALL NodeWorkloadCollector - Получена загрузка очереди сервиса процессов с машины (a833296d-41b6-4a43-8b2d-1a20c174435a, server-address:7800) : 0%

Формула расчета:

maxUnprocessedQueueLength + (maxUnprocessedQueueLength * excessUnprocessedQueuePercent/100)

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

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

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

  • Свободный сервер в этот момент ничего не обрабатывает.

  • На свободном сервере присутствует сервис процессов.

  • Необработанные сообщения не помещены в очередь сервиса процессов загруженного сервера. Объем доступной памяти сервиса процессов определяется параметром сервера maxUnprocessedQueueLength. Для включения логов по перенаправлению необходимо внести параметры кластера в разделе globalDiagnosticParams: «features»: [«NodeBalancing»].

Примечание

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

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

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

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

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

../_images/redirect_format.png

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

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

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