Общая схема работы 

Создание кластера и сервера 

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

Автоматическое создание кластера и сервера 

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

Ниже представлена конфигурация кластера с набором параметров по умолчанию:

{
        "entityId": "15cb7126-637e-4c0b-a56d-aff3ed7ec819",
        "version": 0,
        "tagsCollection": [],
        "$type": "DT.ClusterConfiguration.Cluster, DT_Core",
        "coordinators": [],
        "heartbeatPeriod": 30000,
        "failThreshold": 3,
        "faultTolerance": 0,
        "apiPort": 7201,
        "archiveApiPort": 7202,
        "snmpPort": 0,
        "useBalancing": true,
        "resolveList": [],
        "processParams": {
        "$type": "DT.MdmCommon.ProcessParams, DT_Core",
        "threadCount": 5,
        "maxSleepingProcessCount": 100,
        "maxSleepingProcessMB": 200,
        "maxUnprocessedQueueMB": 30,
        "minWaitBeforeSleep": 10000,
        "maxRunnedRequests": 50,
        "maxSleepTimeMinutes": 1440
        },
        "commonParams": {
                "$type": "DT.MdmCommon.CommonParams, DT_Core",
                "maxModuleMemoryUsage": 2
        },
                "nodeParams": {
                "$type": "DT.MdmCommon.NodeParams, DT_Core",
                "maxUnprocessedQueueLength": 200,
                "excessUnprocessedQueuePercent": 50
        },
                "globalDiagnosticParams": {
                "$type": "DT.MdmCommon.DiagnosticParams, DT_Core",
                "issueCollectPeriod": 300,
                "minLogLevel": "Info",
                "defaultEventLevel": "Info",
                "eventsLogLevels": {
                        "$type":
        "System.Collections.Generic.Dictionary'2[[DT.Diagnostics.Trace.MessageEventType,
        DT_Core],[DT.Diagnostics.Issues.IssueLevel, DT_Core]], System.Private.CoreLib",
                "AbandonPeekLock": "Debug",
                "Delay": "Verbose",
                "Get": "Verbose",
                "Dequeue": "Verbose",
                "Drop": "Info",
                "Enqueue": "Verbose",
                "Error": "Fatal",
                "LiveTimeExpired": "Info",
                "PeekLock": "Debug",
                "Receive": "Info",
                "CompletePeekLock": "Debug",
                "DefineFunc": "Info",
                "Send": "Info",
                "TrRecv": "Verbose",
                "TrSend": "Verbose",
                "Create": "Info",
                "Transform": "Info",
                "TransportError": "Error"
        },
        "features": []
},
        "cacheSettings": {
                "$type": "DT.MdmCommon.CacheSettings, DT_Core",
                "issuesCacheSettings": {
                        "$type": "DT.MdmCommon.DiagnosticCacheSettings, DT_Core",
                        "metadataRequestFrequency": 60,
                        "stopRequestSendTimeout": 10
        },
        "logsCacheSettings": {
                "$type": "DT.MdmCommon.DiagnosticCacheSettings, DT_Core",
                "metadataRequestFrequency": 30,
                "stopRequestSendTimeout": 10
        },
        "countersCacheSettings": {
                "$type": "DT.MdmCommon.DiagnosticCacheSettings, DT_Core",
                "metadataRequestFrequency": 60,
                "stopRequestSendTimeout": 10
        }
},
"name": "Новый_кластер",
"description": "Новый кластер",
"clusterId": "15cb7126-637e-4c0b-a56d-aff3ed7ec819"
}

Ручной режим создания кластера и сервера 

Создание кластера

При отсутствии кластеров в Платформе предусмотрена возможность создания кластера вручную. Для создания кластера необходимо открыть раздел Обслуживание -> Кластеры и нажать на кнопку +. Пользователь может изменить имя кластера (имя по умолчанию Новый_кластер) и при необходимости внести изменения в параметры кластера (см. раздел Кластеры).

Создание сервера

Ниже представлена конфигурация кластера с набором параметров по умолчанию:

{
        "entityId": "e2d60a94-71fa-4b89-b169-0de593ce7062",
        "version": 0,
        "tagsCollection": [],
        "$type": "DT.ClusterConfiguration.ClusterNode, DT_Core",
        "replicateTo": [],
        "nodeResolveList": [],
        "isActive": true,
        "address": "",
        "port": 7290,
        "controlCenterPort": 7200,
        "serviceKey": "00000000-0000-0000-0000-000000000000",
        "allocationsGlobal": {
                "$type": "DT.ClusterConfiguration.Allocation.AllocationConfig, DT_Core",
                "systems": [],
                "modules": [],
                "disableAutoAssignment": false
        },
        "name": "Сервер",
        "description": "Сервер",
        "clusterId": "cdd60d79-014f-422a-9d0d-6f1c4561c1a9",
        "comment": null,
        "folderId": null
}

Система предоставляет возможность создания нескольких серверов в схеме. При создании схемы из нескольких серверов необходимо учесть, что параметры address, port, controlCenterPort должны быть уникальными. Если в схеме планируется использования нескольких серверов, то необходимо заранее описать правила запуска сервисов, репликации и выбрать координатор. Правила запуска сервисов задаются в блоке параметров allocationsGlobal. Здесь пользователь указывает какие сервисы и системы будут запущены на сервере. Для сохранения работоспособности схемы в целом предусмотрен механизм репликации. Если сервер будет недоступен, сломан и т.д. все указанные сервисы и системы будут запущены на запасном сервере. Для этого необходимо в параметре указать адрес сервера или несколько адресов в параметре replicateTo.

Проверка и применение конфигурации 

Реализовано 3 способа проверки и применения конфигурации:

для проверки конфигурации (не)сохраненной функции (check функции);
для проверки сохраненной, но еще не примененной конфигурации (check кластера);
для проверки с применением конфигурации (apply кластера).

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

Генерируются и компилируются следующие библиотеки:

Библиотека типов.
Типы данных.
Метаданные.
Перечисления.
Интерфейсы.
Группы.
Дополнительные служебные функции и расширения.
Пользовательские методы.
Определение функции.
Входящий/исходящий трансформаторы.
Библиотека функций.
Процессы.
Алгоритмы.
Библиотека маппинга для процессов.
Шаги Установка переменных.
Шаги Запуск БП.
Настройки маппинга в шагах процессов (вкладки Локальные переменные, После выполнения).
Библиотека маппинга для каждого сервиса UI.
Библиотеки обработчиков - для каждой активной системы (кроме 1С) создается своя библиотека с кодом обработчиков, привязанных к этой системе.

Check (Проверка)

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

Проверка процессов и алгоритмов 

Проверка запускается в редакторах процессов и алгоритмов. При этом компилируется библиотека и возвращается результат компиляции. Библиотека типов компилируется только если были изменения в ее объектах. Проверять можно как сохраненные, так и не сохраненные процессы.

При выполнении функции check:

В Центре настройки появляется запись о результате проверки в разделе Обслуживание -> Управление конфигурацией.
В логах сервера Центра настройки в зависимости от успешности проверки:
- При успешной проверке: сообщение о сохранении временной dll с идентификатором.
- При неуспешной проверке: сообщение о допущенной в функции ошибке с указанием места ошибки.

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

Проверка конфигурации 

Проверка запускается в ЦН в разделе Обслуживание -> Управление конфигурацией, либо посредством нажатия на значок в плашке нужного кластера в правом верхнем углу рабочей области ЦН.

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

В Центре настройки появляется всплывающее окно и запись в разделе Обслуживание -> Управление конфигурацией с результатом проверки:
- При успешной проверке Проверка конфигурации прошла успешно!.
- При неуспешной проверке в тексте ошибки перечислены причины.
В логах сервера Центре настройки в зависимости от успешности проверки:
- При успешной проверке и совпадении контрольной суммы с текущей контрольной суммой выводится одно сообщение Проверка конфигурации кластера [идентификатор Кластера].
- При успешной проверке и несовпадении контрольной суммы в процессе проверки происходит сохранение dll конфигурации. Начало проверки - Проверка конфигурации кластера [идентификатор Кластера]. Окончание проверки - Выполнена проверка конфигурации кластера [идентификатор Кластера].
- при неуспешной проверке в логах сообщения выводится сообщение о допущенной в функции ошибке с указанием места ошибки.
При выполнении действия check из очереди учитываются сохраненные изменения, т.е. действие из очереди выполняется на той конфигурации, которая актуальна на момент начала выполнения, а не на момент вызова этой операции.

Применение конфигурации (Apply)

В логах сервера управления в зависимости от успешности проверки.
- При успешной проверке и совпадении контрольной суммы происходит проверка, применена ли конфигурация, и выводится сообщение с актуальной версией. Если не применена - применяется.
- Начало применения: Применение нового состояния метаданных для кластера [идентификатор Кластера].
- Регистрация конфигурации на применение: Обновление актуальной конфигурации в хранилище.
- Завершение проверки конфигурации на применение и ее сохранение: Обновление актуальной конфигурации в хранилище завершено успешно.
- Окончание действия apply: Настройки репликации Центра настройки успешно применены. Версия ххх.
- При успешной проверке и несовпадении контрольной суммы происходит сохранение dll конфигурации и применение конфигурации. Начальное и конечное сообщение в логах как в прошлом пункте.
- При неуспешной проверке выводится сообщение начала действия apply, сообщения о сохранении dll конфигурации и об ошибке.
В логах узла присутствуют записи только об успешных конфигурациях.
- При совпадении версии с предыдущей. действия apply: Поступило ping сообщение от ControlServer.
- Окончание действия apply: Применение конфигурации сети, версия ххх.
- При несовпадении версии с предыдущей происходит запуск необходимых компонентов.
В Центре настройки запись об успешном применении появляется в момент передачи стабильной конфигурации на применение в Node. Это значит, что конфигурация скомпилирована, но еще не применена на узлах. В Центре настройки появляется всплывающее окно и запись в разделе Обслуживание с результатом проверки:
- При успешной проверке: Применение конфигурации прошло успешно!.
- При неуспешной проверке в тексте ошибки перечислены причины.
В Журнале действий пользователя (при использовании Guard - в журнале Guard) сохраняется применение стабильной конфигурации для кластера и центров настройки (настройки репликации).

Если предыдущая компиляция еще не завершена, при многократном запуске apply конфигурация нового применения отличается от выполняемой в данный момент. При этом происходит отмена предыдущей компиляции и начинается компиляция по последнему запуску проверки.

Проверка компиляции маппинга и обработчиков происходит после успешной компиляции библиотеки основных объектов. Т.е. если есть ошибка в маппинге, и при этом допущены более серьезные ошибки (для переменной используется несуществующий тип данных или удалена вложенная функция), то при проверке сначала отобразятся эти более серьезные ошибки (так как для компиляции всех прочих библиотек библиотека функций должна скомпилироваться успешно). И только после их устранения будет выдано сообщение об ошибке маппинга, обработчиков или процессов. После успешной компиляции Центр настройки передает обновленную конфигурацию на координатор для рассылки и применения на узлах. Узлы при получении команды на обновление конфигурации сначала сравнивают номера версий (полученной и фактической) и запускают процесс обновления только в случае их отличия. Кроче того, если узел получает новую версию конфигурации в момент перезапуска, обновление останавливается и снова запускается процесс обновления уже по последней версии.

Устранение ошибок обновления 

Откат на предыдущую версию конфигурации

В Центре настройки возможен отказ на примененную ранее конфигурацию с помощью метода post/api/{clusterId}/metadata/restoreStable. При этом все сохраненные и непримененные изменения будут удалены.

Внимание

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

Рассинхронизация версий

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

Обновление от неизвестного Центра настроек

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

Для Windows:

DatareonPlatformService.exe SetCS <ip adress>

Для Linux:

sudo /usr/bin/datareon/platform DatareonPlatformService setCS <ip adress>

После выполнения команды требуется отправить обновление повторно.

Список стандартных портов и swagger-ов 

В таблице ниже указаны стандартные порты, используемые разными подсистемами Платформы.

Стандартные порты подсистемы Платформы
Имя	Протокол	По умолчанию	Назначение	Описание
Guard или Security	https	7203	При использовании Guard через установщик	https://hostname:7203 Управление пользователями конфигурации и настройками доступа к объектам конфигурации
Центр настройки	https	7201	При установке Платформы через установщик	https://hostname:7200 Управление конфигурацией
Центр мониторинга	https	7200	Конфигурация кластера через Центр настройки	https://hostname:7201 Оперативное состояние всех сервисов системы – доступно только после настройки конфигурации
SNMP узла	snmp	windows - 162;linux - 7295	Конфигурация кластера через Центр настройки (поле snmpPort)	Счетчики для мониторинга работы системы с помощью сторонних средств
Рассылка данных для 1С (узел)	UPD	5557	Запускается сам при старте узла	Не настраивается. По UDP выполняется рассылка для ИБ 1С, подключенных к системе.
Рассылка данных для 1С (узел)	TCP (сервер)	7928	Запускается сам при старте узла	Не настраивается. ИБ 1С подключаются по TCP для получения актуальной конфигурации коннектора.
Клиентская часть UI	http(s)	нет	Центр настройки - Сервисы - Создать сервис UI	http://hostname:port или https://hostname:port. Веб-приложение для пользователей в соответствии с настройками административной панели UI.
Веб-адаптеры	http(s)	нет	Центр настройки - Потребители Системы - Создать систему с конфигурацией WebSystemConfig	http://hostname:port или https://hostname:port. Документация к сервисам публикуется на http://hostname:port/swagger или https://hostname:port/swagger

В таблице ниже указаны стандартные порты, используемые Transport Platform:

Стандартные порты Transport Platform
Имя	Протокол	По умолчанию	Назначение	Описание
Центр настройки	https	7205	При установке Transport Platform через установщик	https://hostname:7205 Управление конфигурацией
Центр мониторинга	https	7206	Конфигурация через Центр настройки	https://hostname:7206 Оперативное состояние всех сервисов системы – доступно только после настройки конфигурации
Веб-адаптеры	http(s)	нет	Центр настройки - Потребители Системы - Создать систему с конфигурацией WebSystemConfig	http://hostname:port или https://hostname:port. Документация к сервисам публикуется на http://hostname:port/swagger или https://hostname:port/swagger

Схема подключения всех сервисов по TCP/Pipe 

После установки программы запускается служба DatareonPlatform, а также Центр настройки (ControlCenter) и сервис Менеджер узла (Node). Для Центра настройки доступны методы API для настройки Платформы, а также настройка через интерфейс (порт 7200). Для Менеджера узла доступно диагностическое API (порт 7201) и API в Swagger по описанию методов узла (порт 7202, https://localhost:7202/swagger/index.html).

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

Процесс
Банк данных
Управление пользователями
Веб-интерфейс (web-интерфейс публикуется на порту, указанному в настройках сервиса)
Хранилище сообщений
Онтология
Другое

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

Защита данных с помощью протокола SSL 

В Платформе реализована функциональность протокола SSL для TCP-подключений, которая обеспечивает шифрование данных, передающихся между серверами кластера. При этом используются SSL-сертификаты, установленные на каждом сервере Платформы (может использоваться сертификат, сформированный установщиком Платформы, или добавленный при помощи команды установки сертификата). Для успешной работы функциональность должна быть включена на каждом сервере кластера.

Для управления функциональностью используются следующие аргументы для исполняемого файла DatareonPlatformService.exe в Windows и platformmanager в Linux:

useSsl: включает использование протокола SSL для TCP-соединений между серверами.
unUseSsl: выключает использование протокола SSL для TCP-соединений между серверами.

Внимание

Перед изменением настроек требуется остановить работу службы Платформы.

Настройка серверов в кластере 

Для настройки кластера из нескольких серверов:

Произведите установку приложения Datareon Platform на все устройства, на которых планируется разместить серверы Платформы.
Выберите устройство на котором будет располагаться Центр настройки всего кластера. Все настройки будут производиться в Центре настройки выбранного устройства.
Откройте Центр настройки по адресу выбранного устройства. Адрес Центра настройки по умолчанию: https://ip-adress:7200/. В Центре настройки отобразится окно создания конфигурации кластера.
В окне создания конфигурации выберите опцию Создать новую конфигурацию и подтвердите свой выбор. Автоматически произойдет создание кластера, сервера и сервиса обработки процессов.
Нажмите на кнопку Применить конфигурацию. После сообщения об успешном применении конфигурации станет доступен Центр мониторинга, в котором отображается актуальная информация о работе кластера.

Внимание

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

Чтобы добавить в кластер серверов еще один сервер, в Центре настройки на вкладке Серверы нажмите на кнопку Добавить.
На странице добавления нового сервера указать адрес устройства, на котором установлена Платформа и порт сервера этого экземпляра Платформы. По умолчанию при установке Платформы порт сервера 7290.
Вписать любые Название и Имя по своему выбору.
Установить флажок Включен.
Сохранить и применить конфигурацию.

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

Внимание

Центр мониторинга всегда публикуется по адресу сервера-координатора. После того как вы добавили второй сервер в кластер, координатор может измениться, и Центр мониторинга может публиковаться по адресам как одного, так и другого сервера в зависимости от того какой из них будет координатором. По этому для открытия Центра мониторинга воспользуйтесь кнопкой Центр мониторинга на вкладке Управление конфигурацией.

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

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

Управление сервером с неизвестного Центра настройки.

Если на Сервер придет запрос от Центра настройки, который находится по адресу не в списке доверенных, то Сервер не примет запрос и в ответ отправит сообщение с ошибкой. В Центре настройки отобразится ошибка: В списке зарегистрированных Центров настроек на сервере отсутствует адрес сервера Центра настройки. Чтобы на сервере-координаторе добавить адрес Центра настройки в список доверенных, на устройстве сервера-координатора в командной строке выполните команду:

Для Windows:

DatareonPlatformService.exe SetCS <ip adress>

Для Linux:

sudo /usr/bin/datareon/platform DatareonPlatformService setCS <ip adress>

После выполнения команды требуется применить конфигурацию Центра настройки повторно.