В данной статье я приведу подробную пошаговую инструкцию по установке сервера терминалов (англ. terminal server), или по другому, службы удаленных рабочих столов в Windows Server 2012. В принципе, последовательность действий не сильно отличается от установки , однако есть ряд значимых отличий. Итак:

1. Что понадобится

1. Компьютер (сервер) с установленной на нем Windows Server 2012 (об установки этой ОС, я писал ) и права администратора на данном сервере.
2. Действительная клиентская лицензия сервера терминалов, приобретенная по одной из существующих программ лицензирования. (В данной статье я буду использовать найденный в интернете номер соглашения, по программе Enterprise Agriment. На момент написания статьи рабочими были номера: 6565792, 5296992, 3325596, 4965437, 4526017.)
3. Доступ к сети Internet для активации сервера лицензирования и установки лицензий (возможна также активация и по телефону).

2. Установка службы удаленных рабочих столов

Запускаем Диспетчер серверов. Его можно запустить с ярлыка на панели задач, или же выполнив команду servermanager.exe (Для этого необходимо нажать комбинацию клавиш Win + R, в появившемся окне в поле «Открыть » (Open ) написать имя команды и нажать «ОК »).

В меню, в верхнем правом углу, выбираем «Управление » (Manage ) — «Добавить роли и компоненты » (Add Roles and Features ) .

Запустится «Мастер добавления ролей и компонентов » (Add Roles and Features Wizard) . Нажимаем «Далее » (Next) на начальной странице.

Оставляем переключатель на «Установка ролей и компонентов » (Role-based or features-based installation ) и снова жмем «Далее » (Next) .

Выбираем тот сервер из пула серверов, на который будет установлена служба терминалов. В моем примере это данный локальный сервер. Нажимаем «Далее » (Next) .

Отмечаем роль «» (Remote Desktop Services ) в списке ролей и жмем «Далее » (Next) .

Компоненты оставляем в том виде, в котором они есть. Ничего не отмечая жмем «Далее » (Next) .

Читаем описание службы удаленных рабочих столов и нажимаем «Далее » (Next) .

Теперь необходимо выбрать устанавливаемые службы ролей. Как минимум нам пригодится «Лицензирование удаленных рабочих столов » (Remote Desktop Licensing ) (также соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты » (Add Features ) в появившемся мастере)

и «» (Remote Desktop Session Host ) (опять соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты » (Add Features ) в открывшемся окне). Отметив необходимы службы ролей, нажимаем «Далее » (Next) .

Все параметры установки роли определены. На последней странице установим флаг «Автоматический перезапуск конечного сервера, если требуется » (Restart the destination server automatically if required ) , подтвердим выбор нажав «Да » (Yes ) в появившемся окне и нажмем «Установить » (Install ) для запуска установки службы.

Если все прошло хорошо, после перезагрузки, увидим сообщение об успешной установке всех выбранных служб и компонент. Нажимаем «Закрыть » (Close ) для завершения работы мастера.

3. Определение сервера лицензирования для службы удаленных рабочих столов

Теперь запустим «» (RD Licensing Diagnoser) . Сделать это можно из диспетчера серверов, выбрав в правом верхнем меню «Средства » (Tools ) — «Terminal Services » — «Средство диагностики лицензирования удаленных рабочих столов » (RD Licensing Diagnoser ) .

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

Сервер лицензирования указывается теперь в локальных групповых политиках. Для запуска редактора выполним команду gpedit.msc .

Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:

• «Конфигурация компьютера » (Computer Configuration )
  • «Административные шаблоны » (Administrative Templates )
    • «Компоненты Windows » (Windows Components )
      • «Службы удаленных рабочих столов » (Remote Desktop Services )
        • «Узел сеансов удаленных рабочих столов » (Remote Desktop Session Host )
          • «Лицензирование » (Licensing )

Откроем параметры «Использовать указанные серверы лицензирования удаленных рабочих столов » (Use the specified Remote Desktop license servers ) , кликнув 2 раза по соответствующей строке.

В окне редактирования параметров политики, переставим переключатель в «Включено » (Enabled ) . Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В моем примере сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем «ОК » .

Далее меняем параметры политики «Задать режим лицензирования удаленных рабочих столов » (Set the Remote licensing mode ) . Также устанавливаем переключатель в «Включено » (Enabled ) и указываем режим лицензирования для сервера узла сеансов удаленных рабочих столов. Возможны 2 варианта:

• «На пользователя» (Per User)
• «На устройство» (Per Device)

Для того, чтобы разобраться чем отличаются эти режимы, рассмотрим простой пример. Предположим, у Вас есть 5 лицензий. При режиме «На устройство » вы можете создать неограниченное число пользователей на сервере, которые смогут подключаться через удаленный рабочий стол только с 5 компьютеров, на которых установлены эти лицензии. Если выбрать режим «На пользователя », то зайти на сервер смогут только 5 выбранных пользователей, независимо с какого устройства они подключаются.

Выбираем тот режим, который наиболее подходит для ваших нужд и нажимаем «ОК » .

Изменив вышеперечисленные политики, закрываем редактор.

Возвращаемся в оснастку «Средство диагностики лицензирования удаленных рабочих столов » (RD Licensing Diagnoser ) и видим новую ошибку, указывающую на то, что сервер лицензирования указан, но не включен.

Для запуска сервера лицензирования переходим в «» (RD Licensing Manager ) . Найти его можно в диспетчере серверов, вкладка «Средства » (Tools ) — «Terminal Services » — «Диспетчер лицензирования удаленных рабочих столов » (Remote Desktop Licensing Manager ) .

Здесь найдем наш сервер лицензирования, со статусом «Не активирован » (Not Activated ) . Для активации кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Активировать сервер » (Activate Server ) .

Запустится Мастер активации сервера. Жмем «Далее » (Next) на первой странице мастера.

Затем выбираем метод подключения («Авто » (Automatic connection ) по умолчанию) и жмем «Далее » (Next) .

Вводим сведения об организации (эти поля обязательны для заполнения) после чего жмем «Далее » (Next) .

Вводим дополнительные сведения об организации (необязательно) и снова нажимаем «Далее » (Next) .

Сервер лицензирования активирован. Теперь следует установить лицензии. Для этого нажимаем «Далее » (Next) оставив включенным флаг «Запустить мастер установки лицензий » .

4. Установка лицензий на сервер лицензирования службы удаленных рабочих столов

Затем выбираем необходимую вам программу лицензирования. В моем примере это «Соглашение «Enterprise Agreement «» . Жмем «Далее » (Next) .

Указываем версию продукта, тип лицензии и количество лицензий в соответствии с вашей программой лицензирования. Жмем «Далее » (Next) .

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

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

Ну и наконец возвращаемся в «Средства диагностики лицензирования удаленных рабочих столов » (RD Licensing Diagnoser ) и видим, что ошибок нет, а число лицензий, доступных клиентам, соответствует тому, что мы вводили на предыдущем шаге.

На этом установка сервера терминалов в Windows Server 2012 завершена.

5. Подключение к серверу терминалов

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

Помогла ли Вам данная статья?

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

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

Как мы видим, имя нашего домена – domain.local. Для доступа к терминальным службам снаружи будет использоваться доменное имя domain.ru. Таким образом, в нашем DNS домена domain.local нам необходимо будет создать дополнительную зону с именем domain.ru, где мы потом создадим запись RDS.domain.ru, которая будет ссылаться на IP адрес терминальной фермы.

1. Установка терминальных служб на сервер RDS1.

1.1 Добавляем роли «Службы удаленных рабочих столов» (Remote Desktop Services) и «Службы политики сети и доступа» (Network Policy and Access Services). Выбираем для установки следующие службы ролей:

1.2 Создадим в ДНС нашего домена запись RDFarm.domain.local, которой присвоим IP адрес 192.168.0.80. Это будет внутренний адрес нашей фермы, а также адрес кластера NLB.

1.3 Создадим в ДНС зоне domain.ru нашего домена запись RDS.domain.ru, которой присвоим тот же IP адрес, что и адрес кластера - 192.168.0.80. Это будет внешний адрес нашей фермы, через который будут заходить удаленные пользователи.

1.4 Заходим в оснастку Remote Desktop Services – RemoteApp Manager – RD Gateway и настраиваем параметры следующим образом:

На закладке Digital Signature указываем сертификат, который надо предварительно запросить. Для выполнения этого шага в вашем домене должен быть центр сертификации (CA). На сервере RDS1 запустите mmc и добавьте оснастку Certificates (computer account):

Теперь на закладке Digital Signature мы можем указать наш сертификат:

1.5 Заходим в оснастку Remote Desktop Services – RemoteApp Manager и в разделе RemoteApp Programs и добавим одно удаленное приложение. Пусть это будет калькулятор.

Нажмем кнопку «Properties» и добавим в список пользователей, которые смогут запускать наш Калькулятор, группу rd_users.

1.6 Заходим в оснастку Remote Desktop Services – RD Gateway Manager и настраиваем свойства RDS1 (Local). Но перед этим необходимо запросить еще один сертификат (см. пункт 1.4), но на сей раз с Common Name внешнего адреса – RDS.domain.ru.

На закладке Private Key не забудьте указать, что ключ может быть экспортирован.

После получения сертификата экспортируйте его в pfx-файл – он нам понадобится для настройки второго сервера.

Теперь указываем этот сертификат в свойствах нашего шлюза удаленных рабочих столов:

Переходим на закладку Server Farm, где добавим наш сервер RDS1 в ферму шлюзов:

Обратите внимание, что на данном этапе поле статус не обязательно должно иметь состояние «ОК».

1.7 Заходим в оснастку Remote Desktop Services – RD Gateway Manager - RDS1 (Local) – Policies – Connection Authorization Policies и создаем политику авторизации подключений при помощи мастера:

1.8 Заходим в оснастку Remote Desktop Services – RD Gateway Manager - RDS1 (Local) – Policies – Resource Authorization Policies и создаем политику авторизации приложений минуя мастер (Create New Policy – Custom):

1.9 Заходим в оснастку Remote Desktop Services – RD Session Host Configuration и настраиваем свойства подключения RDP-Tcp следующим образом:

Нажимаем на кнопку «Select» и указываем сертификат с Common Name нашей фермы – RDFarm.domain.local (он уже был установлен на сервер в пункте 1.4).

Остальные параметры не настраиваем.

Здесь же, в RD Session Host Configuration, настраиваем параметры лицензирования.

1.10 Для проверки правильности настройки приложения RemoteApp заходим на адрес localhost/RDWeb

2. Установка терминальных служб на сервер RDS2.

2.1 Добавляем роли «Службы удаленных рабочих столов» (Remote Desktop Services) и «Службы политики сети и доступа» (Network Policy and Access Services). Выбираем для установки следующие службы ролей:

Узел сеансов удаленных рабочих столов (Remote Desktop Session Host)

Шлюз удаленных рабочих столов (Remote Desktop Gateway)

Веб-доступ к удаленным рабочим столам (Remote Desktop Web Access)

Сервер политики сети (NPS)

При установке служб ставим галочку «Require NLA», остальные настройки сконфигурим позже. Перезагружаем сервер при первом же требовании.

2.2 Настраиваем второй сервер RDS2 точно таким же образом, как и настроен наш первый сервер за исключением того, что сертификаты уже запрашивать не нужно – их надо импортировать с сервера RDS1. Для импортирования сертификатов запустите mmc и добавьте оснастку Certificates (computer account):

Укажите путь к pfx файлам, содержащим сертификаты, и импортируйте их в личные сертификаты компьютера RDS2.

3. Создание и конфигурирование терминальной фермы.

3.1 Устанавливаем роль RD Connection Broker на сервер BROKER.

3.2 Добавляем сервера RDS1 и RDS2 в локальную группу Session Broker Computers на сервере BROKER.

3.3 Добавляем все наши три сервера в локальную группу TS Web Access Computers на серверах RDS1 и RDS2

3.4 На сервере BROKER добавляем наши сервера RDS1 и RDS2 в группу RD Web Access (Admin Tools > Remote Desktop Services > Remote Desktop Connection Manager > Add RD Web Access Server).

3.5 Сперва на сервере RDS1, а затем и на RDS2, заходим в Remote Desktop Services > Remote Desktop Session Host Configuration и меняем настройки RD Connection Broker:

3.6 Настраиваем удаленные приложения RemoteApp на работу с нашей фермой. Для этого на серверах RDS1 и RDS2 заходим в Remote Desktop Services > RemoteApp Manager и меняем параметр Server Name:

3.7 На сервере BROKER идем в Remote Desktop Services > Remote Desktop Connection Manager > RemoteApp Sources и жмем кнопку «Add RemoteApp Source…»:

Добавляем все наши возможные ресурсы RemoteApp: RDFarm.domain.local, RDS1.domain.local, RDS2.domain.local и RDS.domain.ru.

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

3.8.1 Устанавливаем компонент Network Load Balancing на сервера RDS1 и RDS2. Далее открываем оснастку Network Load Balancing Manager на сервере RDS1 и создаем кластер:

Включаем в балансировку только 443 и 3389 TCP порты.

3.8.2 Добавляем второй компьютер (RDS2) в NLB кластер

3.9 Удостоверяемся, что на серверах RDS1 и RDS2, в свойствах сервера RD Gateway Manager на закладке Server Farm указаны оба наших сервера:

3.10 На серверах RDS1 и RDS2 заходим в оснастку IIS Manager, далее Sites – Default Web Site – RDWeb – Pages и справа жмем Application Settings, где присваиваем параметру DefaultTSGateway значение RDS.domain.ru:

4. Публикация фермы RemoteApp приложений на ISA Server.

Вначале необходимо установить наш сертификат с Common Name «RDS.domain.ru» на ISA сервер (сделать это можно так же, как в случае с сервером RDS2, когда мы переносили на него сертификат с RDS1).

Этот раздел я не буду рассматривать слишком подробно, а обойдусь лишь наиболее важными скриншотами с настройками правила публикации и созданием WEB-прослушивателя:

Спасибо за внимание.

Remote Desktop Connection Broker (RD Connection Broker) – это функционал роли терминального сервера Windows Server. RD Connection Broker позволяет равномерно распределить нагрузку между серверам в ферме Remote Desktop (при подключении к RDS пользователя перенаправляет на наименее загруженный сервер), обеспечить доступ пользователей к VDI и RemoteApp, а также реализует возможность переподключения пользователей к своим сессиям (при подключении к новому серверу RDS, RDCB проверяет наличие незавершенной сессии на других серверах фермы, и в случае ее обнаружения новая сессия не создается, а пользователь перенаправляется в старую сессию).

В этой статье мы рассмотрим процесс настройки отказоустойчивого высоко-доступного экземпляра RD Connection Broker , обеспечивающего свой функционал при выходе из строя одного из серверов с ролью RDCB.

В отличии от реализации , Connection Broker в Windows Server 2012 обеспечивает высокую доступность в режиме Active/Active, когда каждый из серверов RDCB является активным и обрабатывает входящие запросы. Это позволяет обеспечить высокую доступность и масштабируемость RDCB в больших фермах Remote Desktop. Для хранения данных RDCB используется БД на MS SQL Server.

Примечание . В Windows Server 2008 R2 поддерживалась кластеризация службы RDCB только в режиме Active/Passive. Т.е. для фермы RD серверов поддерживался только один активный сервер Connection Broker.

Требования для внедрения отказоустойчивого RDCB

• Как минимум 2 сервера с ролью RDCB (под ОС Windows Server 2012 / 2012 R2)
• SQL Server (редакция SQL server 2008 R2 Standard или выше) c минимум 4 Гб RAM
• Наличие установленного SQL Server Native Client
• Полные права серверов RD Connection Broker на БД SQL и каталог установки SQL
• Минимум один сервер с ролью Remote Desktop Session Host в ферме
• Разрешенные исключения для портов SQL server в фаерволе Windows

Важно . Перед началом создания отказоустойчивой конфигурации RDCB, убедитесь, что эта роль установлена только на одном из серверов.

Всем серверам, на которых будут установлены роли RD Connection Broker необходимо назначить статические ip-адреса и включить в домен Active Drectory.

• RDCB1.domain.ru — 172.25.104.71
• RDCB2.domain.ru — 172.25.104.171

В Active Directory создадим отдельную группу безопасности RDS Connection Brokers , в которую нужно включить все сервера RDCB.

Далее на отдельном сервере (или SQL-кластере) устанавливается SQL Server версии 2008 R2 или 2012 Standard.

На SQL сервере с помощью SQL Server Management Studio в разделе Security нужно создать новый login и предоставить доменной группе RDCB права с возможностью создания и редактирования баз данных. Также этой группе нужно предоставить полные права на каталог установки SQL.

На SQL сервере нужно создать каталог, в котором будут храниться файлы БД, например, C:\SQLDB , и предоставить этой же группе полные права на каталог.

На всех серверах с ролью RDCB необходимо установить. Его нужно скачать отдельно с сайта MS, либо запустить прямо с установочного диска (на установочном диске SQL Server 2012 он хранится в каталоге \1033_ENU_LP\x64\Setup\x64\sqlncli.msi).

Для SQL server 2008 R2 нужен SQL native client 10, для SQL Server 2012 — SQL Native client 11.

В брандмауэра SQL-сервера создадим новое правило, открывающее порт TCP 1433 для доменных машин. Сделать это можно так:

netsh advfirewall firewall add rule name = SQLSRVPort dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = DOMAIN

Следующий шаг – создание в DNS зоне A записей для реализации балансировки нагрузки (Round Robin) между серверами RD Connection Broker. Например, DNS имя нашей фермы RDCB будет RDCB_lb . Создадим две следующие A записи вида:

• A RDCB_lb.domain.ru 172.25.104.71 (ip адрес RDCB1)
• A RDCB_lb.domain.ru 172.25.104.171 (ip адрес RDCB2)

С помощью консоли Server Manager на первом из серверов RDCB устанавливаем роль RD Connection Broker (если еще не установлена).

После установки роли RDCB используется маленькая локальная база SQL, хранящаяся на локальном диске сервера RD Connection Broker в каталоге c:\windows\rdcbDb\ .

В этой базе хранится информация о ферме и терминальный сессиях пользователей. Так как она расположена на локальной машине, другие сервера RDCB не смогут ее использовать. Для создания HA для RDCB нужно перенести ее на выделенный SQL сервер, на котором она будет доступна другим серверам.

Для переноса БД на выделенный SQL Server нужно перейти на вкладку управления Remote Desktop Services -> Overview . Для запуска мастера создания отказоустойчивой конфигурации RD Connection Broker, щёлкнем ПКМ по изображению роли RD Connection Broker и выбираем пункт Configure High Availability . Запустившийся мастер должен создать БД на MS SQL Server и перенести в нее локальную конфигурацию.

Заполним три поля:

• Database Connection String – строка подключения с базе на SQL сервере.Для SQL 2008 R2 : DRIVER=SQL Server Native Client 10.0;SERVER=
  

  Для SQL 2012 :DRIVER=SQL Server Native Client 11.0;SERVER=;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=

• Folder to store database files – каталог, в котором будут храниться файла БД: C:\SQLDB . Папка находится на SQL сервере, мы ранее ее создали и предоставили доступ группе серверов RDCB.
• DNS Round Robin name : FQDN имя фермы RDCB, для которой мы создавали записи в DNS для Round Robin (в нашем примере это RDCB_lb ). Именно по этому адресу будут обращаться RDP клиенты при подключении к серверам RD Connection Broker.

Затем откроем SQL Server Manager на сервере СУБД и убедимся, что была создана новая база. Переходим на вкладку Security , выберем ранее добавленную группу — > свойства, и в качестве БД по-умолчанию выбираем базу RDS. Потом отмечаем роли db_owner и public .

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

Для этого щелкаем ПКМ по иконке RD Connection Broker, и выбираем пункт Add RD Connection Broker Server .

Указываем имя второго сервера, на котором нужно установить роль Connection Broker и жмем Далее.

На этом настройка High Availability конфигурации Connection Broker завершена.

Итак, мы создали высоко доступный сервис RD Connection Broker на Windows Server 2012. Вы можете протестируйте доступность RDCB, отключив один из серверов фермы RDCB. В этом сценарии точкой отказа остается SQL server. Отказоустойчивость SQL сервера можно реализовать с помощью HA SQL кластера или зеркалирования базы SQL.

Данная статья написана в рамках общего описания настройки терминальных служб в Windows server 2012. Центральная статья с описанием .

Отказоустойчивость в RDS

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

Отказоустойчивость серверной части можно обеспечить на двух уровнях:

• аппаратный — когда выход из строя физического сервера не ведет к долгому простою терминального сервера. Это легко осуществимо при использовании платформы виртуализации от любого производителя , Citrix, Microsoft, у них у всех есть технология высокой доступности HA (High Availability)
• программный — когда выходит из строя операционная система (Windows server 2008 или 2012) и администратору приходится восстанавливать данные из резервной копии с неизбежной потерей информации. Чтобы пережить программные сбои нужно настраивать кластеры, дублирующие серверы и не забывать о резервном копировании.

Клиентское устройство , очевидно, что это должен быть тонкий клиент, на котором не хранится никакой информации, только базовые настройки подключения. Он должен уметь подключаться к терминальному серверу (серверам) по RDP протоколу и отображать на экране монитора удаленный рабочий стол или опубликованные приложения. Таких тонких клиентов сейчас на рынке очень много, от недорогих китайских (3000 руб) до дорогих брендовых на платформе Windows Embedded (до 20 000 руб). Я предлагаю использовать вот такие решения — , .

Распределение нагрузки и отказоустойчивость . Если клиент будет подключаться напрямую к терминальному серверу (точка-точка), то в такой схеме не будет никакой отказоустойчивости. Выходит из строя сервер — работа встает. Нужно несколько терминальных серверов с одинаковым функционалом, чтобы при поломке первого клиент мог бы продолжить работу на втором, третьем и т.д. Для этого устанавливают посредник подключения к удаленными рабочим столам. В 2012 сервере (и ранее в 2008) в этой роли выступает RD connection broker – это роль, которую можно добавить через мастер добавления ролей в диспетчере сервера. Посредник подключений в первую очередь распределяет нагрузку между терминальными серверами, отправляет пользователей на тот сервер терминалов, на котором в данный момент меньше пользователей.
Для отказоустойчивости роль посредника устанавливали на два сервера, затем объединяли их в кластер, если в Windows server 2008 Broker работал по схеме Active – Passive, т.е. один из серверов посредника, находясь в простое, ждал, пока откажет основной, то в 2012 эта схема улучшена (переработана) и работает как Active –Active кластер. Клиенты поочередно обращаются то к одному, то к другому Connection Broker (за счет работы службы DNS Round Robin), который уже указывает на терминальный сервер к которому ему следует подключаться.
Но есть одно НО , для работы в отказоустойчивом режиме Connection Broker использует базу данных MSSQL. По логике отказоустойчивости нужно и ее дублировать, создавать кластер, а это еще больше усложнит схему.
Не забываем, про доменные службы, которые должны обеспечивать аутентификацию пользователей, DNS сервер должен разрешать имена, без этого наши терминальные службы тоже работать не будут.

В итоге, для отказоустойчивой схемы потребуется как минимум два сервера с Ролью Connection Broker, два терминальных сервера, два MSSQL сервера, два контроллера домена и два DNS сервера. Плюс два сервера, на которых будут хранениться профили пользователей. Общая папка, в которой они будут храниться, должна реплицироваться между двумя серверами.

Теперь я задам вопрос: » Стоит ли городить такой огород из разнообразных служб Microsoft? Может быть есть другой способ?»
Думаю, что есть. Не создаем кластеры из MSSQL, контроллеров доменов, DNS серверов, а используя технологии виртуализации, реплицируем виртуальные машины на другой физический сервер и не забываем делать резервное копирование. Но такая схема потребует вмешательства администратора при сбое, он должен будет удостовериться, что основные виртуальные машины вышли из строя и в ручном режиме запустить реплики.

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

В 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 представлены на рисунке.

Для отказоустойчивого кластера 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. В результате будет запущен мастер добавления ролей и компонентов.

Первой после запуска мастера откроется страница приветствия 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.

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

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

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

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

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

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

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

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

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

После ввода имени и IP-адреса нажмите кнопку Next, чтобы увидеть страницу подтверждения (экран 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.

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

* C:ClusterStorageVolume1 * C:ClusterStorageVolume2

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

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

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

Пример настройки хранилища iSCSI

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

Сначала в сети iSCSI SAN были созданы три логических устройства LUN. Один LUN был создан для диска кворума кластера (520 Мбайт). Другой LUN предназначен для 10 виртуальных машин и имеет размер 375 Гбайт. Третий LUN выделен для небольшой тестовой виртуальной машины. Все три LUN представлены в формате NTFS.

После того, как были созданы LUN, была выполнена настройка iSCSI Initiator на обоих узлах Server 2012. Чтобы добавить цели iSCSI, был выбран iSCSI Initiator в меню Tools в диспетчере сервера. На вкладке Discovery я нажал кнопку Discover Portal. В результате появилось диалоговое окно Discover Portal, куда были введены IP-адрес (192.168.0.1) и порт iSCSI (3260) сети SAN.

Затем я перешел на вкладку Targets и нажал кнопку Connect. В диалоговом окне Connect To Target («Подключение к целевому серверу») я ввел целевое имя iSCSI SAN. Оно было получено из свойств SAN. Имя зависит от поставщика SAN, имени домена и имен созданных LUN. Помимо целевого имени я установил режим Add this connection to the list of Favorite Targets.

По завершении настройки iSCSI эти LUN появились на вкладке Targets iSCSI Initiator. Чтобы автоматически подключать LUN при запуске Server 2012, я убедился, что они перечислены на вкладке Favorite Targets, как показано на экране A.

Экран A. Настройка iSCSI Initiator

Наконец, были назначены буквенные обозначения устройствам LUN с помощью оснастки Disk Management консоли управления Microsoft (MMC). Я выбрал Q для диска кворума и W для диска, используемого для виртуальных машин и общих томов кластера (CSV). При назначении буквенных обозначений необходимо сначала назначить их на одном узле. Затем нужно перевести диски в автономный режим и сделать аналогичные назначения на втором узле. Результаты назначения букв дискам для одного узла приведены на экране B. При создании кластера диски будут показаны как доступное хранилище.