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

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

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

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

{
        "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"
}

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

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

В системе предусмотрена возможность создания кластера вручную. Для создания кластера необходимо открыть в меню Обслуживание->Управление конфигурацией и нажать на кнопку Создать кластер. Система откроет окно создания кластера. Пользователь может изменить имя кластера (имя по умолчанию Новый_кластер) и внести изменения в параметры кластера при необходимости. Для схем состоящих из нескольких кластеров необходимо учесть, что параметры apiPort и archiveApiPort должны быть уникальными.

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

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

{
        "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).

При работе с Платформой доступны для подключения следующие модули: - Модуль процессов. - Модуль онтологии. - Модуль репликации. - Банк данных. - Хранилище учетных данных. - Модуль UI (web-интерфейс публикуется на порту, указанному в настройках модуля).

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

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

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

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

#. Нажмите на кнопку Применить конфигурацию. После сообщения об успешном применении конфигурации станет доступен Центр мониторинга, в котором отображается актуальная информация о работе Кластера.

Внимание

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

Чтобы добавить в кластер серверов еще один сервер, в Центре настройки на вкладке Серверы нажмите на кнопку Добавить.

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

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

Внимание

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

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

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

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

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

Для Windows:

DatareonPlatformService.exe SetCS <ip adress>

Для Linux:

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

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