主页 / server / 问题 / 779545
Accepted
xstnc
Asked: 2016-05-29 00:04:52 +0800 CST

Windows Server 2012 蓝屏上的 Exchange 2016

  • 772

我有一个 Exchange 2016 服务器，其间大约有 14 天的蓝屏死机。服务器是虚拟的，存在于通过 iSCSI 存储的集群 vmware 环境中。我们运行的其他 Windows 服务器（包括 Exchange 的被动副本）都没有蓝屏。被动 Exchange 正在备份并清除被动和主动节点上的事务日志。

  • 我已经尝试安装最新的关键补丁（还没有可选的）
  • 我已尝试将有问题的 VM 迁移到新主机。

这是 BSoD 查看器给我的信息：

052716-21921-01.dmp 27.05.2016 10:22:16 CRITICAL_PROCESS_DIED   0x000000ef  ffffe000`de10d080   00000000`00000000   00000000`00000000   00000000`00000000   ntoskrnl.exe    ntoskrnl.exe+14e3a0 NT Kernel & System  Microsoft® Windows® Operating System    Microsoft Corporation   6.3.9600.18289 (winblue_ltsb.160328-1315)   x64 ntoskrnl.exe+14e3a0                 C:\Windows\Minidump\052716-21921-01.dmp 8   15  9600    138 150 27.05.2016 10:22:47 
051516-25765-01.dmp 15.05.2016 10:11:06 CRITICAL_PROCESS_DIED   0x000000ef  ffffe001`0ad80900   00000000`00000000   00000000`00000000   00000000`00000000   ntoskrnl.exe    ntoskrnl.exe+14e3a0 NT Kernel & System  Microsoft® Windows® Operating System    Microsoft Corporation   6.3.9600.18289 (winblue_ltsb.160328-1315)   x64 ntoskrnl.exe+14e3a0                 C:\Windows\Minidump\051516-25765-01.dmp 8   15  9600    138 150 15.05.2016 10:11:41 
042816-19328-01.dmp 28.04.2016 22:36:50 CRITICAL_PROCESS_DIED   0x000000ef  ffffe001`3da4f900   00000000`00000000   00000000`00000000   00000000`00000000   ntoskrnl.exe    ntoskrnl.exe+14e8a0 NT Kernel & System  Microsoft® Windows® Operating System    Microsoft Corporation   6.3.9600.18289 (winblue_ltsb.160328-1315)   x64 ntoskrnl.exe+14e8a0                 C:\Windows\Minidump\042816-19328-01.dmp 8   15  9600    294 472 28.04.2016 22:39:45 
041916-23859-01.dmp 19.04.2016 08:43:53 CRITICAL_PROCESS_DIED   0x000000ef  ffffe001`23101900   00000000`00000000   00000000`00000000   00000000`00000000   ntoskrnl.exe    ntoskrnl.exe+14e8a0 NT Kernel & System  Microsoft® Windows® Operating System    Microsoft Corporation   6.3.9600.18289 (winblue_ltsb.160328-1315)   x64 ntoskrnl.exe+14e8a0                 C:\Windows\Minidump\041916-23859-01.dmp 8   15  9600    294 472 19.04.2016 08:47:04

我在不同的网站上看到了一个有同样问题的帖子，但没有人真正回答这个问题，而且帖子已经过时了。

有人对如何解决这个问题有任何指示吗？我是否必须安装另一台 Exchange 服务器并迁移到其中？这将是非常不幸的..

exchange vmware-esxi windows-server-2012-r2 exchange-2016

2 个回答

  1. Best Answer

    您的存储系统出现故障或速度太慢而无法跟上。如果 IO 停滞时间过长，Exchange 会认为存储已死并杀死 Wininit 以强制硬重置。

    请参阅https://technet.microsoft.com/en-us/library/ff625233.aspx并滚动到末尾。2013 年和 2016 年也是如此。

    在某些情况下，整个存储堆栈可能会受到挂起的影响，从而无法将故障事件写入 crimson 通道或 Windows 事件日志的任何其他区域。ESE 还通过验证是否可以写入事件日志来监控深红色通道。如果长时间写入事件日志失败，MSExchangeRepl 会通过终止 wininit.exe 故意导致对 Windows 的错误检查。当操作系统 I/O 挂起时，系统显然无法将任何 ESE 事件写入事件日志。

    我在使用 Windows Server Backup 备份 Exchange 时亲身体验过。当备份开始时，它将并行对所有数据库进行一致性检查。这会在存储退出几分钟后导致 Exchange 蓝屏。

    第一个解决方案是禁用 ATS 心跳到存储阵列 https://kb.vmware.com/kb/2113956

    文本太长无法复制，但 TL；DR：当 8 秒的 ATS 心跳超时时，您的存储阵列连接可能会在大量 IO 下断开，这将导致 VM 中的 IO 超时，从而导致 Exchange 到 BSoD。

    第二种解决方案是在虚拟机中添加存储控制器，并在控制器之间分配数据库磁盘。就我而言，单个 pvscsi 控制器在 6 个数据库下会严重阻塞，但是当磁盘（包括 OS 磁盘等）分布在 4 个 pvscsi 控制器上时，问题就消失了。我对此没有参考，只是对 vSphere 5.5 U3 的个人经验。

    • 5

  2. 您可以发出命令禁用 ESE 强制重启，原因已在 Don 的回答中得到了很好的解释。

    我最近为一个使用 ESXi 的单一服务器的客户做了这件事，因为 IO 对 Exchange 的杀伤力太大了​​。（它仍然会杀死它，因为在示例中简单地打开一个管理控制台需要很长时间，但至少它不会重新启动..）

    Add-GlobalMonitoringOverride -Identity Exchange\ActiveDirectoryConnectivityConfigDCServerReboot -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion '15.0.712.24'

    在那里，您需要使用正确的 Exchange 版本。

    Exchange 版本请参见此处；https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx

    请参阅此处了解更多详情；http://www.tecfused.com/2014/11/exchange-2013-dag-bsod/

    • 3

相关问题