Планирование / очередь больших писем в Exchange 2010, отложить до задержки

Мой вызов

У нас есть серверы Exchange на разных сайтах, но также и на кораблях. Корабли подключены к нашей сети через спутниковую связь, когда находятся в море, но переключаются на мосты WiFi, когда в порту.

Из-за высокой задержки (500+ мс) и нередких выпадений (например, когда корабли поворачивают), попытка отправить любое электронное письмо размером более нескольких мегабайт в море может привести к сбою и повторной попытке до предела Был достигнут. Результат: электронная почта не доставляется, и каждая попытка потребляет ценную полосу пропускания по спутниковой ссылке.

Одно из «решений» - ограничить максимальный размер электронной почты, скажем, 5 МБ, но это вряд ли удобно для пользователя и является ненужным ограничением в порту.

Приблизительное представление

Что я предпочел бы сделать, так это поставить в очередь все электронные письма, размер которых превышает установленное ограничение, для последующей доставки в море, при этом отправляя все небольшие электронные письма немедленно. Тогда я подумал, что буду регулярно пинговать транспортный сервер-концентратор в нашем центре обработки данных. Когда задержка становится меньше ~ 400 мс, я начинаю обрабатывать большую очередь сообщений электронной почты. Когда задержка превышает 400 мс, я закрываю дыру и позволяю электронной почте снова стоять в очереди.

Теперь я не сильно испачкал свои руки с Exchange начиная с версии 2003. В то время вы могли планировать большие электронные письма для последующей доставки, поэтому моя идея заключалась в том, чтобы сделать что-то подобное в Exchange 2010, а затем написать сценарий для переключения доставки. график больших писем между «всегда» и «никогда».

препятствие

Создать такой сценарий не должно быть слишком сложно, но потом я прочитал, что функция, на которую я полагаюсь, была удалена в Exchange 2007:

Эта функция присутствовала в Exchange 2003, но была удалена для Exchange 2007. Она была установлена ​​на соединителе SMTP с «использованием разных сроков доставки для сообщений большего размера».

Техцентр: возможно ли запланировать доставку электронной почты в зависимости от размера в Exchange?

Вопросов

Это правда? - Эта функция больше не присутствует в Exchange 2010 или просто превращена в нечто подобное, что я могу использовать для достижения своей цели? Если так, то?

Есть ли другой способ отложить доставку больших писем на определенных серверах Exchange? Это может быть основано на расписании или, может быть, даже требовать определенных действий - я вполне уверен, что будет какой-то способ инициировать доставку через сценарий, мне просто нужны большие электронные письма в отдельной очереди на кораблях.

Ваши мысли по этому поводу будут высоко оценены! :-)

Edit # 1: уточненная грубая идея

Я наткнулся на два PowerShell CmdLets, которые, я думаю, могут приблизить меня к моей цели:

• Suspend-Message
• Resume-Message

Я поэкспериментировал с Get-Message, чтобы посмотреть, с какими сообщениями будут иметь дело вышеприведенные команды.

Наиболее важно, что эти команды принимают фильтр размера сообщения. Эта команда выведет список сообщений в очереди на текущем сервере размером более 5 МБ (5 242 880 байт):

get-message -Filter {Size -gt 5242880}

Кажется, Get-Messageтолько возвращает сообщения из различных очередей удаленной доставки. Но отображаются ли сообщения, поступающие на сервер, хотя бы кратко, в очередь, с которой будет возиться Get / Suspend / Resume-Message?

Если нет, решение может быть таким простым, как запланированный сценарий каждые несколько минут, в соответствии с (в псевдокоде):

if ping_rtt > 400 Then
    Suspend-Message -Filter {Size -gt 5242880}
Else
    Resume-Message
EndIf

Проблемы / дополнительные вопросы:

В основном неактуальная сейчас - см. Правку № 2.

Будут ли Get-Messageвозвращаться только сообщения из удаленных очередей доставки, а не сообщения для внутрисерверной доставки? Если нет, то соответствует ли идентификационное имя очередей удаленной доставки определенному шаблону, который я могу использовать для фильтрации?

Может ли / должно ли это быть выполнено с помощью специального агента транспорта (как предложено @longneck) или приемника событий (если эта концепция все еще существует в Exchange 2010)?

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

Даже если я проверяю только время прохождения туда-обратно каждые 5 минут (для экономии спутникового трафика), какой механизм Exchange мне нужно настроить, чтобы сравнивать с последним записанным RTT, каждый раз при отправке сообщения, отправляемого на удаленную доставку очереди, а затем предпринять уместные действия?

Редактировать № 2: Предлагаемые решения

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

Таможенный транспортный агент

концепция

• Периодически контролировать задержку, классифицировать как высокий или низкий (порог: 400 мс?)
• Через пользовательский агент транспорта приостановить / возобновить все электронные письма, размер которых превышает установленный порог, при изменении классификации задержки
• Через пользовательский TA сразу же помещайте впоследствии отправленные большие сообщения в режим «приостановки», если задержка высока

Сильные стороны

• Большие сообщения никогда не доставляются при высокой задержке

Слабые стороны

• Нет навыков разработки, чтобы сделать это собственными силами (обратите внимание на себя: исходный код должен принадлежать моей компании в рамках контракта с внешним разработчиком)
• Программное обеспечение сторонних производителей, связанное с Exchange, может вызвать проблемы при исправлении или обновлении
• Требуется какое-то соглашение о поддержке, если что-то пойдет не так (см. Выше)

Умеренные большие сообщения

концепция

• Периодически контролировать задержку, классифицировать как высокий или низкий (порог: 400 мс?)
• На основе классификации задержек настройте правила транспорта Exchange с помощью сценариев, чтобы все сообщения передавались или пересылали большие сообщения модератору.
• Утверждать сообщения в очереди модератора, когда судно находится в порту, возможно, человеком

Сильные стороны

• Большие сообщения никогда не доставляются при высокой задержке
• Сообщения приостанавливаются с использованием собственных собственных правил транспорта Exchange.

Слабые стороны

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

Вопросов

• Могут ли сообщения быть утверждены программно из почтового ящика модератора? Как?

Запланированные команды PowerShell

концепция

• Периодически контролировать задержку, классифицировать как высокий или низкий (порог: 400 мс?)
• Пока задержка высока, часто (каждую минуту?) Приостанавливают любые большие сообщения ( Suspend-Message -Filter {Size -gt 5242880})
• Когда задержка снизится до минимума, возобновите все сообщения ( Resume-Message)

Сильные стороны

• Очень просто реализовать

Слабые стороны

• Не самое элегантное решение
• Доставка каждого нового большого сообщения может быть предпринята до тех пор, пока интервал между Suspend-Messageкомандами, возможно, все еще тратит некоторую пропускную способность и создает перегрузки (хотя очень кратко по сравнению с бездействием)

Вопросов

• Любые идеи о том, как предотвратить попытки доставки больших сообщений, между Suspend-Messageкомандами?
• Будут ли Get-Messageвозвращаться только сообщения из удаленных очередей доставки, а не сообщения для внутрисерверной доставки? Если нет, то соответствует ли идентификационное имя очередей удаленной доставки определенному шаблону, который я могу использовать для фильтрации?

Правка № 3: путь вперед

После представления предложенных решений в моей команде (включая прокси-сервер SMTP, который я не смог включить в правку № 2) и основываясь на своем собственном интуитивном ощущении, мы решили использовать собственный транспортный агент Exchange.

Я нахожусь в контакте с несколькими консалтинговыми компаниями, которые ответят мне, как это решит проблему и сколько это будет стоить.

Если у вас есть опыт работы с задачами аутсорсинга, не стесняйтесь оставлять отзывы на мой связанный с этим вопрос о переполнении стека , потому что я этого не делаю.

Чтобы решить проблему так, как вы просили, вы можете написать свой собственный транспортный агент с помощью Microsoft Exchange Transport Agent SDK . Транспортные агенты основаны на событиях, поэтому Exchange будет вызывать функцию в вашей библиотеке при получении сообщения. Ваша библиотека может сделать что-то вроде удержания сообщения. Если у вас нет внутренних навыков, чтобы сделать это, я уверен, что вы могли бы нанять разработчика, чтобы написать это для вас.

Но я не думаю, что это отличное решение. В качестве альтернативы для исследования вы можете использовать что-то вроде SMTP-прокси для некачественных ссылок. Как вы обнаружили, SMTP - ужасный протокол для низкокачественных каналов, потому что прерванное соединение вызывает перезапуск передачи сообщения с самого начала, а не возобновление с того места, где оно было прервано. Если вы собираетесь нанять разработчика для чего-то, я бы рассмотрел написание серверной программы, которая принимает входящие SMTP-соединения и отправляет сообщение удаленному экземпляру этой же программы на другом конце спутникового соединения в возобновляемой форме ( возможно отделение больших сообщений от небольших сообщений через порт TCP, чтобы ускорить обработку QoS вашим WAN-ускорителем). Удаленный экземпляр может затем, после получения полного сообщения,

Сообщение Модерация

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

Недостатки:

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

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

Транспортные правила Exchange 2010

Пользовательский скрипт

RE: Пользовательский скрипт для управления большими письмами. Я мог видеть что-то вроде ниже, что бы включить / отключить ваш соединитель отправки на сервере Exchange. Недостатком является то, что вся почта удерживается в очереди, а не просто большие сообщения, но некоторая логика в этих направлениях должна работать:

1. Проверьте на задержку. Если он низкий, включите соединитель отправки, отмените приостановку больших сообщений и подождите 5 минут (или другой произвольный промежуток времени). Если оно высокое, отключите отправляющий соединитель.
2. Подожди 5 минут.
3. Через 5 минут проверьте наличие больших сообщений и приостановите их. Повторно включите соединитель отправки, чтобы небольшие сообщения в очереди выпускались до тех пор, пока очередь не станет пустой (вы можете даже циклически проходить по 1 сообщению за раз, чтобы не засорять связь очереди / глобальной сети после повторного включения соединителя отправки)
4. Отключите соединитель отправки и перейдите к # 1

Эта логика не полностью отработана, чтобы иметь смысл на 100%, но вы поняли - поставьте в очередь всю почту, проверьте задержку, приостановите большие сообщения, если она высока, отмените очередь почты, поставьте в очередь всю почту и т. Д. Еще один недостаток запуска Сценарий, подобный следующему: если он когда-нибудь выйдет из строя или остановится, как вы узнаете, как его повторно инициализировать, если на борту корабля нет ИТ-персонала? Он может либо потенциально остановить всю исходящую почту на неопределенный срок (если она останавливается после отключения соединителя отправки), либо вы можете потерять элемент управления большими сообщениями, если он просто оставит соединитель отправки включенным и сценарий больше не будет работать.

SMTP Proxy

Даже несмотря на то, что вы указали, что вы против любой обработки сообщений за пределами Exchange, подумав еще об этом, я решил, что использую @longneck для использования какого-либо SMTP-прокси-решения. Даже в IIS SMTP есть механизм отложенной доставки, который, как может показаться, в Exchange 2010 отсутствует. Вы можете перенаправлять большие сообщения на SMTP-сервер IIS, который может хранить их на диске, и, сначала проверяя наличие задержки, заставить SMTP-сервер IIS отправлять их через сценарий при низкой задержке. В худшем случае, если ваш механизм планирования зависнет или остановится, большие сообщения застрянут на диске, но небольшие сообщения продолжают отправляться. Вероятно, есть лучшие решения, чем IIS SMTP, и я никогда не использовал его сам, но это всего лишь пример.

Настройка электронной почты SMTP в IIS 7

Попробуйте взглянуть на новые функции «Регулирование сообщений», представленные в Exchange 2010 с пакетом обновления 1 (SP1). Это может быть очень полезно для вашего случая использования.

http://technet.microsoft.com/en-us/library/bb232205(v=exchg.141).aspx