Установка RPLW на VM#

Порядок установки#

1. Создайте пользователя (роль) и схему gdl в БД модуля управления и выдайте ему необходимые права).

2. Создайте tablespace grdl_ts_data и grdl_ts_idx.

3. Создайте пользователя (роль) в БД источника и приемника для выполнения репликации и выдайте ему необходимые права.

4. Проверьте и подготовьте параметры в common репозитории стенда.

5. Выполните развертывание объектов базы данных (playbook DB_UPDATE).

6. Используя средства Pipeline, выполните миграцию конфигурационных файлов GraDeLy на узел.

7. Произведите полную установку GraDeLy инструментом CDJE.

8. Рекомендуется убедиться, что в БД источника создаются публикации для выбора реплицируемых таблиц.

9. Создайте техническую таблицу в БД приемника для старта с GraDeLyID.

10. Настройте секреты в системе управления секретами HashiCorp Vault/Secret Management System.

11. Определите максимальную производительность.

12. Настройте механизм для ограничения входящих запросов Rate Limiter

13. Настройте интеграция с SecMan.

Шаг 1. Создайте пользователя (роль) и схему gdl в БД модуля управления и выдайте ему необходимые права (обязательный)#

Последовательность действий#

    CREATE ROLE gdl WITH
        LOGIN
        ENCRYPTED PASSWORD '${password.placeholder}'
        VALID UNTIL '${time.placeholder}';
    CREATE SCHEMA IF NOT EXISTS AUTHORIZATION gdl;
    ALTER ROLE gdl SET search_path = "$user",ext,public;
    GRANT USAGE ON SCHEMA ext TO gdl;
    commit;

Примечания:

• замените ${password.placeholder} актуальным паролем;

• замените ${time.placeholder} на timestamp срока действия пароля или на значение infinity для бессрочного пароля.

Проверка результата#

Пользователь и схема gdl созданы в БД модуля управления.

Шаг 2. Создайте tablespace grdl_ts_data и grdl_ts_idx (обязательный)#

Последовательность действий#

    create tablespace grdl_ts_data owner gdl location '${YYY_location.placeholder}';
    create tablespace grdl_ts_idx owner gdl location '${ZZZ_location.placeholder}';
    commit;
    GRANT ALL ON TABLESPACE grdl_ts_data TO gdl;
    GRANT ALL ON TABLESPACE grdl_ts_idx TO gdl;
    commit;

Примечания:

• замените ${YYY_location.placeholder} на абсолютный путь к папке для табличного пространства grdl_ts_data (папка должна существовать на момент создания табличного пространства);

• замените ${ZZZ_location.placeholder} на абсолютный путь к папке для табличного пространства grdl_ts_idx (папка должна существовать на момент создания табличного пространства).

Проверка результата#

Tablespace созданы.

Шаг 3. Создайте пользователя (роль) в БД источника и приемника для выполнения репликации и выдайте ему необходимые права (обязательный)#

Последовательность действий#

• Роль для БД источника:

      CREATE ROLE gdl_worker WITH
          REPLICATION
          LOGIN
          ENCRYPTED PASSWORD '${password.placeholder}'
          VALID UNTIL '${time.placeholder}';
          commit;
  

• Роль для БД приемника (выдача прав на репликацию не требуется):

      CREATE ROLE gdl_worker WITH
      LOGIN
      ENCRYPTED PASSWORD '${password.placeholder}'
      VALID UNTIL '${time.placeholder}';
      commit;
  

    > Примечания:
    >
    > - замените `${password.placeholder}` актуальным паролем;
    > - замените `${time.placeholder}` на timestamp срока действия пароля или на значение infinity для бессрочного пароля.
  

  Выдача минимально необходимых прав репликатору на объекты приемника (для всех DML операций и на использование схемы):

    GRANT USAGE ON SCHEMA ${schema_name} TO gdl_worker;
    GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA ${schema_name} TO gdl_worker;
    ALTER DEFAULT PRIVILEGES IN SCHEMA ${schema_name} GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO gdl_worker;
    commit; 
  

  Для использования обязательных технических таблиц со стороны репликатора ($GRADELY_APPLY_POSITION$ и $CONFLICT_RESOLUTION_TX$) выдайте дополнительные права:

    GRANT USAGE ON SCHEMA ${schema_name} TO gdl_worker;
    GRANT SELECT, INSERT, UPDATE, DELETE ON $GRADELY_APPLY_POSITION$, $CONFLICT_RESOLUTION_TX$ IN SCHEMA ${schema_name} TO gdl_worker;
  

  Примечания:

  • воркер по умолчанию ожидает значение ${schema_name} = public, однако можно указать другую схему через параметр apply_position_schema в Опциях соединения с БД приемника (см Руководство администратора);

  • достаточно создать одну таблицы $GRADELY_APPLY_POSITION$ и $CONFLICT_RESOLUTION_TX$ на каждой БД приемника.

  • выдача дополнительных прав репликатору на объекты источника не требуется.

Проверка результата#

Роли пользователей в БД источника и приемника созданы.

Шаг 4. Проверьте и подготовьте параметры в common репозитории стенда для воркера (RPLW) при развертывании на VM (обязательный)#

Последовательность действий#

• параметры ${стенд}/hosts/globalInventory

    rplw_vms_group:
      hosts:
        rplw-vm-1:
          ansible_host: rplw-vm-1.domain.local
          ip_address: [ip адрес хоста]
          rplw_module_url: "http://rplw-vm-1.domain.local:6884"
          rplw_module_label: "rplw_on_vm"
          rplw_module_console_url: "https://grdl-console.domain.local/"
          rplw_module_db_urls: '["source-db.domain.local:5432/postgres", "target-db.domain.local:5432/postgres"]'
          rplw_module_secman_prefix: "A/IFT3/GRDL/KV2"
          rplw_module_secman_address: "https://secman.domain.local:8443/"
          rplw_module_secman_namespace: "DEV"
          rplw_module_secman_pg_cert_path: "DEV/IFT3/GRDL/KV2/source-db.domain.local"
          rplw_module_secman_ssl_cert_path: "A/IFT3/GRDL/KV2/rplw-on-vm"
      vars:
        ansible_ssh_user: "[имя пользователя]"
        ansible_ssh_private_key_file: "{{ [имя секрета приватного ключа] }}"
  

• параметры точки расширения ${стенд}/environment.json

    "pipeline_extensions": {
      "INSTALL_RPLW_MODULE_ON_VM": {
        "enable": true,
        "visible": true,
        "description": "Установка или обновление дистрибутива rplw на виртуальном сервере",
        "priority": 10,
        "failJobOnError": true,
        "allowedSecrets": [
          "rplw_module_secman_role_id",
          "rplw_module_secman_secret_id"
        ],
        "extend": {
          "instead": [
            "START_DEPLOY"
          ]
        },
        "parameters": {
          "SUB_STAGE": "INSTALL_WORKER_ON_VM_SUBSTAGE"
        },
        "run": {
          "ansible": [
            {
              "role": "{{ distr_unpack_dir }}/package/conf/ansible/gradely_install_dot",
              "group": "rplw_vms_group",
              "parameters": {
                "DEBUG": "$DEBUG"
              }
            }
          ]
        }
      }
    }
  

Проверка результата#

Параметры в common репозитории стенда для воркера подготовлены.

Шаг 5. Выполните развертывание объектов базы данных (обязательный)#

Последовательность действий#

Выполните файл сценария DB_UPDATE, используя устанавливаемый дистрибутив.

Проверка результата#

Сценарий выполнен.

Шаг 6. Мигрируйте конфигурационные файлы GraDeLy (обязательный)#

Последовательность действий#

Перед развертыванием самого приложения необходимо произвести шаблонизацию и миграцию параметров из дистрибутива на среду (параметров среды и параметров программного обеспечения).

Данные для шаблонизации и миграции находятся в папке дистрибутива conf/config/parameters.

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

Для RPLW:

  └── conf
  	 └── config
  	     └── parameters
  	     	 ├── rplw.all.conf
  	     	 ├── rplw.istio.all.conf
  	     	 └── rplw-module.conf

Справочная информация по параметрам конфигурации:

# размер кэша на воркере - применителе, количество собранных балков в очереди перед применением к БД
gdl.apply-cache-size=15 

# размер кэша на воркере – приемнике, сколько сообщений держим в очереди при вычитке из базы
gdl.capture-cache-size=12000 

# необходима ли регистрация в консоли
gdl.console-integration=true 

# url консоли
gdl.console.url

# какой адептер для подключения к БД использовать (на данный момент только postgres)
gdl.db.adapter=postgres 

# какой диалект для подключения к БД использовать (на данный момент только postgres)
gdl.db.dialect=postgres 

# включить ssl
gdl.db.ssl.enable=true 

# путь до ssl key
gdl.db.ssl.sslkey

# включить ли чтение секретов и hot-reload 
gdl.hot-reload.enabled=true 

# адрес сервиса хранилища секретов
gdl.hot-reload.vault.address 

# путь до клиентского сертификата для хранилища секретов
gdl.hot-reload.vault.clientSSLCertPath

# чтение секретов из сервиса хранилища секретов (если false – будет пытаться читать с файловой системы)
gdl.hot-reload.vault.enabled=true

# roleid/secretid в зашифрованном виде (base64), результат работы утилиты password-encrypt-cli-2.4.0.jar: java -jar password-encrypt-cli-2.4.0.jar -k <KEY> -p <roleId>/<secretId> -a PBEWithMD5AndTripleDES
gdl.hot-reload.vault.enc-role-secret 

# namespace хранилища секретов
gdl.hot-reload.vault.namespace 

# путь до ключа, с помощью которого шифруется roleid/secretid
gdl.hot-reload.vault.phrase-path 

# префикс до секретов в хранилище секретов
gdl.hot-reload.vault.prefix 

# путь до серверного сертификата хранилища секретов
gdl.hot-reload.vault.serverSSLCertPath

# путь для авторизации в хранилище секретов (например, approle или worker)
gdl.hot-reload.vault.vault-path 

# размер кэша на воркере – применителе, сколько транзакций держим в очереди при вычитке из кафки
gdl.kafka-consumer-queue-size=12000 

# создавать ли необходимые для работы приложения топики автоматически
gdl.kafka.auto-create-topics-enable=false 

# актуально только при gdl.kafka.auto-create-topics-enable=true – с каким количеством партиций создавать топики (на данный момент есть поддержка только для gdl.kafka.topic-partition-count=1)
gdl.kafka.topic-partition-count=1 

# id модуля, которое необходимо отображать при выводе метрик
gdl.module-id=gradely-module

# метка воркера, говорит воркеру, для графов с какой меткой он должен включаться в репликацию (если не заполнить, то воркер сможет подключаться к репликации в те графы, где метка также не заполнена)
gdl.module.label

# url воркера, который он сообщает консоли при регистрации, по нему консоль будет общаться воркером
gdl.module.url

# задержка в мс перед регистрацией в консоли
gdl.module.worker-registry-delay=10000

# unimonId, который будет виден при выводе метрик
gdl.unimon.id

# unimonResourceName, который будет виден при выводе метрик
gdl.unimon.rn=grdl-module

# версия приложения, которая будет видна при выводе метрик
gdl.version

# файл, в который будут писаться логи приложения
logging.file.name

# список доступных системных метрик
management.endpoints.web.exposure.include=health,info,Prometheus

# определяет порт, который будет использовать воркер
server.port 

# указывает бандл для настроек безопасности
server.ssl.bundle=server 

# устанавливает обязательность аутентификацию клиента при SSL/TLS подключении
server.ssl.client-auth=NEED 

# выбор версий протокола 
server.ssl.enabled-protocols=TLSv1.2

# выбор протокола
server.ssl.protocol=TLS 

# указывает псевдоним (alias) для ключа клиента в хранилище
spring.ssl.bundle.jks.client.key.alias=console 

# определяет путь к хранилищу ключей клиента
spring.ssl.bundle.jks.client.keystore.location

# устанавливает тип хранилища ключей клиента
spring.ssl.bundle.jks.client.keystore.type=PKCS12 

# указывает путь к доверенному хранилищу клиента
spring.ssl.bundle.jks.client.truststore.location

# устанавливает тип доверенного хранилища клиента
spring.ssl.bundle.jks.client.truststore.type=PKCS12 

# указывает псевдоним (alias) для серверного ключа в хранилище
spring.ssl.bundle.jks.server.key.alias=console 

# определяет путь к серверному хранилищу ключей;
spring.ssl.bundle.jks.server.keystore.location

# устанавливает тип серверного хранилища ключей
spring.ssl.bundle.jks.server.keystore.type=PKCS12

Пример готовой конфигурации:

gdl:
  apply-cache-size: 15
  capture-cache-size: 12000
  console:
    url: https://console-ingress.example.com
  console-integration: true
  db:
    adapter: postgres
    dialect: postgres
    ssl:
      enable: false
      sslkey: /opt/cdc/grdl/grdl-module/ssl/db_keystore.p12
  hot-reload:
    enabled: true
    vault:
      address: https://t.secrets.example.com
      clientSSLCertPath: A/APP/SERV/KV2/client_secret
      enabled: true
      enc-role-secret: NQWm1Bi7pgseK11enR4wFPjeuPP0OshV6TzKvQCjZo30jC2DNvSFf5+bEJ/mfQU0EL6iuh71FfAchREuJlqJa67WdDnalIg==
      namespace: CIXXXXXXXX_CIXXXXXXXX
      phrase-path: /opt/cdc/grdl/grdl-module/ssl/encrypt_phrase
      prefix: A/APP/SERV/KV2
      serverSSLCertPath: A/SIDEC/APP/SERV/KV2/server_secret
      vault-path: ar/worker
  kafka:
    auto-create-topics-enable: true
    topic-partition-count: 1
  kafka-consumer-queue-size: 12000
  module:
    label: 'worker_on_vm'
    url: http://vm-hostname.example.com:6884
    worker-registry-delay: 10000
  module-id: gradely-module
  unimon:
    id: 'worker_1'
    rn: grdl-module
  version: 2.3.1
logging:
  file:
    name: /opt/cdc/grdl/grdl-module/logs/module.log
management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus,metrics-requiredMetricName
server:
  port: 443
  ssl:
    bundle: server
    client-auth: NEED
    enabled-protocols: TLSv1.2
    protocol: TLS
spring:
  ssl:
    bundle:
      jks:
        client:
          key:
            alias: console
          keystore:
            location: /opt/cdc/grdl/grdl-module/ssl/client_keystore.p12
            type: PKCS12
          truststore:
            location: /opt/cdc/grdl/grdl-module/ssl/truststore.p12
            type: PKCS12
        server:
          key:
            alias: console
          keystore:
            location: /opt/cdc/grdl/grdl-module/ssl/server_keystore.p12
            type: PKCS12

Проверка результата#

Конфигурационные файлы мигрированы.

Шаг 7. Произведите полную установку GraDeLy инструментом CDJE (обязательный)#

Последовательность действий при развертывании на VM#

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

Полный список файлов сценария для установки:

• MIGRATION_FP_CONF;

• FP_CONF_CHECK;

• DB_UPDATE;

• INSTALL_RPLW_MODULE_ON_VM.

Проверка результата#

Установка проведена.

Шаг 8. Убедиться, что в БД источника создаются публикации для выбора реплицируемых таблиц (обязательный)#

Последовательность действий#

Зайдите в клиентский терминал psql, в БД источника и создайте публикацию: create PUBLICATION {имя_публикации} FOR ALL TABLES;, чтобы реплицировать все таблицы, или create PUBLICATION {имя_публикации} FOR TABLE {имя_таблицы1}, {имя_таблицы2}...; для репликации отдельных таблиц.

Механизм публикации в PostgreSQL позволяет выбирать таблицы для репликации. Выбрать таблицы также можно с помощью визуального редактора маппинга (подробнее в «Руководстве пользователя интерфейса консоли управления», однако для лучшей производительности, рекомендуется использовать механизм публикаций.

Проверка результата#

Публикация создаются.

Шаг 9. Создайте техническую таблицу в БД приемника для старта с GraDeLyID и репликации из нескольких источников в один приемник (обязательный)#

Последовательность действий#

Разверните в БД получателя архив воркера package/db/db_archive_receiver.zip для запуска на БД получателя.

Архив консоли package/db/db_archive_console.zip разворачивается на БД конфигураций по умолчанию.

Для этого в параметрах в репозитории с конфигурацией стенда в параметре ${стенд}/parameters/common.conf.yml установите переключатель «YES» для триггера на дополнительные таблицы на БД получателя.

Или пропишите и выполните в редакторе СУБД SQL-скрипт:

   CREATE TABLE schema."$GRADELY_APPLY_POSITION$" (
   thread_id int4 NOT NULL,
   trx_id int8 NULL,
   source_id int8 NOT NULL,
   internal_id int8 NULL,
   "offset" int8 NULL,
   kafka_id varchar(255) NULL,
   CONSTRAINT grdl_pk_apply_position_id PRIMARY KEY (source_id)
   );

Запуск сценария (playbook) DB_UPDATE создает таблицу $CONFLICT_RESOLUTION_TX$. Также ее можно создать вручную, выполнив следующую SQL команду:

```
   CREATE TABLE public."$CONFLICT_RESOLUTION_TX$" (
   source_id bigint NOT NULL,
   gradely_id bigint NOT NULL,
   change_vector_seq int NOT NULL,
   transaction_id bigint NOT NULL,
   table_schema varchar(128) NOT NULL,
   table_name varchar(128) NOT NULL,-
   opcode char(1) NOT NULL,
   error_code char(1) NOT NULL,
   error_message text,
   vector_data jsonb NOT NULL,
   error_handle_action char(1) NOT NULL
   PRIMARY KEY (source_id, gradely_id, change_vector_seq)
   );
```

Проверка результата#

Технические таблицы созданы.

Шаг 10. Настройте секреты в системе управления секретами HashiCorp Vault/Secret Management System (обязательный)#

Последовательность действий#

С внедрением поддержки PKI для Worker на VM меняется способ получения сертификата, с помощью которого воркер взаимодействует с внешними системами (консоль, базы данных, кафка). Важно отметить, что автоматически выпускается ровно один сертификат и переиспользуется при установлении соединения со всеми внешними системами.

1. Убедитесь, что настроены следующие параметры конфигурации:

   # включить ли чтение секретов и hot-reload 
   gdl.hot-reload.enabled=true
   
   # путь до клиентского сертификата для хранилища секретов
   gdl.hot-reload.vault.clientSSLCertPath
   
   # чтение секретов из сервиса хранилища секретов (если false – будет пытаться читать с файловой системы)
   gdl.hot-reload.vault.enabled=true
   
   # roleid/secretid в зашифрованном виде (base64), результат работы утилиты password-encrypt-cli-2.4.0.jar: java -jar password-encrypt-cli-2.4.0.jar -k <KEY> -p <roleId>/<secretId> -a PBEWithMD5AndTripleDES
   gdl.hot-reload.vault.enc-role-secret
   
   # namespace хранилища секретов
   gdl.hot-reload.vault.namespace
   
   # путь до ключа, с помощью которого шифруется roleid/secretid
   gdl.hot-reload.vault.phrase-path
   
   # префикс до секретов в хранилище секретов
   gdl.hot-reload.vault.prefix
   
   # путь до серверного сертификата хранилища секретов
   gdl.hot-reload.vault.serverSSLCertPath
   
   # путь для авторизации в хранилище секретов (например, approle или worker)
   gdl.hot-reload.vault.vault-path
   
   # путь к PKI плагину(например, PKI, SberCA)
   gdl.hot-reload.pki.mount-path
   
   # период с которым делать fetch сертификата (запрос к сервису на выдачу сертификата, который либо сгенерирует новый сертификат, либо вернет уже выпущенный, если он актуален. Критерии актуальности разнятся в зависимости от используемого сервиса и плагина для хранилища секретов, поэтому необходимо обратиться к документации используемого сервиса). Пример: 30s
   gdl.hot-reload.pki.refresh-period
   
   # CN с которым делать fetch, пример, '*.solution.sbt'
   gdl.hot-reload.pki.fetch-cn
   
   # имя роли, через которую делать fetch, например, role-ga-secman-grdl-ift
   gdl.hot-reload.pki.fetch-role
   
   # альтернативные имена доменов для fetch
   gdl.hot-reload.pki.alt-names
   
   # альтернативные ip для fetch
   gdl.hot-reload.pki.ip-sans
   
   # время жизни сертификата (лучше не заполнять, тогда возьмется максимальное из настроек сервиса хранилища секретов). Например, 30d
   gdl.hot-reload.pki.fetch-ttl
   
   # для автоматической ротации сертификатов
   spring.ssl.bundle.jks.tls.reload-on-update
   

2. Назовите секреты для БД сетевым адресом подключения к этим ресурсам, например vm-gdev-db-psql-143.vdc11.db.dev.sbt. Воркер автоматически распознает назначение этих секретов.

   Секрет с логином, паролем, сертификатами и ключом для подключения к БД:

   • PASSWORD = <Пароль ТУЗ>

   • USER = <Логин ТУЗ>

3. Platform V GraDeLy сам запрашивает автоматическое создание сертификата через pki движок сервиса для хранения секретов.

Ограничения

• Сервис репликации воркера не может запуститься или перезагрузиться без доступа к сервису хранилища секретов;

• После обновления сертификата необходимо получить исключение от БД, тогда соединение с БД будет пересоздано с новым сертификатом;

Особенность работы

• При потере доступа к SecMan репликация не прерывается, процессы продолжают исполнение на последних сертификатах

Проверка результата#

Секреты настроены.

Шаг 11. Определите максимальную производительность (обязательный)#

Последовательность действий#

Проверка результата#

Максимальная производительность определена.

Шаг 12. Настройте механизм для ограничения входящих запросов Rate Limiter (обязательный)#

Последовательность действий#

Проверка результата#

Rate Limiter настроен.

Шаг 13. Интеграция с HashiCorp Vault (SecMan) (обязательный)#

Последовательность действий при развертывании на VM#

Интеграция с Secman реализована встроенными средствами и управляется следующими параметрами конфигурации:

  gdl:
    hot-reload:
      vault:
        prefix: A/IFT/RPLW/KV2
        address: https://secman.domain.local:8443/
        namespace: DEV
        roleId: censored
        secretId: censored
        pgCertPath: A/IFT3/GRDL/KV2/pg_secret
        sslCertPath: A/IFT3/GRDL/KV2/rplw_ssl_secret

Проверка результата#

Интеграция с SecMan настроена.

Описание системных пользователей при развертывании RPLW на ВМ#

Пользователи и группы#

Описание структуры каталогов и прав доступа при развертывании RPLW на ВМ#

Структура каталогов с правами доступа: