Сначала добавить узлы, затем назначить роли

1. Для каждого нового сервера откройте «Инфраструктура → Узлы кластера → Добавить узел» (/ui/nodes/add). Укажите IP или DNS/FQDN, SSH-порт, пользователя и пароль либо приватный ключ. Проверьте соединение и явно подтвердите добавление. Устанавливаются отдельный ключ управления и агент mTLS; пароль SSH не сохраняется. На этом этапе роли, почтовые приложения и репликация не назначаются.
2. Отпечаток SSH-ключа сверяйте по независимому доверенному каналу. Принятие первого наблюдаемого ключа (TOFU) само по себе не доказывает подлинность сервера. Смена подтверждённого ключа требует отдельного разбора. «Отдельная проверка SSH» (/ui/nodes/check) не заменяет добавление узла.
3. Глобальный системный администратор открывает «Инфраструктура → Failover-кластер → Создать кластер» (/ui/cluster/create). Текущий мастер состоит из трёх этапов: 1. Роли узлов; 2. Компоненты; 3. Синхронизация данных. На первом этапе выберите уже добавленные резервный и инфраструктурный узлы. Active — существующий основной почтовый сервер; Standby — резервный; инфраструктурный узел предназначен для etcd и Redis и хранит данные Redis. Active/Active пока недоступен.
4. Нажмите «Проверить выбранные узлы», сверьте состав и подтвердите «Сохранить роли и далее». Проверка использует агенты по mTLS; SSH-паролей в мастере ролей нет. Сохранение состава не устанавливает хранилища и не включает обслуживание пользователей на резерве. При неизвестном исходе нажмите «Уточнить результат сохранения», а не повторяйте команду. Сохранённые роли и доступный агент не означают готовый кластер; ошибка чтения не доказывает отсутствие ранее сохранённого состава.

Подготовить и передать только компоненты Blackhole

1. На этапе 2 последовательно пройдите 2.1 «Проверить основной узел», 2.2 «Подготовить кластерные образы» и 2.3 «Передать образы по ролям». Сохранение проверенной подготовки создаёт кандидат конфигурации, не меняя рабочую базу и почту. В 2.2 отдельно проверьте пакет Patroni, etcd и MailGW и подтвердите подготовку образов на основном узле; это не запускает миграцию данных.
2. В 2.3 нажмите «Проверить состав по ролям». Сверьте списки резервного и инфраструктурного узлов: план использует фактически установленный доверенный состав Blackhole; посторонние Docker-контейнеры не включаются. Инфраструктурный узел не должен получать почтовые приложения как второй резервный. Образы поступают только с основного, с сохранением имён и тегов.
3. Явно подтвердите показанный состав и нажмите «Передать на оба узла». Каждый образ передаётся последовательно и проверяется через mTLS, без внешнего registry. В состоянии очереди проверяйте текущий образ, переданные байты, этап и ошибку. Закрытие мастера не останавливает сохранённое задание; при неизвестном исходе сначала обновите очередь и сверяйте результат. Наличие образов не означает запуск приложений, копирование томов или готовность переключения.
4. После проверки обеих передач подключение кластерных исполнителей требует отдельной проверки и подтверждения. Оно изменяет конфигурацию управления агента, но само не запускает PostgreSQL, Redis или почтовые реплики. Не считайте состояния «образы готовы» и «исполнители подключены» подтверждением перевода рабочих хранилищ в кластер.

Планы данных — отдельный опасный этап

1. Этап 3 «Синхронизация данных» не выполняется автоматически после сохранения ролей или передачи образов. Сначала получите планы и проверьте доступные операции и предпосылки именно этой установки. Перевод существующих PostgreSQL под Patroni и Redis standalone в Cluster меняет работающую систему: необходимы согласованное окно обслуживания, проверенная резервная копия и план отката с сохранением существующих данных. Наличие панели или проверенного образа не подтверждает завершённую миграцию.
2. В отдельной панели PostgreSQL используется план начальной копии и WAL streaming, не копирование работающего каталога базы. Подготовка реплики и переход основного под Patroni — разные действия. План реплики сам не подтверждает принятие существующей базы Patroni, кворум etcd или синхронное подтверждение транзакций. Запускайте только доступную подтверждённую операцию после проверки её плана.
3. Панели Redis показывают поддержанные задания репликации и измеренные смещения. Не путайте отдельную Redis-реплику с переходом standalone в Redis Cluster из трёх основных экземпляров и трёх реплик. Готовность полного перехода и сохранность существующих данных требуют отдельной проверки; здоровый контейнер не доказывает отсутствие отставания. Репликация асинхронная.
4. В панели «Письма · постоянная синхронизация» сначала нажмите «Проверить план писем» и проверьте владельцев, UID/GID, каталоги и предпосылки пассивного Dovecot. Радиокнопка подтверждения относится к конкретному почтовому заданию, а не ко всем хранилищам. Поддержанное задание использует Dovecot DSYNC по mTLS; его результат и дальнейшие циклы проверяются отдельно. Клиентские порты и обслуживание пользователей на резерве этим заданием не включаются. Браузер и SSH не являются постоянным каналом синхронизации; закрытие страницы не подтверждает и не отменяет результат.

Читать прогресс и восстановить просмотр

Владение ящиками и смена пароля

Files: подтвердить владельца существующих файлов

1. После сохранения состава и проверки переданных образов откройте этап 3, панель «Files · владельцы существующих файлов», если она доступна для этой установки. Нажмите «Получить пользователей Files» и выберите пользователя из серверного списка. UUID, путь каталога и ключи в браузере не вводятся; неподтверждённый профиль Files выбрать нельзя.
2. Проверьте адрес и AD GUID, если он есть. План связывает учётную запись с версией безопасности, штатным профилем Files, томом и физическим каталогом. Совпадение адреса само по себе не доказывает принадлежность старых файлов.
3. По умолчанию выбрано «Не подтверждаю принадлежность». Выберите радиокнопку «Подтверждаю: существующие файлы принадлежат …» и точно повторите адрес в поле «Повторите адрес владельца». Затем нажмите «Подтвердить владельца файлов». Идентификатор администратора берётся из действительной глобальной системной сессии, не из формы. Действие сохраняет подтверждение владения, не перемещает файлы и не меняет AD-пользователей.
4. При потерянном ответе используйте «Проверить сохранённую привязку». После перезапуска читается сохранённый результат; команда автоматически не повторяется. Состояния confirming/unknown не означают успех. Изменение личности, каталога или пары блокирует старый план.
5. source_confirmed=true подтверждает получение записи владельца на источнике; проверяйте также state/reason, поскольку последующая смена личности может заблокировать её. В этом сценарии target_configured=false и target_enrollment_not_available означают, что получатель данных ещё не подключён. replication_ready=false и promote=false сохраняются.

Files: подготовленные сертификаты и CLI — ещё не активация

Что пока не разрешает переключение

Если план недоступен