У меня есть сервер Exchange 2016, который имеет промежуток около 14 дней. Сервер является виртуальным и существует в кластерной среде VMware с хранилищем через iSCSI. Ни один из других серверов Windows, которые у нас работают (включая пассивную копию Exchange), bsods. Пассивный Exchange подвергается резервному копированию и очищает журналы транзакций, как и должно быть на пассивном и активном узлах.
Вот что дает мне программа просмотра 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 считает, что хранилище мертво, и завершает работу Wininit, чтобы принудительно выполнить полный сброс.
Видеть https://technet.microsoft.com/en-us/library/ff625233.aspx и прокрутите до конца. То же самое в 2013 и 2016 годах.
В некоторых случаях зависание может повлиять на весь стек хранилища, что делает невозможным запись событий сбоя в малиновый канал или любую другую область журнала событий Windows. ESE также следит за малиновым каналом, проверяя возможность записи в журнал событий. Если запись в журнал событий не выполняется в течение длительного периода времени, MSExchangeRepl намеренно вызывает проверку ошибок Windows, завершая wininit.exe. Когда операционная система ввода-вывода зависает, очевидно, что система не может записывать какие-либо события ESE в журнал событий.
Я испытал это на собственном опыте, когда использовал Windows Server Backup для резервного копирования Exchange. Когда начинается резервное копирование, выполняется параллельная проверка целостности всех баз данных. Это привело к тому, что Exchange перешел в BSoD через несколько минут после того, как выпало хранилище.
Первое решение - отключить контрольный сигнал ATS для массива хранения. https://kb.vmware.com/kb/2113956
Текст слишком длинный для копирования, но TL; DR: подключение к вашему массиву хранения может быть прервано при интенсивном вводе-выводе, когда истекает 8-секундный период времени ATS, что вызовет таймаут ввода-вывода в виртуальной машине, что приведет к переходу Exchange в BSoD.
Дополнительным решением является добавление контроллеров хранилища к виртуальной машине и распределение дисков базы данных между контроллерами. В моем случае один контроллер pvscsi сильно подавился бы под 6 базами данных, но когда диски (включая диск ОС и т. Д.) Были распределены по 4 контроллерам pvscsi, проблемы исчезли. У меня нет ссылки на это, просто личный опыт работы с vSphere 5.5 U3.
Вы можете подать команду, чтобы отключить принудительную перезагрузку ESE, причина хорошо объяснена ответом Дона.
Я сделал это поздно для клиента с единственным сервером с esx, так как ввод-вывод перегружал Exchange. (это все еще убивает его, поскольку в примере требуется время, чтобы просто открыть консоль управления, но, по крайней мере, она не перезагружается ..)
Add-GlobalMonitoringOverride -Identity ExchangeActiveDirectoryConnectivityConfigDCServerReboot -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/