4. Настройка программы

4.1. Настройка на состав технических средств

4.1.1. Общие требования

Предъявляются следующие общие обязательные требования:

созданы все виртуальные машины согласно схеме развертывания;
операционная система на базе Linux (kernel 3.10 и yum/rpm). В данном документе описание на примере CentOS 7.8;
организован доступ к пользователю root/технологическому пользователю с правами sudo на серверах;
имена хостов (FQDN) серверов могут взаимно получать IP по имени со всех машин;
на всех серверах установлены пакеты:

«Python 2» (version 2.7);
«libselinux-python».

на всех серверах установлен сервис синхронизации времени;
хранилище «centos-extras» включено;
в случае работы с RHEL/CentOS 7.8 со всех машин в кластере обеспечен доступ к официальному репозиторию «CentOS Extras» (например, http://centos-mirror.rbc.ru/pub/centos/7/extras/x86_64/ или создано локальное зеркало);
в случае работы с RHEL/CentOS 7.8 со всех машин в кластере обеспечен доступ к официальному репозиторию «CentOS Updates» (например, http://centos-mirror.rbc.ru/pub/centos/7/updates/x86_64/ или создано локальное зеркало);
в случае работы с RHEL/CentOS 7.8 со всех машин в кластере обеспечен доступ к официальному репозиторию «CentOS Base» (например, http://centos-mirror.rbc.ru/pub/centos/7/os/x86_64/ или создано локальное зеркало).
смонтирован диск большого объема (выделенный под данные) на тех серверах, для которых требуется большой объем данных. По умолчанию диск монтируется в /opt.

4.1.2. Общие требования для развертывания ProStore

наличие одной или нескольких выделенных и обособленных одноранговых Interconnect-сетей под цели внутренней коммуникации кластера;
все сервера кластера должны быть подключены к Interconnect-сетям, для серверов должны быть назначены адреса, и должно быть настроено соединение между всеми серверами кластера;
скорость Ethernet от 1 Гб/с (стандартом является 10 Гб/с);
отсутствие firewalls и другого ПО, блокирующего или замедляющего трафик;
внутри кластера должна быть открыта коммуникация по всем портам;
доступность проверки целостности и качества соединений (Ping) для всех серверов (ICMP);
сервисы firewalld и SELinux не должны контролироваться системой управления конфигурации (при ее наличии), поскольку они должны быть доступны процессу установки ADS, ADB и ADQM для остановки и выключения;
создание новых сервисов не должно контролироваться системой управления конфигурации (при ее наличии), поскольку оно должно быть доступно процессу установки ADS, ADB и ADQM.

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

наличие доступа для серверов ADS и ADB к ПО ADCM, предварительно развернутому в сети организации на выделенном сервере;
наличие доступа для серверов ADB к следующим официальным репозиториям Arenadata или созданным локальным зеркалам:

ADB: https://downloads.arenadata.io/ADB/<ADB_version>/centos/7/community/$basearch;
Arenadata Monitoring: https://downloads.arenadata.io/ADM/<ADM_version>/centos/7/community/$basearch/.

наличие доступа для серверов кластера ADQM к следующим официальным репозиториям Arenadata или созданным локальным зеркалам:

наличие доступа для серверов кластера ADG к официальному репозиторию Arenadata ADG или созданному локальному зеркалу;
наличие доступа для сервера ProStore к официальному репозиторию Arenadata ProStore или созданному локальному зеркалу.

4.1.3. Требования к серверу ProStore

Необходимо не менее 20ГБ свободного пространства.

4.1.4. Требования к серверу «Менеджер кластера ADCM»

Требуется виртуальная или физическая машина с операционной системой на базе Linux (kernel 3.10 и yum/rpm). В данном документе описание на примере CentOS 7.8;

Необходимо не менее 5 ГБ свободного пространства в директории /home.

4.1.5. Требования к кластеру серверов «ADQM»

снаружи кластер должен быть доступен по следующим портам:

22 (ssh);
8123 (HTTP-интерфейс Clickhouse);
8000 (ADCM).

Clickhouse-cервера должны быть доступны по портам 9000, 8123, 9009 внутри кластера;
для отправки метрик на сервер мониторинга к нему должно быть разрешено подключение серверов кластера (по умолчанию 2015/tcp, 2016/udp);
для отправки статусов компонентов кластера в ADCM к нему должно быть разрешено подключение серверов кластера (по умолчанию порт 8000).

4.1.6. Требования к кластеру серверов «ADS»

На серверах должен быть настроен протокол NTP;
следующие файлы не должны контролироваться системой управления конфигурации (при ее наличии), поскольку они должны быть доступны процессу установки для создания и модификации:

/etc/hosts
/etc/selinux/config
/etc/sysctl.conf
файлы директории /usr/lib/systemd/system/;

в кластерe должны быть открыты порты, представленные в таблице ниже (см. tab_gost_6).

Перечень сетевых портов, используемых серверами ADS
Номер порта	Описание использования порта
22	SSH
81	(при установке ADS без подключения к сети Интернет) TCP-порт репозиториев Arenadata Enterprise Tools
2015	TCP-порт для отправки метрик на сервер мониторинга
2016	Udp-порт для отправки метрик на сервер мониторинга
8000	TCP-порт для отправки статусов компонентов кластера в ADCM
2181	Порт доступа к сервису ZooKeeper
2888	Порт межсерверного взаимодействия для компонентов кворума ZooKeeper
3888	Порт межсерверного взаимодествия для компонентов кворума ZooKeeper
9092	HTTP-порт доступа к сервису Kafka
9093	HTTPS-порт доступа к сервису Kafka
8081	Порт доступа к сервису Schema-Registry
8082	Порт доступа к сервису Kafka REST Proxy
8088	Порт доступа к компоненту KSQL Server
9898	Порт доступа к сервису Kafka-Manager
9997	JMX-порт для доступа к метрикам сервисa Schema-Registry
9998	JMX-порт для доступа к метрикам сервисa Kafka REST Proxy
9999	JMX-порт для доступа к метрикам сервиса Kafka

4.1.7. Требования к кластеру серверов «ADB»

Снаружи кластер должен быть доступен по следующим портам:
- 22 (ssh);
- 5432 (входящий интерфейс postgresql);
для доступа к серверам точного времени для мастер-серверов должен быть открыт доступ по порту 123/udp;
для отправки метрик на сервер мониторинга к нему должно быть разрешено подключение серверов кластера (по умолчанию 2015/tcp, 2016/udp);
для отправки статусов компонентов кластера в ADCM к нему должно быть разрешено подключение серверов кластера (по умолчанию порт 8000/tcp);
следующие файлы не должны контролироваться системой управления конфигурации (при ее наличии), поскольку они должны быть доступны процессу установки для создания и модификации:
- /etc/fstab;
- /etc/hosts;
- /etc/hostname;
- /etc/chrony.conf;
- /etc/ssh/sshd_config;
- /etc/selinux/config;
- /etc/security/limits.conf;
- файлы директории /usr/lib/systemd/system/;
- файлы директории /etc/cgconfig.d/.

4.1.8. Требования к кластеру серверов «ADG»

для отправки метрик на сервер мониторинга к нему должно быть разрешено подключение серверов кластера (по умолчанию 2015/tcp, 2016/udp);
снаружи кластер должен быть доступен по порту 22 (ssh);
наличие библиотеки glibc версии 2.17-260.el7_6.6 или выше.

4.1.9. Требования к серверу «СМЭВ3 коннектор»

На серверах должен быть настроен протокол NTP;
следующие файлы не должны контролироваться системой управления конфигурации (при ее наличии), поскольку они должны быть доступны процессу установки для создания и модификации:

/etc/hosts;
/etc/selinux/config;
/etc/sysctl.conf;
/usr/lib/systemd/system/;
/etc/sysconfig/iptables\*;
/etc/firewalld/\*;
/etc/docker/\*.

Снаружи сервер должен быть доступен по следующим портам:

22 (ssh);

Необходим сетевой доступ до сервера СМЭВ. Например, если используется адрес http://smev3-n0.test.gosuslugi.ru:5000/transport_1_0_2/, необходимо организовать доступ
Если для шифрования и подписи сообщений используется КриптоПро JCP 2.0.41618.
Необходимо так же подготовить ключи (контейнер) для КриптоПро и лицензию на JCP. В случае отсутствия лицензии будет использоваться пробная лицензия.
Если для оформления цифровой подписи используется VipNet PKI необходимо обеспечить сетевой доступ до его сервера.

4.1.10. Требования к серверу «Агент ПОДД»

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

/etc/hosts;
/etc/selinux/config;
/etc/sysctl.conf;
/usr/lib/systemd/system/;
/etc/sysconfig/iptables\*;
/etc/firewalld/\*;
/etc/docker/\*.

Снаружи сервер должен быть доступен по следующим портам:

22 (ssh);

Необходим сетевой доступ до сервера ПОДД. Например, если
используется адрес http://smev3-n0.test.gosuslugi.ru:5000/transport_1_0_2/, необходимо организовать доступ до хоста smev3-n0.test.gosuslugi.ru по порту 5000.

4.1.11. Требования к серверу «ETL»

На серверах должен быть настроен протокол NTP;
Следующие файлы не должны контролироваться системой управления конфигурации (при ее наличии), поскольку они должны быть доступны процессу установки для создания и модификации:

/etc/hosts;
/etc/selinux/config;
/etc/sysctl.conf;
/usr/lib/systemd/system/;
/etc/sysconfig/iptables\*;
/etc/firewalld/\*;
/etc/docker/\*.

Должны быть открыты порты, представленные в таблице ниже (см. tab_gost_7).

Перечень сетевых портов, используемых серверами ETL
Номер порта	Описание использования порта
22	SSH
8080	TCP-порт, WEB - интерфейс для Apache Spark master
6066	TCP-порт, отправка задач в кластер через rest api для Apache Spark master
7077	TCP-порт, отправка задач в кластер регистрация исполнителей Apache Spark worker для spark master
8081	TCP-порт, WEB-интерфейс Apache Spark worker
8080	TCP-порт, WEB – интерфейс Apache Airflow
5555	TCP-порт, мониторинг задач Apache Airflow
5432	TCP-порт, Airflow Postgres для хранения метаданных
6379	TCP-порт, Redis для хранения очередей

4.1.12. Требования к серверу конечных точек

На серверах должен быть настроен протокол NTP;
следующие файлы не должны контролироваться системой управления конфигурации (при ее наличии), поскольку они должны быть доступны процессу установки для создания и модификации:

/etc/hosts;
/etc/selinux/config;
/etc/sysctl.conf;
файлы директории /usr/lib/systemd/system/;
/etc/sysconfig/iptables\*;
/etc/firewalld/\*;
/etc/docker/\*.

Снаружи сервер должен быть доступен по следующим портам:
- 22 (ssh)
- 8080

4.2. Настройка на состав программных средств

Установка витрины данных производится без необходимости доступа к сети «Интернет» для скачивания компонент.

4.2.1. Создание технологического пользователя

Для корректной работы в процессе установки программного обеспечения необходимо:

Создать технологического пользователя с правами «sudo» на всех серверах.
Выдать технологическому пользователю на всех серверах право выполнять через «sudo» команды от имени пользователей root и gpadmin.
Выдать технологическому пользователю право без пароля использовать «sudo». Если такой возможности нет, необходимо создать одинаковый пароль. В этом случае при запуске ansible-playbook ``необходимо будет указать ключ ``-K и задавать пароль пользователя для использования sudo.
На сервере ADCM сгенерировать пару закрытого и открытого ключа для данного пользователя.
Разместить на остальных серверах открытый ключ

4.2.2. Установка Менеджера кластера ADCM

Сервер «Менеджер Кластера» – сервер, с которого будет централизованно производиться установка почти всех компонентов витрины. Данный компонент обязателен для установки.

ADCM – программное обеспечение, распространяемое в виде образа докеров. У вас должен быть Докер или совместимый движок контейнеров, чтобы запустить ADCM. Текущая версия программного обеспечения не совместима с SELinux.

Подробная инструкция по установке Менеджера кластера ADCM приведена в документации к ПО Менеджера кластера ADCM (https://docs.arenadata.io/adcm/user/install.html ). Список основных объектов ADCM приведен в приложении 1. Таблица 8 – Основные объекты ADCM

Установка ПО ADCM осуществляется технологическим пользователем согласно следующим этапам:

Выключить selinux. В файле /etc/selinux/config установить значение SELINUX=disabled, перезапустить сервер командой reboot now

Установить докер согласно его документации, спользуйте следующие команды:

yum-config-manager --add-repo
https://download.docker.com/linux/centos/docker-ce.repo
yum install -y containerd.io
yum install -y docker-ce-3:18.09.1-3.el7
systemctl enable docker
systemctl start docker

Установить ПО ADCM в докере командами:

docker pull arenadata/adcm:latest

docker create --name adcm -p 8000:8000 -v /opt/adcm:/adcm/data
arenadata/adcm:latest

Запустить ADCM командой:
```
docker start adcm
```
Открыть браузер и перейти по адресу http: // <ip_of_your_server>: Пользователь по умолчанию - admin, пароль - admin.

4.2.3. Установка ADQM

Подробная инструкция по установке СУБД ADQM приведена в документации к СУБД ADQM и СУБД ClickHouse (https://docs.arenadata.io/adqm/install/adcm/ru/index.html , https://clickhouse.tech/docs/ru/getting-started/install/ ).

Создать не менее трёх виртуальных машин для кластера ClickHouse (используйте гипервизор (монитор виртуальных машин)).
Установить ClickHouse на каждом узле кластера под профилем пользователя root с помощью команд:

rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPG
yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/stable/x86_64
yum install -y clickhouse-server-20.4.4.18-2 clickhouse-client-20.4.4.18-2

Запустить сервер следующей командой:
```
systemctl start clickhouse-server
```
Выполнить настройку среды

В конфигурационный файл каждого сервера ClickHouse, размещенным по относительному пути /etc/clickhouse-server/config.xml, внести описание конфигурации кластера ClickHouse и Zookeeper в следующем формате (на примере конфигурации ClickHouse из одного шарда и двух реплик):

<remote_servers incl="clickhouse_remote_servers" >
         <cluster>
           <shard>
               <replica>
                   <host>bdv-adqm-1.ru-central1.internal</host>
                   <port>9000</port>
               </replica>
           </shard>
           <shard>
               <replica>
                   <host>bdv-adqm-2.ru-central1.internal</host>
                   <port>9000</port>
               </replica>
           </shard>
       </cluster>
   </remote_servers>

Пример конфигурации ClickHouse из двух шардов и двух реплик:

<remote_servers incl="clickhouse_remote_servers" >
    <!-- Test only shard config for testing distributed storage -->
    <cluster>
        <shard>
            <replica>
                <host>bdv-adqm-1.ru-central1.internal</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>bdv-adqm-2.ru-central1.internal</host>
                <port>9000</port>
            </replica>
        </shard>
        <shard>
            <replica>
                <host>bdv-adqm-3.ru-central1.internal</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>bdv-adqm-4.ru-central1.internal</host>
                <port>9000</port>
            </replica>
        </shard>
      </cluster>
    </remote_servers>

Пример указания кластера Zookeeper из трёх нод:

<zookeeper>
    <node index="1">
        <host>bdv-zookeeper-1.ru-central1.internal</host>
        <port>2181</port>
    </node>
    <node index="2">
        <host>bdv-zookeeper-2.ru-central1.internal</host>
        <port>2181</port>
    </node>
    <node index="3">
        <host>bdv-zookeeper-3.ru-central1.internal</host>
        <port>2181</port>
    </node>
    <session_timeout_ms>30000</session_timeout_ms>
</zookeeper>

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

Например, доступ с любого адреса (IPv4, IPv6):

<yandex>
   <listen_host>::</listen_host>
</yandex>

Перезапуск СУБД командой:
```
systemctl restart clickhouse-server
```

Проверить успешность завершения установки СУБД ADQM:

Проверить логи СУБД ADQM по относительному пути:

/var/log/clickhouse-server/
Проверить удалённое подключение с помощью http-запроса:
```
curl 'http://10.92.3.13:8123/ping'
```
Проверить работу СУБД ADQM работает в кластерном режиме, путём запуска клиента командной строки ClickHouse, создания тестовой таблицы SQL-запросом через клиента:
```
$ clickhouse-client
CREATE DATABASE test1 ON CLUSTER <имя_кластера>
```

Результатом выполнение команды будет сообщения об успешном выполнении запроса Настройка ПО ADQM ~~~~~~~~~~~~~~~~~

Инструкция по настройке СУБД ADQM приведена в официальной документации к СУБД ADQM и СУБД Clickhouse (https://docs.arenadata.io/adqm/expand/adcm/ru/index.html , https://clickhouse.tech/docs/ru/operations/configuration-files/ ).

4.2.4. Установка Диспетчера сообщений ADS

ПО Диспетчера сообщений ADS разворачивается на кластере с помощью ADCM из загруженного установочного пакета (бандла).

Скачать установочный пакет (версия: ads_v1.6.0.0-1) можно с сайта разработчика: https://store.arenadata.io/#products/arenadata_streaming.

Подробная инструкция по установке Диспетчера сообщений приведена в официальной документации к ПО Диспетчера сообщений (https://docs.arenadata.io/DTM/Install/ADS.html , https://docs.arenadata.io/ads/Install/index.html ). В данной инструкции описывается установка кластера Kafka и импорт уже установленного кластера Zookeeper. Установка ПО Zookeeper на кластер приведена в инструкции по установке ADQM.

Для создания кластера необходимо иметь предварительно загруженный бандл (версия: ads_v1.6.0.0-1). В графическом интерфейсе ADCM осуществить переход в раздел CLUSTERS -> Create cluster.
В разделе Services графического интерфейса ADCM необходимо добавить сервисы в созданный кластер.
В случае, если Kafka и Zookeeper разворачивается в одном кластере, необходимо добавить сервис Zookeeper.
В разделе Hosts графического интерфейса ADCM указать серверы созданного кластера, на которых будет развёрнуто ПО ADS.
В разделе Hosts - Components указать три узла (ноды) Kafka.
Указать кластер Zookeeper в разделе Import, в случае если Zookeeper находится на другом кластере.
Нажатием программной кнопки InstalL инициировать процесс установки. В новом окне с дополнительными параметрами – нажатием программной кнопки Run запустить установку.
Проверить успешность завершения установки:

Проверить лог-файл Zookeeper по относительному пути:
```
/var/log/zookeeper/.
```
Проверить лог-файл Kafka по относительному пути:

/var/log/kafka/.
Проверить настройки подключения к кластеру Zookeeper с помощью сторонней утилиты KafkaTool.
Проверить корректность разрешения имен серверов для автоматического определения bootstrap-серверов Kafka. При отсутствии DNS-севера прописать в локальный hosts адреса Kafka.
Определить путь chroot path, запустив на любом сервере Zookeeper команду:
```
/usr/lib/zookeeper/bin/zkCli.sh
```

После выполнить команду:

ls     /arenadata/cluster.

При проверке, в данном руководстве, использовался графический интерфейс приложения Offset Explorer 2.1 (https://www.kafkatool.com/download.html).

4.2.5. Настройка Диспетчера сообщений ADS

Инструкция по настройке Диспетчера сообщений ADS через Менеджер кластера ADCM приведена в официальной документации к ПО Менеджера кластера ADCM (https://docs.arenadata.io/ads/AdminGuide/Config_ADCM.html ).

4.2.6. Установка ПО ADB

Подробная инструкция по установке СУБД ADB приведена в документации к СУБД ADB (https://docs.arenadata.io/DTM/Install/ADB.html).

Для установки кластера ADB посредством ADCM необходимо выполнить следующие шаги:

Установить ADCM (см. п.3.2.3);
Создать хосты для кластера ADB:
Загрузить выбранный бандл хоста (версия: ADB 6.15, ссылка для скачивания https://store.arenadata.io/#products/arenadata_db ).
Открыть в графическом интерфейсе ADCM раздел “BUNDLES”. Нажать программную кнопку “Upload bundle” и в открывшейся экранной форме выбрать файл бандла ADB. Проверить отображение факта успешной загрузки в общем списке бандлов на вкладке “BUNDLES”.

Для установки понадобится один или более хост для размещения мастера, резервного мастера и сегментов.

В графическом интерфейсе ADCM перейти в раздел CLUSTERS -> Create cluster. Создать кластер.
Добавить сервисы ADB и PXF на созданный кластер.

Примечание

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

В диалоговом окне Add service указать сервис PXF (данный сервис доступен только в версии «Arenadata Enterprise») как подлежащий к установке;
В диалоговом окне Add service не указывать сервис ADB to Kafka (данный сервис доступен только в версии «Arenadata Enterprise») как подлежащий установке.

В разделе Hosts указать серверы, на которых будет развёрнут кластер ADB.
В разделе Hosts - Components указать назначение узлов: master ставится на один узел, segment на два других узла,
PXF - на все узлы.
При необходимости указать количество зеркал и сегментов на узлах в разделе конфигурации сервиса ADB. По умолчанию, количество сегментов на хост = (CPU cores)/2.
Через графический интерфейс ADCM в разделе Configuration установить флажок Set up EPEL repo, необходимый для установки kafka fwd.
Выполнить предварительную проверку кластерной конфигурации и необходимых условий путём нажатия программной кнопки Precheck.
Осуществить отслеживание статуса проверки в разделе JOBS.
В случае успешности проверки выполнить установку ADB путём нажатия программной кнопки Install. После установки осуществить перезагрузку серверов.
Выполнить актуализацию установленного PXF-сервиса для кластера ADB:

собрать из репозитория http://github.com/arenadata/kafka-pxf-connector актуальную версию PXF-сервиса (см. документацию по коннектору GreenPlum: https://gpdb.docs.pivotal.io/6-8/pxf/sdk/build_conn.html#demo_buildjar);
при необходимости развернуть актуальную версию PXF-сервиса (см. документацию по коннектору GreenPlum: https://gpdb.docs.pivotal.io/6-8/pxf/sdk/deploy_conn.html)
На каждом хосте сегмента с PXF-сервисом заменить соответствующий этому сервису jar-file на актуальную версию, собранную из репозитория

cp <project>/pxf-kafka/env/pxf-profiles.xml $PXF_CONF/conf/
cp <project>/pxf-kafka/build/libs/pxf-kafka-*.jar $PXF_CONF/lib/
cp <project>/pxf-kafka/build/libs/kafka-clients-*.jar $PXF_CONF/lib/
cp <project>/pxf-kafka/build/libs/avro-1.9.2.jar $PXF_CONF/lib/shared
pxf cluster sync

посредством SQL-консоли кластера ADB выполнить проверочные запросы

CREATE WRITABLE EXTERNAL TABLE kafka_tbl (a TEXT, b TEXT, c TEXT)
LOCATION ('pxf://<topic>?PROFILE=kafka&BOOTSTRAP_SERVERS=<server>')
FORMAT 'CUSTOM' (FORMATTER='pxfwritable_export');
insert into kafka_tbl values ('a', 'b,c', 'd'), ('x', 'y', 'z');
drop external table kafka_tbl;

При отсутствии автоматического встраивания и настройки PXF в кластер ADB через Менеджер кластера ADCM осуществить запуск и настройку PXF в кластере ADB, управляемом ADCM.

В графическом интерфейсе ADCM в разделе CLUSTERS выбрать требуемый кластер ADB.
В графическом интерфейсе ADCM для выбранного кластера перебрать все хосты и в разделе Actions выбрать Install rng-tools (для устранения ошибки ADBDEV-306: PXF fail with timeout on start).
В графическом интерфейсе ADCM для выбранного кластера в разделе Services добавить PXF, в разделе Hosts - Components добавить PXF на каждый хост.
Выполнить проверку того, что PXF установился в /usr/lib/pxf под отдельным пользователем pxf.
Выполнить следующие операции на каждом хосте в силу ограничений работы команд cluster в таком окружении.
Выполнить:

sudo su - pxf
mkdir /var/lib/pxf/servers/<name>
vi /var/lib/pxf/servers/<name>/jdbc-site.xml
PXF_HOME=/usr/lib/pxf /usr/lib/pxf/bin/pxf restart

Сконфигурировать jdbc-site.xml:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property>
        <name>jdbc.driver</name>
        <value>org.postgresql.Driver</value>
    </property>
    <property>
        <name>jdbc.url</name>
        <value>jdbc:postgresql://10.92.3.31:5432/postgres</value>
    </property>
    <property>
        <name>jdbc.user</name>
        <value>postgres</value>
    </property>
    <property>
        <name>jdbc.password</name>
        <value>postgres</value>
    </property>
</configuration>

Выполнить запрос в SQL-консоли ADB:

CREATE WRITABLE EXTERNAL TABLE sample ( id int, name varchar )

LOCATION ('pxf://sample?PROFILE=Jdbc&SERVER=<name>')

FORMAT 'CUSTOM' (FORMATTER='pxfwritable_export');

insert into sample values (100,'qwe');

Проверить наличие ошибок, записанных лог-файл в /var/lib/pxf/logs/.

Выполнить установку kafka-fwd после успешной установки кластера ADB. Зайти на каждый узел кластера по протоколу ssh и через профиль пользователя root выполнить пакет команд

yum install -y wget epel-release libcsv-devel
wget https://ci.arenadata.io/artifactory/ADB/6.13.0_arenadata13/centos/7/enterprise/x86_64/kafka-fdw-0.10-377.git3fe5e36.el7.x86_64.rpm
yum install -y kafka-fdw-0.10-377.git3fe5e36.el7.x86_64.rpm
cd /usr/lib/gpdb/lib/postgresql
sudo chown gpadmin:gpadmin kadb_fdw.so

Выполнить настройку удалённого доступа для возможности подключения к СУБД извне. Прописать правила доступа в файле pg_hba.conf. Формат доступа подробно описан в документации по postgresql. Добавить правило доступа через графический интерфейс ADCM в конфигурации кластера ADB. Проверить на мастер-узле файл /data1/master/gpseg-1/pg_hba.conf на наличие запрещающих правил выше добавленного правила доступа. При наличии запрещающих правил удалить их. Добавляемые правила доступа имеют вид:

host all all 10.92.3.33/32 md5 # доступ для всех пользователей на все БД из указанной подсети
host all test 0.0.0.0/0 md5 # доступ ко всем БД из любой подсети пользователю test

Выполнить настройку среды путём создания вручную или при добавлении сервиса ADB до его инициализации.

Для создания базы вручную после установки кластера: подключиться к мастер-узлу по ssh; подключиться в качестве пользователя pgadmin su - gpadmin; подключиться к СУБД командой:

psql adb

Выполнить в СУБД SQL-запрос:

CREATE DATABASE <имя среды>.

Подключить коннектор kafka-greenplum следующими инструкциями:

CREATE EXTENSION IF NOT EXISTS kadb_fdw

для подключения kafka-greenplum connector writer

CREATE EXTENSION IF NOT EXISTS pxf

для подключения kafka-greenplum connector reader

Создать профиль пользователя через графический интерфейс ADCM в разделе сервиса ADB - Create role с установкой флажка Make role superuser, или создать профиль вручную через подключение к СУБД psql <имя среды> и выполнения SQL-запроса:

ALTER USER <имя пользователя> WITH SUPERUSER.

Выполнить следующие проверки:

проверку статуса сегментов с помощью SQL-запроса

select \* from gp_segment_configuration

проверку установленной версии с помощью команд:

postgres --gp-version
postgres -V

проверку прав пользователя на создание схемы:

Create schema IF NOT EXISTS test; Drop schema test;

4.2.7. Настройка ПО ADB

Инструкция по настройке СУБД ADB приведена в официальной документации к СУБД ADB (https://docs.arenadata.io/adb/adminguide/managetools.html).

4.2.8. Установка ПО ADG

Установку ПО ADG рекомендуется производить на хост или виртуальную машину (или на группу - кластер) под управлением ОС Linux, дистрибутив CentOS 7, Red Hat Enterprise Linux 7 или производных. Пользователь, выполняющий установку, должен находиться в группе sudo.

Подготовка управляющего хоста

Для установки ADG необходимо подготовить управляющий хост или виртуальную машину, с которой будет осуществляться установка ПО ADG на целевой кластер. Для этого на управляющий хост необходимо установить ПО удалённого управления (Ansible) из репозитория RPM-пакетов Extra Packages for Enterprise Linux (далее - EPEL). Допускается установка данного ПО непосредственно на целевой хост:

sudo yum -y install epel-release

Проверка: об успешности установки репозитория EPEL свидетельствует сообщение в конце вывода программы установки yum:

*Installed:*
*epel-release.noarch 0:7-11*
*Complete!*

Далее, необходимо обновить список пакетов из репозитория EPEL и установить ПО удалённого управления:

sudo yum update
sudo yum install -y ansible

Проверка: выполнить команду:

.. code-block:: bash

rpm -qa ansible»

Примечание

Версия пакета может отличаться.

rpm -qa ansible
ansible-2.9.23-1.el7.noarch

Для ПО удалённого управления необходимо установить роль tarantool.cartridge (дополнительный программный модуль). Необходим доступ к сайту github.com. Приведен полный вывод успешного процесса установки:

ansible-galaxy install tarantool.cartridge
downloading role 'cartridge', owned by tarantool
downloading role from https://github.com/tarantool/ansible-cartridge/archive/1.10.0.tar.gz
extracting tarantool.cartridge to /home/vagrant/.ansible/roles/tarantool.cartridge*
tarantool.cartridge (1.10.0) was installed successfully

Проверка: выполнить команду:

ansible-galaxy role list

в выводе должна быть строка с ролью tarantool.cartridge:

ansible-galaxy role list
tarantool.cartridge, 1.10.0

Установка зависимостей ПО ADG

Для корректной работы ПО AGD на целевой хост необходимо установить дополнительные зависимости доступные в официальном репозитории CentOS 7:

sudo yum install -y snappy zip unzip

Также необходимо установить дополнительные зависимости из RPM-пакетов. Перед выполнением команд установки данные файлы необходимо предварительно скопировать на целевой хост (ссылки для скачивания указаны в Таблица 2 - Состав типового ПО ведомственной витрины данных НСУД):

sudo rpm -i rpm/avroc-1.10.0-1.el7.x86_64.rpm
sudo rpm -i rpm/libzstd-1.4.5-3.el7.x86_64.rpm
sudo rpm -i rpm/librdkafka-1.5.0-1.el7.x86_64.rpm

Для проверки выполнить следующую команду:

rpm -qa snappy zip unzip avroc libzstd librdkafka

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

Примечание

Версии пакетов могут отличаться.

rpm -qa snappy zip unzip avroc libzstd librdkafka
zip-3.0-11.el7.x86_64
libzstd-1.4.5-3.el7.x86_64
snappy-1.1.0-3.el7.x86_64
avroc-1.10.0-1.el7.x86_64
librdkafka-1.5.0-1.el7.x86_64
unzip-6.0-22.el7_9.x86_64

Далее, устанавливается основная зависимость - платформа in-memory вычислений Tarantool:

curl -L https://tarantool.io/yDNXllJ/release/2.6/installer.sh \| bash
sudo yum install -y tarantool

Проверка: выполнить команду:

rpm -qa tarantool
rpm -qa tarantool
tarantool-2.6.3.0-1.el7.x86_64

4.2.9. Установка ПО ADG

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

Пример файла adg.yml смотри в Приложении 1.

В файле adg.yml перед запуском роли необходимо изменить ряд параметров:

IP-адрес 192.168.99.9 на адрес целевого хоста.
Параметры доступа ansible_user, ansible_password могут быть заполнены на валидные или убраны, при указании корректного ключа в параметре ansible_ssh_private_key_file.
Параметр cartridge_cluster_cookie следует заменить на свой. Он служит меткой для определения «своих» экземпляров кластера ADG, если в одном контуре будет установлено более 1 кластера.
В файл config.yml (пример файла config.yml смотри в Приложении 1) необходимо изменить kafka_server_ip на реальный IP до kafka сервера. Если серверов несколько, можно указать через запятую.
После внесения настроек в adg.yml установка производится командой:

ansible-playbook -i adg.yml cartridge.yml

из папки в, которой расположен файл adg.yml, например, если файл расположен в папке inventory, команда будет выглядеть следующим образом:

cd inventory
ansible-playbook -i adg.yml cartridge.yml

Пример файла cartridge.yml (см. Приложение 1.)

В конце работы команды ansible-playbook выводится итоговая таблица. В столбце со счетчиками ошибок их количество должно быть равно нулю:

failed=0 у всех экземпляров ADG.
*PLAY RECAP
\**********************************************************\**
*api-1 : ok=57 changed=9 unreachable=0 failed=0 skipped=30 rescued=0
ignored=0*
*c-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17 rescued=0
ignored=0*
*ip-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17 rescued=0
ignored=0*
*out-task-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17
rescued=0 ignored=0*
*sch-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17 rescued=0
ignored=0*
*state-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17 rescued=0
ignored=0*
*storage-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17 rescued=0
ignored=0*

Настройка конфигурации для доступа к kafka

Откройте в Web-браузере адрес целевого хоста, с указанием HTTP-порта. Например: http://192.168.99.9:8181/.

Выбрать раздел Configuration files и загрузить файл конфигурации config.yml с корректно указанным в нем адресом Kafka-сервера. Нажать кнопку Save и получить корректный ответ о загрузке конфигурации.

Перейдите на вкладку Code убедитесь, что конфигурация загрузилась .

Далее необходимо провести перезапуск сервисов для принятия настроек конфигурации. Для этого выполните в ssh-консоли следующую команду:

sudo systemctl restart memstorage@\*

Откройте в Web-браузере адрес целевого хоста, с указанием HTTP-порта. Например: http://192.168.99.9:8181/ и перейдите в раздел Cluster.

На кнопке Issues количество ошибок должно быть равно нулю, как в примере: «Issues: 0». В случае отсутствия ошибок нужно нажать красную кнопку Bootstrap vshard. Это действие выполняется однократно после успешной установки.

Проверка-2: выполнить команду:

systemctl status memstorage@*

Ниже приведен полный вывод работы этой команды:

systemctl status memstorage@\

memstorage@state-1.service - Tarantool Cartridge app

memstorage@state-1
Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)
Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago
Main PID: 18638 (tarantool)
CGroup:
/system.slice/system-memstorage.slice/memstorage@state-1.service
└─18638 tarantool init.lua <running>: memstorage@state-1

memstorage@c-1.service - Tarantool Cartridge app memstorage@c-1
Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)*
Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Main PID: 18665 (tarantool)

CGroup: /system.slice/system-memstorage.slice/memstorage@c-1.service

└─18665 tarantool init.lua <running>: memstorage@c-1

memstorage@sch-1.service - Tarantool Cartridge app memstorage@sch-1

Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)

Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Main PID: 18635 (tarantool)

CGroup: /system.slice/system-memstorage.slice/memstorage@sch-1.service

└─18635 tarantool init.lua <running>: memstorage@sch-1

memstorage@ip-1.service - Tarantool Cartridge app memstorage@ip-1

Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)

Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Main PID: 18649 (tarantool)

CGroup: /system.slice/system-memstorage.slice/memstorage@ip-1.service

└─18649 tarantool init.lua <running>: memstorage@ip-1

memstorage@out-task-1.service - Tarantool Cartridge app

memstorage@out-task-1

Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)
Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Process: 18920 ExecStartPre=/bin/sh -c mkdir -p
/var/lib/tarantool/memstorage.%i (code=exited, status=0/SUCCESS)

Main PID: 18923 (tarantool)

CGroup:
/system.slice/system-memstorage.slice/memstorage@out-task-1.service

└─18923 tarantool init.lua <running>: memstorage@out-task-1

memstorage@api-1.service - Tarantool Cartridge app memstorage@api-1

Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)

Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Main PID: 18547 (tarantool)

*CGroup: /system.slice/system-memstorage.slice/memstorage@api-1.service*

└─18547 tarantool init.lua <running>: memstorage@api-1

memstorage@storage-1.service - Tarantool Cartridge app
memstorage@storage-1

Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)

Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Main PID: 18880 (tarantool)

CGroup:
/system.slice/system-memstorage.slice/memstorage@storage-1.service

└─18880 tarantool init.lua <running>: memstorage@storage-1

4.2.10. Настройка ПО ADG

Инструкция по настройке СУБД ADG приведена в официальной документации к СУБД ADG и СУБД Tarantool (https://docs.arenadata.io/adg/install_adcm/ru/source/manage_tools/index.html).

4.2.11. Установка ПО ProStore

Установка ядра витрины как ПО ProStore осуществляется после установки Менеджера кластера ADCM, СУБД ADQM, ADS , СУБД ADG, СУБД ADB

Установка ПО ProStore из репозитория

Для установки ПО ProStore необходимо:

Клонировать репозиторий с исходным кодом проекта ProStore из репозитория: https://g.info.gov.ru/datamart/nsud-datamarts/-/blob/master/%D0%94%D0%B8%D1%81%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B8%D0%B2%D1%8B%20%D0%9F%D0%9E%20%D0%92%D0%B8%D1%82%D1%80%D0%B8%D0%BD%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85%20%D0%9D%D0%A1%D0%A3%D0%94/%

Примечание

Актуальная версия на момент написания данного руководства 3.4.0

Собрать проект ProStore с помощью Maven (команда mvn package);
Создать на сервере ProStore папки: /opt/query-execution и /opt/status-monitor.
В файлах сборки adtm-3.4.0-master@c3279ff89d8 перейти в папку dtm-query-execution-core.
Скопировать файл из сборки target/dtm-query-execution-core-3.4.0.jar и загрузить в папку /opt/query-execution на сервере.
Скопировать файл из сборки config/application-default.yml и загрузить в как /opt/query-execution/application.yml на сервере.
Перейти в папку dtm-status-monitor.
Скопировать файлы из сборки target/dtm-status-monitor-4.1.0.jar и dtm-status-monitor/src/main/resources/application.yml в папку /opt/status-monitor на сервере.
Создать файлы /opt/query-execution/logback.xml и /opt/status-monitor/logback.xml. Содержимое файлов:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="FILE"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>application.log</file>
<rollingPolicy
class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- daily rollover -->
<fileNamePattern>application.%d{yyyy-MM-dd}.log</fileNamePattern>
<!-- keep 30 days' worth of history capped at 3GB total size -->
<maxHistory>30</maxHistory>
<totalSizeCap>3GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{35} -
%msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="FILE"/>
</root>
</configuration>

Создать файл /etc/systemd/system/query-execution.service со следующим содержимым:

[Unit]
Description="Core service"
After=syslog.target
[Service]
Type=simple
WorkingDirectory=/opt/query-execution
User=root
Group=root
ExecStart=/usr/bin/java \\
-Dlogback.configurationFile=/opt/query-execution/logback.xml \\
-jar dtm-query-execution-core-3.4.0.jar \\
--logging.config=/opt/query-execution/logback.xml

Создать файл /etc/systemd/system/status-monitor.service со следующим содержимым:

[Unit]
Description="Status monitor service"
After=syslog.target
[Service]
Type=simple
WorkingDirectory=/opt/status-monitor
User=root
Group=root
ExecStart=/usr/bin/java \\
-Dlogback.configurationFile=/opt/status-monitor/logback.xml \\
-jar dtm-status-monitor-4.1.0.jar \\
--logging.config=/opt/status-monitor/logback.xml

Включить автозапуск сервисов:

sudo systemctl enable query-execution status-monitor

Получить драйвер в папке dtm-jdbc-driver;
Настроить подключения к JDBC-клиентам типа DataGrip и DBeaver (см. «Руководство оператора» раздел 3.1.1 и 3.1.1.3);
Клонировать репозиторий https://github.com/arenadata/kafka-clickhouse-connector/tree/release-3.4.0
Перейти в директорию kafka-clickhouse-reader
Собрать при помощи команды:

mvn clean package

Перейти в директорию kafka-clickhouse-writer
Собрать при помощи команды:

mvn clean package

Создать на сервере ProStor папки: /opt/kafka-clickhouse-writer и /opt/kafka-clickhouse-reader
Скопировать файлы из сборки kafka-clickhouse-reader/src/main/resources/application.yml и kafka-clickhouse-reader/target/kafka-clickhouse-reader-3.4.0.jar в /opt/kafka-clickhouse-reader
Скопировать файлы из сборки kafka-clickhouse-writer/src/main/resources/application.yml и kafka-clickhouse-writer/target/kafka-clickhouse-writer-3.4.0.jar в /opt/kafka-clickhouse-writer
Создать файл /etc/systemd/system/kafka-clickhouse-reader.service со следующим содержимым:

[Unit]
Description="kafka-clickhouse-reader"
After=syslog.target
[Service]
Type=simple
WorkingDirectory=/opt/kafka-clickhouse-reader
User=root
Group=root
ExecStart=/usr/bin/java \\
-Dspring.config.location=classpath:application.yml \\
-jar kafka-clickhouse-reader-3.4.0.jar

Создать файл /etc/systemd/system/kafka-clickhouse-writer.service со следующим содержимым:

[Unit]
Description="kafka-clickhouse-writer"
After=syslog.target
[Service]
Type=simple
WorkingDirectory=/opt/kafka-clickhouse-writer
User=root
Group=root
ExecStart=/usr/bin/java \\
-Dspring.config.location=classpath:application.yml \\
-jar kafka-clickhouse-writer-3.4.0.jar

Настроить ProStore (см. раздел 3.2.11)
Запустить ProStore (см. раздел 4.5.1)
Проверить корректность функционирования ProStore путём подачи произвольного SQL- запроса к ProStore и сопоставления ожидаемого эталонного и полученного результатов.
Пример тестового запроса

SELECT 1;

Ответ: 1.

4.2.12. Настройка ПО ProStore

Настройка ПО ProStore заключается в настройке составляющих его компонентов и осуществляется путём внесения изменений в описание программной конфигурации кластера, размещенное в текстовом конфигурационном yml-файле сервиса исполнения запросов. Программная конфигурация, в частности, включает сетевые адреса, сетевые порты и идентификаторы компонентов для взаимосвязи между ними, пути на дисковых пространствах для обработки полезных и служебных данных, а также метаданных.

Настройка Сервиса исполнения запросов (query-execution)

Настройка сервиса исполнения запросов осуществляется путем заполнения в конфигурационном текстовом yml-файле разделов, описанных ниже (для первоначальной установки используйте значения «по умолчанию»). Пример полного yml-файла со всеми конфигурируемыми атрибутами, приведен в Приложении 1.

Настройки журналирования сервиса исполнения запросов

io.arenadata.dtm.query.execution- задание уровня важности сообщений, журналируемых в лог-файл; По умолчанию установлен в TRACE;
DTM_METRICS_PORT- номер порта, используемого Сервисом исполнения запросов для отправки и получения метрик;
DTM_METRICS_ENABLED- настройка генерации метрик со стороны ProStore;
DTM_METRICS_SCOPE- состав метрик, видимых через веб-соединения

Настройка ProStore:

CORE_PLUGINS_ACTIVE- перечень используемых плагинов для доступа к СУБД ADB, ADG, ADQM
DTM_CORE_PLUGINS_RELATIONAL - настройка профилей приоритетности СУБД для общих реляционных запросов
DTM_CORE_PLUGINS_ANALYTICAL - настройка профилей приоритетности СУБД для запросов аналитики
DTM_CORE_PLUGINS_DICTIONARY - настройка профилей приоритетности СУБД для запросов ключ-значение
DTM_CORE_PLUGINS_UNDEFINED - настройка профилей приоритетности СУБД для не указанной категории запросов
DTM_CORE_HTTP_PORT - номер порта, на который Сервис исполнения запросов ожидает входящие запросы от JDBC-драйвера;
DTM_NAME - имя среды для формирования полного наименования датамартов;
CORE_TIME_ZONE - настройки временной зоны;
DTM_CORE_METRICS_ENABLED - настройки генерации метрики Сервиса исполнения запросов;
DTM_CORE_TASK_POOL_SIZE - максимальный объем пула задач в cервисе исполнения запросов;
DTM_CORE_TASK_TIMEOUT - интервал времени завершения задачи, выполняемой в Сервисе исполнения запросов;

Оптимизация работы сокета TCP_NODELAY:

DTM_CORE_HTTP_TCP_NODELAY - настройка режима оптимизации работы сокета TCP_NODELAY;
DTM_CORE_HTTP_TCP_FAST_OPEN - настройка режима TCP FAST_OPEN;
DTM_CORE_HTTP_TCP_QUICK_ACK - настройка режима оптимизации работы сокета TCP_QUICKACK;

Настройки для EDML операторов:

EDML_DATASOURCE - тип СУБД-источника (ADB, ADQM, ADG);
EDML_DEFAULT_CHUNK_SIZE – размер chunk по умолчанию;
EDML_STATUS_CHECK_PERIOD_MS - период проверки статуса плагина в миллисекундах;
EDML_FIRST_OFFSET_TIMEOUT_MS - интервал времени ожидания до таймаута в миллисекундах при работе с первым смещением;
EDML_CHANGE_OFFSET_TIMEOUT_MS - интервал времени ожидания до таймаута в миллисекундах при работе с первым смещением в топике Kafka;

Настройка Zookeeper-серверов:

ZOOKEEPER_DS_ADDRESS - сетевой адрес хоста Zookeeper для служебной БД;
ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS - интервал времени ожидания (в миллисекундах) соединения с хостом Zookeeper для служебной БД до достижения таймаута;
ZOOKEEPER_DS_SESSION_TIMEOUT_MS – интервал времени бездействия (в миллисекундах) соединения с хостом Zookeeper для служебной БД до достижения таймаута;
ZOOKEEPER_DS_CHROOT - корневой путь к хосту Zookeeper для служебной БД;
ZOOKEEPER_KAFKA_ADDRESS - сетевой адрес хоста Zookeeper для брокера сообщений Kafka;
ZOOKEEPER_KAFKA_CONNECTION_TIMEOUT_MS - интервал времени ожидания (в миллисекундах) соединения с хостом Zookeeper для брокера сообщений Kafka до достижения таймаута;
ZOOKEEPER_KAFKA_SESSION_TIMEOUT_MS - интервал времени бездействия (в миллисекундах) соединения с хостом Zookeeper для брокера сообщений Kafka до достижения таймаута;
ZOOKEEPER_KAFKA_CHROOT - корневой путь к хосту Zookeeper для брокера сообщений Kafka;

Настройка Kafka-серверов:

KAFKA_INPUT_STREAM_TIMEOUT_MS – интервал времени ожидания (в миллисекундах) входного потока данных для брокера сообщений Kafka до достижения таймаута;
KAFKA_STATUS_EVENT_ENABLED - разрешение на публикацию событий;
KAFKA_STATUS_EVENT_TOPIC - наименование топика Kafka, в который публикуются события;
STATUS_MONITOR_URL - сетевой адрес, порт и путь к Сервису мониторинга статусов Kafka;

Настройки кэширования запросов:

CACHE_INITIAL_CAPACITY - начальная емкость кэша;
CACHE_MAXIMUM_SIZE - максимальный размер кэша;
CACHE_EXPIRE_AFTER_ACCESS_MINUTES - время (в минутах) устаревания кэша после последнего момента доступа к нему;

Настройки для плагина ADB:

ADB_USERNAME - имя пользователя/логин для авторизации в СУБД ADB;
ADB_PASS - пароль для авторизации в СУБД ADB;
ADB_HOST - сетевой адрес хоста со СУБД ADB;
ADB_PORT - сетевой адрес порта на хосте с СУБД ADB;
ADB_MAX_POOL_SIZE - максимальный размер пула подключений к СУБД ADB;
ADB_FETCH_SIZE - максимальный размер возвращаемого результата по FETCH-запросу к СУБД ADB;
ADB_LOAD_GROUP – наименование консьюмер-группы СУБД ADB для взаимодействия с брокером сообщений Kafka;

Настройки механизма MPPW загрузки данных для плагина ADB:

ADB_MPPW_POOL_SIZE - максимальный размер пула подключений к СУБД ADB для операций MPPW;
ADB_MPPW_STOP_TIMEOUT_MS - интервал времени остановки таймаута в миллисекундах при операции MPP-загрузки в СУБД ADB;
ADB_MPPW_DEFAULT_MESSAGE_LIMIT - предельный размер сообщения по умолчанию для операции MPP-загрузки в СУБД ADB;
ADB_MPPW_FDW_TIMEOUT_MS – интервал времени ожидания до таймаута в миллисекундах при операции MPP-загрузки в СУБД ADB;

Настройки для СУБД ADG / Tarantool:

TARANTOOL_DB_HOST - сетевой адрес хоста с СУБД ADG;
TARANTOOL_DB_PORT - сетевой адрес порта на хосте с СУБД ADG;
TARANTOOL_DB_USER - имя пользователя/логин для авторизации в СУБД ADG;
TARANTOOL_DB_PASS - пароль для авторизации в СУБД ADG;
TARANTOOL_DB_OPER_TIMEOUT - максимальный интервал времени ожидания выполнения операции СУБД ADG до тайм-аута;
TARANTOOL_DB_RETRY_COUNT - максимальное количество повторных попыток выполнения операции;
TARANTOOL_CATRIDGE_URL - сетевой адрес и порт картриджа с графическим интерфейсом к СУБД ADG;
ADG_CONSUMER_GROUP - consumer-группа СУБД ADG для взаимодействия с брокером сообщений Kafka;
ADG_MAX_MSG_PER_PARTITION – максимальное количество сообщений на раздел СУБД ADG.
ADG_CB_FUNC_IDLE – время простоя (в секундах) callback-функции;
ADG_ROLLBACK_OPERATION_BATCH_SIZE - размер пакета операций при откате операции;
ADG_CIRCUIT_BREAKER_MAX_FAILURES - максимальное количество отказов ADG по паттерну circuitbreaker;
ADG_CIRCUIT_BREAKER_TIMEOUT - интервал времени фиксации отказа при пропадании отклика ADG;
ADG_CIRCUIT_BREAKER_FALLBACK_ON_FAILURE - использование паттерна fallback при отказе;
ADG_CIRCUIT_BREAKER_RESET_TIMEOUT - интервал времени до сброса по паттерну timeout;
ADG_WEB_CLIENT_MAX_POOL_SIZE - максимальный размер пула подключений веб-клиентов к СУБД ADG;

Настройки для плагина ADQM:

ADQM_DB_NAME - наименование СУБД ADQM;
ADQM_USERNAME - имя пользователя/логин для авторизации в СУБД ADQM;
ADQM_PASS - пароль для авторизации в СУБД ADQM;
ADQM_HOSTS - сетевой адрес хоста с СУБД ADQM и номер порта на хосте;
ADQM_SOCKET_TIMEOUT - интервал времени ожидания отклика соединения с СУБД ADQM до таймаута;
ADQM_DATA_TRANSFER_TIMEOUT - интервал времени ожидания завершения обмена данными с СУБД ADQM до таймаута;
ADQM_CLUSTER - наименование кластера СУБД ADQM;

Настройки MPPR для СУБД ADQM:

ADQM_MPPR_CONNECTOR_HOST - сетевой адрес коннектора MPP-выгрузки данных из ADQM;
ADQM_MPPR_CONNECTOR_PORT - сетевой порт коннектора MPP-выгрузки данных из ADQM;
ADQM_MPPR_CONNECTOR_URL - сетевой путь к коннектору MPP-выгрузки данных из ADQM;

Настройки MPPW для СУБД ADQM:

ADQM_CONSUMER_GROUP - наименование консьюмер-группы СУБД ADQM для взаимодействия с брокером сообщений Kafka;
ADQM_BROKERS - сетевой адрес брокера сообщений Kafka;
ADQM_MPPW_LOAD_TYPE - тип интерфейса для MPPW-загрузки данных в СУБД ADQM;
ADQM_REST_START_LOAD_URL - сетевой адрес и путь к REST-интерфейсу для старта загрузки данных в СУБД ADQM;
ADQM_REST_STOP_LOAD_URL - сетевой адрес и путь к REST-интерфейсу для остановки загрузки данных в СУБД ADQM;
ADQM_WEB_CLIENT_MAX_POOL_SIZE - максимальный размер пула подключений веб-клиентов к СУБД ADQM;

Настройка Сервиса мониторинга Kafka (status-monitor)

Настройка Сервиса мониторинга Kafka осуществляется путём указания в соответствующем конфигурационном текстовом yml-файле параметров отслеживания файлов-топиков брокера сообщений Kafka, таких как: смещения consumer, содержания последнего сообщения и времени появления последнего сообщения.

STATUS_MONITOR_BROKERS - сетевые адреса и порты брокеров сообщений Kafka, которые отслеживает монитор статусов Kafka
STATUS_MONITOR_CONSUMERS - количество потребителей (consumer) Сервиса мониторинга Kafka

Настройка Сервиса kafka-clickhouse-reader

Настройка Сервиса kafka-clickhouse-reader осуществляется путём указания в соответствующем конфигурационном текстовом yml-файле параметров:

CLICKHOUSE_DB_NAME – наименование базы данных в ADQM
CLICKHOUSE_HOSTS – имя одно их хостов ADQM
CLICKHOUSE_PASS – пароль пользователя для доступа к ADQM
CLICKHOUSE_USERNAME – имя пользователя для доступа к ADQM
ZOOKEEPER_HOSTS - Подключение к Zookeeper ProStore
KAFKA_CLUSTER_ROOTPATH - Путь хранения информации о Kafka ProStore в Zookeeper

Настройка Сервиса kafka-clickhouse-writer

Настройка Сервиса kafka-clickhouse-writer осуществляется путём указания в соответствующем конфигурационном текстовом yml-файле параметров:

CLICKHOUSE_DB_NAME – наименование базы данных в ADQM
CLICKHOUSE_HOSTS – имя одно их хостов ADQM
CLICKHOUSE_PASS – пароль пользователя для доступа к ADQM
CLICKHOUSE_USERNAME – имя пользователя для доступа к ADQM
KAFKA_BOOTSTRAP_SERVERS - Подключение к ProStore Kafka
ENV - Название окружения

4.2.13. Установка СМЭВ3-адаптера

Установка СМЭВ3-адаптер возможна, только если были добавлены ключи.

Действия по установке выполняются через SSH консоль технологического пользователя.

Установка КриптоПро

В случае использования для электронной подписи сервиса КриптоПро, необходимо предварительно скачать КриптоПро CSP (https://www.cryptopro.ru/download?pid=1417) и КриптоПро JCP (https://www.cryptopro.ru/download?pid=129) для Java JDK на компьютер, где будет устанавливаться СМЭВ3-адаптер. Установить, следуя инструкции и документации на официальном сайте. После чего получить сертификат для установки от уполномоченных лиц и установить его в КриптоПро.

Установка сервиса

Подготовка конфигурации

Для подготовки конфигурации необходимо отредактировать переменные в файле application.yml (пример application.yml приведен в Приложении 1) дистрибутива СМЭВ3-адаптер:

Указать корректный путь до СМЭВ. Переменная endpoint_url во всех вертиклах.
Указать корректный путь до ядра ProStore. Блок ProcessorVerticle:

jdbcUrl – строка подключения по JDBC в формате jdbc:postgresql://localhost:5432/smev3;
username – логин для подключения;
password – пароль для подключения;
readOnly – доступ только на чтение;

Если для цифровой подписи используется VipNet, указать переменные для доступа к VipNet:

keystoreType - тип хранилища, VIPNETPKI для VipNet
keystoreFile - URL Vipnet сервера
keystorePass - имя пользователя и пароль, выдается администратором Vipnet PKI
privateKeyAlias - токен, полученный от администратора VIPNet
certificateAlias - дублирование токена, полученного от администратора VIPNet

Если для цифровой подписи используется КриптоПро:

keystoreType - тип хранилища, JCP для КриптоПро
keystorePass - пароль хранилища ключей
privateKeyAlias - алиас приватного ключа
certificateAlias - алиас сертификата
privateKeyPass - пароль приватного ключа
signatureURI, signatureAlgorithm, digestMethod оставить аналогично указанным в примере Приложения 1.

Если используется механизм отправки дельт по расписанию и установлена сервисная БД, заполнить следующие параметры:

Для вертикла SchedulerVerticle:

interval - интервал между отправкой дельт;
template - pebble-шаблон/

Для вертикла DeltaStorageVerticle

jdbcUrl – строка подключения к сервисной БД по JDBC в формате jdbcUrl: jdbc:postgresql://127.0.0.1:5432/smev3_connector;
username – логин для подключения;
password – пароль для подключения;

Список параметров, которые необходимо настроить для обработки собственно запросов, их назначения и pebble шаблоны приведены в документе «Руководство программиста» п.3.1.2

Установка

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

Скопировать jar-файл СМЭВ3-адаптер, конфигурационный файл application.yml, jar-файл JDBC-драйвер ДТМ, сконфигурированные pebble-шаблоны на целевую машину.
В консоли перейти в каталог, в который были скопированы описанные в п.1 файлы:

Например:

cd ~/direct

Запустить jar-файл командой:

java -cp smev3-connector-x.x.x-fat.jar:dtm-jdbc-3.4.0.jar
-Dconfig.location=application.yml io.vertx.core.Launcher yml

Дождаться завершения установки. При успешном запуске будет выведена следующая информация:

INFO: Succeeded in deploying verticle

4.2.14. Установка ПОДД-адаптера

4.2.14.1. Процесс установки

Действия по установке выполняются через SSH консоль технологического пользователя.

Общий процесс установки состоит из следующих действий:

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

4.2.14.1.1. Настройка конфигурации

Настройка конфигурации выполняется путем редактирования параметров файла конфигурации application.yml.

Пример файла application.yml для Модуля исполнения запросов см. в разделе Конфигурация ПОДД-адаптера - Модуль исполнения запросов (application.yml) Руководства администратора ПО «Витрина данных НСУД».

Примечание

Значения настроек MYSQL_USER для MariaDB и SUBSCR_DB_USER для Модуля исполнения запросов, а также MYSQL_PASSWORD и SUBSCR_DB_PASS, должны совпадать.

4.2.14.1.2. Кластеризация модуля

Кластеризация модуля достигается путем запуска копии экземпляра данного модуля. Оптимальным вариантом является использование оркестраторов, например:

Kubernetes;
Openshift;
Docker-swarm;
Nomad.

4.2.15. Настройка ПОДД-адаптера

4.2.15.1. Конфигурация ПОДД-адаптера - Модуль исполнения запросов (application.yml)

Файл application.yml – основной конфигурационный файл ПОДД-адаптера - Модуль исполнения запросов, в котором задана логика и порядок работы адаптера:

получение и обработка входящих запросов;
подключение к Сервису формирования документов (секция: printable-forms-service);
настройки логирования (секция: logging), а также другие настройки необходимые для корректной работы адаптера.

Хинт пагинации FORCE_LLR определен в переменных среды.

4.2.15.1.1. Пример файла application.yml

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

http-server:
  port: ${HTTP_PORT:8090}

environment:
  name: ${ENVIRONMENT_NAME:test}

executor:
  reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
  max-execute-time: ${EXECUTOR_MAX_EXECUTE_TIME:600}
  log-pool-size: ${EXECUTOR_LOG_POOL_SIZE:20}

send:
  channel-size: ${SEND_CHANNEL_SIZE:1}
  compress: ${SEND_COMPRESS:none}
  max-message-size: ${SEND_MAX_MESSAGE_SIZE:800000}

query:
  data-source-type:
    for-listagg: ${DATA_SOURCE_TYPE_LISTAGG:ADP}
    statistics-request: ${DATA_SOURCE_TYPE_STATISTIC:ADP}
  force-llr-for-order: ${FORCE_LLR_FOR_ORDER:true}
  force-llr-for-all: ${FORCE_LLR_FOR_ALL:false}
  llr-rows-limit: ${LLR_ROWS_LIMIT:200}
  fetch-size: ${FETCH_SIZE:1000}

zookeeper:
  connection-string: ${ZOOKEEPER_DS_ADDRESS:localhost}
  connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
  session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:86400000}
  chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}

prostore-rest-client:
  host: ${PS_HOST:localhost}
  port: ${PS_PORT:9195}
  http:
    max-pool-size: ${PS_MAX_POOL_SIZE:8}

printable-forms-service:
  host: ${PFS_HOST:localhost}
  port: ${PFS_PORT:8080}
  pool-size: ${PFS_POOL_SIZE:10}
  timeout: ${PFS_TIMEOUT:30}

kafka:
  agent.topic.prefix: ${AGENT_TOPIC_PREFIX:}
  max-concurrent-handle: ${KAFKA_MAX_CONCURRENT_HANDLE:1000}
  commit-interval: ${KAFKA_COMMIT_INTERVAL:5s}
  external:
    bootstrap.servers: ${KAFKA_BOOTSTRAP_SERVERS:localhost:9092}
    topic.prefix: ${EXTERNAL_TOPIC_PREFIX:${agent.topic.prefix}}
  internal:
    bootstrap.servers: ${PS_KAFKA:localhost:9092}
    topic.prefix: ${INTERNAL_TOPIC_PREFIX:${agent.topic.prefix}}
  consumer:
    query-request:
      topic: ${kafka.external.topic.prefix}query.rq
      max-concurrent-handle: ${kafka.max-concurrent-handle}
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}query.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    query-cancel-request:
      topic: ${kafka.external.topic.prefix}cancel.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}cancel.query.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    metadata-request:
      topic: ${kafka.external.topic.prefix}metadata.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}metadata.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    metadata-new-data-request:
      topic: ${kafka.external.topic.prefix}metadata.newdata.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}metadata.newdata.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    statistics-request:
      topic: ${kafka.external.topic.prefix}statistics.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}statistics.rq.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    report-request:
      topic: ${kafka.external.topic.prefix}procedure.query.rq
      max-concurrent-handle: ${kafka.max-concurrent-handle}
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}report.rq.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
  producer:
    query-result: ${kafka.external.topic.prefix}query.rs
    query-error: ${kafka.external.topic.prefix}query.err
    query-estimation-result: ${kafka.external.topic.prefix}query.estimation.rs
    query-cancel-result: ${kafka.external.topic.prefix}cancel.rs
    query-cancel-error: ${kafka.external.topic.prefix}cancel.err
    metadata-result: ${kafka.external.topic.prefix}metadata.rs
    metadata-error: ${kafka.external.topic.prefix}metadata.err
    metadata-newdata-result: ${kafka.external.topic.prefix}metadata.newdata.rs
    metadata-newdata-error: ${kafka.external.topic.prefix}metadata.newdata.err
    statistics-result: ${kafka.external.topic.prefix}statistics.rs
    statistics-error: ${kafka.external.topic.prefix}statistics.err
    report-result: ${kafka.external.topic.prefix}query.rs
    report-error: ${kafka.external.topic.prefix}query.err
    property:
      bootstrap.servers: ${kafka.external.bootstrap.servers}
    internal:
      mppr-query-request: ${kafka.internal.topic.prefix}mppr.delegate.rq
      tp-delete-tmp: ${kafka.internal.topic.prefix}tp.delete.tmp
      property:
        bootstrap.servers: ${kafka.internal.bootstrap.servers}

statistics:
  enabled: ${STATISTICS_ENABLED:false}
  timeout-min: ${STATISTICS_TIMEOUT_MIN:60}
  datamarts:
    - name: demo_dev
      tables:
        - name: all_types
          columns:
            - varchar_c
            - char_c
            - bigint_c

logging:
  request-response:
    query-request: ${QUERY_REQUEST_LOG_ENABLED:false}
    query-response: ${QUERY_RESPONSE_LOG_ENABLED:false}
    pf-request: ${PF_REQUEST_LOG_ENABLED:false}
    pf-response: ${PF_RESPONSE_LOG_ENABLED:false}

metrics:
  port: ${METRICS_PORT:9837}

4.2.15.2. Параметры конфигурации

Настройка конфигурации ПОДД-адаптера - Модуль исполнения запросов осуществляется путем редактирования параметров настроек в файле application.yml, где настраиваются секции:

http-server - указывается порт для подключения;
environment - указывается название окружения (test, prod и т.д.);
executor - настраивается размер пула для запросов;
send - настраиваются ограничения на размер загружаемого файла;
query - настройка выполнения запросов;
zookeeper - подключения в Zookeeper;
prostore-rest-client - блок параметров конфигурирования взаимодействия с ProStore;
prostore- указываются настройки подключения к ProStore;
printable-forms-service - настройки подключения к Сервис формирования документов;
kafka - настройки параметров подключения к шине данных Apache Kafka;
statistics - управление статистикой;
logging - настройка сохранения лог-файла;
metrics - настройка получения метрик.

4.2.15.2.1. Секция http-server

В секции http-server указывается порт веб-сервера.

Например:

http:
  port: ${HTTP_PORT:8090}

Параметры настроек

port - порт веб-сервера, например: HTTP_PORT:8090.

4.2.15.2.2. Секция environment

Секция environment предназначена для настройки параметров окружения.

Например:

environment:
  name: ${ENVIRONMENT_NAME:test}

Параметры настроек

name - название окружения (test, prod и т.д.), например: ENVIRONMENT_NAME:test.

4.2.15.2.3. Секция executor

Секция executor предназначена для указания размера пула для чтения Kafka и времени выполнения задач.

Например:

executor:
  reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
  max-execute-time: ${EXECUTOR_MAX_EXECUTE_TIME:600}
  log-pool-size: ${EXECUTOR_LOG_POOL_SIZE:20}

Параметры настроек

reader-pool-size - размер пула для чтения Kafka, например EXECUTOR_READER_POOL_SIZE:20;
max-execute-time - максимальное время выполнения задачи (сек), например EXECUTOR_MAX_EXECUTE_TIME:600;
log-pool-size - размер используемого пула для журналирования запросов и ответов, например EXECUTOR_LOG_POOL_SIZE:20.

4.2.15.2.4. Секция send

В секции send настраиваются ограничения на размер загружаемого файла.

Например:

send:
  channel-size: ${SEND_CHANNEL_SIZE:1}
  compress: ${SEND_COMPRESS:none}
  max-message-size: ${SEND_MAX_MESSAGE_SIZE:800000}

Параметры настроек

channel-size - размер канала на отправку сообщения, например SEND_CHANNEL_SIZE:10;
compress - сжатие выгружаемых сообщений (none или zstd), например SEND_COMPRESS:none;
max-message-size - максимальный размер отправляемого сообщения, например SEND_MAX_MESSAGE_SIZE:800000.

4.2.15.2.5. Секция query

В секции query выполняется настройка выполнения запросов.

Например:

query:
  data-source-type:
    for-listagg: ${DATA_SOURCE_TYPE_LISTAGG:ADP}
    statistics-request: ${DATA_SOURCE_TYPE_STATISTIC:ADP}
  force-llr-for-order: ${FORCE_LLR_FOR_ORDER:true}
  force-llr-for-all: ${FORCE_LLR_FOR_ALL:false}
  llr-rows-limit: ${LLR_ROWS_LIMIT:200}
  fetch-size: ${FETCH_SIZE:1000}

Параметры настроек

data-source-type - выполнение запроса с LISTAGG на (ADB/ADP), например DATA_SOURCE_TYPE:ADB;
force-llr-for-order - выполнение ORDER BY запроса c использованием пагинации, например FORCE_LLR_FOR_ORDER:true;
force-llr-for-all - выполнение всех запросов через LLR, например FORCE_LLR_FOR_ALL:false;
llr-rows-limit - ограничение выгрузки через ЛЛР, при использовании в запросе лимита со значением меньшим, чем указанное значение, например LLR_ROWS_LIMIT:200, будет использован режим LLR;
fetch-size - размер выгрузки через JDBC, например FETCH_SIZE:1000.

Внимание

Для опции force-llr-for-order параметр false можно устанавливать только при развертывании витрины на единственной БД ADP.

4.2.15.2.6. Секция zookeeper

Секция zookeeper определяет настройки подключения к Zookeeper DS.

Например:

zookeeper:
  connection-string: ${ZOOKEEPER_DS_ADDRESS:t5-adsp-01.ru-central1.internal}
  connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
  session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:86400000}
  chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}

Параметры настроек

connection-string - подключение в Zookeeper DS, например ZOOKEEPER_DS_ADDRESS:t5-adsp-01.ru-central1.internal;
connection-timeout-ms - Zookeeper DS таймаут подключения, например ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000;
session-timeout-ms - Zookeeper DS таймаут сессии, например ZOOKEEPER_DS_SESSION_TIMEOUT_MS:86400000;
chroot - Zookeeper DS chroot path, например ZOOKEEPER_DS_CHROOT:/adapter.

4.2.15.2.7. Секция prostore-rest-client

В секции prostore-rest-client реализован блок параметров конфигурирования взаимодействия с ProStore.

Например:

prostore-rest-client:
  host: ${PS_HOST:localhost}
  port: ${PS_PORT:9195}
  http:
    max-pool-size: ${PS_MAX_POOL_SIZE:8}

Параметры настроек

host - адрес Prostore, например PS_HOST:localhost;
port - порт Prostore, например PS_PORT:9195;
max-pool-size - максимальное число подключений к Prostore, например PS_MAX_POOL_SIZE:8.

4.2.15.2.8. Секция printable-forms-service

Секция printable-forms-service определяет настройки подключения к Сервис формирования документов.

Например:

printable-forms-service:
  host: ${PFS_HOST:localhost}
  port: ${PFS_PORT:8080}
  pool-size: ${PFS_POOL_SIZE:10}
  timeout: ${PFS_TIMEOUT:30}

Параметры настроек

host - адрес сервера формирования документов, например PFS_HOST:localhost;
port - порт сервера формирования документов, например PFS_PORT:8080;
pool-size - размер пула соединений для ПФ, например PFS_POOL_SIZE:10;
timeout - таймаут переподключения к сервису формирования документов (секунды), например PFS_TIMEOUT:30.

4.2.15.2.9. Секция kafka

В секции kafka настраиваются параметры подключения к шине данных Apache Kafka.

Например:

kafka:
  agent.topic.prefix: ${AGENT_TOPIC_PREFIX:}
  max-concurrent-handle: ${KAFKA_MAX_CONCURRENT_HANDLE:1000}
  commit-interval: ${KAFKA_COMMIT_INTERVAL:5s}
  external:
    bootstrap.servers: ${KAFKA_BOOTSTRAP_SERVERS:localhost:9092}
    topic.prefix: ${EXTERNAL_TOPIC_PREFIX:${agent.topic.prefix}}
  internal:
    bootstrap.servers: ${PS_KAFKA:localhost:9092}
    topic.prefix: ${INTERNAL_TOPIC_PREFIX:${agent.topic.prefix}}
  consumer:
    query-request:
      topic: ${kafka.external.topic.prefix}query.rq
      max-concurrent-handle: ${kafka.max-concurrent-handle}
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}query.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    query-cancel-request:
      topic: ${kafka.external.topic.prefix}cancel.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}cancel.query.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    metadata-request:
      topic: ${kafka.external.topic.prefix}metadata.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}metadata.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    metadata-new-data-request:
      topic: ${kafka.external.topic.prefix}metadata.newdata.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}metadata.newdata.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    statistics-request:
      topic: ${kafka.external.topic.prefix}statistics.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}statistics.rq.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    report-request:
      topic: ${kafka.external.topic.prefix}procedure.query.rq
      max-concurrent-handle: ${kafka.max-concurrent-handle}
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}report.rq.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
  producer:
    query-result: ${kafka.external.topic.prefix}query.rs
    query-error: ${kafka.external.topic.prefix}query.err
    query-estimation-result: ${kafka.external.topic.prefix}}query.estimation.rs
    query-cancel-result: ${kafka.external.topic.prefix}cancel.rs
    query-cancel-error: ${kafka.external.topic.prefix}cancel.err
    metadata-result: ${kafka.external.topic.prefix}metadata.rs
    metadata-error: ${kafka.external.topic.prefix}metadata.err
    metadata-newdata-result: ${kafka.external.topic.prefix}metadata.newdata.rs
    metadata-newdata-error: ${kafka.external.topic.prefix}metadata.newdata.err
    statistics-result: ${kafka.external.topic.prefix}statistics.rs
    statistics-error: ${kafka.external.topic.prefix}statistics.err
    report-result: ${kafka.external.topic.prefix}query.rs
    report-error: ${kafka.external.topic.prefix}query.err
    property:
      bootstrap.servers: ${kafka.external.bootstrap.servers}
    internal:
      mppr-query-request: ${kafka.internal.topic.prefix}mppr.delegate.rq
      tp-delete-tmp: ${kafka.internal.topic.prefix}tp.delete.tmp
      property:
        bootstrap.servers: ${kafka.internal.bootstrap.servers}

Параметры конфигурации

topic - префикс для топиков Агента СМЭВ4, например AGENT_TOPIC_PREFIX.

4.2.15.2.10. Секция statistics

Секция statistics предназначена для управления статистикой.

Например:

statistics:
  enabled: ${STATISTICS_ENABLED:false}
  timeout-min: ${STATISTICS_TIMEOUT_MIN:60}
  datamarts:
    - name: demo_dev
      tables:
        - name: all_types
          columns:
            - varchar_c
            - char_c
            - bigint_c

Параметры конфигурации

enabled - включение (true)/ выключение (false) расчета статистики, например STATISTICS_ENABLED:false;
timeout-min - время обновления статистики (минуты), например STATISTICS_TIMEOUT_MIN:60.

4.2.15.2.11. Секция logging

Секция logging предназначена для настройки параметров логирования.

Например:

logging:
  request-response:
    query-request: ${QUERY_REQUEST_LOG_ENABLED:false}
    query-response: ${QUERY_RESPONSE_LOG_ENABLED:false}
    pf-request: ${PF_REQUEST_LOG_ENABLED:false}
    pf-response: ${PF_RESPONSE_LOG_ENABLED:false}

Параметры конфигурации

query-request - журналирование query запросов, например QUERY_REQUEST_LOG_ENABLED:false;
query-response - журналирование query ответов, например QUERY_RESPONSE_LOG_ENABLED:false;
pf-request - журналирование запросов на сервис формирования документов, например PF_REQUEST_LOG_ENABLED:false;
pf-response - журналирование ответов от сервиса формирования документов, например PF_RESPONSE_LOG_ENABLED:false.

4.2.15.2.12. Секция metrics

Секция metrics предназначена для настройки параметров метрик.

Например:

metrics:
  port: ${METRICS_PORT:9837}

Параметры конфигурации

port - Порт для метрик, например METRICS_PORT:9837.

4.2.16. Установка ETL

Установка Apache Airflow

Подготовка конфигурации

Клонировать репозиторий Apache Airflow из официального репозитория:
```
git clone https://github.com/apache/airflow.git
```
Перейти в папку airflow

Создать в папке файл Dockerfile.custom со следующим содержимым:

FROM ${BASE_AIRFLOW_IMAGE}
SHELL ["/bin/bash", "-o", "pipefail", "-e", "-u", "-x", "-c"]
USER 0
# Install Java
RUN mkdir -pv /usr/share/man/man1 \\
&& mkdir -pv /usr/share/man/man7 \\
&& curl -fsSL
https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public \|
apt-key add - \\
&& echo 'deb https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/ buster
main' > \\
/etc/apt/sources.list.d/adoptopenjdk.list \\
&& apt-get update \\
&& apt-get install --no-install-recommends -y \\
adoptopenjdk-8-hotspot-jre \\
&& apt-get autoremove -yqq --purge \\
&& apt-get clean \\
&& rm -rf /var/lib/apt/lists/\*
# Установка JDR 1.8
ENV JAVA_HOME=/usr/lib/jvm/adoptopenjdk-8-hotspot-jre-amd64
USER ${AIRFLOW_UID}
# Установка компонента apache.spark
RUN pip install --upgrade pip \\
&& pip install --no-cache-dir --user 'apache-airflow[apache.spark]'

Установка

Установка docker описана в разделе 3.3.2. Установка Менеджера кластера ADCM.

Создать новый образ в докере, в той же директории, где расположен файл Dockerfile.custom:

docker build . \ –build-arg BASE_AIRFLOW_IMAGE=»apache/airflow:2.0.1-python3.8» \ -f Dockerfile.java8 \ -t airflow:2.0.1-python3.8-custom
Скачать файл docker-compose.yaml с официального сайта Airflow https://Airflow.apache.org/docs/apache-airflow/2.0.1/docker-compose.yaml
Установить docker-compose.yaml через SSH-консоль технологического пользователя.

Выдать права на исполнение файла:
```
sudo chmod +x /usr/local/bin/docker-compose
```

Запустить sudo:

ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

Проверить корректность установки:

$ docker-compose --version
docker-compose version 1.28.6, build 1110ad01

Перейти в директорию с файлом docker-compose.yml

Например:

cd ~/direct

Инициализировать компоненты:
```
docker-compose up airflow-init
```

Запустить сервисы с новым образом:

docker-compose up
AIRFLOW_IMAGE_NAME=apache/airflow:2.0.1-python3.8-custom

Установка Apache Spark

Установка docker описана в разделе 3.3.2. Установка Менеджера кластера ADCM.

Подготовка конфигурации
Клонировать репозиторий Apache Airflow из официального репозитория:

git clone https://github.com/big-data-europe/docker-spark.git
Перейти в директорию docker-spark

Пример:

cd ~/direct
Выполнить скрипт ./build.sh или вручную последовательно запустить следующие команды:
- сборка базового образа
  
  docker build -t bde2020/spark-base:3.1.1-hadoop3.2
- сборка образа мастер
  
  docker build -t bde2020/spark-master:3.1.1-hadoop3.2
- сборка образа воркера
  
  docker build -t bde2020/spark-worker:3.1.1-hadoop3.2
Проверить наличие собранных образов:

Выполнить команду docker images:

REPOSITORY TAG IMAGE ID CREATED SIZE

bde2020/spark-worker 3.1.1-hadoop3.2 05c349b4646f 4 minutes ago 460MB

bde2020/spark-master 3.1.1-hadoop3.2 7918c5357d6d 4 minutes ago 460MB

bde2020/spark-base 3.1.1-hadoop3.2 5430434220d2 4 minutes ago 460MB
1. Установка
Перейти в директорию docker-spark, где располагается файлом docker-compose.yml

Пример:

cd ~/direct
Поднять Apache Spark командой:

docker-compose up
Проверить командой:

docker ps

В списке запущенных образов должны присутствовать spark-worker и spark-master

Установка Apache Hadoop

Установка docker описана в разделе 3.3.2. Установка Менеджера кластера ADCM.

Подготовка конфигурации
Клонировать репозиторий Apache Hadoop из официального репозитория:
```
git clone https://github.com/big-data-europe/docker-hadoop.git
```

Перейти в папку docker-hadoop

Наример:

cd ~/direct

Выполнить скрипт make build или вручную последовательно запустить следующие команды:

сборка базового образа:

docker build -t bde2020/hadoop-base:master ./base

сборка остальных образов:

docker build -t bde2020/hadoop-namenode:master ./namenode
docker build -t bde2020/hadoop-datanode:master ./datanode
docker build -t bde2020/hadoop-resourcemanager:master
./resourcemanager
docker build -t bde2020/hadoop-nodemanager:master ./nodemanager
docker build -t bde2020/hadoop-historyserver:master
./historyserver
docker build -t bde2020/hadoop-submit:master ./submit

Проверить наличие собранных образов:

Выполнить команду docker images:

REPOSITORY TAG IMAGE ID CREATED SIZE

bde2020/hadoop-submit master 665a424edc23 9 minutes ago 1.37GB

bde2020/hadoop-historyserver master ff53bf6835e2 9 minutes ago 1.37GB

bde2020/hadoop-nodemanager master c48c47bc840f 9 minutes ago 1.37GB

bde2020/hadoop-resourcemanager master 74fc55d664d2 9 minutes ago 1.37GB

bde2020/hadoop-datanode master f69c6460a292 9 minutes ago 1.37GB

bde2020/hadoop-namenode master 7a8250da8510 9 minutes ago 1.37GB

bde2020/hadoop-base master aeb6500ab4b5 10 minutes ago 1.37GB

Установка

Перейти в директорию docker-hadoop, где располагается файл docker-compose.yml

Наример:

cd ~/direct

Поднять Apache Hadoop командой:
```
docker-compose up
```
Проверить командой:
```
docker ps
```

В списке запущенных образов должны присутствовать hadoop-resourcemanager, hadoop-historyserver, hadoop-datanode, hadoop-nodemanager, hadoop-namenode

Установка СУБД Tarantool

Установка docker описана в разделе 3.3.2. Установка Менеджера кластера ADCM.

Подготовка конфигурации

Клонировать репозиторий Tarantool из официального репозитория:
```
git clone https://github.com/tarantool/docker.git
```
Выполнить сборку согласно инструкции:

https://github.com/tarantool/docker#how-to-push-an-image-for-maintainers

Перейти в клонированную папку docker

Например:

cd ~/direct

Выполнить сборку образа docker для Tarantool:

export TAG=2 export OS=alpine DIST=3.9 VER=2.8.0 PORT=5200 make -f .gitlab.mk build

Проверить наличие собранных образов командой docker images:

REPOSITORY TAG IMAGE ID CREATED SIZE
tarantool/tarantool 2 27f80564ecce 2 minutes ago 298MB

Создать в клонированной директории docker файл docker-compose.yml со следующим содержимым:

version: "3"
services:
tarantool1:
image: tarantool/tarantool:2
container_name: tarantool1
restart: always
networks:
- tarantool_network
ports:
- "3301:3301"
volumes:
- tarantool1_volume:/opt/tarantool
environment:
# https://github.com/tarantool/docker#environment-variables
TARANTOOL_REPLICATION: "tarantool1,tarantool2"
tarantool2:
image: tarantool/tarantool:2
container_name: tarantool2
restart: always
networks:
- tarantool_network
ports:
- "3302:3301"
volumes:
- tarantool2_volume:/opt/tarantool
environment:
TARANTOOL_REPLICATION: "tarantool1,tarantool2"
volumes:
tarantool1_volume:
tarantool2_volume:
networks:
tarantool_network:
driver: bridge

Установка

Перейти в директорию docker, где располагается файл docker-compose.yml

Напимер:

cd ~/direct

Пример запуска мастер-мастер репликации:

https://github.com/tarantool/docker#start-a-master-master-replica-set

Поднять Tarantool командой:
```
docker-compose up
```
Проверить командой:
```
docker ps
```

В списке запущенных образов должны присутствовать tarantool1 и tarantool2

4.2.17. Установка REST-адаптера

Установка сервисов и необходимых сервисных баз данных.

Внимание

Установка данных сервисов выполняется после установки «Core Services».

Действия по установке выполняются на сервере ADCM через SSH-консоль технологического пользователя.

Установка docker-образов

Установка docker описана в разделе 3.3.2. Установка Менеджера кластера ADCM. Установить образ сервера конечных точек API, файл образа .tar должен быть загружен через docker. (ссылки для скачивания указаны в Таблица 2 - Состав типового ПО ведомственной витрины данных НСУД в строке «Сервер конечных точек API).

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

docker image load -i <image_file>

Подготовка конфигурации

Для подготовки скриптов необходимо выполнить следующие действия:

Отредактировать переменные в файле application.yml для вашей среды. Пример файла приведен в Приложении 1. Файл необходимо поместить в папку config:

Указать корректный путь до целевой БД. Переменная jdbc_url.

Например:

jdbc:{drv_name}://{IP_Host}:{Port}/{db_name}

, где:

drv_name - имя драйвера , берется из описания драйвера базы
IP_Host - ip или имя хоста с базой;
Port - порт, на котором будет слушать сервис . По умолчанию 8080;
db_name - имя базы данных.
Указать driver-class-name - имя класса , берется из описания драйвера базы
Указать переменную file_path - наименование файла с описанием запросов, по умолчанию sample.yaml.
Указать переменные execquery - сопоставление operationId из файла с описанием запросов c файлом обработчиком, по умолчанию sample.peb.

Установка

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

Перейти в директорию с файлом docker-compose.yml

Наример:

cd ~/direct

Поднять сервис конечных точек командой:
```
docker-compose up -d
```
Проверить установку следующей командой:

docker ps

В списке запущенных образов должен присутствовать rest-adapter

4.2.18. Настройка сервера конечных точек API

Детальные примеры описания REST API и pebble-шаблонов приведены в документе «Руководство программиста».

Kонфигурационный файл с конечными точками

Для доступа к конечным точкам необходим отредактировать файл sample.yaml, описав все необходимые API в соответствии с приведенным в файле шаблоном (шаблон соответствует спецификации OpenAPI 3.0 https://swagger.io/specification/ ).

Секция: servers:

url: / - корневой путь сервера.

Секция: paths

/test/query - путь запроса;
тип запроса - get , post и т.д. ;
operationId - определение operationId для связки с темплейт файлом;
responses - описание параметров ответа.

Шаблоны

Для парсинга и обогащениe запросов используются шаблоны.

В качестве языка шаблонов используется pebble. С дополнениями:

функция xpath(expression) - возвращает вычисленное выражение на входящем документе;
тэг {% mtom %} some content {% endmtom %} - отправляет внутренность вложением;
функция sql(var, sql, param1, param2, ...) - выполняет sql с параметрами, результат записывается в переменную var.

Пример формирования шаблона приведен в файле sample.peb.