Улучшения средств изоляции сбоев драйвера хранилища в Exchange 2010 SP1
Введение
Драйвер хранилища Exchange – это ключевой транспортный компонент, который расположен и на роли сервера почтовых ящиков (в виде службы передачи сообщений), и на роли транспортного сервера-маршрутизатора. Он отвечает за:
• прием отправленных конечными пользователями сообщений от сервера почтовых ящиков и их передачу роли транспортного сервера-маршрутизатора для категоризации и маршрутизации;
• доставку сообщений соответствующему серверу почтовых ящиков в зависимости от расположения почтового ящика получателя;
• расширяемость платформы и для отправки, и для доставки писем. Драйвер хранилища обеспечивает работу агентов, которые расширяют функциональность Exchange. Примерами подобных агентов являются правила почтового ящика, беседы, извещения о переадресации приглашения на встречу, и т.д.
Exchange 2010 сейчас применяется в Live@EDU, а также в будущем Office 365. Как вы наверное понимаете, серверы Exchange, которые работают в центрах обработки данных этих служб, являются более нагруженными, чем практически любой сервер Exchange, который можно себе представить. До SP1 существовали некоторые проблемы, связанные с доставкой почты в хранилище почтовых ящиков Exchange. В частности, нужно было обезопасить себя того, чтобы горстка получателей не "подвесила" всю остальную систему доставки почты.
В то время как многие из вас не слышали об этой проблеме, Microsoft наблюдала многие ее варианты за последние годы; часто это сводилось к одиночному событию вроде случайно спровоцированного шторма при репликации общих папок.
Это происходило несмотря на доступность регулирования количества сообщений. Для транспортных ролей также было средство против исчерпания ресурсов – обратное давление, но оно не было предназначено для защиты системы от сообщений, которые уже находятся в локальной очереди доставки.
Изменения в SP1
Для того, чтобы защищать серверы почтовых ящиков и транспортные серверы-маршрутизаторы от исчерпания ресурсов, в SP1 появились новые ограничения для потоков команд:
| Ключ | Описание | Сценарий | Ошибка в журнале подключений: |
|---|---|---|---|
<add key=”RecipientThreadLimit” value=”1”/> |
Ограничение потоков доставки почты, которые могут быть назначены одному получателю. Примечание: Если увеличить это значение, то вам нужно увеличить параметр MaxMailboxDeliveryPerMdbConnections так, чтобы медленные или "зависшие" доставки одному получателю не заблокировали доставку для всей почтовой базы. |
Флуд сообщений в один почтовый ящик или проблемы производительности, связанные с одним почтовым ящиком, оказывают минимальное влияние на доставку в другие почтовые ящики почтовой базы. | Throttled delivery for recipient <recipient> due to concurrency limit <limit> |
<add key=”MaxMailboxDeliveryPerMdbConnections” value=”2”/> |
Максимальное число одновременных подключений к одной «здоровой» почтовой базе. "Здоровье" базы определяется с помощью Health Monitor API и записывается в журнал подключений как значение между -1, 0-100. 100 означает, что база "здорова". |
Подключения, "подвисшие" из-за одной проблемной почтовой базы, оказывают минимальное влияние на доставку других сообщений, находящихся в очередях. | Throttled Delivery due to server limit for <server FQDN> with threshold |
Примечание: по умолчанию этих ключей в файле EdgeTransport.exe.Сonfig нет. |
Бывает ли так, что защиты слишком много?
К сожалению, после установки SP1 существует два сценария, в которых мы наблюдаем возврат сообщений обратно в очередь. Вспомогательное сообщение об ошибке выглядит так:
432 4.3.2 STOREDRV.Deliver; recipient thread limit exceeded
Как вы возможно догадались, к этим сценариям относятся:
• Журналирование
• Общие папки
В обоих случаях доставка происходит одному получателю (или очень малому числу получателей). Это может произойти при большом потоке почты. Приведенный ниже снимок экрана был сделан на лабораторном сервере во время воспроизведения этой проблемы:
Рисунок 1: Сообщения возвращаются обратно в очередь доставки сообщений из-за превышения ограничения количества потоков на получателя.
Вы можете найти историю событий 4.3.2 в журналах подключений на ваших транспортных серверах маршрутизаторах (в \Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\Connectivity\CONNECTLOGxxxxxxxx-x.LOG), например:
#Software: Microsoft Exchange Server
#Version: 14.0.0.0
#Log-type: Transport Connectivity Log
#Date: 2011-01-12T00:00:00.775Z
#Fields: date-time,session,source,Destination,direction,description
2011-01-12T00:00:00.775Z,08CD7F1200CBDBD0,MapiSubmission,5f24e416-c380-41b5-bfe0-37b6f1091f49,>,"Failed; HResult: 1140850693; DiagnosticInfo: Stage:LoadItem, SmtpResponse:432-4.3.2 STOREDRV; mailbox server is too busy"
2011-01-12T00:00:00.775Z,08CD7F1200CBDBD0,MapiSubmission,5f24e416-c380-41b5-bfe0-37b6f1091f49,-,RegularSubmissions: 0 ShadowSubmissions: 0 Bytes: 0 Recipients: 0 Failures: 1 ReachedLimit: False Idle: False
2011-01-12T00:00:05.792Z,08CD7F1200CBDBD1,MapiSubmission,5f24e416-c380-41b5-bfe0-37b6f1091f49,+,Win2k8R2Ex14.dom2k8r2ex14.lab
В некоторых случаях, если не трогать серверы, то очереди могут постепенно рассасываться. В других случаях может потребоваться предпринять дополнительные меры, т.к. проблема сохраняется с течением времени или проблема не является разовой, например, шторм при репликации общих папок.
Хорошо, понятно. Как теперь исправить ситуацию?
Как любая другая функция, связанная с исчерпанием ресурсов и производительностью, которая когда-либо была в Exchange, решение не прямолинейное. Для начала мы получим некоторую степень успеха, просто увеличивая оба значения, как показано ниже:
<add key="RecipientThreadLimit" value="2" />
<add key="MaxMailboxDeliveryPerMdbConnections" value="3" />
Фактически это дало настолько положительный результат, что мы рассматриваем изменение значений по умолчанию в будущих кумулятивных обновлениях или сервис-паке. Конечно, когда мы это сделаем, новые значения по умолчанию будут применяться только к тем, кто не изменил эти значения. Хотя это еще не реализовано, статья KB 2491972 будет обсуждать это изменение, когда придет время.
Если +1 это хорошо, то почему не сделать +2 или больше?
Проблема заключается в том, что все серверы Exchange будут в конечном итоге ограничены аппаратными ресурсами. Вы не захотите столкнуться со снижением производительности или исчерпанием ресурсов из-за события, связанного с общими папками или журналированием, и которое оказывает воздействие на всех пользователей. Кроме того, существуют другие ограничения, которые управляют максимальным числом потоков, обслуживающими эти типы доставок. Иными словами, мы не рекомендуем ставить больше 4 для MaxMailboxDeliveryPerMdbConnections, а RecipientThreadLimit всегда должен быть по крайней мере на единицу меньше.
В крайнем случае, если вы находитесь в очень загруженной среде с выделенными серверами для журналирования, возможно, стоит рассмотреть обособление транспортных серверов-маршрутизаторов, чтобы установить на них особые параметры. Конечно, они могут быть виртуализированными или многоролевыми, но чтобы быть изолированными, все они должны быть в выделенном сайте. После этого вы сможете увеличить значения параметров без риска повлиять на доставку в другие почтовые ящики.
Конечно это экстремальный пример. Для большинства из нас проще всего попробовать +1 при тщательном мониторинге серверов почтовых ящиков и траспортных сервеов-маршрутизаторов.
Скотт Лэндри, Стив Шиманн, Фрэнк Браун и Джейсон Нельсон
Перевод: Илья Сазонов, MVP