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

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

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

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

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

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

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

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

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

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

Отказоустойчивость Центра мониторинга и администрирования 

Отказоустойчивость ЦМ реализуется совместно с механизмом отказоустойчивости координатора. ЦМ открывается с сервера, который является координатором. Перенаправление на страницу ЦМ сервера-координатора перенастраивается автоматически на других серверах кластера в течение короткого времени после переезда координатора на другой сервер.

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

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

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

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

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

Название параметра	Имя параметра	Default	Min
Максимальное количество в очереди новых для модуля процессов	maxU nprocessedQueueLength	200	10
% превышения количества в очереди новых для модуля процессов	excessUn processedQueuePercent	50	5

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

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

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

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

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

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

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

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

Отказоустойчивость Центра мониторинга и администрирования 

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

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

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

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

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