У цій статті я наведу докладну покрокову інструкціюпо встановленню сервера терміналів (англ. 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 або 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 автоматично 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 файли– каталог, в якому зберігатимуться файли БД: 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 або 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. Під час створення кластера диски будуть показані як доступне сховище.