Сведения о планировании пространств имен для Exchange Server 2007
Применимо к: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
Последнее изменение раздела: 2008-11-14
При планировании организации Microsoft Exchange Server 2007 одним из важнейших решений является определение того, как будут использоваться внешние пространства имен. Пространство имен — это логическая структура, которая обычно представлена именем домена в DNS. При определении пространства имен необходимо учесть различные расположения клиентов и серверов, на которых расположены их почтовые ящики. Кроме того, необходимо оценить, как клиенты подключаются к Exchange 2007. Ответы на такие вопросы позволяют определить требуемое количество пространств имен. Пространства имен обычно соответствуют конфигурации DNS. Рекомендуется создать уникальное пространство имен для каждого сайта Active Directory в регионе, в котором есть один или несколько серверов клиентского доступа, доступных из Интернета. В DNS это обычно представлено в виде A-записи, например mail.contoso.com или mail.europe.contoso.com.
Перед развертыванием организации Exchange 2007 необходимо решить, как будет настроена организация и как будут определены внешние пространства имен. Решения относительно пространств имен будут влиять на следующее:
как будет настроена DNS;
какие сертификаты требуются для шифрования связи между компьютерами с Exchange 2007 и клиентскими компьютерами и устройствами;
cпособ подключения клиентов к почтовым ящикам при использовании мобильного Outlook, веб-клиента Outlook и клиентов, работающих по протоколам POP3 и IMAP4.
Этот процесс включает анализ физической и логической структуры сети и выбор топологии организации. В этом разделе приводятся общие сведения о различных топологиях, а также о том, как они влияют на организацию Exchange.
Примечание. |
---|
В этом разделе не рассматривается планирование внутреннего пространства имен, что может потребоваться при реализации балансировки нагрузки в сайте Active Directory. Подробные сведения о следствиях внутренней реализации балансировки нагрузки см. в статье Общие сведения по передаче данных через прокси-соединения и перенаправление. |
Модели организации Exchange Server 2007
В этом разделе рассматриваются указанные ниже топологии.
Модель консолидированного центра обработки данных. Эта модель состоит из одного физического сайта. Все серверы расположены в пределах одного физического сайта, и существует одно пространство имен, например mail.contoso.com.
Одно пространство имен с прокси-сайтами. Эта модель состоит из нескольких физических сайтов. Только один сайт содержит сервер клиентского доступа, доступный из Интернета. Другие физические сайты не доступны через Интернет. Для сайтов в модели существует только одно пространство имен, например mail.contoso.com.
Одно пространство имен с несколькими сайтами. Эта модель состоит из нескольких физических сайтов. Сервер клиентского доступа, доступный из Интернета, может находиться как на одном сайте, так на нескольких сайтах. Для сайтов в модели существует только одно пространство имен, например mail.contoso.com.
Региональные пространства имен. Эта модель состоит из нескольких физических сайтов и нескольких пространств имен. Например, сайт, расположенный в Нью-Йорке, имеет пространство имен mail.usa.contoso.com, сайт, расположенный в Торонто, — mail.canada.contoso.com, а сайт в Лондоне — mail.europe.contoso.com.
Несколько лесов. Эта модель состоит из нескольких лесов и нескольких пространств имен. Организация, применяющая эту модель, может состоять из двух партнерских компания (например, Contoso и ContosoOnline). При этом могут использоваться пространства имен mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.contosoonline.com и mail.europe.contosoonline.com.
Модель консолидированного центра обработки данных
Модель консолидированного центра обработки данных — это наиболее простая модель из рассматриваемых в этом разделе. Она состоит из одного физического сайта. Модель показана на рисунке ниже.
Ниже перечислены преимущества модели консолидированного центра обработки данных.
Требуется управлять меньшим количеством записей DNS, чем в моделях с несколькими пространствами имен.
Требуется управлять меньшим количеством сертификатов. Существует несколько способов шифрования связи между сервером клиентского доступа Exchange и клиентами. Рекомендуется использовать один сертификат, который поддерживает дополнительные имена субъекта. Дополнительные сведения о сертификатах, поддерживающих такие имена субъекта, см. в статье Партнеры по сертификации единой системы связи для Exchange 2007 и Communications Server 2007.
Примечание. Дополнительное имя субъекта — это атрибут цифрового сертификата, который позволяет администратору сайта настроить один сертификат, в котором указаны все пространства имен, требующие сертификата сервера. Примечание. Для управления сертификатами в этой модели можно также использовать групповой сертификат, несколько сертификатов и настройку SRV-записей. Дополнительные сведения об этих методах см. в статье White Paper: Exchange 2007 Autodiscover Service (на английском языке). Пользователям не требуется определять, какое пространство имен необходимо использовать. Все пользователи применяют одно и то же пространство имен и URL-адрес для доступа к Microsoft Exchange.
У модели консолидированного центра обработки данных также есть несколько недостатков, некоторые из которых перечислены ниже.
Модель не поддерживает несколько центров обработки данных.
Если интернет-связь с регионами медленная из-за низкой пропускной способности, значительных задержек или высокой загрузки, пользователи в регионах столкнутся с низкой производительностью.
Одно пространство имен с прокси-сайтами
Эта модель состоит из нескольких физических сайтов, которые используют одно пространство имен. На одном из сайтов, расположенном за ISA Server или другим брандмауэром, находится один или несколько серверов клиентского доступа, доступных из Интернета. На других сайтах нет серверов клиентского доступа, доступных из Интернета.
Важно! |
---|
Установка сервера клиентского доступа в демилитаризованной зоне не поддерживается. |
Модель показана на рисунке ниже.
Внимание! |
---|
Если все сайты подключены к Интернету, использовать эту модель не рекомендуется. Если в топологии есть несколько сайтов Active Directory с подключением к Интернету, которые не находятся в непосредственной близости, рекомендуется использовать модель регионального пространства имен. |
Ниже описаны преимущества модели.
Требуется управлять меньшим количеством записей DNS, чем в топологиях с несколькими пространствами имен. Это снижает сложность работы.
Требуется управлять меньшим количеством сертификатов. Связь между сервером клиентского доступа и клиентами можно шифровать с помощью одного сертификата, который поддерживает дополнительные имена субъекта.
Пользователям не требуется определять, какое пространство имен необходимо использовать. Все пользователи применяют одно и то же пространство имен и URL-адрес для доступа к Microsoft Exchange.
Развертывание одного пространства имен с прокси-сайтами имеет несколько недостатков, некоторые из которых перечислены ниже.
Большое количество пользователей будут получать доступ к серверу почтовых ящиков через передачу. Если пользователь подключается к серверу клиентского доступа, который не находится на том же физическом сайте, что и его сервер почтовых ящиков, запрос будет передан на сервер клиентского доступа в том же физическом сайте, что и сервер почтовых ящиков. Из-за дополнительной передачи возрастет стоимость связи глобальной сети, а производительность снизится. Влияние на производительность зависит от расстояния между двумя физическими центрами обработки данных и количества прокси-подключений.
Доступ к библиотекам Windows SharePoint Services и общим папкам Windows невозможен при подключении пользователей к серверу клиентского доступа, который не находится на том же физическом сайте, что и их сервер почтовых ящиков. Сбой происходит из-за того, что для доступа к библиотекам Windows SharePoint Services и общим папкам требуется имя пользователя и пароль. В сценарии с использованием прокси связь с библиотеками Windows SharePoint Services и общими папками Windows выполняется через системную учетную запись сервера клиентского доступа. Этой учетной записи недоступны имя и пароль пользователя.
Клиенты, использующие протоколы POP3 и IMAP4, не смогут подключаться к своим почтовым ящикам, если сервер клиентского доступа, к которому осуществляется подключение, находится не в одном сайте с сервером почтовых ящиков. Подключения POP3 и IMAP4 через прокси между сайтами при этом невозможны.
Важно! На каждом из серверов клиентского доступа в сайте, к которому осуществляется подключение через прокси, необходимо настроить целевые виртуальные каталоги для использования встроенной проверки подлинности Windows.
Одно пространство имен с несколькими сайтами
Эта модель состоит из нескольких физических сайтов, которые используют одно пространство имен. Для данной модели возможны два варианта развертывания. Можно использовать сервер ISA Server перед одним или несколькими сайтами или прокси-сайт сервера клиентского доступа. За каждым из сайтов может находиться один или несколько серверов, доступных из Интернета. Для этой модели также требуется решение для балансировки нагрузки, которое равномерно распределяет входящий трафик между сайтами, доступными из Интернета.
Важно! |
---|
Установка сервера клиентского доступа в демилитаризованной зоне не поддерживается. |
Развертывание с сервером ISA Server
На приведенном ниже рисунке показано развертывание этой модели за сервером ISA Server или другим брандмауэром.
В конфигурации, показанной на рисунке, сервер ISA Server выполняет предварительную проверку подлинности подключения, чтобы определить членство клиента в группах. После этого трафик перенаправляется на нужный сайт на основе настроенных правил публикации.
Ниже описаны преимущества модели.
Требуется управлять меньшим количеством записей DNS, чем в моделях с несколькими пространствами имен. Это снижает сложность работы.
Требуется управлять меньшим количеством сертификатов. Связь между сервером клиентского доступа и клиентами можно шифровать с помощью одного сертификата, который поддерживает дополнительные имена субъекта. Сервер ISA Server можно настроить для использования внешнего доверенного сертификата от надежного поставщика. Безопасность трафика между сервером ISA Server и серверами клиентского доступа можно обеспечить с помощью внутреннего сертификата.
Пользователям не требуется определять, какое пространство имен необходимо использовать. Все пользователи применяют для доступа к Microsoft Exchange одно и то же пространство имен и URL-адрес.
Почтовые ящики можно переносить между сайтами без изменения внешних пространств имен. Это обеспечивает гибкость для администраторов, которым необходимо сбалансировать распределение трафика между сайтами без изменения конфигурации клиентов.
При необходимости на более позднем этапе можно добавить региональное пространство имен. Эту же модель можно воспроизвести в другом месте с использованием другого внешнего URL-адреса.
Проверку на основе форм сервера ISA Server 2006 можно настроить в соответствии со специфическими требованиями организации.
Ниже указаны некоторые из недостатков реализации этой модели.
Скорее всего, повысится степень использования глобальной сети. Размер увеличения зависит от физического расположения сервера ISA Server.
ISA Server необходимо развернуть и настроить правильно.
Чтобы обеспечить перенапрвление трафика нужному сайту, необходимо управлять членством в группах. По умолчанию администраторы-получатели не могут создавать группы безопасности, поэтому делегирование Active Directory необходимо настроить так, чтобы специальные администраторы Exchange могли создавать участников групп и обновлять членство в группах. Использование групп требует дополнительных действий, которые необходимо принимать во внимание при создании или перемещении почтовых ящиков. Во избежание передачи ненужных запросов проверки подлинности через глобальную сеть рекомендуется размещать сервер глобального каталога рядом с сервером ISA Server.
Важно! Не рекомендуется развертывать одно пространство имен и несколько сайтов Active Directory. Если в топологии есть несколько сайтов Active Directory, рекомендуется использовать модель региональных пространств имен. Примечание. Чтобы развернуть одно пространство имен с несколькими сайтами, необходимо удалить значения ExternalURL для виртуальных каталогов на серверах клиентского доступа, доступных из Интернета, чтобы отключить перенаправление и применять передачу.
Развертывание с прокси-сайтом сервера клиентского доступа
Модель показана на рисунке ниже.
В этой модели все клиентские подключения извне направляются к сайту Active Directory C. После этого подключения перенаправляются сервером клиентского доступа из сайта C к сайту, в котором находится почтовый ящик пользователя.
Ниже описаны преимущества этой модели.
Требуется управлять меньшим количеством записей DNS, чем в моделях с несколькими пространствами имен. Это делдает работу более простой.
Требуется управлять меньшим количеством сертификатов. Связь между сервером клиентского доступа и клиентами можно шифровать с помощью одного сертификата, который поддерживает дополнительные имена субъекта. Сервер ISA Server можно настроить для использования внешнего доверенного сертификата от надежного поставщика, а безопасность трафика между сервером ISA Server и серверами клиентского доступа можно обеспечить с помощью внутреннего сертификата.
Пользователям не требуется определять, какое пространство имен необходимо использовать. Все пользователи применяют для доступа к Microsoft Exchange одно и то же пространство имен и URL-адрес. В случае настройки раздельного DNS эту модель также можно использовать для унификации внутреннего пространства имен. Если раздельный DNS не настроен, все запросы внутренних клиентов будут достигать брандмауэра и перенаправляться соответствующим образом.
Почтовые ящики можно переносить между сайтами без изменения пространств имен с точки зрения внешнего пользователя. Это обеспечивает гибкость для администраторов, которым требуется сбалансировать нагрузку между сайтами. Это также полезно на случай чрезвычайных ситуаций, когда всю службу необходимо переместить между сайтами, поскольку изменять конфигурацию клиентов не требуется.
При необходимости на более позднем этапе можно добавить региональное пространство имен. Эту же модель можно воспроизвести в другом месте с использованием другого внешнего URL-адреса.
Ниже приведены недостатки этой модели.
Скорее всего повысится степень использования глобальной сети. Это будет зависеть от физического размещения серверов клиентского доступа в сайте, доступном из Интернета.
Требуется развернуть и настроить дополнительные серверы клиентского доступа.
Все пользователи будут получать доступ к своим почтовым ящикам через прокси. Когда пользователь подключается к серверу клиентского доступа в сайте C, сервер почтовых ящиков не находится в этом же сайте Active Directory. Пользователь будет перенаправлен на сервер клиентского доступа, который находится в одном сайте Active Directory с сервером почтовых ящиков. Вследствие наличия дополнительного прокси производительность будет ниже оптимальной. Изменение производительности зависит от расстояния между двумя физическими сайтами.
Доступ к библиотекам служб Windows SharePoint Services и общим папкам Windows при подключении пользователей к серверу клиентского доступа, который не находится на том же физическом сайте, что и их сервер почтовых ящиков, невозможен. Это связано с тем, что для доступа к библиотекам служб Windows SharePoint Services и общим папкам Windows требуются имя пользователя и пароль. В сценарии с передачей через прокси связь с библиотеками служб Windows SharePoint Services и общими папками Windows выполняется через системную учетную запись Exchange. Этой учетной записи недоступны имя и пароль пользователя.
Клиенты, использующие протоколы POP3 и IMAP4, не смогут подключаться к своим почтовым ящикам, если сервер клиентского доступа, к которому осуществляется подключение, находится не в одном сайте с сервером почтовых ящиков. Подключения POP3 и IMAP4 через прокси между сайтами невозможны.
Важно! Свойству ExternalURL каждого виртуального каталога в сайте, содержащем почтовые ящики пользователей, должно быть присвоено значение $null. Важно! Серверы клиентского доступа не поддерживают несколько уровней прокси. Каждый сайт, в котором находятся почтовые ящики пользователей, должен быть доступен серверам клиентского доступа из специального сайта прокси. Примечание. При использовании нескольких расположений может потребоваться дополнительная настройка сети. Это может включать настройку аппаратных средств распределения нагрузки, нескольких записей DNS и избыточности маршрутов. Физический способ развертывания будет зависеть от топологии сети организации.
Региональные пространства имен
Моделью региональных пространств имен называется модель, в которой для каждого сайта используется свое пространство имен. Модель показана на рисунке ниже.
Ниже описаны преимущества модели.
- Объем передачи будет сокращен, так как большое количество пользователей смогут подключаться к серверу клиентского доступа на том же сайте Active Directory, что и их сервер почтовых ящиков. Это улучшит работу пользователей и производительность. Для пользователей, почтовые ящики которых находятся на сайте без сервера клиентского доступа, доступного из Интернета, будет выполняться передача.
Ниже описаны недостатки модели.
Требуется управлять несколькими записями DNS.
Требуется получать, настраивать и обслуживать несколько сертификатов.
Усложняется управлением безопасностью, так как для каждого сайта, доступного из Интернета, требуется ISA Server или другой брандмауэр.
Каждый пользователь должен подключаться к собственному региональному пространству имен. Это может привести к необходимости обучения и повысить количество обращений в службу поддержки.
Важно! |
---|
Во всех топологиях с несколькими сайтами Active Directory, подключенными к Интернету, рекомендуется применять модель региональных пространств имен. |
Несколько лесов
Эта модель состоит из нескольких лесов и нескольких пространств имен. Организация, применяющая эту модель, может состоять из двух партнерских компания (например, Contoso и ContosoOnline). При этом могут использоваться пространства имен mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.contosoonline.com и mail.europe.contosoonline.com.
Для каждого леса рекомендуется реализовать модель региональных пространств имен для максимального повышения производительности. Для каждого леса потребуется управлять несколькими сертификатами.
Дополнительные сведения
Дополнительные сведения о планировании пространств имен и его влиянии на безопасность Exchange см. в следующих разделах: