私はExchange2016サーバーを持っており、その間に約14日かかります。サーバーは仮想であり、iSCSI経由のストレージを備えたクラスター化されたvmware環境に存在します。私たちが実行している他のWindowsサーバー(Exchangeのパッシブコピーを含む)bsodはありません。パッシブ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
別のサイトで同じ問題の投稿を見ましたが、実際には問題に答えた人はおらず、投稿は古くなっていました。
誰かがこれを修正する方法について何かアドバイスがありますか? ANOTHTER Exchangeサーバーをインストールしてに移行する必要がありますか?これは非常に残念なことです。
ストレージシステムに障害が発生しているか、速度が遅すぎて追いつけません。 IOが長時間停止している場合、Exchangeはストレージが停止していると見なし、Wininitを強制終了してハードリセットを強制します。
https://technet.Microsoft.com/en-us/library/ff625233.aspx を参照して、最後までスクロールします。 2013年も2016年も同じです。
場合によっては、ストレージスタック全体がハングの影響を受け、深紅色のチャネルまたはWindowsイベントログの他の領域に障害イベントを書き込むことができなくなる可能性があります。 ESEは、イベントログに書き込むことができることを確認することにより、深紅色のチャネルも監視します。イベントログへの書き込みが長期間失敗した場合、MSExchangeReplはwininit.exeを終了することにより、意図的にWindowsのバグチェックを引き起こします。オペレーティングシステムのI/Oがハングすると、システムは明らかにESEイベントをイベントログに書き込むことができません。
Windows Serverバックアップを使用してExchangeをバックアップするときに、これを直接体験しました。バックアップが開始されると、すべてのデータベースの整合性チェックが並行して実行されます。これにより、ストレージがドロップアウトした数分後にExchangeがBSoDになりました。
最初の解決策は、ストレージアレイへのATSハートビートを無効にすることです https://kb.vmware.com/kb/2113956
テキストが長すぎてコピーできませんが、TL; DR:8秒のATSハートビートがタイムアウトすると、ストレージアレイ接続が重いIOでドロップされる可能性があります。これにより、VMでIOタイムアウトが発生します。 ExchangeをBSoDにします。
二次的な解決策は、ストレージコントローラーをVMに追加し、コントローラー間でデータベースディスクを分散することです。私の場合、単一のpvscsiコントローラーは6つのデータベースでひどく詰まりますが、ディスク(OSディスクなどを含む)が4つのpvscsiコントローラーに分散されると、問題は解消されました。そのためのリファレンスはありません。vSphere5.5U3での個人的な経験だけです。
ESEの強制再起動を無効にするコマンドを発行できます。原因は、Donの回答で詳しく説明されています。
IOはExchangeを過剰に殺していたので、esxを備えた単一のサーバーを使用している顧客のために最近それを行いました。ただし、少なくとも再起動しないでください。)
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/