Архитектура маршрутизации Exchange Server

Использование информации о состоянии связи

Давайте разберемся, каким образом используется информация о состоянии связи, и что происходит с сообщениями в случае возникновения неполадки. На рисунке 3.14 показана топология сети, состоящей из пяти групп маршрутизации, с указанием затрат на использование каждого коннектора.

Рис. 3.14. Топология маршрутизации в привязке к состоянию связей

Ошибка одной связи

Как правило, сообщение, отправляемое с сервера в RG1 на сервер в RG5, будет проходить через RG2 и RG4, так как этот маршрут требует наименьших затрат. Предположим, что между RG2 и RG4 возникла неполадка в связи. При возникновении такой ошибки в одной связи протокол состояния связи предписывает выполнение процессов маршрутизации следующим образом.

1. Сервер BHS в RG1 отправляет сообщение серверу BHS в RG2.
2. Сервер BHS в RG2 пытается установить SMTP-соединение с сервером BHS в RG 4. Если RG4 содержит несколько серверов BHS, BHS в RG2 пытается установить соединение с каждым BHS в последовательном порядке.
3. Сервер BHS в RG2 не имеет возможности соединиться ни с одним сервером в RG4, так как физический канал связи находится в нерабочем состоянии. Следовательно, BHS в RG2 переводит соединение в состояние повтора попыток передачи данных. BHS ожидает в течение 60 секунд, после чего осуществляет повторную попытку передачи сообщения серверу BHS в группе RG4.
4. После трех безуспешных попыток подключения к RG4 BHS в группе RG2 помечает связь нерабочим состоянием, обновляет информацию о состоянии связи в RGM в группе RG2 через порт TCP 691 и вызывает повторную маршрутизацию сообщения, находящегося в исходящей очереди SMTP.
5. В RGM после получения уведомления о нерабочем состоянии связи эта информация немедленно распространяется среди остальных серверов Exchange Server 2003 в группе маршрутизации.
6. Сервер BHS в группе RG2 повторно определяет маршрут в RG5 через RG1, RG3 и RG4.
7. Перед перемаршрутизацией сообщения в RG1 сервер BHS в RG2 отправляет информацию о нерабочем состоянии связи серверу BHS в RG1. Это соединение осуществляется через порт TCP 25 и состоит из команд EHLO и X-Link2state. (Для получения дополнительной информации об этих и других командах SMTP см. в лекции 7 курса "Переход к Microsoft Exchange Server 2003 и поддержка Outlook".)
8. Сервер BHS в группе RG1 немедленно соединяется с RGM в группе RG1 через порт TCP 691 и передает информацию о нерабочем состоянии связи.
9. RGM в группе RG1 немедленно распространяет эти данные среди остальных серверов Exchange Server 2003 в группе маршрутизации.
10. С использованием новой информации о состоянии связи BHS и RG1 определяет оптимальный маршрут к RG5 – через RG3 и RG4.
11. Перед направлением сообщения в 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, как это было в варианте с выходом из строя одной связи. Ниже приведены шаги, которые будут выполнены протоколом состояния связи.

1. Сервер BHS в RG1 устанавливает соединение с сервером BHS в группе RG3. Однако перед отправкой сообщения он сообщает серверу BHS в RG3 информацию о нерабочем состоянии связи между группами маршрутизации RG2 и RG4. Сервер BHS в группе RG3 пересылает эту информацию серверу RGM, который распространяет ее среди других серверов в группе маршрутизации.
2. Затем сервер BHS в группе RG1 отправляет сообщение серверу BHS в группе RG3. Сервер BHS в группе RG3 обнаруживает, что сообщение предназначено для группы RG4, осуществляет попытку установки соединения с сервером BHS в группе RG4, которая заканчивается неудачей. Сервер BHS присваивает связи состояние повторения попыток и осуществляет повтор попыток передачи через 60-секундные промежутки времени.
3. Если соединение установить не удается, связь помечается нерабочим состоянием, и передается соответствующее уведомление серверу RGM, который, в свою очередь, распространяет данную информацию среди других серверов в группе маршрутизации.
4. Сервер BHS в группе RG3 пытается определить новый маршрут отправки сообщения, принимая во внимание поступившую информацию. При вышедших из строя связях между группами RG2 и RG4 и группами RG3 и RG4 затраты на маршрутизацию сообщения в группу RG5 принимают значение Infine ("Бесконечность").
5. Если сумма затрат приняла значение Infinite, сообщение остается в очереди сервера BHS группы RG3, который осуществляет вызовы маршрутизации согласно настройкам вкладки Delivery (Доставка) окна свойств виртуального сервера SMTP, чтобы определить, стала ли связь доступной.
6. Когда связь снова переходит в рабочее состояние, сообщение соответствующим образом подвергается повторной маршрутизации. Если сообщение простаивает в очереди больше 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.