Віртуалізація додатків від microsoft - просто та ефективно, windows it pro
Компоненти набору Microsoft Desktop Optimization Pack (MDOP) дозволяють створювати потужні комплексні рішення для оптимізації та автоматизації управління ІТ-інфраструктурою.
ІТ-інфраструктура для вашого підприємства
Microsoft Application Virtualization, або AppV, - це патентована технологія, пропонована Microsoft в рамках одного з напрямків загальної стратегії віртуалізації. На відміну від інших технологій, AppV «відокремлює» додатка від операційної системи і дозволяє їм функціонувати через мережеві служби, повністю позбавляючи від необхідності установки самого додатка на конкретну робочу станцію або термінальний сервер.
Технології AppV дозволяють організувати «потокову доставку» коду програми, виконання якого відбувається в повністю ізольованому віртуальному оточенні, не залишаючи слідів в самій операційній системі, що позбавляє адміністраторів і службу підтримки від вирішення цілої низки проблем, пов'язаних з сумісністю, міграцією та версійна додатків.
Звичайно, це вимагає розгортання певної інфраструктури, основу для якої і пропонує компонент Microsoft Application Virtualization зі складу Desktop Optimization Pack. У AppV версії 4.5 реалізовані такі її варіанти:
окремий самостійний потоковий сервер (так званий «полегшений варіант», Lightweight Solution);
автономний режим, при якому здійснюється поширення готових віртуалізованних додатків у вигляді * .msi пакетів (припустимо, через Software Installation Active Directory або навіть на знімних носіях).
Як «кінцевих пристроїв» для кожного з варіантів виступають робочі станції або сервер терміналів.
Розглянемо розгортання Microsoft Application Virtualization на прикладі і почнемо, як годиться, з побудови інфраструктури. З огляду на реалії виробництва, доведеться орієнтуватися на «полегшений варіант», так як «важкий» рішення зажадає деяких змін у членстві в групах Active Directory, а також або розгортання ще одного локального сервера SQL Server, або надання доступу на запис-читання до вже існуючого. Крім того, адміністратору AppV доведеться делегувати ряд повноважень у AD і на SQL Server, що в виробничих умовах, швидше за все, зустріне опір. Таким чином, в основі нашого середовища лежить звичайний рядовий сервер домену, на якому «поодинці» буде функціонувати самодостатній потоковий сервер AppV (див. Екран 1).
Процес настройки серверної складової прямолінійний і дуже простий. Перед установкою потокового сервера необхідно створити на ньому роль IIS, так як HTTP-транспорт IIS нам згодом буде потрібно. Далі встановлюємо Streaming Server з дистрибутива MDOP, запустивши відповідний майстер (див. Екран 2).
Майстер установки виконується зі збереженням всіх значень за замовчуванням, за винятком сторінки Advanced Settings, де ми знімаємо прапорець у параметра Enable User authentication, тому що не будемо використовувати контролер домену (див. Екран 3).
До перезавантаження сервера потрібно виконати ще одну дію: надати загальний доступ до папки C: Program FilesMicrosoft System Center App Virt Streaming Servercontent (хоча можна і до будь-якої іншої). Вона стане кореневою текою, в якій будуть зберігатися пакети додатків. На даний момент дозволу на загальний доступ і дозволу NTFS можна залишити за замовчуванням.
Після перезавантаження виконуємо ще одну дію - налаштовуємо потоковий сервер для роботи з HTTP. Це нова можливість версії 4.5, яка має ряд переваг (втім, і недоліків теж).
Перша перевага - відсутність згаданих організаційних проблем і надзвичайна простота настройки. Друге - IIS, які використовуються для цього, добре всім знайомі, і їх налаштування і обслуговування не викличуть труднощів.
Третє - використовується протокол передачі даних і порт, який зазвичай залишається відкритим на мережевих екранах і, як правило, не вимагає зміни існуючої настройки маршрутизаторів. Якби ми налаштовували потоковий сервер на використання «рідного» протоколу доставки коду додатків Real Time Streaming Protocol (RTSP), такі додаткові настройки треба було б зробити.
Недоліки такого варіанту наступні. Потоковий сервер без сервера управління інфраструктурою (Management Server) позбавлений практично всіх адміністративних зручностей повного варіанту. Він не здатний публікувати додатки на стороні клієнта, не підтримує формування значків віртуалізованних додатків на робочому столі, в меню і інших місцях, де можна було б ними безпосередньо скористатися, не враховує використання ліцензій на додатки, не дозволяє створювати набори додатків і прив'язувати їх публікацію до конкретних груп користувачів. Найсерйозніший недолік при використанні саме http полягає в тому, що не підтримує активне динамічне оновлення (Active Upgrade) додатків на клієнтах, якщо таке відбулося на сервері.
Для налаштування роботи сервера AppV через HTTP потрібно запустити оснащення IIS, перейти в вузол Default Website і створити на ньому віртуальну папку Content, яка б вказувала на раніше надану в загальний доступ папку Content (див. Екран 4).
Далі через контекстне меню слід увійти в налаштування Default Website, відкрити вкладку HTTP headers і створити два типи MIME: для розширення * .osd і розширення * .sft, вказавши тип MIME як App-V Application (див. Екран 5).
Після завершення налаштування серверної частини встановлюємо клієнт AppV на контрольну робочу станцію. При установці вказуємо налаштування сервера. Хоча в нашому випадку це і необов'язково. Всі інші параметри залишаємо за замовчуванням (див. Екран 6).
Ну ось, середа доставки додатки готова, тепер необхідно визначити перелік додатків, які будуть піддані віртуалізації, і групи користувачів, яким набори цих додатків будуть доставлятися.
Найчастіше самими затребуваними і критичними з точки зору доступності та взаємосумісності виявляються додатки офісного плану, і навіть на якийсь період освоєння AppV фахівцями питання «а чи можна в ньому віртуалізувати офісний пакет?» Був мірилом цінності продукту MDOP. Тому подальший розгляд можливостей та порядку використання AppV з пакета MDOP пройде саме на такому прикладі - віртуалізація пакету офісних додатків.
Для цього нам буде потрібно ще одна робоча станція, на яку буде встановлено додаток віртуалізації - секвенсор. Бажано, щоб ця система була максимально продуктивною. Крім того, одному з розділів її жорстких дисків повинна бути присвоєна буква віртуального системного диска, яка була вказана при установці клієнта AppV. За замовчуванням це буква Q. Саме на цей розділ і будуть встановлюватися додатки, що відслідковують секвенсором.
Це робиться для того, щоб настройки додатків залишалися незмінними для всіх клієнтських робочих станціях в оточенні сервера. Тому для секвенсора використовується логічний розділ Q, а на клієнтських робочих станціях, завдяки технології SystemGuard, створюється віртуальний Q-розділ.
Установка секвенсора теж виконується з дистрибутива MDOP і традиційно для MDOP не викликає ніяких проблем: все установки - по-замовчуванню (див. Екран 7).
Останній етап роботи в секвенсорі - вікно остаточних налаштувань перед збереженням проекту. Тут, крім виконання деяких обов'язкових змін відповідно до згаданої інструкцією, необхідно проконтролювати значення параметрів на вкладці Deployment. Саме вони визначають, як клієнт буде «спілкуватися» з потоковим сервером (див. Екран 8).
В результаті роботи секвенсора будуть створені такі файли:
файли значків додатків в окремому каталозі. При використанні сервера управління інфраструктурою вони використовуються при доставці значків додатків на робочий стіл користувача і «прив'язці» типів файлів до додатків;
файли * .OSD (формату Open Software Description) для кожного з віртуалізованних додатків. У моєму випадку після закінчення віртуалізації я залишив тільки Microsoft Word, Excel, Outlook, Powerpoint. У цих файлах XML описані всі необхідні атрибути запуску віртуального додатки клієнтом. Файл * .OSD також вказує на місце розташування файла.sft. Саме файл * .OSD використовується клієнтом AppV для установки з'єднання з потоковим сервером і початку завантажити програму;
файл * .SPRJ - файл проекту секвенсора. Він може використовуватися для подальшого коректування пакетів віртуалізованних додатків.
Файли * .OSD і * .SFT, а також каталог зі значками і маніфест слід скопіювати в папку Content на потоковому сервері. Настійно рекомендую також перевірити вміст файлів * .OSD вручну, особливо вміст тегів і. У моєму випадку це виглядало приблизно так, як показано на екрані 10.
Тепер необхідно створити комфортні умови для користувачів, тобто виконати «доставку» ярликів додатків в легкодоступні місця інтерфейсу і створити необхідні асоціації для розширень імен файлів, щоб їх можна було запускати звичним подвійним клацанням.
У нашому спрощеному сценарії полегшеної інфраструктури присутня тільки потоковий сервер. Як уже було згадано при описі недоліків цього варіанту, централізована публікація додатків на стороні клієнта з усіма атрибутами в такому випадку не виконується. Тому зробимо це вручну - скористаємося додатком SFTMIME. EXE, яке входить в комплект клієнтської поставки, запустивши його з командного рядка:
SFTMIME ADD PACKAGE: »office12»
/ MANIFEST \ str-srvcontent
Office12_manifest.xml
/ OVERRIDEURL \ str-srvcontent
office12_2.sft / GLOBAL
Взагалі, SFTMIME замислювалося як засіб віддаленого адміністрування клієнтів AppV. Будучи додатком для командного рядка, воно дозволяє виконати ті ж самі настройки, які виконуються в графічному режимі в оснащенні MMC Application Virtualization Client. Через використання SFTMIME в сценаріях реєстрації групових політик Active Directory можна виконати всі необхідні адміністративні завдання на клієнтах AppV, припустимо, зробити попередню завантаження додатків, відкликати окремі додатки, перепризначити потоковий сервер і.т.д.
Останнє, що залишилося зробити, - це призначити селективні дозволу користувачам на роботу з додатками. Адже не всі всім повинно бути доступно, вірно?
У варіанті Lightweight Solution дозволу на запуск додатків регулюються через списки ACL загальної папки Content або її підпапок на потоковому сервері і селективним наданням додатків різних груп користувачів в контексті SFTMIME ADD APP або SFTMIME DELETE. У моєму випадку в остаточному варіанті я роздав дозволу NTFS і дозволи на загальний доступ «з читання» для членів групи Authenticated Users на папку Content і цим обмежився.
При прийнятті рішення на впровадження Application Virtualization слід виконати ретельну оцінку існуючого оточення, а також визначитися з наявними обмеженнями і ризиками, пов'язаними з використанням цього продукту. Якщо умови жорсткі, а ризики для виробничого оточення неприйнятні, то цілком можна обмежитися і розглянутим спрощеним варіантом.
Втім, це має і зворотний бік: успішне впровадження нових технологій залежить не тільки від їх привабливості і перспектив, а й від простоти їх інтеграції, а також від підготовленості інфраструктури до нових віянь. Приклад, який я навів у своїй статті, абсолютно невимогливий до жодного, ні до іншого, і тому я вважаю, що MDOP і Application Virtalization приречені на успіх.
Валерій Волобуєв ([email protected]) - тренер-консультант з інформаційних технологій, УЦ «Мережеві Технології», компанія TechExpert, г. Киев