Автоматическое восстановление после сбоя в Exchange DAG - причины
Наша DAG 2013 года, кажется, произвольно активирует БД на других серверах и перемещает их с тех, на которых они были активны. При просмотре метрик не было заметных скачков в RAM / IO / Networking / и т. Д., Поэтому я не уверен, почему они перемещаются.
Я не могу найти, как проверить, почему базы данных перемещаются, и ищу файл журнала или Командлет powershell, который может помочь решить эту проблему.
Для пояснения, много упрощения: На сервере 1 активен DB1 На сервере 2 активна DB2 На сервере 3 активен DB3
. На каждом сервере есть пассивные копии двух других баз данных. Ночью, без видимой причины, все переместится и будет выглядеть так:
На сервере 1 активны DB1 и DB3. На сервере 2 нет активных БД На сервере 3 активна БД 2
Спасибо за любую помощь!
PS: В случае, если кто-то имеет дело с этим и хочет остановить его при потере некоторых функций (например, автоматического переключения), рассмотрите возможность использования следующей политики на каждом сервере, который вы хотите остановить автоматическое переключение на:
Set-MailboxServer -Identity EXSRV01 -DatabaseCopyAutoActivationPolicy Blocked
Где EXSRV01 заменяется именем сервера Exchange, на котором будет остановлена автоактивация.
Я добавлю в свой комментарий для более полного ответа. Основываясь на ответе mfinni на кластеризацию, при отказе базы данных всегда возникает ошибка. Реакция Exchange по умолчанию на что-либо ошибочное - это аварийное переключение базы данных для защиты от сценариев расщепления мозга (обе базы данных считают себя активными и вызывают преступления против человечности).
Вы можете иметь вполне разумные ЦП / память и, казалось бы, никаких сетевых сбоев, кроме MSFT Clustering вы увидите сбои по многим причинам. Если кластеризация считает, что возникла проблема, она выполняет фантастическую работу по ПЕРЕЗАПУСКУ службы кластеризации, чтобы убедиться, что все работает. Когда это произойдет, Exchange переключится на ВСЕ базы данных. Это может быть вызвано многими проблемами, такими как:
- Высокое использование памяти за пределами почтовых ящиков и без того сумасшедшее распределение памяти (2013 год делает здесь лучше)
- Элемент списка
- Сеть «вспыхивает»; не обижайте здесь своего сетевого администратора, это может быть буквально увеличение TTL в сети heartbeat ИЛИ даже сброс на vswitch по какой-либо причине
- Vmotion .... но у вас это не правильно, потому что это не поддерживается. ; -)
Журналы средства просмотра событий кластеризации предоставят вам время «сбоя», и вы можете сопоставить это с журналами просмотра событий высокой доступности, чтобы выяснить, возникла ли проблема или возникла проблема. внезапное событие. Я видел, когда сама база данных была слишком занята, пытаясь не отставать от некоторых почтовых бомб, которые некоторые отделы вызывали неконтролируемыми заданиями cron, и это привело к тому, что журнал транзакций превысил пороговые ограничения репликации для работоспособности базы данных ... бум. .. аварийное переключение.
Если вы найдете что-нибудь в этих журналах, опубликуйте это (очистите конфиденциальные данные), и я смогу помочь. И убедитесь, что на всех серверах Exchange установлены актуальные исправления. Было несколько обновлений CU, которые вызывали аналогичные проблемы без причины.
Если это виртуальные машины, а процесс резервного копирования включает получение моментального снимка Vmware, возможно, время ожидания истекло по разрешенному тактовому сигналу DAG. Вам необходимо установить для SameSubnet и CrossSubnet значения задержки и пороговых значений выше значений по умолчанию.
cluster / prop SameSubnetDelay = 2000: DWORD
кластер / prop CrossSubnetDelay = 4000: DWORD
cluster / prop CrossSubnetThreshold = 10: DWORD
cluster / prop SameSubnetThreshold = 10: DWORD