Опубликован: 08.12.2008 | Доступ: свободный | Студентов: 544 / 31 | Оценка: 4.55 / 4.64 | Длительность: 15:21:00
Лекция 6:

Поддержка Outlook Web Access

< Лекция 5 || Лекция 6: 12345 || Лекция 7 >

Развертывание OWA

Мы рассмотрим два базовых сценария развертывания: сценарий с одним сервером и сценарий с серверами front-end и back-end.

Сценарий с одним сервером

В сценарии с одним сервером рассматривается только один сервер Exchange. Пользователи подключаются напрямую к IIS на сервере Exchange и осуществляют доступ к своим почтовым ящикам на этом сервере. Для небольших организаций следует использовать данную топологию. Это наиболее простой и понятный подход к применению OWA.

Сценарий с серверами front-end и back-end

В случае с серверами front-end и back-end хотя бы один сервер front-end (FE) содержит протоколы Exchange в наборе серверов IIS. На сервере back-end (BE) работает, по крайней мере, одна база данных Exchange. Серверы FE направляют вызовы клиентов на серверы BE для предоставления доступа к их почтовым ящикам или общим папкам.

Протоколами, используемыми в таком сценарии, являются РОРЗ (Post Office Protocol версии 3), IMAP 4 (Internet Messaging Application Protocol версии 4), NNTP (Network News Transfer Protocol) и HTTP (Hyper Text Transfer Protocol). Для получения детальной информации об этих протоколах обратитесь к гл. 20.

Как корпоративная, так и стандартная версии Exchange 2003 поддерживают сценарий с серверами front-end и back-end. Серверы FE не содержат хранилище почтовых ящиков или общих папок. Front-end-cep-веры направляют клиентские запросы на back-end-серверы, на которых также работает Exchange 2003. Сервер back-end осуществляет поддержку, как минимум, одного хранилища почтовых ящиков или общих папок. Обратите внимание, что можно использовать Exchange 2003 FE для перенаправления на сервер BE Exchange 2000, однако функциональность будет ограничена возможностями Exchange 2000. Если требуется полный набор возможностей, поставляемый с Exchange 2003, необходимо использовать Exchange 2003 с обеих сторон.

Конфигурация back-end/front-end обеспечивает несколько преимуществ.

  • Одно пространство имен. Поскольку имеется возможность использовать такие протоколы, как Network Load Balancing (NLB), не имеет значения, сколько серверов IIS размещается в кластере. Клиентам придется запомнить лишь одно имя и IP-адрес для подключения к своим почтовым ящикам через HTTP.
  • Обработка с разгрузкой.Если принято решение о применении SSL или другого типа шифрования, front-end-серверы будут осуществлять все процедуры шифрования и дешифрования, освободив от этой работы ВЕ-серверы баз данных.
  • Повышенный уровень безопасности.Существует возможность выбрать местонахождение сервера FE: внутри межсетевого экрана, вне межсетевого экрана или внутри сетевого периметра. Серверы FE можно настроить на аутентификацию пользователей перед перенаправлением их запросов на ВЕ-серверы.
  • Масштабируемость. Так как имеется возможность добавления новых серверов в кластер балансировки нагрузки FE, каждый добавляемый сервер представляет собой вспомогательную структуру управления новыми и существующими клиентскими запросов. И поскольку клиентам не нужно знать, на каком сервере BE находятся их почтовые ящики, можно переместить почтовый ящик клиента на новый сервер, и это перемещение пройдет для клиента незаметно. Данная архитектура обладает высоким уровнем масштабируемости и обеспечивает работу миллионов пользователей.

NLB - это сервер, поставляемый с Windows 2003, который динамически распределяет клиентские вызовы служб между несколькими серверами FE. Обратите внимание, что речь идет об уровне клиентских запросов, а не об уровне сеансов клиентов. Сеансы не участвуют в балансировке нагрузки, в отличие от отдельных вызовов клиентов. Балансировка нагрузки достигается посредством виртуализации адресов Media Access Control (MAC) и IP-адресов на каждой карте сетевого интерфейса (NIC) каждого сервера в кластере. Следовательно, каждый вызов при поступлении на серверы имеет такое же имя узла и комбинацию адресов MAC и IP, как и другие вызовы, что облегчает распределение не только нагрузки сеансов, но и нагрузки трафика между серверами.

Дополнительная информация.Чтобы узнать больше о распределении нагрузки в сети, обратитесь к обзору Network Load Balancing Technical Overview, который можно найти в TechNet или библиотеке MSDN Library.

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

Microsoft предоставляет дополнительные инструкции по реализации архитектуры FE/BE. Во-первых, следует разместить в кластере NLB как минимум два сервера для каждого протокола, предлагаемого с использованием данной архитектуры. Каждый сервер FE определяет местонахождение почтового ящика пользователя с помощью пользовательских данных из каталога на сервере Windows 2003.

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

Наконец, не следует разрешать прямой доступ к серверам BE. Это сведет на нет первоочередное создание FE-серверов и вызовет ненужную нагрузку на соответствующие ВЕ-серверы.

Настройка FE-сервера OWA

В Exchange 2003 по умолчанию не требуется дополнительная конфигурация на сервере FE, кроме включения опции Front End Server (Интерфейсный сервер). Эта опция находится в свойствах сервера. После ее включения сервер Exchange может работать как сервер FE.

Если осуществляется поддержка нескольких имен доменов или нескольких деревьев общих папок, создайте дополнительные виртуальные серверы или каталоги. Чтобы создать новый виртуальный сервер, откройте ESM и перейдите к папке протокола HTTP. Дважды щелкните на папке, укажите пункт New (Создать) и выберите HTTP Virtual Server (Виртуальный сервер HTTP). Необходимо присвоить серверу имя, поэтому укажите уникальную комбинацию IP-адреса и номера порта (см. рис. 6.5) и введите данные доступа и аутентификации на вкладке Access (Доступ). После этого будет создан новый виртуальный сервер, и сервер сможет начать свою работу.

Добавление нового виртуального сервера HTTP

Рис. 6.5. Добавление нового виртуального сервера HTTP
Примечание Виртуальный сервер в Exchange и веб-сайт в IIS необходимо запускать по отдельности. Имейте в виду, что при выборе одинакового с виртуальным сервером IP-адреса по умолчанию и указании другого номера порта понадобится ручная настройка номера порта на новом веб-сайте в IIS. Кроме того, сервер FE не может стать сервером обновления получателей (Recipient Update Server) для любых контроллеров домена в организации.

При своем создании новый виртуальный сервер ассоциируется с именем домена по умолчанию в организации Exchange, поэтому его нужно ассоциировать с конкретным именем домена SMTP. Это можно сделать в свойствах виртуального сервера в ESM, как показано на рис. 6.5. Нажмите кнопку Modify (Изменить) и выберите имя домена для данного виртуального сервера. Если не изменить эту связь, пользователи не смогут осуществлять вход на интерфейсный (front-end) сервер, если их адреса электронной почты не будут принадлежать домену, принятому по умолчанию. Если имя домена, которое нужно присвоить виртуальному серверу, отсутствует в списке, добавьте его как дополнительный SMTP-домен в организации Exchange в политиках получателей (Recipient Policies).

Для содержания нескольких доменных имен посредством использования виртуальных каталогов вместо новых виртуальных серверов добавьте виртуальный каталог под виртуальным сервером Exchange HTTP по умолчанию, щелкнув правой кнопкой мыши на Exchange Virtual Server, указав пункт New (Создать) и выбрав Virtual Directory (Виртуальный каталог). Чтобы выбрать доменное имя для обслуживания виртуальным каталогом, нажмите кнопку Modify (Изменить) (см. рис. 6.6). Этот виртуальный каталог будет обслуживать клиентские запросы для электронной почты или доступа к общим папкам.

 Настройка виртуального каталога и присвоение его к доменному имени для виртуального сервера HTTP

Рис. 6.6. Настройка виртуального каталога и присвоение его к доменному имени для виртуального сервера HTTP

При необходимости в просмотре или синхронизации электронной почты с помощью клиентов ОМА, возможно, потребуется использование виртуальных каталогов через виртуальные серверы. Если требуется осуществить доступ к электронной почте через порт 80 с использованием одного и того же IP-адреса для каждого доменного имени, то выходом из положения являются виртуальные каталоги. Давайте разберемся, каким образом это реализуется. Допустим, что доменным именем по умолчанию являетсяhttp:// trainsbydave.com, и требуется содержать электронную почту для Networknowledge. При использовании виртуальных каталогов адресом URL для Networknowledge будет http://www.trainsbydave.com/ Networknowledge.

Если доступны дополнительные IP-адреса, то имеет смысл использовать виртуальный сервер для каждого имеющегося дополнительного домена, так как каждый виртуальный сервер получит уникальный IP-адрес, и URL будет базироваться на домене: http://www.networknowledge.com/ exchange или http://www.trainsbydave.com/exchange. Запомнить одно доменное имя в URL проще для пользователей, чем запоминать два различных имени домена.

В отличие от параметров виртуального сервера, здесь появляются две дополнительные опции: Browse (Обзор) и Sync (Синхронизация). Выбор опции Sync (Синхронизация) делает недоступной кнопку Modify (Изменить) и добавляет опцию Outlook Mobile Access (Мобильный доступ из Outlook) для разрешения синхронизации клиентов ОМА. Этот виртуальный каталог наследует присвоение домена SMTP родительского виртуального сервера. Следовательно, если требуется синхронизировать электронную почту с клиентами ОМА для пяти различных доменных имен, необходимо наличие пяти различных виртуальных серверов HTTP, и каждый из них должен быть присвоен отдельному доменному имени SMTP.

Примечание.При настройке дополнительных виртуальных серверов или каталогов на серверах FE необходимо проделать то же самое на серверах BE, чтобы обеспечить правильность функционирования топологии FE/BE. Причиной является то, что адрес, по которому клиентский браузер осуществляет доступ к серверу FE, пересылается FE-сервером на ВЕ-сервер, поэтому ВЕ-серверу должно быть известно о каждом имени, которое клиент может использовать для чтения FE-сервера. Имейте в виду, что при наличии кластеризации ВЕ-серверов необходимо использовать имя группы кластеризации.
< Лекция 5 || Лекция 6: 12345 || Лекция 7 >