Ошибка STOP 0x0000009E на узле кластера Exchange

Жил-был обычный кластер 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

После изменения действия на «запись в лог», ребуты прекратились.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *