Виртуелизација и перформансе апликација: комплетан водич за максимално искоришћавање ваше инфраструктуре

Информатек Дигитал » Средства » Виртуелизација и перформансе апликација: комплетан водич за максимално искоришћавање ваше инфраструктуре

Виртуелизација , једноставно речено, подразумева креирање виртуелних верзија физичких ресурса (сервера, складишта података, мрежа или апликација) за покретање више окружења на истом хардверу. Ова могућност „сечења“ физичког сервера на неколико логичких инстанци је основа рачунарства у облаку и већине модерних дата центара.

Виртуелна машина (ВМ) је изолован систем са сопственим виртуелним процесором, меморијом, складиштем и мрежом, изграђен од физичких ресурса хоста. Свака ВМ се понаша као да је независан рачунар и обично је енкапсулирана у једној или више датотека, што је чини релативно лаким за премештање, копирање и враћање.

Компонента која све ово омогућава је хипервизор или VMM (Virtual Machine Monitor). Његова функција је да раздвоји физичке ресурсе хоста (CPU, RAM, диск, мрежу) и додели их различитим виртуелним машинама којима су потребни, контролишући њихову употребу и изолујући их једне од других тако да квар у једној виртуелној машини не утиче на остатак система.

Постоје две главне врсте хипервизора . Тип 1 (bare metal) ради директно на серверском хардверу и уобичајен је у дата центрима и приватним облацима. Тип 2 се инсталира као апликација преко главног оперативног система (на пример, десктоп хипервизор за покретање више виртуелних машина на лаптопу).

У Линукс екосистему, KVM (Kernel-based Virtual Machine - виртуелна машина заснована на језгру) је посебно релевантан , хипервизор типа 1 интегрисан у језгро који омогућава виртуелним машинама да користе перформансе и могућности Линукса, са веома прецизном контролом процесора, меморије и уређаја.

Шта је виртуелизација апликација и како се разликује од виртуелизације сервера?

Виртуелизација апликација одваја апликацију од њеног оперативног система тако да програм ради без стварне инсталације на корисничком уређају. Апликација „верује“ да комуницира са оперативним системом, али у стварности комуницира са посредничким слојем (хипервизор апликација или технологија изолације) који преусмерава приступ датотекама, регистру и другим ресурсима.

Обично се ове апликације покрећу на централном серверу (у дата центру или облаку) и испоручују се преко мреже (LAN или интернет) на кориснички уређај. Крајњем кориснику, апликација делује као нативна, али је заправо објављена или виртуелизована у контролисаном окружењу.

За разлику од виртуелизације сервера, која функционише на нивоу целог оперативног система , виртуелизација апликација функционише на нивоу појединачних програма : Word документа, CRM-а, ERP-а, алата за дизајн итд. Ово значајно поједностављује управљање, изолацију и ажурирања, али уводи изазове у погледу перформанси везаних за мрежу, складиштење и корисничке профиле.

Предности виртуелизације апликација за кориснике, ИТ и пословање

Са становишта крајњег корисника , главна предност је слобода. Могу да користе свој омиљени уређај (компанијски лаптоп, персонални рачунар, танки клијент, таблет) и приступају корпоративним апликацијама без бриге о инсталирању, ажурирању или одржавању било чега. За њих је прелазак са једног уређаја на други готово беспрекоран: пријављују се и имају спремне пречице за коришћење.

За ИТ администраторе , виртуелизација апликација представља значајно олакшање. Уместо распоређивања и ажурирања софтвера на стотинама или хиљадама рачунара, они инсталирају и одржавају апликацију на једном или неколико сервера и објављују је овлашћеним корисницима. Ово централизује управљање на једној локацији и чини примену закрпа, промена верзија, безбедносних конфигурација и политика много бржим.

Програмери такође имају користи. Могу имати различита виртуелизована окружења на истом систему за тестирање кода на различитим верзијама оперативних система или комбинацијама софтвера, без потребе за подешавањем сложених физичких лабораторија. Штавише, изолација коју пружа слој виртуелизације омогућава им да отварају потенцијално оштећене или опасне датотеке без угрожавања система домаћина.

За организацију у целини, виртуелизација апликација олакшава иницијативе као што је BYOD (Bring Your Own Device - Донеси свој уређај) , смањује потребу за куповином моћних корпоративних уређаја, поједностављује подршку и обично се претвара у значајне уштеде у дуплираним лиценцама, сатима подршке и раном обнављању хардвера.

Важна ствар је усклађеност са прописима . Пошто се осетљиви подаци не налазе на корисничком уређају (већ у дата центру или облаку), лакше је поштовати прописе као што су HIPAA или PCI-DSS, јер је површина напада смањена, а контрола приступа и ревизија су централизоване.

Утицај виртуелизације на перформансе: процесор, РАМ, диск и мрежа

Виртуелизација увек уводи одређено оптерећење ресурса јер се појављује додатни слој између апликације и хардвера (хипервизор, систем за објављивање, удаљени клијент итд.). Иако је ова казна обично мала ако је платформа правилно димензионисана, вреди разумети где је најприметнија.

На нивоу процесора , бенчмарк тестови показују да типична виртуелна машина која ради на KVM-у или VMware vSphere-у постиже између 5% и 7,5% мање перформанси од истог система који ради директно на голом хардверу. Ова разлика је прихватљива за већину пословних апликација (канцеларијски пакети, веб апликације, ERP), али може бити критична за рачунарски захтевне задатке, вештачку интелигенцију или 3D рендеровање.

Код DDR4 у односу на DDR5 RAM меморију , ефективна брзина може да се смањи за око 7-13% због додатног управљања које захтева хипервизор. У веома захтевним окружењима, ово захтева или превелику величину меморије или ограничавање броја виртуелних машина по хосту како би се спречила уска грла.

Најприметнија разлика је у меморији (IOPS) . Тестови са алатима као што је fio показују пад перформанси од око 17-25% у 4K насумичним операцијама читања/писања у поређењу са истим диском у „голом металу“. Избор NVMe низова, високоперформансних SSD дискова, кеш меморије и доброг дизајна дељене меморије је кључан за глатко функционисање виртуелних машина и виртуелизованих апликација.

Латенција мреже такође може да се повећа, посебно када много виртуелних машина дели исти физички интерфејс или када се саобраћај са интензивном графиком или видеом премешта између удаљених сесија. Дизајн мреже (VLAN-ови, QoS, пропусни опсег, растерећење) и коришћење ефикасних протокола за објављивање графике значајно утичу на корисничко искуство.

Windows, App-V и VDI/RDS окружења: перформансе у пракси

У модерним Windows окружењима (Windows 7 SP1, Windows 10, Windows 11, Windows Server 2012 R2 и 2016), виртуелизација апликација помоћу Microsoft App-V је једна од кључних технологија за испоруку апликација у сценаријима услуга удаљене радне површине (RDS) и VDI инфраструктурама.

У овим окружењима, корисници обично раде на непостојаним машинама (виртуелним машинама или RDSH хостовима који се често регенеришу). Да би се осигурало да корисници могу приступити својим виртуелним апликацијама у року од неколико секунди након пријављивања, кључно је оптимизовати App -V клијента , решење за управљање профилима и саму основну слику.

Корисничко искуство зависи од неколико међусобно повезаних интервала: времена од тренутка када корисник унесе своје акредитиве до тренутка када може да интерагује са радном површином, времена од тада до почетка ажурирања објављивања App-V, трајања тог ажурирања и коначно, времена потребног да пречица виртуелне апликације или повезивање датотеке постану доступне.

Оптимизација ових времена подразумева комбиновање App-V конфигурација ( режим дељеног складиштења садржаја , ограничења истовременог објављивања, очување корисничких интеграција), добро решење за профилисање (UE-V или други UPM) и основну стратегију слике дизајнирану према главном циљу: максималне перформансе или максимална уштеда простора за складиштење.

Случајеви употребе: приступ оријентисан на перформансе у односу на складиштење

Можемо груписати App-V имплементације у неперзистентним, стајним VDI/RDSH окружењима у два главна екстремна сценарија, знајући да се у пракси многе компаније налазе негде између: једна је оптимизована за перформансе , а друга фокусирана на смањење потрошње складишног простора.

У сценарију оријентисаном на перформансе, основна слика унапред укључује неке или све релевантне пакете виртуелних апликација, као и њихове групе за повезивање. Ово подразумева додатну припрему и одржавање слике, али нуди најбоље корисничко искуство: апликације изгледају практично спремне од тренутка када се корисник пријави.

Приступ оријентисан на складиштење избегава укључивање пакета специфичних за кориснике у основну слику, спречавајући затрпавање дељених дисковних низова подацима који многим корисницима можда нису потребни. Овај приступ даје приоритет смањењу величине слика виртуелних машина, по цену померања неких операција конфигурације на време пријављивања, чиме се мало повећава време потребно да одређене апликације постану доступне.

У пракси је уобичајено да се приступ усмерен на перформансе примењује на подскуп критичних корисника или пакета (нпр. особље корисничке службе или интензивно коришћене пословне апликације), а приступ усмерен на складиштење на повремене кориснике или апликације које су мање осетљиве на време покретања система.

Припрема окружења и основне слике за App-V

Да би виртуелизација апликација у VDI или RDSH функционисала глатко, основно решење за управљање сликама и профилима (UE-V или други UPM) мора бити правилно припремљено. Грешка у овој фази обично доводи до бесконачних пријављивања, изгубљених интеграција или непотребних дуплих публикација.

У приступу перформансама, кључни кораци укључују омогућавање системски интегрисаног App-V клијента , активирање UE-V (или еквивалентног решења) помоћу шаблона конфигурације App-V, конфигурисање режима складишта дељеног садржаја (SCS) да би се подаци објављивали само на диску и подешавање регистра да задржава корисничке интеграције након пријављивања.

Поред тога, сви глобални и кориснички пакети и групе за повезивање морају бити унапред конфигурисани (коришћењем команди као што су Add-AppvClientPackage и Add-AppvClientConnectionGroup), а глобални пакети морају бити унапред објављени. У неким случајевима, препоручује се извршавање глобалних и корисничких циклуса објављивања/ажурирања, опозивање објављивања корисничких циљних пакета и чишћење VFS уноса у профилима (на пример, у AppData\Local и AppData\Roaming везаним за App-V).

Код приступа оријентисаног на складиштење, припрема је слична, али су само глобалне групе повезивања и пакети унапред конфигурисани. Пакети специфични за кориснике су изостављени из основне слике како би се избегло повећање величине и коришћења диска виртуелних машина.

Поред тога, важно је разумети да ће ИТ администрација морати редовно да ажурира основну слику како би одражавала промене у верзијама пакета, безбедносним закрпама и новим правима приступа. У неким окружењима биће потребно управљати неколико различитих слика за различите корисничке профиле.

Критични параметри перформанси у App-V клијенту

Унутар App-V клијента постоји неколико подешавања регистра која директно утичу на брзину публикација и оптерећење процесора, диска и мреже, посебно на RDS хостовима са много истовремених корисника.

Режим дељеног складишта садржаја (SCS) омогућава да се само метаподаци објављивања чувају на локалном диску, док се остатак ресурса апликације учитавају на захтев из централног спремишта (SAN, сервер садржаја). Ово штеди локалне IOPS и смањује простор на диску, под условом да постоји мрежна веза са малим кашњењем са сервером садржаја.

Опција PreserveUserIntegrationsOnLogin спречава клијента да дезинтегрише и поново интегрише корисничке интеграције из пакета који нису унапред конфигурисани приликом пријављивања. Ако овај кључ није омогућен и постоји много неконфигурисаних корисничких пакета, свако пријављивање може довести до двоструког објављивања за сваки пакет, што значајно утиче на време пријављивања.

Још један важан параметар је MaxConcurrentPublishingRefresh , који дефинише колико корисника може истовремено покренути ажурирање објављивања. Ако га оставите без ограничења на RDS серверу, то може проузроковати веома велике скокове оптерећења процесора када се много корисника истовремено пријави. Постављање разумне вредности ублажава ове скокове, по цену да, у сценаријима са великим таласима пријављивања, неки корисници могу искусити нешто дуже време чекања да виде нове објављене апликације.

Управљање корисничким профилима: UE-V и друга UPM решења

Да би се виртуелне апликације покренуле готово тренутно у неперзистентним окружењима, неопходно је да решење за управљање корисничким профилима одржава и примењује исправне „интеграције корисника“ између сесија: кључеве регистра, пречице, меније „Старт“, каталоге App-V итд.

Мајкрософтова виртуелизација корисничког искуства (UE-V) је у великој мери фокусирана на VDI и RDS сценарије. Она бележи и чува корисничка подешавања и аутоматски их примењује када се корисник пријави на други уређај или сесију. За App-V, UE-V може да ради са одређеним шаблонима који бележе тачне путање регистра и датотека где се чувају интеграције.

Једна важна особеност је руковање .lnk датотекама (пречицама). UE-V подржава уклањање .lnk екстензије са листе искључених датотека само у сценаријима где сви кориснички уређаји имају исти скуп апликација инсталираних на истој путањи. Ако овај услов није испуњен (на пример, апликација је инсталирана само на једном рачунару или на другој путањи), синхронизација .lnk датотека може довести до неисправних пречица.

Када користите друга UPM решења (дискове корисничких профила, производе трећих страна), кључно је да она могу: да сачувају одређене корисничке интеграције (дневнике и фасцикле), да синхронизују профил у одговарајуће време (пријава или покретање апликације, пре објављивања App-V) и да забележе промене на тим локацијама пре одјаве.

У App-V, услужни програм SyncAppvPublishingServer.exe је представљен како би се решењима за профилисање пружио јасан окидач: он покреће ажурирање објављивања корисника при пријављивању, али дозвољава да се оно одложи док се профил потпуно не учита. Ово спречава App-V да објави на непотпуном или застарелом профилу.

Водич за корисничко искуство: шта се дешава при сваком пријављивању

Посматрајући ток корак по корак, можемо боље разумети како се виртуелизација апликација доживљава у свакодневном животу корисника, у зависности од тога да ли усвајамо приступ усмерен ка перформансама или складиштењу.

У приступу заснованом на перформансама , прво пријављивање на неперзистентни VDI/RDSH покреће објављивање или ажурирање корисника. Ако је то први пут да је корисник примио виртуелне апликације, операција траје уобичајено време. Након завршетка, решење за профилисање бележи интеграције корисника, обично након одјаве, са ефектом сличним чувању остатка стања корисника.

У почетним фазама, UPM решење прво примењује све корисничке интеграције пре него што App-V почне да освежава процес објављивања. Корисници виде пречице на радној површини или у менију „Старт“ од самог почетка, а многе од њих су одмах функционалне. Ако нема промена дозвола, процес објављивања се завршава за неколико секунди. Када дође до промена, трајање се повећава у зависности од броја и сложености виртуелизованих апликација.

Као резултат тога, очувањем 100% корисничких интеграција, оптерећење током објављивања је минимизирано : систем подешава само промене дозвола или верзија, а апликације су спремне за веома кратко време од пријављивања.

Код приступа заснованог на складиштењу , прво пријављивање такође покреће корисничку публикацију, са нормалним трајањем. Међутим, и при том првом пријављивању и при наредним пријављивањима, потреба за претходном конфигурацијом (додавањем или ажурирањем) корисничких пакета може продужити доступност апликације. Уобичајено је додати 10 секунди или више, у зависности од количине и сложености пакета.

У овом случају, процеси објављивања и ажурирања морају поново конфигурисати све виртуелне апликације при сваком пријављивању, што неизбежно продужава фазу освежавања објављивања. Ово штеди простор на диску, али жртвује део брзине пријављивања.

Животни циклус App-V пакета и стања на чекању

Управљање животним циклусом App-V пакета такође утиче на перформансе и доследност верзија које корисници виде. Када администратор ажурира пакет, промени дозволе или опозове објављивање апликација, те операције могу остати на чекању ако је пакет у употреби.

Почевши од App-V 5.0 SP2, уведена су стања на чекању . Уместо неуспеха, операције објављивања или опозива објављивања су означене као завршене при следећем поновном покретању App-V сервиса или када се поново изда команда за објављивање/опозивање објављивања. За глобално објављене пакете, ово обично захтева поновно покретање сервера или клијентског сервиса.

У непостојаним окружењима, ови задаци на чекању се можда никада неће обрадити јер се машине одбацују или поново креирају пре него што се услови испуне. Задаци на чекању се чувају у корисничком профилу (на пример, под HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\PendingTasks), и ако решење за профилисање не примени овај кључ пре пријављивања, операције ће бити остављене у неизвесности.

Зато је толико важно да основна слика буде усклађена са стварним стањем пакета: верзије, права, глобална издања. Што се мање ослањамо на статусе на чекању, искуство ће бити предвидљивије и мање ће бити изненађења са пакетима који изгледају заглављени или неочекивано нестају.

Оптимизација и конфигурација секвенцирања ради побољшања учинка објављивања

App-V укључује разне функције које утичу на то како се понашају операције објављивања и покретања апликација. Одређена подешавања током фазе секвенцирања могу направити приметне разлике у мрежним окружењима велике брзине.

Један пример је уклањање блока функција 1 (FB1) . Ако FB1 (минимални скуп датотека које се претходно преузимају за покретање апликације) није дефинисан, апликација ће покушати да се одмах покрене и преузме оно што јој је потребно у ходу. На мрежама велике брзине, ово може убрзати прво покретање, али на спорим мрежама може изазвати прекиде или чекање док се стримује додатни садржај.

Приликом креирања новог пакета помоћу секвенцера, једноставно оставите опцију „Оптимизуј пакет за споре мреже“ неозначену током корака стримовања. За постојеће пакете, можете ажурирати пакет без одабира ове оптимизације. Идеално би било да ове тестове извршите у контролисаном окружењу и увек вратите машину за секвенцирање на чист снимак након тога.

Још један аспект је управљање Side-by-Side (SxS) склоповима , као што су Visual C++ runtime средине. Није потребно поново секвенцирати пакете да би се изменили: ако су SxS зависности већ инсталиране на клијенту, MSI инсталатер који App-V може покренути током објављивања неће се покренути, штедећи време. Укључивање превише SxS склопова у пакет може покренути додатне инсталације током објављивања, што утиче на перформансе.

Употреба динамичких конфигурационих датотека (Deployment/User Configuration) такође има утицај. App-V клијент мора да анализира ове датотеке и покреће скрипте или примењује изузећа/укључења виртуелног регистра. Ако сваки пакет садржи велике конфигурације, објављивање ће бити погођено. Њихово коришћење само тамо где пружају стварну вредност и онемогућавање у пакетима којима нису потребне може значајно смањити време објављивања.

Коначно, вреди прегледати виртуелне фонтове укључене у пакете. Иако типичан пакет обично садржи не више од двадесет, сваки декларисани фонт значи додатни посао током ажурирања имплементације. Онемогућавање непотребних виртуелних фонтова путем динамичке конфигурације и уместо тога инсталирање фонтова који су заиста потребни изворно у слици помаже у скраћивању времена имплементације са великим бројем корисника.

Општа оптимизација перформанси у виртуелним машинама

Поред App-V, постоји низ уобичајених пракси за побољшање перформанси било које виртуелне машине , било да је у десктоп, лабораторијском или производном окружењу.

Први корак је осигурати да су проширења за виртуелизацију хардвера, као што су Intel VT-x или AMD-V , омогућена у BIOS-у/UEFI-ју хоста. Без њих, хипервизор ће морати да емулира више операција у софтверу, а перформансе ће се значајно смањити.

Такође је препоручљиво бирати виртуелне дискове фиксне величине уместо динамичких. Иако су дискови који расту како се попуњавају флексибилнији у погледу простора, они имају тенденцију да постану фрагментиранији и нуде лошије перформансе. Ако простор на хосту није проблем, вреди резервисати максималну величину виртуелног диска од самог почетка.

Локација складиштења је још један критичан фактор. Кад год је то могуће, најбоље је хостовати виртуелне машине на брзим SSD дисковима, а не на механичким чврстим дисковима или спорим екстерним дисковима. Разлика у перформансама у времену покретања система, времену покретања апликација и приступу подацима је веома приметна.

Не заборавите да инсталирате алате за интеграцију хипервизора (Guest Additions, VMware Tools, итд.) на гостујуће системе. Они додају оптимизоване драјвере за видео, мрежу, миш и складиштење и омогућавају много глаткији рад него са генеричким драјверима оперативног система.

Коначно, препоручљиво је доделити довољно RAM меморије и CPU језгара свакој виртуелној машини, имајући у виду да свака виртуелна машина покреће комплетан оперативни систем. За Windows 7/10/11 системе или тренутне Linux дистрибуције, 2 GB је веома мали минимум; у пракси, додељивање више меморије значајно побољшава перформансе. Исто важи и за CPU језгра: ако хост има много језгара, њихова мудра расподела међу активним виртуелним машинама ће направити разлику.

Физички сервери наспрам виртуелизованих окружења: када одабрати сваку опцију

Приликом имплементације услуга, увек се поставља питање да ли је боље одлучити се за виртуелне машине или наменске физичке сервере . Не постоји јединствен одговор: то зависи од оптерећења, критичности латенције и циљева трошкова и флексибилности.

Физички (голи метал) сервери нуде максималне перформансе без оптерећења хипервизора. Они су преферирани избор за трансакционе базе података веома високих перформанси, радна оптерећења која захтевају много графичких процесора (вештачка интелигенција, 3Д рендеровање, напредни CAD) или услуге у реалном времену (игре, стримовање са великим бројем кодираних садржаја) где је свака милисекунда важна.

Виртуелне машине, с друге стране, блистају у веома флексибилним и скалабилним окружењима . Веб сервиси, микросервиси и контејнери , окружења за развој и тестирање, виртуелне радне површине и многе пословне апликације одлично функционишу у виртуелизованим окружењима, омогућавајући снимке података, миграције уживо, брзо обезбеђивање и централизовано управљање ресурсима.

Са становишта лиценцирања и трошкова, виртуелизована окружења могу бити скупља ако се користе комерцијални хипервизори са лиценцама по процесору или по сокету, али штеде на хардверу, простору и потрошњи енергије. С друге стране, наменски физички сервер може бити јефтинији за лиценцирање, али мање ефикасан у коришћењу ресурса ако хостује само неколико апликација.

У пракси, многе организације се одлучују за хибридни приступ : физички сервери за најкритичнија и на перформансе осетљива радна оптерећења и кластер за виртуелизацију за остатак услуга, укључујући платформе за објављивање апликација и VDI.

Тестови оптерећења и метрике за процену учинка

Да бисте доносили информисане одлуке, сама интуиција није довољна: потребно је мерити. Тестови оптерећења процесора, RAM меморије, диска и мреже вам омогућавају да упоредите виртуелизована окружења са физичким серверима и потврдите да ли је пад перформанси прихватљив за одређену апликацију.

Алати попут sysbench-а помажу у мерењу рачунарског капацитета процесора (на пример, израчунавањем простих бројева до одређене границе), док вам услужни програми попут memtester-а или stress-ng-а омогућавају да процените латенцију меморије и пропусни опсег под различитим условима оптерећења.

За складиштење података, специјализовани алати попут fio су де факто стандард за мерење IOPS-а, пропусног опсега и латенције са различитим обрасцима приступа (секвенцијално читање/писање, насумично читање/писање и комбинације оба). Ови алати вам омогућавају да квантификујете утицај слоја виртуелизације и типа коришћеног диска.

На нивоу мреже, услужни програми као што су iperf3, netperf и ping вам омогућавају да измерите максимални пропусни опсег, просечну латенцију и подрхтавање између физичких хостова, виртуелних машина и удаљених клијената. Ови подаци су посебно релевантни у сценаријима који укључују објављивање графичких апликација или удаљених радних површина са високим захтевима за интеракцију.

Комбиновање ових метрика са искуством пилотског програма у стварном свету омогућава прилагођавања дизајна: од надоградње RAM-а или CPU-а на одређене виртуелне машине, до промене локација дискова, модификовања максималне величине истовремених App-V публикација или одлучивања да одређена база података треба да се покреће на физичком хосту.

У светлу горе наведеног, добро осмишљена виртуелизација апликација и инфраструктуре може понудити веома јаку равнотежу између перформанси, флексибилности и трошкова . Коришћење технологија као што су App-V, UE-V, KVM или комерцијални хипервизори, пажљив избор између физичких сервера и виртуелних машина на основу оптерећења и фино подешавање критичних параметара објављивања и корисничког профила омогућава запосленима да уживају у брзим, доступним апликацијама свуда, а да основна сложеност не постане уско грло пословања.