Dns round robin windows server 2012

Обновлено 29.07.2019

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов на просторах рунета Pyatilistnik.org. Продолжаем с вами усовершенствовать свои навыки и знания в сфере системного администрирования. В предыдущей статье мы с вами разобрали основные понятия DNS сервера и его компонентов. Сегодня мы более подробно разберем, одну из его полезнейших вещей, которую очень часто используют, например на RDS фермах, или различных балансировщиках. Речь пойдет про функционал DNS Round Robin, рассмотрим его настройку и его применение.

Теория

Статья описывает одну из технологий балансировки нагрузки, которая может быть реализована средствами DNS. Для перевода имени хоста в IP-адрес клиент DNS направляет серверу DNS рекурсивный запрос (т.е. запрос, на который сервер DNS возвращает клиенту либо ответ с IP адресом, либо ответ с ошибкой).

В подавляющем большинстве случаев в зонах DNS содержится только один IP адрес, соответствующий тому или иному имени хоста. А какой IP адрес будет возвращать клиенту сервер DNS, если зона содержит несколько записей типа A для одного и того же имени? Ответ простой: сервер DNS всегда возвращает клиенту все IP адреса, соответствующие запрашиваемому имени. А дальше клиент пытается связаться с первым IP адресом в списке и, если он не будет найден, делает попытку связаться со вторым адресом и т.д.

Предположим, у меня есть несколько зеркальных веб-сайтов по имени www.gorbunov.pro, расположенных на разных площадках и имеющих IP адреса 20.0.0.1, 30.0.0.1 и 40.0.0.1.

В ответ на рекурсивный запрос клиента об имени www.gorbunov.pro сервер DNS вернет клиенту весь набор записей из зоны:

www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1

Поскольку адрес 20.0.0.1 идет первым в списке, клиент всегда будет пытаться связаться именно с сайтом по адресу 20.0.0.1. Получается, что сайты 30.0.0.1 и 40.0.0.1 используются только как пассивный резерв. До тех пор, пока «жив» сайт по адресу 20.0.0.1, сайты 30.0.0.1 и 40.0.0.1 не получат от клиента ни одного запроса.

Как сделать, чтобы запросы “доставались” всем хостам? Ответ простой: настроить на сервере DNS функцию Round robin.

При включенной функции Round robin сервер DNS постоянно «перемешивает» ответы клиентам, поэтому на первый запрос клиента DNS об имени www.gorbunov.pro сервер DNS вернет ответ

www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1

На второй запрос от клиента или от другого сервера DNS будет возвращен ответ

www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1
www.gorbunov.pro 20.0.0.1

На третий запрос будет ответ
www.gorbunov.pro 40.0.0.1
www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1

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

Практика
____________________________________________________________________________________

Проверка работы DNS Round robin

В Windows Server опция Enable round robin включена по умолчанию. Достаточно в консоли DNS Manager открыть свойства DNS сервера и посмотреть вкладку Advanced.

Для практической проверки функционала DNS Round robin создаем зону gorbunov.pro и добавляем в нее три записи для хоста www.

Если вы попробуете теперь “попинговать” хост www.gorbunov.pro, то с удивлением обнаружите, что клиент все время отправляет пакеты на адрес 20.0.0.1 (выделено красным). Понятно, что ответа от хоста нет, но и DNS Round robin не работает!

C:>ping www.gorbunov.pro

Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:>ping www.gorbunov.pro

Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:>
Анализ кэша DNS на стороне клиента дает следующий результат:
C:>ipconfig /displaydns

Windows IP Configuration

www.gorbunov.pro
—————————————-
Record Name . . . . . : www.gorbunov.pro
Record Type . . . . . : 1
Time To Live . . . . : 3567
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 20.0.0.1

Record Name . . . . . : www.gorbunov.pro
Record Type . . . . . : 1
Time To Live . . . . : 3567
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 30.0.0.1

Record Name . . . . . : www.gorbunov.pro
Record Type . . . . . : 1
Time To Live . . . . : 3567
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 40.0.0.1
C:>

Теперь становится понятно, почему мы “пингуем” один и тот же хост 20.0.0.1. Сервер DNS возвращает клиенту все записи из зоны с указанием времени кэширования, равным по умолчанию 1 часу (или 3600 секундам). Поэтому до истечения времени кэширования (TTL – Time To Live) клиент больше не направляет к серверу DNS никаких новых запросов.

Сброс кэша командой ipconfig / flushdns и новая команда
ping www.gorbunov.pro приводят, наконец к желаемому результату.C:>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

C:>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [30.0.0.1] with 32 bytes of data:
Request timed out.

Теперь ясно, что для правильной работы DNS Round robin потребуется изменение параметров кэширования, чтобы клиенты постоянно получали обновленный список с “перемешанными” записями.
Настройка времени кэширования ответов DNS

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

Для настройки индивидуального времени кэширования в консоли DNS Manager требуется сначала включить режим View –> Advanced. Затем последовательно открываем свойства записей (в нашем примере это три записи www) и ставим время кэширования, равное нулю.

Проверка работы дает в конце концов желаемый результат!

C:>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.

Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [30.0.0.1] with 32 bytes of data:
Request timed out.

Ping statistics for 30.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [40.0.0.1] with 32 bytes of data:
Request timed out.

Ping statistics for 40.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Файл зоны на сервере DNS при этом будет выглядеть так:
;
; Database file gorbunov.pro.dns for gorbunov.pro zone.
; Zone version: 7
;

@ IN SOA dc01.contoso.com. hostmaster.contoso.com. (
7 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; default TTL

www 0 A 20.0.0.1
0 A 30.0.0.1
0 A 40.0.0.1

Добавления нуля в записи типа A можно сделать и вручную непосредственно в файле зоны.

• Исключения

В настройках сервера DNS по умолчанию включена и опция Enable netmask ordering. Смысл опции заключаются в том, что при наличии нескольких IP адресов для одного и того же имени хоста сервер DNS анализирует из какой сети пришел запрос от клиента. Если IP сеть клиента совпадает с номером сети одного из IP адресов хоста, то такой IP всегда возвращается первым. Проще говоря, если в нашем примере клиент с адресом 30.67.98.123 будет запрашивать имя www.gorbunov.pro, то ему всегда первым в списке будет возвращаться адрес 30.0.0.1. В серверах Windows опция Enable netmask ordering перебивает опцию Enable round robin. Т.е. клиентам DNS первым всегда возвращается адрес ближайшего хоста, даже несмотря на правильно настроенную функцию DNS Round robin.

• Выводы

Технология DNS Round robin часто применяется для динамической балансировки нагрузки между зеркальными хостами. Она значительно проще в реализации, чем вариант настройки для тех же целей кластера NLB. При настройке DNS Round robin на серверах Windows не забывайте, что настройки по умолчанию для сервера DNS не позволяют в полной мере реализовать балансировку запросов и требуется ручная конфигурация сервера.

Привет.

DNS – важная инфраструктурная служба. Настолько, что в предыдущей статье на тему безопасности DNS использовалась специальная иллюстрация:

В принципе, мало что изменилось – поэтому в данной, обновлённой версии статьи про безопасность DNS в Windows Server, я расскажу про то же самое, но уже детальнее. Будет рассматриваться Windows Server 2012 R2 и Windows Server 2016 – оба со всеми обновлениями на апрель 2016 года, для тюнинга будет использоваться ATcmd, в общем – работы много.

Безопасность и тюнинг DNS в Windows Server 2012 R2 и 2016

• Механизм SocketPool – защищаемся от предсказуемости DNS-порта
• Secure cache against pollution – защищаемся от отравления DNS-кэша
• Блокируем раннее обновление кэша – Cache Locking
• Привязка DNS-сервера к сетевым интерфейсам
• Удалённое управление DNS-сервером
• Настраиваем Global Query Block List
• Отключение обработки рекурсивных запросов
• Ограничение времени кэширования записей
• Отключаем AXFR / IXFR трансфер у зон, интегрированных в Active Directory
• Ограничение числа Resource Record’ов (RR) в ответе DNS-сервера
• Настройка BIND secondaries
• Настройка тайм-аута AXFR / IXFR трансфера
• Настройка времени блокировки AXFR / IXFR трансфера
• Фильтрация Name checking
• Механизм Aging/Scavenging в DNS
• Работа Round Robin и Netmask Ordering
• Блокировка динамической регистрации по типу RR
• Настройка EDNS0 в Windows Server 2012 R2
• Настройка DNS-форвардеров в Windows Server
• Ускоряем загрузку DNS-зон в Windows Server 2012 R2 и старше

Начнём.

Механизм SocketPool – защищаемся от предсказуемости DNS-порта

SocketPool появился как способ противодействия описанной в KB 953230 уязвимости, называемой иногда “Kaminsky bug”. Суть достаточно проста. В версиях Microsoft DNS до NT 6.1 для отправки данных DNS-сервера стартово инициализировался один сокет, от которого шло взаимодействие (в частности – ответы на UDP-запросы клиентов). Один сокет = разовая инициализация = одинаковый случайный ID транзакции. Это позволяло проводить атаку на перебор вариантов ID и с определённой вероятностью отравить кэш DNS-сервера путём отправки ему “заранее” неправильного ответа на предсказуемый запрос. А после, соответственно, DNS-сервер отдавал бы клиентам неправильную информацию из своего кэша, таким образом перенаправляя трафик туда, куда надо нарушителю.

Бороться с этим было решено достаточно просто – выделяя под нужды DNS-сервера пул сокетов, и отправляя ответы со случайного из них. Плюс, для каждой DNS-транзакции стал генериться уникальный ID, что дополнительно усложнило задачу отравления кэша, сделав её, при корректном применении всех защитных мер, осуществимой лишь теоретически.

Настройка SocketPool

По умолчанию пул равен 2.500 сокетам (притом, замечу, под пул выделяется одинаковое число и IPv4-портов, и IPv6 – т.е. в сумме по умолчанию зарезервированно 5 тысяч портов), но если ваш DNS-сервер обрабатывает запросы от внешних клиентов – увеличьте пул до 10К (если попробовать больше, выдаст DNS_ERROR_DWORD_VALUE_TOO_LARGE с кодом 9567). В случае, если DNS-сервер локальный – допустим, это DNS-сервер контроллера домена, и к нему обращаются клиенты из внутренней сети – стандартных 2.500 сокетов хватит.

Команда для задания количества сокетов, которые под себя “застолбит” сервис DNS:

Посмотреть текущую ситуацию с выделенными для SocketPool сокетам также можно в сводной информации по расширенным настройкам DNS server’а:

Как видно, параметр этот не одинок – продолжим про остальные.

Возможные проблемы, связанные с SocketPool, и настройка исключений

Возможные проблемы связаны с тем, что DNS Server застолбит под себя много UDP-сокетов, и различное ПО может от этого не иметь возможность сделать то же самое. Известный пример – это WDS (Windows Deployment Services). Эта служба резервирует для себя диапазон портов с 64.000 по 65.000, и в случае, когда DNS Server заберёт нужное число под SocketPool, могут возникнуть проблемы из-за наложения диапазонов DNS и WDS. Они решаемы, благодаря тому, что в WDS, который в Windows Server 2012 R2, встроен механизм динамического выбора портов. Включается он достаточно просто:

Замечу, что данный случай, когда существует штатный способ обойти ситуацию – единичная редкость. Вообще, так как механизм SocketPool резервирует под себя непрерывный блок UDP-портов, находящихся в верхней четверти всего доступного диапазона – т.е. с 49К и до 64К (это лишь 16К портов), то немудрено, что блок в 10К будет занимать много места и, возможно, конфликтовать с другими сервисами на том же хосте. Поэтому есть механизм, который позволяет исключить один или более диапазонов из SocketPool. Это делается специальной настройкой – штатного интерфейса у неё нет, поэтому выглядеть, например, исключение из пула портов диапазона 62000-63000, будет так:

Дополнительной и достаточно хитрой проблемой будет сценарий “Мы когда-то обновлялись с Windows Server 2003”. В этом случае в реестре может остаться технический параметр сетевого стека, актуальный до-NT-6.0 – т.н. MaxUserPort. Данный параметр ограничивает сверху диапазон выдаваемых приложению портов. То есть, если этот параметр есть, Windows Server 2012 R2 поменяет логику выдачи портов для DNS-сервера с “выдавать из диапазона 49K – 64K” на устаревший “выдавать с 1024 порта по MaxUserPort”. Поэтому для нормальной работы этот параметр надо, в случае его присутствия, удалить, он от устаревшей версии Windows Server и сейчас не нужен:

Суммаризируем советы по этому масштабному пункту:

• Выставляем SocketPool везде в 2.500 – за исключением тех DNS-серверов, которые опубликованы в Интернет. У них – 10.000.
• Заранее отключаем устаревшее управление диапазоном выделяемых портов, которое MaxUserPort. Оно нам сейчас только мешает и всё путает.
• В случае острой необходимости используем исключения из диапазона SocketPool, чтобы не конфликтовать с другими сервисами, которые тоже хотят зарезервировать для себя ‘слушающие ‘UDP-порты.

Теперь двигаемся дальше.

Secure cache against pollution – защищаемся от отравления DNS-кэша

Идея этой настройки, появившейся ещё в Windows NT 4.0, и включенной по умолчанию с Windows Server 2003, проста. Она состоит в том, чтобы читать из ответа DNS-сервера только запрашиваемые ранее сведения, и игнорировать остальные. Рассмотрим пример.

Допустим, на DNS-сервер пришёл запрос от клиента – “хочу A-запись с именем msdn.microsoft.com”. DNS-сервер посмотрел в зонах, расположеных на нём – не нашёл. Потом посмотрел у себя в кэше – тоже нет. ОК, на DNS-сервере включена рекурсия. Он запрашивает другой сервер (например, DNS провайдера или какой-нибудь публичный) и ждёт ответ. И сервер присылает ему ответ – вида “msdn.microsoft.com доступен по адресу 1.2.3.4”. Но иногда сервер хочет помочь – вдруг следующим запросом Вы захотите microsoft.com? И он присылает не только msdn.microsoft.com, но и ту информацию, которую он выяснил попутно – адрес microsoft.com. По умолчанию ответ обрабатывается и добавляется в кэш, т.к. предполагается, что сервер хороший, и присылает только полезную и нужную информацию.

Но жизнь жёстче.

Поэтому надо включать параметр secure cache against pollution, чтобы исключить даже теоретическую возможность получения недостоверной информации из DNS-ответа.

Проще всего сделать это через консоль управления сервером – открыть Properties, вкладку Advanced и установить нужное значение.

Блокируем раннее обновление кэша – Cache Locking

Механизм Cache Locking появился в Windows Server 2008 R2 и, по сути, является дополнительной мерой безопасности для защиты от “Kaminsky bug”. Работает Cache Locking просто – на какое-то время запрещает обновление успешно закэшированных записей. Параметр задаётся в процентах – допустим, если установить его в 50, то в случае, если Ваш сервер закэширует какую-нибудь запись, TTL которой равен 6 часам, все попытки обновить её на протяжении первых 3х часов будут игнорироваться. Установка параметра в 100, как понятно, приведёт к блокировке всех запросов на обновление имеющихся в кэше записей. Это – рекомендованное значение данного параметра, т.к. обычно Вы запрашиваете какую-то DNS-запись, сервер узнаёт про неё информацию и кэширует – перезапись “на лету”, пока не истекло время кэширования, не предполагается.

Настраиваем данный параметр:

Напомню, что после смены этого параметра, как и подавляющего большинства других параметров уровня сервера, необходимо перезапустить службу DNS Server.

Привязка DNS-сервера к сетевым интерфейсам

По умолчанию DNS-сервер слушает трафик и реагирует на запросы со всех интерфейсов. Это включает в себя все IPv4-адреса и все IPv6 (как unicast’ы, так и link local’ы). Да и при добавлении нового интерфейса он будет сразу же использоваться службой DNS. Имеет смысл из соображений предсказуемости переключить эту настройку на явное указание адресов, на которых DNS-сервер будет принимать трафик. Например, если в инфраструктуре не используется IPv6, а DNS Server настроен “по умолчанию”, и на его интерфейсах включен сетевой компонент IPv6, он (DNS Server) будет обрабатывать запросы, пришедшие на адрес link local (вида fe80::идентификатор хоста), что является в указанной ситуации не нужным и не должно, согласно принципу Уильяма Оккама, существовать. Также не очевидно, что в случае установки нового сетевого соединения с хоста, на котором запущена служба DNS Server, подразумевается, что надо сразу же начать обрабатывать запросы клиентов, пришедшие на новопоявившийся интерфейс.

Как настраивается привязка DNS-сервера к сетевым интерфейсам

Необходимо зайти в настройки DNS Server, выбрать Properties и на вкладке Interfaces в явном виде выбрать только те адреса, на которые нужно принимать dns-запросы. Вот так:

Удалённое управление DNS-сервером

DNS-сервером можно управлять дистанционно через три технологически различных способа – это прямое подключение по TCP/IP (в данном случае, по сути, обычно и называемое RPC), отправка команд через Named Pipes и локальный вызов процедур (LPC). Имеются в виду, безусловно, способы подключения именно к службе и COM-объектам DNS-сервера, а не к хосту, на котором эта служба запущена. Так вот, если ваш DNS-сервер администрируется не всеми из них – а так обычно и бывает – то лишние надо выключать. Если это, допустим, опубликованный наружу DNS-сервер, который установлен на отдельной виртуальной машине, и управление осуществляется путём подключения администратора по RDP, то ничего, кроме LPC (чтобы MMC-консоль работала) серверу не нужно. Если это инфраструктурная виртуалка, к которой подключаются удалённой оснасткой, то ей надо только RPC поверх TCP/IP, никакие named pipes ей не нужны. Данная настройка (для случая с LPC) будет выглядеть так, иные варианты делаются по аналогии:

Настраиваем Global Query Block List

Глобальный блок-лист имён – достаточно интересная штука. Необходимость его использования вызвана тем, что в случае использования хостами динамической регистрации DNS-имён возможна ситуация, когда злонамеренный участник зарегистрирует well-known имя, которое используется сетевой службой (например, wpad или isatap). Имя другого компьютера или сервера ему зарегистрировать, в случае существования оных и включённого механизма secure updates, не дадут, а вот wpad допустим – пожалуйста, ведь сервера с таким именем нет, это служебный идентификатор. А после – данный компьютер будет отвечать на запросы пытающихся автоконфигурироваться клиентов вида “а дайте мне настройки” по адресу “http://wpad.имя_домена/wpad.dat”, отдавая им то, что посчитает нужным. Это неправильно. Ну и второй вариант злонамеренного использования – удалённый пользователь может получить информацию об инфраструктурных сервисах, запросив эти технические resource record’ы. Соответственно, GQBL нужен для того, чтобы отсечь эти возможности.

Как этот механизм будет работать? Рассмотрим вариант для наличия в GQBL стандартного имени wpad.

При добавлении имени в GQBL будут игнорироваться запросы для всех типов записей (это важно – не только A и AAAA, а всех) для всех зон, для которых данный сервер является authoritative. То есть, допустим, если на сервере есть зоны domain.local и _msdcs.domain.local, то запросы wpad._msdcs.domain.local и wpad.domain.local, несмотря на фактическое наличие/отсутствие данной записи, будут возвращать ответ, что запись не найдена.

Замечу, что если что – это можно обойти, если создать зону с именем wpad.domain.local и в ней – пустую запись нужного типа. В именах зон проверка не происходит. Уязвимостью это не является, т.к. удалённо динамически зарегистрировать зону нельзя.

Запросы для других зон (не находящихся на сервере) под это подпадать не будут (т.е. wpad.externaldomain.ru под этот механизм не подпадёт).

Интересным является также момент про то, как данный механизм работает с логами. При первой блокировке в журнал пишется событие, где написано, что запрос от такого-то клиента заблокирован по причине нахождения искомого в GQBL. После запись уже не ведётся. Это не баг, а защита от простейшей атаки – переполнения журнала путём отправки огромного количества запросов на предсказуемо блокируемый FQDN. После перезапуска сервера счётчик сбросится на нуль и опять – первая блокировка будет записана в журнал, далее – нет.

Теперь настройка.

Настройка Global Query Block List на Windows Server 2012 R2

Включить этот фильтр на уровне сервера просто:

Задать содержимое – тоже несложно. Можно задать весь лист целиком, редактировать каждую запись отдельно – увы, только через реестр:

Отключение обработки рекурсивных запросов

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

В упомянутых случаях DNS-сервер должен отвечать исключительно на один тип вопросов – про те зоны, которые ему явно известны и локально находятся. Абстрактные же запросы вида “а поищи-ка мне вот такое вот имя” не нужны и приводят к потенциальной DoS-атаке.

Отключение рекурсии выглядит так:

Как понятно из названия, вместе с ней отключаются и форвардеры – это логично, т.к. серверу без рекурсии форвардеры не нужны – он принципиально не обрабатывает запросы, для которых может понадобиться запрос какого-либо другого сервера.

Ограничение времени кэширования записей

Записи, которые DNS-сервер получил от других DNS-серверов, не только передаются запрашивающим клиентам, но и кэшируются на сервере. Время кэширования указано в самой записи – у неё есть личный TTL.

В ряде случаев имеет смысл сделать работу более динамичной и ускорить актуализацию записей, установив максимальный TTL для всех RR’ов на сервере. Простой пример – некто установил огромный TTL (например, 42 дня), а по факту запись иногда меняется. В этом случае пока запись не устареет в кэше, ваш DNS-сервер будет давать неверный/устаревший ответ. Проще указать некую верхнюю границу – допустим, сутки – и записи с любыми TTL не будут храниться в кэше дольше этого срока, и сервер будет их запрашивать. Ничтожный рост трафика (один доп.пакет в день) гораздо лучше, чем, допустим, три недели испытывать проблемы с электронной почтой, потому что кто-то обновил MX, но забыл, что TTL выставлен огромный, поэтому изменение по факту применится очень нескоро. Этому, кстати, способствует тот момент, что в интерфейсе Microsoft DNS Server изменение TTL у DNS-записи доступно только в расширенном режиме работы. Вот как окно редактирования DNS-записи выглядит обычно:

А вот как в случае, когда в меню View включён пункт Advanced:

Не забывайте про то, что нужно выставлять разумные TTL у записей. Ну а теперь как ограничить максимальный срок жизни записи в кэше DNS-сервера:

86400 – это секунд в сутках, как понятно.

Не менее важным параметром является ограничение времени кэширования негативного ответа. Суть достаточно проста – в случае, если в качестве ответа на запрос пришёл отказ, ваш DNS-сервер запоминает это, чтобы при повторных запросах каждый раз не повторять обращение – ну, экономит силы. Нет смысла раз в секунду по-честному бегать и проверять, не появилась ли запись, если удалённый сервер сообщил, что её нет.

Однако на практике данный параметр желательно настроить на какой-то небольшой интервал времени – чтобы с одной стороны, часто запрашивающий клиент не мог перегрузить DNS-сервер, а с другой, при появлении запрашиваемой записи на удалённом сервере мы бы могли про это узнать в разумное время.

Я поставлю время кэширования негативного ответа в 5 минут:

Отключаем AXFR/IXFR трансфер у зон, интегрированных в Active Directory

В том случае, если все сервера, на которых находится определённая зона, расположены на контроллерах Active Directory, то наличие возможности трансфера зоны стандартным способом – AXFR / IXFR запросом по TCP 53 является уязвимостью, так как может помочь потенциальному злоумышленнику узнать дополнительные сведения об инфраструктуре. Притом достаточно простым способом – например, подключившись при помощи nslookup и выполнив команду ls. Нормальная же репликация зоны происходит через механизмы LDAP-репликации Active Directory.

Отключаем просто – открываем свойства (Properties) у нужной DNS-зоны, выбираем вкладку Zone Transfers:

Это надо сделать не только у зон, интегрированных в Active Directory, но и у всех копий зоны, находящихся на secondary-серверах, с которых не забирают копию другие secondary-сервера.

Ограничение числа Resource Record’ов (RR) в ответе DNS-сервера

Данная настройка позволит обойти одну редкую, но неприятную проблему, связанную с разным поведением DNS-клиентов. Суть проста – в случае, когда в ответ надо добавить много записей, и, несмотря на EDNS0 и прочие ухищрения, они не влезают, у ответа ставится бит “неполный” – т.н. “truncation bit”. По идее, после получения ответа с таким битом, запрашивающий должен насторожиться и переспросить повторно, но уже по TCP (не забывайте, DNS-сервер умеет отвечать на запросы не только по UDP), чтобы получить не-урезанный ответ. Однако так поступают не все клиенты. Более того, высока вероятность того, что где-то в цепочке передачи рекурсивного запроса кто-то один не будет поддерживать запросы/ответы по TCP, поэтому информация просто потеряется – грубо говоря, клиент, получив не полный ответ, а урезанный, запросит иным способом, а в ответ – тишина, в результате клиент может решить, что имя просто не разрешилось полноценно.

Чтобы минимизировать вероятность этой ситуации, нужно сделать ряд шагов.

Первым делом – разберитесь с максимальным размером UDP-ответа. Чем лучше разберётесь – тем ниже вероятность возникновения упомянутой ситуации.

Вторым – проверьте, все ли ваши DNS-сервера отвечают по TCP. Для этого в ATcmd есть встроенный тест – команда test dns ports, которой надо лишь указать имя домена (например, локального домена Active Directory) – она найдёт все NS-сервера за этот домен, и попробует запросить у каждого и UDP- и TCP-вариант ответа. Обеспечение возможности клиентов посылать вашим DNS-серверам запросы через TCP – это тот минимум, который вы можете сделать, т.к. не можете влиять на все DNS-сервера в рекурсивной цепочке. Примитивный подход “DNS работает только через UDP, через TCP только трансфер зон, поэтому TCP за исключением трансфера надо блочить на firewall’е” не работает – вы решите массу проблем и уберёте непонятные сбои, если клиенты смогут нормально переспрашивать DNS-сервер по TCP.

А теперь можно и ограничить число RR в DNS-ответе. Я поставлю 28 (это максимальное ограничение).

Это обозначает то, что я уверен, что у меня нет ни одной записи, которая разрешается сразу в более чем 28 ответов, но если таковые есть (допустим, чужие, после рекурсивного запроса) – клиенту будет возвращаться не “сколько влезло плюс пометка, что влезло не всё”, а только 28 лучших. Сценарий с возвратом большого числа записей возможен, в принципе, в паре основных случаев – когда запрашивается разрешение имени какого-то высоконагруженного ресурса (в ответе пачка A и AAAA), или когда во внутренней сети запрашивается Active Directory-специфичная корневая или SRV запись (допустим, за корень домена в DNS регистрируются все DC – поэтому в больших доменах очевидна ситуация, когда ответ на вопрос “а кто у нас хост за domain.local” возвращает опять же большую пачку A- и AAAA-записей). В этом случае нужно оперировать настройками сервера по части приоритета выдачи только нужных ответов, а не всех, и максимально избегать линейного решения ситуации “вот тебе в ответ на запрос 250 A-ответов про все DC в домене, делай что хочешь”.

Настройка BIND secondaries

По сути, этот параметр делает одну-единственную вещь – запрещает при стандартном трансфере зоны с текущего DNS-сервера передавать несколько записей одной операцией, чем замедляет трансфер. Поддержка функционала передачи нескольких записей есть в BIND уже достаточно давно, с версии 4.9.4, поэтому на данный момент включение данной опции не имеет смысла и лишь замедлит трансфер DNS-зон.

Для настройки этой опции нужно выбрать свойства (Properties) у сервера DNS, там – вкладку Advanced, а после выбрать соответствующий параметр:

Настройка тайм-аута AXFR / IXFR трансфера

По умолчанию трансфер DNS-зоны считается несостоявшимся, если тайм-аут со стороны отвечающего сервера превысил 30 секунд бездействия. Этот параметр можно и нужно править – например, снизить до 15 секунд, чтобы раньше “отсекать” ситуации, когда сервер не осуществляет трансфер, а просто подключился и сидит. Хорошие DNS-серверы так себя не ведут, действуют быстро и закрывают TCP-сессию тоже оперативно. Правим:

Настройка времени блокировки AXFR / IXFR трансфера

Одной из загадок в поведении Microsoft DNS Server, обнаруживаемой в начале использования, является то, что после удачной передачи зоны с одного сервера на другой, и быстрого рефреша консоли нажатием F5, вылезает ошибка “Всё, трансфер зоны сломался”. В самом деле, чему там ломаться-то в такой ситуации?

Ломаться действительно нечему – просто срабатывает механизм защиты primary DNS от перегрузки. Логика следующая:

• Допустим, что у нас есть DNS-зона, которая расположена на 1 primary DNS-серверах и на 100 secondary. Притом все secondary обновляют её исключительно с primary, т.е. никакой иерархии secondary нет.
• Один из secondary начинает скачивать зону. Пока он это делает, в эту же зону хочет записаться dynamic update какой-либо записи. Допускать этого нельзя, поэтому на зону на время трансфера накладывается write lock.
• Зона успешно передана – write lock снят, записи в зону произведены, и primary уведомляет всех secondary (через механизм DNS Notify), что есть изменения. Все они приходят качать зону, она опять блокируется от записей.

Такие “качели” приводят к тому, что зона непрерывно крутится в цикле “накопить пачку отложенных записей – массово раздать зону”. По сути, ради каждого единичного обновления все сервера подрываются полностью передавать зону (мы ж не уверены, что у всех есть IXFR). Вот для блокировки этого и нужен данный параметр. Время блокировки считается просто – количество секунд, по факту потраченное на последний успешный трансфер зоны (параметр хранится для каждой DNS-зоны на DNS-сервере отдельно), домножается на коэффициент, и результирующее число – это тот интервал, когда все запросы на трансфер будут безусловно отвергаться (в логах у secondary вы увидите событие 6525, “primary server refuses zone transfer”). Если этот параметр установить явно в нуль, то механизм полностью выключится – вы можете сделать так в случае, если подобная защита не нужна (малое число DNS-серверов), тогда ваша зона будет актуализироваться максимально быстро. Я просто уменьшу данный параметр с 10 (значение по умолчанию) до 3 раз – т.е. если зона передаётся за 3 секунды, следующие 9 секунд все запросы на трансфер будут отклоняться.

Фильтрация Name checking

Настройка Name Checking на уровне DNS Server’а указывает на то, по каким критериям будут фильтроваться имена в запросах. То есть в случае, если имя в запросе подпадает под выбранную логику проверки – запрос обрабатывается, если нет – то считается ошибочным и отбрасывается. Вариантов настройки будет четыре:

Вариант Strict RFC (ANSI)

В запрашиваемых именах могут быть только символы, которые указаны в RFC 952 и RFC 1123. Т.е. подмножество семибитовых ASCII-символов, case insensitive, по сути – только английские буквы, цифры и минус/тире/дефис.

Вариант Non RFC (ANSI)

Strict RFC плюс подчёркивание.

Вариант Multibyte (UTF8)

Имена могут быть в Unicode (RFC 2181).

Вариант All Names

Фильтрация не производится, сервер пытается обработать все полученные строки.

Что выбрать? Тут всё достаточно сложно. Ситуаций много. Например, если ваш DNS-сервер держит исключительно внешние зоны, в которых нет хостов с именами, использующими символы национальных алфавитов, и предназначен он лишь для этой задачи (т.е. на нём нет рекурсии), то имеет смысл использовать Non RFC. Для обычного сервера, который кэширует запросы клиентов, подойдёт Multibyte. Отключать фильтрацию целиком нецелесообразно.

Фильтрация по размеру FQDN – каждый компонент не более 63 байт и все в сумме – не более 255 – всегда сохраняется и не редактируема.

Наглядный пример – то, что на картинке, может быть только на сервере, который настроен не на Strict RFC / Non RFC:

Если у данного сервера поменять настройку на Strict RFC и сделать на зоне Reload, то запись тихо пропадёт – сервер проигнорирует её при загрузке. А если после вернуть настройки на All Names и опять сделать Reload – запись опять появится.

Как настраивается фильтрация Name Checking в Windows Server 2008 R2 DNS

Для настройки этой опции нужно выбрать свойства (Properties) у сервера DNS, и там – вкладку Advanced, а после выбрать необходимый режим.

Механизм Aging/Scavenging в DNS

Динамически добавленные в DNS-зону записи не умеют пропадать сами. Это не баг, это так положено. В WINS (который NBNS) (не к ночи он будет помянут) этот механизм был штатным, а вот в DNS – увы. Поэтому фирма Microsoft добавила данный механизм в свою реализацию DNS Server. Как он будет работать?

У каждой динамически зарегистрированной записи будет указываться time stamp – время последнего успешного изменения этой записи. После, на протяжении no-refresh time (по умолчанию – 7 дней), все обновления этой записи будут игнорироваться. В оригинале, когда этот механизм был в WINS, это было нужно, чтобы информация о записи “расползлась” по инфраструктуре, сейчас делается с другими целями. Когда no-refresh time закончится, у записи начинает бежать обратный отсчёт – refresh-time. Это время, в течении которого запись должна обновиться. Если она не обновится за это время (по умолчанию – тоже 7 дней), то она является кандидатом на удаление. И вот тут-то, если на уровне сервера включен механизм Scavenging of stale records, такие записи будут удаляться. Делается это раз в сутки (если включен автоматический режим), либо вручную.

Этот механизм полезен, т.к. при должной настройке будет эффективно удалять ненужные DNS-записи, например, переименованных или удалённых из домена рабочих станций.

Не забывайте, что механизм включается и на уровне сервера, и на уровне зоны. Чтобы механизм функционировал, необходимо включить его и там и там. Т.е. и зона должна одобрять идею автоматической очистки, и конкретный сервер знать, что периодически надо удалять записи, не обновлённые уже X дней.

Включать данный механизм полезно ещё по одной причине. Мало того, что он будет удалять устаревшие записи. Он ещё будет, вводя no-refresh interval, уменьшать трафик репликации Active Directory. Т.е. если за время no-refresh interval придёт запрос на динамическое обновление записи, и в нём не будет ничего нового, кроме продления срока жизни, то без механизма aging/scavenging этот запрос будет отработан и в зону будет произведена запись (бессмысленная), что вызовет репликацию раздела Active Directory, в котором находится эта запись. А в случае, если механизм будет включен, сервер посмотрит, и если запрос не будет содержать никакой новой информации (ну, например, машину просто перезагрузили – она ту же A-запись пытается зарегистрировать, по сути – просто сбросить time stamp), он будет проигнорирован. Это никак не повлияет на качество работы DNS, а вот новую репликацию не инициирует. Профит!

Как включается Aging/Scavenging в Microsoft Windows Server 2008 R2 DNS

Первое – включаем на уровне сервера. Этот пункт находится в настройках сервера (Properties), вкладке Advanced, снизу. Время, задаваемое там – это критерий очистки. Т.е. раз в сутки сервер, на котором это включено, будет находить все динамически зарегистрированные записи, которые не обновлялись указанное в настройках время, и удалять их. Можно указать этот параметр достаточно большим – я указываю 30 дней, если рабочая станция месяц не обновляла свою запись – наверное, смысла жить в DNS ей больше нет. Вернётся – заново зарегистрирует.

Второе – включаем на уровне зоны. Задаём no-refresh и refresh интервалы. Обычно стандартное время менять не нужно. В общем, всё.

Работа Round Robin и Netmask Ordering

Оба данных механизма, в общем, преследуют предсказуемую цель – улучшить жизнь DNS-клиента, выдавая ему заранее перетасованные и (желательно) только лучшие RR-записи в ответ на запрос, на который надо вернуть большое подмножество ответов. Поэтому по умолчанию оба этих параметра включены:

Как будет вести себя DNS-сервер в зависимости от их настроек:

• Если оба параметра выключены, то клиенту в ответ на запрос возвращается всегда одинаковый комплект A- и AAAA-записей, порядок их не меняется.
• Если включен только Netmask Ordering, то из списка всех A- и AAAA-записей хоста будут выбраны те, у кого первые N бит совпадают с source address клиентского запроса, и эти записи будут помещены в верх списка по критерию “чем больше бит совпало, тем лучше”. Обратите внимание на то, что source address – это, в случае рекурсии, всё время одинаковый адрес вашего DNS-сервера, который форвардит запросы наружу, поэтому фактически Netmask Ordering нужен только на сервере, к которому напрямую подключаются клиенты, и хорошо подходит, допустим, для задачи “дай список DC за домен”, где клиент и DC в региональном филиале скорее всего будут в одном сегменте сети.
• Если включен только Round Robin, то A- и AAAA-записи в ответе перемешиваются каждый раз, благодаря чему простые реализации DNS client’ов, которые берут первый попавшийся ответ, математически ровно распределяют попытки подключения между хостами.
• Ну а если включены оба режима, то вначале отработает Netmask Ordering, а не подпавшие под него записи будут перетасованы Round Robin’ом.

Данные параметры полезные и выключать их особо не требуется – вреда от них нет.

В случае же, если вам нужно исключить какой-либо тип RR из ротации round robin – т.е. надо, чтобы записи именно этого типа отдавались клиенту вот именно в одном и том же порядке всегда – то есть специальная команда:

Посмотреть исключённые в данный момент типы записей можно как обычно, командой show dnsserver.

Блокировка динамической регистрации по типу RR

В зонах, где разрешена динамическая регистрация, возможно указание того, какие именно типы записей можно обновлять динамически, а какие – нет. Это логично – разрешая динамическое обновление зоны (что безопасное, что обычное), администратор обычно подразумевает, что туда могут регистрироваться новые хосты. А вот что можно удалённо записать произвольную SOA, NS, или сделать NS-делегирование – это, в общем, неправильно.

Для управления этим есть параметр updatetypes, текущие настройки его можно посмотреть той же командой show dnsserver:

Задавать его придётся битовой маской, где каждый бит – это разрешение или запрет для динамической регистрации определённого типа RR. В одном DWORD собраны настройки и для всех зон, поддерживающих только безопасные обновления, и для всех зон, поддерживающих обычные динамические обновления:

Практический пример применения этого параметра – допустим, у вас есть домен Active Directory с названием kontora.local. Вы хотите, чтобы все сетевые принтеры в фирме были подключены не по IP-адресам, а по DNS-именам. Принтеры умеют, получив новый адрес от DHCP, динамически зарегистрироваться в DNS – но не умеют делать это безопасно, т.к. не имеют учётной записи в Active Directory. Ради принтеров ослаблять безопасность основной DNS-зоны домена – неправильно. Можно сделать субдомен prn.kontora.local и сказать принтерам регистрироваться в нём. Но тогда неплохо бы подстраховаться, чтобы они регистрировали именно A-записи, а вот например NS чисто технически обновить было бы нельзя (чтобы не было атаки на добавление rogue-DNS, в котором под A-записями принтеров будут скрываться узлы, которые будут делать что-то нехорошее).

Настройка EDNS0 в Windows Server 2012 R2

Данный блок настроек, из-за своей неочевидности и необходимости подробно разобрать лежащие в их основе технологии, вынесен в отдельную статью на нашей Knowledge Base – https://www.atraining.ru/edns0-windows-server/. Относится он скорее к тюнингу, чем к безопасности, но это никак не снижает его нужности.

Настройка DNS-форвардеров в Windows Server

Стандартное окно, где можно добавить форвардеры – очень простое.

В случае работы с conditional forwarders, которые появились с Windows Server 2003, вам разве что добавляется возможность повлиять на тайм-аут запроса – мол, если за это время DNS-сервер не ответит, запрос считается пропавшим без вести.

Но на самом деле возможностей настройки – гораздо больше.

Командлет Set-DnsServerRecursion поможет настроить более тонкую обработку рекурсии. Какие у него будут параметры?

Параметр -SecureResponse

Данный параметр очень ценный – он будет указывать, проверять ли ответ удалённого сервера на возможность cache pollution. То есть, допустим сценарий – вы сделали conditional forwarder, который говорит, чтобы все запросы вида *.atraining.ru перенаправлялись на адрес 178.159.49.230. Обычно подобные conditional forwarder’ы используются как обеспечение разрешения партнёрских внутренних DNS-зон в рамках forest trust – поэтому простой вопрос – а есть ли смысл, чтобы хост 178.159.49.230 передавал информацию дальше, если не найдёт у себя? По идее нет – вы указываете DNS-серверы партнёра, которые являются authoritative за его зону. Вот, используя этот параметр, можно указать – как в данном случае будет вести себя ваш сервер, получив ответ – поверит в любом случае или удостоверится, что присылающий сервер является авторитативным за зону, из которой пришёл ответ.

Параметр -Timeout

Стандартный тайм-аут ответа удалённого сервера – 15 секунд. Вы можете повлиять на этот параметр – увеличив его (тогда далёкие сервера будут успевать отвечать), или уменьшив (тогда нерабочий сервер будет определяться быстрее).

Параметр -AdditionalTimeout

Это – плюсик к предыдущему параметру, показывающий, что если в запросе будет бит рекурсии, то надо дополнительно подождать – ведь удалённый сервер может куда-то сбегать и спросить. Стандартно это дополнительные 4 секунды, как у гранаты Ф1 (хотя сейчас они от 3.2 секунд бывают, так что DNS server чуток тормознее). Если настраиваете региональный DNS-сервер, который пробрасывает запросы по VPN до центрального офиса – возможно, надо увеличить данный параметр, это положительно повлияет на уменьшение false negative в кэше сервера.

Параметр -RetryInterval

Это то время, через которое DNS-сервер попробует заново отправить запрос, после того, как прошёл тайм-аут по предыдущему. По умолчанию – три секунды. Не ставьте меньше, если не уверены, что всё работает просто идеально и очень быстро – вначале разберитесь с предыдущими параметрами, цель – не ускорить запросы (вы их не ускорите, они вами только отправляются и принимается результат), а снизить частоту сбоев из-за раннего тайм-аута.

Ускоряем загрузку DNS-зон в Windows Server 2012 R2 и старше

Hotfix 3038024 приносит новую функциональность в DNS server в Windows Server 2012 R2 и старше. Заключается она в альтернативном механизме подгрузки зон и решении проблем с “зависшим” форвардером (это когда DNS server при наличии более одного форвардера почему-то после тайм-аута первого не пробует второй). Ключевое – действует этот метод только для серверов, которые подгружают зоны из файлов, а не из Active Directory – т.е. данный приём нужен только для проксирующих и держащих внешние зоны DNS-серверов.

До установки 3038024 обязательно установите апрельский update rollup. Microsoft пишет, что хотфикс меняет загрузку зон только в случае, если DNS-сервер стартует с параметром “Load zone data on startup: From registry” (это когда BootMethod будет равен 2), по факту же работает всегда – поэтому, кстати, этот хотфикс добавлен в Windows Server 2016 сразу же, как часть функционала.

В общем, пока всё.

Заключение

Надеюсь, что данная статья поможет Вам корректно и эффективно настроить сервис DNS в инфраструктуре предприятия. Ну, а про DNSSEC (как и ранее про EDNS0) – напишем отдельно. Удач!

Hello Ryan,
Not sure if I’m posting my questions in the correct place. I’ve been reading your RDS 2012 R2 blogs and they are definitely helpful.
I’m needing some help/guidance.

We are attempting to configure a “simple” RDS 2012 R2 Farm.
One RDS Connection Broker non-HA, with license server (a Standalone Server), and 4 separate RDSH 2012 R2 Servers.
We have configured the Connection Broker “Collection” with the 4 RDSH Servers and called RDSFarm.

We want the users to connect to the 4 RDSH Servers Remote Session Desktops via RDP 3389 (Users are using a Wyse T10D Terminal, but only using the RDSH Desktops not the ThinOS desktops of the Wyse Terminal).
We do not have a RDS Gateway configured, as we do not anticipate the need for remote external connections.
Our DNS has configured the 4 RDSH servers as 192.168.0.101 – 104 and the RDCB as .110.
We have made a DNS RR of the 4 RDSH with the DNS name of RDSFarm.

Couple of questions/issues:
1) Should we be pointing the users directly to the RDCB server?
And if so how do I set this up on the RDCB server?
What I’ve done: I’ve tested pointing users RDP sessions directly to the RDCB (.110) server, however they receive the error that the user does not have access, which makes sense in they don’t have access to the RDCB server.
I see in your instructions that you also use a RDGateway and it would seem to solve this issue, however is RDGateway a requirement for my setup or is it that I simply am missing something?

2) Currently when a user connects via RDP to the RDSFarm (DNS RR), they are requested to login their domain credentials twice.
I’m assuming that this is because they are routed to one RDSH server first via DNS RR and then the RDCB server takes over and reroutes them to a a different RDSH server.
Is there a way I can fix this so they only have to enter credentials once?

3) Does the RDP Client need any configuration in the “Gateway settings” section, perhaps entering in the RDCB server settings?

I hope this makes sense, it’s been difficult to find instructions for simplistic configurations of RDS 2012 R2, I.E. setups without the need for HA, RDGateway, RDWeb, and RDApps.

Thanks for your help,

Anthony

Ранее мы рассматривали пример построения фермы Remote Desktop Connection Broker (RDCB) на базе Windows Server 2008 R2. С выходом Windows Server 2012 технологии повышения доступности для служб RDS претерпели определённые изменения, в частности теперь для построения отказоустойчивой фермы RDCB не используются механизмы Windows Failover Cluster. В этой заметке мы попробуем рассмотреть процедуру создания новой фермы RDCB на базе Windows Server 2012 с применением Windows NLB, как средства повышения доступности и балансировки сетевой нагрузки для ролей RD Connection Broker и RD Web Access. После создания фермы RDCB выполним ряд настроек, которые позволят нам считать инфраструктуру RDS минимально подготовленной к использованию в соответствии со следующим планом:
— Среда исполнения
— Подготавливаем виртуальные сервера
— Создаём кластер NLB
— Подготавливаем SQL Server
— Устанавливаем роли Remote Desktop Services
— Создаём высоко-доступный RD Connection Broker
— Добавляем сервера в высоко-доступный RD Connection Broker
— Добавляем на сервера роль RD Web Access
— Создаём коллекцию сеансов – Session Collection
— Настраиваем цифровые сертификаты
— Настраиваем веб-узлы RD Web Access
— Настраиваем Roaming User Profiles и Folder Redirection
— Публикуем приложения RemoteApp
— Устанавливаем языковой пакет
— Настраиваем перенаправление печати

Среда исполнения

В рассматриваемом примере мы будем строить ферму RDCB из 5 виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 Datacenter EN. На всех виртуальных серверах устанавливается Windows Server 2012 Standard EN.

Каждый из виртуальных серверов будет иметь по два сетевых интерфейса, настройка которых будет рассмотрена далее.

Серверам присвоены имена – KOM-AD01-RDS21 , KOM-AD01-RDS22 , KOM-AD01-RDS23 , KOM-AD01-RDS24 , KOM-AD01-RDS25

Создаваемый в процессе описания высоко-доступный экземпляр RD Connection Broker а также NLB-кластер RD Web Access будут использовать общее виртуальное имя KOM-AD01-RDSNLB.

База данных высоко-доступного экземпляра RDCB будет расположена на отдельном кластере SQL Server c именем KOM-SQLCL 

С точки зрения сетевого взаимодействия, упрощённая схема отказоустойчивой фермы RDS в нашем случае будет выглядеть следующим образом:

Подготавливаем виртуальные сервера

Итак, у каждого виртуального сервера создадим по 2 сетевых адаптера. Назовём их условно на каждом сервере таким образом, чтобы было понятно за что отвечает этот интерфейс — NIC1 (Management) и NIC2 (NLB Cluster).

При создании второго сетевого адаптера NIC2, который будет использоваться для построения NLB в свойствах виртуальной машины Hyper-V необходимо разрешить спуфинг МАС адресов (Enable spoofing of MAC addresses)

Согласно нашей схемы, выделим и распределим статические IP адреса на серверах следующим образом:

Имя сервера	Настройки IP NIC1	Настройки IP NIC2 (NLB Cluster)
KOM-AD01-RDS21	IP 10.160.0.151/24	IP 10.160.0.141/24
KOM-AD01-RDS22	IP 10.160.0.152/24	IP 10.160.0.142/24
KOM-AD01-RDS23	IP 10.160.0.153/24	IP 10.160.0.143/24
KOM-AD01-RDS24	IP 10.160.0.154/24	IP 10.160.0.144/24
KOM-AD01-RDS25	IP 10.160.0.155/24	IP 10.160.0.145/24

На всех интерфейсах используются одинаковые настройки адреса шлюза по умолчанию -10.160.0.254 и адресов DNS — 10.160.0.253, 10.160.1.253. Причина использования именно такой сетевой конфигурации для построения NLB на базе Windows Server 2012 была ранее изложена в заметке App-V 5 for RDS — Разворачиваем инфраструктуру повышенной доступности

Интерфейс NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера), а NIC2 (для которого включён спуфинг MAC адресов) будет участником NLB кластера. Выполним настройку сетевых интерфейсов на каждом из серверов согласно вышеприведённой таблицы на примере сервера KOM-AD01-RDS21

Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).

NIC1 должен иметь приоритет над NIC2.

В свойствах сетевого подключения, которое будет использоваться для подключения к NLB кластеру (NIC2) можно отключить все компоненты, за исключением TCP/IPv4 и Client for Microsoft Networks:

В свойствах компонента TCP/IPv4 зададим настройки согласно приведённой ранее таблицы и по кнопке Advanced откроем окно дополнительных настроек

В окне дополнительных настроек TCP/IP на закладке DNS отключим механизм регистрации в DNS:

Интерфейс NIC1 настроим согласно вышеприведённой таблицы аналогичным образом, за исключением того, что на нём может быть включена опция регистрации в DNS и обязательно должны быть включены компоненты TCP/IPv4 , Client for Microsoft Networks и File and Printer Sharing for Microsoft Networks

После того как описанным способом настроены сетевые интерфейсы на всех серверах, зарегистрируем их имена в доменной зоне прямого просмотра DNS (если запрещена динамическая регистрация в DNS и/или отключена опция регистрации в свойствах интерфейсов NIC1). Для пакетной регистрации A-записей в DNS можно воспользоваться скриптом описанным в заметке DNS – Пакетное создание А-записей с помощью WMI и Powershell 

Дополнительно сразу же создаём статическую А-запись для будущего NLB кластера.

RD Connection Broker использует для хранения БД сессий общий экземпляр SQL Server, поэтому все сервера RDCB должны иметь «на борту» клиентские компоненты SQL Server, а также привилегии доступа к SQL Server. Настройку доступа к SQL Server выполним позже, а пока установим на каждый сервер, где планируется развертывание RD Connection Broker, свежую версию пакета Microsoft SQL Server 2012 Native Client (в нашем случае установка нужна на всех пяти виртуальных серверах). Скачать его можно со страницы загрузки Microsoft SQL Server 2012 SP1 Feature Pack (файл sqlncli.msi)

После установки клиента SQL Server создадим на каждом сервере SQL-Alias, который будем в дальнейшем использовать для подключения серверов RDCB к серверу SQL Server. Этого конечно можно и не делать, но это может оказаться полезным (даст нам дополнительную гибкость) в случае необходимости переноса БД на другой SQL-сервер или даже экземпляр. Запустим встроенную в ОС утилиту SQL Server Client Network Utility (C:windowssystem32cliconfg.exe) и добавим два новых алиаса – с коротким именем сервера и FQDN

Фактически созданные SQL-алиасы в интерфейсе утилиты были записаны в ключ реестра HKLMSOFTWAREMicrosoftMSSQLServerClientConnectTo

Теперь нужно проверить созданные нами SQL-алиасы. Для этого создадим пустой файл Universal Data Link с расширением *.udl и запустим его. На закладке Connection укажем SQL-алиас, выберем режим аутентификации Use Windows NT Integrated security и нажмём кнопку Test Connection

Если мы всё сделали правильно, то получим положительный результат подключения. При этом перечень всех активных БД на новом SQL сервере будет доступен в выпадающем списке Select the database on the server. Таким образом проверим алиас созданный как по NetBIOS имени так и по FQDN.

***

Далее, с помощью PowerShell установим на каждый сервер исполняемые компоненты NLB

Import-Module "ServerManager" 
Add-WindowsFeature "NLB" -IncludeManagementTools

Создаём кластер NLB

На первом виртуальном сервере (KOM-AD01-RDS21) открываем консоль Network Load Balancing Manager (nlbmgr.exe). Выбираем пункт меню Cluster > New Cluster

Вводим имя первого узла, который хотим добавить в NLB, кнопкой Connect подключаемся к нему, и получив с него набор доступных интерфейсов, выбираем тот который хотим сделать участником кластера:

На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:

В следующем окне мастера создания кластера добавляем IP адрес NLB кластера, на который мы ранее в DNS зарегистрировали А-запись.

Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. Режим работы кластера – режим одноадресной рассылки – Unicast.

На странице правил портов (Port rules) удаляем имеющееся по умолчанию правило и добавляем необходимые нам правила. При добавлении правила портов убираем флажок All и указываем конкретный интерфейс NLB и диапазон портов, который хотим добавить в кластер NLB.

В общей сложности, в нашем примере балансировке в NLB кластере мы будем подвергать следующие порты:

TCP 443 – для подключения клиентов к RD Web Access;
TCP/UDP 3389 – для подключения клиентов к RD Connection Broker/Session Host;

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

Далее, переходим на имя NLB кластера и пунктом меню Add Host to Cluster вызываем мастер добавления второго и последующих серверов в кластер.

В конечном итоге после добавления (по аналогии с первым узлом) всех серверов мы получим работоспособный Windows NLB кластер

С помощью Ping -t проверяем из клиентской подсети доступность кластерного интерфейса по очереди перезагружая узлы кластера, а затем друг за другом выключая их до тех пор пока в кластере не останется один живой узел. 

Подготавливаем SQL Server

Создадим в AD группу безопасности, например KOM-AD01-RDS-Connection-Broker-Computers, и включим в нее учетные записи наших виртуальных серверов.

После этого подключимся к экземпляру SQL Server на котором будет размещаться БД RDCB (в нашем случае это отдельный кластер SQL Server из двух серверов), создадим новый SQL Login с привязкой к указанной доменной группе. При создании SQL-логина ему будет присвоена серверная роль SQL Server – public, которая даст право подключаться к экземпляру SQL Server. Включим ещё одну серверную роль – dbcreator. Эта роль понадобится нам лишь на время первоначальной инициализации БД RDCB для того, чтобы учетная запись сервера, на котором мы будем запускать процесс создания отказоустойчивого RDCB, смогла выполнить операцию создания новой БД.

Дополнительно на SQL сервере создадим каталог для файлов базы данных RDCB. В нашем случае это будет каталог U:SQLData_SQL01_RDCB на кластерном диске SQL сервера.

Устанавливаем роли Remote Desktop Services

Так как консоль Server Manager в Windows Server 2012 поддерживает групповую настройку сразу нескольких серверов, перед тем как разворачивать на наши виртуальные сервера роли RDS, объединим их в логическую группу. На любом из виртуальных серверов, например на KOM-AD01-RDS21, откроем консоль Server Manager и выберем пункт меню Manage > Create Server Group

добавим пять наших виртуальных серверов в группу и дадим ей название, например RDS-FARM.

После этого выберем пункт меню Manage > Add Roles and Features Wizard

В открывшемся мастере добавления ролей выберем режим установки служб RDS — Remote Desktop Services installation

 

  Тип развёртывания — Standard deployment

Сценарий развертывания выбираем Session-based desktop deployment, так как планируется развертывание серверов сеансов, а не серверов инфраструктуры VDI 

На этапе выбора ролей RDS нас предупредят о том, что будет выполняться развертывание сразу трёх ролей —  RD Connection Broker, RD Session Host, RD Web Access, не оставляя при этом нам никакого выбора…

На этапе выбора серверов для роли RD Connection Broker выбираем один сервер, ибо мастер не даст нам выбрать более одного сервера. Так как всю первоначальную настройку мы выполняем на сервере KOM-AD01-RDS21, то соответственно и выберем его для этой роли…

На этапе выбора серверов для роли RD Web Access включим опцию Install the RD Web Access role on the RD Connection Broker server для того чтобы эта роль была установлена на тот же сервер, который был выбран для роли RDCB. Выбирать какой-то другой сервер в нашей ситуации особого смысла нет, да и потом мастер опять таки не даст нам выбрать для установки этой роли более чем один сервер…

На этапе выбора серверов для роли RD Session Host мы сможем выбрать все сервера…

 
На странице подтверждения мы видим предупреждение, что серверы могут быть перезагружены после установки роли RD Session Host. Включим опцию автоматической перезагрузки серверов — Restart the destination server automatically if required и запустим процесс развёртывания..

В процессе установки ролей первым будет автоматически перезагружен сервер, с которого мы запустили весь этот процесс, поэтому мы отвалимся от его консоли. Пугаться не надо… После того, как система поднимется из перезагрузки, снова залогинимся и запустим консоль Server Manager, где через несколько секунд автоматически запустится мастер развертывания ролей RDS и мы сможем убедиться в том, что процесс развертывания успешно прошёл до конца на всех серверах.

В нашем примере мастер сообщил о том, что на двух серверах из пяти не удалось установить службу RDSH, хотя последующая проверка этих серверов свидетельствовала об обратном. В системном журнале Applications and Services Logs > Microsoft > Windows > ServerManager-DeploymentProvider > Operational было зарегистрировано событие говорящее об успешной установке компонент…

Ну и соответственно PS-запрос состояния компонент RDS показывал что роль RDSH установлена..

В любом случае если Server Manager упорно будет говорить вам о том, что роль RD Session Host не установлена на каких-то серверах, то для того чтобы заставить её «прокашляться», можно повторить процедуру установки через мастер добавления ролей RDS на вкладке управления службами Remote Desktop Services > Overview

Создаём высоко-доступный RD Connection Broker

После окончания процесса установки ролей в консоли Server Manager и перейдём на вкладку управления службами Remote Desktop Services > Overview, чтобы приступить к созданию отказоустойчивой конфигурации RD Connection Broker.

На схеме инфраструктуры RDS выберем изображение роли RD Connection Broker и правой кнопкой мыши вызовем меню, в котором выберем пункт Configure High Availability.

Запустится мастер создания высоко-доступного экземпляра RDCB, где нас предупредят о необходимых условиях, которые мы уже предварительно выполнили, за исключением последнего пункта, который предполагает создание в DNS A-записей c одинаковым FQDN именем RDCB и IP адресами всех серверов (для работы механизма Round Robin). Откажемся от концепции использования DNS Round Robin для получения клиентами имени точки подключения к ферме RDCB. Вместо этого мы будем использовать имя созданного ранее NLB кластера.

На следующем шаге мастера Configure High Availability заполняем значения трёх полей:

Database connection string – строка подключения к БД SQL Server. Значение должно иметь вид: DRIVER=SQL Server Native Client 11.0 (10.50 для SQL Server 2008 R2);SERVER=<FQDN-Имя или SQL-Alias сервера SQL Server>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<Имя БД>

В нашем случае это значение будет иметь следующий вид:

DRIVER=SQL Server Native Client 11.0;SERVER=KOM-AD01-SQL-RDCB.holding.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDS_ConnectionBroker

Folder to store database files — путь ранее подготовленного каталога U:SQLData_SQL01_RDCB на кластерном диске SQL сервера. В этом каталоге будут размещены файл данных и лога транзакций SQL Server при создании БД RDCB.

DNS round robin name – имя точки подключения клиентов. Как я уже сказал, здесь предполагается ввод значения FQDN-имени созданного в DNS с несколькими A-записями. В нашем примере, в качестве такого имени, мы будем использовать имя созданного ранее NLB кластера – KOM-AD01-RDSNLB.holding.com

Далее мы получим предупреждение о том, что указанное нами имя DNS RR имеет отличный IP адрес от того, для которого выполняется установка HA RDCB. Мы идём на этот шаг намеренно и поэтому соглашаемся…

Дожидаемся успешного окончания процесса конфигурирования высокой доступности.

В ходе этого процесса на SQL-сервере будет создана БД высоко-доступного экземпляра RDCB.

***

Переключимся на наш SQL Server с только что созданной БД и выполним пару настроек…

В обязательном порядке для SQL-логина, который мы создавали на подготовительном этапе (KOM-AD01-RDS-Connection-Broker-Computers), нужно дать роль db_owner для созданной базы RDS_ConnectionBroker

Помимо этого, для данного SQL-логина можно отключить добавленную ранее серверную роль dbcreator, так как БД уже создана и больше данная привилегия этому SQL-логину не потребуется.

Если резервное копирование баз данных SQL Server выполняется такими инструментами как например SC 2012 DPM, то при желании мы можем поменять модель восстановления созданной БД (Recovery Model) c Full на Simple.

***

Вернёмся на наш сервер KOM-AD01-RDS21 и обратим внимание на то, что в консоли Server Manager в схеме инфраструктуры RDS статус роли RDCB поменялся на High Availability Mode

Теперь для того чтобы задуманная нами связка NLB + RDCB работала так как нужно, нам необходимо до-установить роль RD Connection Broker на оставшиеся четыре сервера.

Добавляем сервера в высоко-доступный RD Connection Broker

Добавление серверов к высоко-доступной конфигурации RDCB делается через то же самое контекстное меню в схеме развертывания RDS на странице Overview.

В открывшемся мастере добавляем следующий сервер (мастер также не даст добавить более одного сервера)

После успешного добавления роли на выбранный сервер и подключение этого сервера к БД HA RDCB мы получим предупреждение о необходимости настройки сертификатов, которое пока можем проигнорировать, так как займёмся сертификатами позже.

Аналогичным образом мы по одному серверу должны добавить роль HA RDCB на все оставшиеся сервера, те. KOM-AD01-RDS23, KOM-AD01-RDS24 и KOM-AD01-RDS25.

Добавляем на сервера роль RD Web Access

Так как мы хотим иметь отказоустойчивую конфигурацию роли RD Web Access, нам нужно до-установить эту роль на оставшиеся четыре сервера (на KOM-AD01-RDS21 эта роль уже установлена). Делаем это в уже знакомом нам месте через мастер добавления ролей

Здесь уже мы сможем выбрать сразу все серверы и выполнить установку роли RDWA оптом…

Создаём коллекцию сеансов – Session Collection

Все наши сервера с ролью RD Session Host мы должны объединить в логическую единицу – коллекцию сеансов (Session Collection). Делаем это в оснастке Server Manager на вкладке Remote Desktop Services > Collections выбрав задачу Create Session Collection в таблице перечисления коллекций.

В открывшемся мастере создания коллекции зададим имя коллекции и при желании описание

Затем выбираем все сервера, которые хотим сделать членами коллекции…

Далее мы должны определить доменную группу безопасности которой будет разрешено подключаться к коллекции сеансов. Убираем выбранную по умолчанию группу доступа Domain Users и добавляем специально созданную группу доступа, в нашем случае KOM-AD01-RDS-AllUsers, ограничив тем самым круг пользователей которые смогут подключаться к серверам коллекции.

На следующем шаге определяемся с тем, хотим ли мы использовать новую технологию Windows Server 2012 – User profile disks (UPD), которая, как я понял, предлагается в качестве альтернативы механизму перемещаемых профилей — Roaming User Profiles. Новая технология подразумевает централизованное хранение файлов пользователя в отдельных VHD дисках, которые располагаются где-то на выделенном файловом ресурсе. В силу того, что на данный момент нет уверенности в стабильности работы данного механизма из-за полученной информации в обсуждении Windows Server 2012 RDS — [User Profile Disk] VS [Roaming Profiles + Folder Redirection] я решил пока не использовать данный функционал и поэтому он не будет рассмотрен в данной заметке.

А пока не будут разрешены имеющиеся на данный момент проблемы с UPD будем использовать связку технологий Roaming User Profiles и Folder Redirection, настройка которых рассматривалась ранее в заметке Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки 

В результате работы мастера все наши сервера успешно добавляются в коллекцию с предупреждениями о том, что желательна настройка групповых политик для задания параметров RDP на этих серверах…

Настраиваем цифровые сертификаты

При попытке подключения к ферме RD Connection Broker по FQDN-имени кластера NLB клиенты могут получать предупреждение безопасности, говорящее о том, что нет доверия сертификату того сервера сеансов, на который он был перенаправлен. Если открыть свойства этого сертификата, мы увидим, что сертификат создаваемый на сервере RDSH по умолчанию является самоподписанным. Чтобы избежать таких предупреждений нам нужно создать для развёртывания RDS сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС. Этот сертификат после создания мы развернём на всех серверах фермы.

При создании запроса на сертификат нужно использовать как минимум 2 политики применения:

Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)

Хотя в нашей ситуации альтернативные имена в сертификате Subject Alternative Name (SAN) иметь вовсе необязательно, я всё-таки рассмотрю вариант создания именно такого сертификата, то есть чтобы помимо имени NLB кластера в сертификате содержались имена отдельных серверов.

Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. О том как это сделать можно прочитать в заметке Remote Desktop Services – Строим отказоустойчивую ферму RD Connection Broker

Подготовим файл параметров для создания запроса на получение нужного нам сертификата. Это обычный текстовый файл, назовём его например RequestPolicy.inf

Содержимое этого файла в нашем примере выглядит так:

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-RDSNLB.holding.com" ; 
Exportable = TRUE; Private key is exportable 
KeyLength = 2048 
KeySpec = 1; Key Exchange – Required for encryption 
KeyUsage = 0xA0; Digital Signature, Key Encipherment 
MachineKeySet = TRUE 
ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
RequestType = PKCS10

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication 
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication 
  
[RequestAttributes] 
SAN  = "dns=KOM-AD01-RDSNLB.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS21.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS22.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS23.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS24.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS25.holding.com&" 
_continue_ = "dns=KOM-AD01-RDSNLB&" 
_continue_ = "dns=KOM-AD01-RDS21&" 
_continue_ = "dns=KOM-AD01-RDS22&" 
_continue_ = "dns=KOM-AD01-RDS23&" 
_continue_ = "dns=KOM-AD01-RDS24&" 
_continue_ = "dns=KOM-AD01-RDS25&"

С помощью встроенной в ОС утилиты CertReq.exe создадим файл запроса на основе файла параметров:

cd /d C:Temp
CertReq –New RequestPolicy.inf RequestFile.req

Выполнять эту команду надо локально на сервере RDS. В нашем случае команда выполняется на сервере KOM-AD01-RDS21. После выполнения команды откроем консоль управления локальными сертификатами (mmc.exe > Add/Remove snap-in > Certificates > Add > Computer account) для хранилища Local Computer и убедимся в появлении ожидающего запроса в разделе Certificate Enrollment Request

Полученный файл запроса RequestFile.req добавляем в локальный центр сертификации через консоль управления Certification Authority (certsrv.msc) (All Tasks > Submit new request)

Затем в этой же консоли в разделе Pending Requests проверяем наш добавленный запрос и разрешаем выдачу сертификата по нему (Выбираем запрос > All Tasks > Issue )

Переходим в раздел выданных сертификатов — Issued Certificates, находим сертификат, открываем его свойства и на закладке Details вызываем мастер экспорта сертификата (Copy to File)

В открывшемся мастере выбираем формат экспорта DER X.509 и сохраняем файл например с именем NLBCert.cer

Скопируем полученный файл NLBCert.cer на сервер RDS, где мы создавали запрос на сертификат (KOM-AD01-RDS21) и вернёмся в консоль управления локальными сертификатами этого сервера. Выберем хранилище Personal > Certificates и вызовем мастер импорта сертификатов (All Tasks > Import)

В мастере импорта автоматически будет выбрано хранилище Local Machine

Далее выберем импортируемый файл сертификата NLBCert.cer и укажем раздел хранилища PersonalRegistry. Чтобы этот раздел был доступен для выбора, нужно включить опцию Show physical stores.

После того как импорт сертификата выполнен, убеждаемся что он появился в соответствующем хранилище и с ним связан его закрытый ключ (присутствует значок ключика на иконке). При этом в разделе Certificate Enrollment Request информация о запросе должна исчезнуть.

Далее выбираем установленный сертификат и вызываем мастер экспорта (All Task > Export). В мастере экспорта выбираем опцию экспорта закрытого ключа при экспорте сертификата – Yes, export the private key

В качестве формата экспорта используем единственно возможный и нужный нам формат .PFX

Далее задаем пароль (он потребуется нам в дальнейшем для назначения этого сертификата в развёртывании RDS)

После того как сертификат экспортирован, переходим в консоль Server ManagerRemote Desktop ServicesOverview и на схеме развёртывания в списке задач выбираем пункт редактирования развёртывания (TASKS > Edit Deployment Properties)

На вкладке Certificates используем кнопку Select existing cerificates для того чтобы назначить сделанный нами сертификат для той или иной роли RDS…

В окне выбора сертификата определяем, что мы хотим использовать файл PFX полученный нами ранее и задаём пароль с которым этот сертификат был экспортирован. Хотя опция Allow the certificate to be added to the Trusted Root CA нам по сути не нужна, так как созданный нами сертификат сделан в ЦС, которому предположительно все наши сервера уже доверяют, её всё таки придётся отметить, так как если она не отмечена, кнопка OK недоступна…

После закрытия этого окна по ОК, мы увидим что в таблице статус сертификата изменился на Ready to apply..Нажмём кнопку Apply и через несколько секунд наш сертификат будет назначен роли соответствующей RDS. Описанным методом мы выполним привязку сертификатов ко всем развёрнутым у нас ролям и в конечном итоге получим примерно следующий вид:

Назначенные нами сертификаты будут автоматически установлены на все сервера, которые участвуют в нашем RDS развёртывании.

Настраиваем веб-узлы RD Web Access

По умолчанию при обращении в стартовой веб-странице RDWA от пользователя в явном виде требуется ввод учетной записи и пароля. Если мы используем RDWA для доменных пользователей внутри локальной сети, то для удобства нам нужно будет задействовать механизм прозрачного входа Single sign-on (SSO) при обращении к веб-узлу RDWA. Для этого на каждом сервере с установленной ролью RDWA в оснастке IIS Manager откроем свойства веб-приложения RDWeb > Pages выберем в разделе настроек пункт Authentication…выключим анонимную аутентификацию (Anonymous Authentication), аутентификацию на основе формы (Forms Authentication) и включим Windows Authentication:

***

После входа на веб-страницу RDWA можно обнаружить уже знакомый нам по предыдущей версии опцию I am using a private computer that complies with my organization’s security policy (в русском варианте — Я использую личный компьютер, соответствующий политике безопасности моей организации).

Ранее, в заметке RDS Web Access – Опция «Я использую личный компьютер…», я писал о том, как выставить эту опцию во включенное состояние по умолчанию, чтобы избежать повторного запроса аутентификации при подключении к опубликованным приложениям RemoteApp в Windows Server 2008 R2. Это рецепт работает и для Windows Server 2012.

***

Верхняя часть страниц RDWA по умолчанию оформлена в виде заголовочной надписи Work Resources и изображения размером 48*48 пикселей.

Для того чтобы заменить заголовочную надпись можно использовать командлет PowerShell (один раз для всей коллекции серверов):

Set-RDWorkspace -Name "Приложения RemoteApp" -ConnectionBroker KOM-AD01-RDS21.holding.com

 

Для того чтобы заменить имеющееся изображение на другое, например с корпоративной символикой, можно внести корректировки в файл %windir%WebRDWebPagesSite.xsl – найти секцию с комментарием «Replaceable Company Logo Image«…

… и заменить ссылку на файл изображения, указав собственный файл размещённый в соответствующем подкаталоге %windir%WebRDWebPagesimages

В результате мы получим примерно следующий вид верхней части страниц RDWA:

Настраиваем Roaming User Profiles и Folder Redirection

Так как пользователи нашей фермы RDS от сеанса к сеансу могут попадать на разные сервера, нам необходимо обеспечить идентичность пользовательской среды на всех этих серверах. Для этого мы будем использовать механизмы перемещаемых профилей (Roaming User Profiles ) и перенаправления папок (Folder Redirection). Для настройки этих механизмов настраиваем групповую политику применяемую к серверам нашей фермы RDS. Здесь мы не будем рассматривать эту процедуру, так как она уже была ранее описана мной в заметке Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки

Публикуем приложения RemoteApp

Чтобы опубликовать в ферме RDS приложения RemoteApp переходим в консоль Server Manager в раздел Remote Desktop Services > Collections > выбираем нашу коллекцию KOM-AD01-RDSH-COLL и публикуем необходимые приложения в окне REMOTEAPP PROGRAMS. В меню задач выбираем пункт публикации TASKS > Publish RemoteApp Programs

Для примера опубликуем два простых приложения Calculator и WordPad

 
Опубликованные приложения доступны клиентам нашей фермы RDS двумя основными способами – через веб-интерфейс RD Web Access и через непосредственную доставку ярлыков запуска на клиентские компьютеры. С первым способом, полагаю, всё итак понятно, рассмотрим второй. Для того чтобы ярлыки опубликованных приложений RemoteApp стали доступны на клиенте с Windows 7/8, нужно выполнить подписку на узел RDWA в Панели управления (апплет Подключения к удаленным рабочим столам и приложениям RemoteApp). Щелкнув по ссылке Доступ к удалённым приложениям RemoteApp и рабочим столам мы вызовем мастер подключения, где в адресной строке укажем URL RDWA в формате http://KOM-AD01-RDSNLB.holding.com/RDWeb/Feed/WebFeed.aspx

В примерах описанных в окне подключения можно заметить вариант с указанием адреса, похожего на адрес электронной почты —  alexeyo@contoso.com. На самом деле такой метод указания адреса не столько имеет отношение к электронной почте, сколько относится к методу автоматического обнаружения сервера публикации RemoteApp с помощью специальных записей в зоне прямого просмотра DNS. То есть мастеру подключения важно лишь то, что указано после символа @ – имя зоны DNS. До символа @ можно написать любую ерунду. Например, в нашем примере в DNS используется зона holding.com и в качестве адреса мы можем указать например blablabla@holding.com

В зоне DNS соответственно при использовании такого метода должна быть создана специальная запись формата TXT c именем _msradc и текстовым значением в формате https://rds.domain.com/rdweb/feed 
Соответственно в нашем примере запись будет иметь следующий вид:

После того как запись создана, проверим то, что DNS сервер возвращает нам значение этой записи с помощью утилиты nslookup в режиме set querytype=TXT и если всё в порядке, то теперь в качестве адреса подключения можем указать соответствующее значение

При этом из DNS будет возвращён URL-адрес подключения…

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

При этом в меню “Пуск” для Windows 7 и в стартовом экране для Windows 8 в отдельной группе появятся ярлыки на запуск приложений RemoteApp

Если вам потребуется каким-то альтернативным способом распространять ярлыки на приложения RemoteApp, то их можно будет найти на клиентской машине подключённой вышеописанным способом к точке публикации RDWA в каталоге
%APPDATA%MicrosoftWorkspaces{GUID}Resource

Нововведением Windows 8 стал ещё один способ подключения клиентов к точке публикации – с помощью групповых политик (GPO). За это отвечает параметр
Specify default connection URL в разделе User Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/RemoteApp and Desktop Connections. Для настройки клиентов нужно включить этот параметр и указать значение URL-адреса подключения в формате:
https://KOM-AD01-RDSNLB.holding.com/rdweb/Feed/webfeed.aspx

Как я уже сказал, этот параметр поможет нам настроить только клиентов Windows 8, но если у вас есть сильное желание раздать через GPO настройку и для клиентов Windows 7 – читайте статью Concurrency Blog — How to deliver RemoteApps from Windows Server 2012 RDS. Метод заключается в применении на клиентских машинах PowerShell скрипта Configure RemoteApp and Desktop Connection on Windows 7 Clients с передачей ему в виде параметра файла настроек в следующем формате:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<workspace name="Enterprise Remote Access" xmlns="http://schemas.microsoft.com/ts/2008/09/tswcx" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<defaultFeed url="https://KOM-AD01-RDSNLB.holding.com/rdweb/Feed/webfeed.aspx" />
</workspace>

Устанавливаем языковой пакет

Так как в нашем примере на серверах фермы RDS используется англоязычная система, нам потребуется установка языкового пакета для локализации интерфейса пользователя. Чтобы получить файлы русского языкового пакета распаковываем образ содержащий все языковые пакеты для Windows Server 2012 RTM SW_DVD5_NTRL_Win_Svr_Language_Pack_2012_64Bit_MultiLang_FPP_VL_OEM_X18-27741.ISO

Извлекаем файл langpacksru-rulp.cab из состава образа и вызываем на сервере RDS мастер установки языковых пакетов командой lpksetup

Помимо этого установку языкового пакета можно выполнить командой:

Dism /online /Add-Package /PackagePath:"C:DistributivesWS2012RTMLanguagePacklp.cab"

Практика показывает, что после выполнения этой команды, для того чтобы в панели управления появилась информация о том, что языковой пакет действительно установлен, – необходима перезагрузка системы. После перезагрузки сервера RDS переходим в панель управления в раздел Language и выделив русский язык кнопкой Move Up поднимаем его на первую позицию, сделав его таким образом приоритетным языком интерфейса.

Далее открываем апплет панели управления Control Panel > Region (intl.cpl) , проверяем и при необходимости настраиваем параметры на родной язык на закладках Formats и Locations , а затем на закладке Administrative нажимаем Copy settings, чтобы скопировать языковые предпочтения текущего пользователя для всех пользователей которые будут первый раз входить в эту систему.

Убедимся что у текущего пользователя установлены такие настройки, которые мы хотим иметь у всех пользователей сервера RDS и включим галочку New user accounts

Не рекомендую использовать опцию копирования русских настроек в системный профиль (галка Welcome screen and system accounts), так как это в перспективе может привести к невменяемой работе некоторых “буржуйских” программ, проблемы в которых возникают чаще всего из-за знака разделителя целой и дробной части.

Настраиваем перенаправление печати

Для того чтобы пользователи служб удалённых рабочих столов смогли выполнять печать на перенаправленные с их клиентских мест устройств печати, выполним ряд нехитрых манипуляций.
Установим на сервера RDS консоль управления службой печати – Print Management, например с помощью PowerShell:

Add-WindowsFeature RSAT-Print-Services

Если есть сильное желание управлять службой печати на всех серверах например с рабочей станции Администратора, то для того, чтобы можно было удалённо подключаться к службе печати, на серверах необходимо включить параметр групповой политики Allow Print Spooler to accept client connections в разделе Computer ConfigurationPoliciesAdministrative TemplatesPrinters. После применения политики на серверах нужно перезапустить службу очереди печати — Print Spooler.
На мой взгляд использовать локально установленную на серверах консоль – более предпочтительно.

После установки открываем консоль, добавляем в неё наши сервера, и в свойствах сервера печати для каждого сервера выполняем необходимые изменения настроек, например на закладке Advanced отключаем включённые по умолчанию оповещения сетевых и локальных принтеров…

К слову об использовании именно локальной консоли…эти две опции недоступны для изменения (попросту не видны) если вы подключаетесь консолью удалённо.

На закладке Drivers добавляем драйвера принтеров, которые используются для печати на клиентских компьютерах. Драйвера принтеров нужно добавлять исходя из принципа разумного минимума. Например вместо того чтобы для принтеров Hewlett-Packard добавлять несколько драйверов для конкретных моделей лучше добавить один универсальный драйвер HP Universal Print Driver (UPD), в случае если принтеры поддерживают работу на данном драйвере. В нашем примере используется текущая версия (на момент написания этой заметки) UPD совместимая с Windows Server 2012 — 5.6.5.15717. Разумеется добавлять драйвера производителей оборудования вообще имеет резон только в том случае если тесты показывают, что принтер не выполняет поставленные задачи печати на драйвере Remote Desktop Easy Print.

В конфигурации по умолчанию для принтеров перенаправляемых с пользовательских компьютеров система будет использовать драйвер Remote Desktop Easy Print. Если мы загружаем на сервера RDS драйвера производителей принтеров, как например тот же HP UPD, то возможно нам стоит переопределить такое поведение, то есть, чтобы приоритетным для использования считался драйвер вендора железки, а уж если его не удалось найти – использовать RD Easy Print. Задаётся это параметром групповой политики Use Remote Desktop Easy Print printer driver first = Disabled в разделе Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostPrinter Redirection

После применения GPO в пользовательской терминальной сессии проверяем какой драйвер был назначен для перенаправленного принтера…

На этом, в целом, можно считать, что мы выполнили основные этапы создания и настройки отказоустойчивой фермы RD Connection Broker на базе Windows Server 2012. В отдельной следующей заметке мы рассмотрим пример настройки пользовательского интерфейса на сервера RD Session Host.

Полезные ссылки по теме:

Remote Desktop Services Blog — RD Connection Broker High Availability in Windows Server 2012
VirtualizationAdmin.com — Taking a closer look at RD Connection Broker High Availability in Windows Server 2012
TechNet Articles  —  RD Connection Broker HA – SQL Permissions
Freek Berson Blog — RD Connection Broker HA and the RDP properties on the client
Blog Working Hard In IT — Reflections on Getting Windows Network Load Balancing To Work (Part 1)
Blog Working Hard In IT — Reflections on Getting Windows Network Load Balancing To Work (Part 2)

Статья описывает одну из технологий балансировки нагрузки, которая может быть реализована средствами DNS.

Теория

---

Для перевода имени хоста в IP-адрес клиент DNS направляет серверу DNS рекурсивный запрос (т.е. запрос, на который сервер DNS возвращает клиенту либо ответ с IP адресом, либо ответ с ошибкой).

В подавляющем большинстве случаев в зонах DNS содержится только один IP адрес, соответствующий тому или иному имени хоста. А какой IP адрес будет возвращать клиенту сервер DNS, если зона содержит несколько записей типа A для одного и того же имени? Ответ простой: сервер DNS всегда возвращает клиенту все IP адреса, соответствующие запрашиваемому имени. А дальше клиент пытается связаться с первым IP адресом в списке и, если он не будет найден, делает попытку связаться со вторым адресом и т.д.

Предположим, у меня есть несколько зеркальных веб-сайтов по имени www.gorbunov.pro, расположенных на разных площадках и имеющих IP адреса 20.0.0.1, 30.0.0.1 и 40.0.0.1.

В ответ на рекурсивный запрос клиента об имени www.gorbunov.pro сервер DNS вернет клиенту весь набор записей из зоны:

www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1

Поскольку адрес 20.0.0.1 идет первым в списке, клиент всегда будет пытаться связаться именно с сайтом по адресу 20.0.0.1. Получается, что сайты 30.0.0.1 и 40.0.0.1 используются только как пассивный резерв. До тех пор, пока «жив» сайт по адресу 20.0.0.1, сайты 30.0.0.1 и 40.0.0.1 не получат от клиента ни одного запроса.

Как сделать, чтобы запросы “доставались” всем хостам? Ответ простой: настроить на сервере DNS функцию Round robin.

При включенной функции Round robin сервер DNS постоянно «перемешивает» ответы клиентам, поэтому на первый запрос клиента DNS об имени www.gorbunov.pro сервер DNS вернет ответ

www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1

На второй запрос от клиента или от другого сервера DNS будет возвращен ответ

www.gorbunov.pro 30.0.0.1
www.gorbunov.pro 40.0.0.1
www.gorbunov.pro 20.0.0.1

На третий запрос будет ответ

www.gorbunov.pro 40.0.0.1
www.gorbunov.pro 20.0.0.1
www.gorbunov.pro 30.0.0.1

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

Практика

---

Проверка работы DNS Round robin

В Windows Server опция Enable round robin включена по умолчанию. Достаточно в консоли DNS Manager открыть свойства DNS сервера и посмотреть вкладку Advanced.

Для практической проверки функционала DNS Round robin создаем зону gorbunov.pro и добавляем в нее три записи для хоста www.

Если вы попробуете теперь “попинговать” хост www.gorbunov.pro, то с удивлением обнаружите, что клиент все время отправляет пакеты на адрес 20.0.0.1 (выделено красным). Понятно, что ответа от хоста нет, но и DNS Round robin не работает!

C:>ping www.gorbunov.pro

Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 20.0.0.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:>ping www.gorbunov.pro

Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 20.0.0.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:>

Анализ кэша DNS на стороне клиента дает следующий результат:

C:>ipconfig /displaydns

Windows IP Configuration

    www.gorbunov.pro
    —————————————-
    Record Name . . . . . : www.gorbunov.pro
    Record Type . . . . . : 1
    Time To Live  . . . . : 3567
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 20.0.0.1

    Record Name . . . . . : www.gorbunov.pro
    Record Type . . . . . : 1
    Time To Live  . . . . : 3567
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 30.0.0.1

    Record Name . . . . . : www.gorbunov.pro
    Record Type . . . . . : 1
    Time To Live  . . . . : 3567
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 40.0.0.1

C:>

Теперь становится понятно, почему мы “пингуем” один и тот же хост 20.0.0.1. Сервер DNS возвращает клиенту все записи из зоны с указанием времени кэширования, равным по умолчанию 1 часу (или 3600 секундам). Поэтому до истечения времени кэширования (TTL – Time To Live) клиент больше не направляет к серверу DNS никаких новых запросов.

Сброс кэша командой ipconfig / flushdns и новая команда
ping www.gorbunov.pro приводят, наконец к желаемому результату.

C:>ipconfig /flushdns

Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

C:>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [30.0.0.1] with 32 bytes of data:
Request timed out.

Ping statistics for 30.0.0.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:>

Теперь ясно, что для правильной работы DNS Round robin потребуется изменение параметров кэширования, чтобы клиенты постоянно получали обновленный список с “перемешанными” записями.

Настройка времени кэширования ответов DNS

Возможные варианты:

• постоянный сброс кэша на стороне клиента (плохой вариант);
• установка времени кэширования, равное нулю, в свойствах зоны (плохой вариант, поскольку влияет на всю зону);
• установка индивидуального времени кэширования на отдельных записях (хороший вариант).

Для настройки индивидуального времени кэширования в консоли DNS Manager требуется сначала включить режим View –> Advanced. Затем последовательно открываем свойства записей (в нашем примере это три записи www) и ставим время кэширования, равное нулю.

Проверка работы дает в конце концов желаемый результат!

C:>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [20.0.0.1] with 32 bytes of data:
Request timed out.

Ping statistics for 20.0.0.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [30.0.0.1] with 32 bytes of data:
Request timed out.

Ping statistics for 30.0.0.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:>ping www.gorbunov.pro –n 1

Pinging www.gorbunov.pro [40.0.0.1] with 32 bytes of data:
Request timed out.

Ping statistics for 40.0.0.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:>

Файл зоны на сервере DNS при этом будет выглядеть так:

;
;  Database file gorbunov.pro.dns for gorbunov.pro zone.
;      Zone version:  7
;

@   IN  SOA dc01.contoso.com. hostmaster.contoso.com. (
                                7            ; serial number
                                900          ; refresh
                                600          ; retry
                                86400        ; expire
                                3600       ) ; default TTL

www                     0    A    20.0.0.1
                        0    A    30.0.0.1
                        0    A    40.0.0.1

Добавления нуля в записи типа A можно сделать и вручную непосредственно в файле зоны.

Исключения

В настройках сервера DNS по умолчанию включена и опция Enable netmask ordering. Смысл опции заключаются в том, что при наличии нескольких IP адресов для одного и того же имени хоста сервер DNS анализирует из какой сети пришел запрос от клиента. Если IP сеть клиента совпадает с номером сети одного из IP адресов хоста, то такой IP всегда возвращается первым. Проще говоря, если в нашем примере клиент с адресом 30.67.98.123 будет запрашивать имя www.gorbunov.pro, то ему всегда первым в списке будет возвращаться адрес 30.0.0.1.

В серверах Windows опция Enable netmask ordering перебивает опцию Enable round robin. Т.е. клиентам DNS первым всегда возвращается адрес ближайшего хоста, даже несмотря на правильно настроенную функцию DNS Round robin.

Выводы

---

Технология DNS Round robin часто применяется для динамической балансировки нагрузки между зеркальными хостами. Она значительно проще в реализации, чем вариант настройки для тех же целей кластера NLB. При настройке DNS Round robin на серверах Windows не забывайте, что настройки по умолчанию для сервера DNS не позволяют в полной мере реализовать балансировку запросов и требуется ручная конфигурация сервера.

Обновлена в июле 2014

План настройки:

1. Различные варианты архитектуры решений MS RDS (эта статья)
2. Описание MS RDS в Windows server 2012 и плана моей настройки (тут)
3. Настройка домена в Windows server 2012 R2: Active Directory, DNS, DHCP
4. Настройка дублирующих служб Active Directory, DNS, DHCP
5. Развертывание RDS и создание кластера NLB
6. Развертывание DFS для хранения данных пользователей
7. Настройка премещаемых профилей и перенаправленных папок

В своих статьях по настройке, я всегда пытаюсь показывать архитектуру, которую рекомендует производитель или разработчик программного обеспечения. ВСЕГДА у ВСЕХ существуют так называемые best practice или reference architecture, в которых показано, как лучшим образом построить масштабируемую и отказоустойчивую систему. Я написал у ВСЕХ? За исключением Microsoft… Может в этом есть большая политика или еще что-то, но для для служб RDS я не смог найти рекомендаций, только какие-то старые статьи и примеры простых настроек, которые не претендуют на полноценные гайды. Интересно написана вот эта статья, с виду все правильно, но для небольшой компании не подойдет, слишком громоздкая схема и дорогая в реализации в плане оборудования и лицензий (их автор не рассматривает). Я тоже подготовил свои вариации на тему терминального сервера от Microsoft, и вот как я мыслю, от простого к сложному.

Вариант 1

Самый простой вариант, известный очень давно, с ним спорить никто не станет, да и придраться не к чему, кроме сомнительной отказоустойчивости данного решения. Хотя есть в компании, где такие установки работают годами и ничего с ними не происходит. На сервер установлен гипервизор (любой), настроены две виртуальные машины: одна Active Directory, DNS, DHCP и вторая со службой удаленных рабочих столов (RDS) и сервером лицензий. Данная схема может успешно держать до 80-100 пользователей. Точки отказа помечены красными кружками. Из строя могут выйти:

• сервер RDS (программная то) — все сессии рвутся, пользователи не работают
• AD, DNS, DHCP (программная то) — существующие сессии продолжают работать, все попытки новых подключение заканчиваются неудачей
• гипервизор (программная то) — все выключается никто не работает больше до восстановления
• сервер (аппаратная) — ничего не работает до починки сервера

Вариант 2 Создаем еще одну виртуальную машину и резервируем важные для работы сервисы Active Directory, DNS, DHCP. Избавляемся от одной программной точки отказа.

Вариант 3

Делаем еще один или несколько терминальных серверов (RDS), в основном для того, чтобы большему числу пользователей дать терминальный доступ, рекомендуется 40-50 человек на один терминальный сервер. Также придется добавить файловый сервер (программная то), где будут храниться профили пользователей и перенаправленные папки. Если пользователь подключается к одному из терминальных серверов, то на этот сервер загружается его профиль с файлового сервера и подключаются перенаправленные папки. Пользователей можно раскидывать между серверами с помощью DNS Round Robin или NLB cluster.

DNS round robin настраивается очень легко, в DNS создаются записи с одинаковыми именами и разными IP адресами. Пользователи обращаются на адрес и случайным образом получают один из IP адресов и попадают на один из терминальных серверов. Опасности DNS round robin:

• нет распределения нагрузки между серверами, может оказаться, что на одном из серверов больше пользователей чем на другом. Или один сервер будет загружен на 80%, а второй на 20%. Данную проблему можно решить, нарастив количество терминальных серверов, тогда нагрузку будет распределять уже гипервизор, который умеет динамически распределять оперативную память и процессорную мощность.
• двойные сессии, если пользователь отключился по каким-то причинам, а затем переподключается, то может легко попасть на другой сервер и откроется еще одна сессия. А в старой могут остаться открытые документы, программы, браузер и другая недоделанная работа. Можно настроить автоматическое отключение неактивных сессий, это приучит пользователей чаще сохраняться и двойных сессий не будет.
• отказ в подключении —  DNS round robin не проверяет доступность IP адреса, который он выдает, и это самое неприятное в этом простом алгоритме. Поэтому, если один из терминальных серверов выйдет из строя, то при подключении пользователь может все равно получить его IP адрес и подключение не пройдет. Дальше два варианта, или пользователь не оставляет попытки подключения и в конце концов получает рабочий IP адрес или начинает звонить в тех поддержку. Данную проблему решает только замена DNS round robin на NLB cluster.

NLB cluster — встроенная фича Windows server, которая устанавливается через мастер добавления ролей сервера. В отличии от DNS round robin не перенаправляет пользователей на недоступные в данный момент серверы. Из минусов остаются невозможность распределять нагрузку и двойные сессии.

Вариант 4

Чтобы распределять нагрузку у Microsoft RDS есть специальная роль — Connection Broker. Он отслеживает нагрузку, количество пользователей на серверах, уже открытые сессии и перенаправляет новые подключения или переподключения на подходящие серверы RDS. Добавляя новый сервер с Connection Broker мы получаем новую программную точку отказа.

Вариант 5

Добавляем дублирующий Connection Broker, но чтобы они работали вместе, обязательно нужен MSSQL сервер, который становится новой точкой отказа. Причем MSSQL отказоустойчивый кластер настроить и сложно и дорого. Чтобы сделать это нормально понадобится общая папка на системе хранения данных и лицензия MS SQL server Standard, обойтись версией MSSQL Express не получится. На мой взгляд, в эту сторону имеет смысл двигаться только в больших инфраструктурах, где уже есть отказоустойчивый кластер MS SQL. В любом случае, сделать это на одном физическом сервере не получится.

Распределять пользователей между двумя и более Connection Broker также можно средствами DNS Round Robin или NLB Cluster.

Вариант 6-7 (финальные для одного физического сервера)

Возвращаемся к варианту с одним Connection Broker. От точки отказа файлового сервера избавляемся, заменяем связкой DFS серверов. Это будет финальный вариант для одного физического сервера.

С одной стороны отсутствие Connection Broker лишает распределения нагрузки, с другой стороны убираем точку отказа. Рекомендуется использование NLB cluster на RDS серверах.

Вариант 8

Добавляем второй физический сервер, что добавляет нам производительности. Остается точка отказа Connection Broker (программная), гипервизор (программная то) и сервер на котором находится CB (аппаратная то)

Вариант 9

Явных точек отказа в данном варианте нет. Распределение нагрузки через NLB cluster. Масштабировать решение легко, никаких проблем с этим быть не должно.

Вариант 10

Если добавить в решение систему хранения данных, то можно собрать отказоустойчивый кластер и защитить Connection Broker от аппаратного отказа сервера на котором он запущен. В High Availability кластере виртуальная машина с CB будет автоматически перезапущена на втором сервере. Напомню, что виртуальная машина занимается распределением нагрузки между терминальными серверами.
Данный вариант не защищает от программного сбоя (BSOD например) в виртуальной машине CB.

Вариант 11

По логике Microsoft эта схема самая правильная, и ,конечно, самая дорогая. Connection broker работает в отказоустойчивом режиме, используя в свою очередь отказоустойчивый кластер MS SQL, работающий в режиме active-passive (лицензия MS SQL Standard) или в режиме active-active (лицензия MS SQL Enterprise)

ВЫВОДЫ

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

2012 R2, HA, High Availability, Microsoft, network resources, RD Connection Broker, RD Gateway, RDS, Remote Desktop Services, Resource Authorization Policy, Windows Server 2012

This entry was posted on February 2, 2014, 7:25 pm and is filed under MICROSOFT. You can follow any responses to this entry through RSS 2.0.

You can leave a response, or trackback from your own site.