VDI-le minevarud: mida testida ette, et vältida valusaid üllatusi

Kas olete kunagi mõelnud, mida skanner VDI-jaamas teeb? Alguses tundub kõik hea: see tuvastatakse nagu tavaline USB-seade ja on „läbipaistvalt” nähtav virtuaalmachine'ist. Siis saadab kasutaja käsu skaneerimiseks, ja kõik kukub kokku. Parimal juhul — skanneri draiver, halvemal juhul — mõne minuti pärast skanneri tarkvara, mis võib mõjutada ka teisi klastrikasutajaid. Miks? Sest viie megabaidi kokku surutud pildi saamiseks tuleb USB 2.0 kaudu edastada kaks-kolm korda rohkem andmeid. Bussi läbilaskevõime on 480 Mbit/s.

Seega tuleb testida kolme asja: kasutajakogemust, perifeeriat ja turvalisust — see on hädavajalik. Testimise viisid erinevad. Üks võimalus on paigaldada agent kohaliku seadme peale igasse virtuaalsesse tööjaama. See on suhteliselt odav, kuid ei näita kanalikoormust ja ei arvuta protsessori koormust täpselt. Teine variant on seadistada teises kohas vajalik hulk emulatorroboteid ja hakata neid ühendama reaalse tööjaamaga nagu tegelikud kasutajad. Teise võimalusena tuleb juurde koormust ekraanivideosignaali edastamise protokollilt (täpsemalt, muudetud pikslitelt), võrgupakettide analüüsilt ja edastamiselt, mis selgitab kanalikoormust. Kanalit kontrollitakse üldiselt väga harva.

Kasutajakogemus (UX) tähendab erinevate toimingute sooritamise kiirusest lõppkasutaja poolt. On olemas testipakette, mis koormavad installeerimist sadade kasutajatega ja täidavad nendele tüüpilisi tegevusi: käivitavad kontoriprogramme, loevad PDF-e, sirvivad, väga harva vaatavad pornot tööajal ja nii edasi.

Toreda on hea näide sellest, miks sellised testid on enne tähtsad, oli viimasel paigaldusel. Seal tuhat kasutajat kolib VDI-sse, neil on kontor, brauser ja SAP. Ettevõtte IT-osakond on arenenud, seega on enne rakendusi testimisstandardi kultuur. Minu kogemuse kohaselt tuleb tavaliselt tellijat selliseks mõtlema veenda, sest kulud on suured ja kasu pole alati ilmne. On ju arvutusi, kus võib eksida? Tegelikkuses paljastavad sellised testid kohad, mida arvati, kuid ei saanud kontrollida.

Paigaldamine

Kuus serverit, konfiguratsioon on järgmine:

Kliendi SAN-i juurde meil juurdepääsu ei olnud; see pakuti juba teenusena. Aga me teame, et seal on all-flash. Milline täpselt all-flash, ei tea, kuid sektsioonid on 10 TB. VDI on kliendi valitud VMware, kuna IT-meeskonnale on see juba tuttav ja kõik sulandub üsna orgaaniliselt kokku terviklikuks infrastruktuuriks. VMware tõeliselt "harjub" oma ökosüsteemiga, kuid kui eelarvest ostmiseks piisab — aastaid võib mitte muretseda. Kuid see on sageli väga suur "kui". Meil on hea allahindlus ja klient teab sellest.

Alustame teste, kuna IT-meeskond ei lase peaaegu midagi tootmisesse ilma testideta. VDI ei ole asi, mida saab lihtsalt käivitada ja siis aktsepteerida. Kasutajad laaditakse sisse järk-järgult ning probleemidega võib kokku puutuda isegi kuue kuu pärast. Mida keegi loomulikult ei soovi.

450 „kasutajat” testis, koormust genereerime kohapeal. Robootikakasutajad teevad erinevaid tegevusi samaaegselt, mõõdame iga operatsiooni aega paaritunnise töö jooksul:

Vaatele, kuidas serverid ja andmesalvestussüsteem käituvad. Kas VDI suudab luua vajaliku arvu virtuaalseid töökohti jne. Kuna tellija ei valinud hüperkonvergeeritud lahendust, vaid valis välkmäluga andmesalvestussüsteemi, tuli kontrollida ka suuruse seadistamise õigust.

Kui kuskil on viivitusi - tuleb muuta VDI-farmi seadistusi, eelkõige ressursside jaotust erinevate kategooriate kasutajate vahel.

Perifeeria

Perifeeriaga on tavaliselt kolm olukorda:

• Tellija ütleb lihtsalt, et me ei ühenda midagi (välja arvatud kõrvaklapid, need on tavaliselt "karbist välja" nähtavad). Viimased viis aastat olen väga harva näinud kõrvaklappe, mis ise ei ühenduks ja mida VMware ei haaraks.
• Teine lähenemine on see, et võtame ja projektis VDI rakendamise raames muudame periferiat: võtame meie ja tellija poolt testitud ja toetatud seadmed. Selline juhtum on arusaadavatel põhjustel haruldane.
• Kolmas lähenemine on olemasoleva riistvara üleviimine.

Teate juba skanneritega seotud probleeme: tuleb paigaldada vahepealne tarkvara tööjaama (õhuke klient), mis saab USB voogu, tihendab pildi ja saadab selle VDI-sse. Mitme teguri tõttu ei ole see alati võimalik: kui Win-klientides (koduarvutid ja õhukesed kliendid) on kõik hästi, siis *nix-kogumite puhul toetab tavaliselt VDI tarnija mõnda konkreetset distributsiooni ning hakkavad pihta tantsud nagu Mac-kliendi puhul. Minu mälestuste järgi on vähe inimesi, kes on Linuxi installatsioonidest kohalikku printerit ühendades saavutanud, et need debugimise etapis töötaksid ilma pidevate tugiteenuste kõnede tegemiseta. Kuid see on juba positiivne, mõni aeg tagasi — isegi lihtsalt selleks, et need töötaksid.

Videokonverents — kõik kliendid tahavad varem või hiljem, et see töötaks ja töötaks hästi. Kui serverifarm on õigesti projekteeritud, siis see töötab hästi; kui vale, saame olukorra, kus helikonverentsi ajal suureneb koormus kanalil, lisaks ilmneb probleem, et pilt kuvatakse halvasti (full HD puudub, nägu on 9–16 pikslit). Tekib väga suur täiendav viivitus, kui ilmneb silmus kliendi, VDI tööjaama, VKSe serveri, sealt teise VDI ja teise kliendi vahel. Õige on ühenduda otse kliendist VKSe serverisse, mis nõuab veel ühe täiendava komponenti paigaldamist.

USB-mälupulgad — nendega ei ole üldse probleeme, nutikaardid ja sarnased, kõik töötab kohe välja kastist. Raskusi esineb viipemoodulite, etikettide printerite, seadmete (jah, ka selliseid oli) ja kassadega. Kuid kõik on lahendatav. Nüanssidega ja mitte ilma üllatusteta, kuid lõpuks on see ikka võimalik.

Kui kasutaja vaatab YouTube'i VDI-teenusest, on see halvim olukord nii koormuse kui ka kanali jaoks. Enamik lahendusi pakub HTML5 video suunamist. Kompressitud fail edastatakse kliendile, kus see kuvatakse. Või antakse kliendile link otseühenduseks brauseri ja videohostingu vahel (see on harvem).

Ohutus

Turvalisus kriitiliselt puudutab komponentide liitumiskohti ja kliendiseadmeid. Ühes ökosüsteemis peaks kõik toimima hästi, kuid praktikas juhtub see 90% juhtudest ja midagi tuleb ikkagi täiendada. Viimastel aastatel on olnud eriti mugav veel üks VMware ost - nad on integreerinud MDM-i seadmete haldamiseks ettevõttes. VMware-l on hiljuti uudseid võrgu tasakaalustajaid (endine Avi Networks), mis võimaldavad jagada vooge aasta pärast VDI üleandmist, näiteks. Veel üks puhtalt VMware eripära on head filiaalide optimeerimise võimalused, tänu nende värskele ostule, kui nad soetasid ettevõtte VeloCloud, mis pakub SD-WAN-i filiaalvõrkudele.

Lõppkasutaja vaatenurgast on arhitektuur ja teenusepakkuja peaaegu nähtamatud. Globaalne tähtsus on, et igale seadmele on saadaval klient, millega saab ühendada tahvelarvutist, Mac'ist või Windows õhukesest kliendist. Üksikute klientide toeks on isegi olnud teleritele, kuid nüüdseks on need õnneks kadunud.

VDI-installatsiooni eripära on see, et lõppkasutajal ei ole kodus tavaliselt arvutit. Tihti on ainult nõrk Android-tahvelarvuti (mõnikord isegi hiire või klaviatuuriga) või võib-olla on isegi vedanud ja saadud Windows XP süsteem. Mis, nagu võite aimata, ei ole juba mõnda aega uuendatud. Ja see ei hakka kunagi uuenduma. Või on olemas väga nõrgad masinad, kus klienti ei saa paigaldada, rakendused ei tööta, kasutaja ei saa tööd teha. Õnneks sobivad isegi väga nõrgad seadmed (kuigi mitte alati mugavalt, kuid siiski sobivad), ja see on VDI suur pluss. Mis puutub aga turvalisusesse, siis tuleb testida kliendi süsteemide kompromiteerimist. See toimub piisavalt sageli.

Vastas, et Rospotrebnadzori soovituste valguses ettevõtete töö korraldamiseks COVID-19 riski tingimustes on ühendamine oma töökohtadega kontoris väga oluline. Tundub, et see olukord jääb püsima ja jah, kui mõtlesite VDI-le — võite alustada testimist. See tuleb kasuks. Soovitused leiad siit, selgitused siit. Oluline on, et VDI kaudu on võimalik ka ruume ümber korraldada nõuete täitmiseks. Regulaator kehtestab teatud distantseerimise normid. Näiteks ei tohi 50 m² kontoris viibida enam kui viiel töötajal.

Kui teil on VDI kohta küsimusi, mis ei vaja kommentaare — siin on minu e-post: SSkryl@croc.ru.

Allikas: habr.com