Изменения в процессе маршрутизации обеспечивают более эффективную доставку сообщений
С выходом Microsoft Exchange Server 2007 в технологиях Exchange произошли значительные изменения. Большинство из них широко известны, в том числе переход на 64-разрядные аппаратные средства и применение новой среды подготовки сценариев в качестве оболочки управления Exchange (на основе Windows Powershell). Однако есть и другие изменения, которым уделялось меньше внимания, потому что они не затрагивают каждую почтовую организацию Exchange. В частности, это касается использования групп маршрутизации в Exchange 2007 — они больше не применяются. Рассмотрим изменения в маршрутизации Exchange 2007 и те меры, которые необходимо принять для подготовки к развертыванию Exchange 2007 со множеством групп маршрутизации.
Вне сайта
С выпуском Windows 2000 компания Microsoft представила ряд инструментов для сегментированных сетей: сайты Active Directory (AD), соединения сайтов и мосты соединений сайтов. Эти объекты обеспечивают способы ввода информации о базовой сети в топологию AD. В Windows такая информация используется при выполнении различных задач. Например, при начальной загрузке компьютера могут генерироваться запросы DNS, чтобы определить, какие контроллеры домена (DC) находятся в том же сайте, так как их уровень готовности и скорость должны быть выше, чем у DC в удаленных сайтах.
Сайт — набор взаимосвязанных IP-подсетей. Сайты отличаются от доменов; домен может охватывать несколько сайтов, а сайт может содержать несколько доменов. Однако структура модели сайта Windows такова, что каждый компьютер (сервер или клиент) должен быть членом только одного сайта. При организации AD в новом лесу формируется новый сайт с именем Default-First-Site, и в нем находятся все контроллеры домена, если не создавать вручную новых сайтов. При создании новых сайтов компьютеры распределяются по нужным сайтам в соответствии с их IP-адресами.
Соединения сайтов — сетевые структуры, соединяющие независимые сайты. Соединениям сайтов назначается стоимость; на основе этой стоимости Windows формирует путь с минимальной стоимостью для конкретных типов сетевых соединений. Например, Windows использует набор соединений сайтов, определенных администратором, чтобы найти наиболее эффективный путь репликации в AD. Для данной статьи не имеют значения особенности базовой сетевой реализации соединений сайтов; достаточно того, что соединение между сайтами существует.
Определения сайтов и их соединений упорядочиваются службой Windows Knowledge Consistency Checker (KCC). Не следует путать ее со службой KCC Exchange Server 5.5 и с процессом с тем же названием в Exchange Server 2003 и Exchange 2000 Server Site Replication Service (SRS). Windows KCC обеспечивает точность информации о распределении контроллеров домена по сайтам. Если сведения о местонахождении отличаются от действительной сетевой топологии, в дальнейшем могут возникнуть проблемы с репликацией.
Для добавления новых сайтов и соединений сайтов используется консоль Active Directory Sites And Services, показанная на экране. Сначала указывается сайт, затем определяются соединения, представляющие базовые сетевые соединения.
Изменения в маршрутизации сообщений
В Exchange 2003 и Exchange 2000 можно задать несколько групп маршрутизации в одной организации Exchange. У каждой группы маршрутизации есть один компьютер, действующий в качестве ведущего в группе, и один или несколько членов группы. Отдельные серверы внутри группы маршрутизации ведут собственную таблицу состояния соединений: набор векторов, которые указывают конечную точку, стоимость и состояние соединения. Для просмотра содержимого таблицы состояния соединений используется инструмент WinRoute, который можно загрузить с Web-узла Microsoft (http://www.microsoft.com/downloads/details.aspx?familyid=c5a8afbf-a4da-45e0-adea-6d44eb6c257b).
Впрочем, достаточно знать, что отдельные серверы обновляют локальные таблицы состояния соединений каждый раз, когда они замечают изменения в состоянии соединения. Когда происходит обновление, сервер передает информацию об обновленном соединении ведущему группы маршрутизации, который в свою очередь рассылает сведения другим серверам группы.
Благодаря такой архитектуре отдельные серверы получают гибкий способ найти доступные соединения, но в крупных сетях возникают проблемы масштабируемости. Кроме того, чрезвычайно трудно выявить некорректные или искаженные записи из всех таблиц состояния соединений в организации Exchange; для этого необходимо отключить механизм маршрутизации на каждом сервере Exchange в организации, и они должны оставаться отключенными, пока не будет отключен механизм последнего сервера. После этого можно перезапустить механизм маршрутизации и предоставить серверам возможность воссоздать локальные копии карты маршрутизации.
Кроме того, потребуется время, пока изменения в таблице состояния соединений распространятся по всей организации; изменения могут произойти быстрее, чем о них успеют узнать все серверы в сети. Сложность увеличивается из-за того, что группы должны быть привязаны к коннекторам групп маршрутизации Routing Group Connector (RGC), и каждый коннектор должен указывать по крайней мере один сервер-мост с каждой стороны соединения. Коннекторы RGC нельзя назвать очень полезными для тех вариантов маршрутизации, когда существует лишь один путь из данной группы маршрутизации.
Подобно Exchange 2003 и Exchange 2000, в Exchange 2007 в качестве основного транспортного протокола сообщений используется SMTP. Однако в Exchange 2007 внесены некоторые изменения, чтобы упростить процесс маршрутизации и повысить его надежность. Во-первых, введена серверная роль Hub Transport. Серверы Hub Transport перемещают сообщения между серверами почтовых ящиков и внешним миром; например, если Alice и Bob — два разных сервера почтовых ящиков, то любые почтовые сообщения, посылаемые от Alice к Bob, должны пройти через сервер централизованной обработки Hub Transport. Кроме того, сообщения, поступающие из Internet, должны пройти через сервер Hub Transport, даже если они уже прошли через сервер пограничной обработки Edge Transport. Даже в организации с одним сервером почтовых ящиков необходима по крайней мере одна роль Hub Transport. Но роль Hub Transport может сосуществовать с другими серверными ролями, поэтому можно обойтись без отдельного физического сервера.
Роль Hub Transport — своего рода универсальный мост для сайта, в котором она находится; любой сервер Hub Transport в любом сайте может связаться с любым другим сервером Hub Transport в организации. Серверы почтовых ящиков всегда будут пытаться сначала направить исходящие почтовые сообщения на сервер Hub Transport в том же сайте, а сервер Hub Transport должен принять почтовые сообщения для доставки в серверы почтовых ящиков, расположенные с ним в одном сайте. Не нужно принимать никаких специальных мер, чтобы запустить этот процесс. Если сервер Hub Transport в локальном сайте сервера почтовых ящиков неработоспособен, то сервер почтовых ящиков попытается найти ближайший сервер Hub Transport в соответствии с топологией сайта AD.
Во-вторых, компания Microsoft полностью устранила концепцию групп маршрутизации. По умолчанию Exchange 2007 по-прежнему располагает единственной группой маршрутизации для сосуществования с Exchange 2003 и Exchange 2000. Ее имя — DWBGZMFD01QNBJR (EXCHANGE12ROCKS со смещением по алфавиту на один символ влево). Все добавляемые серверы Exchange 2007 вводятся в эту группу маршрутизации; официально одобренного способа поместить их в унаследованную группу маршрутизации Exchange 2003 или Exchange 2000 не существует. Если имеется более одной унаследованной группы маршрутизации Exchange, то необходимо приложить некоторые усилия, чтобы обеспечить сосуществование между этими группами и методами маршрутизации Exchange 2007. В ходе установки Exchange 2007 требуется выбрать сервер-мост в первой группе маршрутизации Exchange 2003 или Exchange 2000; это необходимо для того, чтобы программа установки Exchange 2007 могла создать коннектор RGC для связывания группы маршрутизации Exchange 2007 со старыми группами маршрутизации. Можно создать несколько RGC, чтобы управлять процессом маршрутизации более детально. Для оптимальной маршрутизации сообщений компания Microsoft рекомендует сформировать дополнительные RGC из каждой старой группы маршрутизации к группе маршрутизации Exchange 2007. В сущности, последняя превращается в центральный элемент топологии маршрутизации типа «звезда». Благодаря этой топологии уменьшается число ретрансляционных участков при передаче сообщений между различными унаследованными группами маршрутизации.
В Exchange 2007 есть еще несколько изменений, относящихся к сайтам.
- Изменился механизм ссылки на общие папки. В Exchange 2003 и Exchange 2000 используется сложный алгоритм поиска реплики данного клиента почтовых ящиков с минимальной стоимостью. В Exchange 2007 этот алгоритм существенно упрощен: Information Store (IS) составляет список всех обнаруженных баз данных общих папок, упорядоченных по стоимости доступа; стоимость баз данных в текущем сайте — наименьшая, а рейтинг остальных определяется стоимостью межсайтовых соединений.
- Членство серверов единой системы обмена сообщениями Unified Messaging (UM) в сайте используется для поиска оптимального сервера Hub Transport для доставки сообщения в почтовый ящик конкретного пользователя.
- Серверы клиентского доступа используют членство в сайте, чтобы определить, следует ли направить поступивший запрос на другой сервер клиентского доступа. Например, предположим, что почтовый ящик пользователя находится в сайте 1, а сам пользователь подключен к серверу клиентского доступа в сайте 2. Сервер клиентского доступа сайта 2 может обнаружить, что почтовый ящик пользователя находится в сайте 1, и перенаправит запрос на сервер клиентского доступа сайта 1.
Управление потоком сообщений
Сервер Hub Transport должен обработать каждое сообщение, передаваемое между двумя пользователями, даже если эти два пользователя подключены к одному серверу почтовых ящиков. С учетом данного обстоятельства можно проанализировать ряд интересных новшеств маршрутизации сообщений в Exchange 2007. В сущности, есть только два возможных сценария: отправитель и получатель находятся в одном сайте либо они находятся в разных сайтах.
Рассмотрим самый простой вариант: два пользователя одного сервера почтовых ящиков. Сообщение пользователя A передано в IS и оттуда направлено на сервер Hub Transport (который в данном случае, вероятно, находится на том же физическом сервере), тот переправляет его в почтовый ящик пользователя B. В этом процессе информация о сайте не играет очевидной роли, но сервер Hub Transport все же должен запросить в AD данные о сайте, чтобы определить, находится ли почтовый ящик B в том же сайте. Из этого примера видно, что случаи одного сайта и одного сервера, в сущности, одинаковы и обрабатываются аналогично.
Более сложный и интересный случай: отправитель находится в одном сайте, а получатель — в другом. Почтовый клиент отправителя передает сообщение на сервер почтовых ящиков отправителя, который пересылает его на сервер Hub Transport в локальном сайте. Этот сервер Hub Transport пытается найти оптимальный путь для сообщения, сначала просчитывая все возможные маршруты. На основании полученного списка маршрутов предпринимается попытка установить соединение с самой низкой стоимостью непосредственно с сервером Hub Transport целевого сайта. В механизме маршрутизации предпочтение по возможности отдается прямым соединениям, поэтому, если существует два маршрута с одинаковой стоимостью, то будет выбран маршрут с наименьшим числом ретрансляционных участков.
Сайты и соединения сайтов первоначально проектировались для поиска локальных служб, поэтому в Windows нет концепции, привязанной к службам стоимости для сайтов или соединений сайтов: стоимость соединения практически фиксированная. Однако специально для Exchange можно назначить стоимость соединениям сайтов, используя серверную команду Set-AdSiteLink оболочки управления Exchange. Если явно назначить стоимость для Exchange, то Exchange использует ее при расчете стоимости маршрута. Но другие службы Windows (в частности, репликации AD) игнорируют специальную стоимость Exchange.
Стоимость Exchange учитывается в сценариях, когда целевой сервер Hub Transport недоступен напрямую. Такое может случиться по следующим причинам.
- Связь с целевым сайтом прервана. Предположим, есть три сайта, A, B и C, каждый из них подключен к двум другим. Обычно сообщение может пересылаться напрямую из A в C, но, если соединение между A и C нарушено, сервер Hub Transport может передать сообщение из A в C через B.
- Построен центральный сайт, который, в сущности, представляет собой аналог топологии «звезда» в стиле Exchange Server 5.5. Все сообщения передаются из исходного сервера Hub Transport в центральный сайт, а оттуда — в место назначения.
В документации Exchange 2007 содержится четкое определение области применения этой топологии; центральные сайты «должны использоваться только тогда, когда они необходимы в соответствии с топологией сети, например если между сайтами Active Directory расположен брандмауэр, который препятствует прямой передаче сообщений по протоколу SMTP (http://technet.microsoft.com/en-us/library/0f697cee-bcaa-4c69-b80c-7a2afd1817d2.aspx). Чтобы сформировать центральный сайт, необходимо использовать серверную команду Set-AdSite из оболочки управления Exchange.
Сосуществование разных серверов
Когда первый сервер Exchange 2007 вводится в организацию Exchange, программа установки Exchange 2007 просит указать целевой сервер-мост в организации. Этот сервер используется для создания коннектора RGC, поэтому в группе маршрутизации следует выбирать сервер с хорошими соединениями. Все сообщения, пересылаемые между почтовыми ящиками в сервере Exchange 2007 и старых серверах, будут проходить через этот коннектор. Все серверы Exchange 2007 помещаются в группу маршрутизации Exchange 2007, DWBGZMFD01QNBJR; их нельзя поместить куда-либо еще. Это может привести к нежелательной маршрутизации, так как сообщения между Exchange 2007 и унаследованными компонентами Exchange должны пройти через данный коннектор, независимо от физического расположения сервера. Чтобы обойти проблему, компания Microsoft рекомендует создать дополнительные RGC между DWBGZMFD01QNBJR и целевыми группами маршрутизации; для этого требуется использовать новую команду New-RoutingGroupConnector оболочки управления Exchange.
Следует также учесть обновления состояния соединений групп маршрутизации Exchange 2003 и Exchange 2000. Если имеется только один RGC, то обновления состояния соединений не вызовут затруднений. Но при наличии нескольких коннекторов изменения состояния соединений будут распространяться только среди серверов Exchange 2003 и Exchange 2000. Роль Hub Transport в Exchange 2007 не воспринимает обновления состояния соединений и не принимает их от унаследованных серверов, поэтому серверы Hub Transport могут попытаться пересылать сообщения через коннекторы, которые в данный момент не функционируют. Это может привести в лучшем случае к задержкам доставки, а в худшем — к зацикливанию сообщений. Компания Microsoft рекомендует установить параметр реестра SuppressStateChanges (подробное описание дано по адресу http://www.microsoft.com/downloads/details.aspx?familyiD=62fb1297-4c6b-4d84-84cc-060989f2f305), чтобы отключить сообщения об изменении состояния коннектора. После этого Exchange 2003 и Exchange 2000 будут, в сущности, функционировать как Exchange 2007 (использовать только информацию о стоимости маршрута, но не о состоянии маршрута при принятии решений о маршрутизации).
При перемещении почтовых ящиков из Exchange 2003 и Exchange 2000 в Exchange 2007 необходимо ликвидировать старые серверы; по мере их удаления они устраняются из топологии маршрутизации. Однако коннекторы RGC приходится удалять вручную по мере удаления отдельных унаследованных групп маршрутизации, а также удалять коннекторы RGC между псевдогруппами маршрутизации Exchange 2007 и остальной частью организации. Процесс прост, но необходимо тщательно отслеживать поток сообщений, чтобы не задерживать сообщения на сервере и не препятствовать потоку с других серверов, который может зависеть от конкретного коннектора или моста.
Более продуманная система
С появлением Exchange 2007 маршрутизация сообщений заметно меняется. Компания Microsoft добавила серверную роль Hub Transport и полностью отказалась от групп маршрутизации. Благодаря изменениям удалось усовершенствовать систему пересылки сообщений. Однако эффективность потока сообщений зависит от правильной структуры сайта AD. Если администратор не уверен, что топология сайта точно соответствует структуре сети, то необходимо безотлагательно устранить недостатки, чтобы упростить процесс перехода на Exchange 2007.
Поль Робишо (troubleshooter@robichaux.net) — главный инженер компании 3sharp, имеет сертификаты MCSE и звание Exchange MVP. Автор нескольких книг, в том числе The Exchange Server Cookbook (издательство O’Reilly and Associates), и создатель Web-узла http://www.exchangefaq.org
Дополнительная литература
Ресурсы Windows IT Pro
Дополнительные сведения об Exchange Server 2007:
Новые возможности Exchange Server 2007. Windows IT Pro/RE 7, 2006, с. 10.
Начинаем готовиться к Exchange 2007. Windows IT Pro/RE 2, 2007, с. 52.
Ресурсы Microsoft
Message Routing in a Coexistence Environment, http://technet.microsoft.com/en-us/library/f81aab39-ff50-4950-a2f1-25c3f0bb66ec.aspx
How to Set the SuppressStateChanges Registry Value, http://technet.microsoft.com/en-us/library/ 875ae7f8-446d-4786-85d2-719ac7093cf6.aspx
Exchange 2007: учимся у Microsoft
Энн Грабб
Администратор Exchange в компании Microsoft Дерек Ингаллс рассказывает о трудностях и успехах, достигнутых за полтора года работы с Exchange 2007.
Применение передовых технологий — обычная составляющая профессиональной деятельности ИТ-администратора компании Microsoft. Многие администраторы Exchange будут осваивать Exchange Server 2007 постепенно, предоставив первопроходцам самим разбираться в особенностях продукта, но в компании Microsoft развертывание Exchange 2007 для 70 тыс. пользователей идет полным ходом. Активному внедрению предшествовало тестирование в течение полутора лет, в котором участвовали как группа разработчиков продукта, так и ИТ-подразделение, в соответствии с принятой в Microsoft политикой внутреннего развертывания собственных продуктов перед их выпуском в свет. Дерек Ингаллс, генеральный менеджер, и другие сотрудники ИТ-подразделения провели весь 2006 год и значительную часть 2005 года в интенсивном тестировании Exchange 2007 с 5500 почтовыми ящиками на специально выделенном сервере. Ингаллс рассказал о том, как его группа выполняла переход от Exchange Server 2003 к Exchange 2007, и о том, каким образом этот опыт может пригодиться другим ИТ-специалистам.
Какой была общая процедура тестирования Exchange 2007?
Эта модернизация существенно отличалась от прежних переходов. Exchange 2003 для нас был похож на пакет обновления. Мы обновили всю среду за два выходных дня. Но процесс модернизации Exchange 2007 занял много времени. С тех пор как мы построили первый сервер и разместили на нем действующие почтовые ящики, было пройдено немало важных этапов. Как известно, Exchange 2007 выполняет несколько серверных ролей, но не все роли были освоены сразу. Первой вехой стал первый сервер клиентского доступа (Client Access), затем появились производственные почтовые ящики на сервере Mailbox, затем первый пограничный сервер (Edge) и т. д.
Что было самым трудным при переходе на Exchange 2007?
Горячие споры разгорелись вокруг хранения данных. Интенсивность обращений к диску Exchange 2007 ниже, чем у предыдущих версий, поэтому мы использовали более емкие и медленные диски меньшей стоимости. Благодаря мерам, принятым для повышения отказоустойчивости Exchange 2007, таким как непрерывная репликация кластеров (CCR), снижается зависимость от единственного устройства хранения, и можно подумать об использовании менее надежных устройств. При работе с Exchange 2003 мы использовали кластерную сеть SAN, и уровень абсолютной готовности выражался четырьмя девятками. Сбои всегда были связаны с авариями устройств хранения.
Группа разработчиков Exchange всерьез решила уменьшить зависимость пользователей от SAN. Естественно, потребители будут применять с Exchange 2007 различные подсистемы памяти, поэтому от нас потребовали оценить наиболее неожиданные сценарии, например использование DAS или SCSI с последовательным подключением (SAS).
Но разработчики Microsoft не утверждают, что DAS — предпочтительное решение для хранения данных в Exchange 2007. Это просто один из вариантов, не так ли?
Верно. Среди ИТ-специалистов нет единого мнения о замене SAN на менее дорогостоящие диски, так как наши пользователи, как обычно, ожидают высокой отказоустойчивости. Но мы решили увеличить размер почтового ящика с 200 Мбайт до 2 Гбайт, поэтому в целях соответствия законодательным актам и для внедрения решения в своей компании нам пришлось архивировать в 10 раз больше данных, чем при работе с Exchange 2003. Любопытно, что в разгар споров мы лишились массива SAN для 8 тыс. пользователей. Он полностью вышел из строя, и нам пришлось заново устанавливать Exchange и восстанавливать 800 почтовых ящиков по 200 Мбайт каждый. Это было чрезвычайно сложно. И программисты из группы Exchange заявили нам: «При использовании CCR результатом аварии был бы перерыв длительностью две минуты, а не два дня». Они были правы. Это бедствие оказалось полезным, так как помогло нам сделать шаг вперед.
Еще одна проблема — при переходе к почтовым ящикам по 2 Гбайт пользователи лишились PST-файлов. Это решение, похоже, вызвало самое большое сопротивление, с которым нам приходилось сталкиваться. Но когда мы предложили сторонникам PST-файлов отказаться от участия в пилотной программе, они предпочли преимущества почтовых ящиков по 2 Гбайт. С помощью новых функций управления записями можно задавать ограничения и действия для различных папок, в зависимости от категории почты (например, следует ли архивировать или удалять сообщения по истечении определенного времени). Для пользователей почтовый ящик на 2 Гбайт — практически бездонный.
Какие возможности Exchange 2007 оказались наиболее полезными для ИТ-персонала в процессе эксплуатации?
Очень пригодились администраторам усовершенствования Windows PowerShell (или Exchange Management Shell) и расширенные возможности командной строки. Когда мы впервые услышали о Monad (предварительная версия PowerShell), все сотрудники ИТ-подразделения были уверены, что этот новый способ администрирования не принесет ничего, кроме головной боли. Но после того как мы начали работать с PowerShell, оболочка всем очень понравилась.
PowerShell унифицирует выполнение операций и поэтому имеет огромный потенциал для всех потребителей. Полагаю, что со временем возникнет сообщество для обмена сценариями, серверными командами и знаниями, чтобы не изобретать повторно способы перемещения почтовых ящиков или выполнения определенных задач.
Могли бы вы привести пример проблемы, которую проще обнаружить с использованием PowerShell?
Один пример — состояние служб и баз данных. Другой пример: в силу новизны серверная роль Edge доставляла нам немало хлопот. В ходе диагностики неполадок сервера Edge мы обнаружили, что традиционные методы — с использованием Performance Monitor или Queue Viewer через Exchange System Manager (ESM) — менее точны, чем хотелось бы. Однако нам удалось найти ответы с помощью Powershell; мы получили более детальное представление о происходящем на сервере Edge.
Какой совет можно дать ИТ-администраторам в других компаниях, чтобы помочь им преодолеть страх перед Powershell?
Полагаю, что для этого достаточно просто познакомиться с инструментом. Спустя 30 минут работы с Powershell сотрудники нашего ИТ-подразделения поражались мощи и чрезвычайной эффективности инструмента.
Энн Грабб (agrubb@windowsitpro.com) — старший редактор Windows IT Pro, SQL Server Magazine и Exchange & Outlook PRO VIP