Если вы хотите прочитать другие части этого цикла статей, перейдите по ссылкам:
- Развёртывание Exchange 2007 Edge Transport Server (часть 1)
- Развёртывание Exchange 2007 Edge Transport Server (часть 2)
- Развёртывание Exchange 2007 Edge Transport Server (часть 3)
- Развёртывание Exchange 2007 Edge Transport Server (часть 4)
- Развёртывание Exchange 2007 Edge Transport Server (часть 5)
Введение
В большинстве компаний в мире через электронную почту решаются наиболее ответственные задачи. Тысячи, а в некоторых случаях и миллионы сообщений отправляются и принимаются пользователями в большой корпорации ежедневно. Кроме того, внутренние линии бизнес-приложений зависят от возможности успешно передавать сообщения через серверы Exchange 2007 Hub Transport, развернутые внутри корпорации. Это означает, что вам нужно развернуть солидную и надежную транспортную инфраструктуру, не только избыточную, но и хорошо сбалансированную на всех уровнях.
В таких больших корпорациях обычно получается столько сообщений от внешних пользователей, сколько бизнес партнеров и пользователей у них есть. В связи с этим почтовые шлюзы, выходящие в Интернет и находящиеся в пограничной зоне, должны соответствовать мощности и надежности транспортной инфраструктуры, развернутой внутри корпорации. Такие шлюзы должны быть всегда доступны, а также сбалансированно настроены, так чтобы входящие сообщения распределялись равномерно по серверам.
В этой статье я опишу, как можно настроить серверы Exchange 2007 Edge Transport, имея в виду их избыточность и хорошую сбалансированность. Шаги, описанные в этой статье, могут быть использованы практически для любого типа шлюзового решения, используемого вами.
Решение
Для данной статьи описываемая среда содержит распределение шлюзов электронной почты, состоящее, в свою очередь, из четырех серверов Exchange 2007 Edge Transport, распределенных по двум центрам данных. Оба активны, и показаны на Рисунке 1.
Рисунок 1: Четыре сервера Edge Transport, распределенные между двумя центрами данныхТе, кто уже ознакомился с предыдущими статьями этого цикла, знают, что сервер Edge Transport может быть приписан к узлу Active Directory, содержащему один или более серверов Hub Transport. Поскольку серверы Hub Transport являются по умолчанию восстанавливаемыми, входящие сообщения от серверов Edge Transport приграничной зоны будут доставляться до сервера Hub Transport в узле Active Directory, к которому приписан соответствующий сервер Edge Transport через Edge Subscription (см. третью статью этого цикла для получения подробной информации по Edge Subscription). Поскольку вы приписываете сервер Edge Transport к узлу AD, а не к серверу Hub Transport в узле AD, и так как серверы Hub Transport имеют встроенные механизмы восстановления и балансировки нагрузки, вам не нужно дополнительно настраивать что-либо для балансировки нагрузки и восстанавливаемости на узле AD. Когда у вас появляется как минимум два сервера Hub Transport на каждом узле AD, сервер Edge Transport сможет правильно решать, которому из двух серверов Hub Transport отправлять то или иное сообщение. Решение принимается на основании метода Round Robin. Конкретнее, каждый сервер Hub Transport на узле AD, к которому приписан сервер Edge Transport, указан как умный хост для коннектора отправления, созданного между сервером Edge Transport и соответствующим узлом AD.
Замечание:При добавлении нового сервера Hub Transport к узлу AD вам нужно создать новую подписку к данному узлу AD.
Итак, как же нам достигнуть восстанавливаемости и балансировки нагрузки от Интернета для наших серверов Edge Transport? Достичь этого можно различными способами. Самый простой – использовать аппаратную балансировку перед серверами Edge Transport, но так как эта балансировка тоже должна быть избыточной, нужно разместить как минимум два балансировщика нагрузки. Аппаратные балансировщики нагрузки недешевы, поэтому можно поискать более дешевое решение. Такое решение имеется, и я его собираюсь описать в этой статье.
Мы просто создаем две почтовые записи - mail1.exchangehosting.dk и mail2.exchangehosting.dk и обе приписываем нашему домену, в этой статье - exchangehosting.dk. Каждой записи мы назначаем одинаковую стоимость (например, 10). И, наконец, мы добавляем две А-записи (узлы Edge Transport) к каждой почтовой записи. Теперь каждая почтовая запись должна содержать А-запись от центра данных 1 и от центра данных 2. Эта конфигурация проиллюстрирована на Рисунке 2 ниже.
Рисунок 2: Равноценные почтовые записи с двумя А-записями в каждойНаличие двух почтовых записей, указывающих на одинаковый SMTP домен, обеспечивает нужный выбор при случайной отборе с использованием метода round robin. Некоторые из вас могут спросить, почему именно две А-записи на каждую почтовую запись. Это происходит из-за того, что некоторые MTA (message transfer agent – агент пересылки сообщений) будут выбирать одну и ту же почтовую запись вне зависимости от того, сколько почтовых записей настроено для данного домена. Что касается Exchange Server, это было проблемой на протяжении многих лет (не только в Exchange 2000), но, к сожалению, и до сих пор есть такие MTA, в которых встречается подобный недостаток. Поэтому нет никакой разницы, какой именно MTA пытается доставить сообщение по адресу Exchangehosting.dk, все SMTP соединения распределяются с помощью комбинации методов DNS Round Robin и балансирования нагрузки.
Обеспечение отказоустойчивости и балансировки нагрузки для исходящих сообщений
Итак, как же вам сбалансировать нагрузку при одновременно обеспечении отказоустойчивости для потока исходящей почты (т.е. сообщений, покидающих организацию Exchange)? В действительности это очень просто. Вам нужно всего лишь убедиться, что к узлу AD приписано более одного сервера Edge Transport, при этом они добавляются на вкладке Source Server коннектора отправления, который занимается маршрутизацией сообщений на (от) сервер (ы) Edge Transport в вашей приграничной сети.
Замечание: Серверы Edge Transport автоматически добавляются на странице свойств коннектора отправления, а настройки автоматически распространяются на серверы Edge Transport, указанные на вкладке Source Server.
Для того чтобы убедиться, что серверы Edge Transport присутствуют в коннекторе отправления, вам нужно открыть консоль Exchange Management Console (EMC), затем развернуть узел Organization Configuration work Center в навигационном дереве с левой стороны EMC. Здесь вам нужно выбрать Hub Transport и перейти на вкладку Send Connector. Затем вам нужно открыть страницу свойств соответствующего коннектора и щелкнуть на вкладку Source Server (Рисунок 3).
Рисунок 3: Приписанный сервер Edge Transport указан на вкладке Source ServerВам входящие сообщения теперь будут распределены между серверами, и если какой-нибудь из этих серверов падает (по тем или иным причинам), сервер Hub Transport, которому нужно доставить сообщения до адресатов вне организации, выберет следующий сервер по методу round robin.
Замечание: Если коннектор отправления, маршрутизирующий сообщения от организации настроен доставлять сообщения на умный хост, пожалуйста, убедитесь, что добавлено несколько умных хостов, так что у вас нет неподстрахованной точки отказа в вашей топологии отправки сообщений.
Резюме
В шестой части (кстати, последней) этого цикла статей, описывающего серверы Edge Transport, я объяснял, как вы можете достичь хорошей избыточности и балансировки нагрузки для потока сообщений между Интернетом и серверами Edge Transport, расположенными в приграничной области, а также от них к узлам AD, содержащим серверы Hub Transport.
Если вы хотите прочитать другие части этого цикла статей, перейдите по ссылкам:
- Развёртывание Exchange 2007 Edge Transport Server (часть 1)
- Развёртывание Exchange 2007 Edge Transport Server (часть 2)
- Развёртывание Exchange 2007 Edge Transport Server (часть 3)
- Развёртывание Exchange 2007 Edge Transport Server (часть 4)
- Развёртывание Exchange 2007 Edge Transport Server (часть 5)
