Компьютерщик на все руки: Больше одного

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

Грэг Шилдс

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

Вряд ли кто-то будет спорить, что самое важное и сложное расширение RDS — переход от одного до двух серверов узлов сеансов удаленных рабочих столов (RDSH). Причина заключается в необходимости обеспечения всех этих мелких деталей, которые необходимы для добавления второго сервера к уже существующему.

Локальные профили пользователей уже не подходят. Ранее простое конфигурирование пользовательского интерфейса разумнее было выполнять посредством развертывания групповой политики. Но сейчас серверы и приложения нуждаются в дополнительном внимании.

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

Шаг 1. Создайте второй RDSH-сервер

Первая задача… ну, вы поняли — добавить второй сервер. Подготовьте сервер под управлением Windows Server 2008 R2 и в Диспетчере сервера добавьте роль RDSH. Далее сервер будет настроен для доступа многих пользователей, а его ОС подготовлена для специальной настройки, которая требуется для размещенных в службах RDS приложениях. Помните, что исключительно важно установить службу роли RDSH перед установкой каких-либо приложений.

В ферме RDS, которую вы планируете создать, предполагается, что все члены сконфигурированы идентично. «Ферма» — это группа RDSH-серверов, каждый из которых предлагает один и тот же набор приложений. Унификация серверов с одинаковой конфигурацией в рамках одной фермы позволяет реализовать прозрачную балансировку нагрузки.

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

Шаг 2. Перенос управления конфигурацией в групповые политики

Используйте групповые политики и предпочтения групповых политик для установки и конфигурирования приложений. Использование этих средств для унификации установки приложений и применения одинаковых параметров позволяет сделать добавление серверов таким же простым, как добавление учетных записей в подразделения (OU). Подробнее об автоматизации этих процессов см. статью «Любопытство, нарушающее работу приложений» в предыдущем номере

Традиционные групповые политики позволяют обеспечить унификацию параметров RDS. До этого момента вы имели дело со вторым RDSH-сервером. Но может потребоваться добавить больше, чем один сервер. Перенос параметров RDS в групповые политики гарантирует, что все последующие добавляемые серверы получат правильную конфигурацию. И как вы вскоре узнаете, у RDS столько же панелей управления, сколько и конфигураций. В сущности, применять параметры RDS с помощью групповых политик намного проще, чем делать это вручную.

Особое внимание надо уделить параметрам узла Windows Components/Remote Desktop/Remote Desktop Session в ветках Computer Configuration и User Configuration. Это базовые параметры RDSH, и почти все из них требуют внимания.

Параметры служб RDS и их приложений — это всего лишь начало. С пользователями RDS ОС Windows ведет себя иначе, чем в других сценариях. Причина в том, что пользовательские параметры настройки управляются на уровне политики — точно так же, как параметры компьютера.

Переведите групповую политику замыкания на себя в режим слияния. Соответствующая политика называется «Режим обработки замыкания пользовательской групповой политики» (User Group Policy loopback processing mode) и находится в узле Computer Configuration/System/Group Policy. Включение режима слияния позволяет управлять параметрами пользователя посредством объектов групповых политик (GPO). Все конфликтующие параметры переопределяются.

Включение политики замыкания на себя позволяет получить доступ к параметрам ветки User Configuration. Их можно применять только в ситуациях, когда пользователи входят в систему ваших серверов RDS. Обработку профилей пользователей в многосерверной среде нужно планировать. Проще говоря, локальные профили не работают в фермах RDS. Их заменяют перемещаемые профили удаленных рабочих столов. При входе пользователей на RDSH-серверы используется специальные перемещаемый профиль.

В применяемом к своим RDSH-серверам GPO-объекте перейдите к узлу Configuration/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Profiles. Включите параметр «Set path for Remote Desktop Services Roaming User Profile» (Задать путь для перемещаемого профиля пользователя служб удаленных рабочих столов) и укажите путь к общей папке. При наличии этого параметра пользователи всегда будут получать свой профиль независимо от того, к какому серверу RDS они подключились.

Для предотвращения неограниченного роста профилей на серверах RDS используется другая групповая политика. В узле Computer Configuration/System/Profiles включите параметр «Delete cached copies of roaming profiles» (Удалять кешированные копии перемещаемых профилей). Это заставляет серверы RDS удалять профили из локального кеша при выходе пользователя из системы и гарантирует, что в долгосрочной перспективе перемещаемые профили удаленного рабочего стола не станут занимать лишнее место.

Шаг 3. Установка посредника подключений к удаленному рабочему столу и присоединение RDSH-серверов к ферме

Теперь у вас есть два независимых RDSH-сервера. Для организации среди них балансировки нагрузки требуются дополнительные шаги. Сначала надо установить службу роли RD Connection Broker (Посредник подключений к удаленному рабочему столу). Это позволяет организовать сеансы балансировки нагрузки среди независимых RDSH-серверов.

Со службой роли посредника подключений к удаленному рабочему столу есть одна проблема. Его нельзя установить на RDSH-сервер, который является членом фермы. Для размещения посредника нужно найти третий сравнительно не сильно нагруженный сервер. Для этой службы роли требуется не очень много ресурсов.

Завершив установку посредника, перейдите на сервере к узлу Local Users and Groups. Добавьте учетную запись обоих RDSH-серверов в группу Session Broker Computers. Это позволит посреднику подключений к удаленному рабочему столу взаимодействовать с RDSH-серверами.

Следующая задача — добавить все RDSH-серверы в ферму. Это делается в узле RD Session Host Configuration в Диспетчере сервера (Server Manager). Дважды щелкните параметр Member of farm in RD Connection Broker (Член фермы в посреднике подключений к удаленному рабочему столу)(рис. 1).Выберите Farm member (Член фермы) и задайте полное доменное имя посредника подключений к удаленным рабочим столам и имя фермы. На всех членах имя фермы должно быть одинаковым.

Рис. 1. Настройка параметров посредника подключений к удаленным рабочим столам

Откроется окно свойств (рис. 2). Установите флажок Participate in Connection Broker Load-Balancing (Участвовать в балансировке нагрузки посредника подключений). Вы можете задать относительный вес данного сервера в ферме. Относительный вес определяет долю нагрузки, которая приходится на данный сервер по сравнению с остальными серверами. Например, если первый сервер наполовину менее мощный, чем второй, задайте вес первого сервера наполовину меньшим, чем вес второго сервера (например, 50 и 100 или 5 и 10). Абсолютное значение веса не имеет значения — смысл имеет только вес в сравнении с весами других серверов.

Рис. 2. Свойства посредника подключений к удаленным рабочим столам

Есть еще два необходимых параметра. В большинстве реализаций посредника для балансировки нагрузки используется перенаправление IP-адреса, поэтому скорее всего подойдут параметры по умолчанию (рис. 2). Выберите нужный IP-адрес во втором параметре. Он будет использоваться для переподключения сеанса, когда пользователи начнут обращаться к серверу.

Есть еще одна операция, которую нужно выполнить в узле RemoteApp Manager консоли «Диспетчер сервера». Щелкните ссылку Change рядом с RD Session Host Server Settings, чтобы открыть панель управления (Рис. 3). В параметре Connection замените имя RDSH-сервера на полное доменное имя вашей фермы.

Рис. 3 . Настройка параметров развертывания удаленных приложений RemoteApp.

Шаг 4. Включение балансировки сетевой нагрузки

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

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

Запустите диспетчер NLB (NLB Manager) из папки средств администрирования (Administrative Tools) на своей рабочей станции. Не пытайтесь управлять NLB с одного из RDSH-серверов — вы можете получить очень неприятное сообщение об ошибке. В консоли диспетчера щелкните правой кнопкой Network Load Balancing Clusters и выберите New Cluster. Поначалу мастер создания нового кластера может показаться сложным, но нам пока будет достаточно немного операций по конфигурированию.

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

На пятой и последней странице потребуется немного потрудиться. На ней надо сконфигурировать кластер NLB на балансировку только трафика RDS. Для этого отредактируйте существующее правило для портов (рис. 4), ограничив его только балансировкой нагрузки TCP-порта 3389. Надо также задать None в качестве привязки режима фильтрации, что обеспечит балансировку всего входящего трафика.

Рис. 4 . Определение правила для портов для настройки балансировки сетевой нагрузки

Завершив настройку, щелкните правой кнопкой значок только что созданного кластера NLB и выберите команду Add Host to Cluster. В мастере задайте всю соответствующую информацию, чтобы добавить второй узел RDSH.

Осталась еще одна операция в нашей процедуре настройки NLB. Надо сопоставить IP-адрес кластера NLB (тот, что назначен самому кластеру) его DNS-имени. В консоли DNS задайте этот конечный IP-адрес и сопоставление имени в DNS.

Шаг 5. Обновление веб-доступа к удаленным рабочим столам и подключениям к приложениям RemoteApp и рабочему столу

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

Но это еще не конец. Для RDS теперь включена балансировка нагрузки, но нужно обновить механизм направления пользователей на «правильное» приложение RemoteApp, чтобы обеспечить возможность работы в ферме. На этом этапе есть два параметра доступа пользователей, которые надо настроить: веб-доступ к удаленным рабочим столам и подключения к приложениям RemoteApp и рабочему столу. Далее предполагается, что оба этих параметра уже настроены в исходной среде с одним сервером.

Перейдите на серверах к узлу Local Users and Groups. Обеспечьте, чтобы учетные записи серверов веб-доступа к удаленным рабочим столам и посредника подключений к удаленным рабочим столам были членами группы TS Web Access Computers (Компьютеры веб-доступа к службам терминалов). Откройте апплет Remote Desktop Connection Manager (Диспетчер подключений к удаленным рабочим столам) и щелкните Add в разделе RD Web Access servers (рис. 5). Если вам не удается увидеть окно свойств подключения к удаленным рабочим столам и приложениям RemoteApp, добавьте имя своего сервера веб-доступа к удаленным рабочим столам в нижней части окна и щелкните Add.

Рис. 5 . Настройка свойств подключения к удаленным рабочим столам и приложениям RemoteApp

Далее развените узел Remote Desktop Connection Manager, щелкните правой кнопкой RemoteApp Sources и выберите Add RemoteApp Source (рис. 6). Укажите полное доменное имя фермы серверов RDS в качестве источника удаленного приложения RemoteApp. В процессе этой настройки подключение к рабочим столам и приложениям RemoteApp перенаправляется на ферму, а не на отдельный сервер.

Рис. 6 . Добавление источника удаленных приложений RemoteApp

Есть еще одна завершающая операция. Перейдите к узлу Administrative Tools/Remote Desktop Services/Remote Desktop Web Access Configuration и подключитесь с административными полномочиями. В окне Configuration (рис. 7) выберите вариант An RD Connection Broker server. Введите полное доменное имя сервера посредника подключений к удаленным рабочим столам в текстовом поле Source. Теперь у вас должна появиться возможность просматривать список приложений RemoteApp и выполнять балансировку пользовательских сеансов в рамках фермы RDSH.

Рис. 7 . Настройка веб-доступа к удаленным рабочим столам

Необъятное число панелей управления

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

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

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

Грег Шилдс (Greg Shields) носит звание MVP и является партнером в компании Concentrated Technology. Другие советы и подсказки Грега из рубрики «Компьютерщик на все руки» вы найдете на сайте ConcentratedTech.com..