Соединение групп маршрутизации

Администрирование состояния связи

В этом параграфе будет рассказано о том, как управлять информацией о состоянии связи в системе Exchange. (О работе протокола состояния связи см. в "Архитектура маршрутизации Exchange Server" .)

Администрирование информации о состоянии связи выполняется внутри контейнера Queues (Очереди) сервера и заключается, в основном, в выполнении функций управления очередями. Мы сконцентрируем внимание на протоколе SMTP (см. рис. 13.11), поскольку он используется и коннектором Routing Group Connector (RGC), и коннектором SMTP.

увеличить изображение
Рис. 13.11. Очереди SMTP в окне оснастки Exchange System

Прежде чем начать обсуждение, рассмотрим топологию сети, которая будет использоваться в качестве примера. На рисунке 13.12 показано, что наша вымышленная компания hr.trainsbydave.com имеет офисы в четырех городах: Folsom, Tucson, Minneapolis и Indianapolis. Здесь также видно, что в каждом городе имеется по одному пользователю, которые будут использоваться нами для иллюстрации обмена сообщениями и соединений. Предполагается, что значение стоимости для каждого коннектора равно 1. Кроме того, коннекторам групп маршрутизации присвоены имена соответствующих штатов, например, California Arizona RGC для канала связи между городами Folsom (шт. Калифорния) и Tucson (шт. Аризона). И, наконец, серверы именуются по их местонахождению, то есть имеются четыре сервера: Tucson, Folsom, Minneapolis и Indianapolis.

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

Когда пользователь ssmith отправляет сообщение пользователю benglish, оно должно пройти через сервер Folsom. Сообщение не проходит через Minneapolis потому, что суммарная стоимость данного маршрута не является минимальной. По умолчанию используется маршрут с минимальной стоимостью, то есть из Indianapolis в Folsom и далее в Tucson, с суммарной стоимостью, равной 2.

Рис. 13.12. Топология маршрутизации для hr.trainsbydave.com

Теперь, когда вы ознакомились с данной вымышленной компанией, рассмотрим работу протокола состояния связи (Link State) при отключении какого-либо канала. Мы рассмотрим четыре различных сценария и покажем, как происходит администрирование протокола Link State.

Сценарий 1: недоступен первый канал связи

Сообщение, отправленное пользователем benglish пользователю ssmith, должно пройти через два отдельных канала (Indianapolis/Folsom и Folsom/Tucson) и через три различных сервера (Tucson, Folsom и Indianapolis). Однако предположим, что сервер Folsom отключен от сети по какой-либо причине, и что benglish отправляет сообщение ssmith. Как видно из рисунка 13.13, это сообщение сначала поступает в исходящую очередь коннектора RGC.

Управление сообщениями в исходящих очередях

В Microsoft разработан удобный способ, позволяющий узнавать о проблемах, связанных с очередью, – значки. Как показано на рисунке 13.13, значок в области результатов (область справа) очереди группы маршрутизации California Arizona сменился для отображения того, что очередь находится в состоянии повтора (небольшая синяя стрелка на значке).

увеличить изображение
Рис. 13.13. Сообщение в исходящей очереди California Indiana RGC (Routing Group Connector)

Управление очередями и сообщениями, которые в них находятся, можно осуществлять несколькими способами. Во-первых, можно "заморозить" (задержать) очередь, щелкнув на ней правой кнопкой мыши и выбрав команду Freeze (Задержать). Если выполнить это действие, то все сообщения так и останутся в очереди, даже если канал связи снова начнет работать. Задержание очереди может стать хорошим способом отключения попыток доставки сообщения во время разрешения каких-либо возникших проблем. Если дважды щелкнуть на очереди, чтобы отобразить находящиеся в ней сообщения, станет понятно, что можно задерживать и отдельные сообщения. Замораживание сообщения пригодится в том случае, если известно, что конкретное сообщение в очереди имеет достаточно большой размер или маленькую важность, и что его можно отложить до тех пор, пока не будут отправлены все остальные сообщения. Очередь или отдельное сообщение размораживаются посредством щелчка правой кнопкой мыши на объекте и выбора команды Unfreeze (Разморозить). При размораживании очереди или сообщения немедленно возобновляется доставка сообщений.

Кроме этого, существует возможность удаления любого отдельного сообщения в исходящей очереди. Для этого щелкните правой кнопкой мыши на данном сообщении и выберите команду Delete (Удалить) (либо просто щелкните на сообщении и нажмите клавишу [Delete]). При этом можно указать, требуется или не требуется отправка создателю сообщения отчета о невозможности доставки.

Возобновление нормальной работы

Один лишь тот факт, что сообщения отправлялись, не означает, что информация о состоянии связи снова отражает нормальное состояние. После того как сервер снова подсоединен и начал работу, может начаться передача сообщений, но значок коннектора все еще будет указывать, что канал находится в состоянии повторения попыток. Здесь не о чем беспокоиться. Подождите несколько минут и снова проверьте очередь; после этого обычно значок указывает, что очередь находится в нормальном состоянии.

Сценарий 2: канал получателя недоступен

Мы разобрались, что происходит с сообщением, если становится недоступным первый сегмент. Теперь рассмотрим, что произойдет, если станет недоступным последний сегмент. В этом сценарии пользователь benglish отправляет сообщение пользователю ssmith, но на этот раз нет доступа к серверу Indianapolis.

Когда benglish отправляет сообщение, оно маршрутизируется из Tucson в Folsom, где ожидает, пока не заработает сервер Indianapolis или пока не истечет срок годности сообщения; в последнем случае автору будет отправлен отчет о невозможности доставки (NDR).

Сценарий 3: доступен альтернативный маршрут с более высокой стоимостью

Одной из возможностей протокола состояния связи является его способность определять, что часть полного маршрута неисправна, и перенаправлять сообщение через канал с большей стоимостью. Однако, как говорилось в "Архитектура маршрутизации Exchange Server" , усовершенствования в протоколе состояния связи в Exchange Server 2003 обуславливают тот факт, что связи не помечаются как недоступные, если конкретная связь является единственной связью между двумя местоположениями, или если состояние связи постоянно изменяется.

Для данного сценария увеличим до 100 единиц стоимость коннектора между серверами Folsom и Indianapolis. На рисунке 13.14 показана новая топология. Теперь предположим, что пользователь benglish в Tucson отправляет сообщение пользователю ssmith в Indianapolis.

При заданных стоимостях коннекторов обычный маршрут этого сообщения будет проходить через Minneapolis. Предположим, что канал между серверами Minneapolis и Folsom отключен. В результате сообщения будут маршрутизироваться через канал с более высокой стоимостью – между Indianapolis и Folsom.

Примечание. Если вы не знаете, по какому маршруту направлено сообщение, отследите путь этого сообщения. Подробнее об этом рассказывается в лекции 6 "Функциональность, безопасность и поддержка Exchange Server 2003"

увеличить изображение
Рис. 13.14. Новая топология для hr.trainsbydave.com

Сценарий 4: сообщение имеет несколько получателей

Если сообщение направлено как внутренним, так и внешним получателям, то создается временная очередь для каждого внешнего доменного имени, а также для каждого внутреннего сервера Exchange Server 2003, на котором находится получатель данного сообщения. Предположим, что сообщение отправлено в группу вымышленных доменных имен. При отправке сообщения расширенный механизм очередей создает необходимые очереди. Протокол состояния связи не используется для этих выходных очередей SMTP к внешним серверам. Он должен только поддерживать текущую информацию о состоянии связи для внутренних серверов.

Заключение

В этой лекции рассказывалось о том, как осуществляется администрирование и управление коннекторами Routing Group Connector и SMTP Connector. Кроме этого, показано, как информация о состоянии связи позволяет осуществлять маршрутизацию сообщений в различных ситуациях. Например, было показано, что протокол состояния связи может определять, когда канал связи находится в нерабочем состоянии, и удерживать сообщения до тех пор, пока канал вновь не заработает.

Протокол состояния связи является одной из наиболее мощных возможностей Exchange Server 2003. Еще одной важной особенностью Exchange Server 2003 является возможность сосуществования с серверами Exchange 5.x. Если в организации используется операционная система Windows NT 4 и Exchange 5.5, необходимо разрешить вопросы, связанные с обновлением и сосуществованием с Windows Server 2003 и Exchange Server 2003, в процессе перехода к более новым версиям продуктов. Эти вопросы обсуждаются в курсе "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".