У нас есть серверы Exchange на разных площадках, а также на борту судов. Суда подключаются к нашей сети через спутниковые каналы в море, но переключаются на мосты Wi-Fi в порту.
Из-за большой задержки (500+ мс) и нередких отказов (например, когда корабли поворачиваются) попытка отправить любые электронные письма размером более нескольких мегабайт в море, скорее всего, потерпит неудачу и будет повторена до предела. Был достигнут. Результат: электронное письмо не доставляется, и каждая попытка потребляет ценную полосу пропускания спутниковой связи.
Одно «решение» - ограничить максимальный размер электронной почты, скажем, 5 МБ, но это вряд ли удобно для пользователя и является ненужным ограничением в порте.
Я бы предпочел поставить в очередь все электронные письма, размер которых превышает установленный предел, для последующей доставки в море, одновременно отправляя все небольшие электронные письма немедленно. Тогда я думал, что буду регулярно пинговать транспортный сервер-концентратор в нашем центре обработки данных, и когда задержка упадет ниже ~ 400 мс, я начну обрабатывать большую очередь электронной почты. Когда задержка превышает 400 мс, я закрываю дыру и позволяю электронной почте снова вставать в очередь.
Я не особо пачкал свои руки с Exchange с версии 2003. В то время вы могли запланировать большие электронные письма для более поздней доставки, поэтому моя идея заключалась в том, чтобы сделать что-то подобное в Exchange 2010, а затем написать сценарий для переключения доставки расписание для больших писем между «всегда» и «никогда».
Создать такой сценарий не должно быть слишком сложно, но потом я прочитал, что функция, на которую я полагался, была удалена в Exchange 2007:
Эта функция присутствовала в Exchange 2003, но была удалена в Exchange 2007. Она была настроена на коннекторе SMTP с «использованием разных сроков доставки для сообщений большого размера».
TechCenter: Можно ли запланировать доставку электронной почты в зависимости от размера в Exchange?
Это правда? - Эта функция больше не присутствует в Exchange 2010 или она просто преобразована во что-то подобное, которое я могу использовать для достижения своей цели? Если да, то?
Есть ли другой способ отложить доставку больших писем на определенные серверы Exchange? Это может быть основано на расписании или, возможно, даже требовать определенных действий - я почти уверен, что будет какой-то способ инициировать доставку через скрипт, мне просто нужны большие электронные письма в отдельной очереди на кораблях.
Мы будем очень признательны за ваши мысли по этому поводу! :-)
Я наткнулся на два PowerShell CmdLet, которые, как мне кажется, могут приблизить меня к моей цели:
Я некоторое время поигрался с 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, каждый раз, когда отправляется сообщение, которое отправляется на удаленную доставку очереди, а затем предпринять соответствующие действия?
Позвольте мне резюмировать предлагаемые решения, а также их плюсы и минусы, как я это вижу:
Пользовательский транспортный агент
Концепция
Сильные стороны
Слабые стороны
Умеренные большие сообщения
Концепция
Сильные стороны
Слабые стороны
Вопросы
Запланированные команды PowerShell
Концепция
Suspend-Message -Filter {Size -gt 5242880})Resume-Message)Сильные стороны
Слабые стороны
Suspend-Message команды, возможно, все еще тратя некоторую пропускную способность и создавая перегрузки (хотя очень кратко по сравнению с бездействием)Вопросы
Suspend-Message команды?Get-Message возвращать только сообщения из очередей удаленной доставки - никогда сообщения для внутрисерверной доставки? Если нет, соответствует ли идентификационное имя очередей удаленной доставки определенному шаблону, который я могу использовать для фильтрации?После того, как моя команда представила предлагаемые решения (включая прокси-сервер SMTP, который мне не удалось включить в правку № 2), и, основываясь на моем внутреннем чутье, мы решили перейти на настраиваемый транспортный агент Exchange.
Я связываюсь с парой консалтинговых компаний, которые свяжутся со мной и расскажут, как они решат проблему и сколько это будет стоить.
Если у вас есть опыт работы с задачами программирования на аутсорсинге, вы можете оставить отзыв на мой связанный вопрос о переполнении стека, потому что я этого не делаю.
Модерация сообщений
Одним из, вероятно, неидеальных решений является использование правила транспорта для пересылки сообщений более определенного размера либо менеджеру отправителя, либо указанному почтовому ящику (на судовом сервере Exchange) для модерации. Таким образом, если они находятся в море, большие сообщения могут быть помещены в очередь в другом почтовом ящике. Когда судно прибывает в порт, менеджер или назначенный модератор может утвердить их для доставки.
Минусы:
Одним из положительных моментов является то, что у вас будет человек, принимающий решения о том, следует ли отправлять сообщение, например, если бы пользователь пытался отправить кучу не связанного с работой дерьма, которое просто без причины прервало бы соединение. Их можно исправить с помощью административных элементов управления, например, указав на политику и похлопав их по запястью, чтобы они больше не делали этого.
Правила транспорта Exchange 2010
Пользовательский сценарий
RE: Пользовательский сценарий для управления большими электронными письмами. Я мог видеть что-то вроде приведенного ниже, которое могло бы включать / отключать ваш коннектор отправки на сервере Exchange. Обратной стороной является то, что в очереди хранится вся почта, а не только большие сообщения, но некоторая логика в этом направлении должна работать:
Эта логика не полностью доработана, чтобы иметь 100% смысл, но вы поняли идею - ставить в очередь всю почту, проверять задержку, приостанавливать большие сообщения, если она высокая, не ставить в очередь почту, ставить в очередь всю почту и т. Д. Еще один недостаток работы такой сценарий, если он когда-либо выйдет из строя или остановится, как вы узнаете, что нужно повторно инициализировать его без ИТ-персонала на борту корабля? Он может либо потенциально остановить всю исходящую почту на неопределенный срок (если она останавливается после отключения соединителя отправки), либо вы можете потерять контроль над большими сообщениями, если он просто оставит включенным соединитель отправки и сценарий больше не будет работать.
Прокси-сервер SMTP
Несмотря на то, что вы указали, что вы против любой обработки сообщений вне Exchange, подумав об этом еще немного, я решил, что я с @longneck использую какой-либо тип прокси-сервера SMTP. Даже в IIS SMTP есть механизм отложенной доставки, которого, казалось бы, нет в Exchange 2010. Вы можете перенаправить большие сообщения на SMTP-сервер IIS, который может хранить их на диске, и, предварительно проверив задержку, попросить SMTP-сервер IIS отправлять их через скрипт при низкой задержке. В худшем случае, если ваш механизм планирования зависнет или остановится, большие сообщения застрянут на диске, но небольшие сообщения будут отправляться. Вероятно, есть решения лучше, чем IIS SMTP, и я сам никогда не использовал их, но это всего лишь пример.
Попробуйте взглянуть на новые функции «Регулирования сообщений», представленные в Exchange 2010 SP1. Это может быть очень полезно для вашего варианта использования.
http://technet.microsoft.com/en-us/library/bb232205(v=exchg.141).aspx
Чтобы решить проблему так, как вы просили, вы можете написать своего собственного транспортного агента, используя Пакет SDK транспортного агента Microsoft Exchange. Транспортные агенты основаны на событиях, поэтому Exchange будет вызывать функцию в вашей библиотеке при получении сообщения. Затем ваша библиотека может делать что-то вроде удержания сообщения. Если у вас нет навыков для этого, я уверен, что вы могли бы нанять разработчика, который напишет это за вас.
Но я не думаю, что это отличное решение. В качестве альтернативы, которую вы можете исследовать, вы можете поискать что-то вроде прокси-сервера SMTP для некачественных ссылок. Как вы обнаружили, SMTP - ужасный протокол для низкокачественных ссылок, потому что прерванное соединение вызывает перезапуск передачи сообщения с самого начала, а не возобновление с того места, где она была прервана. Если вы собираетесь нанять разработчика для чего-то, я бы подумал о написании серверной программы, которая принимает входящие SMTP-соединения и отправляет сообщение удаленному экземпляру этой же программы на другом конце спутникового соединения с возможностью возобновления ( возможно отделение больших сообщений от мелких через порт TCP, чтобы обеспечить обработку QoS вашим ускорителем WAN). После получения полного сообщения удаленный экземпляр может завершить доставку сообщения через SMTP.