Exchange в вопросах и ответах: роли сервера, создание клиентов, балансировка нагрузки и многое другое
Хенрик Вальтер
Использование ролей сервера
Вопрос: Я планирую обновить среду с Microsoft Exchange 2007 до Exchange 2010. При реализации проекта нужно предусмотреть избыточность на всех уровнях. Поскольку в нашей организации примерно 3 тыс. пользователей, я планирую с самого начала установить Exchange на двух машинах. На каждом будут установлены роли «транспортный сервер-концентратор», «сервер клиентского доступа» и «сервер почтовых ящиков». Оба сервера также будут членами группы DAG (Database Availability Group — группы доступности базы данных), чтобы серверы обновляли в рамках репликации свои базы данных.
Опыт использования уже имеющейся среды Exchange подсказывает мне, что если роли «транспортный сервер-концентратор» и «сервер почтовых ящиков» разместить на одной машине, Служба передачи почты Microsoft Exchange (Microsoft Exchange Mail Submission) всегда предпочитает локальный сервер-концентратор и не использует другие аналогичные серверы в сайте Active Directory по методу циклического обслуживания, как это делают другие серверы почтовых ящиков, на которых не установлена роль «транспортный сервер-концентратор».
Если в Exchange 2010 такая же ситуация, у нас проблема. Хранение корзины службы передачи Exchange в группах DAG лишено смысла. Если член группы потерпит сбой и база данных почтовых ящиков перейдет на другой член DAG, сообщения в корзине службы передачи Exchange не удастся отправить повторно.
Ответ: Я понимаю ваше беспокойство. Прежде всего позвольте вас уверить, что команда разработки Exchange учла возможность такой ситуации. В самом начале разработки Exchange 2010 было внесено изменение в проект. Если служба передачи почты Microsoft Exchange обнаруживает, что работает на сервере почтовых ящиков, входящем в группу DAG, она не будет предпочитать локальный сервер-концентратор, а будет распределять нагрузку среди других транспортных серверов-концентраторов в том же сайте Active Directory. Если ей не удастся найти другие серверы, она обратиться к локальному серверу-концентратору.
Разработчики изменили не только поведение службы передачи почты Microsoft Exchange. Они также обновили роль «транспортный сервер-концентратор» так, чтобы сообщение перенаправлялось на другой транспортный сервер-концентратор в сайте Active Directory, если роль «транспортный сервер-концентратор» установлена на сервере, у которого также имеется роль «сервер почтовых ящиков» и который является членом DAG. Цель этих изменений —гарантировать высокую доступность ролей «транспортный сервер-концентратор» и «сервер почтовых ящиков», сосуществующих на сервере, входящем в состав DAG.
Проектирование клиентского доступа
Вопрос: Мы разрабатываем решение на основе Exchange 2010 и должны определиться, сколько массивов серверов клиентского доступа создать. У нас будет два центра данных, расположенных в разных сайтах Active Directory. Надо ли нам создавать в каждом сайте центр данных или имеет смысл в каждом сайте иметь несколько массивов?
Мы также будем использовать группы DAG для защиты базы данных почтовых ящиков и распределять копии всех баз данных между этими двумя сайтами. Нужно ли для перехода или переключения на копию в другом сайте, к которой подключены пользователи, вручную переконфигурировать DNS, чтобы клиенты перенаправлялись на массив серверов клиентского доступа в другом сайте?
Ответ: Вопрос о числе массивов серверов клиентского доступа решается просто — можно создавать не более одного массива на сайт Active Directory. Если все же попытаться создать больше, вы получите сообщение об ошибке, показанное на рис. 1.
.png)
Рис. 1 Сообщение об ошибке, отображаемое при попытке создать второй массив серверов клиентского доступа в сайте Active Directory.
Поскольку получить доступ к базе данных почтовых ящиков можно через любой массив серверов клиентского доступа в среде, нет необходимости в более чем одном массиве. Даже если можно было бы создать больше массивов, реально использовался бы только первый.
Что касается другого вопроса, пока в массиве серверов клиентского доступа в сайте 1 доступен хотя бы один сервер, после переключения или перехода при сбое не нужно перенастраивать DNS, перенаправляя клиентов на массив другого сайта. Доступные серверы клиентского доступа в сайте 1 будут контактировать напрямую с серверами почтовых ящиков (которые хранят активные базы данных пользователей в сайте 1), используя протокол RPC.
Создание клиентов
Вопрос: Не могли бы вы порекомендовать, как «правильно» создавать массив серверов клиентского доступа Exchange 2010 в сайте Active Directory?
Ответ: Я бы посоветовал создавать такой массив до создания в сайте каких-либо баз данных почтовых ящиков или перемещения любых почтовых ящиков на сервер почтовых ящиков Exchange 2010. У баз данных почтовых ящиков в Exchange 2010 есть атрибут, который называется RpcClientAccessServer. Если в момент создания базы данных в сайте Active Directory нет массива серверов клиентского доступа, в атрибут записывается полное доменное имя сервера клиентского доступа Exchange 2010 в сайте Active Directory. Если создать массив серверов клиентского доступа до базы данных почтовых ящиков, в атрибут будет записано полное доменное имя массива серверов клиентского доступа, показанное на рис 2.
.png)
Рис. 2 Значение атрибута RpcClientAccessServer базы данных почтовых ящиков.
Почему я рекомендую делать именно так? Outlook-клиент (версии Outlook 2003, 2007 или 2010) автоматически не среагирует на изменение. Если вы используете Outlook 2007 или 2010, можно инициировать обновление конфигурации, отключив доступ к старой конечной точке RPC или выполнив исправление конфигурации. Но Outlook 2003 не способен менять конечную точку и не поддерживает исправление конфигурации. Это вынуждает вручную изменять конфигурацию путем удаления пользователя, затем его повторного добавления и щелчка кнопки «Проверить имя» (Check name). Это неудобно и задевает конечных пользователей, поэтому настоятельно рекомендую все-таки создавать массив серверов клиентского доступа заранее.
Балансировка нагрузки в массивах серверов клиентского доступа
Вопрос: Мы планируем использовать в своем массиве серверов клиентского доступа аппаратное устройство балансировки нагрузки вместо Windows-службы NLB, поэтому нас интересует, можно ли задать статические порты в новой службе RPC сервера клиентского доступа Exchange 2010. Поставщик устройства балансировки нагрузки, не рекомендует использовать динамические порты. Если можно задать статические порты для этого службы, не могли бы вы порекомендовать, какие?
Ответ: Как и в предыдущих версиях, в Exchange 2010 можно задавать статические порты для службы RPC сервера клиентского доступа, а также для Службы Адресной книги Exchange, потому что Outlook взаимодействует с ними через интерфейс MAPI. Подключение к общим папкам все еще выполняется через сервер почтовых ящиков.
Чтобы задать статический порт для службы RPC на сервере клиентского доступа, на каждом члене массива серверов клиентского доступа сделайте следующее: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC. создайте новый раздел по имени ParametersSystem, в котором создайте параметр типа REG_DWORD по имени «TCP/IP Port». В качестве значения параметра задайте нужный номер порта (см. рис. 3).
Настройка статического порта для службы RPC на сервере клиентского доступаНет никаких особых рекомендаций касательно статических портов RPC кроме того, что надо задействовать неназначенный и неиспользуемый порт в корпоративной сети. В отделе ИТ корпорации Майкрософт выбрали для использования в корпоративной сети TCP/IP-порт 7575. Выбирайте тот, который удобен вам.
Чтобы задать статический порт для службы адресной книги Exchange, откройте в «Блокноте» файл microsoft.exchange.addressbook.service.exe.config, расположенный в папке C:\\Program Files\\Microsoft\\Exchange Server\\V14\\Bin, и замените порт TCP/IP на тот, который нужен вам. Нельзя использовать один TCP/IP-порт для RPC и службы Адресной книги Exchange.
.png)
Рис. 3 Настройка статического порта для службы RPC CA на сервере CAS.
Задав порт, перезапустите службы адресной книги Microsoft Exchange и RPC сервера клиентского доступа. Статический порт для подключения к общим папкам задают так же, как и TCP/IP-порт, используемый службой RPC, — единственное различие в том, что то же нужно сделать на серверах почтовых ящиков Exchange 2010, потому что подключение к общим папкам происходит через службу RPC клиентского доступа на роли «сервер почтовых ящиков». Создав порт для общих папок, нужно перезапустить службу RPC клиентского доступа сервера Microsoft Exchange на каждом сервере почтовых ящиков.
Подключения Outlook
Вопрос: Я слышал, что подключения к службе RPC сервера клиентского доступа или к массиву серверов клиентского доступа поддерживают только Outlook 2007 и 2010. Это правда?
Ответ: В прошлом в документации Exchange 2010 содержалось неверное утверждение, что к службе RPC сервера клиентского доступа или массиву серверов клиентского доступа нельзя подключиться средствами клиента Outlook 2003. Это было ошибкой, попавшей в документацию. Клиенты Outlook 2003 полностью поддерживаются. Надо только не забыть включить шифрование RPC в профиле Outlook или отключить его на серверах клиентского доступа. С точки зрения безопасности Microsoft рекомендует все-таки включать шифрование в профиле Outlook. Это можно сделать средствами групповой политики. Руководство приведено в статье Базы знаний “Outlook connection issues with Exchange 2010 mailboxes because of the RPC encryption requirement.”
Балансировка нагрузки средствами Windows NLB
Вопрос: Нужно ли, чтобы при использовании службы балансировки нагрузки Windows (Windows Network Load Balancing, WNLB) для балансировки трафика Exchange 2010 в массиве серверов клиентского доступа полное доменное имя WNLB совпадало с полным доменным именем массива серверов клиентского доступа?
Ответ: Такого требования нет. Например, при использовании Windows NLB для балансировки трафика массива серверов клиентского доступа можно задать в качестве полного доменного имени WNLB, скажем, casarray01.contoso.com, а массиву серверов клиентского доступа назначить имя outlook.contoso.com. Все будет прекрасно работать при условии, что внутренняя запись DNS, соответствующая массиву серверов клиентского доступа, указывает на виртуальный IP-адрес WNLB.
Хенрик Вальтер (Henrik Walther)* — сертифицированный специалист Microsoft, а также MVP по Exchange 2007 и обладает более чем 15-летним опытом работы в ИТ. Он занимает должность архитектора технологий в Trifork Infrastructure Consulting (компании, находящейся в Дании и обладающей званием Microsoft Gold Certified Partner), а также работает в качестве технического писателя для Biblioso Corp.(находящейся в США компании, специализирующейся в области услуг по управлению документацией и локализации). Ему можно написать по адресу exqa@microsoft.com.*