none
CAS, NLB Broadcast RRS feed

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

  • Добрый день. Досталась сеть. в сети есть VLAN 58 где microsoft сервисы. На CAS сервере две сетевые карты как и на MBX. одна сетевая карта(на CASах) смотрим на клиентов (vlan 58) Другая на mbx сервер (vlan 59).

    Запустив WireShark выяснилось что CAS +NLB подгружают сеть (все кто в vlan 58, до 54 мбит)

    Настройки NLB: Unicast

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


    1 сентября 2014 г. 18:41

Все ответы

  • Какой трафик вы имеете ввиду, клиентский, или сервер-сервер. И для чего такое разделение подсетей? Непонятна топология сети в части серверной части Exchange. Действительно, на MBX серверах, если они в массиве DAG, рекомендуется использовать 2 интерфейса - один для клиентского доступа, второй для репликации баз данных, но к CAS серверам эта рекомендация не относится. 

    Do not multiply entities beyond what is necessary

    2 сентября 2014 г. 4:51
  • Сетевые интерфейсы подключения пользователей CAS и MBX должны находится в одном VLAN.

    Интерфейс синхронизации NLB Cluster выделяется в отдельну сеть.

    Network Load Balancing Best practices

    Исключением является сеть репликации DAG.

    Planning for high availability and site resilience


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.


    2 сентября 2014 г. 7:33
    Модератор
  • Добрый день.

    NLB в режиме Unicast или Multicast всегда будут генерировать бродкаст нагрузку на всю подсеть клиентских подключений. Это связано со спецификой работы WNLB. Дело в том, что MAС адрес WNLB кластера не регистрируется ни на каком порту коммутатора и фактически коммутатор для данных пакетов превращается в хаб, то есть бродскатит весь трафик на всю подсеть. В свою очередь члены NLB кластера через отдельную подсеть общаются между собой на предмет того, кто будет обрабатывать трафик. Наличие отдельной сети для NLB синхронизации не является обязательным для режима Multicast, да и если быть честным то и в режиме Unicast все прекрасно работает. Вашу проблему можно решить следующим способом:

    • Выделить CAS сервера в отдельный VLAN.Сообщение от Oleg.Kovalenko, что CAS и MBX должны быть в одном VLAN не соответствует действительности. Главное чтобы CAS и MBX сервера могли спокойно общаться между собой.
    • Перевести NLB в режим IGMP Multicast. Требуется поддержка IGMP на коммутаторах, куда включены CAS сервера. Почитайте тут и тут. В данной схеме порты CAS серверов будут подписываться на Multicast рассылку и трафик на CAS Array будет бродкаститься только на подписанные порты.
    • Ну и самый дорогой это заменить Windows NLB на какой-то железный балансировщик.
    2 сентября 2014 г. 8:10
  • Спасибо, Sidorenko Andrey за исправление. 

    Самы простой вариант расположение сетевых интерфейсов Exchange в одном VLAN.

    Разделять интерфейсы CAS и MBX по VLAN имеет смысл, в том случае, если сервера разнесены по площадкам или ЦОДАМ. Как это реализовано в инфраструктуре Андрея. 

    В его случае сервера Exchange разнесны по различным площадкам с настроеной маршрутизацией по VLAN.

    Исключением является VLAN NLB растянутый на все площадки для обеспечения высокой доступности подключения пользователей.

    По вопросу нагрузки трафика на сетевой интерфейс NLB.

    В NLB есть критический уровень запросов и обьема трафика. При достижения 500 Mb/s NLB может не корректно начать обслуживать подключения. 


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    2 сентября 2014 г. 8:42
    Модератор
  • Насчет моей инфраструктуры, вы  абсолютно правы. но растянутый VLAN был создан как раз по причине того, что WNLB не умеет работать, когда сервера находятся в разных VLAN'ах.

    Однако у меня есть еще один наглядный пример где CAS сегмент выделен  в отдельный VLAN именно по причине того что NLB бродкастит. В момент построения Exchange данное решение было самым легким в настройке и удовлетворяет всем требованиям системы Exchange, а вернее им не противоречит.

    Идеальным решением вопроса Vitaliy_2012 конечно остается перевод NLB в режим IGMP Multicast, но как я уже писал выше необходима поддержка на сетевом оборудовании.

    2 сентября 2014 г. 9:03
  • Какой трафик вы имеете ввиду, клиентский, или сервер-сервер. И для чего такое разделение подсетей? Непонятна топология сети в части серверной части Exchange. Действительно, на MBX серверах, если они в массиве DAG, рекомендуется использовать 2 интерфейса - один для клиентского доступа, второй для репликации баз данных, но к CAS серверам эта рекомендация не относится. 

    Do not multiply entities beyond what is necessary


    У клиентов в outlook прописан сервак  mail.mycomp.com (10.10.3.10)
    10.10.3.10 это NLB

    c 10.10.3.11 по 15 - это сервера CAS и находятся в vlan 58

    AD, SCOM, SCCM и т.д. находятся в том же vlan (10.10.3.0/24)

    Получается:

     CAS имеет два интерфейса

    Ethernet 1 - с адресом 10.10.3.11 (vlan 58)

    Ethernet 2 - с адресом 10.10.5.11(vlan 59) для связи с mbx

    MBX имеет два интерфейса

    Ethernet 1 - с адресом 10.10.5.21 (vlan 59) для связи с cas

    Ethernet 2 - с адресом 172.16.0.1 (vlan 10) (для репликации БД)

    Планировалась двух ЦОДовая модель.
    3 сентября 2014 г. 9:35
  • CAS 

    Ethernet 1 - с адресом 10.10.3.11 (vlan 58) - обращение к MBX идет через эту сеть

    Ethernet 2 - с адресом 10.10.5.11(vlan 59) для связи с mbx - на мой взгляд сдесь ошибка. Эта сеть для NLB, через нее не идет обращение к MBX. Если оборудование поддерживает и есть возможность настроить Multicast, то это немного(~1%-5%) снизит нагрузку на оборудование. При использовании HLB смысла второго интерфейса не вижу.

    Если вы планируете в двух DC, то используйте балансировщики виртуальные или физические. 

    Citrix Netscaler VPX-10 или VPX-200  (около от 2000 до 5000 у) минимум по одному в DC. 

    При использовании HLB вам не надо будет разворачивать отдельно CAS сервера, и можно совместить роли.

    MBX имеет два интерфейса

    Ethernet 1 - с адресом 10.10.5.21 (vlan 59) для связи с cas - рекомендую это интерфейс включить в VLAN 58

    Ethernet 2 - с адресом 172.16.0.1 (vlan 10) (для репликации БД)

    ЗЫ. Если у вас уже развернута эта инфраструктура, то принципиально не вижу смысла ее  изменять. Если вы ее только планируете, то имеет смысл ее корректировать.


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    3 сентября 2014 г. 9:43
    Модератор
  • Насчет моей инфраструктуры, вы  абсолютно правы. но растянутый VLAN был создан как раз по причине того, что WNLB не умеет работать, когда сервера находятся в разных VLAN'ах.

    Однако у меня есть еще один наглядный пример где CAS сегмент выделен  в отдельный VLAN именно по причине того что NLB бродкастит. В момент построения Exchange данное решение было самым легким в настройке и удовлетворяет всем требованиям системы Exchange, а вернее им не противоречит.

    Идеальным решением вопроса Vitaliy_2012 конечно остается перевод NLB в режим IGMP Multicast, но как я уже писал выше необходима поддержка на сетевом оборудовании.


    Огромное спасибо за поддержку, и детализированное объяснение. Вынести в отдельный VLAN для NLB, наверное так в будущем и сделаем. а временное решение будет IGMP Multicast.
    Если я правильно понял, кластер(nlb) и сами узлы(cas) должны находится в отдельном кластере ?
    3 сентября 2014 г. 9:56
  • Выше вариант расположения в двух DC. Имя точки подключения пользователей зависит от плана Name Space и версии HLB. 

    Вот всплыла правда. Вы только планируете инфраструктуру. ;)) Могу ошибаться. ;))

    Exchange 2013 не требуется использовать WinNLB для балансировки и не рекомендуется.

    Очень рекомендую использовать HLB или как минимум виртуальные балансировщики Citrix Netscaler VPX-10 или Citrix Netscaler VPX-200 (с возможность обновления на версию выше вводом нового ключа) .


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.

    3 сентября 2014 г. 10:03
    Модератор
  • CAS 

    Ethernet 1 - с адресом 10.10.3.11 (vlan 58) - обращение к MBX идет через эту сеть

    Ethernet 2 - с адресом 10.10.5.11(vlan 59) для связи с mbx - на мой взгляд сдесь ошибка. Эта сеть для NLB, через нее не идет обращение к MBX. Если оборудование поддерживает и есть возможность настроить Multicast, то это немного(~1%-5%) снизит нагрузку на оборудование. При использовании HLB смысла второго интерфейса не вижу.

    Если вы планируете в двух DC, то используйте балансировщики виртуальные или физические. 

    Citrix Netscaler VPX-10 или VPX-200  (около от 2000 до 5000 у) минимум по одному в DC. 

    При использовании HLB вам не надо будет разворачивать отдельно CAS сервера, и можно совместить роли.

    MBX имеет два интерфейса

    Ethernet 1 - с адресом 10.10.5.21 (vlan 59) для связи с cas - рекомендую это интерфейс включить в VLAN 58

    Ethernet 2 - с адресом 172.16.0.1 (vlan 10) (для репликации БД)

    ЗЫ. Если у вас уже развернута эта инфраструктура, то принципиально не вижу смысла ее  изменять. Если вы ее только планируете, то имеет смысл ее корректировать.


    MCITP, MCSE. Знание - не уменьшает нашей глупости. Все данные приведены в виде примера и не адаптированы для вашей системы. Выполнения командлетов и внесения изменений в систему, делаете ВЫ. Все вопросы по привязке примера к вашей ситуации или адаптации решения, рассматриваются, только через заявку или кейс в техническую поддержку.


    Она уже развернута. При указании на другой локации vlan 58 что-то нагрузило сеть, выяснилось что это NLB. В итоге номер vlan сменим, а на будущие особенность архитектуры учтем. 

    PS Планируется миграция со старой на новую архитектуру (Win2008R2 -> Win2012R2) (Exchange 2010 -> Exchange 2013 и т.д.)

    • Изменено Vitaliy_2012 3 сентября 2014 г. 11:02
    3 сентября 2014 г. 10:56