none
Балансировка между двумя SMTP коннекторами RRS feed

  • Общие обсуждения

  • Есть два Front-End сервера (на каждом по одному SMTP-коннетору), смотрящие в независимые каналы в интернет. Каким образом Back-End сервера организации будут использовать эти два канала, если у SMTP-коннекторов будет одинаковая стоимость? Будут ли оба канала использоваться наравне? Может ли произойти ситуация, когда один канал будет использоваться на 100%, а второй при этом будет простаивать? Если да, то как этого избежать?

    Другими словами как сделать так, чтобы оба канала использовались равномерно?

    23 января 2007 г. 16:13

Все ответы

  • Advanced Routing Configuration

    Configuring Connectors for Load Balancing

    If you want to configure a connector to load balance requests between two or more bridgehead servers, create a single connector with the desired address space, for example, * for an SMTP connector, and then assign two different Exchange servers and SMTP virtual servers as bridgehead servers. Routing chooses the bridgehead server at random and effectively load balances the requests that are sent through this connector. However, if a message reaches one of these bridgehead servers, and this server becomes unavailable, routing does not automatically choose the alternate route. Mail simply queues until this server becomes available. There is no rerouting among bridgehead servers once a message reaches the intended bridgehead server.

    Link state only contains a connector's state, and a connector is always considered available if one bridgehead server is available. If one bridgehead server becomes unavailable, routing still considers this connector a valid path and chooses randomly among the available bridgehead servers.

    23 января 2007 г. 17:27
  • а вот это http://www.osp.ru/win2000/2006/04/2618289/ вам поможет разобраться?
    24 января 2007 г. 0:44
  • magadaner, теоретически должно, но нужно бы точно знать вашу конфигурацию. Попробуйте ее описать.
    24 января 2007 г. 6:46
    Модератор
  • Cоздать "внешний" коннектор. В нем в качестве bridgehead servers указать frontend-сервера, а отправку "Use DNS to route"

    25 января 2007 г. 5:35
    Модератор
  • спасибо всем ;)
    29 января 2007 г. 10:59
  • а вы кнопочкой выразите спасибо ;) и вам помогло, и нам приятно
    30 января 2007 г. 1:48
  • Однако не совсем помогло

    В предложенных статьях описываются конфигурации, защищающие от падения одного из серверов exchange, а мне больше интересна ситуация, когда становится недоступен один из каналов интернет.

    Вот моя конфигурация: несколько Back-End серверов и два Front-End сервера. На каждом FE сервере по одному виртуальному SMTP серверу. У каждого FE организован выход в интернет через отдельный канал.

    Рассматривал два варианта:

    1. один SMTP-коннектор, в котором в качестве bridgehead-серверов прописаны оба FE

    2. два SMTP-коннектора одинаковой стоимости, в каждом из которых прописан один из FE. (вариант с разной стоимостью коннекторов пока не рассматриваю, т.к. есть необходимость равномерно загрузить оба интернет-канала)

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

    Мне необходимо сделать так, чтобы при нескольких неудачных попытках отправить почту сервер передавал бы ее другому, который способен ее отправить. И еще было бы неплохо сделать так, чтобы "мертвый" сервер временно не принимал почту для отправки до тех пор, пока не восстановится интернет-канал.

    Есть ли у Exchange какой-нибудь механизм, способный реализовать эту задачу?

    30 января 2007 г. 14:27
  • На мой взгляд стандартными средствами Exchange вам не обойтись.

    Вот описание роутинга Exchange 2003 http://technet.microsoft.com/en-us/library/bb123812.aspx Используется link state алгоритм. Но проблема в том, что link state относится только к линкам внутри организации Exchange! Причем прямым линкам, без учета транзитивных связей. Иначе говоря если сервер Exchange доступен по внутреннему интерфейсу, то на него почта роутится даже если внешний интерфейс в дауне. Аналогично для коннектора: если bridgehead сервер доступен, то почта роутится через коннектор. Соответственно если внешний интерфейс сервера не работает (прямо или косвенно), то почта копится в очереди.

    Возможно существует sink ,который может рероутить почту на другой сервер после, скажем, второй неудачной попытки отправки письма.

     

    Но вообще говоря задача наличия канала это не задача почтовой системы. Лучше перед FE серверами поставить что-то вроде Cisco-роутера, в него воткнуть обоих провайдеров и "умно настроить" - пусть эта железка решает куда трафик роутить.

    Можно предложить промежуточный вариант: подключить каждый FE к обоим провайдерам и на второго прописать маршрут по умолчанию с большим preference. Но такой вариант имеет ряд ограничений.

    31 января 2007 г. 5:34
    Модератор
  • Полностью согласен с sie, особенно в части этого:

    "Но вообще говоря задача наличия канала это не задача почтовой системы. Лучше перед FE серверами поставить что-то вроде Cisco-роутера, в него воткнуть обоих провайдеров и "умно настроить" - пусть эта железка решает куда трафик роутить."

    Exchange не умеет определять состояние канала(для внешних каналов), доступности серверов и в зависимости от этого делать рероутинг.

    На самом деле это плохо, потому что у меня случались ситуации, когда серверы были недоступны через одного провайдера и доступны через другого. Можно написать sink, а можно написать внешнюю программу, которая будет отслеживать состояние каналов и при падении одного, перенастраивать коннекторы через ADSI на другой канал. Но это изобретение велосипеда, железками на уровне трафика это нужно делать.

    Даже тупее можно сделать. Программа отслеживает количество файлов в папке c:\Program Files\Exchsrvr\Mailroot\vsi 1\Queue одного сервера и если количество файлов растет, то тупо перекидывать их в c:\Program Files\Exchsrvr\Mailroot\vsi 1\PickUp другого севера.

    Но это всего лишь мысль, называется заплаткой, но не решением проблемы.

     

     А если поднять NLB на FE серверах и сваливать SMTP коннектором с BE на NLB всю исходящую почту.

    http://www.internetaccessmonitor.ru/rus/products/articles/Load-Balancing-Exchange-Front-End-Servers/Load-Balancing-Exchange-Front-End-Servers.php

    Но от падения одного канала это не спасет.  

     

     

     

     

    31 января 2007 г. 8:22
    Модератор
  •  Pavel Nagaev написано:

    Exchange не умеет определять состояние канала(для внешних каналов), доступности серверов и в зависимости от этого делать рероутинг.

     

    если расширить Exch систему за рамки локальной организации - то можно -) и только средствами Exch обойтись, а что б обойтись именно средствами Exch без расширения - нужно "гасить" тот Exch на котором нет внешнего коннекта

    31 января 2007 г. 16:37
  • Сергей, а можно более подробно, на примере. Не совсем понятно, что Вы имеете ввиду.
    1 февраля 2007 г. 5:42
    Модератор
  • Мне представляется что можно сделать так - создать один коннектор с двумя бриджхед серверами. На каждом бриджхед сервере в случае падения канала (или недоступности смартхоста если используется) останавливается служба smtp. Соответственно вся почта пойдет через другой бриджхед сервер. Впринципе написать скрипт который проверяет со определенной периодичностью канал и останавливает службу не так уж и сложно. Ну и соответственно при появлении канала тот же скрипт службу поднимает
    1 февраля 2007 г. 6:37
  • Попробовал использовать Monitoring and Status, создал проверку SMTP очереди - если очередь хранится больше определенного времени, то серверу присваивается статус Critical. Однако даже со статусом Critical сервер продолжает принимать почту от пользователей и пытатется отправить ее в интернет. Почему так?

    Пошел дальше. В Notifications создал событие, которое при изменении статуса сервера в Critical запускает скрипт, который паузит службу SMTP. Добился того, что сервер перестает обслуживать пользователей. Однако остался вопрос - каким образом и по какому событию заново запускать службу SMTP?

    1 февраля 2007 г. 8:13
  • Время хранения очереди не очень правильный критерий. У меня в очередях наружу постоянно что-то висит.

    Это все не то. Ненадежно.

    1 февраля 2007 г. 9:54
    Модератор
  • Что нибудь такое, запускающееся с небольшим интервалом времени

    ping smarthost && net start | find "Simple Mail Transfer Protocol (SMTP)" >nul && goto end

    ping smarthost || net start | find "Simple Mail Transfer Protocol (SMTP)" >nul || goto end

    ping smarthost || net start | find "Simple Mail Transfer Protocol (SMTP)" >nul && net stop "Simple Mail Transfer Protocol (SMTP)"

    ping smarthost && net start | find "Simple Mail Transfer Protocol (SMTP)" >nul || net start "Simple Mail Transfer Protocol (SMTP)"

    :end

    Ну или вместо смартхост любой сервер интернета с высокой доступностью. Конечно лучше проверять достпность порта но вприницпе о состоянии канала пинг говорит досаточно однозначно

    1 февраля 2007 г. 10:03
  •  magadaner написано:

    Попробовал использовать Monitoring and Status, создал проверку SMTP очереди - если очередь хранится больше определенного времени, то серверу присваивается статус Critical. Однако даже со статусом Critical сервер продолжает принимать почту от пользователей и пытатется отправить ее в интернет. Почему так?

    Пошел дальше. В Notifications создал событие, которое при изменении статуса сервера в Critical запускает скрипт, который паузит службу SMTP. Добился того, что сервер перестает обслуживать пользователей. Однако остался вопрос - каким образом и по какому событию заново запускать службу SMTP?

     

    очередью очень не надежная проверка - ибо к реальной работоспособности канала практически не имеет отношения

     

    относительно надежен ping нескольких серверов , по результатам которого и принимается решение о "гашении\ поднятии" служб(ы).

    1 февраля 2007 г. 13:16
  • Есть идея. 

    Можно создать два SMTP коннектора и в случае падения одного из каналов увеличивать на его коннекторе стоимость соединения. Как можно программно поменять стоимость коннектора?

    А еще было бы интересно программным путем отслеживать количество сообщений в очереди. Может на основании этого параметра принимать решение о наличии канала? Мне кажется этот параметр будет поинтереснее чем время, в течении которого копится очередь.

    1 февраля 2007 г. 14:44
  •  magadaner написано:

    А еще было бы интересно программным путем отслеживать количество сообщений в очереди. Может на основании этого параметра принимать решение о наличии канала? Мне кажется этот параметр будет поинтереснее чем время, в течении которого копится очередь.

    Не опирайтесь вы на размеры очереди. Намного более правильный показатель - наличие/отсутствие пинга. Вот и проверяйте это. Один из варинатов cmd-шника уже предложен. Выполняйте его в шедулере на фронтенд серверах, создайте во всех бэкендах один коннектор с двумя фронтендами. Тогда система будет балансировать траффик и при этом будет достаточно отказоустойчивой

    Да, забыл добавить. Служба smtp в этом варианте на фронтендах должна быть в мануале, и данный cmd (либо другой скрипт, останавливающий или запускающий службу) должен отрабатывать на стартап системы 

    1 февраля 2007 г. 14:57
  • Есть идея. 

    Можно создать два SMTP коннектора и в случае падения одного из каналов увеличивать на его коннекторе стоимость соединения. Как можно программно поменять стоимость коннектора?

    А еще было бы интересно программным путем отслеживать количество сообщений в очереди. Может на основании этого параметра принимать решение о наличии канала? Мне кажется этот параметр будет поинтереснее чем время, в течении которого копится очередь.

    1 февраля 2007 г. 14:59
  • После того как отработает вышенаписанный батник SMTP сервис "мертвого" сервера остановится и перестанет принимать сообщения, но при этом в его очереди наверняка останутся неотправленные сообщения. Единственным способом как можно их отправить будет перемещение в PickUp другого сервера.Не очень хочется грубой силой лезть в каталог очереди "мертвого" сервера и перемещать сообщения на "живой". Если хотите, то у меня есть предубеждения не делать этого

    Гораздо корректнее смотрится вариант изменения стоимости коннектора, в результате чего почта автоматически перебрасывается на менее дорогой. А проверять очередь я хочу только из тех побуждений, что обе эти задачи можно будет выполнять в одном скрипте. Если вы мне покажите как используя батник можно манипулировать со стоимостью коннектора, то я буду рад.

    1 февраля 2007 г. 15:07
  •  magadaner написано:

    После того как отработает вышенаписанный батник SMTP сервис "мертвого" сервера остановится и перестанет принимать сообщения, но при этом в его очереди наверняка останутся неотправленные сообщения. Единственным способом как можно их отправить будет перемещение в PickUp другого сервера.Не очень хочется грубой силой лезть в каталог очереди "мертвого" сервера и перемещать сообщения на "живой". Если хотите, то у меня есть предубеждения не делать этого

    Гораздо корректнее смотрится вариант изменения стоимости коннектора, в результате чего почта автоматически перебрасывается на менее дорогой. А проверять очередь я хочу только из тех побуждений, что обе эти задачи можно будет выполнять в одном скрипте. Если вы мне покажите как используя батник можно манипулировать со стоимостью коннектора, то я буду рад.

    стоимость и адресное пространство меняется в атрибуте routingList - <имя сервера>/Configuration/Services/Microsoft Exchange/First Organization/Administrative Groups/First Administrative Group/Routing Groups/First Routing Group/Connections/<имя коннектора>

    1 февраля 2007 г. 18:20
  •  magadaner написано:

    Есть идея. 

    Можно создать два SMTP коннектора и в случае падения одного из каналов увеличивать на его коннекторе стоимость соединения. Как можно программно поменять стоимость коннектора?

    А еще было бы интересно программным путем отслеживать количество сообщений в очереди. Может на основании этого параметра принимать решение о наличии канала? Мне кажется этот параметр будет поинтереснее чем время, в течении которого копится очередь.

    количество сообщений в очереди не является показателем неработоспособности канала - подумайте об этом ибо если брать его за основу то вы просто зациклите систему на шаге изменения стоимости коннектора(ов) а так ... подсчет через wmi
    1 февраля 2007 г. 20:23
  •   magadaner, очень хорошо написал Вам Joker в самом начале о том, что резервирование каналов делается на уровне каналов. Это не функции SMTP сервера и протокола.

    Мне, например, совсем не нравится, чтобы у меня скрипты запускали и останавливали smtp сервера. Рано или поздно ружье на стене выстрелит.

    Железками, железками это делается.

     

    Pavel, клевые скрипты. Я давно уже подобным не занимался.

    2 февраля 2007 г. 5:34
    Модератор
  •  Pavel Nagaev написано:

    Pavel, клевые скрипты. Я давно уже подобным не занимался.

    Да это и не скрипт собственно. Самое главное - работает

    А насчет того чтобы скрипты запускали и останавливали сервисы... В случае с эксч 2003 на контроллере домена так и рекомендуется делать при стартапе и шатдауне. Так что я не вижу здесь криминала. Хотя повторюсь, конечно же вопрос решается железками. Просто если их нет, то при определенном допущении задача все же решается

    2 февраля 2007 г. 7:08
  •  Pavel Nagaev написано:
    Железками, железками это делается.

    На железки денег нет, вот и ищу другой выход

    2 февраля 2007 г. 8:13
  • Тогда предлагаю отказаться от FE на пограничных серверах, а сделать Exchange сервера внутренними, настроить их на отправку почты наружу (через firewall и NAT), соответственно настроить для них DNS для разрешения интернетовских адресов и прописать маршрут по умолчанию у одного Exchange-сервера на один пограничный сервер, у второго на другой, чтобы по умолчанию они отправляли почту через разных провайдеров. Теперь делаем резервироание. Пограничные сервера настроить как firewall-ы (NAT). Затем на пограничном сервере прописываем два маршрута по умолчанию. Один с меньшей preference на одного (основного) провайдера, а другой с большей preference на второго (резервного для этого сервера) провайдера. Если нет возможности подключить второго провайдера непосредственно к пограничному серверу, то вместо него прописываем маршрут на внутренний интерфейс другого пограничного сервера (он будет как промежуточный маршрутизатор для выхода на резервный канал). Так как маршруты по умолчанию будут переключаться только тогда, когда система определит падение канала, а это не все варианты недоступности интернета через провайдера, то можно применить скрипт аналогичный приведенному выше, который запускается раз 15-30 минут, проверяет доспупность заданных сайтов и при необходимости убирает маршрут по умолчанию на основного провайдера (переключая систему на резервный маршрут по умолчанию) или возвращает его на место.
    2 февраля 2007 г. 13:08
    Модератор