🛡 Бэкап не спасёт: архитектура службы каталогов с несколькими контроллерами Что произойдёт, если контроллер домена решит прилечь? Если ответ начинается с «ну, у нас есть бэкап», это не отказоустойчивость. Бэкап восстанавливает систему после аварии, но не помогает пользователю войти в корпоративный сервис прямо сейчас. Диск умер, виртуальная машина упала, сеть потеряна — вход заблокирован до восстановления. Один DC — нет отказоустойчивости. По данным habr_infosec, поставить второй сервер недостаточно: нужна синхронизация данных каталога, файлов, конфигурации и состояния БД. В MULTIDIRECTORY выстраивают несколько уровней: контроллеры домена, кластер PostgreSQL с Patroni и etcd, репликация файловых политик и DNS round-robin. Patroni отслеживает узлы и автоматически переключает ведущий узел при сбое. Запись идёт строго на ведущий узел, чтение — с локальной реплики рядом с контроллером. Ключевой нюанс: локальная реплика PostgreSQL — не кэш, а полноценная копия состояния. При потере связи с ведущим узлом контроллер переходит в режим только чтения и продолжает аутентификацию. Филиал за сотни километров от центра сохраняет доступ, но без записи. После восстановления связи данные быстро актуализируются. Это не полное переключение при сбое. Запись недоступна. Меня цепляет отсутствие цифр: производитель не назвал целевое время восстановления (RTO) и точку восстановления (RPO), не показал результаты измерения времени переключения и не объяснил, как решается разделение кластера для файлов. Схема с несколькими контроллерами решает проблему аутентификации, но резервное копирование не отменяет. Отказоустойчивость без измеренных RTO — это архитектурная декларация, а не SLA. #MULTIDIRECTORY #отказоустойчивость #PostgreSQL #службакаталогов