none
Ферма терминальных серверов 2016 RRS feed

  • Вопрос

  • Может не в тот раздел, модерам\адм просьба поправить.

    Планируется ферма терм. серверов на базе 2016 (и домен на них).

    Требования:

    0. число юзеров - до 300

    1. Все профили юзеров - отдельный кластерный ф.сервер

    2. Офис - отдельными терм. окнами (терм.доступ), не локально установлен, а отд. срв. с публикацией оф. приложений

    3. С ПК, кот. коннектится к сессии - нет доступа, кроме РДП (есть обмен с доп. сервером, кот. на вири проверяет и безопасники там перекладывают что нужно из вх. в исх. папку)

    Места и ресурсов мала.

    Планируется примерно 300/50 (рекомендации число юзеров на 1 срв) - 6 терминальников. Лицензирование - поставил на DC. Ок.

    Для офиса, ну ок, поставлю свои терм. 2-3 типа ферму, туда же инет. Для профилей кластер файловый.

    А сколько нужно под все остальное - посредники подключений, например? Доп. вопрос - их в режиме ядра можно поставить? И может еще что остальное. Sql кластер тоже есть.

    Нужен совет.

    Как бы вы расчитали и реализовали такие хотелки?

    Читаю вот это http://winitpro.ru/index.php/2011/08/26/nastrojka-terminalnoj-fermy-rds-s-rd-connection-broker/ но как-то конкретных цифр не видно.

    Посоветуйте плз, как сделать _правильно_.

    18 марта 2019 г. 19:29

Ответы

  • Из личного опыта. 10 RDSH хостов по 40GB RAM, 150 HDD, 16 CPU + 5 таких выключенных в резерве. 2 RDSH под Remoteapp с такой же конфигурацией, 2 RDCB в коре с базой на SQL Always ON разнесенные по ЦОДам - они же сервера лицензирования. 1 RDGW (Desktop), 1 RDWEB (он может быть только desktop). Профили пользователей перенаправляемые на файловый кластер. Офис установлен локально для пользователей полноценных хостов. Remoteapp только для некоторых приложений для пользователей с личными компьютерами. Еще есть два RDSH для 1С с таким же конфигом, с них тоже RemoteApp.

    Но это для наших пользователей, довольно высоконагруженные сессии у них. А вообще, пользовательские сессии сожрут всё, что вы им выдадите - тут вопрос комфорта работы. Так же, постарайтесь максимально сплитить RDSH хосты. Заафекченый сервер с 10 пользователями требующий работ, это не сервер с 50 пользователями. А это будет случаться постоянно - то кто-нибудь вкладок в хроме наоткрывает, то кто-то отчет под конец периода в excel запустит. Так же максимальный сплитинг RD серверов дает более легкое управление ими в виртуальной инфраструктуре (например, DRS в vmware будет работать более гибко с мелкими серверами). Обратите внимание на свои старые принтеры, их драйвера могут выводить спулер из строя и вешать пользовательские сессии (остаются те самые, которые "shadow", без отображаемого имени пользователя) спасает либо ребут, либо рестарт спулера с разлогиниванием их через ProcessExplorer (от Руссиновича). Не сказать, что критично, ежедневный ребут RDSH помогает, но надо быть готовым). 

    Вроде всё, что вспомнилось ночью. Если есть вопросы - задавайте.

    18 марта 2019 г. 23:05
  • посредников было бы неплохо 2 в высокодосьупной конфигурации (можно и больше но 2 вполне достаточно). Думаю что можно посредники засунуть в кор но я не пробовал.

    по поводу сущностей не понимаю профита от офиса в remote app, поэтому я бы поставил их локально

    статей к сожалению толковых под рукой нет. последний раз пользовался 3 - 4 статьями но ссылки потеряны на просторах истории


    The opinion expressed by me is not an official position of Microsoft

    18 марта 2019 г. 20:25
    Модератор

Все ответы

  • смотрите статьи поновее так как с приходом 2012 сервера на рынок философия настройки терминальных ферм значительно изменилась.

    концептуально мыслите в правильную сторону но при ограниченных ресурсах непонятно зачем плодить сущьности с remote app серверами, но дело ваше.

    что до посредников то вы их можете вынести на отдельные сервера (что рекомендуется) или развернуть на тех же хостах что и rdsh (но как минимум 1 брокер должен НЕ входить в состав rdsh)

    sql кластер вам пригодится для брокеров

    цифры конкретные вам скорее всего никто вменяемые никто не даст, так как все зависит от конкретного конфига

    например встречал брошюру мс с расчетом памяти на хост в которой было написано что 128 мб на пользюка это прям ооочень много, а из практики мы получали цифры в 8 - 10 раз большие.


    The opinion expressed by me is not an official position of Microsoft

    18 марта 2019 г. 19:47
    Модератор
  • За ответ спасибо.

    Если есть ссылки на новые (en) статьи - с удовольствием почитаю.

    плодить>>

    а как бы вы поступили?

    >> что до посредников

    это и так планируется. вопрос - сколько их нужно и можно ли в ядре?

    то, что написал выше - лишь план. а желательно получить пошаговое "как нужно" + опыта внедрения, если е. у кого.

    Или хотя бы последней теории.


    • Изменено GuSoft 18 марта 2019 г. 20:04
    18 марта 2019 г. 20:02
  • посредников было бы неплохо 2 в высокодосьупной конфигурации (можно и больше но 2 вполне достаточно). Думаю что можно посредники засунуть в кор но я не пробовал.

    по поводу сущностей не понимаю профита от офиса в remote app, поэтому я бы поставил их локально

    статей к сожалению толковых под рукой нет. последний раз пользовался 3 - 4 статьями но ссылки потеряны на просторах истории


    The opinion expressed by me is not an official position of Microsoft

    18 марта 2019 г. 20:25
    Модератор
  • Из личного опыта. 10 RDSH хостов по 40GB RAM, 150 HDD, 16 CPU + 5 таких выключенных в резерве. 2 RDSH под Remoteapp с такой же конфигурацией, 2 RDCB в коре с базой на SQL Always ON разнесенные по ЦОДам - они же сервера лицензирования. 1 RDGW (Desktop), 1 RDWEB (он может быть только desktop). Профили пользователей перенаправляемые на файловый кластер. Офис установлен локально для пользователей полноценных хостов. Remoteapp только для некоторых приложений для пользователей с личными компьютерами. Еще есть два RDSH для 1С с таким же конфигом, с них тоже RemoteApp.

    Но это для наших пользователей, довольно высоконагруженные сессии у них. А вообще, пользовательские сессии сожрут всё, что вы им выдадите - тут вопрос комфорта работы. Так же, постарайтесь максимально сплитить RDSH хосты. Заафекченый сервер с 10 пользователями требующий работ, это не сервер с 50 пользователями. А это будет случаться постоянно - то кто-нибудь вкладок в хроме наоткрывает, то кто-то отчет под конец периода в excel запустит. Так же максимальный сплитинг RD серверов дает более легкое управление ими в виртуальной инфраструктуре (например, DRS в vmware будет работать более гибко с мелкими серверами). Обратите внимание на свои старые принтеры, их драйвера могут выводить спулер из строя и вешать пользовательские сессии (остаются те самые, которые "shadow", без отображаемого имени пользователя) спасает либо ребут, либо рестарт спулера с разлогиниванием их через ProcessExplorer (от Руссиновича). Не сказать, что критично, ежедневный ребут RDSH помогает, но надо быть готовым). 

    Вроде всё, что вспомнилось ночью. Если есть вопросы - задавайте.

    18 марта 2019 г. 23:05