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

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

В конфигурации Кластера в параметре 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. Если следующий в списке - он сам, то:

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

    2. Если мы работаем без 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»].