Жил-был обычный кластер Exchange 2010 и, после некоторого роста количества баз в Database Availability Group, один из двух DB-серверов внезапно начал падать с синим экраном и ошибкой 0x0000009E по ночам аккурат во время бэкапа. Но не всегда. Конечно же, он сразу перезагружался и к утру был в строю, но бэкап-то прерывался…
Поиск возможных причин падения показал, что все не так просто. За время существования ОС Windows обязательных и необязательных апдейтов, которые фиксят эту ошибку вышло достаточно, но дальнейшее изучение показало, что все эти апдейты уже установлены. А сервер продолжает падать с завидной регулярностью.
Проверили версии драйверов, статус рэйда, наличие каких-нибудь системных ошибок — все чисто. Сервера по железу одинаковые, но один падает, а другой продолжает работать. Выбрали в качестве «активного» сервера для баз второй — и падать начал он, а второй тем временем прекрасно работал!
Начали тщательно изучать все графики заббикса и увидели, что в момент начала бэкапа среднее время ответа дисковой подсистемы резко вырастает до 6000 мс (я не ошибся с нулями), затем данные от заббикс-агента отсутствуют, а затем, спустя минут 20-30 происходит ребут. В общем, было видно, что после роста количества (но не размера) баз дисковая подсистема перестала справляться с нагрузкой. Но причем тут синий экран?
Ответ кроется в логике работы Cluster Service: если на определенном этапе сервис перестает отвечать на время, превышающее 60 секунд (по умолчанию), то система выпадает в синий экран и перезагружается, предполагая, что с кластером что-то не то и эта нода не живая. За таймаут и действие по умолчанию отвечают два параметра: ClusSvcHangTimeout и HangRecoveryAction. Просмотреть текущие значения этих параметров можно при помощи команды:
cluster /cluster:clustername /prop
Установить таймаут можно командой:
cluster /cluster:clustername /prop ClusSvcHangTimeout=x
где x — время в секундах.
Но мы решили временно, до апгрейда серверов, установить другое действие по умолчанию, а именно «Запись в лог». Делается это так:
cluster /cluster:clustername /prop HangRecoveryAction=x
В данном случае x может быть от 0 до 3: 0 — отключить мониторинг и не делать вообще ничего, 1 — записать в лог, 2 — остановить Cluster Service, 3 — вызвать «синий экран смерти» с ошибкой 0x0000009E
После изменения действия на «запись в лог», ребуты прекратились.