Примечание редактора: эта статья — отрывок из книги «Microsoft Exchange Server 2010 Best Practices» (авторы — Зигфрид Джеготт и Джоэл Стидлей, издательство «Microsoft Press», 2010 год), публикуется с разрешения издателя.

.

Тщательное планирование пространства имен крайне важно при развертывании роли сервера клиентского доступа. Не менее актуально оно и при развертывании ролей транспортного сервера-концентратора и пограничного транспортного сервера. В этой статье рассматриваются основополагающие принципы, понимание которых поможет, в свою очередь, понять всю важность планирования пространства имен. Официальные справочные материалы компании Microsoft по Exchange 2010 и пространствам имен можно найти по адресу msexchangeteam.com/archive/2009/10/27/452969.aspx.

Сценарии пространства имен

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

  • конфигурация ваших серверов Exchange;
  • каким образом будут создаваться ваши сертификаты и какие имена они будут включать;
  • клиентский доступ (Outlook Any­where — OA, Outlook Web App — OWA, POP3 и IMAP, SMTP).

Если вы располагаете несколькими центрами обработки данных, по которым распределены серверы Exchange 2010, то необходимо принять во внимание следующие базовые рекомендации по планированию пространства имен.

  • Планируйте пространства имен исходя из условия, что оба центра обработки данных могут быть активны. При этом по-прежнему допускается добавочное развертывание. Таким образом будет обеспечена возможность автоматического перехвата управления при отказе или ручного переключения на желаемый центр обработки данных.
  • В зависимости от возможностей ваших клиентов по подключению к сети, каждому центру обработки данных потребуются следующие пространства имен: пространство имен Outlook Web App/OA/Веб-службы Exchange (EWS)/Exchange ActiveSync (EAS), пространство имен POP3/IMAP4, пространство имен клиентского доступа к RPC и пространство имен SMTP.
  • Подумайте и решите, какой именно из центров обработки данных будет поддерживать пространство имен службы автообнаружения.

Прежде чем планировать пространство имен, необходимо определиться с физическим расположением клиентов и серверов и тем, каким образом они подключаются к серверам Exchange. Как правило, пространства имен согласовываются с настройками DNS.

Вы можете выбрать один из вариантов планирования пространства имен:

  • консолидированный центр обработки данных;
  • единое пространство имен в сочетании с прокси-сайтами;
  • единое пространство имен в сочетании с множественными сайтами;
  • региональные пространства имен;
  • множественные леса.

Консолидированный центр обработки данных

Этот сценарий пространства имен — самый простой; он предполагает наличие единого пространства имен, которое используется для доступа к единственному физическому сайту, где размещены все серверы Exchange. Этот сценарий имеет следующие преимущества:

  • необходимо управлять одной или очень незначительным количеством записей DNS;
  • организации Exchange потребуется всего один или несколько сертификатов;
  • все пользователи применяют для доступа к серверу Exchange один и тот же URL.

При реализации этого сценария пространства имен доступ к Интернету для сервера клиентского доступа обеспечивается посредством открытия соответствующих портов брандмауэра или путем развертывания программного брандмауэра, такого, например, как Microsoft Forefront Threat Management Gateway (TMG) в демилитаризованной зоне.

Если вы хотите обеспечить поддержку протоколов POP3/IMAP4, необходимо также подумать над тем, каким образом пользователи будут отправлять сообщения посредством протокола SMTP. Это препятствие можно легко преодолеть, если настроить роль транспортного сервера-концентратора на каждом сервере клиентского доступа. В противном случае придется спланировать пространства имен отдельно и для отправки, и для получения сообщений.

Единое пространство имен в сочетании с прокси-сайтами

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

Данный сценарий имеет следующие преимущества:

  • необходимо управлять одной или очень незначительным количеством записей DNS;
  • организации Exchange потребуется всего один или несколько сертификатов;
  • все пользователи применяют для доступа к серверу Exchange один и тот же URL.

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

Для того чтобы реализовать эту модель пространства имен, необходимо задать параметр ExternalURL на сервере (серверах) клиентского доступа на одном из сайтов и убедиться, что на всех остальных сайтах данный параметр задан как $Null. Такая настройка гарантирует, что этот сервер клиентского доступа не просто будет перенаправлять запросы на целевой сервер клиентского доступа, а станет именно транслировать их. Под перенаправлением мы в данном случае понимаем переадресацию соединения сервером клиентского доступа на целевой сервер клиентского доступа; трансляция же означает, что сервер клиентского доступа сам связывается с целевым сервером клиентского доступа и получает от него данные, которые затем передает адресату.

Единое пространство имен в сочетании с множественными сайтами

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

  • Вариант с прокси-сайтом для сервера клиентского доступа предполагает размещение сервера клиентского доступа в отдельном сайте Active Directory (AD), который служит для трансляции трафика на сайт, где расположен почтовый ящик пользователя. Для того чтобы реализовать эту модель пространства имен, нужно на всех сайтах в качестве параметра ExternalURL всех серверов клиентского доступа задать единое пространство имен.
  • Вариант с интеллектуальным брандмауэром предполагает использование программного брандмауэра, такого, например, как Forefront TMG, который в процессе авторизации клиента принимает решение, на какой именно из сайтов будет перенаправлен трафик, руководствуясь при этом заданными правилами. Для того чтобы построить эту модель пространства имен, нужно на всех сайтах в качестве параметра ExternalURL всех серверов клиентского доступа задать единое пространство имен.

Этот сценарий имеет следующие преимущества:

  • необходимо управлять одной или очень незначительным количеством записей DNS;
  • организации Exchange потребуется всего один или несколько сертификатов;
  • все пользователи применяют для доступа к серверу Exchange один и тот же URL.

Недостаток этой модели заключается в том, что для ее реализации необходимо иметь либо программный брандмауэр, способный корректно перенаправлять трафик на другие физические сайты, такой, например, как Forefront TMG, либо прокси-сайт с размещенным в нем сервером клиентского доступа.

Региональные пространства имен

В этой модели для каждого региона или сайта используется свое пространство имен. Для доступа к своим сообщениям пользователи должны будут задействовать свое региональное пространство имен.

Этот сценарий имеет следующие преимущества:

  • клиентский трафик автоматически оптимизируется на уровне региона или сайта. Например, если вы реализуете пространство имен на уровне города, то все пользователи из этого города будут получать локальный доступ;
  • производительность и доступ пользователей к почтовым ресурсам будут оптимизированы;
  • в случае недоступности регионального пространства имен отказоустойчивость обеспечивается посредством использования другого пространства имен (если сервер почтовых ящиков сайта все еще доступен).

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

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

Множественные леса

В модели множественных лесов для каждого леса используется выделенное пространство имен. Например, если бы компании Contoso и Litware объединились, то для доступа к своим почтовым ящикам пользователям Contoso потребовался бы доступ к mail.contoso.com, а пользователи Litware задействовали бы для этого mail.litware.com. Между этими двумя лесами не работает перенаправление запросов к серверу клиентского доступа посредством прокси, поэтому, если один из лесов недоступен, ни один из его пользователей не сможет получить доступ к своим сообщениям.

В этой модели каждому из реализованных пространств имен понадобится своя точка доступа к Интернету, запись DNS и сертификат. Для каждого отдельного леса рекомендуется использовать модель региональных пространств имен, чтобы повысить качество обслуживания клиентов.

Несвязанное пространство имен

Модель несвязанного пространства имен — это особый сценарий планирования пространства имен. Он вступает в силу, когда основной суффикс DNS контроллеров домена (DC) или рядовых серверов в домене не совпадает с именем DNS вашего домена Active Directory (AD).

Например, несвязанное пространство имен встречается, когда у сервера Exchange, который входит в домен Litware.com, есть основной DNS-суффикс Contoso.com. Про такой компьютер (у которого основной суффикс DNS не совпадает с именем DNS домена) говорят, что он является несвязанным.

В силу разных причин может потребоваться, чтобы эти пространства имен различались. Например, если управлением DNS в компании занимаются как администраторы Active Directory (AD), так и администраторы сетей, может возникнуть потребность в топологии с несвязанным пространством имен.

В сервере Exchange 2010 поддерживаются три сценария развертывания Exchange в домене, имеющем несвязанное пространство имен.

  • Сценарий 1. Основной суффикс DNS контроллера домена не совпадает с именем DNS домена. Компьютеры, которые являются членами домена, могут быть как связанными, так и несвязанными.
  • Сценарий 2. Серверы Exchange в домене Active Directory (AD) являются несвязанными, хотя контроллер домена не является таковым.
  • Сценарий 3. Имя NetBIOS домена контроллера не совпадает с соответствующим именем DNS дочернего домена.

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

В среде с несвязанным пространством имен необходимо настроить следующее:

  • все несвязанные домены должны быть добавлены к атрибуту msds-allowedDNSSuffixes корневого домена;
  • список для поиска суффиксов DNS должен содержать все суффиксы DNS, включая несвязанные суффиксы DNS.

Как уже упоминалось выше, каждый несвязанный домен необходимо задать в атрибуте msdsallowedDNSSuffixes корневого домена. Например, если имеется несвязанное пространство имен contoso.com, которое необходимо добавить к лесу Litware.com, нужно произвести необходимые настройки на уровне домена, воспользовавшись для этого имеющимся в Windows Server 2008 инструментом ADSI Edit, как показано на экране.

 

Конфигурирование несвязанного домена
Экран. Конфигурирование несвязанного домена

Кроме того, следует убедиться, что список поиска DNS-суффиксов содержит все пространства имен DNS, развернутые в пределах организации. Чтобы это сделать, нужно настроить список поиска DNS для каждого компьютера в домене, который является несвязанным. Список пространств имен должен включать не только основной суффикс DNS несвязанного компьютера и имя DNS домена, но и все дополнительные пространства имен для всех тех серверов, с которыми могут взаимодействовать серверы Exchange (таких, например, как сервер мониторинга). Дополнительную информацию о сервере Exchange 2010 и несвязанных пространствах имен можно найти по адресу technet.microsoft.com/en-us/library/bb676377.aspx.

Одноуровневые домены

Одноуровневый домен (SLD) — это, по сути, домен с именем, идентичным имени NetBIOS домена. Оно не содержит суффикса, такого как. com или. org, и состоит из одного слова, например LITWARE или CONTOSO.

До появления AD домен SLD был стандартом в Windows NT, поэтому некоторые компании продолжили использование SLD также и в AD. В Windows Server 2008 R2 вы больше не сможете создавать SLD, поэтому, если будет обнаружена среда, в которой все еще есть SLD, подумайте о миграции на стандартное пространство имен, чтобы избежать возможных проблем в будущем.

Сервер Exchange 2010 все еще поддерживает SLD, однако разработчики Exchange не рекомендуют использовать такую конфигурацию, поскольку это может привести к появлению проблем при работе будущих версий Exchange или приложений сторонних разработчиков. Именно по этой причине стоит перевести свою организацию на стандартный сценарий пространства имен.

Несмежные пространства имен

Несмежное пространство имен (иногда называемое также прерывистым) является пространством имен, в котором лес Active Directory включает в себя множественные доменные деревья, имеющие различные имена. Таким образом, у этого леса отсутствует иерархия. Лес может иметь одно или несколько доменных деревьев, и эти деревья определяются именами DNS. Например, contoso.com может быть доменным деревом в лесу Litware.com.

В Server 2008 R2 можно создать множественные доменные деревья, воспользовавшись для этого расширенным режимом установки в мастере установки доменных служб Active Directory (dcpromo.exe). Если у вас есть сходные имена деревьев (litware.com и litware.de), убедитесь, что для соответствующих доменов заданы различные имена NetBIOS домена. Если для обоих деревьев выбрать одинаковые имена NetBIOS, такая конфигурация поддерживаться не будет. Основное правило состоит в том, что для каждого домена по-прежнему должно быть зарегистрировано уникальное традиционное NetBIOS-имя домена.

Если в вашей организации используется сценарий с несмежным пространством имен, DNS должен быть настроен таким образом, чтобы каждый сервер Exchange был в состоянии разрешить все доменные имена в среде. Также в среде Active Directory потребуется сконфигурировать параметр msDS-AllowedDNSSuffixes для всех используемых в лесу пространств имен.

Зигфрид Джеготт (siegfried.jagott@siemens.com) — старший архитектор в компании Siemens в Германии. Имеет статус MCSE, является участником конференций по Windows, обмену сообщениями и совместной работе.

Джоэл Стидлей (joel@mailtask.com) — специалист по технологиям хостинга в компании Microsoft, имеет звание Exchange MVP. Поддерживает сообщество Exchange на сайте exchangeexchange.com