Общие сведения
Поддерживаемые версии
Данная функциональность доступна в Avanpost FAM начиная с версии 1.12
Функциональность программной синхронизации предназначена для синхронизации между узлами следующих сведений:
- Основных атрибутов профиля пользователя;
- Дополнительных атрибутов профиля пользователя;
- Аутентификаторов.
Данная функциональность функционирует в режиме pull («вытягивания»): узел, которому требуется получить информацию с других узлов, подключается к узлам, с которых необходимо выполнить синхронизацию.
Если требуется настройка двунаправленной синхронизации, то пункты указанной инструкции выполняются на двух узлах.
Описание работы механизма программной синхронизации приведено на странице описания масштабирования и кластеризации.
Инициализация механизма синхронизации
Для обеспечения возможности работы механизма программной синхронизации требуется выполнить его инициализацию.
Для этого необходимо выполнить следующие действия:
- Установить последние миграции, т.е. выполнить migratedb (по умолчанию - логин "
avanpost", база данных - "idp"). - Найти и отредактировать конфиг-файл базы данных 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
- Перезапустить кластер СУБД PostgreSQL:
sudo systemctl restart postgresql
- В PostgreSQL с помощью учетной записи суперпользователя или любой другой с соответствующими правами (например "postgres") подключиться к базе данных "idp" и выполнить:
-- CREATE extension IF NOT exists hstore ;
- В PostgreSQL с помощью учетной записи суперпользователя или любой другой с соответствующими правами (например "
postgres") подключиться к базе данных "idp" и создать пользователя репликации с паролем (в текущем примере создается пользователь "repladm" с паролем "repladm"):-- CREATE USER repladm WITH PASSWORD 'repladm' REPLICATION LOGIN ;
- Затем выполнить команды:
-- 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 ;
- Настроить параметры текущего узла синхронизации в конфигурационном файле
replicator/conf.json:"
memberID": свой UUID (например "33645877-70c1-45b1-b140-ab4028f1a401"; требуется уникальный UUID, сгенерированный любым удобным инструментом, к примеру, https://www.uuidgenerator.net/version4);"memberName": название текущей ноды (например "node1");
"
token" : токен для подключения к текущей ноде (например "token123456"; требуется секретный токен, который можно сгенерировать любым удобным инструментом, к примеру, https://it-tools.tech/token-generator);"
address": адрес интерфейса GRPC текущей ноды (например "192.168.0.101:9696") - из секцииgrpcServerконфигурационного файлаconfig.tomlкомпонента Avanpost FAM Server;"
postgresConnection": строка подключения к БД PostgresSQL с указанием ранее созданного пользователя (например, "postgres://repladm:repladm@192.168.0.83:5432/idp");"retrieveIntervalInSeconds": периодичность pull-запросов (время между запросами в секундах) в другие ноды об измененных данных."retrieveLimits":лимит изменений записей (строк) по каждой таблице для случаев, когда нода предоставляет diff-списки и notExist-спискиНапример, было 1200 изменений (
update) существующих пользователей (в таблице "users") и было добавлено 1899 пользователей (в таблице "users"). При первом запросе в diff-список будет содержать 1000 изменений, notExist-список - 1000. При втором запросе diff-список будет содержать 200 изменений, notExist-список - 899."metaTablesUnlogged": включение/выключение ведения таблиц метаинформации в журнале WAL (по умолчаниюfalse)."kvDataDirPath": путь к встроенному хранилищуkey-value, где будет содержаться часть метаинформации, необходимой для репликации данных (по умолчанию/kv_data/).При запуске Avanpost FAM Server пользователю, от имени которого запускается репликатор, следует предоставить доступ на запись и чтение файлов из папки, где расположено хранилище
key-value:- Ввести команды изменения прав доступа:
chmod 750 kv_data chmod u+rw kv_data
- Изменить владельца папки (при необходимости) при помощи команды (в качестве значения
/path_to_kv_dataуказать путь к папке/kv_data/):sudo chown -R idp:idp /path_to_kv_data
- Ввести команды изменения прав доступа:
- "
postgresVersionBelow14": если PostgreSQL версии 12 или 13 задать значение true. Если версия выше, задатьfalse, также допускается убрать параметр из конфиг-файла. "
coordinator": является ли сервер координатором (по умолчаниюfalse);"
cluser" -> "allMembers": перечислить массивом все uuid всех нод кластера;- "
tls" -> настройки шифрования tls
Инициализация механизма программной синхронизации на узле успешно выполнена, но запуск механизма выполняется по мере добавления других узлов.
Подключение удалённого узла к текущему узлу
Для подключения текущего узла к удалённым узлам необходимо настроить секции syncFrom и allMembers раздела cluster в конфигурационном файле replicator/conf.json. Для это отредактировать конфигурационный файл replicator/conf.json
- В секции "
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" } ] - Заполнить остальные параметры конфига: "
cluser" -> "allMembers": перечислить массивом все uuid всех нод кластера: - Выполнить команду .
/replicator -reinit-c/path/to/conf.json
для инициализации метахранилища. может занять определенное время в зависимости от количества записей в базе (в среднем до нескольких минут).
(чтобы команда отработала корректно в папке с replicator должны лежать файлы "tables.toml" и "views-sql.toml") - Запустить .
/replicator-c/path/to/conf.json
можно запускать с флагом (--debugдля отладки) - На других нодах проделать всё тоже самое, только в "
syncFrom" указать остальные ноды синхронизации.
После этого можно редактировать/удалять/создавать пользователей на любом из узлов кластера, и изменения через некоторое время распространятся на другие узлы кластера.
Обновление кластера
Для обновления механизмов синхронизации (при переходе с FAM Server версии 1.14.13 и ниже на версию 1.15+) требуется выполнить следующие действия:
- Перед началом обновления совершить следующие действия:
- Выполнить резервное копирование базы данных на всех узлах и заархивировать конфигурационные файлы.
- Убедитесь, что все изменения на всех узлах реплицированы и отсутствуют задержки синхронизации.
- Проверить статус репликатора на всех узлах:
systemctl status replicator
- На каждом из узлов остановить службы idp и репликатор, используя команду:
sudo systemctl stop idp sudo systemctl stop replicator
- На мастер-узле (в случае мультимастерной конфигурации мастер-узел определяется вручную) выполнить обновление Avanpost FAM Server согласно инструкции.
- Выполнить миграцию, используя команду:
cd /opt/idp ./fam_linux_amd64 -migratedb postgres
В процессе миграции будут автоматически сформированы таблицы
authentication_methods(таблица с методами аутентификации) иauthenticators(таблица с привязками аутентификаторов к пользователям). После завершения миграции FAM (службу Idp) не запускать. - Подключитесь к БД
idpот имени суперпользователя или пользователя idp:sudo -u postgres psql idp
- Выполнить следующие команды:
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;
- Выйти из PostgreSQL:
\q
- Обновить компонент репликатора: замените файлы: tables.toml, views-sql.toml и replicator. Убедиться, в tables.toml и views-sql.toml добавлены "authentication_methods" и "authenticators".
- Выполнить реинициализацию репликатора:
./replicator -reinit
Не стоит запускать службу
replicatorиidpна мастер-узле до завершения обновления всех слейв-узлов. - Обновить все ведомые узлы:
- Обновить FAM Server и применить миграции по аналогии с мастер-узлом.
- Во избежание дублирования данных при последующей синхронизации следует очистить таблицу "authenticators":
psql -U avanpost -d idp -c "TRUNCATE public.authenticators;"
- Повторить шаги, описанные в пунктах 5 - 9 данной инструкции, для оставшихся слейв-узлов.
- После завершения обновления запустить службы на узлах (сперва запускаются службы на мастер-узле, затем на каждом слейв-узле):
sudo systemctl start replicator sudo systemctl start idp
- Убедиться в корректности обновления:
- Проверить статус служб:
systemctl status idp replicator
- Убедиться, что таблице authentication_methods имеются записи:
SELECT * FROM authentication_methods;
- Убедиться, что таблица
authenticatorsзаполняется при привязывании аутентификаторов. - Убедиться, что методы аутентификации в административной консоли отображаются корректно, а аутентификация пользователей проходит согласно настроенному сценарию.
- Проверить статус служб:
Приложение 1. Пример заполненного конфигурационного файла в рамках кластера:
Пример заполненного файла конфигурации replicator/conf.json:
{
"memberID": "33645877-70c1-45b1-b140-ab4028f1a401",
"memberName": "node1",
"token" : "token123456",
"address": "0.0.0.0:9696",
"tls": {
"enabled": false,
"certPath": "",
"keyPath": ""
},
"postgresConnection": "postgres://repladm:repladm@192.168.0.101:5432/idp",
"retrieveIntervalInSeconds": 15,
"retrieveLimits": 1000,
"coordinator": false,
"metaTablesUnlogged": false,
"kvDataDirPath": "kv_data",
"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"
]
}
}