Перейти к основному содержимому

Реплики каталога

Актуально для: directory после 1.3.7, агент после 1.0.4 · Проверено: 29.10.2026

В установке один каталог. Каждый следующий экземпляр directory — в любом метапространстве платформы — реплика того же каталога: как второй контроллер одного домена, не второе хранилище. Все экземпляры держат одни и те же учётные записи, группы, подразделения, объекты установки и схему атрибутов; каждый принимает записи своих клиентов и администраторов, и изменения расходятся между экземплярами репликацией.

Что реплицируется и как​

  • Записи. Учётные записи (вместе с хэшами паролей и секретами второго фактора — иначе реплика не сможет впускать людей), группы и членство, дерево подразделений и размещения, объекты установки (серверы, службы, площадки, политики, адресные списки) и определения схемы, включая расширения платформ. Календарь не реплицируется: он живёт на том экземпляре, где включён профиль calendar.

  • Правило конфликта — как в Active Directory. Каждый атрибут записи несёт версию, время и экземпляр последнего изменения; при расхождении побеждает бо́льшая версия, при равной — более позднее время. Многозначные атрибуты (члены группы, связи объекта) сравниваются по значению.

  • Удаление. Удалённая запись остаётся «надгробием» 14 дней, за которые о ней узнают все экземпляры; реплика, отставшая дольше, загружается заново.

  • Транспорт. Экземпляры читают друг друга по SCIM (?since= на коллекциях /scim/v2/*), каждый со своим курсором, раз в минуту, с обеих сторон. Отказ одной стороны не останавливает другую — в карточке остаётся ошибка и время последнего успешного прохода.

  • Ключи подписи и токены. Каждый экземпляр подписывает токены платформы своими ключами, но под одним именем эмитента — публичным адресом первичного экземпляра (его координатор передаёт и службам, и каждому каталогу). На каждом проходе экземпляр читает у партнёра его /oauth/jwks и публикует в своём /oauth/jwks ключи всех экземпляров установки. Поэтому токен, выданный репликой, принимает любая служба и любой каталог, на какой бы экземпляр координатор ни указывал. Закрытые ключи не передаются. В карточке экземпляра у партнёра видно число его ключей, известных этому экземпляру.

Первичный экземпляр​

Один экземпляр — первичный: у него меняется схема атрибутов (остальные перенаправляют такие запросы к нему), и он выполняет исходящие задания — рассылку в SCIM-приёмники, SIEM, синхронизацию с HRMS и вышестоящим LDAP, обновление метаданных SAML. Всё, что каталог обслуживает, — LDAP для аппаратов, вход людей, OIDC/SAML, SCIM-двери — отвечает каждый экземпляр.

Первичный по умолчанию — самый старый экземпляр. Перенести роль — Settings → Platforms → Directory → Make primary; каждый экземпляр узнаёт о переносе со следующим желаемым состоянием. Клиентам платформы объявляется имя первичного.

Как добавить реплику​

  1. Servers & deploys → Add a host → directory. Пока в установке есть живой каталог, новый экземпляр заводится как реплика автоматически (консоль передаёт это в приглашении); выберите метапространство — платформы, которую этот экземпляр будет обслуживать своим публичным именем.
  2. Хост поднимается, получает от координатора адреса остальных экземпляров и своё положение (реплика, первичный — кто) и начинает первичную загрузку: тот же проход репликации с нуля. На 50 000 учётных записей это минуты. Пока она не закончена, /healthz экземпляра отвечает replication: initial.
  3. Остальные экземпляры получают нового партнёра со своим следующим желаемым состоянием — чтение идёт в обе стороны.

Токены для репликации передавать не нужно: у всех экземпляров установки один ключ службы, и читают они друг друга служебным токеном каталога.

Состояние синхронизации в консоли​

Settings → Platforms → Directory показывает каждый экземпляр: платформу, положение (первичный или реплика), состояние репликации — current (прочитано всё до головы ленты), loading (первичная загрузка), alone (партнёров нет) — и по каждому партнёру: время последнего успешного прохода, курсоры по коллекциям, число подряд неудач и текст последней ошибки. То же отдаёт GET /healthz экземпляра в поле replication и GET /control/replication его control API.

Если партнёр долго в ошибке, причина почти всегда в сети между публичными именами экземпляров или в сертификате: реплика ходит к партнёру по его публичному имени, как клиент.