☰

Exchange DAG 自动故障转移 - 原因

tag-icon • tag-icon exchange windows-server-2012 windows-server-2012-r2 exchange-2013
Exchange DAG 自动故障转移 - 原因

我们的 2013 DAG 似乎会随意激活其他服务器上的数据库，并将它们从活跃的服务器上移走。查看指标时，RAM/IO/网络/等方面没有明显的峰值，所以我不确定为什么要移动它们。

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

为了清楚起见，我们简化了很多事情：服务器 1 有 DB1 处于活动状态服务器 2 有 DB2 处于活动状态服务器 3 有 DB3 处于活动状态

每台服务器都有另外两个数据库的被动副本。一夜之间，不知何故，事情发生了变化，看起来如下图所示：

服务器 1 具有活动的 DB1 和 DB3 服务器 2 没有活动的 DB 服务器 3 具有活动的 DB 2

谢谢你的帮助！

PS：如果有人正在处理这个问题并且想要在失去某些功能（即自动故障转移）的情况下停止它，请考虑在要停止自动故障转移的每台服务器上使用以下策略：

Set-MailboxServer -Identity EXSRV01 -DatabaseCopyAutoActivationPolicy Blocked

其中 EXSRV01 替换为要停止自动激活的 Exchange 服务器的名称。

答案1

我将补充我的评论以获得更完整的答案。基于 mfinni 对集群的回应，如果数据库发生故障，则始终会出现错误。Exchange 对任何错误的默认反应是故障转移数据库以防止出现裂脑情况（两个数据库都认为自己处于活动状态并造成反人类罪行）。

您可以拥有非常合理的 CPU/内存，并且似乎没有网络故障，但在 MSFT 群集中，您会因为多种原因看到故障。如果群集认为它有问题，它会出色地重新启动群集服务以确保一切正常。当发生这种情况时，Exchange 将故障转移所有数据库。这可能是由许多类似以下问题引起的：

  1. 超出邮箱服务器的高内存使用率已经疯狂的内存分配（2013 在这里做得更好）
  2. 项目清单
  3. 网络“闪烁”；请不要在这里冒犯您的网络管理员，它实际上可能是心跳网络上的 TTL 增加，或者甚至出于某种原因重置了 vswitch
  4. Vmotion....但是你把它关闭了，因为它不受支持。;-)

集群事件查看器日志将为您提供“故障”发生的时间，您可以将其与高可用性事件查看器日志关联起来，以确定问题是否是累积的，还是突发事件。我曾看到过数据库本身忙于处理某些部门因失控的 cron 作业而导致的邮件轰炸，这导致事务日志超出了数据库健康的复制阈值限制……砰……故障转移。

如果您在这些日志中发现任何内容，请发布它（清除敏感数据），我可以提供更多帮助。并确保所有 Exchange 服务器上都已打上最新补丁。有一些 CU 更新毫无理由地导致了类似的问题。

答案2

如果这些是虚拟机，并且备份过程涉及获取 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

相关内容