Exchange Server and Network Load Balancing

by Arman Obosyan 11. January 2011 08:47

Как вы наверное слышали (знаете) что в Exchange 2010 был изменен механизм работы Client Access Server (CAS, сервер клиентского доступа) и теперь Outlook MAPI трафик до серверной роли Mailbox проходит через CAS, что делает данную роль более важной чем в ранних версиях Exchange Server, в связи с этим балансировка нагрузки на роль сервера клиентского доступа становится актуальней более чем в ранних версиях. Я постараюсь выделить несколько моментов связанных с балансировкой нагрузки роли Client Access Server.

Как правило балансировка нагрузки нам нужна для следующих направлений:

  • Трафик из внутренней сети
  • Трафик от внешней сети (Интернет)
  • Трафик от других серверов клиентского доступа (прокси)

Балансировка нагрузки может осуществляться разными способами соответствия (Affinity), это способы связи клиентов с сервером, у нас имеется;

  • Existing Cookies or HTTP Headers (Существующие файлы Cookie или заголовки HTTP)
  • Load Balancer Created Cookie (Файл Cookie, созданный подсистемой балансировки нагрузки)
  • SSL Session ID (Идентификатор сеанса SSL)
  • Source IP (Исходный IP-адрес)
  • No Affinity (Отсутствие соответствия)

Важно учитывать то что поддержка разного рода соответствия зависит от типа используемого решения (и/или устройства) по балансировки нагрузки.

Из решения построения балансировки нагрузки серверов клиентского доступа;

  • DNS Round Robin
  • Software Load Balancer
  • Reverse Proxy Solutions
  • Hardware Load Balancer

Расмотрим их поближе,

Основные преимущества DNS Round Robin являются его низкая стоимость (точнее никакой стоимости) но к сожалению его применение ограничивается в очень небольших реализациях и для тестовых лабораторий. Простая имплементация позволяет прописать нам несколько узлов на одно общее имя, например если у нас есть два сервера клиентского доступа, зарегистрировано в DNS, “А” записи таким образом

mail.lab.postmaster.ge 10.10.10.11
mail.lab.postmaster.ge 10.10.10.12

Первый запрос возвращает IP-адрес 10.10.10.11, второй запрос возвращает 10.10.10.12  а третий запрос возвращает нам снова 10.10.1.11 и так будет продолжаться по кругу. Одним из основных ограничений (минусов) это то что не поддерживается ни один из методов Affinity (сходства). Например при первом входе на mail.lab.postmaster.ge веб-браузер будет использовать IP-адрес который ему вернет DNS-сервер, при получении записи она кэширует, веб-браузер будет пытаться достучаться до сервера даже если он недоступен до истечения срока действия кэша (как правило 30 минут) также после истечения срока действия кэша при следующем обращении DNS вернет новый IP (следующий в списке) клиентского доступа это приведет к потере всех данных состояния и сессия теряется. DNS перебор в итоге не содержит какого-либо механизма проверки работоспособности или удаления нерабочих узлов. Далее мы не будем рассматривать DNS Round Robin в качестве механизма балансировки.

Под Software Load Balancer как правило подразумевают Windows Network Load Balancing, WNLB является частью операционной системы Windows Server. На практике без заморочек можно объединить 8 узлов (в теории до 32 узлов). Из недостатков стоит отметить что подсистема WNLB не обнаруживает простои в работе служб, она обнаруживает только простои в работе серверов по IP-адресу. Это значит, что если в работе определенной веб-службы, например Outlook Web App, произошёл сбой, но сервер по-прежнему работает (пингуется!), то подсистема WNLB не обнаружит неполадку и будет направлять запросы на этот сервер клиентского доступа. Администратору необходимо вручную удалить простаивающий сервер клиентского доступа из пула балансировки нагрузки, конечно во избежание таких проблем можно использовать (нужно!) Microsoft Operation Manger . WNLB также может приводить к переполнению портов и перегрузке сетевой инфраструктуры, так как балансировка сетевой нагрузки Windows обеспечивает соответствие (Affinity) для клиентов только с помощью исходного IP-адреса (source IP), решение будет неэффективным если в нем используется пул исходных IP-адресов небольшого размера, это может происходить при использовании пула исходных IP-адресов из удаленной подсети или в случае применения преобразования сетевых адресов (NAT) в организации. WNLB поддерживает Source IP (Исходный IP-адрес) режим и в отдельном массиве серверов может использовать файлы Cookie.

Из других недостатков нужно отметить то что если вы пытаетесь настроить сервер все-в-одном, роли CAS/HUB/MBX+DAG то необходимо использовать аппаратные решения балансировки нагрузки для клиентского доступа так как WLNB и Windows Cluster не могут сосуществовать на одном сервере.

Также стоит отметить что Microsoft более не рекомендует использовать Windows Network Load Balancing, это уже не является рекомендуемым решением,

How Outlook connects to Exchange 2010 Client Access ServerHow Outlook connects to Exchange 2010 Client Access Server

более подробно вы можете посмотреть в полной презентации Tech-Ed Europe, How Outlook connects to Exchange 2010 Client Access Server

Решения с обратным прокси-сервером (Reverse Proxy), как правило используется для балансировки нагрузки серверов публикуемых в интернет, тут используются продукты Microsoft Forefront Threat Management Gateway (TMG) и Forefront Unified Access Gateway (UAG) который является рекомендуемым решением.

Обратным прокси-сервер позволяет выполнять балансировку нагрузки служб Exchange Server публикуемых в интернет, поддерживается балансировк�� нагрузки на основе файлов Cookie, обратный прокси-сервер считывает и изменять данные в HTTP потоке. При использовании SSL обратный прокси-сервер расшифровывает трафик и создает файл Cookie в потоке, но такое решение не работает если используется проверка подлинности наличием клиентского сертификата для доступа к серверу Client Access (CAS).

Аппаратное решение балансировки нагрузки (Hardware Load Balancer) Аппаратные подсистемы балансировки нагрузки могут быть настроены на балансировку нагрузки различными способами, как правило все они поддерживают все способы соответствия (Affinity) связи клиентов с серверами, как один из простых методов настройки аппаратных подсистем балансировки нагрузки является создание списка резервных методов обеспечения соответствия, которые будут применяться балансером, в первую очередь применять соответствие файлам Cookie, затем соответствие идентификатору сеанса SSL и исходному IP-адресу. Также аппаратные решения поддерживают передачу очень большого объема трафика и другие примочки от производителя.
Наиболее распространенными решениями Hardware Load Balancer являются BIG-IP (компании F5), NetScaler (от Citrix), Application Control Engine (ACE) от CISCO и другие, полный список протестированных устройств производителями и рассмотренных компанией Microsoft для работы с Exchange 2010 вы можете посмотреть тут Microsoft Unified Communications Load Balancer Deployment,

Недавно выше упомянутый список пополнила и компания Barracuda Networks c устройствами балансировки нагрузки серии Load Balancer 340, 440, 640 моделей. Barracuda Networks хорошо зарекомендовала себя на Грузинском рынке своими устройствами фильтрации спама Spam & Virus Firewall, в мою тестовую лабораторию попало одно из устройств Load Balancer которую любезно предоставила компания Orient-Logic, партнер Barracuda Networks в Грузии.

Во второй части я расскажу вам подробней о Hardware Load Balancer решении от компании Barracuda Networks

 

to be continued…

Comments (4) -

Sandro Galdava
Sandro Galdava Georgia
1/11/2011 1:48:26 PM #

"Также стоит отметить что Microsoft более не рекомендует использовать Windows Network Load Balancing, это уже не является рекомендуемым решением" < это меня немного удивило.
Спасибо за познавательный пост.


P.S. Только после вчерашнего я догодался почему у тебя спамфильтром стоит 20+22 ;)

Arman Obosyan
Arman Obosyan Georgia
1/11/2011 2:01:41 PM #


...да порой 42 это единственный ответ и решение всех проблем

kkvkkv
kkvkkv Russia
4/13/2011 8:52:40 AM #

А когда ждать to be continued… ?

Arman Obosyan
Arman Obosyan Georgia
4/21/2011 5:03:24 PM #

ждем обновленную версию, как только так сразу отпишусь

Comments are closed

© 2008-2012, Arman Obosyan, Postmaster.GE
Powered by BlogEngine.NET 2.6.0.18
Hosted on Windows Azure and IIS8

About the author

Arman Obosyan is an experienced IT Pro. with over 17+ years work experience in Information Technologies sector.

Certified since 2003 year, passed following certifications MCP, MCSA, MCSE, MCTS, MCITP, Exin ITIL and VMware Certified Professional (VCP)

In 2010 Was awarded a Microsoft Most Valuable Professional (MVP)

--------

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent anyone else's view in any way, including those of my employer.



Live Trafic

 

Calendar

<<  October 2017  >>
MoTuWeThFrSaSu
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

View posts in large calendar

TextBox