Установка#

Установка компонентов технологического ядра Platform V#

Установите компоненты, указанные в разделе «Компоненты технологического ядра Platform V».

Настройка серверов Kafka#

Для своей работы Archiving использует три Kafka:

• для обмена данных с КАП;

• для обмена данными с источниками данных в 4 поколении (стек k8s или OpenShift (опционально));

• для обмена данными с АС Прикладной журнал.

Подключение к каждой Kafka осуществляется через SSL. Для каждой Kafka необходимы собственные сертификаты.

Шифрование трафика осуществляется средствами Kafka.

Настройка интеграционной Kafka#

Интеграционная Kafka Archiving отвечает за обмен данными с КАП. Другие сервисы к ней не подключаются. Исходя из требований безопасности подключение к ней должно осуществляться через SSL. При подключении необходимо выпустить сертификаты, которые дают право:

• чтения;

• записи данных;

• создания топиков.

Генерация сертификата#

При генерации сертификата необходимо указать уникальный пароль, удовлетворяющий требованиям безопасности к его составу. В <CN> вставьте заполненный шаблон:

00CA0000CKafkaPPRBARCH4@kbrb.prom.arch-journal.sbrf.ru

Команда для сертификата:

keytool -genkey -alias serverNode -keystore serverNode.jks -keyalg RSA -keysize 2048 -dname "CN=<CN>, OU=00CA, O=Savings Bank of the Russian Federation, C=RU"

Создание запроса на подпись сертификата#

Запрос на подпись сертификата:

keytool -keystore serverNode.jks -alias serverNode -certreq -file serverNode-certreq.csr

Подпись сертификата#

Для подписи сертификата необходимо сформировать запрос в RLM. Процесс создания запроса может отличаться в зависимости от полигона установки. Подробно процесс формирования запроса описан в документации поддержки сервиса WildFly.

Импорт сертификатов удостоверяющего центра#

Импортируйте в JKS-хранилище сертификаты удостоверяющего центра (УЦ), которым подписаны сертификаты на предыдущем шаге. Это обязательно для последующего импорта подписанного сертификата, так как keytool проверяет корректность всей цепочки сертификации при импорте.

keytool -keystore serverNode.jks -alias "Test Root CA 2" -import -file "Test Root CA 2.cer"
keytool -keystore serverNode.jks -alias "Sberbank Test Issuing CA 2" -import -file "Sberbank Test Issuing CA 2.cer"

Импорт подписанного сертификата#

1. Импортируйте подписанный сертификат в JKS-хранилище:

   keytool -keystore serverNode.jks -alias serverNode -import -file <путь к подписанному сертификату>
   

   Проверка корректности созданных сертификатов:

   keytool -v --list --keystore serverNode.jks | awk '/Owner:|Issuer:|Your keystore contains|Certificate chain length/'
   

   Пример вывода:

   Your keystore contains 3 entry
   Certificate chain length: 3
   Owner: CN=000CA0000CKafkaPPRBARCH4@kbrb.prom.arch-journal.sbrf.ru, OU=00CA, O=Savings Bank of the Russian Federation, C=RU
   Issuer: CN=Sberbank Test Issuing CA 2, DC=ca, DC=sbrf, DC=ru
   Owner: CN=Sberbank Test Issuing CA 2, DC=ca, DC=sbrf, DC=ru
   Issuer: CN=Test Root CA 2
   Owner: CN=Test Root CA 2
   Issuer: CN=Test Root CA 2
   

   Вывод должен содержать:

   • Your keystore contains 3 entry;

   • Certificate chain length: 3;

   • Issuer: УЦ банка.

2. Поместите сертификаты УЦ, полученные через ЗНО, в truststore:

   keytool -keystore truststore.jks -alias "Test Root CA 2" -import -file "Test Root CA 2.cer"
   keytool -keystore truststore.jks -alias "Sberbank Test Issuing CA 2" -import -file "Sberbank Test Issuing CA 2.cer"
   

Корректировка server.properties#

На каждом узле брокеров Kafka в файле server.properties необходимо отредактировать основные параметры:

1. Измените:

   listeners= PLAINTEXT://<ip_брокера>:9092
   

   на

   listeners = SSL://<ip_брокера>:9093
   

2. Добавьте параметры в секции SSL и MAIN:

   ############################### SSL #################################
   security.inter.broker.protocol=SSL
   sasl.enabled.mechanisms=GSSAPI
   sasl.mechanism.inter.broker.protocol=GSSAPI
   sasl.kerberos.service.name =kafka
   #путь к файлу, скопированному в п.4
   ssl.keystore.location = ./ssl/serverNode.jks
   ssl.truststore.location = ./ssl/trustStore.jks
   ssl.keystore.password = XXXXX
   ssl.truststore.password = XXXXX
   ssl.key.password = XXXX
   ssl.client.auth = required
   ssl.enabled.protocols = TLSv1.2
   
   ##########################[ MAIN ]#########################
   broker.id=1
   replica.fetch.max.bytes = 20971520
   max.message.bytes = 20971520
   message.max.bytes = 20971520
   

   Параметр max.message.bytes устанавливается для каждого топика по отдельности через утилиту ./kafka-configs.

   Пример:

   ./kafka-configs --zookeeper <ip-адрес-zookeper1>:2181,<ip-адрес-zookeper2>:2181 --entity-name <topic-name> --entity-type topics --alter --add-config max.message.bytes=XXXXXXX
   

   Параметр message.max.bytes устанавливается в конфигурационном файле на уровне брокера.

3. Добавьте параметры в секцию авторизации:

   #####################[ AUTHORIZATION ]#####################
   authorizer.class.name =kafka.security.auth.SimpleAclAuthorizer
   
   #здесь указывается сертификат администратора Kafka
   super.users=User:CN=00CA0001SKAFKAPPRBEFIMOVAV,OU=00CA,O=Savings Bank of the Russian Federation,C=RU
   zookeeper.set.acl=false
   allow.everyone.if.no.acl.found=false
   

   Примечание

   Каталоги с топиками рекомендуется разместить на SSD-томе (в случае испрользования физического сервера).

4. Отредактируйте параметры в секции логирования LOGS.

   Установите время хранения — 72 часа в параметре log.retention.hours и максимальный размер сообщений.

   #######################[ LOGS ]##########################
   log.retention.hours = 72
   log.retention.check.interval.ms =300000
   log.cleaner.enable = True
   log.dirs =/kafka/ssd/kafka-logs-new
   log.segment.bytes= 2073741824 log.retention.check.interval.ms =300000
   log.cleaner.enable=true
   

Перезапуск Kafka и ZooKeeper#

Остановить Kafka на всех узлах:

./bin/kafka-server-stop.sh
./bin/zookeeper-server-stop.sh

Запустить Kafka на всех узлах:

./bin/zookeeper-server-start.sh -daemon config/zookeeper.properties

./bin/kafka-server-start.sh -daemon config/server.properties

Топики, необходимые для работы, создаются при первом подключении Archiving к Kafka полигона.

Создание служебных топиков#

Для работы Archiving в Kafka создаются служебные топики. Существуют два варианта их создания:

• автоматически при первом запуске Archiving;

• вручную.

Если необходимо автоматическое создание, то в конфигурации Archiving (смотрите раздел «Доработка конфигурации под полигон развертывания») установите pprbod-source-provider-v4@topics.enable.autoconfig = true.

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

Создание топиков источника#

Процесс аналогичен созданию служебных топиков. В Kafka создаются топики под каждый источник. Если необходимо автоматическое создание, установите pprbod-source-provider-v4@topics.enable.autoconfig = true.

Создание транспортных топиков источника#

Для источников на DataSpace и Platform V Persistence 4 поколения в транспортной Kafka Archiving создаются транспортные топики. Если необходимо автоматическое создание, установите pprbod-transport-kafka-lib@transport_topics.enable.autoconfig= true.

Настройка Kafka взаимодействия с источниками 4 поколения (Kafka 4-3)#

Данная Kafka служит шиной для взаимодействия с источниками данных, которые находятся в четвертом поколении платформы (стек k8s или OpenShift (опционально)).

Так же, как в случае с интеграционной Kafka, соединение происходит через SSL. Процесс выпуска сертификатов аналогичен интеграцинной Kafka, но шаги выполняются на брокерах данной Kafka.

Настройка Kafka Прикладного Журнала#

Интеграционная Kafka Archiving и Kafka для взаимодействия с источниками 4 поколения являются частью инфраструктуры Archiving и конфигурируются его сопровождением.

Kafka Прикладного журнала относится к инфраструктуре Прикладного журнала. Archiving является для нее клиентом. Поэтому при настройке взаимодействия с данной Kafka выпускаются только клиентские сертификаты (смотрите раздел «Создание клиентских сертификатов»).

Переход с Kafka на Corax#

Для перехода на Corax выполните следующие действия:

1. Определите все нестандартные (имеющие параметры со значениями, отличающимеся от значений по умолчанию) конфигурации топиков на старой Kafka на каждом узле брокеров Kafka в файле server.properties.

2. Отключите модули Archiving на всех стендах, связанных с данной Kafka.

3. Пропишите Corax в Platform V Configuration (описано в разделе Настройка серверов Kafka), установите сертификаты (см. раздел Генерация сертификата).

4. Запустите модули Archiving (см. Сценарии администрирования.

5. Сконфигурируйте топики аналогично исходной конфигурации, определенной в пункте «1» (например, увеличьте количество партиций, время хранения и т.д.).

Создание клиентских сертификатов#

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

Создание клиентского сертификата интеграционной Kafka#

1. Создайте клиентский сертификат. Он необходим Archiving для чтения и записи в топики. Процедура выпуска аналогична серверному сертификату.

   После выпуска сертификата сохраните его DNAME как параметр конфигурации pprbod-source-provider-v4@kafka.tsa.principal в формате: User:CN=00CA....brf.ru,OU=00CA,O=Savings Bank of the Russian Federation,C=RU. Путь к сертификату сохраните как параметр конфигурации pprbod-source-provider-v4@kafka.ssl.keystore.location.

2. Получите от КАП клиентский сертификат для чтения и записи в топики интеграционой Kafka Archiving.

   Получите DNAME клиентского сертификата КАП и запомните его как параметр конфигурации pprbod-source-provider-v4@kafka.cap.principal в формате: User:CN=00CA....brf.ru,OU=00CA,O=Savings Bank of the Russian Federation,C=RU.

3. Создайте клиентский сертификат администратора, который необходим Archiving для создания топиков.

   Путь к сертификату сохраните как параметр конфигурации pprbod-source-provider-v4@kafka.admin.ssl.keystore.location.

4. Выдайте клиентскому admin-сертификату SSL для интеграционной Kafka Archiving Devops-права: автосоздание и автоконфиг топиков.

   Необходимые права:

   

5. Выдайте клиентскому сертификату SSL Archiving для интеграционной Kafka Archiving права all на группу '*'.

6. Выдайте клиентскому сертификату SSL КАП для интеграционной Kafka Archiving права all на группу '*'.

7. Сохраните адреса брокеров Kafka как параметр конфигурации: pprbod-source-provider-v4@integration-environment.bootstrap.servers.

   Проверьте, что указаны SSL порты Kafka (пример параметра: <ip-адрес1>:9093,<ip-адрес2>:9093,<ip-адрес3>:9093).

Создание клиентского сертификата Kafka 4-3#

1. Создайте клиентский сертификат с правами на чтение всех топиков. Он необходим Archiving для чтения из топиков.

   Разместите сертификат на каждом из узлов Archiving.

   Путь к сертификату запомните как параметр конфигурации pprbod-transport-kafka-lib@kafka.consumer.ssl.keystore.location.

2. Создайте клиентский сертификат для записи с правами на запись во все топики. Необходим Archiving для записи в любой из топиков.

   Разместите сертификат на каждом из узлов Archiving.

   Путь к сертификату запомните как параметр конфигурации pprbod-transport-kafka-lib@kafka.producer.ssl.keystore.location.

3. Создайте клиентский admin-сертификат. Необходим Archiving для создания топиков.

   Путь к сертификату запомните как параметр конфигурации pprbod-source-provider-v4@kafka.aj.ssl.keystore.location.

4. Выдайте клиентскому admin-сертификату SSL для интеграционной Kafka Archiving Devops права: автосоздание и автоконфиг топиков.

   Необходимые права:

   

5. Выдайте клиентскому сертификату SSL Archiving для интеграционной Kafka 4-3 права all на группу '*'.

6. Сохраните адреса брокеров Kafka как параметр конфигурации pprbod-transport-kafka-lib@bootstrap.servers.

   Проверьте, что указаны SSL порты Kafka (пример параметра: <ip-адрес1>:9093,<ip-адрес2>:9093,<ip-адрес3>:9093).

Создание клиентского сертификата Kafka Прикладного Журнала#

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

Разместите выпущенные сертификаты на узлах Archiving в каталогах, пути до которых указаны в конфигурации Прикладного журнала в артефакте:

• application-journal@kafka.consumer.ssl.keystore.location — сертификат на чтение;

• application-journal@kafka.producer.ssl.keystore.location — сертификат на запись.

После выполнения всех шагов настройка всех Kafka завершена.

Выпуск сертификата Archiving для Ignite SE 4.2100.6#

Выпуск сертификатов неразрывно связан с безопасным режимом Ignite. Безопасный режим активирует работу через SSL, а также отправку событий в подсистему аудит. Конфигурация безопасного режима начинается с установки JVM параметров на стенде.

Опции можно указать в конце файла [дирeктория wildfly]/bin/standalone.conf.

Например, для типа кластера CLUSTER (для других стендов изменится только контур):

JAVA_OPTS="$JAVA_OPTS -DIGNITE_CLUSTER_TYPE=CLUSTER -DIGNITE_CLUSTER_NAME=arch-journal -DIGNITE_MBEANS_DISABLED=true"

Хранилище ключей#

Для серверных узлов Ignite необходимо подготовить сертификат. Он будет одинаковый для всех узлов в кластере. На этом этапе важно правильно сформировать CN для сертификата.

Генерация сертификата#

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

Шаблон для CN сертификата:

00CA0000<CERTIFICATE_TYPE><LOGIN>@<IGNITE_NODE_NAME>.<IGNITE_CLUSTER_TYPE>.<IGNITE_CLUSTER_NAME>.sbrf.ru
00CA0000SIgnitePPRBARCH\@arch-journal.ru
00CA0000CIgniteClientPPRBARCH\@arch-journal.ru

CERTIFICATE_TYPE — буква перед логином:

• S — серверный сертификат;

• C — клиентский сертификат.

IgnitePPRBARCH — логин, под которым узел будет подключаться к кластеру. Должен совпадать с серверным логином в PPRBARCH-security-data.json.

IgniteClientPPRBARCH — логин клиента, который будет подключаться к кластеру. Должен совпадать с клиентским логином в PPRBARCH-security-data.json.

При генерации сертификата укажите уникальный пароль, удовлетворяющий требованиям безопасности к его составу. В <CN> вставьте заполненный выше шаблон.

Команда на создание сертификата:

keytool -genkey -alias serverNode -keystore serverNode.jks -keyalg RSA -keysize 2048 -dname "CN=<CN>, OU=00CA, O=Savings Bank of the Russian Federation, C=RU"

Создание запроса на подпись сертификата#

Выполните запрос на подпись сертификата:

keytool -keystore serverNode.jks -alias serverNode -certreq -file serverNode-certreq.csr

Подпись сертификата через RLM#

Для подписи сертификата необходимо сформировать запрос в RLM. Процесс формирования запроса зависит от полигона выпуска.

Внимание!

В поле Тип сертификата выберите Серверно-клиентский.

Импорт сертификатов удостоверяющего центра#

Импортируйте в JKS-хранилище сертификаты удостоверяющего центра (УЦ), которым подписаны сертификаты на предыдущем шаге. Это обязательно для последующего импорта подписанного сертификата, так как keytool проверяет корректность всей цепочки сертификации при импорте.

keytool -keystore serverNode.jks -alias "Test Root CA 2" -import -file "Test Root CA 2.cer"
keytool -keystore serverNode.jks -alias "Sberbank Test Issuing CA 2" -import -file "Sberbank Test Issuing CA 2.cer"

Импорт подписанного сертификата#

Импортируйте подписанный через ЗНО сертификат в JKS-хранилище командой:

keytool -keystore serverNode.jks -alias serverNode -import -file <путь к подписанному сертификату>

Удаление сертификатов удостоверяющего центра#

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

Удалите из JKS-хранилища сертификаты УЦ, добавленные в разделе «Импорт сертификатов удостоверяющего центра»

keytool -keystore serverNode.jks -alias "Test Root CA 2\" -delete
keytool -keystore serverNode.jks -alias "Sberbank Test Issuing CA 2" --delete

Проверка корректности созданных сертификатов#

1. Проверьте целостность созданных сертификатов командой:

   keytool -v --list --keystore serverNode.jks | awk '/Owner:|Issuer:|Your keystore contains|Certificate chain length/'
   

   Пример вывода:

   Your keystore contains 1 entry
   Certificate chain length: 3
   Owner: CN=00CA0000SIgnitePPRBARCH\@arch-journal.ru, OU=00CA, O=Savings Bank of the Russian Federation, C=RU
   Issuer: CN=Sberbank Test Issuing CA 2, DC=ca, DC=sbrf, DC=ru
   Owner: CN=Sberbank Test Issuing CA 2, DC=ca, DC=sbrf, DC=ru
   Issuer: CN=Test Root CA 2
   Owner: CN=Test Root CA 2
   Issuer: CN=Test Root CA
   

   Вывод должен содержать:

   • Your keystore contains 1 entry;

   • Certificate chain length: 3;

   • Issuer: УЦ банка.

   Внимание!

   Обязательно проверьте в сертификате наличие поля ExtendedKeyUsages с двумя записями - serverAuth и clientAuth командой: keytool -v --list --keystore serverNode.jks.

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

   ExtendedKeyUsages [
       serverAuth
       clientAuth
   ]
   

2. Переместите сертификаты, подписанные УЦ, в truststore.

     keytool -keystore truststore.jks -alias \"Test Root CA 2\" -import -file \"Test Root CA 2.cer\"\
     keytool -keystore truststore.jks -alias \"Sberbank Test Issuing CA 2\" -import -file \"Sberbank Test Issuing CA 2.cer\"
   

Конфигурирование учетных записей Ignite#

Файл PPRBARCH-security-data.json содержит роли и пользователей Ignite. Файл должен содержать хешированые пароли. Логин пользователя должен совпадать с логином в сертификате.

Получить хеш и соль можно с помощью скрипта ise-user-control.sh, который находится в дистрибутиве Ignite по пути bin/ise-user-control.sh. Предварительно необходимо запустить узел скриптом bin/startServer.sh, а после генерации остановить скриптом bin/stopServer.sh.

Дистрибутив Ignite-SE-4.2100.6: запуск/остановка узла для генерации хеша

./bin/startServer.sh
./bin/stopServer.sh

Команда для генерации хеша

./bin/ise-user-control.sh generate-hash

Результат выполнения:

bash-3.2$ ./bin/ise-user-control.sh generate-hash
User control utility.
Time: 2021-02-09T11:47:57.021
Command [generate-hash] started.
Enter value for --password (password)
Enter value for --confirm-password (confirm password):
Salt: 72C44DCB781208723C177F595986B4A03DF44E23B850A11DF3098691D557CA6A
Salted hash: F18EE9C089DD482DF638DA9407DFA2388165408FAE8EF6895B34FE7051B0BC1DD3438A79351D3BE45F4F47E2A15F5154E8305A8F8A835D801751D83C174C388C
Command [generate-hash] finished successfully.Control utility has completed execution at: 2021-02-09T11:48:07.227
Execution time: 10206 ms

Полученные Salt и Salted hash необходимо разместить в параметрах salt и password соответственно.

{
  "creds":
    "login": "testUser1",
    "password":
"F18EE9C089DD482DF638DA9407DFA2388165408FAE8EF6895B34FE7051B0BC1DD3438A79351D3BE45F4F47E2A15F5154E8305A8F8A835D801751D83C174C388C"
"salt": "72C44DCB781208723C177F595986B4A03DF44E23B850A11DF3098691D557CA6A"
}

Рабочая директория Ignite#

Параметр igniteWorkDir должен указывать на рабочую директорию Ignite. У WildFly должны быть права на чтение и запись в эту папку. Например, когда владельцем файла является user WildFly.

Пример конфигурации (в конфигураторе) с включенным безопасным режимом:

  igniteWorkDir=/usr/WF/ignite
  addresses=10.XX.XXX.XX:XXXXX..XXXXX;
  localPort=47500
  secureGrid=true
  keyStoreFilePath=/usr/WF/certs/IgnitePPRBARCH-keystore.jks
  keyStorePassword=123456
  trustStoreFilePath=/usr/WF/certs/truststore.jks
  trustStorePassword=123456
  sslProtocol=TLSv1.2
  keyStoreType=JKS
  serverLogin=IgnitePPRBARCH
  serverPassword=123456
  allCredentialsFilePath=/usr/WF/certs/PPRBARCH-security-data.json
  sslClientAuth=true
  clientLogin=IgniteClientPPRBARCH
  clientPassword=123456
  clientKeyStoreFilePath=/usr/WF/certs/IgniteClientPPRBARCH-keystore.jks
  clientKeyStorePassword=123456
  clientTrustStoreFilePath=/usr/WF/certs/truststore.jks
  clientTrustStorePassword=123456
  clientTransactionTimeout=300000

Подключение Archiving к ОТТ#

Список модулей Archiving, для которых нужна настройка ОТТ#

• arch-journal-cdm-init;

• arch-journal-gbk-init;

• arch-journal-ucp-consents-init;

• arch-journal-dataspace-init;

• pprbod-applied-journal-handler;

• pprbod-data-quality-processor;

• pprbod-offline-dq-collector-v4;

• pprbod-source-provider-v4;

• pprbod-stream-processor.

Порядок настройки ОТТ для отдельного модуля#

1. Установка клиентских модулей OTT на сервера приложений Archiving.

2. Генерация секретных ключей и сертификатов.

3. Размещение на серверах Archiving секретных ключей.

4. Размещение на серверах Archiving сертификатов OTT.

5. Настройки в Конфигураторе.

6. Перезапуск серверов приложений фабрики.

Настройка PostgreSQL (Platform V Pangolin SE (PSQ))#

Базовая настройка PostgreSQL (рекомендуется использовать Platform V Pangolin SE (PSQ))#

Подготовка БД#

Закажите КТС PostgreSQL (Platform V Pangolin SE (PSQ)) (заявка может отличаться в зависимости от полигона) с указанием компонентов:

• имя табличного пространства;

• имя базы данных;

• владелец БД (указать УЗ администратора/администраторов: кто будет работать с первичной настройкой/подготовкой базы и сопровождать ее);

• ТУЗ системы/сервиса;

• имя схемы.

Внимание!

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

Подключение к PostgreSQL (Platform V Pangolin SE (PSQ)) через pgAdmin#

1. Запустите pgAdmin. Откроется вкладка в браузере с запросом мастер-пароля (нужно ввести и запомнить пароль, так как он будет запрашиваться всегда при открытии pgAdmin).

2. В разделе Servers выберите Add New Server, далее во вкладке General укажите имя сервера (для отображения в списке серверов).

3. Откройте вкладку Connection и укажите ip/dns name сервера БД в поле host).

4. В поле Port укажите порт, который был указан в почте (обычно это 5432 или 5433) .

5. В поле Maintenance database укажите название базы.

6. В полях Username/password укажите логин/пароль учетной записи и выполните подключение к базе.

7. Для выполнения переподключения к базе под другой учетной записью нажмите правой кнопкой на сервер и выберите Disconnect, далее зайдите в Properties и укажите соответствующий логин/пароль.

После получения КТС:

ы1. Подключитесь к БД через pgAdmin (или другой клиент) под УЗ «Владелец БД» с указанным портом в письме (обычно это порт 5432 или 5433). 2. Смените транспортный паролль для ТУЗ (пароль по умолчанию Supertransport$123):

```
alter user "<ТУЗ>" with password '<новый_пароль>';
```

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

3. Выполните команду:

   set role as_admin;
   

4. Создайте схему pprbod_cfg. Она требуется БД для работы ТС Архивирование, так как у скриптов Liquibase ТСА отсуствуют права на создание схем. Команда на создание схемы:

   create schema if not exists pprbod_cfg;
   

5. Укажите использование схемы по умолчанию командой:

   alter role "<ТУЗ>" in database <имя БД> set search_path to <имя схемы данных>;
   

6. Выдайте привелегии для ТУЗ командой:

   grant ALL on schema <имя схемы данных> to "<ТУЗ>";
   

7. Установите максимальное количество соединений с БД. Рассчитывается по формуле: <количество серверов Archiving> * jdbc.maxPoolSize (параметр конфигуратора в артефакте pprbod-source-provider-v4, по умолчанию 5) + 10 (на случай необходимости дополнительных подключений).

Возможные проблемы:

• Скрипт liquibase при выполнении update блокирует параметр в базе. Можно проверить командой select * from DATABASECHANGELOGLOCK. Если параметр будет Locked true, необходимо выполнить команду Truncate table DATABASECHANGELOGLOCK для очистки значения в таблице.

• Баг при выдаче КТС с владельцем группы db_admin (должна быть as_admin): необходимо оформлять ЗНО на группу SberInfra УБД Администрирование СУБД PostgreSQL (Platform V Pangolin SE (PSQ)).

• Если схема не выбралась, укажите схему для сессии командой SET search_path TO <имя схемы данных>. Посмотреть можно через pgAdmin. Для этого нажмите правой кнопкой мыши по базе htmdb и выберите properties. В поле owner должен быть as_admin.

Перечисление списка схем:

select schema_name from information_schema.schemata;

Настройка PostgreSQL (рекомендуется использовать Platform V Pangolin SE (PSQ)) для работы через SSL соединение#

Создание центра сертификации для выпуска самоподписанных сертификатов.#

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

Создайте центр сертификации (CA — Certificate Authority), с помощью которого вы сможете выпускать сертификаты как для серверов, так и для клиентов. CA можно создать с помощью пакета OpenSSL.

Создайте корневой ключ:

openssl genrsa -out rootCA.key 2048

Создайте корневой сертификат:

openssl req -x509 -new -key rootCA.key -days 10000 rootCA.crt

Создание запроса на подпись сертификатов#

• Сервер

  Создание ключа и сертификата для сервера.

  Создайте ключ сервера:

  openssl genrsa -out server.key 2048
  

  Создайте запрос на сертификат:

  openssl req -new server.key -out server.csr
  

  При заполнении полей в поле Common Name (CN) важно указать имя сервера: домен или IP адрес (Например, доменное имя: tkli-pprb3862).

  Подпишите запрос на сертификат корневым сертификатом:

  openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server.crt -days 5000
  

• Клиент

  Создайте клиентский ключ аналогично серверному, только имена файлов измените соответственно на client.key, client.crt, client.csr. В поле Common Name (CN) укажите логин, под которым будет выполняться подключение к БД.

  Для выпуска не самодписанных сертификатов создайте запрос на подпись сертификатов в RLM, приложите к нему файлы с расширением "csr".

Создание хранилища ключей и хранилища доверенных сертификатов для клиента#

1. Создайте хранилище ключей PKCS12 из закрытого ключа и открытого сертификата:

   openssl pkcs12 -export -name client-cert -in client.crt -inkey client.key -out client_keystore.p12`
   

2. Преобразуйте хранилище ключей PKCS12 в хранилище ключей JKS:

   keytool -importkeystore -destkeystore client_keystore.jks -srckeystore client_keystore.p12 -srcstoretype pkcs12 -alias client-cert
   

3. Импортируйте сертификат сервера в доверенное хранилище клиента:

   keytool -import -alias server-cert -file rootCA.crt -keystore client_truststore.jks
   

Настройка конфигурационного файла PostgreSQL (рекомендуется использовать Platform V Pangolin SE (PSQ))#

1. Скопируйте корневой сертификат CA, ключ и сертификат сервера в каталог БД:

   cp server.key /var/opt/rh/rh-postgresql12/lib/pgsql/data
   cp server.crt /var/opt/rh/rh-postgresql12/lib/pgsql/data
   cp rootCA.crt /var/opt/rh/rh-postgresql12/lib/pgsql/data
   chown postgres: /var/opt/rh/rh-postgresql12/lib/pgsql/data/server.{crt,key} /var/opt/rh/rh-postgresql12/lib/pgsql/data/rootCA.crt
   chmod 600 /var/opt/rh/rh-postgresql12/lib/pgsql/data/server.crt
   

2. Отредактируйте конфигурацию PostgresSQL SE:

   nano /var/opt/rh/rh-postgresql12/lib/pgsql/data/postgresql.conf
   #(конфигурационный файл может быть custom.conf)
   ssl = on
   ssl_ca_file = 'rootCA.crt'
   ssl_cert_file = 'server.crt'
   ssl_key_file = 'server.key'
   ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL'
   nano /var/opt/rh/rh-postgresql12/lib/pgsql/data/pg_hba.conf
   hostssl arch_poseydon poseydon all md5 clientcert=verify-full
   

   После внесения изменений перезапустите PostgreSQL (Platform V Pangolin SE (PSQ)).

Установка Archiving на стенд#

1. Загрузите конфигурационные файлы в конфигуратор Platform V (через который осуществляется конфигурирование WildFly) на полигоне. Для этого необходимо сделать следующее:

   Импортировать конфигурационные файлы модулей:

   • arch-journal-cdm-init-config-struct.xml;

   • arch-journal-gbk-init-config-struct.xml;

   • arch-journal-ucp-consents-init-config-struct.xml;

   • arch-journal-dataspace-init-config-struct.xml;

   • pprbod-applied-journal-handler-config-struct.xml;

   • pprbod-data-quality-processor-config-struct.xml;

   • pprbod-grid-lib-v4-config-struct.xml;

   • pprbod-handler-config-struct.xml;

   • pprbod-offline-dq-collector-v4-config-struct.xml;

   • pprbod-source-provider-v4-config-struct.xml;

   • pprbod-stream-processor-config-struct.xml.

   И другие (при наличии их в каталоге config).

2. Выполните импорт настроек из property-файлов для импортированных конфигураций.

Именование конфигурационных файлов осуществляется по следующему шаблону: <название модуля>.properties.<расширение полигона>.

Общие параметры#

Параметры для всех модулей сохранены в файлах

<module>.properies.<server>

Примеры названия properties файла:

• pprbod-applied-journal-handler.properties.server1;

• pprbod-grid-lib-v4.properties.server2;

• pprbod-data-quality-processor.properties.server3.

Частный случай для развертывания на стенде ИФТ КБ. Необходимо импортировать настройки:

• arch-journal-cdm-init.properties.boston;

• arch-journal-gbk-init.properties.boston;

• arch-journal-ucp-consents-init.properties.boston;

• pprbod-applied-journal-handler.properties.boston;

• pprbod-data-quality-processor.properties.boston;

• pprbod-grid-lib-v4.properties.boston;

• pprbod-offline-dq-collector-v4.properties.boston;

• pprbod-source-provider-v4.properties.boston;

• pprbod-stream-processor.properties.boston.

Примечание

Некоторые параметры зависят от окружения установки модуля.

Доработка конфигурации под полигон развертывания#

Жирным шрифтом помечены те параметры, которые необходимо настраивать. Если Значение по умолчанию не заполнено, параметр необходимо указать, исходя из конфигурации полигона; если заполнено, рекомендуется заполнить, исходя из комментария в описании, или оставить как есть. Перечень конфигурационных файлов, подлежащих настройке, приведен в разделе «Загрузка новой конфигурации Archiving».

prbod-source-provider-v4#

Настройки БД

Название полигона

Настройки подключения к Kafka

Настройки продюсера

Настройки консюмера

Настройки автоматического конфигурирования топиков

Настройки системных топиков

Прочие параметры

Параметры админ-клиента транспортной Kafka

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

Параметры, определяющие работу прозрачного шифрования (Transparent Data Encryption, TDE) для функционала целостности и полноты в части шифрования Kafka трафика.

Параметры, определяющие работу модуля контроля задержки на RAW Topic и Data Topic.

| Название | Значение по умолчанию | Описание | |—|—|—|—|—| | cap.cluster.name | | clr1;clr2;clr3 - список кластеров(не стенды) через ';'. При отсутствии КАП может быть произвольным. По информации от КАП, в зонах его присутствия списки кластеров следующие: DEV - стенды: pprbod-source-provider-v4@cap.cluster.name=dev;sdpdevod; IFT - стенды: pprbod-source-provider-v4@cap.cluster.name=ift;iftnrt;sdpiftod ПСИ-стенды: pprbod-source-provider-v4@cap.cluster.name=clatsklod;atdisdpcap ПРОМ-стенды: pprbod-source-provider-v4@cap.cluster.name=clsklhbase;clsklhbase2;clsphbase3;sklsdppprb | | journal.deactivation.mode | | (ALL/MAIN) - выбор варианта остановки чтения - останавливаются все потоки, или остановка основного потока векторов изменений, при этом поток ретраев не останавливается | | lag.watcher.refresh.interval.ms | | Интервал проверки проверки лага в милисекундах. (60000 = 1 минута) | | lag.watcher.activate.on.error | | Реакция на ошибку вычисления лага. true - при любой ошибке вычисления лага включаем поток. false - поток не включаем | | data.lag.watcher.off.threshold | | Верхний порог отключения потока для Data Lag Wathcer | | data.lag.watcher.on.threshold | | Нижний порог включения потока для Data Lag Wathcer | | raw.lag.watcher.off.threshold | | Верхний порог отключения потока для Raw Data Lag Wathcer | | raw.lag.watcher.on.threshold | | Нижний порог включения потока для Raw Data Lag Wathcer |

pprbod-grid-lib-v4#

Настройки для работы с Ignite.

Конфигурация данного артефакта полностью зависит от настроек, выполненных на шаге «Конфигурация Ignite на стенде»

В случае, если secureGrid=false, для заполнения обязательны поля: addresses, Platform V DataGridWorkDir, localPort.

pprbod-transport-kafka-lib#

Настройки подключения к Kafka

Настройки подключения к Kafka продюсера

Настройки продюсера

Настройки подключения к Kafka консюмера

Настройки консюмера

Параметры протокола 4-3

pprbod-data-quality-processor#

Параметры процессора оффлайн/онлайн ТКД.

Параметры наполняемости кэша для хранения запрошенных в ходе ТКД ключей

pprbod-applied-journal-handler#

Параметры адаптера потока (модуль взаимодействия с АС Прикладной журнал).

Детальнее про настройку механизма ретраев см. «Подключение библиотеки для отправки журналов и перехода в StandIn».

pprbod-stream-processor#

Параметры процессора потока данных.

pprbod-offline-dq-collector-v4#

Параметры коллектора данных Init и ТКД (параметры конфигуратора отсуствуют).

arch-journal-cdm-init/arch-journal-ucp-consents-init/arch-journal-gbk-init/arch-journal-dataspace-init#

Параметры адаптеров Init.

После выполения всех перечисленных шагов можно приступать к установке компонентов Archiving на стенд.

Установка модулей на WildFly#

Следующим этапом развертывывания Archiving является установка компонентов сервиса на серверы WildFly.

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

1. Установить на WildFly без запуска компоненты, которые присутствуют в дистрибутиве (не включать):

   Наименование компонента	Назначение компонента
   pprbod-source-provider-v4	JBoss модуль - хранилище системных компонентов сервиса
   pprbod-stream-processor	Обработчик данных, отправляющий данные в интеграционную Kafka Archiving
   pprbod-offline-dq-collector-v4	Обработчик данных, присылаемых от источников данных в процессе Init и ТКД
   pprbod-data-quality-processor	Модуль, отвечающий за выполнение ТКД и DRP
   pprbod-applied-journal-handler	Обработчик данных, получаемых от АС Прикладной журнал
   arch-journal-cdm-init, arch-journal-dataspace-init, arch-journal-gbk-init, arch-journal-ucp-consents-init	Модули-адаптеры для инициализирующей выгрузки различных типов источников данных

2. Прописать все модули Archiving в seap-lib overlay в конфигурации WildFly.

   Один из вариантов выполнения с помощью встроенной утилиты WildFly ./jboss-cli.sh. При помощи терминала зайдите в каталог, где установлен WildFly, в подкаталог bin (пример: wildfly/bin), используя команду:

   ./jboss-cli.sh --connect --controller=<адрес сервера>:\<порт WildFly> --user=<имя пользователя> ---password=<пароль пользователя> --command="deployment-overlay link --name=seap-lib-9.2 --deployments=<название модуля>*"
   

   --deployments=<название модуля>* — звездочка означает, что overlay прописывается для любой версии данного модуля. Чтобы прописать overlay для конкретной версии,отредактируйте команду следующим образом:

   --deployments=<название модуля>-<номер версии>.war
   

   Пример команды для модуля pprbod-source-provider-v4

   ./jboss-cli.sh --connect --controller=10.XX.XXX.XX:XXXX --user=admin --password=admin --command="deployment-overlay link --name=seap-lib-9.2 --deployments=pprbod-source-provider-v4*"
   

3. Перезапустите WildFly.

4. Запустите компонеты Платформы в нужном порядке.

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

   1. pprbod-source-provider-v4.war;

   2. pprbod-stream-processor.war;

   3. pprbod-data-quality-processor.war;

   4. pprbod-offline-dq-collector-v4.war;

   5. pprbod-applied-journal-handler.war;

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

6. Повторите шаги 1-5 на всех серверах приложений WildFly, где необходимо установить Archiving.

Если запуск всех модулей на всех узлах произведен успешно, Archiving установлен на полигон.

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

Чек-лист установки компонентов Archiving на сервер#

1. На серверах приложений все модули Archiving установлены успешно.

2. Если параметр pprbod-source-provider-v4@topics.enable.autoconfig = true, в интеграционной Kafka появились топики, указанные в разделе «Создание служебных топиков».