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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Репликация сервера управления

Настройка репликации Центра Настройки выполняется методом POST/api/scheme/controlcenter Сохранить настройки репликации Центра настройки с конфигурацией:

{
        "$type": "DT.Config.ControlCenterReplication.ControlCenterReplicationSettings, DT_Core",
        "replicationNodes": [
        {
                "$type": "DT.Config.ControlCenterReplication.ControlCenterReplicationNode, DT_Core",
                "order": 1,
                "nodeId": "d28268c6-ab48-4d7a-b5d5-8e0618ec8c3a",
                "runControlCenter": true,
                "usedForReplication": true
        },
{
        "$type": "DT.Config.ControlCenterReplication.ControlCenterReplicationNode, DT_Core",
        "order": 2,
        "nodeId": "7f66dec4-78eb-47fc-9635-9f4ea805d3a1",
        "runControlCenter": true,
        "usedForReplication": true
}
],
"folderId": "33333333-3333-3333-0000-000000000000",
"entityId": "96385274-1111-1111-1234-000000000000",
"clusterId": "00000000-0000-0000-0000-000000000000",
"name": "Настройки репликации Центра настройки",
}

где узел с order=1 - мастер-сервер ЦН добавляется в список автоматически при создании первого узла в схеме, остальные узлы нужно добавить вручную. Настройки репликации сохраняются в файле LocalNodeConfig.json на всех узлах.

Механика репликации

  1. В конфигурации настраиваются параметры резервного копирования (по умолчанию 1 минута).

  2. Менеджер узла отслеживает изменения файлов копий:

    • если последнее изменении было более минуты назад, то последний файл нужно реплицировать.

    • если последнее изменение менее 1 минуты назад, то реплицируется предпоследний файл.

  3. При репликации менеджер копирует себе последнюю реплицированную копию в C:\ProgramData\Datareon\Platform\ReplicaBackup. Копирование файла выполняется, только если появился новый бекап конфигурации. В остальных случаях копирование не выполняется.

  4. Узел-приемник (узел, который есть в списке репликации) при несовпадении контрольных сумм запрашивает полную копию у источника. При отправке полной реплики она перед отправкой считывается из файла со сжатием, а при получении распаковывается в файл в C:\ProgramData\Datareon\Platform\ReplicaBackup. Аналогично дифф перед отправкой считывается из файла со сжатием, а при получении распаковывается в файл.

  5. Если на узел выполняется репликация CS, и он не мастер (не первый в списке репликации), менеджер должен запускать периодическую проверку доступности мастер-CS и всех, кто выше него в списке репликации. Если в течение 15 минут мастер недоступен, менеджер должен определять - он ли следующий должен запускать резервную копию CS. Если он следующий в списке, то:

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

    • Если работа производится без Guard:

      1. Остановить CS.

      2. Заменить файл с базой на резервную копию.

      3. Запустить CS вместе с API. Команда DatareonPlatformService.exe restore запускается с правами администратора из папки C:\Program Files(x86)\Datareon\Platform.

  6. Перед тем, как запускать CS, менеджер должен выполнить синхронизацию версий баз конфигураций со всеми машинами, на которых могут быть реплики. Если вдруг у кого-то есть база новее, необходимо сначала выкачать ее себе, затем в зависимости от использования Guard попытаться применить изменения, и в случае успеха - запустить 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%

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

  • Cам свободный узел в этот момент ничего не обрабатывает.

  • На узле есть сервис процессов.

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