ІТ-інфраструктура для вашого підприємства
попередні відомості
Перш ніж розглянути всі кроки типового процесу підключення до розгортання настільної системі, буде корисно визначити типи служб, необхідних для побудови архітектури VDI. На малюнку показані основні кроки, необхідні для функціонування VDI, від початкового підключення користувача до формування робочої сесії VDI, за винятком таких технологій, як віртуалізація додатків від Microsoft Application Virtualization (App-V), що переміщуються профілі і т. Д.
Малюнок. компоненти VDI
На третьому кроці посередник підключень до віддалених робочих столів взаємодіє з Active Directory для визначення прав доступу користувача. Завдяки цьому взаємодії у властивостях користувача відображаються також налаштування особистих робочих столів, які ми обговоримо нижче.
На кроці 5 користувачеві необхідно знати точку початкового підключення RDP, так як призначена йому віртуальна машина клієнту VDI поки що невідома, якщо тільки у користувача немає налаштованого особистого робочого столу. Сервер сеансів віддалених робочих столів Remote Desktop Session Host налаштовується в режимі перенаправлення підключень, тобто сервер приймає запити користувачів на підключення RDP-, а потім перенаправляє клієнта до сеансу DVI. Вузол сеансів віддалених робочих столів підключається до посередника підключень до віддаленого робочого столу Remote Desktop Connection Broker для визначення точки підключення клієнта. У даній архітектурі сервер сеансів віддалених робочих столів і посередник підключень до віддаленого робочого столу - це один і той же сервер, проте ви не зобов'язані їх розміщувати на одному вузлі (хоча зазвичай робиться саме так через тісний взаємозв'язок між цими ролями).
На кроці 7 клієнт підключається по протоколу RDP до своєї віртуальної машині через шлюз віддалених робочих столів (якщо підключення здійснюється ззовні корпоративної мережі); на цьому процес підключення завершується. При реєстрації користувача завантажується його переміщуваний профіль, а також дані з перенаправлених папок і додатки, доступні через App-V.
Хоча процес підключення до розміщеної настільної системі включає безліч компонентів і кроків, з точки зору користувача, це гладкий і майже миттєвий процес, що надає повнофункціональну настільну систему за допомогою будь-якого клієнта RDP.
На малюнку показаний елемент, який ми не розглядали, - це Microsoft System Center Virtual Machine Manager (VMM). І хоча VMM не є абсолютно необхідним для середовища VDI, він буде дуже корисний в управлінні цим середовищем за допомогою засобів управління фермою Hyper-V, бібліотек, підтримки PowerShell і інших інструментів.
Веб-доступ до віддалених робочих столів
Якщо ви хочете створити конфігураційний файл для автоматичної настройки компонента підключення до віддалених робочих столів і програм RemoteApp для клієнтів Windows 7, використовуйте параметр Create Configuration File в диспетчері підключень до віддаленого робочого столу. При цьому створюється файл, який можна запускати на клієнті Windows 7 для автоматичної настройки. Це дуже вдале рішення для великих систем.
Посередник підключень до віддаленого робочого столу
Служба Remote Desktop Connection Broker - це мозок середовища VDI. Вона обмінюється інформацією і управляє всіма іншими компонентами, найбільш тісно взаємодіючи з сервером сеансів віддалених робочих столів в режимі перенаправлення, тому посередник підключень до віддаленого робочого столу і сервер сеансів віддалених робочих столів в режимі перенаправлення часто встановлюються в одній і тій же системі. Однак, якщо у вас більше 250 одночасних підключень, вам може знадобитися установка даних ролей на різних серверах.
Коли створюється пул VDI, необхідно вказати сервери Hyper-V, на яких розміщено віддалені машини, а потім вибрати клієнтські віртуальні машини, які будуть входити до складу пулу. Майстер створення пулу VDI виконає інші настройки.
Служба Remote Desktop Connection Broker обробляє всі вхідні запити VDI і спочатку перевіряє, чи не залишився у користувача відключений сеанс в пулі VDI. Якщо так, то користувач підключається до цього сеансу, в іншому випадку йому призначається відсутня в даний момент віртуальний робочий стіл.
Вузол сеансів віддалених робочих столів в режимі перенаправлення
Ідея використання сервера сеансів віддалених робочих столів в режимі перенаправлення не нова. Такий підхід застосовувався в попередній версії Windows Server при створенні великої ферми термінальних серверів. Щоб позбавити користувачів від необхідності підключення до різних серверів терміналів, початкова точка входу завжди є виділеним сервером сеансів, який тільки взаємодіє з посередником підключень і перенаправляє підключення RDP на потрібний сервер. Такий же процес відбувається і в середовищі VDI, нам як і раніше потрібна початкова точка підключення RDP для клієнтів RDP, якою є сервер сеансів віддалених робочих столів в режимі перенаправлення. Даний вузол перенаправляє клієнтів RDP до відповідної клієнтської віртуальній машині, що надає операційну систему.
Можна вручну налаштувати сервер сеансів віддалених робочих столів для роботи в режимі перенаправлення. Однак, якщо ми використовуємо майстер створення пулу VDI в диспетчері підключень до віддалених робочих столів, настройка сервера сеансів віддалених робочих столів виконується автоматично, як показано на екрані 2. Зауважимо, що, як тільки сервер сеансів віддалених робочих столів переводиться в режим перенаправлення, він уже не може більше запускати звичайні сеанси, а тільки буде виконувати перенаправлення підключень.
Екран 2. Автоматична настройка сервера сеансів віддалених робочих столів за допомогою майстра пулу VDI
Вузол віртуалізації віддалених робочих столів
Служба Remote Desktop Virtualiza-tion Host встановлюється на кожному вузлі Hyper-V, який включається в пул VDI. Ця служба дозволяє службі посередника підключень до віддаленого робочого столу обмінюватися інформацією з вузлами Hyper-V, запускати і зупиняти віртуальні машини і збирати внутрішню інформацію для забезпечення клієнтських підключень.
Шлюз віддалених робочих столів
Служба шлюзу віддалених робочих столів инкапсулирует трафік RDP в пакети HTTPS, забезпечуючи в захищеному режимі RDP через корпоративні брандмауери без необхідності відкривати на брандмауерах додаткові порти і без додаткових VPN-рішень. Шлюз віддалених робочих столів можна використовувати для налаштування параметрів: хто може підключатися через даний шлюз, куди підключатися, а також для налаштування підтримуваних параметрів протоколу RDP, таких як перенаправлення пристроїв.
Високодоступних рішення VDI
Побудова рішення VDI вимагає централізації середовища робочих столів в єдиному центрі обробки даних. Якщо відбувається збій на сервері, то користувач може продовжувати роботу в локальній операційній системі. Але якщо ми розгортаємо VDI, то все середовище робочих столів тепер знаходиться в центрі обробки даних, так що якщо якась частина VDI виходить з ладу, користувач повністю позбавляється настільного середовища і не може працювати. Забезпечення відмовостійкості всіх елементів VDI стає критично важливим завданням. На щастя, у нас є рішення для кожної частини архітектури VDI.
Служба балансування мережного навантаження Network Load Balancing (NLB) застосовується для розподілу запитів між декількома екземплярами шлюзу віддалених робочих столів. Ми можемо задіяти як службу NLB, вбудовану в систему Windows, так і апаратний балансувальник навантаження. Ті ж технології NLB можна використовувати для забезпечення високої доступності служби веб-доступу до віддалених робочих столів.
Вузли Hyper-V можуть бути розміщені в відмов кластерів таким чином, що при збої вузла Hyper-V клієнтська віртуальна машина переміщається на інші вузли. Якщо буде потрібно, технологія динамічної міграції Live Migration може бути використана для переміщення працюючих клієнтських віртуальних машин між вузлами при технічному обслуговуванні серверів. Однак, оскільки призначені для користувача настройки і дані відокремлені від екземпляра операційної системи, якщо один екземпляр виходить з ладу, користувачам потрібно всього лише перейти на альтернативний екземпляр операційної системи. Установки та вміст знову будуть доступні.
Особисті робочі столи або робочі столи в складі пулу
До сих пір ми розглядали пули для клієнтів VDI, тобто таку схему організації, при якій кілька віртуальних машин з клієнтськими операційними системами групуються в пул. Коли користувачі підключаються до пулу, їм автоматично призначається одна з віртуальних машин, не яка у даний момент. При виході користувача з системи дана віртуальна машина повертається в пул. Оскільки користувач при кожному підключенні, найімовірніше, отримує іншу віртуальну машину, нам необхідні різні рішення віртуалізації (наприклад, переміщувані профілі, перенаправлення папок, віртуалізація додатків) для забезпечення цілісної робочого середовища.
Робочі столи в складі пулу повинні бути робочими столами за замовчуванням для всіх користувачів. Однак для деяких користувачів може виникнути необхідність мати один і той же екземпляр операційної системи при кожному підключенні. Можливо, вони якимось особливим чином налаштовують свою систему або їм потрібно встановити додаток, яке не може бути віртуалізованних. У будь-якому випадку у нас є можливість статичного призначення окремої віртуальної машини будь-якого користувача, щоб цей користувач завжди отримував одну і ту ж клієнтську операційну систему. Це називається особистим робочим столом і налаштовується в консолі Active Directory Users and Computers, як показано на екрані 3. Користувачеві можна призначити тільки один особистий робочий стіл, віртуальна машина в якості особистого робочого столу може бути призначена тільки одному користувачеві, особистий робочий стіл не повинен входити до складу пулу VDI, а повинен бути звичайною віртуальною машиною в середовищі віртуалізації. Необхідно, щоб ім'я особистого робочого столу збігалося з ім'ям віртуальної машини, яка повинна бути повним ім'ям FQDN, наприклад client.savilltech.net, тобто віртуальній машині необхідно призначати ім'я FQDN примірника клієнтської операційної системи.
Екран 3. Призначення користувачу особистого робочого столу
Налаштування клієнтської віртуальної машини
Для зручності в якості клієнтської операційної системи найкраще використовувати Windows 7. При розгортанні VDI на базі служб RDS необхідно заздалегідь створити всі екземпляри віртуальних машин і включити їх в пул; зараз немає можливості динамічного створення або напрямку потоку операційної системи для створення пулу віртуальних машин (така можливість є в Citrix XenDesktop). Для спрощення процесу розгортання віртуальних машин і операційної системи можна задіяти такі технології, як VMM.
Необхідно здійснити деякі додаткові настройки в клієнтських віртуальних машинах для забезпечення управління клієнтськими операційними системами на сервері віртуалізації віддалених робочих столів і підключення до них клієнтів. Основні дії, які потрібно виконати на кожній клієнтської операційної системи:
- дозволити віддалений робочий стіл Remote Desktop;
- додати відповідних користувачів в групу Remote Desktop Users;
- дозволити RPC;
- налаштувати виключення в брандмауері для віддаленого управління службами;
- налаштувати дозволу в протоколі RDP для сервера віртуалізації віддалених робочих столів.
Є ще один цікавий момент, що відноситься до середовищі операційних систем клієнтських віртуальних машин. У нас є кілька варіантів клієнтської операційної системи, що розділяються між багатьма користувачами. Необхідно обмежити доступ до цих розділяються клієнтським середах, щоб користувачі не могли змінювати налаштування операційної системи, а також встановлювати або видаляти програми. Однак, в залежності від конкретного середовища, нам може знадобитися повертати операційну систему в певний стан при кожному завершенні сеансу роботи з системою. Для цього можна використовувати знімки Hyper-V і RDS.
Для кожної віртуальної машини можна зробити знімок, в імені якого є текст RDV_Rollback. Даний знімок повинен бути зроблений, коли віртуальна машина знаходиться в «чистому» стані, так як нам потрібно повертатися до цього стану при кожному завершенні сеансу роботи з системою. Знімок можна зробити і при працюючій, і при непрацюючій віртуальній машині, але необхідно, щоб в процесі створення знімка в системі не було сеансу користувача. Коли користувач завершує сеанс роботи з віртуальною машиною в середовищі VDI, до якої він підключився через службу посередника підключень до віддаленого робочого столу, стан даної віртуальної машини повертається до знімка RDV_Rollback. Зауважимо, що можливість створення знімка RDV_Rollback є тільки у віртуальних машин в пулі, але не у особистих віртуальних робочих столів.
Якщо ви вибираєте застосування RDV_Rollback для того, щоб кожен користувач при реєстрації отримував «чисту» середу, в середовищі VDI доводиться застосовувати якийсь прийом, що відноситься до членства в домені AD. Зазвичай пароль облікового запису комп'ютера автоматично змінюється кожні 30 днів. Якщо ми періодично будемо повертати систему для виміру тиску - наприклад, після кожного завершення сеансу в системі, - старий пароль облікового запису комп'ютера, який присутній в знімку RDV_Rollback, перестане діяти, після того як комп'ютер змінить пароль. Це може статися, коли користувач зареєструється в системі на 30-й день дії пароля, і може привести до збоїв в перевірці достовірності облікового запису комп'ютера і необхідності скидання його пароля. Є кілька способів вирішення цієї проблеми. Один з них - заборона зміни пароля облікового запису комп'ютера, який можна реалізувати за допомогою групових політик. Однак даний підхід може мати небажані наслідки щодо безпеки і тому не рекомендований до використання.
наступні кроки
Поділіться матеріалом з колегами і друзями