Мій виклик
У нас є сервери Exchange на різних сайтах, але також на борту кораблів. Кораблі підключені до нашої мережі за допомогою супутникових зв’язків у морі, але перемикаються на мости WiFi, коли вони в порту.
Через високу затримку (500+ мс) та нечасті вибування (наприклад, коли судна повертаються), спроба надіслати будь-яку електронну пошту вище декількох мегабайт у морі, ймовірно, не вдасться та буде повторено повторно до межі було досягнуто. Результат: електронна пошта не надходить, і кожна спроба споживає цінну пропускну здатність по посиланню.
Одне "рішення" - обмежити максимальний розмір електронної пошти, щоб сказати, 5 Мб, але це навряд чи дружнє для користувачів і зайве обмеження під час перебування в порту.
Приблизна ідея
Я хотів би зробити те, щоб встановити чергу на всі електронні листи, що перевищують встановлений ліміт для подальшої доставки у море, при цьому надсилаючи всі невеликі електронні листи негайно. Тоді я думав, що регулярно надсилаю сервер транспортного центру в наш центр обробки даних, коли затримка падає менше ~ 400 мс, я б розпочала обробку великої черги електронної пошти. Коли затримка збільшується понад 400 мс, я заткну отвір і знову надішлю черги на електронну пошту.
Тепер я не забруднив руки Exchange від версії 2003 року. Тоді ви могли запланувати великі електронні листи для подальшої доставки, тому моя ідея була зробити щось подібне в Exchange 2010, а потім написати сценарій способу переключення доставки. графік великих електронних листів між "завжди" і "ніколи".
Перешкода
Створювати подібний сценарій не повинно бути надто складно, але потім я прочитав, що функція, на яку я покладався, була видалена з Exchange 2007:
Ця функція була присутньою в Exchange 2003, але вона була видалена для Exchange 2007. Вона була встановлена на роз'ємі SMTP з "використанням різних строків доставки для повідомлень великих розмірів".
TechCenter: Чи можна запланувати доставку електронної пошти залежно від розміру в Exchange?
Запитання
Це правда? - Чи ця функція більше не присутня в Exchange 2010 або вона просто перетворилася на щось подібне, я можу використовувати для досягнення своєї мети? Якщо так, то що?
Чи є інший спосіб відкласти доставку великих електронних листів на певні сервери Exchange? Це може базуватися на графіку або, можливо, навіть вимагати конкретних дій - я впевнений, що буде якийсь спосіб запустити доставку через сценарій, мені просто потрібні великі електронні листи в окремій черзі на кораблі.
Ваші думки з цього приводу будуть високо оцінені! :-)
Редагувати №1: Вишукана груба ідея
Я натрапив на два PowerShell CmdLets, я думаю, що можуть наблизити мене до своєї мети:
Я пограв з Get-Message на деякий час, щоб побачити, з якими повідомленнями матимуть справу команди вище.
Найголовніше, що ці команди приймають фільтр розміру повідомлення. Ця команда буде перераховувати в черзі повідомлення на поточному сервері, що перевищує 5 Мб (5 422 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 мс?)
- За допомогою спеціального транспортного агента призупинити / відновити всі електронні листи, що перевищують встановлений поріг, коли класифікація затримок змінюється
- За допомогою спеціальної ТА негайно перекладіть подані великі повідомлення в режим "призупинення", якщо затримка висока
Сильні сторони
- Великі електронні листи ніколи не намагаються доставляти, коли затримка висока
Слабкі сторони
- Ніяких навичок розробки для створення цього власного будинку (зауважте, я: вихідний код повинен належати моїй компанії як частина договору із зовнішнім розробником)
- Програмне забезпечення сторонніх виробників, яке зв’язується з Exchange, може спричинити проблеми під час виправлення або оновлення
- Якась угода про підтримку необхідна, якщо щось піде не так (див. Вище)
Помірні великі повідомлення
Концепція
- Періодично контролюйте затримку, класифікуйте як високу або низьку (поріг: 400 мс?)
- На основі класифікації затримок налаштовуйте правила транспорту Exchange за допомогою сценаріїв, щоб вони дозволяли потоку всіх повідомлень або пересилали великі повідомлення модератору
- Затвердити повідомлення в черзі модератора, коли корабель знаходиться в порту, можливо, людиною
Сильні сторони
- Великі електронні листи ніколи не намагаються доставляти, коли затримка висока
- Повідомлення призупиняються за допомогою власних правил власного транспорту Exchange
Слабкі сторони
- По зовнішньому вигляду повідомлення не можуть бути затверджені програмно, коли затримка низька, тому необхідне втручання людини щоразу, коли корабель знаходиться у порту
- Можливо, проблеми конфіденційності, якщо модерація не обробляється програмно
Запитання
- Чи можна схвалювати повідомлення програмно з поштової скриньки модератора? Як?
Заплановані команди PowerShell
Концепція
- Періодично контролюйте затримку, класифікуйте як високу або низьку (поріг: 400 мс?)
- Поки затримка висока, часто (щохвилини?) Призупиняйте будь-які великі повідомлення (
Suspend-Message -Filter {Size -gt 5242880}) - Коли затримка знизиться до низької, відновіть усі повідомлення (
Resume-Message)
Сильні сторони
- Дуже простий у виконанні
Слабкі сторони
- Не найелегантніше рішення
- Доставка кожного нового великого повідомлення може здійснюватися протягом тих пір, поки інтервал між
Suspend-Messageкомандами, можливо, все-таки витрачає деяку пропускну здатність і створює перевантаження (хоча дуже коротко, порівняно з тим, що нічого не робити)
Запитання
- Будь-які ідеї, як запобігти спробам доставки великих повідомлень між
Suspend-Messageкомандами? - Буду
Get-Messageповертати тільки повідомлення з черг віддаленої доставки - ніколи повідомлення для доставки всередині сервера? Якщо ні, чи відповідає ім'я особи віддалених черг доставки певній схемі, яку я можу використовувати для фільтрації?
Правка №3: Шлях вперед
Після підбору запропонованих рішень у моїй команді (включаючи проксі-сервер SMTP, який мені не вдалося включити у редагування №2), і виходячи з власного відчуття кишки, ми вирішили звернутися до спеціального транспортного агента Exchange.
Я контактую з декількома компаніями-консультантами, які повернуться до мене з тим, як буде атакувати проблему і що це буде коштувати.
Якщо у вас є досвід виконання завдань програмування аутсорсингу, не соромтесь залишити відгуки на моє відповідне питання щодо переповнення стека , оскільки я цього не роблю.