Exchange – очередь за ответами: Балансировка нагрузки, пограничный транспорт и прочее

Вопрос: В нашей корпоративной производственной среде развернуто несколько серверов, использующих Microsoft® Office SharePoint® Server. Каждому из этих серверов необходимо передавать исходящие сообщения через транспортные серверы-концентраторы в нашей свежеразвернутой инфраструктуре Exchange Server 2007. Поскольку сервер SharePoint позволяет нам указать полное доменное имя (Fully Qualified Domain Name – FQDN) лишь одного сервера SMTP (Exchange) на странице «Центр администрирования» | «Операции» | «Параметры исходящей электронной почты», как показано на рис. 1, у меня возник вопрос – как можно устранить это слабое звено?

Рис. 1 Параметры исходящей электронной почты на странице центра администрирования SharePoint

Ответ: Это очень хороший вопрос, поскольку столь многие организации обращают основное внимание на высокую доступность и, следовательно, не могут допустить в своих корпоративных производственных средах ни единого слабого звена. Особенно это верно по отношению к службам обмена сообщениями и совместной работы.

Транспортные серверы-концентраторы Exchange 2007 отказоустойчивы по умолчанию. То есть, при наличии более чем одного транспортного сервера-концентратора, развернутого на веб-узле Active Directory®, и в случае недоступности одного из транспортных серверов-концентраторов в этом сайте Active Directory исходный транспортный сервер-концентратор, пытающийся доставить сообщение, перейдет к следующем транспортному серверу-концентратору в этом сайте Active Directory. Это проделывается с помощью механизмов циклического опроса DNS (если первый транспортный сервер-концентратор в списке не отвечает, переходим к следующему).

Так что когда речь заходит о связи между двумя транспортными серверами-концентраторами или между сервером почтового ящика и транспортным сервером-концентратором (то есть внутренней), нам не нужно заботиться о высокой доступности (или балансировке, если на то пошло), поскольку это собственные функции Exchange 2007. Но не забывайте, что в случае установки роли транспортного сервера-концентратора на компьютере, где также установлена роль сервера почтовых ящиков, роль сервера почтовых ящиков всегда будет предпочитать локальный транспортный сервер-концентратор любым другим транспортным серверам-концентраторам в сайте Active Directory (даже если локально установленный транспортный сервер-концентратор недоступен), когда служба отправки почты Microsoft Exchange отправляет сообщения.

Предшествующая информация не особо полезна, если речь идет о серверах SharePoint, но ее важно знать, прежде чем идти далее. Поскольку транспортный сервер-концентратор по умолчанию является отказоустойчивым, балансирующее нагрузку внутриорганизационное сообщение между транспортными серверами-концентраторами в Exchange 2007 с использованием как аппаратных балансировщиков нагрузки, так и функций средств балансировки сетевой нагрузки Windows® (Windows Network Load Balancing – WNLB) не поддерживается.

На самом деле, ранее не существовало и поддержки балансировки входящего трафика SMTP на транспортныt серверs-концентраторs, основанные на исходной версии Exchange 2007. Но с выпуском пакета обновления 1 (SP1) для Exchange 2007 эта ситуация изменилась. При наличии пакета обновления 1 балансировать нагрузку внутриорганизационных сообщений с помощью аппаратных балансировщиков и функций WNLB все еще нельзя (да и зачем это нужно?), но можно балансировать нагрузку входящего трафика SMTP от не относящихся к Exchange источников (таких, как серверы SharePoint) и клиентов Exchange, вроде IMAP или POP, отправляющих исходящие сообщения организации Exchange 2007, используя соединитель получения клиента по умолчанию на транспортном сервере-концентраторе.

Так что для настройки сервера SharePoint на передачу сообщений через организацию Exchange 2007 с пакетом обновления 1 можно просто создать запись DNS в своей службе DNS Active Directory и сделать, чтобы она указывала на аппаратный балансировщик нагрузки, который может затем распределить трафик между несколькими транспортными серверами-концентраторами, или использовать функции WNLB для достижения этой цели. Чтобы использовать последний метод, настройте кластер WNLB с помощью виртуального IP-адреса и полного доменного имени (такого, как mail.contoso.com) и добавьте порты 25 (входящий трафик SMTP с не использующих Exchange серверов) и 587 (входящий SMTP от клиентов Exchange, таких как IMAP и POP) на вкладке правил порта. На Рис. 2 показано, как будет выглядеть вкладка правил порта с такой настройкой. Также стоит убедиться, что обеим правилам выделяется конкретный IP-адрес виртуального кластера NLB, а не выбираются все IP-адреса.

Рис 2. Определение правил порта

После настройки кластера NLB необходимо создать новый соединитель получения, который следует настроить так, чтобы он прослушивал порт 25, и позволить использовать его лишь серверам, которым он необходим для передачи сообщений. Вдобавок, убедитесь, что этот соединитель использует виртуальный IP-адрес кластера NLB, который был создан ранее.

Вопрос: Наша инфраструктура обмена сообщениями основана на Exchange Server 2007. Чтобы сделать наши серверы почтовых ящиков Exchange 2007 избыточными как на уровне оборудования, так и на уровне хранилищ, все они являются кластеризованными серверами, основанными на технологии непрерывной репликации кластера (CCR). Как активный, так и пассивный узел в каждом кластере CCR расположен в том же физическом центре данных. Теперь, когда наши серверы Exchange 2007 обновлены до уровня пакета обновления 1 (SP1), мы хотим воспользоваться доступностью служб и данных путем репликации баз данных почтовых ящиков на серверы почтовых ящиков на втором узле, используя новую технологию резервной непрерывной репликации (SCR), входящую в Exchange 2007 с пакетом обновления 1 (SP1).

Нам известно, что источники SCR могут быть либо автономными серверами почтовых ящиков Exchange 2007 с пакетом обновления 1, либо кластеризованными серверами почтовых ящиков (CMS), основанными на CCR, либо на технологии кластера единственной копии (SCC). Но как насчет целевых серверов SCR?

Ответ: Целевые серверы SCR (также известные как оконечные точки SCR) должны быть либо автономными серверами почтовых ящиков, где локальная непрерывная репликация не включена ни для одной из групп хранения, либо пассивными узлами в отказоустойчивом кластере Windows (ранее известном как кластерный сервер Майкрософт) с установленной ролью сервера почтовых ящиков. Это значит, что возможно сформировать отказоустойчивый кластер, а затем установить роль сервера почтовых ящиков на пассивном узле в этом кластере, но использовать кластеризованный сервер почтовых ящиков как цель SCR нельзя.

Вопрос: Наша организация использует Exchange 2007 как платформу обмена сообщениями. Мы даже решили заменить наше старое решение по борьбе с нежелательной почтой/вирусами в периферийной сети решением, основанным на пограничных транспортных серверах Exchange 2007 с установленным Forefront™ Security для Exchange, чтобы воспользоваться многослойной защитой и безопасностью сообщений . В ближайшем будущем мы планируем развернуть как минимум еще два пограничных транспортных сервера.

Отсюда мой вопрос. Как нам следует подойти к балансировке нагрузки входящих подключений SMTP к нашему решению для санации сообщений на основе пограничного транспортного сервера Exchange 2007, чтобы нагрузка была распределенной и полностью дублирующейся?

Ответ: Если пограничные транспортные серверы в периферийной сети являются выходящими в Интернет серверами SMTP, то можно использовать подход, подобный подходу отдела информационных технологий корпорации Майкрософт. Этот отдел развернул шесть пограничны транспортных серверов (три в Редмонде и три в Кремниевой долине), обрабатывающих более чем 16 миллионов входящих сообщений в день (из которых более чем 13 миллионов отсеивается как нежелательная почта).

Отдел имеет в целом три записи MX для домена Microsoft.com. Это: maila.microsoft.com, mailb.microsoft.com и mailc.microsoft.com (см. рис. 3). Все записи MX были настроены с приоритетом 10, так что прием циклического перебора DNS выбирает одну из них случайно. Вдобавок, с каждой записью MX связаны два IP-адреса (почтовые узлы).

Рис. 3. Записи MX и почтовые узлы Интернета для Microsoft.com

Зачем нужны два IP-адреса на запись MX? Затем, что некоторые агенты передачи сообщений (MTA) всегда выбирают одну и ту же запись MX вне зависимости от числа настроенных в домене записей MX. Для Exchange Server это уже много лет как не является проблемой (со времени Exchange 2000), но увы, некоторые из используемых MTA все еще имеют этот конструктивный недостаток. Таким образом, независимо от MTA, пытающегося доставить сообщение на адрес Microsoft.com, все подключения SMTP распределяются с использованием сочетания циклического перебора DNS и балансировки нагрузки.

Вопрос: Наш домен Active Directory основан на контроллерах домена Windows Server® 2003. В настоящий момент мы планируем перевод этих контроллеров Windows Server 2003 на Windows Server 2008 и нашей среды обмена сообщениями с Exchange 2003 на Exchange Server 2007. Можем ли мы перевести наш домен Active Directory на Windows Server 2008 путем обновления всех серверов, использующих Windows Server 2003, на Windows Server 2008, прежде чем мы переведем среду обмена сообщениями с Exchange Server 2003 на Exchange 2007?

Ответ: Да, Exchange Server 2003 с пакетом обновления 2 полностью поддерживается доменами Active Directory, состоящими целиком из контроллеров доменов Windows Server 2008, так что этот план можно провести в жизнь. Просто помните, что если планируется использовать контроллеры домена только для чтения Windows Server 2008, не следует настраивать службы обновления получателей Exchange (RUS) на использование контроллера домена только для чтения.