Отказоустойчивый кластер windows server 2012 r2

В Windows Server 2012 появилось так много новшеств, что за всеми уследить трудно. Часть наиболее важных строительных блоков новой ИТ-инфраструктуры связана с улучшениями в отказоустойчивой кластеризации. Отказоустойчивая кластеризация зародилась как технология для защиты важнейших приложений, необходимых для производственной деятельности, таких как Microsoft SQL Server и Microsoft Exchange. Но впоследствии отказоустойчивая кластеризация превратилась в платформу высокой доступности для ряда служб и приложений Windows. Отказоустойчивая кластеризация — часть фундамента Dynamic Datacenter и таких технологий, как динамическая миграция. Благодаря Server 2012 и усовершенствованиям нового протокола Server Message Block (SMB) 3.0 область действия отказоустойчивой кластеризации стала увеличиваться, обеспечивая непрерывно доступные файловые ресурсы с общим доступом. Обзор функциональности отказоустойчивой кластеризации в Server 2012 приведен в опубликованной в этом же номере журнала статье «Новые возможности отказоустойчивой кластеризации Windows Server 2012».

.

Обязательные условия отказоустойчивой кластеризации

Для построения двухузлового отказоустойчивого кластера Server 2012 необходимы два компьютера, работающие с версиями Server 2012 Datacenter или Standard. Это могут быть физические компьютеры или виртуальные машины. Кластеры с виртуальными узлами можно построить с помощью Microsoft Hyper-V или VMware vSphere. В данной статье используются два физических сервера, но этапы настройки кластера для физических и виртуальных узлов одни и те же. Ключевая особенность заключается в том, что узлы должны быть настроены одинаково, чтобы резервный узел мог выполнять рабочие нагрузки в случае аварийного переключения или динамической миграции. Компоненты, использованные в тестовом отказоустойчивом кластере Server 2012 представлены на рисунке.

Картинка с сайта: www.osp.ru

Рисунок. Просмотр компонентов кластера

Для отказоустойчивого кластера Server 2012 необходимо общее хранилище данных типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В нашем примере используется iSCSI SAN. Следует помнить о следующих особенностях хранилищ этого типа.

• Каждый сервер должен располагать по крайней мере тремя сетевыми адаптерами: одним для подключения хранилища iSCSI, одним для связи с узлом кластера и одним для связи с внешней сетью. Если предполагается задействовать кластер для динамической миграции, то полезно иметь четвертый сетевой адаптер. Однако динамическую миграцию можно выполнить и через внешнее сетевое соединение — она просто будет выполняться медленнее. Если серверы используются для виртуализации на основе Hyper-V и консолидации серверов, то нужны дополнительные сетевые адаптеры для передачи сетевого трафика виртуальных машин.
• В быстрых сетях работать всегда лучше, поэтому быстродействие канала связи iSCSI должно быть не менее 1 ГГц.
• Цель iSCSI должна соответствовать спецификации iSCSI-3, в частности обеспечивать постоянное резервирование. Это обязательное требование динамической миграции. Оборудование почти всех поставщиков систем хранения данных соответствует стандарту iSCSI 3. Если нужно организовать кластер в лабораторной среде с небольшими затратами, обязательно убедитесь, что программное обеспечение цели iSCSI соответствует iSCSI 3 и требованиям постоянного резервирования. Старые версии Openfiler не поддерживают этот стандарт, в отличие от новой версии Openfiler с модулем Advanced iSCSI Target Plugin (http://www.openfiler.com/products/advanced-iscsi-plugin). Кроме того, бесплатная версия StarWind iSCSI SAN Free Edition компании StarWind Software (http://www.starwindsoftware.com/starwind-free) полностью совместима с Hyper-V и динамической миграцией. Некоторые версии Microsoft Windows Server также могут функционировать в качестве цели iSCSI, совместимой со стандартами iSCSI 3. В состав Server 2012 входит цель iSCSI. Windows Storage Server 2008 R2 поддерживает программное обеспечение цели iSCSI. Кроме того, можно загрузить программу Microsoft iSCSI Software Target 3.3 (http://www.microsoft.com/en-us/download/details.aspx?id=19867), которая работает с Windows Server 2008 R2.

Дополнительные сведения о настройке хранилища iSCSI для отказоустойчивого кластера приведены во врезке «Пример настройки хранилища iSCSI». Более подробно о требованиях к отказоустойчивой кластеризации рассказано в статье «Failover Clustering Hardware Requirements and Storage Options» (http://technet.microsoft.com/en-us/library/jj612869.aspx).

Добавление функций отказоустойчивой кластеризации

Первый шаг к созданию двухузлового отказоустойчивого кластера Server 2012 — добавление компонента отказоустойчивого кластера с использованием диспетчера сервера. Диспетчер сервера автоматически открывается при регистрации в Server 2012. Чтобы добавить компонент отказоустойчивого кластера, выберите Local Server («Локальный сервер») и прокрутите список вниз до раздела ROLES AND FEATURES. Из раскрывающегося списка TASKS выберите Add Roles and Features, как показано на экране 1. В результате будет запущен мастер добавления ролей и компонентов.

Картинка с сайта: www.osp.ru

Экран 1. Запуск мастера добавления ролей и компонентов

Первой после запуска мастера откроется страница приветствия Before you begin. Нажмите кнопку Next для перехода к странице выбора типа установки, на которой задается вопрос, нужно ли установить компонент на локальном компьютере или в службе Remote Desktop. Для данного примера выберите вариант Role-based or feature-based installation и нажмите кнопку Next.

На странице Select destination server выберите сервер, на котором следует установить функции отказоустойчивого кластера. В моем случае это локальный сервер с именем WS2012-N1. Выбрав локальный сервер, нажмите кнопку Next, чтобы перейти к странице Select server roles. В данном примере роль сервера не устанавливается, поэтому нажмите кнопку Next. Или можно щелкнуть ссылку Features в левом меню.

На странице Select features прокрутите список компонентов до пункта Failover Clustering. Щелкните в поле перед Failover Clustering и увидите диалоговое окно со списком различных компонентов, которые будут установлены как части этого компонента. Как показано на экране 2, по умолчанию мастер установит средства управления отказоустойчивыми кластерами и модуль отказоустойчивого кластера для Windows PowerShell. Нажмите кнопку Add Features, чтобы вернуться на страницу выбора компонентов. Щелкните Next.

Картинка с сайта: www.osp.ru

Экран 2. Добавление средства отказоустойчивого кластера и инструментов

На странице Confirm installation selections будет показана функция отказоустойчивого кластера наряду с инструментами управления и модулем PowerShell. С этой страницы можно вернуться и внести любые изменения. При нажатии кнопки Install начнется собственно установка компонентов. После завершения установки работа мастера будет завершена и функция отказоустойчивого кластера появится в разделе ROLES AND FEATURES диспетчера сервера. Этот процесс необходимо выполнить на обоих узлах.

Проверка отказоустойчивого кластера

Следующий шаг после добавления функции отказоустойчивого кластера — проверка настроек среды, в которой создан кластер. Здесь можно воспользоваться мастером проверки настроек в диспетчере отказоустойчивого кластера. Этот мастер проверяет параметры аппаратных средств и программного обеспечения всех узлов кластера и сообщает обо всех проблемах, которые могут помешать организации кластера.

Чтобы открыть диспетчер отказоустойчивого кластера, выберите параметр Failover Cluster Manager в меню Tools в диспетчере сервера. В области Management щелкните ссылку Validate Configuration, как показано на экране 3, чтобы запустить мастер проверки настроек.

Картинка с сайта: www.osp.ru

Экран 3. Запуск мастера проверки конфигурации

Сначала выводится страница приветствия мастера. Нажмите кнопку Next, чтобы перейти к выбору серверов или странице Cluster. На этой странице введите имена узлов кластера, который необходимо проверить. Я указал WS2012-N1 и WS2012-N2. Нажмите кнопку Next, чтобы показать страницу Testing Options, на которой можно выбрать конкретные наборы тестов или запустить все тесты. По крайней мере в первый раз я рекомендую запустить все тесты. Нажмите кнопку Next, чтобы перейти на страницу подтверждения, на которой показаны выполняемые тесты. Нажмите кнопку Next, чтобы начать процесс тестирования кластера. В ходе тестирования проверяется версия операционной системы, настройки сети и хранилища всех узлов кластера. Сводка результатов отображается после завершения теста.

Если тесты проверки выполнены успешно, можно создать кластер. На экране 4 показан экран сводки для успешно проверенного кластера. Если при проверке обнаружены ошибки, то отчет будет отмечен желтым треугольником (предупреждения) или красным значком «X» в случае серьезных ошибок. С предупреждениями следует ознакомиться, но их можно игнорировать. Серьезные ошибки необходимо исправить перед созданием кластера.

Картинка с сайта: www.osp.ru

Экран 4. Просмотр отчета о проверке

Создание отказоустойчивого кластера

На данном этапе можно создать кластер, начиная с любого узла кластера. Я организовал кластер, начав на первом узле (WS2012-N1).

Чтобы создать новый кластер, выберите ссылку Create Cluster на панели Management или панели Actions, как показано на экране 5.

Картинка с сайта: www.osp.ru

Экран 5. Запуск мастера создания кластера

В результате будет запущен мастер создания кластера, работа которого начинается со страницы приветствия. Нажмите кнопку Next, чтобы перейти на страницу выбора серверов, показанную на экране 6. На этой странице введите имена всех узлов кластера, затем нажмите кнопку Next.

Картинка с сайта: www.osp.ru

Экран 6. Выбор серверов для кластера

На странице Access Point for Administering the Cluster следует указать имя и IP-адрес кластера, которые должны быть уникальными в сети. На экране 7 видно, что имя моего кластера WS2012-CL01, а IP-адрес — 192.168.100.200. При использовании Server 2012 IP-адрес кластера может быть назначен через DHCP, но я предпочитаю для своих серверов статически назначаемый IP-адрес.

Картинка с сайта: www.osp.ru

Экран 7. Настройка точки доступа кластера

После ввода имени и IP-адреса нажмите кнопку Next, чтобы увидеть страницу подтверждения (экран 8). На этой странице можно проверить настройки, сделанные при создании кластера. При необходимости можно вернуться и внести изменения.

Картинка с сайта: www.osp.ru

Экран 8. Подтверждение параметров, выбранных при создании кластера

После нажатия кнопки Next на странице подтверждения формируется кластер на всех выбранных узлах. На странице хода выполнения показаны шаги мастера в процессе создания нового кластера. По завершении мастер покажет страницу сводки с настройками нового кластера.

Мастер создания кластера автоматически выбирает хранилище для кворума, но часто он выбирает не тот диск кворума, который хотелось бы администратору. Чтобы проверить, какой диск используется для кворума, откройте диспетчер отказоустойчивого кластера и разверните кластер. Затем откройте узел Storage и щелкните узел Disks. Диски, доступные в кластере, будут показаны на панели Disks. Диск, выбранный мастером для кворума кластера, будет указан в разделе Disk Witness in Quorum.

В данном примере для кворума был использован Cluster Disk 4. Его размер 520 Мбайт, чуть больше минимального значения для кворума 512 Мбайт. Если нужно использовать другой диск для кворума кластера, можно изменить настройки кластера, щелкнув правой кнопкой мыши имя кластера в диспетчере отказоустойчивого кластера, выбрав пункт More Actions и Configure Cluster Quorum Settings. В результате появится мастер выбора конфигурации кворума, с помощью которого можно изменить параметры кворума кластера.

Настройка общих томов кластера и роли виртуальных машин

Оба узла в моем кластере имеют роль Hyper-V, так как кластер предназначен для виртуальных машин с высокой доступностью, обеспечивающих динамическую миграцию. Чтобы упростить динамическую миграцию, далее требуется настроить общие тома кластера Cluster Shared Volumes (CSV). В отличие от Server 2008 R2, в Server 2012 общие тома кластера включены по умолчанию. Однако все же требуется указать, какое хранилище следует использовать для общих томов кластера. Чтобы включить CSV на доступном диске, разверните узел Storage и выберите узел Disks. Затем выберите диск кластера, который нужно использовать как CSV, и щелкните ссылку Add to Cluster Shared Volumes на панели Actions диспетчера отказоустойчивого кластера (экран 9). Поле Assigned To этого диска кластера изменится с Available Storage на Cluster Shared Volume (общий том кластера), как показано на экране 9.

Картинка с сайта: www.osp.ru

Экран 9. Добавление CSV

В это время диспетчер отказоустойчивого кластера настраивает хранилище диска кластера для CSV, в частности добавляет точку подключения в системном диске. В данном примере общие тома кластера включаются как на Cluster Disk 1, так и на Cluster Disk 3 с добавлением следующих точек подключения:

* C:ClusterStorageVolume1
* C:ClusterStorageVolume2

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

Чтобы добавить новую роль, выберите имя кластера на панели навигации диспетчера отказоустойчивого кластера и щелкните ссылку Configure Roles на панели Actions, чтобы запустить мастер высокой готовности. Нажмите кнопку Next на странице приветствия, чтобы перейти на страницу выбора роли. Прокрутите список ролей, пока не увидите роль виртуальной машины, как показано на экране 10. Выберите роль и нажмите кнопку Next.

Картинка с сайта: www.osp.ru

Экран 10. Добавление роли виртуальной машины

На странице выбора виртуальной машины будут перечислены все VM на всех узлах кластера, как показано на экране 11. Прокрутите список и выберите виртуальные машины, которым необходимо обеспечить высокую готовность. Нажмите кнопку Next. Подтвердив свой выбор, нажмите Next, чтобы добавить роли виртуальной машины в диспетчер отказоустойчивого кластера.

Картинка с сайта: www.osp.ru

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

Время на прочтение4 мин

Количество просмотров115K

Данный топик будет интересен новичкам. Бывалые гуру и все, кто уже знаком с этим вопросом, вряд ли найдут что-то новое и полезное. Всех остальных милости прошу под кат.

Задача, которая стоит перед нами, – обеспечить бесперебойную работу и высокую доступность базы данных в клиент-серверном варианте развертывания.
Тип конфигурации — active/passive.

P.S. Вопросы резервирования узлов не относящихся к MSSQL не рассмотрены.

Этап 1 — Подготовка

Основные требования к аппаратному и программному обеспечению:

• Наличие минимум 2-х узлов(физических/виртуальных), СХД
• MS Windows Server, MS SQL ServerСХД
• СХД
  1. Доступный iSCSI диск для баз данных
  2. Доступный iSCSI диск для MSDTC
  3. Quorum диск

Тестовый стенд:

• Windows Server 2012R2 с ролями AD DS, DNS, DHCP(WS2012R2AD)
• Хранилище iSCSI*
• 2xWindows Server 2012R2(для кластера WS2012R2C1 и WS2012R2C2)
• Windows Server 2012R2 с поднятой службой сервера 1С (WS2012R2AC)

*как вариант можно использовать Роль хранилища на Windows Server 2012R2, софтверное решение от StarWind или реальное сетевое устройство iSCSI

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

Вначале вводим в домен сервера WS2012R2C1 и WS2012R2C2; на каждом из них устанавливаем роль «Отказоустойчивая кластеризация».
После установки роли, запускаем оснастку «Диспетчер отказоустойчивости кластеров» и переходим в Мастер создания кластеров, где конфигурируем наш отказоустойчивый кластер: создаем Quorum (общий ресурс) и MSDTC(iSCSI).

Этап 2 – Установка MS SQL Server

Важно: все действия необходимо выполнять от имени пользователя с правом заведения новых машин в домен. (Спасибоminamoto за дополнение)
Для установки нам понадобится установочный дистрибутив MS SQL Server. Запусткаем мастер установки и выбераем вариант установки нового экземпляра кластера:

Далее вводим данные вашего лицензионного ключа:

Внимательно читаем и принимаем лицензионное соглашение:

Получаем доступные обновления:

Проходим проверку конфигурации (Warning MSCS пропускаем):

Выбираем вариант целевого назначения установки:

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

Еще одна проверка установочной конфигурации:

Далее — важный этап, выбор сетевого имени для кластера MSSQL (instance ID – оставляем):

Проверка доступного пространства:

После чего — список доступных хранилищ, данных (сконфигурировано на этапе подготовки):

Выбираем диск для расположения баз данных кластера:

Конфигурацию сетевого интерфейса кластера рекомендуется указать адрес вручную:

Указываем данные администратора (можно завести отдельного пользователя для MSSQL):

Еще один важный этап – выбор порядка сортировки (Collation). После инсталляции изменить крайне проблематично:

Параметры аутентификации на сервере (в нашем случае выбран смешанный вариант, хотя безопаснее использовать только доменную аутентификацию):

Выбор директорий хранения общих файлов кластера (в версиях MS SQL Server 2012 и старше TempDB можно хранить на каждой ноде и не выносить в общее хранилище):

Еще пару проверок:

Наконец приступаем к установке (процесс может занять длительное время):

Настройка и установка базовой ноды закончена, о чем нам сообщает «зеленый» рапорт

Этап 3 – добавление второй ноды в кластер MSSQL

Дальше необходимо добавить в кластер вторую ноду, т.к. без нее об отказоустойчивости говорить не приходится.
Настройка и установка намного проще. На втором сервере (ВМ) запускаем мастер установки MS SQL Server:

• Проходим стартовый тест
• Вводим лицензионный ключ:
• Читаем и принимаем лицензионное соглашение:
• Получаем обновления:
• Проходим тесты по выполнению требований для установки ноды (MSCS warning – пропускаем):

Выбираем: в какой кластер добавлять ноду:

Просматриваем и принимаем сетевые настройки экземпляра кластера:

Указываем пользователя и пароль (те же, что и на первом этапе):

Снова тесты и процесс установки:

По завершению мы должны получить следующую картину:

Поздравляю, установка закончена.

Этап 4 – проверка работоспособности

Удостоверимся, что все работает как надо. Для этого перейдем в оснастку «Диспетчер отказоустойчивого кластера»:

На данный момент у нас используется вторая нода(WS2012R2C2) в случае сбоя произойдет переключение на первую ноду(WS2012R2C1).
Попробуем подключиться непосредственно к кластеру сервера MSSQL, для этого нам понадобится любой компьютер в доменной сети с установленной Management Studio MSSQL. При запуске указываем имя нашего кластера и пользователя (либо оставляем доменную авторизацию).

После подключения видим базы которые крутятся в кластере (на скриншоте присутствует отдельно добавленная база, после инсталляции присутствуют только системные).

Данный экземпляр отказоустойчивого кластера полностью готов к использованию с любыми базами данных, например, 1С(для нас ставилась задача развернуть такую конфигурацию для работы именно 1С-ки). Работа с ним ничем не отличается от обычной, но основная особенность — в надежности такого решения.

В тестовых целях рекомендую поиграть с отключением нод и посмотреть как происходит миграция базы между ними; проконтролировать важные для вас параметры, например, сколько по времени будет длиться переключение.
У нас при отказе одной из нод – происходит разрыв соединения с базой и переключение на вторую (время восстановления работоспособности: до минуты).
В полевых условиях для обеспечения надежности всей инфраструктуры необходимо обработать точки отказа: СХД, AD и DNS.

P.S. Удачи в построении отказоустойчивых решений.

Дата: 19.05.2015 Автор Admin

В данной статье мы рассмотрим как настроить Отказоустойчивый ISCSI кластер на Windows Server 2012 R2.Для настройки нам понадобятся 2 сервера.

Кластер в данной статье будет настраиваться по следующей схеме:

Соответственно у вас должна быть сеть хранения данных, подключенная по FC, SAS или ISCSI (необходим ISCSI протокол версии не ниже iSCSI-3)

Должна быть настроена LAN сеть на каждом узле кластера, и отдельная сеть между кластерами.

На первом сервере включаем компонент «отказоустойчивая кластеризация»

Нажимаем далее, и выбираем установить.

По аналогии устанавливаем компонент на втором сервере.

Перейдем на первый сервер и перейдем к созданию кластера.

Открываем Диспетчер отказоустойчивости кластеров.

Выбираем создать кластер

Добавляем сервера (узлы кластера)

Далее по желанию запускаем проверочные тесты.

Вводим имя кластера и адреса.

Создаем кластер. Обязательно добавляем все допустимые хранилища.

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

Далее в консоли должен появится созданный кластер.

Добавляем роль ISCSI target на каждый узел кластера.

Дожидаемся установки компонента роли.

Возвращаемся в консоль управления кластером, и добавляем новую роль кластера.

Выбираем «Настроить роль»

Выбираем роль ISCSI сервера

Указываем название кластера и сетевые адреса.

Выбираем диск кластера.

Подтверждаем создание роли.

Дожидаемся установки роли.

Теперь перейдем к настройке ISCSI сервера.

На одном из узлов кластера открываем диспетчер сервера, в нем открываем файловые службы и выбираем ISCSI.

Запускаем мастер создания ISCSI диска.

Выбираем кластер и общий кластерный диск.

Вводим название диска.

Указываем размер диска и его тип.

Далее выбираем пункт — «Новая цель ISCSI»

Далее вводим название цели ISCSI.

Указываем каким серверам можно подключаться к ISCSI цели.

Указываем учетные данные для подключения.

Далее нажимаем «Создать» и ожидаем окончания работы мастера.

Готово! Теперь указанные клиенты могут подключаться к кластеру ISCSI. Для подключения нужно использовать DNS имя кластера.

Удачной установки!

Ранее мы рассматривали пример построения фермы 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:\windows\system32\cliconfg.exe) и добавим два новых алиаса – с коротким именем сервера и FQDN

Фактически созданные SQL-алиасы в интерфейсе утилиты были записаны в ключ реестра HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo

Теперь нужно проверить созданные нами 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 и укажем раздел хранилища Personal\Registry. Чтобы этот раздел был доступен для выбора, нужно включить опцию Show physical stores.

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

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

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

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

После того как сертификат экспортирован, переходим в консоль Server Manager\Remote Desktop Services\Overview и на схеме развёртывания в списке задач выбираем пункт редактирования развёртывания (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%\Web\RDWeb\Pages\Site.xsl – найти секцию с комментарием «Replaceable Company Logo Image«…

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

В результате мы получим примерно следующий вид верхней части страниц 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%\Microsoft\Workspaces{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

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

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

Dism /online /Add-Package /PackagePath:"C:\Distributives\WS2012RTMLanguagePack\lp.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 Configuration\Policies\Administrative Templates\Printers. После применения политики на серверах нужно перезапустить службу очереди печати — 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 Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Printer 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)