Одно из наиболее значительных различий между Microsoft Exchange Server 5.5 и Microsoft Exchange Server 2003 заключается в базовой архитектуре системы Exchange. Топология маршрутизации сообщений в Exchange Server 5.5 базируется на сайтах. Как известно, сайт образуется посредством логической группировки серверов с постоянными высокоскоростными каналами связи. С точки зрения архитектуры каждый сайт определяет собой три различные области: область для однопролетной маршрутизации, административный модуль и иерархию пространства имен в структуре каталогов.
В Microsoft Exchange 2000 и выше эти три области поделены на отдельные элементы. Однопролетная маршрутизация определяется группой маршрутизации, модуль администрирования определяется административной группой, а иерархия пространства имен располагается в службе каталогов Active Directory в форме домена. Такая архитектура дает администраторам более высокую гибкость при администрировании Exchange Server 2003, так как операции по администрированию разделяются по функциям и действиям, а не по географическому месторасположению.
Группы маршрутизации
Каждая группа маршрутизации в организации, использующей Exchange, состоит из набора надежно соединенных друг с другом серверов Exchange, связь между которыми гарантированно является постоянной и полноценной. Чаще всего группы маршрутизации схожи по своему построению с физической топологией сети. Соединения между серверами в группе маршрутизации полностью базируются на протоколе Simple Mail Transfer Protocol (SMTP). Использование протокола SMTP обеспечивает некоторые преимущества над RPC-соединениями, имевшими место в Exchange 5.5. Во-первых, более гибкую схему маршрутизации и администрирования по сравнению с RPC-соединениями, так как SMTP наиболее "терпим" к топологии низкоскоростных каналов связи с высоким уровнем задержек. Эта "терпимость" позволяет в Exchange Server 2003 группировать серверы в одну группу маршрутизации, которую нельзя было разместить в рамках одного сайта в Exchange 5.5. Во-вторых, использование SMTP допускает разделение
между архитектурой маршрутизации и группированием серверов в целях администрирования. В Exchange 5.5 оба эти элемента определялись сайтом, что вынуждало персонал многих организаций сводить область администрирования к границам сайта. В-третьих, SMTP требует меньшей нагрузки и пропускной способности канала, нежели RPC-соединения.
В дополнение к этому Exchange Server 2003 содержит новую систему калькуляции маршрутизации, исключающую проблемы, связанные с таблицей маршрутизации (Gateway Address Routing Table, GWART), заменяя ее информацией о состоянии связи (об этом пойдет речь далее в лекции).
Примечание. SMTP не заменяет агент передачи сообщений (MTA) в Exchange Server 2003. Напротив, MTA был усовершенствован и работает как в системе Exchange 5.5, так и в Exchange 2000. Тем не менее, он теперь используется, главным образом, для соединения с внешними системами X.400.
В объектной иерархии Exchange Server 2003 группы маршрутизации занимают место под группами администрирования (см. рис 3.1). В группе администрирования (с логическим набором связанных с Exchange объектов, таких как серверы, коннекторы и политики, администрирование которых осуществляется в рамках единой группы) можно настраивать серверы таким образом, чтобы одни направляли сообщения напрямую другим серверам, а остальные можно настроить так, чтобы они направляли сообщения на сервер-мост. (Серверы-мосты рассматриваются более подробно далее в лекции.)
Exchange Server 2003 хранит информацию о маршрутизации в разделе определения конфигурации Active Directory. Хотя эта информация становится доступной в организации Exchange посредством репликации, по-прежнему необходимо настраивать коннекторы между серверами, так как коннекторы помогают сформировать топологию маршрутизации в разделе определения конфигурации. С их помощью создаются определенным образом измененные топологии маршрутизации для обеспечения максимальной гибкости.
(рис 3.1) Объектная иерархия, отображающая группы маршрутизации под группами администрированияГруппы маршрутизации и общие папки
Клиент Exchange 2003 использует информацию о маршрутизации в разделе определения конфигурации в Active Directory для нахождения сервера общих папок. По умолчанию пользователи осуществляют попытки подключения к экземпляру общей папки на своем домашнем сервере, а затем на другом сервере в локальной группе маршрутизации. Если клиент пытается подключиться к экземпляру общей папки, расположенному на сервере в удаленной группе маршрутизации, затраты на использование коннекторов определяют порядок групп маршрутизации, на которые направляется клиент. Можно установить флаг на коннекторе обмена сообщениями для запрета направлений на общие папки через связь (см. рис 3.2), что было невозможно при наличии родственности с сайтами в Exchange Server 5.5.
Примечание. Под затратами на использование коннекторов подразумеваются произвольные затраты, указываемые в Routing Group Connector (RGC) для отражения полосы пропускания канала, ассоциированной с коннектором, и количества сообщений, которое должен принимать коннектор. Например, если RGC настроен на канале T1 и коннектор SMTP работает через спутниковый канал, следует присвоить RGC затраты в размере 1, а SMTP-коннектору – в размере 100. При маршрутизации сообщений по возможности в первую очередь будет использоваться коннектор с меньшими затратами.
(рис 3.2) Окно свойств коннектора обмена сообщениями с опцией Do Not Allow Public Folder Referrals (Запретить направления на общие папки)Рассмотрим пример работы данной системы маршрутизации. Предположим, имеются три группы маршрутизации, в каждой из которых есть по два сервера с именами Server1 и Server2. В каждой группе маршрутизации Server1 представляет собой сервер электронной почты, а Server2 – сервер общих папок. Девушка по имени Sally является членом группы маршрутизации A.
Предположим, Sally пытается подключиться к общей папке с именем Memos в своей домашней группе маршрутизации. К сожалению, Server2 в группе маршрутизации A переведен в автономный режим работы в целях обслуживания. В этом случае Sally направляется через RGC на общие папки в группе маршрутизации B и в группе маршрутизации C для осуществления доступа к экземпляру папки Memos. Если затраты на RGC между группой маршрутизации A и группой маршрутизации B равны 10, а затраты на коннектор между группой маршрутизации A и группой маршрутизации C равны 30, Sally сначала будет направлена в группу маршрутизации B, так как ее коннектор подразумевает меньшие затраты.
Теперь предположим, что физическое соединение между группами маршрутизации A и B обслуживается группой техников. Администратор в группе маршрутизации A может отметить опцию Do Not Allow Public Folder Referrals (Запретить направления на общие папки) на коннекторе с группой маршрутизации B, исключив тем самым коннектор из работы при следующей попытке доступа Sally к папке Memos. После восстановления канала связи администратор может отключить эту опцию, снова разрешив направления на общие папки через этот коннектор.
Совет. Еще одной ситуацией, в которой рекомендуется включать опцию Do Not Allow Public Folder Referrals (Запретить направления на общие папки), является отключенное состояние сервера общих папок в удаленном сайте, если известно, что сервер будет отключен в течение длительного времени. Выбор этой опции исключит запросы на общие папки через данный коннектор. Эта опция также используется в том случае, если все экземпляры общих папок расположены в одной группе маршрутизации, и нужно сфокусировать трафик клиента на этой группе маршрутизации. В данном случае для всех RGC, устанавливающих соединение с группами маршрутизации с общими папками, данная опция будет отключена, в то время как для всех остальных RGC она будет включена.
Обзор транспортной архитектуры
Перед обсуждением того, как сообщения направляются внутри одной группы и между группами, следует ознакомиться с основными принципами передачи сообщений внутри сервера Exchange 2000. Зная, каким образом, например, сообщения поступают в исходящую очередь SMTP, можно без особых трудностей составить схему маршрутизации, о которой пойдет речь на нескольких следующих страницах.
Сообщения могут передаваться в Exchange Server 2003 одним из трех способов. Первым является передача через службу SMTP. Примером данного типа обмена сообщениями является электронная почта интернета. Вторым способом является доставка через хранилище, как в случае с сообщением, созданным клиентом Microsoft Outlook (MAPI) или клиентом Outlook Web Access (OWA). Третьим способом является доставка через агент передачи сообщений Message Transfer Agent (MTA). Сообщения поступают через коннектор X.400 из инородной системы электронной почты или через любой коннектор, реализованный с помощью Exchange Development Kit (EDK).
Как видно на рисунке 3.3, сообщения SMTP сначала отправляются в очередь NTFS, так как не все сообщения, поступающие через SMTP, направлены к локальному хранилищу Exchange. После этого сообщения SMTP отправляются в очередь перед категоризацией для дальнейшей обработки.
Сообщения, передаваемые посредством доставки через хранилище или через MTA, направляются драйверу хранилища Exchange. Драйвер хранилища Exchange берет эти сообщения и передает их в очередь перед категоризацией. Очередь перед категоризацией является первым местом, в котором возможно выполнение так называемых приемников событий. Приемники событий представляют собой сценарии обработки сообщения с целью выполнения определенных функций, таких как добавление отказа от прав или запуск антивирусной программы. Затем сообщение передается в систему категоризации сообщений, которая, по сути, представляет собой набор приемников событий, осуществляющих разрешение адресов для создателя сообщения и для его получателя. Кроме этого, система категоризации сообщений получает из Active Directory атрибуты, присущие сообщению, такие как предельный размер исходящих и входящих сообщений создателя или получателя, ограничения доставки,
спецификации пересылки и другие параметры, которые налагают на сообщения некоторые ограничения. Любые имеющиеся ограничения применяются к сообщению. После выполнения этих задач сообщение помещается в очередь после категоризации, позволяющую выполнять дополнительные приемники событий, если таковые установлены.
(рис 3.3) Внутренняя транспортная архитектура Exchange Server 2003После обработки сообщения в очереди после категоризации оно передается в систему маршрутизации, анализирующую адрес пункта назначения в сопоставлении с таблицей структуры и конфигурации домена. Затем система маршрутизации принимает решение о том, направлять ли сообщение в локальное хранилище или создать временную исходящую очередь (также называемую очередью сообщений пункта назначения) для передачи сообщения на другой сервер SMTP.
Очереди сообщений пункта назначения создаются на основе имени домена пункта назначения. Дополнительная система построения очередей может создавать столько очередей пункта назначения, сколько требуется. Из этих очередей служба SMTP считывает сообщение и передает его следующему серверу SMTP. Если сообщение направлено в локальное хранилище, оно располагается в очереди локальной доставки. После этого процесс Store.exe считывает сообщение из очереди и записывает его в локальную базу данных. Затем сообщение ассоциируется с почтовым ящиком пункта назначения, и получатель уведомляется о поступлении новой почты.
, она является управляющим компонентом, работающим в фоновом режиме и обеспечивающим перемещение сообщений через транспортное ядро.
Маршрутизация сообщений внутри одного сервера
Когда Exchange Server 2003 определяет, что получатель сообщения находится на одном сервере с отправителем, происходит доставка сообщения в папку Inbox (Входящие) получателя. Данный процесс (см. рис 3.4) состоит из следующих шагов.
Клиент отправляет сообщение.
Сообщение передается в систему категоризации, анализируется в сопоставлении с таблицей схемы домена, после чего помещается в очередь локальной доставки.
Хранилище информации ассоциирует сообщение с почтовым ящиком получателя.
Маршрутизация сообщений внутри одной группы маршрутизации
При передаче сообщений между серверами в одной и той же группе маршрутизации используется транспортный протокол SMTP. Маршрутизация сообщения между двумя серверами в одной группе маршрутизации (см. рис 3.5) состоит из следующих шагов.
Клиент отправляет сообщение.
Сообщение передается в систему категоризации, применяющую все ограничения, обнаруженные в Active Directory. Затем сообщение передается через очередь после категоризации и далее в систему маршрутизации.
(рис 3.4) Маршрутизация сообщения Exchange Server 2003 в случае, когда отправитель и получатель сообщения располагаются на одном сервере
Система маршрутизации анализирует сообщение в сопоставлении с таблицей схемы имени домена, после чего помещает сообщение в исходящую очередь SMTP для отправки на сервер назначения. Данная очередь создается для сообщения динамически на основе имени домена назначения, которое и становится именем очереди; в данном случае это имя hr.trainsbydave.com (Local Delivery).
Сервер отправки находит каталог почтового ящика получателя в Active Directory, производит поиск DNS записи обмена сообщениями (MX), связанной с сервером назначения, на котором находится почтовый ящик получателя, и после этого создает TCP-соединение с этим сервером через порт 25.
Сообщение передается на сервер назначения.
Сервер назначения принимает сообщение от службы SMTP и помещает его в очередь NTFS. AQE считывает сообщение из очереди и передает сообщение через транспортное ядро.
(рис 3.5) Направление сообщения Exchange Server 2003 получателю, находящемуся на другом сервере
Направление сообщений в другие группы маршрутизации
Сообщения направляются на серверы в других группах маршрутизации через сервер-мост (BHS) с каждой стороны коннектора, если этот сервер в отдельном порядке установлен в коннекторе. С помощью RGC сервер назначения можно настроить на работу в качестве любого сервера в группе маршрутизации назначения. Маршрутизация сообщений на серверы в различных группах маршрутизации (см. рис 3.6) состоит из следующих этапов.
Клиент отправляет сообщение.
Сообщение передается через транспортное ядро, после чего помещается в очередь исходящих сообщений SMTP.
В разделе определения конфигурации Active Directory собирается информация о группе маршрутизации.
Анализируется информация о состоянии связи для определения оптимального маршрута. (Более подробная информация приведена далее в лекции.)
Сообщение передается серверу BHS через порт TCP 25.
Сервер BHS передает сообщение через порт TCP 25 серверу BHS в группе маршрутизации назначения.
Принимающий сервер BHS передает сообщение серверу назначения в своей группе маршрутизации через порт TCP 25.
Сообщение поступает на сервер назначения через службу SMTP и располагается в очереди NTFS.
AQE извлекает сообщение из очереди, после чего сообщение ассоциируется с почтовым ящиком получателя.
(рис 3.6) Маршрутизация сообщения Exchange Server 2003 получателю в другой группе маршрутизации
Направление сообщений в инородные системы электронной почты
Сообщения направляются в другие системы электронной почты через коннектор X.400, если имеется прямое и постоянное соединение. В противном случае сообщения направляются через интернет с использованием протокола SMTP. Маршрутизация сообщений в другую систему электронной почты с использованием SMTP (см. рис 3.7) состоит из следующих этапов.
Клиент отправляет сообщение.
Сообщение располагается в очереди исходящих сообщений SMTP.
Служба SMTP считывает сообщение из очереди и отправляет его через порт TCP 25 на SMTP-сервер назначения.
(рис 3.7) Маршрутизация сообщения Exchange Server 2003 получателю в другой системе электронной почты через протокол SMTPЕсли сообщение направляется в другую систему электронной почты через коннектор X.400, этапы данного процесса, по сути, идентичны маршрутизации через SMTP, за исключением того, что используется коннектор X.400 и отсутствует номер порта.
Топологии группы маршрутизации
Существует несколько способов соединения с группами маршрутизации. Наиболее распространенными топологиями являются топологии типа "ось и спицы" и "паутина". Топология "ось и спицы", как видно из самого названия, содержит центральную группу маршрутизации, с которой соединены все остальные группы маршрутизации (см. рис 3.8). Администрирование топологии "ось и спицы" осуществляется проще, так как в ней приходится создавать и обслуживать сравнительно небольшое число RGC. Одним очень весомым недостатком данной топологии является то, что если в одном месте возникает ошибка, то нет возможности решить текущую задачу альтернативным способом. Если по каким-либо причинам Exchange Server 2003 или физические каналы связи с "осью" выходят из строя, обмен сообщениями между группами маршрутизации полностью прекращается до устранения возникших неполадок.
В топологии "паутина" каждая группа маршрутизации имеет связь RGC с каждой из остальных групп маршрутизации в организации. Данная топология обеспечивает избыточность в случае ошибки соединения или сервера в любой точке; информация о состоянии связи позволяет перенаправить сообщение по другому маршруту. Тем не менее, осуществлять администрирование такой топологии сложнее, так как она требует создания и обслуживания большего числа коннекторов RGC. На рисунке 3.9 показана схема топологии "паутина".
Менее распространенным способом соединения групп маршрутизации является линейная топология (см. рис 3.10). В данной топологии все группы маршрутизации соединяются линейно в логическом порядке. Несмотря на то что эта топология наиболее проста в реализации из-за минимального количества требуемых RGC, в ней очень велика вероятность возникновения неполадок. Например, здесь не обеспечивается избыточности маршрутизации, следовательно, потеря связи между любыми двумя группами маршрутизации означает, что обмен сообщениями будет прерван во всей организации. Во-вторых, передача сообщения из одного конца в другой занимает слишком много времени с точки зрения требований организации. При отсутствии альтернативных маршрутов задержки при обмене сообщениями становятся серьезной проблемой. Данную топологию использовать не рекомендуется, а вместо нее можно использовать либо топологию "ось и спицы",
либо модифицированную топологию "паутина", о которой пойдет речь ниже.
(рис 3.9) Топология "ось и спицы"(рис 3.8) Топология "паутина"
(рис 3.10) Линейная топологияМодифицированная топология "паутина" (см. рис 3.11) предусматривает несколько маршрутов к каждой группе маршрутизации, однако не обеспечивает связь каждой группы маршрутизации с каждой другой группой маршрутизации внутри организации. В большинстве случаев модифицированная топология "паутина" подходит наибольшим образом.
(рис 3.11) Модифицированная топология "паутина"Информация о состоянии связи
Протокол состояния связи представляет собой двоичный протокол, значительно улучшающий маршрутизацию сообщений в Exchange 2003 по сравнению с Exchange 5.5. Маршрутизация сообщений в Exchange 5.5 базируется на таблице маршрутизации GWART, в которой отслеживаются все доступные коннекторы, а также сумма "затрат" на использование этих коннекторов. GWART имеет ограничение, заключающееся в том, что она содержит только информацию об уже происшедшем событии. Она не отслеживает состояние непосредственно в текущий момент времени. Таблица GWART располагается в объекте Site Addressing и вызывается агентом MTA при определении маршрутов доставки сообщений на сервер назначения.
Протокол состояния связи функционирует через порт TCP 691 в группе маршрутизации. В каждой группе маршрутизации один из серверов является главным сервером группы маршрутизации (Routing Group Master, RGM). RGM получает информацию о состоянии связи и сообщает ее серверам в группе маршрутизации, включая сервер BHS. Когда один BHS соединяется с другим BHS, находящимся в другой группе маршрутизации, обмен информацией о состоянии связи осуществляется через порт TCP 25 с использованием протокола SMTP. RGM отслеживает работающие и не работающие серверы и сообщает эту информацию серверам RGM во всех остальных группах маршрутизации.
Алгоритм состояния связи
Алгоритм состояния связи является нововведением в Exchange Server 2003, хотя нечто подобное было разработано очень давно. Впервые об этом алгоритме заговорили в 1959 г., когда Edsger Dijkstra представил разработку протокола Open Shortest Path First (OSPF), который сегодня широко используется маршрутизаторами. Несмотря на то что Exchange Server 2003 при выборе маршрута руководствуется затратами на его использование, не менее значимым фактором в процессе маршрутизации сообщений между группами маршрутизации является информация о состоянии связи.
Алгоритм состояния связи сообщает о состоянии системы обмена сообщениями почти в реальном времени всем серверам в организации. Это обеспечивает следующие преимущества:
каждый сервер Exchange может выбрать оптимальный маршрут перед отправкой сообщения и избежать возможных повреждений канала связи на одном из потенциальных маршрутов;
исключается "пинг-понг" сообщений, так как информация об альтернативных маршрутах сообщается каждому серверу Exchange Server 2003;
исключается зацикливание сообщений.
Принимая во внимание гибкость данного протокола, можно предположить, что грядущие его версии обеспечат взаимодействие с сетевыми маршрутизаторами для достижения еще больших возможностей маршрутизации. Сети, взаимодействие которых построено на этом принципе, обычно называются сетями с направленной маршрутизацией.
Концепции определения состояния связи
Информация о состоянии связи является достаточно важным фактором, если в организации имеется несколько групп маршрутизации с несколькими маршрутами между группами. RGM осуществляет управление информацией о состоянии связи, отправляя и принимая ее от серверов RGM из других групп маршрутизации. RGM не обязательно должен являться тем же сервером, что и BHS, который представляет собой сервер, предназначенный для обмена сообщениями через данный коннектор с другим сервером BHS. Сервер RGM по умолчанию является первым сервером, устанавливаемым в группе маршрутизации. Это обстоятельство можно изменить в ESM, щелкнув правой кнопкой мыши на сервере, не являющемся RGM, и выбрав опцию Set As Master (Сделать главным). Кроме того, можно вручную настроить один и тот же сервер на выполнение обеих ролей.
Сервер RGM обеспечивает наличие на всех серверах в группе маршрутизации информации о состоянии связи, свидетельствующей о доступности коннекторов обмена сообщениями и серверов в других группах. Кроме этого, он обеспечивает наличие в других группах корректной информации о подчиненных ему серверах.
Информация о состоянии связи распространяется между серверами группы с помощью протокола SMTP, а информация о состоянии связи между группами реплицируется от одного RGM к другому через порт TCP 25. Любая рассматриваемая связь находится только в двух состояниях: рабочем ( up ) и нерабочем ( down ). Информация о состоянии связи не содержит какую-либо информацию о соединении, например, находится ли связь в состоянии повторной попытки передачи. Данная информация известна только серверу, участвующему в передаче сообщения.
Примечание. Коннекторы, такие как Lotus cc:Mail Connector, Microsoft Mail Connector и другие коннекторы, реализованные с использованием EDK, всегда отображают свое состояние связи как рабочее, даже если связь в действительности недоступна.
Информация о состоянии связи хранится в памяти, а не на диске. Если сервер RGM отключается или требует перезапуска, он затем должен будет получить всю текущую информацию о состоянии связи от других серверов RGM внутри организации. Так как информация о группах маршрутизации содержится в разделе определения конфигурации Active Directory, определения коннекторов и сведения о затратах находятся здесь же. Протокол состояния связи обращается к каждому из коннекторов по его глобально уникальному идентификатору (GUID).
Примечание. Когда сервер BHS определяет, что связь недоступна для использования, он помечает ее нерабочее состояние. Затем эта информация отправляется всем серверам в данной группе маршрутизации (через порт TCP 691) и серверам-мостам в других группах маршрутизации (через порт TCP 25). При трассировке данных о состоянии связи найдите команду X-Link2state, которая обозначает этот тип данных. Информация передается в порциях, помеченных как "first chunk" ("первая порция"), "second chunk" ("вторая порция") и т.д. вплоть до "last chunk" ("последняя порция").
Ниже показано, какие данные отображаются в Network Monitor. На рис 3.12). Однако в описании пакета отсутствует команда Link2state. Необходимо прочесть данные в каждом пакете, чтобы найти пакеты команды X-Link2state.
(рис 3.13) Данные трассировки, отражающие нерабочее (DOWN) состояние связи(рис 3.12) Данные трассировки, отражающие рабочее (UP) состояние связи
Использование информации о состоянии связи
Давайте разберемся, каким образом используется информация о состоянии связи, и что происходит с сообщениями в случае возникновения неполадки. На рисунке 3.14 показана топология сети, состоящей из пяти групп маршрутизации, с указанием затрат на использование каждого коннектора.
(рис 3.14) Топология маршрутизации в привязке к состоянию связейОшибка одной связи
Как правило, сообщение, отправляемое с сервера в RG1 на сервер в RG5, будет проходить через RG2 и RG4, так как этот маршрут требует наименьших затрат. Предположим, что между RG2 и RG4 возникла неполадка в связи. При возникновении такой ошибки в одной связи протокол состояния связи предписывает выполнение процессов маршрутизации следующим образом.
Сервер BHS в RG1 отправляет сообщение серверу BHS в RG2.
Сервер BHS в RG2 пытается установить SMTP-соединение с сервером BHS в RG 4. Если RG4 содержит несколько серверов BHS, BHS в RG2 пытается установить соединение с каждым BHS в последовательном порядке.
Сервер BHS в RG2 не имеет возможности соединиться ни с одним сервером в RG4, так как физический канал связи находится в нерабочем состоянии. Следовательно, BHS в RG2 переводит соединение в состояние повтора попыток передачи данных. BHS ожидает в течение 60 секунд, после чего осуществляет повторную попытку передачи сообщения серверу BHS в группе RG4.
После трех безуспешных попыток подключения к RG4 BHS в группе RG2 помечает связь нерабочим состоянием, обновляет информацию о состоянии связи в RGM в группе RG2 через порт TCP 691 и вызывает повторную маршрутизацию сообщения, находящегося в исходящей очереди SMTP.
В RGM после получения уведомления о нерабочем состоянии связи эта информация немедленно распространяется среди остальных серверов Exchange Server 2003 в группе маршрутизации.
Сервер BHS в группе RG2 повторно определяет маршрут в RG5 через RG1, RG3 и RG4.
Перед перемаршрутизацией сообщения в RG1 сервер BHS в RG2 отправляет информацию о нерабочем состоянии связи серверу BHS в RG1. Это соединение осуществляется через порт TCP 25 и состоит из команд EHLO и X-Link2state. (Для получения дополнительной информации об этих и других командах SMTP см. в лекции 7 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".)
Сервер BHS в группе RG1 немедленно соединяется с RGM в группе RG1 через порт TCP 691 и передает информацию о нерабочем состоянии связи.
RGM в группе RG1 немедленно распространяет эти данные среди остальных серверов Exchange Server 2003 в группе маршрутизации.
С использованием новой информации о состоянии связи BHS и RG1 определяет оптимальный маршрут к RG5 – через RG3 и RG4.
Перед направлением сообщения в RG3 BHS в RG1 сообщает информацию о состоянии связи серверу BHS в группе RG3. Этот процесс продолжается до тех пор, пока всем группам маршрутизации не станет известно о нерабочем состоянии связи между RG2 и RG4.
В данной ситуации в большинстве случаев все последующие сообщения будут передаваться в RG5 через RG1. При этом сообщения будут доставляться по альтернативному маршруту (RG1-RG3-RG4-RG5), так как каждому серверу в организации известно о нерабочем состоянии основного маршрута.
Сервер BHS в группе RG2 будет продолжать попытки соединения с BHS в RG4 каждые 60 секунд, даже при отсутствии сообщений, ожидающих доставки. Эта функция не подлежит настройке. Когда связь снова переходит в рабочее состояние, всем остальным серверам Exchange в организации сообщается новая информация о состоянии связи. Сервер BHS передает сведения о рабочем состоянии локальному серверу RGM, который, в свою очередь, распространяет эти данные среди серверов Exchange Server 2003 в локальной группе маршрутизации. Затем, аналогично тому, как была распространена информация о нерабочем состоянии связи, сообщение о рабочем состоянии отправляется остальным серверам организации Exchange.
Совет. Как показано на рисунке 3.15, сервер SMTP по умолчанию проверяет состояние связи через 10 минут в рамках первого интервала проверки состояния связи, затем еще через 10 минут – в рамках второго интервала проверки, далее следует третий 10-минутный интервал перед третьей проверкой, после которого все последующие интервалы проверки составляют 15 минут. Можно уменьшить величину этих интервалов, если связь осуществляет передачу важной информации между двумя группами маршрутизации. Минимальный интервал повторной проверки составляет 1 минуту.
(рис 3.15) Интервалы повторной проверки, по умолчанию установленные в настройках виртуального SMTP-сервераПримечание. В этом и следующем примере, в котором рассматривается ситуация с выходом из строя нескольких связей, может сложиться впечатление, что информация о состоянии связи передается только непосредственно перед инициированным пользователем сообщением. Это не так. Информация о состоянии связи передается немедленно в любом случае, независимо от того, осуществляется ли передача других сообщений. В излагаемом материале говорится о том, что информация о состоянии связи передается перед сообщением пользователя, чтобы подчеркнуть важность того, что Exchange Server 2003 распространяет информацию о состоянии связи среди всех своих серверов. Не существует какой-либо обязательной взаимосвязи между передачей сообщения пользователя и отправкой сообщения о состоянии связи главному серверу другой группы маршрутизации.
Выход из строя нескольких связей
Если в определенный момент времени выходят из строя несколько связей, протокол состояния связи обеспечивает тот факт, что сообщение не начинает передаваться вперед-назад между группами маршрутизации при осуществлении постоянных попыток нахождения открытого маршрута для сообщения. Давайте еще раз рассмотрим пример с сервером в группе RG1, пытающимся отправить сообщение серверу в группе RG5. На этот раз предположим, что из строя вышла связь между RG2 и RG4 и между RG3 и RG4. RG1 отправляет сообщение в RG2, после чего RG2 возвращает сообщение в группу RG1, как это было в варианте с выходом из строя одной связи. Ниже приведены шаги, которые будут выполнены протоколом состояния связи.
Сервер BHS в RG1 устанавливает соединение с сервером BHS в группе RG3. Однако перед отправкой сообщения он сообщает серверу BHS в RG3 информацию о нерабочем состоянии связи между группами маршрутизации RG2 и RG4. Сервер BHS в группе RG3 пересылает эту информацию серверу RGM, который распространяет ее среди других серверов в группе маршрутизации.
Затем сервер BHS в группе RG1 отправляет сообщение серверу BHS в группе RG3. Сервер BHS в группе RG3 обнаруживает, что сообщение предназначено для группы RG4, осуществляет попытку установки соединения с сервером BHS в группе RG4, которая заканчивается неудачей. Сервер BHS присваивает связи состояние повторения попыток и осуществляет повтор попыток передачи через 60-секундные промежутки времени.
Если соединение установить не удается, связь помечается нерабочим состоянием, и передается соответствующее уведомление серверу RGM, который, в свою очередь, распространяет данную информацию среди других серверов в группе маршрутизации.
Сервер BHS в группе RG3 пытается определить новый маршрут отправки сообщения, принимая во внимание поступившую информацию. При вышедших из строя связях между группами RG2 и RG4 и группами RG3 и RG4 затраты на маршрутизацию сообщения в группу RG5 принимают значение Infine ("Бесконечность").
Если сумма затрат приняла значение Infinite, сообщение остается в очереди сервера BHS группы RG3, который осуществляет вызовы маршрутизации согласно настройкам вкладки Delivery (Доставка) окна свойств виртуального сервера SMTP, чтобы определить, стала ли связь доступной.
Когда связь снова переходит в рабочее состояние, сообщение соответствующим образом подвергается повторной маршрутизации. Если сообщение простаивает в очереди больше 48 часов, оно возвращается отправителю в группе RG1 с отчетом о невозможности доставки (NDR).
Если во время нерабочего состояния обеих связей из группы RG1 в RG5 были отправлены другие сообщения, они будут оставаться в очереди сервера BHS группы RG1 до тех пор, пока связи не станут работоспособными, и не будет установлен полноценно функционирующий маршрут. Эта очередь является наилучшим местом для сообщений, ожидающих доставки.
Примечание. 48 часов – это интервал по умолчанию, в течение которого сообщения находятся в очереди перед генерацией отчета о невозможности доставки NDR и возвращением сообщения пользователю в Exchange Server 2003. Это значение настраивается на вкладке Delivery (Доставка) окна свойств виртуального сервера SMTP.
Неизменность состояния связи
Если альтернативный маршрут доставки сообщения в другую группу не может быть найден при выходе из строя физического канала связи, Exchange 2003 не меняет состояние связи на нерабочее (DOWN). Эта функциональность является нововведением относительно Exchange 2000 Server и предназначена для улучшения производительности посредством уменьшения необязательного сетевого трафика распространения информации.
Из вышесказанного следует, что если имеются две группы маршрутизации, соединенные одной физической связью, и эта связь выходит из строя, в таблице состояния связи по-прежнему будет отображаться состояние связи UP (рабочее состояние), что позволит ставить сообщения в очередь для доставки через эту связь. Как только связь станет доступной, нормальный обмен данными между двумя сайтами возобновится.
Чередование данных о состоянии связи
Иногда физический канал связи может выключаться и включаться вновь в процессе обслуживания или во время восстановительных работ. В Exchange 2000 каждое изменение в физическом канале связи вызывало изменение информации о состоянии связи, что приводило к многократной доставке информации о состоянии связи.
Эта особенность, связанная с распространением данных о состоянии связи, была переработана в Exchange 2003. Если канал связи постоянно переходит из нерабочего состояния в рабочее, Exchange 2003 не меняет данные о состоянии канала связи и отображает рабочее состояние. В Microsoft пришли к выводу, что лучше оставлять состояние рабочим, чем постоянно менять данные о состоянии связи, загружая сеть пакетами с информацией о состоянии канала связи при каждом его изменении. Этот подход уменьшает объем трафика состояния связи, передаваемого между серверами.
Неполадки главного сервера группы маршрутизации
Если сервер RGM переключается в автономный режим, новый главный сервер не назначается автоматически. Следовательно, информация о состоянии связи, имеющаяся на других серверах в группе маршрутизации, со временем будет все больше и больше устаревать. Если сервер RGM будет отключен в течение значительного промежутка времени, очень важно вручную настроить новый сервер RGM. Это обеспечит наличие на других серверах группы администрирование актуальных данных о состоянии связи.
Чтобы настроить вручную сервер на выполнение функций RGM, нужно перейти в группу маршрутизации, в которой расположен сервер, выделить папку Members сервера, щелкнуть правой кнопкой мыши на сервере в области деталей и выбрать Set As Master (Сделать главным) (см. рис 3.16).
(рис 3.16) Выбор главного сервера маршрутизации в диспетчере Exchange System Manager
Заключение
В данной лекции рассказывалось о том, какие усовершенствования концепции сайтов были добавлены в Exchange Server 2003 по сравнению с Exchange Server 5.5, а именно рассмотрены группы маршрутизации и информация о состоянии связи. SMTP, являющийся теперь основным протоколом передачи сообщений, наиболее устойчив к большому числу задержек и низкой пропускной способности каналов, нежели соединение RPC, и, следовательно, имеет ряд преимуществ, о которых было рассказано в этой лекции. Также было рассмотрено несколько различных ситуаций с выходом из строя канала связи с пояснением того, каким образом ведет себя информация о состоянии связи в каждом случае. В следующей лекции рассказывается о коннекторе Active Directory Connector и об интеграции Exchange Server 2003 с Microsoft Windows 2000 и Microsoft Internet Information Services.
Одно из наиболее значительных различий между Microsoft Exchange Server 5.5 и Microsoft Exchange Server 2003 заключается в базовой архитектуре системы Exchange. Топология маршрутизации сообщений в Exchange Server 5.5 базируется на сайтах. Как известно, сайт образуется посредством логической группировки серверов с постоянными высокоскоростными каналами связи. С точки зрения архитектуры каждый сайт определяет собой три различные области: область для однопролетной маршрутизации, административный модуль и иерархию пространства имен в структуре каталогов.
В Microsoft Exchange 2000 и выше эти три области поделены на отдельные элементы. Однопролетная маршрутизация определяется группой маршрутизации, модуль администрирования определяется административной группой, а иерархия пространства имен располагается в службе каталогов Active Directory в форме домена. Такая архитектура дает администраторам более высокую гибкость при администрировании Exchange Server 2003, так как операции по администрированию разделяются по функциям и действиям, а не по географическому месторасположению.
Группы маршрутизации
Каждая группа маршрутизации в организации, использующей Exchange, состоит из набора надежно соединенных друг с другом серверов Exchange, связь между которыми гарантированно является постоянной и полноценной. Чаще всего группы маршрутизации схожи по своему построению с физической топологией сети. Соединения между серверами в группе маршрутизации полностью базируются на протоколе Simple Mail Transfer Protocol (SMTP). Использование протокола SMTP обеспечивает некоторые преимущества над RPC-соединениями, имевшими место в Exchange 5.5. Во-первых, более гибкую схему маршрутизации и администрирования по сравнению с RPC-соединениями, так как SMTP наиболее "терпим" к топологии низкоскоростных каналов связи с высоким уровнем задержек. Эта "терпимость" позволяет в Exchange Server 2003 группировать серверы в одну группу маршрутизации, которую нельзя было разместить в рамках одного сайта в Exchange 5.5. Во-вторых, использование SMTP допускает разделение
между архитектурой маршрутизации и группированием серверов в целях администрирования. В Exchange 5.5 оба эти элемента определялись сайтом, что вынуждало персонал многих организаций сводить область администрирования к границам сайта. В-третьих, SMTP требует меньшей нагрузки и пропускной способности канала, нежели RPC-соединения.
В дополнение к этому Exchange Server 2003 содержит новую систему калькуляции маршрутизации, исключающую проблемы, связанные с таблицей маршрутизации (Gateway Address Routing Table, GWART), заменяя ее информацией о состоянии связи (об этом пойдет речь далее в лекции).
Примечание. SMTP не заменяет агент передачи сообщений (MTA) в Exchange Server 2003. Напротив, MTA был усовершенствован и работает как в системе Exchange 5.5, так и в Exchange 2000. Тем не менее, он теперь используется, главным образом, для соединения с внешними системами X.400.
В объектной иерархии Exchange Server 2003 группы маршрутизации занимают место под группами администрирования (см. рис 3.1). В группе администрирования (с логическим набором связанных с Exchange объектов, таких как серверы, коннекторы и политики, администрирование которых осуществляется в рамках единой группы) можно настраивать серверы таким образом, чтобы одни направляли сообщения напрямую другим серверам, а остальные можно настроить так, чтобы они направляли сообщения на сервер-мост. (Серверы-мосты рассматриваются более подробно далее в лекции.)
Exchange Server 2003 хранит информацию о маршрутизации в разделе определения конфигурации Active Directory. Хотя эта информация становится доступной в организации Exchange посредством репликации, по-прежнему необходимо настраивать коннекторы между серверами, так как коннекторы помогают сформировать топологию маршрутизации в разделе определения конфигурации. С их помощью создаются определенным образом измененные топологии маршрутизации для обеспечения максимальной гибкости.
(рис 3.1) Объектная иерархия, отображающая группы маршрутизации под группами администрированияГруппы маршрутизации и общие папки
Клиент Exchange 2003 использует информацию о маршрутизации в разделе определения конфигурации в Active Directory для нахождения сервера общих папок. По умолчанию пользователи осуществляют попытки подключения к экземпляру общей папки на своем домашнем сервере, а затем на другом сервере в локальной группе маршрутизации. Если клиент пытается подключиться к экземпляру общей папки, расположенному на сервере в удаленной группе маршрутизации, затраты на использование коннекторов определяют порядок групп маршрутизации, на которые направляется клиент. Можно установить флаг на коннекторе обмена сообщениями для запрета направлений на общие папки через связь (см. рис 3.2), что было невозможно при наличии родственности с сайтами в Exchange Server 5.5.
Примечание. Под затратами на использование коннекторов подразумеваются произвольные затраты, указываемые в Routing Group Connector (RGC) для отражения полосы пропускания канала, ассоциированной с коннектором, и количества сообщений, которое должен принимать коннектор. Например, если RGC настроен на канале T1 и коннектор SMTP работает через спутниковый канал, следует присвоить RGC затраты в размере 1, а SMTP-коннектору – в размере 100. При маршрутизации сообщений по возможности в первую очередь будет использоваться коннектор с меньшими затратами.
(рис 3.2) Окно свойств коннектора обмена сообщениями с опцией Do Not Allow Public Folder Referrals (Запретить направления на общие папки)Рассмотрим пример работы данной системы маршрутизации. Предположим, имеются три группы маршрутизации, в каждой из которых есть по два сервера с именами Server1 и Server2. В каждой группе маршрутизации Server1 представляет собой сервер электронной почты, а Server2 – сервер общих папок. Девушка по имени Sally является членом группы маршрутизации A.
Предположим, Sally пытается подключиться к общей папке с именем Memos в своей домашней группе маршрутизации. К сожалению, Server2 в группе маршрутизации A переведен в автономный режим работы в целях обслуживания. В этом случае Sally направляется через RGC на общие папки в группе маршрутизации B и в группе маршрутизации C для осуществления доступа к экземпляру папки Memos. Если затраты на RGC между группой маршрутизации A и группой маршрутизации B равны 10, а затраты на коннектор между группой маршрутизации A и группой маршрутизации C равны 30, Sally сначала будет направлена в группу маршрутизации B, так как ее коннектор подразумевает меньшие затраты.
Теперь предположим, что физическое соединение между группами маршрутизации A и B обслуживается группой техников. Администратор в группе маршрутизации A может отметить опцию Do Not Allow Public Folder Referrals (Запретить направления на общие папки) на коннекторе с группой маршрутизации B, исключив тем самым коннектор из работы при следующей попытке доступа Sally к папке Memos. После восстановления канала связи администратор может отключить эту опцию, снова разрешив направления на общие папки через этот коннектор.
Совет. Еще одной ситуацией, в которой рекомендуется включать опцию Do Not Allow Public Folder Referrals (Запретить направления на общие папки), является отключенное состояние сервера общих папок в удаленном сайте, если известно, что сервер будет отключен в течение длительного времени. Выбор этой опции исключит запросы на общие папки через данный коннектор. Эта опция также используется в том случае, если все экземпляры общих папок расположены в одной группе маршрутизации, и нужно сфокусировать трафик клиента на этой группе маршрутизации. В данном случае для всех RGC, устанавливающих соединение с группами маршрутизации с общими папками, данная опция будет отключена, в то время как для всех остальных RGC она будет включена.
Обзор транспортной архитектуры
Перед обсуждением того, как сообщения направляются внутри одной группы и между группами, следует ознакомиться с основными принципами передачи сообщений внутри сервера Exchange 2000. Зная, каким образом, например, сообщения поступают в исходящую очередь SMTP, можно без особых трудностей составить схему маршрутизации, о которой пойдет речь на нескольких следующих страницах.
Сообщения могут передаваться в Exchange Server 2003 одним из трех способов. Первым является передача через службу SMTP. Примером данного типа обмена сообщениями является электронная почта интернета. Вторым способом является доставка через хранилище, как в случае с сообщением, созданным клиентом Microsoft Outlook (MAPI) или клиентом Outlook Web Access (OWA). Третьим способом является доставка через агент передачи сообщений Message Transfer Agent (MTA). Сообщения поступают через коннектор X.400 из инородной системы электронной почты или через любой коннектор, реализованный с помощью Exchange Development Kit (EDK).
Как видно на рисунке 3.3, сообщения SMTP сначала отправляются в очередь NTFS, так как не все сообщения, поступающие через SMTP, направлены к локальному хранилищу Exchange. После этого сообщения SMTP отправляются в очередь перед категоризацией для дальнейшей обработки.
Сообщения, передаваемые посредством доставки через хранилище или через MTA, направляются драйверу хранилища Exchange. Драйвер хранилища Exchange берет эти сообщения и передает их в очередь перед категоризацией. Очередь перед категоризацией является первым местом, в котором возможно выполнение так называемых приемников событий. Приемники событий представляют собой сценарии обработки сообщения с целью выполнения определенных функций, таких как добавление отказа от прав или запуск антивирусной программы. Затем сообщение передается в систему категоризации сообщений, которая, по сути, представляет собой набор приемников событий, осуществляющих разрешение адресов для создателя сообщения и для его получателя. Кроме этого, система категоризации сообщений получает из Active Directory атрибуты, присущие сообщению, такие как предельный размер исходящих и входящих сообщений создателя или получателя, ограничения доставки,
спецификации пересылки и другие параметры, которые налагают на сообщения некоторые ограничения. Любые имеющиеся ограничения применяются к сообщению. После выполнения этих задач сообщение помещается в очередь после категоризации, позволяющую выполнять дополнительные приемники событий, если таковые установлены.
(рис 3.3) Внутренняя транспортная архитектура Exchange Server 2003После обработки сообщения в очереди после категоризации оно передается в систему маршрутизации, анализирующую адрес пункта назначения в сопоставлении с таблицей структуры и конфигурации домена. Затем система маршрутизации принимает решение о том, направлять ли сообщение в локальное хранилище или создать временную исходящую очередь (также называемую очередью сообщений пункта назначения) для передачи сообщения на другой сервер SMTP.
Очереди сообщений пункта назначения создаются на основе имени домена пункта назначения. Дополнительная система построения очередей может создавать столько очередей пункта назначения, сколько требуется. Из этих очередей служба SMTP считывает сообщение и передает его следующему серверу SMTP. Если сообщение направлено в локальное хранилище, оно располагается в очереди локальной доставки. После этого процесс Store.exe считывает сообщение из очереди и записывает его в локальную базу данных. Затем сообщение ассоциируется с почтовым ящиком пункта назначения, и получатель уведомляется о поступлении новой почты.
, она является управляющим компонентом, работающим в фоновом режиме и обеспечивающим перемещение сообщений через транспортное ядро.
Маршрутизация сообщений внутри одного сервера
Когда Exchange Server 2003 определяет, что получатель сообщения находится на одном сервере с отправителем, происходит доставка сообщения в папку Inbox (Входящие) получателя. Данный процесс (см. рис 3.4) состоит из следующих шагов.
Клиент отправляет сообщение.
Сообщение передается в систему категоризации, анализируется в сопоставлении с таблицей схемы домена, после чего помещается в очередь локальной доставки.
Хранилище информации ассоциирует сообщение с почтовым ящиком получателя.
Маршрутизация сообщений внутри одной группы маршрутизации
При передаче сообщений между серверами в одной и той же группе маршрутизации используется транспортный протокол SMTP. Маршрутизация сообщения между двумя серверами в одной группе маршрутизации (см. рис 3.5) состоит из следующих шагов.
Клиент отправляет сообщение.
Сообщение передается в систему категоризации, применяющую все ограничения, обнаруженные в Active Directory. Затем сообщение передается через очередь после категоризации и далее в систему маршрутизации.(рис 3.4) Маршрутизация сообщения Exchange Server 2003 в случае, когда отправитель и получатель сообщения располагаются на одном сервере
Система маршрутизации анализирует сообщение в сопоставлении с таблицей схемы имени домена, после чего помещает сообщение в исходящую очередь SMTP для отправки на сервер назначения. Данная очередь создается для сообщения динамически на основе имени домена назначения, которое и становится именем очереди; в данном случае это имя hr.trainsbydave.com (Local Delivery).
Сервер отправки находит каталог почтового ящика получателя в Active Directory, производит поиск DNS записи обмена сообщениями (MX), связанной с сервером назначения, на котором находится почтовый ящик получателя, и после этого создает TCP-соединение с этим сервером через порт 25.
Сообщение передается на сервер назначения.
Сервер назначения принимает сообщение от службы SMTP и помещает его в очередь NTFS. AQE считывает сообщение из очереди и передает сообщение через транспортное ядро.(рис 3.5) Направление сообщения Exchange Server 2003 получателю, находящемуся на другом сервере
Направление сообщений в другие группы маршрутизации
Сообщения направляются на серверы в других группах маршрутизации через сервер-мост (BHS) с каждой стороны коннектора, если этот сервер в отдельном порядке установлен в коннекторе. С помощью RGC сервер назначения можно настроить на работу в качестве любого сервера в группе маршрутизации назначения. Маршрутизация сообщений на серверы в различных группах маршрутизации (см. рис 3.6) состоит из следующих этапов.
Клиент отправляет сообщение.
Сообщение передается через транспортное ядро, после чего помещается в очередь исходящих сообщений SMTP.
В разделе определения конфигурации Active Directory собирается информация о группе маршрутизации.
Анализируется информация о состоянии связи для определения оптимального маршрута. (Более подробная информация приведена далее в лекции.)
Сообщение передается серверу BHS через порт TCP 25.
Сервер BHS передает сообщение через порт TCP 25 серверу BHS в группе маршрутизации назначения.
Принимающий сервер BHS передает сообщение серверу назначения в своей группе маршрутизации через порт TCP 25.
Сообщение поступает на сервер назначения через службу SMTP и располагается в очереди NTFS.
AQE извлекает сообщение из очереди, после чего сообщение ассоциируется с почтовым ящиком получателя.
(рис 3.6) Маршрутизация сообщения Exchange Server 2003 получателю в другой группе маршрутизации
Направление сообщений в инородные системы электронной почты
Сообщения направляются в другие системы электронной почты через коннектор X.400, если имеется прямое и постоянное соединение. В противном случае сообщения направляются через интернет с использованием протокола SMTP. Маршрутизация сообщений в другую систему электронной почты с использованием SMTP (см. рис 3.7) состоит из следующих этапов.
Клиент отправляет сообщение.
Сообщение располагается в очереди исходящих сообщений SMTP.
Служба SMTP считывает сообщение из очереди и отправляет его через порт TCP 25 на SMTP-сервер назначения.
(рис 3.7) Маршрутизация сообщения Exchange Server 2003 получателю в другой системе электронной почты через протокол SMTPЕсли сообщение направляется в другую систему электронной почты через коннектор X.400, этапы данного процесса, по сути, идентичны маршрутизации через SMTP, за исключением того, что используется коннектор X.400 и отсутствует номер порта.
Топологии группы маршрутизации
Существует несколько способов соединения с группами маршрутизации. Наиболее распространенными топологиями являются топологии типа "ось и спицы" и "паутина". Топология "ось и спицы", как видно из самого названия, содержит центральную группу маршрутизации, с которой соединены все остальные группы маршрутизации (см. рис 3.8). Администрирование топологии "ось и спицы" осуществляется проще, так как в ней приходится создавать и обслуживать сравнительно небольшое число RGC. Одним очень весомым недостатком данной топологии является то, что если в одном месте возникает ошибка, то нет возможности решить текущую задачу альтернативным способом. Если по каким-либо причинам Exchange Server 2003 или физические каналы связи с "осью" выходят из строя, обмен сообщениями между группами маршрутизации полностью прекращается до устранения возникших неполадок.
В топологии "паутина" каждая группа маршрутизации имеет связь RGC с каждой из остальных групп маршрутизации в организации. Данная топология обеспечивает избыточность в случае ошибки соединения или сервера в любой точке; информация о состоянии связи позволяет перенаправить сообщение по другому маршруту. Тем не менее, осуществлять администрирование такой топологии сложнее, так как она требует создания и обслуживания большего числа коннекторов RGC. На рисунке 3.9 показана схема топологии "паутина".
Менее распространенным способом соединения групп маршрутизации является линейная топология (см. рис 3.10). В данной топологии все группы маршрутизации соединяются линейно в логическом порядке. Несмотря на то что эта топология наиболее проста в реализации из-за минимального количества требуемых RGC, в ней очень велика вероятность возникновения неполадок. Например, здесь не обеспечивается избыточности маршрутизации, следовательно, потеря связи между любыми двумя группами маршрутизации означает, что обмен сообщениями будет прерван во всей организации. Во-вторых, передача сообщения из одного конца в другой занимает слишком много времени с точки зрения требований организации. При отсутствии альтернативных маршрутов задержки при обмене сообщениями становятся серьезной проблемой. Данную топологию использовать не рекомендуется, а вместо нее можно использовать либо топологию "ось и спицы",
либо модифицированную топологию "паутина", о которой пойдет речь ниже.
(рис 3.9) Топология "ось и спицы"(рис 3.8) Топология "паутина"(рис 3.10) Линейная топологияМодифицированная топология "паутина" (см. рис 3.11) предусматривает несколько маршрутов к каждой группе маршрутизации, однако не обеспечивает связь каждой группы маршрутизации с каждой другой группой маршрутизации внутри организации. В большинстве случаев модифицированная топология "паутина" подходит наибольшим образом.
(рис 3.11) Модифицированная топология "паутина"Информация о состоянии связи
Протокол состояния связи представляет собой двоичный протокол, значительно улучшающий маршрутизацию сообщений в Exchange 2003 по сравнению с Exchange 5.5. Маршрутизация сообщений в Exchange 5.5 базируется на таблице маршрутизации GWART, в которой отслеживаются все доступные коннекторы, а также сумма "затрат" на использование этих коннекторов. GWART имеет ограничение, заключающееся в том, что она содержит только информацию об уже происшедшем событии. Она не отслеживает состояние непосредственно в текущий момент времени. Таблица GWART располагается в объекте Site Addressing и вызывается агентом MTA при определении маршрутов доставки сообщений на сервер назначения.
Протокол состояния связи функционирует через порт TCP 691 в группе маршрутизации. В каждой группе маршрутизации один из серверов является главным сервером группы маршрутизации (Routing Group Master, RGM). RGM получает информацию о состоянии связи и сообщает ее серверам в группе маршрутизации, включая сервер BHS. Когда один BHS соединяется с другим BHS, находящимся в другой группе маршрутизации, обмен информацией о состоянии связи осуществляется через порт TCP 25 с использованием протокола SMTP. RGM отслеживает работающие и не работающие серверы и сообщает эту информацию серверам RGM во всех остальных группах маршрутизации.
Алгоритм состояния связи
Алгоритм состояния связи является нововведением в Exchange Server 2003, хотя нечто подобное было разработано очень давно. Впервые об этом алгоритме заговорили в 1959 г., когда Edsger Dijkstra представил разработку протокола Open Shortest Path First (OSPF), который сегодня широко используется маршрутизаторами. Несмотря на то что Exchange Server 2003 при выборе маршрута руководствуется затратами на его использование, не менее значимым фактором в процессе маршрутизации сообщений между группами маршрутизации является информация о состоянии связи.
Алгоритм состояния связи сообщает о состоянии системы обмена сообщениями почти в реальном времени всем серверам в организации. Это обеспечивает следующие преимущества:
каждый сервер Exchange может выбрать оптимальный маршрут перед отправкой сообщения и избежать возможных повреждений канала связи на одном из потенциальных маршрутов;
исключается "пинг-понг" сообщений, так как информация об альтернативных маршрутах сообщается каждому серверу Exchange Server 2003;
исключается зацикливание сообщений.
Принимая во внимание гибкость данного протокола, можно предположить, что грядущие его версии обеспечат взаимодействие с сетевыми маршрутизаторами для достижения еще больших возможностей маршрутизации. Сети, взаимодействие которых построено на этом принципе, обычно называются сетями с направленной маршрутизацией.
Концепции определения состояния связи
Информация о состоянии связи является достаточно важным фактором, если в организации имеется несколько групп маршрутизации с несколькими маршрутами между группами. RGM осуществляет управление информацией о состоянии связи, отправляя и принимая ее от серверов RGM из других групп маршрутизации. RGM не обязательно должен являться тем же сервером, что и BHS, который представляет собой сервер, предназначенный для обмена сообщениями через данный коннектор с другим сервером BHS. Сервер RGM по умолчанию является первым сервером, устанавливаемым в группе маршрутизации. Это обстоятельство можно изменить в ESM, щелкнув правой кнопкой мыши на сервере, не являющемся RGM, и выбрав опцию Set As Master (Сделать главным). Кроме того, можно вручную настроить один и тот же сервер на выполнение обеих ролей.
Сервер RGM обеспечивает наличие на всех серверах в группе маршрутизации информации о состоянии связи, свидетельствующей о доступности коннекторов обмена сообщениями и серверов в других группах. Кроме этого, он обеспечивает наличие в других группах корректной информации о подчиненных ему серверах.
Информация о состоянии связи распространяется между серверами группы с помощью протокола SMTP, а информация о состоянии связи между группами реплицируется от одного RGM к другому через порт TCP 25. Любая рассматриваемая связь находится только в двух состояниях: рабочем ( up ) и нерабочем ( down ). Информация о состоянии связи не содержит какую-либо информацию о соединении, например, находится ли связь в состоянии повторной попытки передачи. Данная информация известна только серверу, участвующему в передаче сообщения.
Примечание. Коннекторы, такие как Lotus cc:Mail Connector, Microsoft Mail Connector и другие коннекторы, реализованные с использованием EDK, всегда отображают свое состояние связи как рабочее, даже если связь в действительности недоступна.
Информация о состоянии связи хранится в памяти, а не на диске. Если сервер RGM отключается или требует перезапуска, он затем должен будет получить всю текущую информацию о состоянии связи от других серверов RGM внутри организации. Так как информация о группах маршрутизации содержится в разделе определения конфигурации Active Directory, определения коннекторов и сведения о затратах находятся здесь же. Протокол состояния связи обращается к каждому из коннекторов по его глобально уникальному идентификатору (GUID).
Примечание. Когда сервер BHS определяет, что связь недоступна для использования, он помечает ее нерабочее состояние. Затем эта информация отправляется всем серверам в данной группе маршрутизации (через порт TCP 691) и серверам-мостам в других группах маршрутизации (через порт TCP 25). При трассировке данных о состоянии связи найдите команду X-Link2state, которая обозначает этот тип данных. Информация передается в порциях, помеченных как "first chunk" ("первая порция"), "second chunk" ("вторая порция") и т.д. вплоть до "last chunk" ("последняя порция").
Ниже показано, какие данные отображаются в Network Monitor. На рис 3.12). Однако в описании пакета отсутствует команда Link2state. Необходимо прочесть данные в каждом пакете, чтобы найти пакеты команды X-Link2state.
(рис 3.13) Данные трассировки, отражающие нерабочее (DOWN) состояние связи(рис 3.12) Данные трассировки, отражающие рабочее (UP) состояние связи
Использование информации о состоянии связи
Давайте разберемся, каким образом используется информация о состоянии связи, и что происходит с сообщениями в случае возникновения неполадки. На рисунке 3.14 показана топология сети, состоящей из пяти групп маршрутизации, с указанием затрат на использование каждого коннектора.
(рис 3.14) Топология маршрутизации в привязке к состоянию связейОшибка одной связи
Как правило, сообщение, отправляемое с сервера в RG1 на сервер в RG5, будет проходить через RG2 и RG4, так как этот маршрут требует наименьших затрат. Предположим, что между RG2 и RG4 возникла неполадка в связи. При возникновении такой ошибки в одной связи протокол состояния связи предписывает выполнение процессов маршрутизации следующим образом.
Сервер BHS в RG1 отправляет сообщение серверу BHS в RG2.
Сервер BHS в RG2 пытается установить SMTP-соединение с сервером BHS в RG 4. Если RG4 содержит несколько серверов BHS, BHS в RG2 пытается установить соединение с каждым BHS в последовательном порядке.
Сервер BHS в RG2 не имеет возможности соединиться ни с одним сервером в RG4, так как физический канал связи находится в нерабочем состоянии. Следовательно, BHS в RG2 переводит соединение в состояние повтора попыток передачи данных. BHS ожидает в течение 60 секунд, после чего осуществляет повторную попытку передачи сообщения серверу BHS в группе RG4.
После трех безуспешных попыток подключения к RG4 BHS в группе RG2 помечает связь нерабочим состоянием, обновляет информацию о состоянии связи в RGM в группе RG2 через порт TCP 691 и вызывает повторную маршрутизацию сообщения, находящегося в исходящей очереди SMTP.
В RGM после получения уведомления о нерабочем состоянии связи эта информация немедленно распространяется среди остальных серверов Exchange Server 2003 в группе маршрутизации.
Сервер BHS в группе RG2 повторно определяет маршрут в RG5 через RG1, RG3 и RG4.
Перед перемаршрутизацией сообщения в RG1 сервер BHS в RG2 отправляет информацию о нерабочем состоянии связи серверу BHS в RG1. Это соединение осуществляется через порт TCP 25 и состоит из команд EHLO и X-Link2state. (Для получения дополнительной информации об этих и других командах SMTP см. в лекции 7 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".)
Сервер BHS в группе RG1 немедленно соединяется с RGM в группе RG1 через порт TCP 691 и передает информацию о нерабочем состоянии связи.
RGM в группе RG1 немедленно распространяет эти данные среди остальных серверов Exchange Server 2003 в группе маршрутизации.
С использованием новой информации о состоянии связи BHS и RG1 определяет оптимальный маршрут к RG5 – через RG3 и RG4.
Перед направлением сообщения в RG3 BHS в RG1 сообщает информацию о состоянии связи серверу BHS в группе RG3. Этот процесс продолжается до тех пор, пока всем группам маршрутизации не станет известно о нерабочем состоянии связи между RG2 и RG4.
В данной ситуации в большинстве случаев все последующие сообщения будут передаваться в RG5 через RG1. При этом сообщения будут доставляться по альтернативному маршруту (RG1-RG3-RG4-RG5), так как каждому серверу в организации известно о нерабочем состоянии основного маршрута.
Сервер BHS в группе RG2 будет продолжать попытки соединения с BHS в RG4 каждые 60 секунд, даже при отсутствии сообщений, ожидающих доставки. Эта функция не подлежит настройке. Когда связь снова переходит в рабочее состояние, всем остальным серверам Exchange в организации сообщается новая информация о состоянии связи. Сервер BHS передает сведения о рабочем состоянии локальному серверу RGM, который, в свою очередь, распространяет эти данные среди серверов Exchange Server 2003 в локальной группе маршрутизации. Затем, аналогично тому, как была распространена информация о нерабочем состоянии связи, сообщение о рабочем состоянии отправляется остальным серверам организации Exchange.
Совет. Как показано на рисунке 3.15, сервер SMTP по умолчанию проверяет состояние связи через 10 минут в рамках первого интервала проверки состояния связи, затем еще через 10 минут – в рамках второго интервала проверки, далее следует третий 10-минутный интервал перед третьей проверкой, после которого все последующие интервалы проверки составляют 15 минут. Можно уменьшить величину этих интервалов, если связь осуществляет передачу важной информации между двумя группами маршрутизации. Минимальный интервал повторной проверки составляет 1 минуту.
(рис 3.15) Интервалы повторной проверки, по умолчанию установленные в настройках виртуального SMTP-сервераПримечание. В этом и следующем примере, в котором рассматривается ситуация с выходом из строя нескольких связей, может сложиться впечатление, что информация о состоянии связи передается только непосредственно перед инициированным пользователем сообщением. Это не так. Информация о состоянии связи передается немедленно в любом случае, независимо от того, осуществляется ли передача других сообщений. В излагаемом материале говорится о том, что информация о состоянии связи передается перед сообщением пользователя, чтобы подчеркнуть важность того, что Exchange Server 2003 распространяет информацию о состоянии связи среди всех своих серверов. Не существует какой-либо обязательной взаимосвязи между передачей сообщения пользователя и отправкой сообщения о состоянии связи главному серверу другой группы маршрутизации.
Выход из строя нескольких связей
Если в определенный момент времени выходят из строя несколько связей, протокол состояния связи обеспечивает тот факт, что сообщение не начинает передаваться вперед-назад между группами маршрутизации при осуществлении постоянных попыток нахождения открытого маршрута для сообщения. Давайте еще раз рассмотрим пример с сервером в группе RG1, пытающимся отправить сообщение серверу в группе RG5. На этот раз предположим, что из строя вышла связь между RG2 и RG4 и между RG3 и RG4. RG1 отправляет сообщение в RG2, после чего RG2 возвращает сообщение в группу RG1, как это было в варианте с выходом из строя одной связи. Ниже приведены шаги, которые будут выполнены протоколом состояния связи.
Сервер BHS в RG1 устанавливает соединение с сервером BHS в группе RG3. Однако перед отправкой сообщения он сообщает серверу BHS в RG3 информацию о нерабочем состоянии связи между группами маршрутизации RG2 и RG4. Сервер BHS в группе RG3 пересылает эту информацию серверу RGM, который распространяет ее среди других серверов в группе маршрутизации.
Затем сервер BHS в группе RG1 отправляет сообщение серверу BHS в группе RG3. Сервер BHS в группе RG3 обнаруживает, что сообщение предназначено для группы RG4, осуществляет попытку установки соединения с сервером BHS в группе RG4, которая заканчивается неудачей. Сервер BHS присваивает связи состояние повторения попыток и осуществляет повтор попыток передачи через 60-секундные промежутки времени.
Если соединение установить не удается, связь помечается нерабочим состоянием, и передается соответствующее уведомление серверу RGM, который, в свою очередь, распространяет данную информацию среди других серверов в группе маршрутизации.
Сервер BHS в группе RG3 пытается определить новый маршрут отправки сообщения, принимая во внимание поступившую информацию. При вышедших из строя связях между группами RG2 и RG4 и группами RG3 и RG4 затраты на маршрутизацию сообщения в группу RG5 принимают значение Infine ("Бесконечность").
Если сумма затрат приняла значение Infinite, сообщение остается в очереди сервера BHS группы RG3, который осуществляет вызовы маршрутизации согласно настройкам вкладки Delivery (Доставка) окна свойств виртуального сервера SMTP, чтобы определить, стала ли связь доступной.
Когда связь снова переходит в рабочее состояние, сообщение соответствующим образом подвергается повторной маршрутизации. Если сообщение простаивает в очереди больше 48 часов, оно возвращается отправителю в группе RG1 с отчетом о невозможности доставки (NDR).
Если во время нерабочего состояния обеих связей из группы RG1 в RG5 были отправлены другие сообщения, они будут оставаться в очереди сервера BHS группы RG1 до тех пор, пока связи не станут работоспособными, и не будет установлен полноценно функционирующий маршрут. Эта очередь является наилучшим местом для сообщений, ожидающих доставки.
Примечание. 48 часов – это интервал по умолчанию, в течение которого сообщения находятся в очереди перед генерацией отчета о невозможности доставки NDR и возвращением сообщения пользователю в Exchange Server 2003. Это значение настраивается на вкладке Delivery (Доставка) окна свойств виртуального сервера SMTP.
Неизменность состояния связи
Если альтернативный маршрут доставки сообщения в другую группу не может быть найден при выходе из строя физического канала связи, Exchange 2003 не меняет состояние связи на нерабочее (DOWN). Эта функциональность является нововведением относительно Exchange 2000 Server и предназначена для улучшения производительности посредством уменьшения необязательного сетевого трафика распространения информации.
Из вышесказанного следует, что если имеются две группы маршрутизации, соединенные одной физической связью, и эта связь выходит из строя, в таблице состояния связи по-прежнему будет отображаться состояние связи UP (рабочее состояние), что позволит ставить сообщения в очередь для доставки через эту связь. Как только связь станет доступной, нормальный обмен данными между двумя сайтами возобновится.
Чередование данных о состоянии связи
Иногда физический канал связи может выключаться и включаться вновь в процессе обслуживания или во время восстановительных работ. В Exchange 2000 каждое изменение в физическом канале связи вызывало изменение информации о состоянии связи, что приводило к многократной доставке информации о состоянии связи.
Эта особенность, связанная с распространением данных о состоянии связи, была переработана в Exchange 2003. Если канал связи постоянно переходит из нерабочего состояния в рабочее, Exchange 2003 не меняет данные о состоянии канала связи и отображает рабочее состояние. В Microsoft пришли к выводу, что лучше оставлять состояние рабочим, чем постоянно менять данные о состоянии связи, загружая сеть пакетами с информацией о состоянии канала связи при каждом его изменении. Этот подход уменьшает объем трафика состояния связи, передаваемого между серверами.
Неполадки главного сервера группы маршрутизации
Если сервер RGM переключается в автономный режим, новый главный сервер не назначается автоматически. Следовательно, информация о состоянии связи, имеющаяся на других серверах в группе маршрутизации, со временем будет все больше и больше устаревать. Если сервер RGM будет отключен в течение значительного промежутка времени, очень важно вручную настроить новый сервер RGM. Это обеспечит наличие на других серверах группы администрирование актуальных данных о состоянии связи.
Чтобы настроить вручную сервер на выполнение функций RGM, нужно перейти в группу маршрутизации, в которой расположен сервер, выделить папку Members сервера, щелкнуть правой кнопкой мыши на сервере в области деталей и выбрать Set As Master (Сделать главным) (см. рис 3.16).
(рис 3.16) Выбор главного сервера маршрутизации в диспетчере Exchange System Manager
Заключение
В данной лекции рассказывалось о том, какие усовершенствования концепции сайтов были добавлены в Exchange Server 2003 по сравнению с Exchange Server 5.5, а именно рассмотрены группы маршрутизации и информация о состоянии связи. SMTP, являющийся теперь основным протоколом передачи сообщений, наиболее устойчив к большому числу задержек и низкой пропускной способности каналов, нежели соединение RPC, и, следовательно, имеет ряд преимуществ, о которых было рассказано в этой лекции. Также было рассмотрено несколько различных ситуаций с выходом из строя канала связи с пояснением того, каким образом ведет себя информация о состоянии связи в каждом случае. В следующей лекции рассказывается о коннекторе Active Directory Connector и об интеграции Exchange Server 2003 с Microsoft Windows 2000 и Microsoft Internet Information Services.
