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