Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено
Чудили ли сте се някога какво прави един скенер с VDI станция? Първоначално всичко изглежда добре: препраща се като обикновено USB устройство и е „прозрачно“ видимо от виртуалната машина. След това потребителят дава команда за сканиране и всичко отива по дяволите. В най-добрия случай - драйверът на скенера, по-лошо - след няколко минути софтуерът на скенера, след което може да засегне други потребители на клъстера. Защо? Защото, за да получите компресирано изображение от пет мегабайта, трябва да изпратите два до три порядъка повече данни през USB 2.0. Пропускателната способност на шината е 480 Mbit/s.

Така че трябва да тествате три неща: UX, периферни устройства и сигурност – задължително. Има разлика в начина на тестване. Можете да инсталирате агенти локално на всяка виртуална работна станция. Това е сравнително евтино, но не показва натоварването на канала и не изчислява точно натоварването на процесора. Вторият вариант е да разположите необходимия брой емулаторни роботи на друго място и да започнете да ги свързвате към реални работни места като реални потребители. Ще се добави натоварването от протокола за предаване на видео поток на екрана (по-точно променени пиксели), анализиране и изпращане на мрежови пакети и натоварването на канала ще стане ясно. Каналът по принцип се проверява много рядко.

UX е скоростта, с която крайният потребител извършва различни действия. Има тестови пакети, които зареждат инсталацията със стотици потребители и извършват типични действия за тях: стартиране на офис пакети, четене на PDF файлове, сърфиране, рядко гледане на порно през работно време и т.н.

Доста добър пример за това защо такива тестове са важни предварително беше в последната инсталация. Там хиляда потребители преминават към VDI, имат офис, браузър и SAP. ИТ отделът на компанията е развит, така че има култура на тестване на натоварване преди внедряване. Според моя опит обикновено клиентът трябва да бъде убеден да направи това, тъй като разходите са високи и ползите не винаги са очевидни. Има ли изчисления, където можете да направите грешка? Всъщност такива тестове разкриват места, където са мислили, но не са могли да проверят.

монтаж

Шест сървъра, конфигурацията е:

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Нямахме достъп до системата за съхранение на клиента; тя всъщност беше предоставена като място като услуга. Но знаем, че има изцяло флаш. Не знаем кой флаш е, но дяловете са 10 TB. VDI - VMware по избор на клиента, тъй като ИТ екипът вече е запознат със стека и всичко е доста органично допълнено, за да образува пълна инфраструктура. VMware е много „закачен“ за своята екосистема, но ако имате достатъчен бюджет за доставки, може да нямате никакви проблеми години наред. Но това често е много голямо „ако“. Имаме добра отстъпка и клиентът знае за това.

Започваме тестове, защото IT екипът не пуска почти нищо в производство без тестове. VDI не е нещо, което можете да стартирате и след това да приемете. Потребителите се зареждат постепенно и е напълно възможно да срещнете проблеми след шест месеца. Което, разбира се, никой не иска.

450 „потребители“ в теста, натоварването се генерира локално. Робо-потребителите извършват различни действия едновременно, ние измерваме времето на всяка операция за няколко часа работа:

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Да видим как ще се държат сървърите и системите за съхранение. Ще може ли VDI да създаде необходимия брой виртуални десктопи и т.н. Тъй като клиентът не следваше пътя на хиперконвергенцията, а взе изцяло флаш система за съхранение, беше необходимо да се провери и правилността на оразмеряването.

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Клопки при преминаване към VDI: какво да тествате предварително, за да не е мъчително болезнено

Всъщност, ако нещо се забави някъде, трябва да промените настройките на VDI фермата, по-специално разпределението на ресурсите между потребители от различни категории.

периферия

Обикновено има три ситуации с периферни устройства:

  • Клиентът просто казва, че не свързваме нищо (е, с изключение на слушалките, те обикновено се виждат „извън кутията“). През последните около пет години много, много рядко съм виждал слушалки, които не са били взети сами и които не са били взети от VMware.
  • Вторият подход е да вземем и променим периферните устройства като част от проекта за внедряване на VDI: ние вземаме това, което ние и клиентът сме тествали и поддържали. Случаят разбираемо е рядък.
  • Третият подход е да се хвърли през съществуващия хардуер.

Вече знаете за проблема със скенерите: трябва да инсталирате междинен софтуер на работна станция (тънък клиент), който получава USB поток, компресира изображението и го изпраща към VDI. Поради редица функции, това не винаги е възможно: ако всичко е наред на Win клиенти (домашни компютри и тънки клиенти), тогава за *nix компилации доставчикът на VDI обикновено поддържа специфична дистрибуция и започват танците с дайре, като на Mac -клиенти. В моите спомени малко хора свързваха локални принтери от инсталации на Linux, така че да работят на етапа на отстраняване на грешки без постоянни обаждания към поддръжката. Но това вече е добре, преди време - дори само за работа.

Видеоконференции – всички клиенти рано или късно искат тя да работи и да работи добре. Ако фермата е проектирана правилно, тогава тя работи добре, ако не е правилно, получаваме ситуация, при която по време на аудиоконференция натоварването на канала се увеличава, плюс в допълнение към това има проблем, че картината се показва лошо (няма пълна HD, лице от 9–16 пиксела ). Много силно допълнително забавяне възниква, когато се появи цикъл между клиента, VDI работната станция, сървъра за видеоконференции и оттам втория VDI и втория клиент. Правилно е директното свързване от клиента към видеоконферентния сървър, което изисква инсталирането на друг допълнителен компонент.

USB ключове - изобщо няма проблеми с тях, смарт карти и други подобни, всичко работи от кутията. Трудности могат да възникнат с баркод скенери, принтери за етикети, машини (да, имаше такова нещо) и касови апарати. Но всичко се решава. С нюанси и не без изненади, но в крайна сметка решен.

Когато потребителят гледа YouTube от VDI станция, това е най-лошата ситуация както за натоварването, така и за канала. Повечето решения предлагат HTML5 видео пренасочване. Компресираният файл се прехвърля към клиента, където се показва. Или на клиента се изпраща връзка за директна комуникация между браузъра и видео хостинга (това е по-рядко).

сигурност

Сигурността обикновено се осъществява на компонентни интерфейси и на клиентски устройства. На кръстовищата в една екосистема, на думи, всичко трябва да работи добре. На практика това се случва в 90% от случаите и все нещо трябва да се довърши. През последните години друга покупка на Vmvara се оказа много удобна - те добавиха MDM към екосистемата за управление на устройства в компанията. Виртуалните машини наскоро придобиха интересни мрежови балансьори (преди Avi Networks), които ви позволяват да затворите проблема с разпределението на потока една година след завършването на VDI, например. Друга чисто основна характеристика е добрата оптимизация на клоновете благодарение на тяхното ново пазаруване, когато поеха компанията VeloCloud, която прави SD-WAN за клонови мрежи.

От гледна точка на крайния потребител, архитектурата и доставчикът са почти невидими. Това, което е важно в световен мащаб, е, че има клиент за всяко устройство; можете да се свържете от таблет, Mac или Windows тънък клиент. Имаше дори клиенти за телевизии, но сега, за щастие, вече ги няма.

Особеността на инсталациите на VDI сега е, че крайният потребител просто няма компютър у дома. Често имате слаб таблет с Android (понякога дори с мишка или клавиатура) или може дори да имате късмет и да получите компютър, работещ с Win XP. Което, както се досещате, не е обновявано от известно време. И никога повече няма да се актуализира. Или много слаби машини, където клиентът не е инсталиран, приложенията не работят, потребителят не може да работи. За щастие дори много слаби устройства са подходящи (не винаги удобни, но подходящи) и това се счита за голям плюс на VDI. Е, по отношение на сигурността е необходимо да се тества компрометирането на клиентските системи. Това се случва доста често.

В светлината на препоръките на Роспотребнадзор за организиране на работата на предприятията, изложени на риск от COVID-19, свързването с вашите работни места в офиса е много важно. Изглежда, че тази история ще продължи дълго време и да, ако сте мислили за VDI, можете да започнете да тествате. Ще ми е от полза. Препоръките са тук, уточнения тук. Важно е, че VDI може да се използва и за преоборудване на пространства, за да отговарят на изискванията за съответствие. Регулаторът въвежда определени стандарти за дистанциране. Например в офис от 50 кв. m не може да има повече от пет служители.

Е, ако имате въпроси относно VDI, които не са за коментар, ето имейла ми: [имейл защитен].

Източник: www.habr.com

Добавяне на нов коментар