Exchange DAG自动故障转移 – 原因

我们的2013年DAG似乎有些任意激活其他服务器上的数据库,并将它们从活动的数据库中移出。 在查看指标时,RAM / IO / Networking /等中没有明显的高峰,所以我不确定为什么会出现这种情况。

我找不到如何审核数据库移动的原因,并且正在查找可能有助于解决此问题的日志文件或PowerShell cmdlet。

为了澄清,简化了很多事情:服务器1具有DB1活动服务器2具有DB2活动服务器3具有活动的DB3

每台服务器都有另外两个数据库的被动副本。 一夜之间,没有明显的原因,事情会移动,看起来像这样:

服务器1具有活动的DB1和DB3服务器2没有活动的数据库服务器3具有活动的数据库2

谢谢你的帮助!

PS:如果有人正在处理这个问题,并希望在丢失某些function(如自动过期)时停止它,请考虑在要停止自动closures的每台服务器上使用以下策略:

Set-MailboxServer -Identity EXSRV01 -DatabaseCopyAutoActivationPolicy Blocked 

EXSRV01replace为Exchange服务器的名称以停止自动激活。

我会添加到我的评论更完整的答案。 build立在mfinni对集群的响应上,如果一个数据库发生故障,总会有一个错误。 交易所对任何错误的默认反应是使数据库失效,以防止分裂的大脑情景(这两个数据库都认为它们是活跃的并导致危害人类的罪行)。

你可以有一个完全合理的CPU /内存,似乎没有networking闪烁,但在MSFT集群,你会看到许多原因失败。 如果集群认为存在问题,那么RESTARTING集群服务确保一切正常。 发生这种情况时,Exchange将对所有数据库进行故障转移 这可能是由以下许多问题引起的:

  1. 超过邮箱服务器的内存使用量已经疯狂的内存分配(2013年在这里做的更好)
  2. 项目清单
  3. networking“闪烁”; 在这里不要冒犯你的networkingpipe理员,这可能是心跳networkingTTL的增加,甚至无论出于何种原因重置到vswitch
  4. Vmotion ….但你有正确的,因为这不被支持。 😉

群集事件查看器日志会为您提供发生“失败”的时间,您可以将此事件与高可用性事件查看器日志相关联,以确定问题是否存在或者是否是突发事件。 我已经看到了数据库本身在忙于跟上某些部门由于失控cron作业而造成的一些邮件炸弹,这导致事务日志超过了数据库健康的复制阈值极限。 ..故障转移。

如果您在这些日志中find任何内容,请发布它(清理敏感数据),我可以提供更多帮助。 并确保您在所有Exchange服务器上进行了最新补丁。 有几个CU更新导致类似的问题无缘无故。

如果这些是虚拟机,并且备份过程涉及到获取Vmware快照,则可能会在允许的DAG心跳上超时。 您需要将SameSubnet和CrossSubnet延迟和阈值设置为高于默认值。

http://www.veeam.com/blog/how-to-backup-exchange-database-availability-groups-dags-with-veeam-backup-replication.html

cluster /prop SameSubnetDelay=2000:DWORD cluster /prop CrossSubnetDelay=4000:DWORD cluster /prop CrossSubnetThreshold=10:DWORD cluster /prop SameSubnetThreshold=10:DWORD