Применимо к: Exchange Server 2010 SP1
Последнее изменение раздела: 2011-02-01
При наличии нескольких транспортных серверов-концентраторов в организации система Exchange автоматически распределяет почтовый трафик между всеми транспортными серверами-концентраторами. Распределение нагрузки является успешным и нагрузка распределяется равномерно, если все серверы доступны. Тем не менее, когда один или несколько серверов недоступны, нагрузка может распределяться неравномерно между оставшимися серверами, особенно если организация распределена между несколькими сайтами Служба каталогов Active Directory.
В систему Microsoft Exchange Server 2010 с пакетом обновления 1 (SP1) были внесены некоторые улучшения в механизм принятия решений по распределению нагрузки между транспортными серверами-концентраторами.
Необходимы сведения о задачах управления, связанных с маршрутизацией сообщений? См. раздел Управление маршрутизацией сообщений.
Содержание
Поведение в окончательной первоначальной версии (RTM) Exchange Server 2010
Улучшения Exchange 2010 с пакетом обновления 1 (SP1)
Поведение в окончательной
первоначальной версии (RTM) Exchange Server 2010
В окончательной первоначальной версии (RTM) Exchange 2010 при необходимости маршрутизации транспортным сервером нескольких сообщений в одно место назначения он в первую очередь определяет следующий прыжок для этих сообщений. Если для этого следующего прыжка существует несколько целевых серверов, то транспортный сервер равномерно балансирует нагрузку на подключение, используемое для доставки сообщений, между целевыми серверами методом циклического перебора, имеющимся в улучшенной службе доменных имен (DNS). Например, рассмотрим топологию, в которой существует два сайта Служба каталогов Active Directory с тремя транспортными серверами-концентраторами на каждом из них (как показано на следующем рисунке). Когда транспортному серверу-концентратору на сайте А, например Hub02, необходимо отправить сообщения на сайт Б, сайт Б будет следующим прыжком для этих сообщений. На этом прыжке существует три возможных цели: Hub04, Hub05 и Hub06. Затем сервер равномерно распределит число подключений между этими тремя целями (как показано на следующем рисунке). В результате этого действия сообщения равномерно распределяются между подключениями с течением времени.
Подобным образом транспортные серверы-концентраторы на сайте Site B будут равномерно распределять число сообщений, отправляемых получателям на сайте Site A, между серверами Hub01, Hub02 и Hub03. Кроме того, так как сервер Edge01 подписан на сайт Site A, целями для следующего прыжка сообщений, отправляемых в Интернет, будут серверы Hub01, Hub02 и Hub03.
Проблема возникает, если один или несколько серверов на следующем прыжке оказываются недоступными. Например, предположим, что сервер Hub04 на сайте Site B недоступен для планового обслуживания. Серверы на сайте Site A не поддерживают состояние доступности каждого сервера на сайте Site B. Они будут распределять нагрузку, предназначенную для сайта Site B, между тремя транспортными серверами-концентраторами на этом сайте. Однако приблизительно одна треть этих подключений будет отправлена на сервер Hub04, но завершится ошибкой. Эти подключения будут переведены при сбое на следующий доступный сервер, и один из транспортных серверов-концентраторов на сайте Site B будет обрабатывать значительно больший объем нагрузки по сравнению с другим сервером (как показано на следующем рисунке).
Такое нежелательное поведение может наблюдаться в тех случаях, когда существует недоступный сервер на следующем прыжке, имеющем обычно более двух целей. Следующим прыжком может быть другой сайт Служба каталогов Active Directory (как показано в предыдущем примере) или соединитель, имеющий несколько транспортных серверов-концентраторов, помеченный как исходный сервер (например, соединитель отправки на подписанный пограничный транспортный сервер в топологии, приведенной на предыдущих рисунках).
Такой случай не является проблемным при отправке почты с серверов почтовых ящиков. Служба отправки почты обнаружит недоступные транспортные серверы-концентраторы на сайте и не будет доставлять почту на эти серверы. В предыдущем примере, несмотря на возможность увеличения нагрузки одного из транспортных серверов-концентраторов на сайте Б, при распределении трафика между сайтами нагрузка, создаваемая серверами почтовых ящиков на сайте Б, равномерно распределяется между серверами Hub05 и Hub06.
Улучшения Exchange 2010 с
пакетом обновления 1 (SP1)
Для решения проблемы, описанной в предыдущем разделе, в систему Exchange 2010 с пакетом обновления 1 (SP1) добавлен новый компонент, который называется Выбор работоспособного сервера. Компонент выбора работоспособного сервера сохраняет список недоступных серверов. Этот список используется улучшенной службой доменных имен (DNS) для фильтрации недоступных серверов при применении алгоритма циклического перебора для балансировки нагрузки. Чтобы продемонстрировать, как компонент выбора работоспособного сервера помогает сбалансировать нагрузку, рассмотрим проблематичную ситуацию, показанную на предыдущем рисунке. В системе Exchange 2010 с пакетом обновления 1 (SP1) расширенная служба DNS сначала составляет список возможных целей на следующем прыжке — сайте B, а затем отправляет запрос на фильтрацию этого списка в компонент выбора работоспособного сервера. Компонент выбора работоспособного сервера укажет в ответе, что сервер Hub04 для следующего прыжка на сайте Site B неработоспособен. Расширенная служба DNS удалит сервер Hub04 из списка возможных целей для следующего прыжка на сайте B и выполнит балансировку нагрузки путем циклического перебора только для серверов Hub05 и Hub06 (как показано на рисунке).
Выбор работоспособного сервера
В упрощенном виде компонент выбора работоспособного сервера отслеживает предположительно неработоспособные серверы, чтобы исключить их из процесса балансировки нагрузки методом циклического перебора. Компонент выбора работоспособного сервера определяет в качестве неработоспособного тот сервер, на который подключение возвращает любые коды ошибок Windows Sockets (Winsock).
Для каждого неработоспособного сервера компонент выбора работоспособного сервера сохраняет следующие сведения:
- IP-адрес сервера;
- количество повторных попыток;
- время последней попытки.
Поведение при выполнении повторной попытки
Когда сервер помечен как неработоспособный, компонент выбора работоспособного сервера будет повторно устанавливать подключения к этому серверу, чтобы определить момент возобновления работы сервера. Компонент выбора работоспособного сервера использует следующие параметры для определения частоты повторных подключений к неработоспособному серверу:
- QueueGlitchRetryInterval и
QueueGlitchRetryCount Эти параметры определяют
количество и периодичность повторных попыток компонента выбора
работоспособного сервера подключиться к определенному серверу после
первой пометки его как неработоспособного. Эти параметры
настраиваются в файле EdgeTransport.exe.config. Значениями по
умолчанию для этих параметров являются 1 минута и 4 повторных
попытки. Эти значения указывают, что в конфигурации по умолчанию
будет выполнено четыре повторных попытки подключения к
неработоспособному серверу с интервалом в одну минуту.
- TransientFailureRetryInterval и
TransientFailureRetryCount Если
неработоспособный сервер недоступен, то эти параметры используются
компонентом выбора работоспособного сервера для определения частоты
выполнения следующего набора повторных попыток. Эти параметры
настраиваются для каждого транспортного сервера. Значениями по
умолчанию являются 5 минут (10 минут для пограничного транспортного
сервера) и 6 повторных попыток. Эти значения указывают, что в
конфигурации по умолчанию после первых четырех минут будет
выполнено шесть повторных попыток подключения к неработоспособному
серверу с интервалом в пять минут.
-
OutboundConnectionFailureRetryInterval Если
неработоспособный сервер недоступен, компонент выбора
работоспособного сервера продолжит повторно устанавливать
подключение с частотой, указанной в этом параметре. Этот параметр
настраивается для каждого транспортного сервера. Значением по
умолчанию является 10 минут (30 минут для пограничного
транспортного сервера). Это значит, что в конфигурации по умолчанию
после первых 34 минут подключение к неработоспособному серверу
будет повторно выполняться через каждые 10 минут.
Пошаговые инструкции по настройке этих параметров см. в разделе Настройка интервалов повторной отправки, повторной передачи и окончания срока действия сообщения.
При наступлении времени повторного подключения компонент выбора работоспособного сервера разрешает выполнение только одной попытки подключения к неработоспособному серверу. При успешном подключении компонент исходящего потока почты SMTP отправит в компонент выбора работоспособного сервера уведомление об успешной установке подключения. На этом этапе компонент выбора работоспособного сервера удаляет сервер из списка неработоспособных серверов.
Выбор работоспособного сервера и теневая избыточность
Компонент теневой избыточности службы транспорта включает в себя функцию подтверждения соединения. Подтверждение соединения — это простое подключение SMTP, используемое для запроса сведений о состоянии сообщений, ранее отправленных на целевой сервер. Выполнение фильтрации компонентом выбора работоспособного сервера не предотвратит установку подключений для подтверждения соединения диспетчером теневой избыточности. Если на сервере существуют теневые копии сообщений, отправленных на неработоспособный сервер, то диспетчер теневой избыточности будет пытаться устанавливать подключения для подтверждения соединения к этому серверу. При успешном подключении для подтверждения соединения к неработоспособному серверу этот целевой сервер будет немедленно удален из списка неработоспособных серверов компонентом выбора работоспособного сервера.
Дополнительные сведения о теневой избыточности и подтверждении соединения см. в разделе Общие сведения о теневой избыточности.
Диагностические сведения
В системе Exchange 2010 с пакетом обновления 1 (SP1) журналы подключений содержат диагностические сведения, используемые компонентом выбора работоспособного сервера и улучшенными функциями балансировки нагрузки. При добавлении сервера в список неработоспособных серверов компонентом выбора работоспособного сервера это событие записывается в журнал подключений. Чтобы найти это событие, выполните поиск по фразе MarkedUnhealthy в журнале подключений. В строке, содержащей эту фразу, можно найти следующие сведения:
- IP-адрес целевого узла;
- полное доменное имя (FQDN) целевого узла;
- полученный код ошибки Winsock;
- состояние:
MarkedUnhealthy
- текущее число ошибок;
- время следующей попытки.
С помощью этой записи можно определить причину ошибки путем оценки кода ошибки Winsock. Полный список кодов ошибок Winsock и их определения см. в разделе Коды ошибок Windows Sockets.
Также можно определить число сбоев повторного подключения и время следующей запланированной повторной попытки подключения к целевому серверу путем анализа полей Current Failure Count и Next Retry Time.
Чтобы иметь возможность просматривать диагностические сведения, на транспортных серверах необходимо включить функцию ведения журнала подключений. Функция ведения журнала подключений отключена по умолчанию на транспортных серверах-концентраторах и пограничных транспортных серверах. Дополнительные сведения о настройке ведения журнала подключений см. в разделе Настройка ведения журнала подключений.
Балансировка сетевой нагрузки
Windows или сторонние решения балансировки нагрузки с помощью
транспортных серверов
Как говорилось выше в этом разделе, Exchange 2010 автоматически распределяет трафик сообщений внутри организации между пограничным транспортным сервером, транспортным сервером-концентратором и серверами почтовых ящиков с помощью расширенной службы DNS. Однако эта функция не выполняет балансировку нагрузки для сообщений, полученных от источников, отличных от Exchange, например внешних почтовых серверов, сторонних решений защиты от вирусов и нежелательной почты, всех внутренних почтовых серверов за пределами организации Exchange, бизнес-приложений и почтовых клиентов, использующих протоколы POP или IMAP.
При наличии одного или нескольких перечисленных источников балансировку входящего SMTP-трафика можно выполнять с помощью единого пространства имен SMTP (например, smtp.contoso.com), распределяющего внешние сообщения электронной почты между транспортными серверами организации. Поддерживаются как балансировка сетевой нагрузки (NLB) Windows, так и аппаратные решения балансировки нагрузки от сторонних поставщиков. Список подсистем балансировки нагрузки, протестированных поставщиком и проверенных корпорацией Майкрософт на соответствие требованиям Exchange 2010, см в разделе Развертывание подсистемы балансировки нагрузки Microsoft Unified Communications.
 Важно! |
|---|
| Обработка трафика сообщений между серверами Exchange в организации с помощью решения балансировки нагрузки не поддерживается. Необходимо исключить трафик сообщений между серверами Exchange из всех решений балансировки нагрузки, развертываемых в существующей среде. |
Балансировка нагрузки входящих сообщений Интернета между пограничными транспортными серверами
Одной из наиболее распространенных ситуаций является обработка входящих сообщений из Интернета. Для распределения нагрузки между пограничными транспортными серверами необязательно развертывать решение балансировки нагрузки. Это можно сделать с помощью циклического перебора DNS и записей обмена электронной почтой (записи MX) с таким же значением предпочтения (как показано на рисунке).
При использовании балансировки сетевой нагрузки Windows или аппаратного решения балансировки нагрузки для распределения входящих сообщений Интернета необходима публикация отдельной записи MX, указывающей на выбранное решение. Подсистема балансировки нагрузки распределяет входящие сообщения между всеми пограничными транспортными серверами в списке ее конфигурации (как показано на рисунке).
Балансировка нагрузки для сообщений, полученных от источников, отличных от Exchange, между транспортными серверами-концентраторами
Exchange 2010 использует соединители получения для приема входящих сообщений. По умолчанию сообщение электронной почты, полученное транспортным сервером-концентратором Exchange 2010 с помощью SMTP через порт 25 протокола TCP, обрабатывается соединителем получения, установленным по умолчанию.
По умолчанию при отправке сообщений электронной почты клиентом POP или IMAP на транспортный сервер-концентратор Exchange 2010 используется порт 587 протокола TCP. Это значит, что сообщения электронной почты, отправленные клиентами POP или IMAP, обрабатываются отдельным соединителем получения, являющимся клиентским соединителем получения по умолчанию.
Для размещения решения балансировки нагрузки перед транспортными серверами-концентраторами необходимо создать отдельный соединитель получения и убедиться, что балансировка нагрузки выполняется только для трафика, обрабатываемого этим соединителем. Этого можно достичь, добавив дополнительный IP-адрес на транспортный сервер-концентратор и связав его с новым соединителем получения. Кроме того, необходимо отключить параметр Проверка подлинности сервера Exchange на соединителе получения, чтобы исключить прохождение через него трафика Exchange. На следующем рисунке показана конфигурация, в которой подсистема балансировки нагрузки используется для распределения сообщений, полученных от клиентов POP3 или IMAP4 и SMTP-серверов, отличных от Exchange, между двумя транспортными серверами-концентраторами.
Балансировка сетевой нагрузки Windows
Балансировка сетевой нагрузки Windows — это наиболее распространенная программная подсистема балансировки нагрузки, используемая для серверов Exchange. Далее перечислены некоторые ограничения по развертыванию балансировки сетевой нагрузки Windows с помощью транспортных серверов-концентраторов Exchange 2010.
- Балансировка сетевой нагрузки Windows не может использоваться
на сервере Exchange, на котором совместно работают роли
транспортного сервера-концентратора и сервера почтовых ящиков и
сервер является членом группы обеспечения доступности баз
данных.
Это связано с тем, что функция балансировки сетевой нагрузки Windows несовместима со службой отказоустойчивого кластера Windows. При использовании группы обеспечения доступности баз данных Exchange 2010 и необходимости использовать балансировку сетевой нагрузки Windows роли транспортного сервера-концентратора и сервера почтовых ящиков должны быть установлены на отдельных компьютерах. Кроме того, балансировка сетевой нагрузки Windows влияет на маршрутизацию сообщений, если член группы обеспечения доступности баз данных и роль транспортного сервера-концентратора совместно работают на одном сервере. Дополнительные сведения см. в разделе Сосуществование ролей транспортного сервера-концентратора и сервера почтовых ящиков при использовании групп обеспечения доступности баз данных.
- Не рекомендуется включать более восьми транспортных
серверов-концентраторов в массив, для которого балансировка
нагрузки выполняется с помощью подсистемы балансировки сетевой
нагрузки Windows. Для балансировки нагрузки более чем на восьми
транспортных серверах-концентраторах необходимо развертывание двух
аппаратных решений.
- Балансировка сетевой нагрузки Windows не обнаруживает простои в
работе служб.
Она обнаруживает простои только в работе серверов по IP-адресу. Если в работе службы передачи Exchange происходит сбой, но сервер по-прежнему работает, подсистема балансировки сетевой нагрузки Windows не обнаруживает неполадку и осуществляет маршрутизацию входящих сообщений электронной почты на этот транспортный сервер-концентратор. Администратору необходимо вручную удалить простаивающий транспортный сервер-концентратор из пула балансировки нагрузки.
- Конфигурация подсистемы балансировки сетевой нагрузки Windows
может привести к переполнению портов и перегрузке сетевой
инфраструктуры.
Это связано с тем, что балансировка сетевой нагрузки Windows разработана таким образом, чтобы одновременно доставлять все входящие клиентские пакеты на все порты коммутатора. Хотя такое поведение позволяет подсистеме балансировки сетевой нагрузки Windows обеспечивать высокую пропускную способность, оно может привести к высокой занятости коммутатора.
Дополнительные сведения о настройке балансировки сетевой нагрузки Windows см. в разделе Настройка балансировки сетевой нагрузки Windows для транспортных серверов-концентраторов.
Аппаратное решение балансировки нагрузки
Для балансировки нагрузки трафика сообщений, не относящихся к Exchange, для девяти и более транспортных серверов-концентраторов требуется более масштабируемое решение балансировки нагрузки. Существуют надежные программные решения балансировки нагрузки, однако аппаратные решения обеспечивают большую емкость.
В отличие от подсистемы балансировки сетевой нагрузки Windows, которая обнаруживает только простои сервера по IP-адресу, аппаратную подсистему балансировки нагрузки можно настроить для определения сбоя транспортной службы Exchange и маршрутизации входящих сообщений электронной почты на другие транспортные серверы-концентраторы без ручного вмешательства.
Подробные инструкции по настройке аппаратного решения балансировки нагрузки см. в разделе Настройка аппаратной балансировки нагрузки для транспортных серверов-концентраторов.