Чи замислювалися коли-небудь, що робить сканер з VDI-станцією? Спочатку все виглядає добре: він прокидається як звичайний USB-пристрій і прозоро видно з віртуальної машини. Далі користувач дає команду на сканування, і все до біса падає. У кращому випадку - драйвер сканера, гірше - через пару хвилин софт сканера, потім може поефектувати і інших користувачів кластера. Чому? Тому що, щоб отримати п'ятимегабайтну стислу картинку, потрібно відправити через USB 2.0 на два-три порядки більше даних. Пропускна спроможність шини 480 Мбіт/с.
Тож тестувати треба три речі: UX, периферію та безпеку – обов'язково. Є різниця як тестувати. Можна встановити агентів локально на кожній віртуальній робочій станції. Це відносно бюджетно, але не вказує навантаження на канал і не зовсім вірно вважає навантаження на процесор. Другий варіант - розвернутися в іншому місці необхідною кількістю роботів-емуляторів і почати їх коннектити до реальних робочих місць як справжніх користувачів. Додасться навантаження від протоколу передачі відеопотоку екрана (точніше, змінених пікселів), розбір та відправлення мережевих пакетів, будуть зрозумілі навантаження на канал. Канал взагалі дуже рідко перевіряється.
UX – це швидкість виконання різних дій кінцевим користувачем. Є пакети тестів, які навантажують інсталяцію сотнями користувачів і роблять типові для них дії: запускають офісні пакети, читають PDF, браузять, рідко дивляться порно в робочий час і таке інше.
Досить хороший приклад, чому такі тести важливі заздалегідь, був у останній інсталяції. Там тисяча користувачів переїжджає до VDI, у них офіс, браузер та SAP. ІТ-відділ у компанії розвинений, тому є культура тесту навантаження перед впровадженнями. На мій досвід, зазвичай замовника доводиться вмовляти на таке, тому що витрати великі, а користь не завжди очевидна. Чи є ж розрахунки, де можна помилитися? Насправді такі тести розкривають місця, де думали, але перевірити не могли.
інсталяція
Шість серверів, конфігурація ось:
До СГД замовника у нас доступу не було, надавалася вона вже як місце як сервіс, фактично. Але ми знаємо, що там all-flash. Яка саме all-flash не знаємо, але розділи по 10 ТБ. VDI - VMware на вибір замовника, оскільки стек ІТ-команді вже знайомий, і все досить органічно доповнюється до цілісної інфраструктури. VMware дуже "підсаджує" на свою екосистему, але якщо бюджету в закупівлі вистачає - роками можна не знати проблем. Але це часто дуже велике «якщо». У нас хороша знижка і замовник про це знає.
Починаємо тести, тому що ІТ-команда не пускає в прод майже нічого без тестів. VDI це не та річ, яку можна запустити, а потім прийняти. Користувачі завантажуються поступово, і з проблемами можна зіткнутися через півроку. Чого, звісно, нікому не хочеться.
450 «користувачів» у тесті, навантаження генеруємо локально. Робоюзери роблять різні дії одночасно, ми вимірюємо час кожної операції протягом кількох годин роботи:
Дивимося, як будуть вести себе сервери, СГД. Чи зможе VDI створити потрібну кількість віртуальних робочих місць тощо? Оскільки замовник не пішов шляхом гіперконвергенції, а взяв флешову СГД, потрібно було перевіряти правильність сайзингу теж.
Власне, якщо десь дещо гальмує — потрібно змінювати налаштування VDI-ферми, зокрема, розподіл ресурсів між користувачами різних категорій.
периферія
З периферією зазвичай три ситуації:
- Замовник просто каже, що нічого не підключаємо (ну, крім гарнітур, вони зазвичай видно «з коробки»). Останні приблизно років п'ять я дуже рідко бачу гарнітури, які не підчепилися б самі по собі, і які не підхопила б VMware.
- Другий підхід – беремо і в рамках проекту впровадження VDI змінюємо периферію: беремо протестоване нами та підтримуване замовником. Випадок із зрозумілих причин рідкісний.
- Третій підхід - прокидаємо наявне залізо.
Про проблему зі сканерами ви вже знаєте: потрібно ставити проміжний софт на робочу станцію (тонкий клієнт), який отримує USB потік, стискає картинку і відправляє в VDI. В силу ряду особливостей, це не завжди можливо: якщо на Win-клієнтах (домашніх комп'ютерах і тонких клієнтах) все добре, то для *nix-складання зазвичай вендором VDI підтримується якийсь конкретний дистрибутив і починаються танці з бубном, як і на Mac -Клієнтах. На моїй пам'яті мало хто підключав локальні принтери з Linux-інсталяцій так, щоб вони на етапі налагодження працювали без постійних дзвінків на підтримку. Але це вже добре, якийсь час тому — навіть просто щоб працювали.
Відеоконференцзв'язок — усі замовники рано чи пізно хочуть, щоб це працювало та працювало добре. Якщо правильно спроектували ферму, то це працює добре, якщо неправильно — отримуємо ситуацію, коли у нас під час аудіоконференції зростає навантаження на канал плюс додатково крім цього виникає проблема того, що картинка відображається погано (full HD ні, обличчя з 9–16 пікселів) ). Виникає дуже сильна додаткова затримка, коли з'являється зашморг між клієнтом, робочою станцією VDI, сервером ВКС, звідти другим VDI та другим клієнтом. Правильно з'єднувати з клієнта на сервер ВКС, що потребує встановлення ще одного додаткового компонента.
USB-ключі - з ними взагалі проблем немає, смарт-карти тощо, все працює з коробки. Складнощі бувають зі сканерами штрих-кодів, принтерами етикеток, верстатами (так, було й таке), касами. Але все вирішується. З нюансами і не без сюрпризів, але зрештою вирішується.
Коли користувач дивиться Ютуб з VDI-станції, це найгірша ситуація і для навантаження, і для каналу. Більшість рішень пропонує HTML5 відео редірекшн. Стиснутий файл передають на клієнта, що там показує. Або клієнту передається посилання для прямого зв'язку браузера і відеохостингу (це рідше).
Безпека
Безпека зазвичай іскри на місці стиків компонентів та на клієнтських пристроях. На стиках в одній екосистемі на словах все має працювати добре. На практиці так буває відсотках у 90% випадків, і щось все одно треба доробляти. В останні роки дуже зручною виявилася ще одна покупка Вмвари - вони взяли в екосистему MDM для керування пристроями всередині компанії. У ВМів з'явилися нещодавно цікаві мережеві балансувальники (колишній Avi Networks), які дозволяють закрити питання розподілу потоків через рік після здачі VDI, наприклад. Ще одна суто вмварна особливість — гарна оптимізація філій завдяки їхньому свіжому шопінгу, коли вони взяли компанію VeloCloud, яка робить SD-WAN для філіальних мереж.
З погляду кінцевого користувача, архітектура та вендор майже непомітні. Глобально важливим є те, що є клієнт під будь-який пристрій, з планшета, маку, вин-тонкого клієнта можна підключитися. Були клієнти навіть для телевізорів, але зараз їх уже, на щастя, немає.
Особливість VDI-інсталяцій зараз у тому, що кінцевий користувач будинку просто не має комп'ютера. Часто є слабкий андроїд-планшет (іноді навіть з мишею або клавіатурою), або може взагалі пощастити і отримати комп'ютер на Win XP. Яка, як ви можете здогадатися, якийсь час не оновлювалася. І не оновиться вже ніколи. Або дуже слабкі машини, де клієнт не ставиться, програми не працюють, користувач не може працювати. На щастя, навіть дуже слабкі пристрої підходять (не завжди комфортно, але підходять) і це вважається великим плюсом VDI. Ну а щодо безпеки треба тестувати компрометацію клієнтських систем. Це трапляється досить часто.
У світлі рекомендацій Росспоживнагляду щодо організації роботи підприємств в умовах ризику COVID-19 підключення до своїх робочих місць в офісі дуже актуальне. Схоже, що ця історія надовго, і так, якщо ви думали про VDI, можна починати тестувати. Стане в нагоді. Рекомендації лежать , роз'яснення . Важливо, що за допомогою VDI можна переобладнати приміщення для дотримання вимог. Регулятором запроваджуються певні норми дистанціювання. Наприклад, в офісі площею 50 кв. м не може перебувати понад п'ять співробітників.
Ну а якщо є питання щодо VDI не для коментарів — ось моя пошта: [захищено електронною поштою].
Джерело: habr.com