none
Имя NLB кластера и фермы терминальных серверов RRS feed

  • Вопрос

  • Добрый день! ОС везде Windows Server 2008 R2 Standart. Стоит задача настроить ферму терминальных серверов RDSH (имена хостов TS1, TS2) с выделенным брокером RDCB, а по совместительству еще и RDWA (имя хоста CB) и включенной балансировкой NLB. Вопрос такой - должно ли (может ли) совпадать имя фермы RDSH и NLB кластера? С технологией RDS (фермы, брокеры и т.д.) и NLB столкнулся впервые, не пинайте сильно :) 
    22 апреля 2013 г. 13:51

Ответы

  •  обеспечив максимальную отказоустойчивость и возможность масштабирования.  

    1. Надо более четко описать что для вашей ситуации "отказоустойчивать". Если ваши 100 пользователей могут перебиться пару часов без Dynamics AX  2009, то никаких HA и кластеров вам не нужно.

    2. Выделенный брокер может понадобиться только если у вас число одновременных пользователей будет измеряться тысячами.

    Поэтому скорее всего вам подойдет простейшая (и для пользователей, и для сопровождения, и по цене) конфигурация: развернуть на все три сервера RDSH, на один из них брокер и сделать DNS RR.

    Дополнительно:

    1. RDWA я бы не стал делать на R2, если только на 2012

    2. По официальным тестам на одном сервере уживается от 100 до 150 одновременных терминальных сессий - дальше пользователи начинают испытывать задержки независимо от ресурсов сервера.


    Сазонов Илья http://isazonov.wordpress.com/

    24 апреля 2013 г. 9:44
    Модератор

Все ответы

  • Добрый день.

    Если в вашей конфигурации будет Connection Broker то наличие NLB как минимум спорно.

    RDCB нагрузку на RDSH членов фермы распределит и без NLB.

    Вот статья на эту тему

    Лучше рассмотрите возможность кластеризации роли RDCB для обеспечения высокой доступности.

    23 апреля 2013 г. 2:51
  • Статью видел, читал. Но совершенно согласен с одним из комментариев к нем:

    "

    При использовании,DNS Round Robin, если сервер упал, и dns выдал ip упавшего сервера то в зависимости от времени кэширования возникает задержка с подключением к терминальным службам при использовании NLB такого эфекта не наблюдается. Можно конечно время кэширования dns записи поставить в 0, это конечно скрашивает ситуацию, за исключением того что пользователю надо догадаться не ждать установления соединения с терминалом и переподключиться. А в остальном согласен, NLB должен обязательно работать ВМЕСТЕ сonnection brocker и только для распределения и организации отказоустойчивости первичных подключений. Не понимаю что вам не понравилось в этой фразе “Using NLB with Terminal Services offers the benefits of increased availability, scalability, and load-balancing performance, as well as the ability to distribute a large number of Terminal Services clients over a group of terminal servers”. Всё так и происходит. Моё мнение что NLB лучше использовать, чем DNS round robin для распределения первичных подключений.

    "

    В  качестве первоначальной настройки сейчас как раз и используется  DNS RR. Кстати, вот цитата из статьи Technet Magazine

    http://technet.microsoft.com/ru-ru/magazine/hh551147.aspx

     "

    Существует два варианта. В первом для распределения подключений используется циклическое обслуживание DNS (round-robin DNS). Это простое решение, но механизм циклического обслуживания DNS не в состоянии обнаруживать отказы серверов и продолжает направлять пользователей на недоступный сервер.

    Более подходящее решение развертывание службы балансировки сетевой нагрузки (NLB) на каждом узле RDSH. В отличие от циклического обслуживания DNS, механизм NLB умеет выявлять недоступные узлы и перенаправляет пользователей только на доступные узлы

    "

    Собственно, это и привело к решению использовать NLB..

    23 апреля 2013 г. 4:46
  • Round-Robin как минимум проще в настройке.

    В вашем случае NLB будет только балансировать запросы к брокеру.

    И в первом и втором варианте "перенаправлять пользователей" будет брокер.

    По поводу имен:

    Имя фермы должно совпадать с ip адресом NLB. Имя кластера использовать не надо вообще в такой реализации

    Привожу цитату отсюда A full Internet name is not needed when using NLB with Terminal Services.

    23 апреля 2013 г. 5:03
  • Самое правильное решение - самое простое. Любую новую сущность и новую сложность надо добавлять только тогда, когда нет иного пути.

    Для небольшой фермы DNS RR это самое простое и практичное. И самое надежное.


    Сазонов Илья http://isazonov.wordpress.com/

    23 апреля 2013 г. 11:05
    Модератор
  • Да, все понятно с этим. Подскажите, каким образом более правильно распределить тогда роли RDS, имея 3 физических сервера, при этом обеспечив максимальную отказоустойчивость и возможность масштабирования. Предполагается на начальном этапе подключение приблизительно 100 пользователей и работа в Dynamics AX  2009, дальнейшее расширение до 200-250. Как в данном случае распространять приложение - через RDWA или RDP файлы, или и то, и другое вместе? 
    23 апреля 2013 г. 13:09
  • Распределяйте как хочется, но имейте в виду - не будет брокера, не будет ничего :)

    Масштабирование у вас будет при любых вариантах реализации, так как добавить сервер в ферму - раз плюнуть.

    Распространять приложения - это опять же как вам удобнее: удобно из браузера - пожалуйста, подходит вариант через remoteapp - еще лучше.

    23 апреля 2013 г. 13:16
  •  обеспечив максимальную отказоустойчивость и возможность масштабирования.  

    1. Надо более четко описать что для вашей ситуации "отказоустойчивать". Если ваши 100 пользователей могут перебиться пару часов без Dynamics AX  2009, то никаких HA и кластеров вам не нужно.

    2. Выделенный брокер может понадобиться только если у вас число одновременных пользователей будет измеряться тысячами.

    Поэтому скорее всего вам подойдет простейшая (и для пользователей, и для сопровождения, и по цене) конфигурация: развернуть на все три сервера RDSH, на один из них брокер и сделать DNS RR.

    Дополнительно:

    1. RDWA я бы не стал делать на R2, если только на 2012

    2. По официальным тестам на одном сервере уживается от 100 до 150 одновременных терминальных сессий - дальше пользователи начинают испытывать задержки независимо от ресурсов сервера.


    Сазонов Илья http://isazonov.wordpress.com/

    24 апреля 2013 г. 9:44
    Модератор
  • Спасибо за информацию.

    Еще один вопрос "всплыл". Вы советуете разместить роль RDCB на одном из членов фермы RDSH. А товарищ Грэг Шилдс в вышеупомянутой статье говорит: "Со службой роли посредника подключений к удаленному рабочему столу есть одна проблема. Его нельзя установить на RDSH-сервер, который является членом фермы."

    Как правильнее?

    24 апреля 2013 г. 10:03