Alamvees esinevad probleemid VDI-le üleminekul: mida ette testida, et see ei oleks valus

Olete kunagi mõelnud, mida skanner teeb VDI jaama kaudu? Alguses kõik näeb välja hästi: see edastatakse nagu tavaline USB-seade ja on „läbipaistvalt” nähtav virtuaalmasinast. Siis annab kasutaja käskluse skaneerimiseks ja kõik läheb pekki. Parimal juhul skanneri draiver, halvemal juhul pärast paari minuti jooksul skanneri tarkvara, seejärel võivad mõjutada ka teisi klastrite kasutajaid. Miks? Sest et viie megabaidise kompressitud pildi saamiseks tuleb USB 2.0 kaudu edastada kaks kuni kolm korda rohkem andmeid. Busside läbilaskevõime on 480 Mbit/s.

Seega tuleb testida kolme asja: UX, periferia ja turvalisus - kindlasti. Testimise viisil on erinevusi. Saate agente installida lokaalselt, igasse virtuaalsesse tööjaama. See on suhteliselt odav, kuid ei näita kanali koormust ja ei arvesta protsessori koormust täiesti õigesti. Teine variant on korraldada vajalik arv roboteid-emulaatoreid teises kohas ja hakata neid tõelistele töökohtadele nagu päris kasutajad ühendama. Lisandub koormus ekraanivideo edastamise protokollist (täpsemalt muudetud pikslitest), võrgu paketide analüüs ja edastamine, koormus kanalis on arusaadav. Kanalit kontrollitakse üldiselt väga harva.

UX on erinevate tegevuste täitmise kiirus lõppkasutaja poolt. On olemas testipakette, mis koormavad installatsiooni sadade kasutajatega ja teevad nende jaoks tüüpilisi tegevusi: käivitavad kontoritarkvara, loevad PDF-e, sirvivad, harva vaatavad töökeskkonnas pornot ja nii edasi.

Suhteliselt hea näide, miks sellised testid on eelnevalt olulised, tuli viimases installatsioonis. Seal tuhat kasutajat kolib VDI-sse, neil on kontor, brauser ja SAP. IT-osakond ettevõttes on arenenud, seega on enne juurutusi koormustesti kultuur. Minu kogemuse kohaselt tuleb tellijat selliseks veenda, kuna kulud on suured, kuid kasu ei ole alati ilmne. Kas on olemas kalkulatsioone, kus võib eksida? Tegelikult toovad sellised testid esile kohti, mida arvati, kuid ei saanud kontrollida.

Installatsioon

Kuus serverit, konfiguratsioon on järgmine:

Kliendi andmete keskusesse ei olnud meil ligipääsu, seda pakuti juba teenusena. Kuid me teame, et seal on all-flash. Milline all-flash, me ei tea, kuid jaotused on 10 TB. VDI — VMware vastavalt kliendi soovile, kuna IT-meeskond tunneb seda juba hästi ning kõik sobitub orgaaniliselt terviklikuks infrastruktuuriks. VMware paneb tõeliselt

Käivitame testid, sest IT-meeskond ei luba peaaegu midagi tootmisse ilma testideta. VDI ei ole asi, mida saab käivitada ja siis lihtsalt vastu võtta. Kasutajad laaditakse järk-järgult ja probleemidega võib kokku puutuda kuue kuu pärast. Mida keegi ei soovi, loomulikult.

450

Vaadates, kuidas serverid ja andmete keskus käituvad. Kas VDI suudab luua vajaliku arvu virtuaalseid töökohti jne. Kuna klient ei valinud hüperkonvergentsi teed ja võttis flash-andmete keskuse, pidi ka õigete mõõtmete kontrollimine toimuma.

Kui midagi kuskil pidurdab, tuleb muuta VDI-farmi seadeid, sealhulgas ressursside jaotust erinevate kasutajate vahel.

Perifeeria

Perifeeriaga on tavaliselt kolm olukorda:

• Klient ütleb lihtsalt, et me ei ühenda midagi (noh, peale peakomplektide, need tavaliselt ilmuvad
• Teine lähenemine — võtame ja projektis VDI rakendame muutused perifeerias: kasutame meid ja klienti teste ja toetatud seadmeid. See juhtum on mõistlikel põhjustel haruldane.
• Kolmas lähenemine — kasutame olemasolevat riistvara.

Tead probleemist skanneritega: on vaja paigaldada vahepealne tarkvara töökohale (õhuke klient), mis saab USB voogu, tihendab pildi ja saadab selle VDI-sse. Erinevate eripärade tõttu ei ole see alati võimalik: kui Win-klientide (kodukompuutrite ja õhukeste klientide) puhul on kõik hästi, siis *nix-i kogumite jaoks toetab VDI tavaliselt mõnda konkreetset distributsiooni ja algavad keerulised protsessid, nagu ka Mac-klientide puhul. Mulle meenub, et vähe inimesi on ühendanud kohalikke printereid Linuxi installatsioonidega nii, et need töötaksid veaotsingufaasil ilma pidevate kõneta toele. Aga see on juba edasiminek, paar aastat tagasi töötas see isegi halvasti.

Videokonverentsi süsteem — kõik kliendid tahavad paratamatult, et see toimiks ja toimiks hästi. Kui serverit on õigesti projekteeritud, töötab see hästi, kui valesti — satume olukorda, kus meil on audio konverentsi ajal kanali koormus tõusmas, pluss lisaks sellele tekib probleem, et pilt kuvatakse halvasti (full HD ei ole, nägu 9–16 pikslit). Tekib väga suur täiendav viivitus, kui ilmneb ring, mis ulatub kliendist VDI tööjaama, VKS serveri kaudu teise VDI ja teise kliendi juurde. Õige on otse kliendist VKS serverisse ühendada, mis nõuab veel ühe täiendava komponendi paigaldamist.

USB võtmed — nendega ei ole üldse probleeme, nutikaardid ja sarnased asjad, kõik töötab otse karbist. Probleemid võivad tekkida kui skannerite, etikettide printerite, masinate (jah, ka sellised on olnud), kassadega. Aga kõik on lahendatav. Mõningate nüanssidega ja mitte ilma üllatusteta, kuid lõpuks siiski lahendatav.

Kui kasutaja vaatab YouTube'i VDI jaamalt — on see kõige halvem olukord nii koormuse kui ka kanali jaoks. Enamik lahendusi pakub HTML5 videote suunamist. Tihendatud fail edastatakse kliendile, seal seda kuvatakse. Või edastatakse kliendile link sirgest brauseri ja videohostingu vahel (see on harvem).

Turvalisus

Turvalisus esineb tavaliselt komponentide ja kliendiseadmete ühenduskohtades. Ühendustes sama ökosüsteemi sees peaks kõik tööle hästi, aga praktikas juhtub see 90% juhtudest ja midagi tuleb ikkagi täiendada. Viimastel aastatel on osutunud väga mugavaks ka veel üks VMware ost – nad omandasid MDM-öko süsteemi seadmete haldamiseks ettevõtte sees. VMwarel on hiljuti huvitavad võrgu tasakaalustajad (endine Avi Networks), mis võimaldavad lahendada voogude jaotamise küsimuse näiteks aasta pärast VDI üleandmist. Veel üks puhtalt VMware’i omadus on head filiaalide optimeerimist, mille nad said värske ostuga, kui nad omandasid ettevõtte VeloCloud, mis teeb SD-WAN-i filiaalide võrkude jaoks.

Lõppkasutaja vaatenurgast on arhitektuur ja teenusepakkuja peaaegu märkamatud. Üldiselt on oluline, et igasuguste seadmete jaoks on saadaval klient, millega saab ühendust luua tahvelarvutist, Mac'ist või Windows'i õhukesest kliendist. Varem olid isegi kliendid televiisoritele, aga praegu neid enam, õnneks, pole.

VDI-installatsioonide omadus tänasel päeval on see, et lõppkasutajal kodus lihtsalt pole arvutit. Tihti on olemas nõrk Android-tahvelarvuti (mõnikord isegi hiire või klaviatuuriga) või võib isegi hästi minna ja saada Windows XP arvuti. Mis, nagu võite arvata, ei ole tükk aega uuendatud. Ja seda ei uuendata kunagi. Või on kasutusel väga nõrgad masinad, kuhu klienti ei installita, rakendused ei toimi, kasutaja ei saa töötada. Õnneks sobivad isegi väga nõrgad seadmed (kui mitte alati mugavalt, siis siiski), ja see on suur pluss VDI-le. Mis puutub turvalisusesse, siis tuleb testida klientide süsteemide kompromiteeritust. See juhtub väga sageli.

Venemaa Tarbijakaitseameti soovituste valguses ettevõtete töö korraldamiseks COVID-19 riski tingimustes on kontoris oma töökohtadele juurde pääsemine väga aktuaalne. Tundub, et see lugu jääb kauaks ja jah, kui olete mõelnud VDI-le, siis tasub alustada testimist. See tuleb kasuks. Soovitused on olemas siin, selgitused siit. Oluline on, et VDI abil on võimalik ka ruume ümber korraldada vastavalt nõuetele. Regulatoorselt kehtestatakse teatud sotsiaalset distantseerimist käsitlevad normid. Näiteks ei tohi 50 m² suuruses kontoris viibida rohkem kui viit töötajat.

Kui teil on VDI kohta küsimusi, mis ei kuulu kommentaaride alla, siit leiate minu e-posti: SSkryl@croc.ru.

Allikas: habr.com