крепыш 12 октября 2012 в 19:24

Remote Desktop Services 2012 – Отказоустойчивая ферма Remote Connection Broker нового поколения

Если в версиях 2008/R2 использовалась схема Active/Passive для кластеризации службы RD Connection Broker , то в версии Windows Server 2012 схема работы служб RD переработана в корне. И для отказоустойчивой работы службы RD Connection Broker предлагается схема Active/Active .
Если в предыдущих версиях Connection Broker хранил всю информацию о пользовательских сессиях в локальной базе и, для развёртывания отказоустойчивой фермы, нам предлагалось использовать Failover Cluster, то в новой схеме Failover Cluster не используется. RD Connection Broker хранит свои данные в базе данных SQL Server , а клиенты подключаются к серверам RD Connection Broker используя DNS Round Robin .

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

Четыре виртуальных сервера на базе Windows Server 2012 Standard EN . Серверу, выполняющему роль контроллера домена в лесу contoso.com и DNS сервера присвоено имя DC1 и IP адрес 10.0.0.1. Сервер базы данных нашей фермы имеет имя SQL и IP адрес 10.0.0.10. Два сервера с установленной ОС, роли на них будут добавлены в процессе развертывания служб RDS.

Визуально схема будет выглядеть так:

В нашем случае серверы RD1 и RD2 будут являться как Remote Desktop Session Host , так и Remote Desktop Connection Broker .
На сервере SQL будет установлена SQL Server 2012 Standard (так же возможно использование SQL Server 2008 R2 в редакции не ниже Standard).

Предварительные настройки

1. Так как RD Connection Broker использует SQL Server в отказоустойчивой схеме, то сервер RD Connection Broker должен иметь полные привилегии доступа к SQL Server. Создадим в AD группу RDCB Servers , включим в нее наши RD Connection Broker серверы, а после дадим этой группе все привилегии доступа в разделе Security сервера SQL, используя SQL Server Management Studio .

2. Так же изменим параметры Windows Firewall на нашем SQL сервере, что бы он пропускал входящие подключения. Откроем окно командной строки или PowerShell и введем следующее: netsh advfirewall firewall add rule name = SQLPort dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = DOMAIN .

3. Создадим заранее папку для базы данных. Это может быть как локальная папка, так и расшаренная где либо еще. В нашем случае это будет локальная папка C:\Base на сервере SQL .

5. Создадим имя DNS Round Robin для каждого RD Connection Broker сервера. В нашем случае это будет 2 записи A с именем RD указывающих на IP адреса 10.0.0.3 и 10.0.0.4.

6. Перед тем как создавать нашу ферму, объединим наши будущие RDS сервера в группу. Откроем Manage – Create Server Group , добавим оба сервера в группу и дадим ей название RDS .

Создание отказоустойчивой фермы Remote Desktop Connection Broker

1. Запустите Add Roles and Features Wizard на сервере RD1 и переключите режим установки на Remote Desktop Services installation .

2. Оставьте опцию Standard deployment , так как мы будем делать развертывание на несколько серверов.

3. Выберем Session-based desktop deployment , так как в данной конфигурации мы не рассматриваем ферму VDI.

4. Помимо ролей RD Connection Broker и RD Session Host будет так же установлена роль RD Web Access . Отказаться от нее почему то нельзя. По крайней мере, я не нашел такой возможности.

5. На следующей странице выберем сервер RD1 для установки роли RD Connection Broker .

6. На странице RD Web Access выберем сервер доступа через веб. В нашем случае это будет тот же сервер что и RD Connection Broker . Установим чекбокс Install the RD Web Access role on the RD Connection Broker server и перейдем к следующей странице.

7. Добавим оба сервера в список для установки на них роли RD Session Host на одноименной странице и нажмем Next .

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

10. Приступим, собственно, к созданию отказоустойчивой конфигурации RD Connection Broker . Для этого перейдем на вкладку Overview раздела Remote Desktop Services менеджера серверов (Server Manager ) и нажмем правой клавишей мыши на изображении RD Connection Broker . Там для нас будет доступна одна функция – Configure High Availability .

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

12. На вкладке Configure High Availability нам нужно заполнить 3 строки. Database connection string должна выглядеть следующим образом DRIVER=SQL Server Native Client 11.0 (или 10.50 если вы используете SQL Server 2008 R2);SERVER=;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=. В нашем случае введем следующую строку DRIVER=SQL Server Native Client 11.0;SERVER=SQL.contoso.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB . В строку Folder to store database files введем путь заранее подготовленной нами папки C:\Base . В строку DNS round robin name введем созданный заранее FQDN нашей точки входа RD.contoso.com .

13. На странице подтверждения еще раз проверим введенные нами данные и нажмем Configure .

14. На странице Progress дождемся окончания конфигурации.

Собственно это все, как мы можем видеть на странице Overview раздела Remote Desktop Services менеджера сервера наш RD Connection Broker работает в режиме High Availability Mode . Можно использовать эту ферму RDS через точку входа RD.contoso.com .

Добавление серверов RD Connection Broker делается через то же самое контекстное меню на странице Overview .

Теги: Windows Server 8, Windows Server 2012, RDS, RDCB, Remote Desktop, Remote Desktop Connection Broker, Failover, high availability

В данной статье я приведу подробную пошаговую инструкцию по установке сервера терминалов (англ. 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 клиент .

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

В данной статье будет показано, как построить отказоустойчивый кластер 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. При создании кластера диски будут показаны как доступное хранилище.

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

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

Как мы видим, имя нашего домена – 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-прослушивателя:

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

Всем привет сегодня расскажу как настроить отказоустойчивый кластер Hyper-V в Windows Server 2012 R2. Напомню, что тоже саое мы с вами уже рассматривали для Hyper-V в Windows Server 2012 R2 .

Уже на этапе планирования будущей виртуальной инфраструктуры следует задуматься об обеспечении высокой доступности ваших виртуальных машин. Если в обычной ситуации временная недоступность одного из серверов еще может быть приемлема, то в случае остановки хоста Hyper-V недоступной окажется значительная часть инфраструктуры. В связи с чем резко вырастает сложность администрирования - остановить или перезагрузить хост в рабочее время практически невозможно, а в случае отказа оборудования или программного сбоя получим ЧП уровня предприятия.

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

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

В данном материале мы будем рассматривать наиболее простую конфигурацию отказоустойчивого кластера, состоящего из двух узлов (нод) SRV12R2-NODE1 и SRV12R2-NODE2, каждый из которых работает под управлением Windows Server 2012 R2. Обязательным условием для этих серверов является применение процессоров одного производителя, только Intel или только AMD, в противном случае миграция виртуальных машин между узлами будет невозможна. Каждый узел должен быть подключен к двум сетям: сети предприятия LAN и сети хранения данных SAN.

Вторым обязательным условием для создания кластера является наличие развернутой Active Directory, в нашей схеме она представлена контроллером домена SRV12R2-DC1.

Хранилище выполнено по технологии iSCSI и может быть реализовано на любой подходящей платформе, в данном случае это еще один сервер на Windows Server 2012 R2 - SRV12R2-STOR. Сервер хранилища может быть подключен к сети предприятия и являться членом домена, но это необязательное условие. Пропускная способность сети хранения данных должна быть не ниже 1 Гбит/с.

Следующим шагом добавим компоненту Отказоустойчивая кластеризация .

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

Миграцию виртуальных машин оставляем выключенной .

Остальные параметры оставляем без изменения. Установка роли Hyper-V потребует перезагрузку, после чего аналогичным образом настраиваем второй узел.

Затем перейдем к серверу хранилища, как настроить iSCSI-хранилище на базе Windows Server 2012 мы рассказывали в данной статье, но это непринципиально, вы можете использовать любой сервер цели iSCSI. Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин. Диск-свидетель - это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.

Создайте новую цель iSCSI и разрешите доступ к ней двум инициаторам, в качестве которых будут выступать узлы кластера.

И сопоставьте данной цели созданные виртуальные диски.

Настроив хранилище, вернемся на один из узлов и подключим диски из хранилища. Помните, что если сервер хранилища подключен также к локальной сети, то при подключении к цели iSCSI укажите для доступа сеть хранения данных .

Подключенные диски инициализируем и форматируем.

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

После чего откроем Диспетчер Hyper-V и перейдем к настройке виртуальных коммутаторов. Их название на обоих узлах должно полностью совпадать .

Теперь у нас все готово к созданию кластера. Запустим оснастку Диспетчер отказоустойчивых кластеров и выберем действие Проверить конфигурацию .

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

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

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

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

При создании кластера для него создается виртуальный объект, обладающий сетевым именем и адресом. Укажем их в открывшемся Мастере создания кластеров .

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

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

Затем щелкнем правой кнопкой мыши на объекте кластера в дереве слева и выберем Дополнительные действия - Настроить параметры кворума в кластере .

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

Для того, чтобы диск мог использоваться сразу несколькими участниками кластера на нем создается CSVFS - реализуемая поверх NTFS кластерная файловая система, впервые появившаяся в Windows Server 2008 R2 и позволяющая использовать такие функции как Динамическая (Живая) миграция, т.е. передачу виртуальной машины между узлами кластера без остановки ее работы.

Общие хранилища становятся доступны на всех узлах кластера в расположенииC:\ClusterStorage\VolumeN . Обратите внимание, что это не просто папки на системном диске, а точки монтирования общих томов кластера.

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

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

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

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

После выбора узла откроется стандартный Мастер создания виртуальной машины, работа с ним не представляет сложности, поэтому остановимся только на значимых моментах. В качестве расположения виртуальной машины обязательно укажите один из общих томов кластера C:\ClusterStorage\VolumeN .

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

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

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

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

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

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

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

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

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

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

Завершение работы приостанавливается до тех пор, пока не будут переданы все виртуальные машины.

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

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

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

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