IT-Воробейчик

Объяснение механизма обратной нагрузки (Back pressure) на серверах Exchange

Обратная нагрузка (Back pressure) — компонент мониторинга системных ресурсов транспортной службы Microsoft Exchange. Существует на серверах почтовых ящиков и пограничных транспортных серверах.
Компонент обратной нагрузки обнаруживает когда жизненно важные системные ресурсы (пространство жёсткого диска, оперативной памяти и т.д.) чрезмерно использованы и предпринимает действия, чтобы предотвратить сервер от дальнейшей нагрузки, в следствии которой он может стать полностью недоступным.
Так при превышении порога использования пространства жёсткого диска, на котором находится база данных почтовой очереди или файлы журналов, результатом работы механизма обратной нагрузки может стать задержка принятия новых сообщений или же полная остановка принятия новых сообщений транспортной службой.

Что хранится внутри базы данных Mail.que

По-умолчанию транспортная база данных (БД) располагается по следующему пути:

%ExchangeInstallPath%TransportRoles\data\Queue

Требования к объёму базы данных обуславливаются обеспечением двух потребностей:

1. Временная организация очереди входящих и исходящих сообщений (включая теневую избыточность (shadow redundancy))
2. Реализация механизма сети безопасности (Safety Net)

Можно предположить, что требуемый размер базы данных будет являться суммой всех сообщений на диске при наихудшем сценарии.

В общем, ваш mail.que состоит из следующих элементов:

• почтовый трафик текущего дня, включая сообщения, которые хранятся на диске дольше, чем это установлено настройками истечения срока действия (например, очередь poison, сообщения журналирования и т.п.)
• очередь теневой избыточности (Shadow redundancy)
• очередь отправки и сообщения, ожидающие доставки
• сообщения сети безопасности (Safety Net), сохраняемые на случай, если понадобится повторная доставка

Так же следует учитывать, что как и в других базах данных Exchange, когда происходит удаление почтового сообщения из транспортной базы данных (mail.que), размер базы данных не уменьшается. Вместо этого во время обслуживания образуется 'белое пространство' внутри базы данных, которое может быть использовано для будущего хранения.

Почему транспортная база данных вырастает до большого размера

Размер транспортной БД  зависит от её использования. Размер прямопропорционален среднему размеру всех сообщений за день. Если в какой-то день сообщение с большим вложением отправляется всем работникам компании, то размер транспотрной БД в этот день существенно увеличится. Вот несколько причин, из-за которых может произойти рост транспортной БД:

• внезапное увеличение внутреннего или внешнего почтового трафика
• увеличение значения параметра задерки для сети безопасности (Safety Net)
• увеличение истечения срока действия сообщения на большее количество дней от значения по-умолчанию
• изменение интервала автоматического удаления теневых сообщений в сторону увеличения

Таким образом, было бы не плохо сравнить следующие значения вашей конфигурации со значениями по-умолчанию:

Get-TransportConfig | select SafetyNetHoldTime

Значение по-умолчанию: 2 дня

Get-TransportConfig | select ShadowMessageAutoDiscardInterval

Значение по-умолчанию: 2 дня

Get-TransportService | select name,MessageExpirationTimeout

Значение по-умолчанию: 2 дня

Оценить количество отправленных и принятых писем среднего размера за день можно с помощью журналов отслеживания сообщений (Message tracking logs).

Как рассчитать необходимое дисковое пространство под транспортную базу данных

Чтобы определить максимальный размер транспортной БД, нужно взглянуть на почтовую систему в целом (все сервера), а затем перейти к значению на сервер.

Весь дневной почтовый трафик = количество пользователей х почтовый профиль (используйте эту статью, чтобы вычислить почтовый профиль для вашей организации).
Полный размер транспортной БД = средний размер сообщений х весь дневной почтовый трафик х (1 + (процент сообщений, попадающих в очередь х максимальное количество дней нахождения сообщения в очереди) + количество дней задержки сообщений в сети безопасности (Safety Net)) х 2 копии для высокой доступности.

Для примера возьмём, что у нас 2 000 пользователей и средний размер сообщений составляет 80КБ. Используя эти данные получаем размер транспортной БД:

Полный размер транспортной БД = 80КБ х (2000 пользователей х 200 сообщений/день) х (1 + (50% х 2 дня нахождения сообщения в очереди) + 2 дня задержки сообщений в сети безопасности (Safety Net)) х 2 копии = 80КБ х (400 000) х (1 + 1 + 2) х 2 = 244ГБ

В нашем сценарии мы имеем 1 DAG, который состоит из 4 серверов и спроектирован на обработку отказа 2 серверов. Это значит, что в самом худшем случае у нас может работать 2 сервера и 2 находиться в нерабочем состоянии. Таким образом мы можем определить размер транспотрной БД на сервер:

Размер транспортной БД на сервер = 244ГБ /2 рабочих сервера (худший случай) = 122ГБ

Как было указано ранее, когда сообщение удаляется из транспотной БД mail.que, размер БД не уменьшается. Вместо этого в базе данных образуется «белое пространство» для использования в будущем. Таким образом, если время хранения сообщений в сети безопасности (safety net) составляет 2 дня, то изначально вы увидите экспонентный рост размера транспотрной БД. После двух дней хранения начнётся удаление сообщений из БД и создание «белого пространства». С этого момента данные будут писаться в «белое пространство» БД и размер БД не будет увеличиваться в таком же темпе. Информацию о «белом пространстве» транспортной БД предоставляет счётчик производительности:

\MSExchangeTransport Database\Transport Queue Database Internal Free Space (MB)

Решение проблем, связанных с большим размером транспортной БД

Большой размер mail.que в сотни гигабайт не является проблемой, он в большей степени говорит о том, что в организации высокий почтовый трафик. Но если вы сталкиваетесь с проблемами из-за работы механизма обратной нагрузки (Back pressure) вследствии большого размера файла Mail.que, то первое, что вы можете сделать, чтобы быстро решить проблему — это перенести транспортную БД или файлы журналов транспортной БД на другой жёсткий диск, который имеет достаточно свободного места, сдедуя этой статье.

Если нет доступного жёсткого диска для переноса транспортной БД, то, чтобы быстро решить проблему, можно пересоздать БД. Чтобы сделать это без потери данных, нужно проверить, что в очередях доставки нет сообщений. Нужно проделать следующие шаги:

1. Переключить активные почтовые БД на другой почтовый сервер, чтобы избежать простоя в передаче сообщений из локальных БД
2. Поставить на паузу транспортную службу (Microsoft Exchange Transport Service)
3. Запустить команду Get-queue на почтовом сервере Exchange и убедиться, что все сообщения обработаны и в очередях нет «зависших».
4. Убедиться, что нет других серверов с теневыми сообщениями для этого сервера (в противном случае они будут доставлены заново). Вы можете посмотреть все теневые очереди для конкретного сервера командой:

(Get-MailboxServer).name | Get-Queue | ?{$_.DeliveryType -eq "ShadowRedundancy" -and $_.NextHopDomain -eq "имя_сервера"}

5. Остановить транспортный и внешний транспротный сервисы (Microsoft Exchange Transport и Microsoft Exchange Frontend Transport)

6. Переименовать папку, содержащую транспортную БД

7. Запустить транспортный и внешний транспортные сервисы (Microsoft Exchange Transport и Microsoft Exchange Frontend Transport)

8. Будет создана новая папка с транспортной БД. Убедитесь, что в журнале Приложение появилось событие с идентификатором 7005 : «Новый файл БД mail.que создан»

9. Если транспотная служба запустилась успешно, то можно удалить папку, переименнованную на шаге 6

Подробная инструкция по пересозданию папки с транспортной БД представлена здесь.

Как было указано ранее, начальный рост файла mail.que может быть экспоненциальным, но как только будет достигнуто время задерки для сети безопасности (Safety Net), начнётся удаление сообщений из базы данных и создание «белого пространства». С этого момента начнётся запись новых данных в «белое пространство» и размер БД не будет увеличиваться таким же темпом. Но если проблема не вызвана каким-то недавним увеличением почтового трафика или изменением конфигурации и вы не можете позволить себе иметь большой размер транспортной БД, то можно изменить параметры конфигурации, чтобы уменьшить текущие значения. Например, можно уменьшить время задерки для сети безопасности (Safety Net) с 2-х дней по-умолчанию до 1 дня, используя следующую команду:

Set-TransportConfig -SafetyNetHoldTime 1.00:00:00

Или можно уменьшить интервал удаления теневых сообщений, используя следующую команду:

Set-TransportConfig -ShadowMessageAutoDiscardInterval 1.00:00:00

Счётчики производительности транспортной базы данных mail.que

Хорошей практикой является мониторинг счётчиков производительности транспортной БД для отслеживания потенциальных проблем или внезапные всплески почтового трафика, которые увеличивают размер транспортной БД. В таблице приведено несколько счётчиков производительности с ожидаемыми значениями: