Время ожидания диска в Windows и Exchange Server 2010
Исходная статья опубликована в четверг, 17 ноября 2011 г.
Несколько месяцев назад Брюс Лангуорти (Bruce Langworthy) написал отличную статью, посвященную новым рекомендациям по установке значения времени ожидания диска в Windows- https://blogs.msdn.com/b/san/archive/2011/08/15/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small-value.aspx.
Та публикация заставила меня задуматься об Exchange и о том, как мы решаем проблемы ввода-вывода. Для тех, кто не читал статью Брюса, поясню: в ней объясняется, что время ожидания диска по умолчанию равное 60 секундам означает, что Windows не будет сообщать о зависшей операции ввода-вывода в течение 60 секунд и не попытается ее повторить в течение 8 минут. 8 минут — это слишком долгое ожидание перед повторением зависшей операции ввода-вывода, поэтому Microsoft представляет новое руководство, в котором рекомендуется изменить параметр времени ожидания диска в Windows на значение, соответствующее используемой архитектуре хранения.
Мой вопрос по поводу Exchange был прост: каким образом обработка времени ожидания диска влияет на развертывание Exchange DAG; а точнее следует ли уменьшить время ожидания диска в Windows на используемых серверах Exchange в соответствии с новыми рекомендациями или оставить все, как было?
Чтобы ответить на этот вопрос, я обратился к некоторым нашим разработчикам ESE. И вот, что получилось в результате этого обсуждения.
- Время ожидания диска в Windows в основном предназначено для регистрации событий и повтора операций ввода-вывода.
- До выпуска Exchange Server 2010 в Exchange при снижении скорости операций ввода-вывода не предпринималось никаких действий, кроме регистрации этого в журнале событий.
- В выпуске Exchange Server 2010 RTM представлено упреждающее восстановление страниц (замена на чистые страницы) для страниц, затронутых медленными операциями ввода-вывода.
- Exchange Server 2010 с пакетом обновления 1 (SP1) — это первая версия Exchange, включающая аналитические данные для обработки зависших операций ввода-вывода, которая выполняет намеренный сбой сервера (критическая ошибка), если зависшая операция ввода-вывода влияет на активные базы данных в узле группы обеспечения доступности баз данных (DAG).
Я решил, что, прежде чем определить, что делать с параметрами времени ожидания диска, сначала необходимо понять, какие аналитические данные представлены в Exchange Server 2010 с пакетом обновления 1 (SP1) и как они могут взаимодействовать с временем ожидания диска.
Восстановление Exchange Server 2010 с пакетом обновления 1 (SP1) с помощью расширенного обработчика хранилищ при зависших операциях ввода-вывода
В Exchange Server 2010 с пакетом обновления 1 (SP1) представлен ряд интересных улучшений в плане работы с зависшими операциями ввода-вывода. Эти улучшения подробно обсуждаются в следующей статье TechNet https://technet.microsoft.com/en-us/library/ff625233.aspx:
"Exchange 2010 с пакетом обновления 1 (SP1) имеет новую логику восстановления, которая основана на встроенном механизме отладки в Windows, срабатывающем при возникновении определенных условий, в частности, при появлении зависших операций ввода-вывода. В версии с пакетом обновления 1 (SP1) имеется обновленный расширенный обработчик хранилищ (ESE), который обнаруживает зависшие операции ввода-вывода и предпринимает действия по исправлению для автоматического восстановления сервера. ESE поддерживает поток наблюдения за вводом-выводом, который обнаруживает операции ввода-вывода, задержавшиеся на определенное время. По умолчанию, если операция ввода-вывода для базы данных задерживается более, чем на одну минуту, ESE регистрирует событие в журнале. Если задержка операции ввода-вывода для базы данных превышает 4 минуты, ESE регистрирует конкретный сбой, если это возможно. Регистрироваться могут события ESE с номерами 507, 508, 509 или 510 в зависимости от природы зависшей операции ввода-вывода. Если характер проблемы таков, что она влияет на объем пространства для ОС или на возможность записи событий в журнал, то события не регистрируются. Если события регистрируются, служба репликации Microsoft Exchange (MSExchangeRepl.exe) обнаружит это условие и намеренно создаст критическую ошибку в Windows, завершив процесс wininit.exe".
Итак, что это значит? После некоторого обсуждения (и анализа кода ESE) была создана следующая таблица, которая упрощает понимание этого механизма (для справки я включил предыдущие версии Exchange).
Примечание. Здесь я хочу сказать огромное спасибо Александре Кошта (Alexandre Costa) и Бретт Ширли (Brett Shirley), которые являются разработчиками ESE в группе Exchange и без которых эта публикация бы не состоялась.
|
Версия Exchange |
Тип операции ввода-вывода |
Время операции ввода-вывода |
Действия |
|
Exchange Server 2003 |
Завершена |
>60 с |
|
|
Exchange Server 2007 |
Завершена |
>60 с |
|
|
Exchange Server 2010 RTM |
Завершена |
>60 с |
|
|
Exchange Server 2010 SP1 |
Выполняется |
>60 с |
|
|
>4 мин |
| ||
|
Завершена |
>30 с |
|
Примечание. "Выполняется" означает, что медленная операция ввода-вывода еще успешно не завершилась. "Завершена" означает, что медленная операция ввода-вывода завершилась, но продлилась более 30 с. Здесь важно отметить, что до версии Exchange Server 2010 не существовало понятия медленных "выполняющихся" операций ввода-вывода, сообщалось только о завершенных операциях.
Мне не нравится это новое поведение, что с ним можно сделать?
Как и в большинстве других ситуаций, я не рекомендую менять новое поведение, если только у вас нет очень веской причины для этого… Однако если вам все-таки необходимо изменить новое поведение "Восстановление с помощью расширенного обработчика хранилищ при зависших операциях ввода-вывода", то имеются соответствующие разделы реестра и атрибуты Active Directory, позволяющие сделать это и описанные здесь.
Заключение
Возвращаясь к причине, по которой я взялся за написание этой статьи, я хотел понять, следует ли уменьшать время ожидания диска в Windows в узлах сервера Exchange DAG в соответствии с рекомендациями, описанными здесь.
Поговорив с Мэттом Госседжем (Matt Gossage) из группы Exchange (Мэтт знает все об Exchange и вводе-выводе), я понял, что, помимо прочего, время ожидания диска защищает сервер от шквала сбросов шины. Одним из интересных побочных эффектов, возникающих при задержке операции ввода-вывода дольше времени ожидания диска в Windows, является то, что драйвер disk.sys запускает сброс шины, который затрагивает все LUN на сервере, а не только LUN, который не отвечает.
Чаще всего такое поведение наблюдается с Exchange 2010 и хранилищем JBOD. Там, где развернуто решение RAID, дисковый контроллер может обрабатывать ошибки чтения блоков, считывая данные с другого диска либо заново рассчитывая данные на основе контрольного значения, что задерживает операцию ввода-вывода, но ненадолго. В случае с хранилищем JBOD имеется только одна копия блока данных, поэтому повреждение блока может привести к зависанию операции ввода-вывода, пока диск будет пытаться считать данные. Здесь важно, что при развертывании JBOD не нужно сокращать значение TimeOutValue, напротив, возможно следует его увеличить, чтобы снизить воздействие шквала сбросов шины, если один из шпинделей диска JBOD начинает выходить из строя.
В следующей таблице приводятся рекомендуемые процедуры по установке значения HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue для серверов с ролью почтового ящика Exchange Server 2010.
| Сценарий | Рекомендация |
| Хранилище с прямым подключением |
|
| RAID-хранилище в сети SAN |
|
| Хранилище JBOD |
|
Нил Джонсон (Neil Johnson)
старший консультант, UK MCS
Это локализованная запись блога. Исходная статья находится по ссылке: Windows Disk Timeouts and Exchange Server 2010