Exchange 2016 в Windows Server 2012 BSoD
У меня есть сервер 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 и перейти на него? Это было бы очень прискорбно ..
Ваша система хранения данных выходит из строя или работает слишком медленно. Если IO простоял слишком долго, 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: Ваше соединение с массивом хранилищ может быть прервано при сильном IO, когда сердцебиение ATS разбивается в 8 секунд, что приведет к таймауту IO в виртуальной машине, в результате чего Exchange вернется к BSoD.
Вторичным решением является добавление контроллеров хранилищ в виртуальную машину и распределение дисков БД между контроллерами. В моем случае, один контроллер pvscsi сильно задохнется под 6 БД, но когда диски (включая диски ОС и т.д.) будут распределены между 4 контроллерами pvscsi, проблемы исчезнут. У меня нет для этого ссылки, только личный опыт на vSphere 5.5 U3.
.Вы можете выдать команду на отключение принудительной перезагрузки ESE, причина хорошо объяснена ответом Дона.
Я сделал это поздно для заказчика с одним сервером с esx, так как IO перезагружал 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/