ExchangeRUS.ru

Всё о о Microsoft Exchange Server и электронной почте.

Exchange. Глобальные проблемы. Эпизод1. SMTP rerouting

Опубликовано По

Давным давно мне казалось, что Exchange хорош и о его недостатках я не задумывался. НО! С опытом эксплуатации появились вопросы, а «Как сделать …?»

Оказалось, что некоторые вещи Exchange делать не умеет. Что-то Микрософт уже поправил, например автоматическое подключение Outlook 2007 к серверу,  а что-то до сих пор нет. Я хочу написать серию постов об этих недоделках, а на TechEd IT Forum в Барселоне спрошу у мега мозгов из Микрософта о решениях.

Эпизод 1

Рассмотрим простую схему серверов Exchange 2003/2007, состоящую из двух сайтов в Москве и Владивостоке. Между собой серверы обмениваются почтой по «Connector B», а почта в Интернет отправляется через сервер в DMZ на своем сайте.

Example

Предположим, что пользователь из Москвы с  сервера MOS_HUB отправляет письмо в Интернет. Роутинг настроен так, чтобы письмо ушло на MOS_EDGE и затем в Инет. Что будет, если линк с «ISP MOS» пропал? Письмо придет на сервер MOS_EDGE и будет спокойно ждать 2 дня в очереди и затем вернется пользователю. А ведь у нас есть второй канал в Интернет.

 БЫЛО БЫ ХОРОШО РЕРОУТИТЬ ПОЧТУ НА ДРУГОЙ СЕРВЕР АВТОМАТИЧЕСКИ.

Сейчас такого Exchange делать не умееет, ни 2003, ни 2007. Это объяснимо, т.к. Exchange не может определить состояние канала в Интернет. Между своими серверами умеет определять, а состояние Интернета — нет. 

Алгоритм работы мог бы быть такой. Сервер MOS_EDGE мог бы пинговать через определенное время три независимых сервера в различных подсетях в Интернете.
Если все трое недоступны, значит Интернета нет и можно почту смело рероутить на VLA_EDGE. Это простейший алгоритм и очень хороший.

Это можно реализовать даже сейчас.  Программа работает на MOS_EDGE и пингует внешние серверы. Если время «Ч» наступило, то останавливаем SMTP сервис, переделываем программно в AD коннектор, запускаем SMTP сервис и почта уходит через другого провайдера. Здорово, еще бы реализатор нашелся 🙂

Какое решение данной ситуации есть на данный момент? Сейчас можно переключать коннекторы вручную. Но разве это дело?

Поэтому я хочу задать этот вопрос гуру на конференции,  может что подскажут.  Если у Вас есть идеи, напишите. Может Exchange умеет это делать, а я просто не знаю.

 

Что же касается приема, то почта будет принята ВСЕГДА! Просто MX записи делают две, на MOS_EDGE или VLA_EDGE. Тогда падение провайдера или сервера на входящую почту влиять не будут.

Похожие посты:

  • Sadok

    Выяснение «есть инет или нет» это совсем не задача Эксча. И вмешиваться в роутинг тоже. Это MTA. (Если б мой postfix начал рулить роутингом на шлюзе, я бы зело удивился 🙂 )

  • http://www.exchangerus.ru Pavel Nagaev

    Я ждал такого ответа.
    Роутинг, имелось виду почтовый роутинг, но никак не TCP/IP-шный.

    Эту задачу можно выполнить средствами Exchange, ведь для своих серверов он это может делать.

  • Sadok

    Тогда причем здесь «А ведь у нас есть второй канал в Интернет»? Никоим образом это не касается почтового роутинга. Просто почта наружу пойдет другим путем. Даже если это «внутренняя» почта (между офисами поднят VPN, например), то задача клиента или сервера восстановить подключение, не более того.

  • Sadok

    …а вообще да — указывать для коннекторов «альтернативные» маршруты было бы неплохо

  • http://www.exchangerus.ru Pavel Nagaev

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

    Sadok, каким образом отказоустойчивость делается на уровне каналов?
    Расскажите хотя бы в общем.

  • Sadok

    Способов много. От простейшего скрипта, который через заданный интервал пингует какой-нибудь сервер в инте, и при отстутствии ответа переписывает default gateway на сервере, до динамической маршрутизации (BGP и т.п.) Про второе можно почитать на http://www.opennet.ru/keywords/bgp.html

  • Алексей

    Вопрос — а в эксчендже нельзя сделать fallback relay (как например, в postfix, т е если письмо не смогло уйти нормальным путем — отправляем его на другой сервер, который возможно знает как пропихнуть его дальше). Это не совсем рероутинг — но некое «подобие левой руки» 😎

  • http://www.exchangerus.ru Pavel Nagaev

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

    Коннекторы SMTP не умеют определять конечное состояние сервера SMTP, плюс сам протокол SMTP вполне допускает доставку в течении двух суток.
    Я не знаю, что такое fallback relay в postfix, но наверное это разновидность функционала про который я писал выше.

    В postfix это ведь реализовали? А что мешает это сделать в Exchange?

  • Алексей

    http://www.postfix.org/postconf.5.html#fallback_relay
    там искать по слову fallback — насколько я понял это то, что вам хочется от эксченджа.

    Сам протокол SMTP, насколько я помню, ничего не говорит про время доставки 8-), т е 4хх — попытайся еще (сколько практически во всех мейлсерверах рулится параметрами конфигурации), 5хх — отваливай сразу 😎

  • http://www.exchangerus.ru Pavel Nagaev

    Алексей,
    почитал я про fallback_relay. Хорошо бы почитать, как это работает в деталях.

    By default, mail is returned to the sender when a destination is not found, and delivery is deferred when a destination is unreachable.

    Да, именно это мне и нужно.

    А это смотря какая реализация протокола SMTP :-). По стандарту так и есть, но что мешает добавить ему немного ума:-)

  • Алексей

    Нууу — сайт есть http://www.postfix.org/ — доки там есть тоже 😎 — может осознание «того как» и поможет сформулировать «что надо»? 😎
    Про детали боюсь придется лезть в сырцы 8-/

  • http://www.exchangerus.ru Pavel Nagaev

    Это-то понятно, но на данном этапе меня интересует Exchange. Два postfixа у меня стоят в DMZ и я могу сделать через них отправку по описанному выше способу, но не буду. Пока.

    За саму информацию о том, что такая фишка есть у postfix — спасибо, не знал.

  • Michael Gotch

    Ну а что fallback_relay. Я так понимаю, что это просто отправка почты через альтернативный релей при ошибке и не более. И от падения канала спасает только выбором очень хитрого альтернативного релея.

    И с вашей схемой, если наделить граничные EDGE серверы этим функционалом, так вот просто работать не будет.
    Требуется коннектор непосредственно между MOS_EDGE и VLA_EDGE, что зачастую просто невозможно, так как надо из одной dmz пробраться в другую dmz через корпоративную сеть.

    Другое дело если эта функция была бы у HUB серверов. Однако все просто когда на картинке 4 сервера, а когда их 150? С роутингом бардак будет жутчайший. А разрешения на relay? Не боитесь запутаться?

    А как отнесутся во Владивостоке, что через них полез многомегабайтный трафик из Мск? Например с чудесными mp3 друзьям-знакомым. А почему и нет, в Мск-то канал 10 mbit/s, а во Владике только 2.

  • http://www.exchangerus.ru Pavel Nagaev

    Михаил, главное то, что в postfix об этом позаботились. Реализация — не важно. В Exchange об этом не подумали, сделали только на уровне внутренних коннекторов.

    Вы нам дайте молоток, а уж или гвозди забивать или голову пробить мы сами решим 🙂

    Между DMZ конечно ничего не должно ходить, но на хабах запросто, а про 150 штук. Думаю у тех админов о другом голова болит 🙂

    Трафик дело серьезное, но SMTP сделан для того, чтобы работать в жестких условиях. Трафик можно ведь и ужать, в смысле не сжать, а приоритеты назначить. И кстати я наверное злой админ, но у нас аттачи с mp3 и командным файлам к пересылке запрещены. Режутся. Конечно можно переименовывать, архивировать, но те люди, которые это смогут сделать, никогда не будут посылать mp3. Ведь если пользователь пригрузил хорошо канал, значит ему скоро позвонят 🙂

  • http://www.ogk-5.com Anton

    Выскажусь:
    У меня 5 ЭКСов 2003 и все в разных лесах.
    Между лесами доверилка.
    Один из Эксов стоит в Москве, остальные 4 по России.
    Между Эксами есть корпоративные каналы, по ним почта роутиться по доменным именам лесов.
    Каждый Экс в лесе имеет свой канал на выход в Инет. В случае пропадания канала Интернет, Любой Экс может переправить почту на Экс в Москву и дальше в инет.
    К сожалению, все это на полуавтоматическом варианте.
    Реализовал конекторы между Эксами и выставил веса для вариантов Use to Host.

  • lanos

    в exchange новичок, поясните по поводу коннекторов, в них смысл — если оба удаленных офиса соединены отдельными каналами, не через Инет выходит?

  • http://www.exchangerus.ru Pavel Nagaev

    Перефразируйте вопрос, не понятно, что Вас точно интересует.

    Коннекторы — это правила маршрутизации почты.