среда, 25 мая 2011 г.

Маршрутизация сообщений Microsoft Exchange 2010 в многосайтовой среде Active Directory

clip_image002

На этот раз будет только теория.

Часто случается так, что системные администраторы вынуждены делить локальную сеть предприятия на логические компоненты. Эта потребность может быть вызвана как физическими особенностями сети, так и задачами ограничения контроля доступа и оптимизацией трафика репликации Active Directory. При разделении локальной сети на подсети и объединение подсетей в сайты Active Directory накладывает определенные особенности на организацию маршрутизации сообщений в среде Microsoft Exchange 2010.

Членство Microsoft Exchange 2010 в сайте Active Directory

Во время создания первого домена в лесу Active Directory, автоматически создается и первый сайт – Default-First-Site-Name. Этот сайт по умолчанию включает в себя всех членов домена в лесу. Для разделения домена на сайты, необходимо сопоставить для каждого сайта одну или несколько IP-подсетей. В результате, все компьютеры, входящие в IP-подсеть, будут являться членами связанного с ней сайта. Это не относиться к контроллерам домена и серверам глобального каталога, для них принадлежность к сайту определяется администратором.

Microsoft Exchange 2010 поддерживает работу с сайтами и может сам определить к какому сайту он подключен. Более того, для маршрутизации сообщений Exchange 2010 использует именно топологию Active Directory. Границей маршрутизации сообщений и поиска служб для Exchange Server 2010 являются границы сайта Active Directory.

При запуске компьютера, служба сетевого входа в систему определяет членство компьютера в сайте и использует эти сведения для дальнейшего поиска контроллеров домена. При этом служба топологии Microsoft Exchange Active Directory, получает имя сайта от службы сетевого входа в систему и записывает это значение в атрибут msExchServerSite для объекта сервера Exchange в каталоге Active Directory. Далее этот атрибут используется для считывания топологии Active Directory и поиска других серверов Exchange. Кроме того, сопоставление членства в сайтах включается и для подписанных пограничных транспортных серверов.

Переместить сервер Exchange в другой сайт можно сменой его IP-адреса на адрес подсети сопоставленной с нужным сайтом, либо изменив сопоставление подсетей для сайтов. При этом служба сетевого входа в систему обновит членство компьютера в сайте примерно через 5 минут после того, как эта информация появится на контроллере домена, а службы топологии Microsoft Exchange Active Directory через 15 минут обновит атрибут msExchServerSite. Далее эта информация реплицируется в организации и остальные сервера Exchange обновят свои таблицы маршрутизации.

Связи сайтов

Для взаимодействия сайтов между собой в Active Directory применяются связи сайтов (Site-links). При этом данные связи не отражают действительного маршрута пакетов в физической среде, а являются лишь логическими путями между сайтами. За создание связей между сайтами отвечает служба KCC (Knowledge Consistency Checker). Она автоматизирует процесс создания связей, пытаясь объединить сайты в кольцо и только при наличии более трех «прыжков» между сайтами создает дополнительный связи. Не рекомендуется создавать связи между сайтами в ручном режиме, т.к. в этом случае служба КСС не сможет ими управлять. По умолчанию все связи между сайтами транзитивны, т.е. если несколько сайтов связаны между собой линейно (по цепочке), то первый и последний член этой цепочки могут связываться друг с другом мостом через все промежуточные звенья.

Связи могут быть двух видов:

  • IP-связь – использует протокол IP в качестве транспортного. По ней передаются любые типы данных;
  • SMTP-связь – использует протокол SMTP и ограничена в типах данных, которые могут пересылаться. Используется в исключительных случаях, когда нет надежного канала связи между сайтами.

Microsoft Exchange Server 2010 использует только IP-связи.

Для выражения качества связи между сайтами в количественной форме применяется параметр стоимость связи. По умолчанию существует одна IP-связь – DEFAULTIPSITELINK, все сайты, сопоставленные с ней, могут связываться друг с другом по единой стоимости. Для создания своей собственно топологии сайтов, необходимо самостоятельно создать дополнительные IP-связи и указать для них стоимость от 1 до 99 9999 (по умолчанию 100). При этом компонент маршрутизации сервера Microsoft Exchange 2010 будет учитывать эти стоимости при расчете таблицы маршрутизации.

Стоимость связей для серверов Exchange и использование сайта-концентратора

Топология сайтов Active Directory, установленная администраторами домена, может не соответствовать требованиям маршрутизации почтовых сообщений. Для оптимизации таблиц маршрутизации, к существующим IP-связям может быть установлена дополнительная стоимость для серверов Exchange. Делается это командлетом Set-AdSitelink при помощи параметра -ExchangeCost следующим образом:

Set-AdSitelink –Identity <YourSiteLink> ExchangeCost 50

В результате, при наличии такой стоимости, именно она будет использоваться сервером Exchange, в противном случае будет принята стоимость Active Directory. Возможность установки собственной стоимости IP-связей для серверов Exchange позволяет очень гибко настроить маршрутизацию почтового трафика в организации.

По умолчанию, при пересылке сообщений между сайтами, транспортные сервера-концентраторы (HUB), находящиеся на пути между исходным и конечным серверами, не принимают участия в пересылке и ни как не взаимодействуют с сообщением. Но при необходимости, можно настроить поток почты таким образом, чтобы он проходил через определенный транспортный сервер-концентратор (HUB). Делается это, например, с целью контроля переписки пользователей. Подобная настройка выполняется при помощи командлета Set-AdSite. Здесь нужно учитывать то, что указанный сайт должен быть на пути с наименьшей стоимостью между исходным и конечным сайтами.

Рекомендации по размещению северов

В результате можно сформулировать следующий набор моментов, на которые нужно обратить внимание при планировании размещения ролей сервера Microsoft Exchange в лесе Active Directory:

Чтобы маршрутизация сообщений между ролями Exchange 2010 осуществлялась правильно, все роли, развернутые в лесу, должны принадлежать некоторому сайту Active Directory. Убедитесь в том, что назначенные IP-адреса находятся в подсетях, надлежащим образом связанных с сайтами Active Directory.

Первым действием, которое необходимо выполнить при планировании размещения серверов Exchange 2010 в топологии сайтов Active Directory, является документирование текущей топологии. В этот документ необходимо включить следующие сведения.

  • Сайты
  • Подсети и относящиеся к ним сайты
  • IP-связи сайтов и входящие в них сайты
  • Стоимости IP-связей сайтов
  • Серверы каталогов на всех сайтах
  • Физические сетевые подключения
  • Местонахождения межсетевых экранов

После нанесения на схему этих объектов выполняется планирование размещения серверов Exchange. При выборе местоположения серверов необходимо учесть следующие сведения:

  • Для выполнения поиска Active Directory транспортный сервер-концентратор должен иметь возможность взаимодействовать напрямую с сервером глобального каталога.
  • Серверы почтовых ящиков должны находиться на том же сайте, что и транспортный сервер-концентратор. Для обеспечения сбалансированности нагрузки и отказоустойчивости рекомендуется на каждом сайте Active Directory развертывать несколько транспортных серверов-концентраторов.
  • Серверы единой системы обмена сообщениями отправляют сообщения на транспортный сервер-концентратор для их транспортировки на сервер почтовых ящиков. Сервер единой системы обмена сообщениями может располагаться на концентраторе или рядом со шлюзом IP/VoIP или УАТС, работающей по протоколу IP. Транспортный сервер-концентратор, являющийся членом того же сайта, что и сервер единой системы обмена сообщениями, получает сообщения для транспортировки и маршрутизирует эти сообщения в рамках организации на транспортные серверы-концентраторы и серверы почтовых ящиков.
  • Серверы клиентского доступа обеспечивают точку подключения к организации Exchange для пользователей, получающих доступ к Exchange в удаленном режиме. Сервер клиентского доступа должен быть развернут на каждом сайте, содержащем серверы почтовых ящиков.

После планирования размещения сервера Exchange 2010 определяются области, в которых можно изменить топологию сайтов Active Directory для улучшения потока связи.

Заключение

Надеюсь, не очень утомил вас таким большим количеством букв и отсутствием картинок J

Те, кому нужно будет более глубоко вникнуть в материал, предлагаю ознакомиться с соответствующими статьями в библиотеке TechNet`a:

26 комментариев:

Баф комментирует...

Объясните, откуда у вас столько времени на столько полезных статей для нас, простых смертных? :)

Алексей Богомолов (Alexx) комментирует...

Баф, ничего сверхестественного, просто к началу лета решил наконец-то дописать все черновики. Так чтобы летом можно было отдохнуть :)

Дмитрий комментирует...

Доброго времени суток!

Хорошая статья !

Не могли бы вы мне помочь, уже перелопатил все чо можно, с виндой у меня это первый опыт
Недавно начальство поставило задачу развернуть Exchange 2010 в режиме хостинга, и ПЛАВНО перехать, на новую почтовую инфраструктуру. Все подняли все работает. Но старый почтовый сервак Exim, с него как то надо всех перехать на Exchange, мы решили сделать это так, создали на exchange для всех почтовые ящики и настроили на Exime копию всей входящей почты отправлять на такой же почтовый адрес только в эксченджь тоесть для айпишника эксченджя мы mx запись не добовляли,все вроде работает за одно решили проблему со спамом. Но когда с exchange отправляеш письмо в рамках нашей организации оно естественно туда не доходит.

Пробовал следующие

добавил новый коннектор отправки типо все сообщения на …@sa.ug отпарвлять в roga.i.coputa.com но не помогло он вроде создался тока не работает

дальше я узнал что можно сделать перерегистрацию писем

New-AddressRewriteEntry -Name «To INSIDEORG» -InternalAddress *@sa.ug -ExternalAddress roga.i.coputa.com

но это то же не помогло как я узнал позже оно могло работать тока с Edge

Может сталкивались с таким, по сути надо всю почту которая идет на свой домен отправлять на определенный ip в Exim, она все равно вернется в exchange.
Хоть в какую сторону читать а то я уже хз шо делать с этим плавным перездом))
Заранее пасибо!)

Алексей Богомолов (Alexx) комментирует...

Попробуйте использовать транспортные правила. Что-то типа "Когда в поле То: домен ххх.ххх - отправлять скрытую копию туда-то".

Анонимный комментирует...

Алексей, например, топология сайтов А,В,С,D такова, что сайты связаны в топологии "кольцо" (сайт А связан с сайтом В; сайт В связан с сайтом С ... сайт D связан с сайтом А).

Сообщение из сайта А должно быть доставлено на сайт С. Исходя из топологии может быть два маршрута письма А->В->С и А->D->C, допустим, исходя из стоимости маршрутов был выбран А->В->С.

Почему письмо пойдёт именно по этому маршруту?Если бы хаб-сервер из сайте А отправил письмо на хаб сайта В, а оттуда на хаб сайта С то было бы понятно. Но сервера из сайтов А и С устанавливают соединение напрямую...

Алексей Богомолов (Alexx) комментирует...

Хабы всегда стремятся напрямую соединиться с конечной точкой доставки. Но здесь могут быть исключения:
1. На пути оптимального по стоимости маршрута есть HUB-site (http://technet.microsoft.com/en-us/library/bb232079.aspx). Тогда письмо будет доставлено на него, а потом он уже сам его отправит в конечную точку.
2. Напрямую соединиться не получается. В этом случае выполняется попытка переслать письмо через пре-дпоследний сайт по пути оптимального маршрута, потом - через пред-пред-последний и так далее. Т.е. происходит откат назад от точки назначения и попытка отправить письмо.

Анонимный комментирует...

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

Алексей Богомолов (Alexx) комментирует...

Можно и так наверно выразиться... но точнее будет так, что маршрут строиться в любом случае, но промежуточные сайты используются для передачи сообщений только если нет возможности установить прямое соединение, либо на пути маршрута есть HUB-site.

Анонимный комментирует...

спс

Alex F комментирует...

Алексей, подскажите пожалуйста, есть организация, она имеет несколько сайтов AD, домен един для всех сайтов, поддомены не используются. В центральном сайте развернут Exchange 2010 + Edge, если поставить в каждый филиальный сайт AD по exchenge серверу с ролями mailbox, hubtransport и cas, каким образом будет осуществляться доступ к базам данных писем? Как будут распределяться внешние доступы к OWA?

Например создаются ящики для всех учеток на всех серверах exchange. Пользователь заходить в outlook в сайте А и пишет письма. База его заполняется на сервере echange расположенном в этом же сайте А. После этого пользователь едет в сайт Б и подключает там себе outlook, он ведь по логике должен начать обл уживаться на местном сервере exchange и соответственно база почтовых ящиков будет местная. Будут ли там его письма которые находятся на сервере echange в сайте А? Осуществляется ли какая-то согласаванность баз данных между сайтовыми exchange?

На счет OWA. На всех CAS серверах во всех сайтах настроено одно и тоже внешнее имя, но во внешней зоне DNS прописан ip центрального сайта и следовательно при подключении трафик будет направлен на центральный CAS или все же в зависимости от учетной записи и принадлежности ее к определенному сайту он будет попадать на нужный именно ему CAS сервер расположенный в нужном сайте AD? И все это дело будет происходить через центральный CAS? В общем меня интересуют тонкости развертывания Exchange в многосайтовой AD. Если сможете, ответьте пожалуйста.

Алексей Богомолов (Alexx) комментирует...

Для MAPI доступа у каждой базы есть параметр RPC Client Access Server, так вот именно к этому CAS серверу и подключаются все пользователи этой базы по MAPI в не зависимости от их физического расположения.
Что касается веб сервисов Outlook Anywhere, OWA, Active Sync, то тут тоже у каждого сервиса настраиваются Internal и External URL адреса, к которым и подключаются клиенты. Т.е. куда URL указывает, туда и подключается клиент.
По хорошему, должен быть один Internet-facing сайт, в котором на CAS серверах для веб-служб указан External URL (на всех остальных сайтах это поле должно быть пустым), к нему и будут подключаться все пользователи по HTTPS, после чего этот CAS будет проксировать запросы на CAS в сайте, где лежит пользовательская база.

Alex F комментирует...

Спасибо, Алексей, теперь все стало гораздо понятнее. Тут как я вижу может быть только одна проблема, если пропадет VPN между сайтами и физически не удастся спроксировать на серверы в сайтах клиентов.

Алексей Богомолов (Alexx) комментирует...

тогда сообщения просто останутся в очередях и будут доставлены как только связь восстановится.

rukus комментирует...

К сожалению наблюдается обратное, после восстановления VPN туннеля, письма так и остаются висеть в очереди, до перезагрузки службы Transport. Алексей! не приходилось ли сталкиваться с чем то подобным? VPN организован на IPSec.

Алексей Богомолов (Alexx) комментирует...

как долго они там висят? вообще, транспорт делает Retry сам через несколько минут (можно попробовать сделать руками Retry)

rukus комментирует...

Retry сделать не представляется возможным, т.к. статус одного из сообщений Active. Можно только заморозить отправку(Suspend). А висеть они могут до наступления Expiration Time конкретного сообщения. Ну или либо до перезагрузки службы, как я уже писал ранее.

Алексей Богомолов (Alexx) комментирует...

а если suspend, потом Retry, то поедет письмо?

rukus комментирует...

после Suspend можно сделать только Resume. Письмо снова переходит в Active и повисает. Варианта Retry даже нет. Добавлю еще то, что таким образом подвисают письма только в одном направлении(остальные письма благополучно уходят) для которого настроен Коннектор на Эдже через VPN туннель. И не всегда. Я так понимаю, это происходит после того как падает туннель.

Алексей Богомолов (Alexx) комментирует...

Попробуйте поднять уровень логирования для транспорта (Set-EventLogLevel) и почитайте Application лог после этого, возможно что-то интересное появится по данной проблеме.

Сергей Колногоров комментирует...

Добрый день, а подскажите как настроить именно на Edge сервере, чтобы отправлять на определенный домен во вне на определенный ip.
Просто через коннектор, если делать, то будет отправлять сам Exchange напрямую, а хотелось бы чтобы через Edge.

Алексей Богомолов (Alexx) комментирует...

Вы на Send коннекторе настраиваете нужный Smart-host, а на вкладке Source Server указываете Edge. В результате письма будут проходить именно через Edge.

Сергей Колногоров комментирует...

А у меня там мой сервер задан в Source Server, его удалить и Edge добавить?

Алексей Богомолов (Alexx) комментирует...

Да, именно так.

Сергей Колногоров комментирует...

Смотрите сделал. Но почта идет через edge но, почему-то отправляется не по ip, который я указал, в коннекторе,а через интернет. Как его заставить отправлять имено по ip в коннекторе.

Сергей Колногоров комментирует...

у меня такое ощущение, что edge использует днс для отправки, а не коннектор, прописал в хостах домен не помогло

Сергей Колногоров комментирует...

А можно ли как-то создать коннектор на edge

Отправить комментарий