Кластер HA: создание и обслуживание

Содержание

1. Что даёт кластер HopeDC

Кластер HopeDC — это несколько равноправных контроллеров домена (узлов), которые синхронизируют между собой каталог, DNS, доверительные отношения, доменную политику безопасности и конфигурацию DHCP‑пулов. Схема мульти‑мастер: писать можно на любом узле, изменения расходятся на остальные. Это повышает доступность (при отказе одного узла клиенты обслуживаются другими) и позволяет распределять нагрузку.

Согласованность — итоговая (eventual): после сетевых задержек и простоев узлы сходятся к одинаковому состоянию. Конфликты (одновременная правка одного объекта на разных узлах) разрешаются автоматически по правилу «последняя запись побеждает» (Last‑Writer‑Wins, см. раздел 6).

2. Архитектура репликации

Модель обмена — pull: каждый узел раз в ~15 секунд сам забирает изменения у настроенных пиров, а не рассылает их. Ключевые элементы:

• node_id — постоянный идентификатор узла (UUID), генерируется один раз при первом старте и хранится в конфигурации кластера.
• USN — монотонный счётчик изменений на каждом узле‑источнике (origin). Каждое локальное изменение получает следующий USN.
• Журнал событий репликации — кольцевой буфер последних изменений (до 8000 событий) с полями origin, usn, ts (время), payload (что изменилось). Хранится в файле repl_journal.bin в каталоге данных.
• Водяные знаки (watermarks) — по каждому origin узел помнит максимальный увиденный USN. При pull он просит у пира «всё, что новее моих watermark». Благодаря этому вернувшийся после простоя узел ничего не пропускает — он догоняет все изменения, которых у него нет (пока они живы в кольце из 8000 событий у пира).
• Бутстрап снимком — при первом контакте с пиром узел один раз забирает полный снимок каталога, DNS, доверий, политики безопасности и DHCP‑пулов (/api/replication/snapshot) и добавляет недостающие записи. Дальше идёт только инкрементальный pull.
• Транзитивность — применённое чужое событие тоже попадает в локальный журнал и раздаётся дальше, поэтому изменения доходят и до узлов, не связанных напрямую.

Весь обмен идёт по HTTPS на порту API 9444. Узел аутентифицируется одним из двух способов: общим секретом кластера (заголовок X-Cluster-Secret) — полное взаимное доверие и обмен всеми доменами; либо личным токеном сопряжения пары (заголовок X-Replica-Token) — для региональных узлов с ограниченным разделом (отдаются только их домены, см. раздел 10). Без действующего секрета или токена узел отвечает HTTP 401. Межузловые эндпоинты: /api/replication/pull, /api/replication/snapshot, /api/replication/digest.

Проверка сертификата узла

Узел, подключаясь к пиру, проверяет его сертификат — иначе подставной узел мог бы получить секрет кластера и данные каталога:

1. Сертификат выпущен ЦС домена. Если в домене настроен центр сертификации (корневой ЦС домена есть после выпуска первого сертификата в разделе PKI), каждый узел предъявляет сертификат от этого ЦС с адресами узла (IP из DC_SELF_IP, адрес основного интерфейса, DC_WEB_EXTRA_SAN). Пиры проверяют цепочку до ЦС своего домена и совпадение адреса из URL пира. Это основной режим — ничего настраивать не нужно.
2. Закреплённый отпечаток. Если ЦС нет, узел использует постоянный самоподписанный сертификат (создаётся один раз и хранится зашифрованным в каталоге данных). Пир сверяет его SHA‑256 с отпечатком, закреплённым в настройках пира. Отпечаток можно вписать заранее: он показан на самом узле в карточке «Этот узел» (Кластер → Узлы и репликация, кнопка копирования).
3. Первое подключение. Если отпечаток не задан, сертификат принимается при первом подключении и после успешного обмена запоминается; в журнале появляется строка 🔐 Кластер: запомнен сертификат узла … — сверьте отпечаток с карточкой «Этот узел» на соседнем узле.

Если сертификат пира не проходит проверку ЦС и не совпадает с закреплённым отпечатком, связь с ним прекращается, а в статусе пира и журнале выводится «сертификат узла изменился: … вместо закреплённого …». Если узел действительно переустановлен или сменил сертификат, сверьте новый отпечаток на нём и нажмите «Сбросить» у этого пира (или впишите новый отпечаток) и сохраните настройки.

3. Что реплицируется, а что нет

Важно понимать границы репликации — это влияет на планирование кластера.

4. Требования и подготовка

Сеть

• Между узлами открыт TCP 9444 в обе стороны. Рекомендуется выделенная/доверенная сеть управления.
• Узлы адресуются по базовому URL API (порт 9444), напр. https://10.0.0.2:9444 — это адрес бэкенда, а не веб‑интерфейса. Если перед API стоит HTTPS/обратный прокси — используйте соответствующий URL.

Синхронизация времени (обязательно)

Прочее

• Одинаковая версия HopeDC на всех узлах.
• Один и тот же секрет кластера на всех узлах — произвольная длинная строка, храните её в тайне.
• Каталог данных на каждом узле — свой (репликация синхронизирует содержимое, а не файлы).

5. Создание кластера пошагово

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

Шаг 1. Первый узел — источник данных

Поднимите первый узел и наполните каталог (создайте домен, учётки, DNS) как обычно. Затем откройте Настройки → Кластер (HA), вкладка «Узлы и репликация»:

1. Задайте Имя узла (для удобства, напр. dc-01). ID узла уже сгенерирован автоматически.
2. Задайте Общий секрет кластера — придумайте длинную строку.
3. Включите переключатель репликации (вверху карточки настройки узла).
4. Нажмите Сохранить настройки кластера.

Шаг 2. Второй узел — присоединение

Второй узел запускайте в режиме присоединения, чтобы он не создавал собственный демо‑домен hope.local: задайте службе переменную окружения DC_JOIN_CLUSTER=1 до первого запуска (например, строкой Environment=DC_JOIN_CLUSTER=1 в unit‑файле или файле /etc/systemd/system/hopedc.service.d/). Узел с пустым каталогом в этом режиме создаёт только учётную запись панели admin и ждёт данных от пира; в журнале — «Режим присоединения к кластеру: демо‑домен не создаётся». Тот же режим включается автоматически, если на пустом узле ещё до первого запуска лежит настроенный cluster_config.json с пирами. После присоединения переменную можно убрать — на непустом каталоге она ни на что не влияет.

Затем на втором узле в разделе Кластер (HA):

1. Задайте Имя узла (напр. dc-02) и тот же секрет кластера, что на первом.
2. Нажмите Добавить узел и впишите URL первого узла: https://10.0.0.1:9444.
3. Включите репликацию и Сохранить.

При первом контакте второй узел выполнит бутстрап: заберёт снимок каталога, DNS, доверий, политики безопасности и DHCP‑пулов у первого. Дальше пойдёт инкрементальная синхронизация.

Шаг 3. Встречное направление

Чтобы изменения расходились в обе стороны, на первом узле добавьте пира — URL второго (https://10.0.0.2:9444) и сохраните. В мульти‑мастере каждый узел тянет у каждого.

Шаг 4. Проверка

• На вкладке «Узлы и репликация» у пиров должен появиться статус онлайн и счётчик «применено».
• Кнопка «Реплицировать сейчас» запускает внеочередной проход.
• Создайте тестовый объект на одном узле — через несколько секунд он появится на другом.
• Откройте вкладку «Согласованность» и нажмите «Проверить сейчас» — по пиру должно быть Сошлись.

6. Разрешение конфликтов (LWW)

Если один и тот же объект изменён на двух узлах до того, как они синхронизировались, возникает конфликт. HopeDC разрешает его автоматически правилом Last‑Writer‑Wins:

победитель = у кого больше ts (время изменения);
при равном ts — у кого больше node_id (детерминированный добор)

Три свойства, которые важно понимать:

• Гранулярность — весь объект. Сравнение идёт по объекту целиком (по его UUID), а не по отдельным атрибутам. Победившая версия полностью замещает проигравшую; изменения разных полей на проигравшей стороне не сливаются, а теряются.
• Удаление против правки. Удаление тоже участвует в LWW по времени. Если правка новее удаления — объект «воскресает»; если удаление новее — остаётся удалённым.
• Разные объекты — без конфликта. Если на узлах правили разные объекты, обе правки сохранятся.

Подводные камни

7. Наблюдаемость: конфликты, возвраты, согласованность

Раздел Кластер (HA) содержит четыре вкладки. Кроме «Узлы и репликация» — три инструмента наблюдаемости.

Журнал конфликтов

Фиксирует случаи, когда изменение с этого узла столкнулось с изменением того же объекта на другом узле. Каждая запись показывает объект, что сохранилось (победитель: узел + время) и что затёрлось (проигравшая версия перечёркнута), а также принято ли входящее изменение или отклонено (наша версия оказалась новее). Записи ведутся на обоих узлах — у проигравшего «затёрлось», у победителя «отклонено чужое», — что даёт полную картину.

Хранится в repl_conflicts.json (кольцо на 2000 записей). Кнопка «Очистить журнал» сбрасывает его.

Возвраты узлов

Когда пир возвращается после недоступности, HopeDC догоняет пропущенные изменения. Вкладка показывает сводку каждого догона: простой пира, сколько событий догнано (из полученных), сколько было конфликтов, из них — затёрто локальных (ваши изменения заменены версией пира) и отклонено чужих, и число проходов. Если были перезаписи локальных — карточка подсвечивается и отсылает к «Журналу конфликтов». Долгий догон (более 500 событий за проход) агрегируется в один отчёт.

Хранится в repl_reconnects.json (кольцо на 500 записей).

Согласованность

Сверяет отпечаток (дайджест) реплицируемого состояния с каждым узлом. Дайджест считается детерминированно и порядко‑независимо отдельно по каталогу, DNS, доверительным отношениям и DHCP‑пулам, плюс отдельный хеш доменной политики безопасности (эндпоинт /api/replication/digest). По каждому пиру выводится статус: Сошлись, Расхождение или «Нет связи», с разбивкой по каталогу, DNS, доверию, политике и DHCP‑пулам (сколько объектов «здесь» и «там» и совпадает ли содержимое). Кнопка «Проверить сейчас» запускает сверку.

8. Обслуживание: вывод, возврат и замена узла

Плановый вывод узла

Просто остановите узел. Остальные продолжат работать; клиентов переключит DNS/локатор на живые узлы. Изменения, сделанные на живых узлах во время простоя, накапливаются в их журналах.

Возврат узла

Запустите узел снова. Он автоматически догонит пропущенное по watermark. Проверьте вкладку «Возвраты узлов» — там появится отчёт о догоне, и вкладку «Согласованность» — статус должен стать Сошлись. Если во время простоя те же объекты правились и на вернувшемся узле, часть его локальных правок могла быть затёрта по LWW — детали в «Журнале конфликтов».

Долгий простой: автоматическая пересинхронизация

Каждый узел хранит в журнале последние 8000 изменений. Если узел отсутствовал дольше (или на пире за это время прошёл массовый импорт), часть событий из журнала пира уже вытеснена. С v126 узел обнаруживает такой разрыв сам: пир сообщает нижнюю границу своего журнала, и если наш водяной знак ниже неё, в журнале появляется предупреждение 🔁 Репликация: пропущены события узла … и узел выполняет пересинхронизацию по снимку:

• пир отдаёт снимок данных вместе с версиями (LWW) каждой записи, водяными знаками и «надгробиями» удалённых записей;
• узел сводит снимок со своими данными по правилу «последняя запись побеждает»: недостающее добавляется, устаревшее обновляется, удалённое на пире удаляется (только если удаление строго новее локальной версии), более новые локальные правки сохраняются и уйдут пирам обычной репликацией;
• сведение не порождает ответных событий репликации; итог — строка 🧩 Пересинхронизация от …: добавлено N, обновлено N, удалено N (T с).

Пересинхронизацию можно запустить и вручную — кнопка «Пересинхронизировать» на вкладке «Узлы и репликация» (право cluster.edit). На 200 тыс. объектов она занимает 5–10 секунд. Пока узел сам принимает снимок, отдавать снимок другим он отказывается (HTTP 503) — так не распространяются неполные данные.

Замена узла / повреждённые данные

Если данные узла повреждены — пересоберите его с нуля: остановите службу, очистите каталог данных узла (сохранив cluster_config.json) и запустите — узел присоединится заново бутстрапом снимком. На 200 тыс. объектов бутстрап занимает около 12 секунд после запуска службы.

Шифрование данных и узлы кластера

У каждого узла свой мастер‑ключ шифрования данных на диске (по умолчанию /etc/hopedc/master.key). Ключи узлов не обязаны совпадать и не передаются по сети: узел отдаёт изменения пиру по HTTPS (порт 9444), а принимающий узел записывает их на диск, зашифровав своим ключом. Поэтому:

• для присоединения нового узла или пересборки узла с нуля ключ другого узла не нужен — бутстрап снимком работает как прежде;
• копию ключа (.hdckey под паролем) нужно сохранить для каждого узла — раздел «Резервное копирование» на каждом узле;
• бэкап одного узла можно восстановить на другом, указав при восстановлении файл .hdckey исходного узла — данные будут перешифрованы на ключ узла, на котором идёт восстановление;
• каталог данных одного узла нельзя просто скопировать на другой узел: нужен и ключ исходного узла (hopedc-core key import). Предпочтительный путь — бутстрап снимком.

Подробнее — Документ 2, раздел «Шифрование данных на диске и мастер‑ключ».

Смена ключа krbtgt в кластере

Ключ krbtgt хранится в объекте каталога и реплицируется, как любое изменение. Ручную смену выполняйте на одном узле (Домены → домен → «Ключи Kerberos»; у каждого домена свой ключ): новый ключ доходит до остальных узлов со следующим проходом репликации (обычно до 15 секунд). Предыдущий ключ принимается всеми узлами до следующей смены, поэтому выданные ранее билеты работают на любом узле. В короткое окно до репликации билет, выданный узлом с новым ключом, другой узел может не принять — клиент повторит запрос.

• Плановая смена. Настройки (напоминание, период) задаются для каждого домена и общие для кластера — хранятся в корне домена и реплицируются. Смену выполняет один узел: с наименьшим идентификатором среди доступных узлов с полной репликой (на вкладке «Ключи Kerberos» видно, какой). Если он недоступен, задачу берёт следующий; перед сменой узел забирает изменения у пиров. Чтобы узлы одинаково видели друг друга, настраивайте пиров в обе стороны.
• Региональные серверы получают смену krbtgt своего поддомена от центрального сервера. Обратное запрещено: материал krbtgt от регионального узла центр не принимает.
• Проверить, что ключ дошёл: на каждом узле на вкладке домена «Ключи Kerberos» должна быть одинаковая версия ключа (kvno), а вкладка «Согласованность» — показывать «Сошлись».

Проверка сертификата LDAPS контроллеров AD

Закреплённый отпечаток сертификата DC, сохранённые ЦС AD и имя DC (см. Документ 2, «Проверка подлинности контроллера AD») реплицируются вместе с корнем интегрированного домена. Любой узел кластера проверяет DC одинаково. Сброс или закрепление отпечатка на одном узле действует на всех. Сведения о последнем отказе проверки («DC предъявил другой сертификат») показываются на том узле, где он произошёл.

Вывод Windows‑DC в кластере

Приём роли KDC и отключение домена от AD (Документ 2, п.4.9) выполняйте на одном центральном узле. Ключи krbtgt и отметки домена (роль KDC принята, домен мигрирован) реплицируются: остальные узлы начинают выдавать билеты тем же ключом и прекращают синхронизацию с AD со следующей репликацией.

Контроллер только для чтения (RODC) (v171–v177)

RODC — узел, который держит копию каталога только для чтения и кэширует пароли лишь для заранее разрешённых учёток. Его ставят там, где нельзя полностью доверять физической защите: филиалы, удалённые площадки, DMZ. Если такой узел украдут или вскроют, под угрозой окажутся только кэшированные на нём пароли, а не весь домен.

Как включить. При установке узла задайте переменную окружения DC_RODC=1 (режим хранится в конфигурации кластера; в разделе «Кластер» у такого узла — метка «RODC · только чтение»). RODC настраивается как обычный региональный узел: он тянет каталог с записываемого контроллера (пир с указанным URL), а сам наружу ничего не отдаёт — репликация односторонняя.

• Только чтение. Правки каталога на RODC отклоняются: LDAP add/modify/delete → unwillingToPerform с пояснением; панель на запрос изменения данных домена (каталог, интеграция, GPO, DNS, доверия, DHCP, PKI) отвечает «это контроллер только для чтения». Менять нужно на записываемом контроллере — изменение придёт на RODC репликацией. Конфигурация самого узла (кластер, сеть, обновления) доступна.
• Кэширование паролей (PRP). Какие учётки RODC может кэшировать, задаёт атрибут hopeRodcAllowed на корне домена (на записываемом контроллере): список DN/SID учёток и групп — для групп берутся их прямые члены. По умолчанию (список пуст) RODC не кэширует ни одного пароля. Секреты (NT-хэш, ключи Kerberos, история паролей и т. п.) неразрешённых учёток вычищаются при приёме снимка и фоновой проверкой.
• Персональный krbtgt узла (v172). На записываемом контроллере для каждого RODC заводится отдельная учётка krbtgt_rodc_<id> (кнопка в разделе «Кластер» или POST /api/cluster/rodc-krbtgt). RODC шифрует свои TGT этим ключом; мастер принимает их, пробуя сначала свой krbtgt, затем ключи RODC. Отзыв билетов украденного узла — поворот (rotate) его krbtgt_rodc_* на мастере, не трогая остальной домен. Общий мастер‑krbtgt и чужие krbtgt_rodc_* на RODC не хранятся — с украденного узла нельзя подделать «золотой билет» доменным ключом.
• Доменные ключи подписи сняты (v172). С RODC вычищаются закрытый ключ ЦС (hopeCaKeyPem), ключ KDC для PKINIT (hopePkinitKdcKeyPem) и секрет синхронизации (hopeSyncSecret). Поэтому с украденного филиального узла нельзя выпускать сертификаты домена, подделывать смарт‑карточный вход или получить секрет доверия. Для своего TLS (LDAPS/HTTPS) RODC без ключа ЦС переходит на постоянный самоподписанный сертификат узла — работа LDAP/панели/репликации не нарушается (репликация односторонняя, узел тянет и наружу сертификат не навязывает).
• Вход. Разрешённая учётка входит на RODC обычным образом (её ключи закэшированы). Неразрешённой на RODC ключей нет — вход по ней должен пройти на записываемом контроллере (RODC отвечает «клиент не найден», клиент переходит к другому KDC из своей конфигурации). Смена пароля (kpasswd) и вход по смарт‑карте (PKINIT) на RODC не выполняются — узел отвечает отказом с указанием обратиться к записываемому контроллеру.

Сопряжение RODC с мастером — только токеном пары (v177)

1. На RODC в разделе «Кластер» скопируйте его node_id (кнопка копирования в карточке «Этот узел»).
2. На мастере добавьте пира: имя (например, «Филиал»), URL — пусто (RODC тянет у мастера, мастер у него — нет), домены обмена — домен филиала или «*», токен пары — «Сгенерировать», и отметьте «Этот узел — RODC» с node_id из п.1. Сохраните; токен скопируйте.
3. На RODC у пира-мастера задайте тот же токен пары и домены, сохраните. Проверьте, что репликация идёт (счётчик принятых событий, нет ошибки).
4. На RODC нажмите «Удалить общий секрет» в красном предупреждении. Без токена у пира-мастера кнопка откажет — чтобы не остановить репликацию.
5. На узлах полного доверия смените общий секрет кластера (секрет мог быть скопирован с RODC).

Защиты от ошибок: на RODC нельзя задать общий секрет (сохранение отклоняется); пометку «RODC» нельзя сохранить без токена пары и node_id; старый клиент API, не знающий о пометке, её не снимает. Пока RODC знает секрет, в журнале и в разделе «Кластер» висит предупреждение.

Интеграция с MS AD в кластере (v157)

Пароль учётки синхронизации реплицируется на все узлы (как пароль доверия: на диске зашифрован мастер-ключом узла, по LDAP и API не отдаётся). Синхронизацию каталога, импорт DNS и доверий из AD ведёт один узел — держатель аренды, которую он продлевает каждой успешной синхронизацией (атрибут корня домена). Остальные узлы пишут в журнал «синхронизацию с AD ведёт узел …» и не опрашивают AD. Если ведущий не синхронизирует дольше трёх интервалов + минуты (плюс сдвиг узла до 2 минут), аренду забирает другой узел — в журнале «синхронизацию с AD берёт этот узел». Вернувшийся прежний ведущий роль обратно не забирает. «Синхронизировать сейчас» на любом узле делает ведущим этот узел. Запись по LDAP и правки из панели для интегрированного домена выполняются в AD с любого узла (Документ 2, п.4.9). Сквозная проверка паролей идёт с каждого узла напрямую к DC AD (636).

Доверительные отношения в кластере

Доверие хранится и как запись доверия, и как реплицируемый объект trustedDomain (CN=System домена). В объекте — направление, тип, атрибуты, SID партнёра, суффиксы леса (TLN), время смены пароля и сам пароль доверия (внутренний атрибут: по LDAP не отдаётся, на диске зашифрован мастер‑ключом узла). Поэтому на любом узле кластера доверие видно Windows‑клиентам, ключи Kerberos доверия при необходимости восстанавливаются, а смену пароля может выполнить любой узел. Автоматическую смену пароля доверия (DC_TRUST_ROTATE=1) выполняет тот же единственный выбранный узел, что и плановую смену krbtgt.

Смена пароля и блокировка учёток в кластере

Сменить пароль (kpasswd, Ctrl+Alt+Del) можно на любом узле — новый пароль расходится по кластеру как любое изменение каталога. Политика блокировки задаётся в Default Domain Policy и одинакова на всех узлах. Неверные попытки считает тот узел, к которому обратился клиент; когда счётчик на узле достигает порога, учётке записывается lockoutTime, и блокировка действует на всех узлах. Поэтому подбор пароля, распределённый по N узлам, получит не больше N×порог попыток до блокировки — учитывайте это при выборе порога. Счётчики всех узлов видны в свойствах учётки (вкладка Account → «Состояние входа», таблица по контроллерам, v142) — по ним видно, на какой контроллер шёл подбор. Снять блокировку можно на любом узле кнопкой «Разблокировать» (она обнуляет счётчики и на остальных узлах) или записью lockoutTime=0.

Обновление версии узлов (v147)

Узлы обновляются по очереди из раздела Настройки → Обновления панели каждого узла (Документ 2, п.7). Там же видны версии всех узлов кластера. Пока узел перезапускается (секунды), клиентов обслуживают остальные; после старта он догоняет изменения обычной репликацией. Разные версии на узлах допустимы на время поэтапного обновления; региональные серверы обновляйте после центрального.

Из раздела «Контроллеры» (v188). Узлы, добавленные в «Контроллеры», обновляются по SSH: по одному или все контроллеры домена кнопкой «Обновить контроллеры домена», до пакета из «Обновлений» (если он новее) или до версии узла, с которого запущено обновление. Так обновляются и региональные узлы и RODC, которые обновление «всего кластера» пропускает. Первая ошибка останавливает обход; установщик сам возвращает прежнюю версию, если новая не запустилась. Корневой сервер так не обновляется — только из его «Обновлений» полным администратором.

Обновление всего кластера одной кнопкой (v176)

В разделе Обновления узла с подготовленным пакетом (загружен или скачан) есть блок «Весь кластер одной кнопкой». Узел, на котором нажали кнопку, становится координатором и обновляет остальные по одному:

1. Предпроверка. Каждый узел, который нужно обновить, доступен, на нём установлен механизм применения обновлений (hopedc-update) и не идёт другая установка. Если хоть одно условие не выполнено — обновление не начинается, ничего не меняется; панель называет, что устранить.
2. По узлу за раз: передача пакета → установка (с теми же проверками, что при загрузке вручную, плюс сверка версии и SHA-256) → ожидание, пока узел ответит новой версией → проверка через 15 секунд, что он на ней и остался.
3. При сбое — стоп. Если узел откатился, не вернулся за 15 минут или установщик сообщил об успехе, а узел работает на прежней версии, обновление останавливается: следующие узлы и сам координатор не трогаются. Причина видна в таблице.
4. Координатор — последним. Итог («все узлы на vNNN» или ошибка) сохраняется и виден после его перезапуска.

Кнопка «Остановить после текущего узла» прерывает обход (текущий узел доводится до конца). Узлы, уже работающие на целевой версии, пропускаются.

Лицензия

Кластер (HA) доступен в версии Enterprise. Если лицензия ниже или истекла, раздел открывается только для просмотра: настройки, пиры и включение/выключение недоступны, но уже настроенный кластер продолжает работать и реплицировать изменения.

Файлы состояния (каталог данных)

Все файлы состояния хранятся зашифрованными мастер‑ключом узла; просматривать их следует через вкладки раздела «Кластер (HA)», а не напрямую.

9. Диагностика проблем

10. Региональные серверы дочерних доменов (разделы)

HopeDC ставится не только в корневом домене, но и в регионах, где работают дочерние домены. Региональный сервер держит только свой домен: данные других доменов леса — в том числе учётные записи и ключи Kerberos родительского домена — он не получает, не принимает и не хранит. Общими для всего леса остаются только конфигурация и схема. Это снимает с регионов обязанность хранить секреты всего леса и ограничивает ущерб при компрометации площадки.

Настройка пары «центр ↔ регион»

1. Домены обмена обязательны (v141). На центральном сервере (все домены) поле «Домены обмена с этим узлом» у узла с токеном сопряжения нельзя оставить пустым: раньше пустое поле означало «все домены», и забытое поле отдавало региональному серверу весь лес, включая ключи родительского домена. Теперь такая настройка не сохраняется, а уже сохранённая — отклоняет репликацию по токену (в журнале: «Репликация по токену пары … отклонена: для узла не указаны домены обмена»). Для узла с полной репликой по токену впишите *. На региональном сервере (раздел ограничен) поле можно оставить пустым — он отдаёт не больше своего раздела.
2. На центральном сервере (раздел = все домены): «Добавить узел», укажите адрес регионального сервера, в поле «Домены обмена с этим узлом» впишите его домен (напр. child.hope.local), нажмите кнопку генерации и скопируйте токен сопряжения.
3. На региональном сервере: в «Разделы этого сервера» выберите «Только выбранные» и отметьте его домен; добавьте центральный сервер как узел и вставьте тот же токен.
4. Общий секрет кластера региональному серверу не выдаётся — по секрету отдаются все домены (полная реплика). Региональный узел связывается с центром только личным токеном пары и списком доменов.
5. При сохранении сужения раздела панель запросит подтверждение: всё, что вне выбранных доменов, удаляется с этого сервера (на других узлах данные остаются). Аварийная локальная учётная запись узла сохраняется.

Enterprise Admins в дочерних доменах — как в Windows

В Windows группа Enterprise Admins автоматически входит в BUILTIN\Administrators каждого домена леса и управляет поддоменами. HopeDC теперь ведёт себя так же — и на центральном сервере, и на региональном сервере поддомена (туда пользователь родителя приходит через проверенный PAC по доверию). Доступ распространяется на панель, LDAP и SMB/SYSVOL. Обычный Domain Admins родителя поддоменом по‑прежнему не управляет.

11. Масштаб: 100 тыс. пользователей и 100 тыс. компьютеров

Нагрузочное тестирование v126 проведено на кластере из трёх узлов с доменом hope.local: 100 000 пользователей, 100 000 компьютеров, 1 000 пользователей с ключами AES и служебные объекты — всего около 211 тыс. объектов каталога. Все три узла и генераторы нагрузки работали на одной виртуальной машине (2 vCPU, 8 ГБ ОЗУ), поэтому показатели пропускной способности ограничены процессором клиентов и являются нижней оценкой; на отдельных серверах они выше.

Задержки одиночных операций

Пропускная способность под нагрузкой (ошибок — 0)

Для оценки: утренний вход 100 тыс. пользователей за 30 минут — это около 55 входов в секунду, то есть доля нагрузки одного узла.

Кластер

Память и ресурсы узла

• ОЗУ: около 0,65 ГБ после запуска на 211 тыс. объектов (v125 — 1,3 ГБ), до 1,1–1,2 ГБ под смешанной нагрузкой и сразу после бутстрапа. Рекомендуется 4 ГБ ОЗУ на узел для 200 тыс. объектов (минимум 2 ГБ).
• Процессор: рекомендуется 4 vCPU; все показатели выше получены при 2 vCPU на три узла и клиентов.
• Диск: журнал данных ≈ 145 МБ и журнал репликации ≈ 27 МБ на 211 тыс. объектов; закладывайте не меньше 2 ГБ свободного места под рост и бэкапы.
• Число арен распределителя памяти ядро ограничивает само (как MALLOC_ARENA_MAX=2), после бутстрапа и пересинхронизации освобождённая память возвращается системе.

Что изменилось в v126 для больших каталогов

• Снимок каталога для чтения общий для LDAP, Kerberos, SMB и API; атрибуты объектов не копируются — объект делит их с таблицей (копия при изменении). Память узла уменьшилась вдвое.
• Индекс снимка по sAMAccountName, UPN, SPN и DN: вход, поиск учётки, выдача билетов и поиск службы не перебирают весь каталог.
• Запись не блокирует чтение: если снимок занят читателями, копия делается вне блокировки; применение пакета репликации, бутстрап и массовый импорт обновляют снимок пакетами.
• Состав групп в PAC, страницы и поиск в «Структуре домена», счётчики доменов — без выделения памяти на каждый объект.

Ограничения

• LDAP‑контрол постраничной выдачи (paged results) объявлен, но сервер отдаёт результат одним ответом; ограничения размера ответа нет. Клиенты (ldapsearch, SSSD, ADSI) это корректно обрабатывают, но выгрузка всего каталога одним запросом — 5–6 секунд.
• Массовое изменение больше 8 000 объектов за один цикл репликации приводит к автоматической пересинхронизации остальных узлов по снимку (5–10 секунд) — это штатно.
• Запись во время интенсивного чтения стоит около 0,1 с процессорного времени (копия снимка); при сотнях записей в секунду под нагрузкой чтения выделяйте узлу больше ядер.

12. Автотопология репликации по сайтам (v178)

Раньше каждый узел получал список пиров вручную, а при отказе узла связи приходилось перенастраивать. С автотопологией узлы сами узнают друг о друге и строят связи по сайтам — так же, как KCC в Active Directory. Ручные пиры при этом сохраняются и всегда имеют приоритет.

Как включить

1. Опишите сайты и подсети в разделе «Сайты и службы» (если сайтов нет — все узлы попадают в «Default-First-Site-Name», и автотопология строит одну полносвязную группу). Для интегрированного с MS AD домена используются сайты, подсети и связи сайтов из AD (siteObject, siteList, cost).
2. На каждом узле полного доверия (общий секрет кластера, все разделы) откройте Кластер (HA), включите переключатель «Автотопология репликации по сайтам» и нажмите «Сохранить».
3. Новому узлу достаточно одного ручного пира на любой узел кластера: через него он узнает остальных, после чего ручной пир можно удалить.

Поля «Сайт этого узла» и «Адрес этого узла для других» обычно пустые: сайт определяется по самой узкой подсети, в которую попадает IP узла, адрес — https://<IP узла>:9444. Заполняйте их, если узел за NAT/с другим именем или подсети не описаны. Адрес должен быть https://.

Как строится план

Каждый узел считает план сам по одинаковым данным, поэтому все узлы приходят к одному и тому же плану без «главного». Список узлов распространяется обменом сведениями (каждые 2 минуты) — со своими пирами и напрямую со всеми известными узлами полного доверия, так что филиал не теряет связь с центром при отказе моста.

Отказ узла

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

Кто не участвует

• RODC — по-прежнему связывается только со своим мастером по токену пары (п. 8, «Сопряжение RODC»).
• Региональные серверы (ограниченный раздел) и узлы без общего секрета — настраиваются вручную.
• Узлы с выключенным переключателем — не попадают в чужие планы и тянут только у ручных пиров.

Сведения об узлах передаются только по общему секрету кластера; запросы по токену пары отклоняются.

Наблюдение

Карточка автотопологии показывает таблицу узлов (сайт, адрес, «мост», RODC, давность последнего контакта, «не отвечает»), связи плана (узел ← источник, связи этого узла подсвечены) и предупреждения. В списке состояния пиров автоматические пиры подписаны «(авто)». API: GET /api/cluster/auto-topology.