Avanpost FAM/MFA+ : 4.7. Настройка программной синхронизации

Общие сведения

Поддерживаемые версии

Данная функциональность доступна в Avanpost FAM начиная с версии 1.12

Функциональность программной синхронизации предназначена для синхронизации между узлами следующих сведений:

  • Основных атрибутов профиля пользователя;
  • Дополнительных атрибутов профиля пользователя;
  • Аутентификаторов.

Данная функциональность функционирует в режиме pull («вытягивания»): узел, которому требуется получить информацию с других узлов, подключается к узлам, с которых необходимо выполнить синхронизацию. 

Если требуется настройка двунаправленной синхронизации, то пункты указанной инструкции выполняются на двух узлах.

Описание работы механизма программной синхронизации приведено на странице описания масштабирования и кластеризации.

Инициализация механизма синхронизации

Для обеспечения возможности работы механизма программной синхронизации требуется выполнить его инициализацию.

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

  1. Установить последние миграции, т.е. выполнить migratedb (по умолчанию - логин "avanpost", база данных - "idp").
  2. Найти и отредактировать конфиг-файл базы данных postgresql.conf (ориентировочный путь размещения данного файла - /etc/postgresql/12/main/postgresql.conf, но может отличаться в зависимости от версии PostgreSQL и ОС Linux), раскомментировав, либо добавив параметры (значение параметра max_wal_replication_slots должно быть больше значения max_wal_senders):
    wal_level = logical
max_wal_senders = 10
max_wal_replication_slots = 20
  3. Перезапустить кластер СУБД PostgreSQL:
    sudo systemctl restart postgresql
  4. В PostgreSQL с помощью учетной записи суперпользователя или любой другой с соответствующими правами (например "postgres") подключиться к базе данных "idp" и выполнить:
    --
CREATE extension IF NOT exists hstore ;
  5. В PostgreSQL с помощью учетной записи суперпользователя или любой другой с соответствующими правами (например "postgres") подключиться к базе данных "idp" и создать пользователя репликации с паролем (в текущем примере создается пользователь "repladm" с паролем "repladm"): 
    --
 CREATE USER repladm WITH PASSWORD 'repladm' REPLICATION LOGIN ;
  6. Затем выполнить команды:
    --
ALTER ROLE repladm SET session_replication_role = 'replica' ;
--
GRANT ALL ON SCHEMA sync TO repladm ; 
--
GRANT ALL ON ALL TABLES IN SCHEMA sync TO repladm ;
--
GRANT ALL ON SCHEMA public TO repladm ;
--
GRANT ALL ON ALL TABLES IN SCHEMA public TO repladm ;    
--
DROP PUBLICATION IF EXISTS changes_pub ;
--
CREATE PUBLICATION changes_pub FOR TABLE sync.changes WITH (publish = 'insert') ;
--
ALTER PUBLICATION changes_pub OWNER to repladm ;
  7. Настроить параметры текущего узла синхронизации в конфигурационном файле replicator/conf.json:

    1. "memberID": свой UUID (например "33645877-70c1-45b1-b140-ab4028f1a401"; требуется уникальный UUID, сгенерированный любым удобным инструментом, к примеру, https://www.uuidgenerator.net/version4);

    2. "memberName": название текущей ноды (например "node1");

    3. "token" : токен для подключения к текущей ноде (например "token123456"; требуется секретный токен, который можно сгенерировать любым удобным инструментом, к примеру, https://it-tools.tech/token-generator);

    4. "address": адрес интерфейса GRPC текущей ноды (например "192.168.0.101:9696") - из секции grpcServer конфигурационного файла config.toml компонента Avanpost FAM Server;

    5. "postgresConnection": строка подключения к БД PostgresSQL с указанием ранее созданного пользователя (например "postgres://repladm:repladm@192.168.0.83:5432/idp");

    6. "retrieveIntervalInSeconds": периодичность pull-запросов (время между запросами в секундах) в другие ноды об измененных данных.
    7. "retrieveLimits": лимит изменений записей (строк) по каждой таблице для случаев, когда нода предоставляет diff-списки и notExist-списки

      Например, было 1200 изменений (update) существующих пользователей (в таблице "users") и было добавлено 1899 пользователей (в таблице "users"). При первом запросе в diff-список будет содержать 1000 изменений, notExist-список - 1000. При втором запросе diff-список будет содержать 200 изменений, notExist-список - 899.

    8. "postgresVersionBelow14": если PostgreSQL версии 12 или 13 задать значение true. Если версия выше, задать false, также допускается убрать параметр из конфиг-файла.

    9. "coordinator": является ли сервер координатором (по умолчанию false);

    10. "cluser" -> "allMembers": перечислить массивом все uuid всех нод кластера;

    11. "tls" -> настройки шифрования tls

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

Подключение удалённого узла к текущему узлу

Для подключения текущего узла к удалённым узлам необходимо настроить секции syncFrom и allMembers раздела cluster в конфигурационном файле replicator/conf.json. Для это отредактировать конфигурационный файл replicator/conf.json

  1. В секции "cluser" -> "syncFrom" указать другие параметры подключения к другим узлам синхронизации, с которых мы хотим получать обновления, например:
    "syncFrom": [
        {
            "memberID": "303429e3-5c5c-4169-8dc0-6b042824ac7c",
            "memberName": "node2",
            "address": "localhost:9797",
            "token": "token123456"
        },
        {
            "memberID": "2cf88875-ea5c-4507-928b-acaf44e05628",
            "memberName": "node3",
            "address": "localhost:9898",
            "token": "token123456"
        }
]
  2. Заполнить остальные параметры конфига: "cluser" -> "allMembers": перечислить массивом все uuid всех нод кластера:
  3. Выполнить команду ./replicator -reinit -c /path/to/conf.json
    для инициализации метахранилища. может занять определенное время в зависимости от количества записей в базе (в среднем до нескольких минут).
    (чтобы команда отработала корректно в папке с replicator должны лежать файлы "tables.toml" и "views-sql.toml")
  4. Запустить ./replicator -c /path/to/conf.json
    можно запускать с флагом (--debug для отладки)
  5. На других нодах проделать всё тоже самое, только в "syncFrom" указать остальные ноды синхронизации. 

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

Приложение 1. Пример заполненного конфигурационного файла в рамках кластера:

Пример заполненного файла конфигурации replicator/conf.json:

{
    "memberID": "33645877-70c1-45b1-b140-ab4028f1a401",
    "memberName": "node1",
    "token" : "token123456",
    "address": "0.0.0.0:9696",
     "tls": {
        "enabled": false,
        "certPath": "",
        "key": ""
    },
    "postgresConnection": "postgres://repladm:repladm@192.168.0.101:5432/idp",
    "retrieveIntervalInSeconds": 15,
    "retrieveLimits": 1000,
    "coordinator": false,
    "cluster": {
        "syncFrom": [
            {
                "memberID": "303429e3-5c5c-4169-8dc0-6b042824ac7c",
                "memberName": "node2",
                "address": "localhost:9797",
                "token": "token123456",
                "tls": {
                    "enabled": false,
	                "skipVerify": false,
	                "useSystemRootCA": false,
	                "certPath": ""
                }
            },
            {
                "memberID": "2cf88875-ea5c-4507-928b-acaf44e05628",
                "memberName": "node3",
                "address": "localhost:9898",
                "token": "token123456",
                "tls": {
                    "enabled": false,
	                "skipVerify": false,
	                "useSystemRootCA": false,
	                "certPath": ""
                }
            }
        ],
        "allMembers": [
                        "33645877-70c1-45b1-b140-ab4028f1a401",
                        "303429e3-5c5c-4169-8dc0-6b042824ac7c",
                        "2cf88875-ea5c-4507-928b-acaf44e05628"
        ]
    }
}


Обсуждение