Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas
Gondolkozott már azon, hogy mit csinál egy szkenner a VDI állomással? Elsőre minden jónak tűnik: úgy van továbbítva, mint egy normál USB-eszköz, és „átláthatóan” látható a virtuális gépről. Ezután a felhasználó parancsot ad a vizsgálatra, és minden a pokolba megy. A legjobb esetben - a lapolvasó illesztőprogramja, rosszabb esetben - néhány perc alatt a szkenner szoftvere, majd a fürt többi felhasználóját érintheti. Miért? Ugyanis ahhoz, hogy öt megabájtos tömörített képet kapjunk, két-három nagyságrenddel több adatot kell küldeni az USB 2.0-n keresztül. A busz átviteli sebessége 480 Mbit/s.

Tehát három dolgot kell tesztelnie: UX, perifériák és biztonság – kötelező. Különbség van a tesztelés módjában. Az ügynököket helyileg telepítheti minden virtuális munkaállomásra. Ez viszonylag olcsó, de nem mutatja a csatorna terhelését, és nem pontosan számítja ki a processzor terhelését. A második lehetőség az, hogy a szükséges számú emulátorrobotot egy másik helyre telepítjük, és valódi felhasználókként elkezdjük összekapcsolni őket valódi munkákkal. Hozzáadódik a képernyős videó stream átviteli protokoll (pontosabban megváltozott pixel) terhelése, a hálózati csomagok elemzése és küldése, és egyértelművé válik a csatorna terhelése. A csatornát általában nagyon ritkán ellenőrzik.

Az UX az a sebesség, amellyel a végfelhasználó különféle műveleteket hajt végre. Vannak tesztcsomagok, amelyek több száz felhasználóval töltik be a telepítést, és tipikus műveleteket hajtanak végre velük: irodai csomagokat indítanak el, PDF-eket olvasnak, böngésznek, munkaidőben ritkán néznek pornót stb.

Egy nagyon jó példa arra, hogy az ilyen tesztek eleve fontosak, a legújabb telepítés volt. Ott ezer felhasználó költözik a VDI-be, van iroda, böngésző és SAP. A cég informatikai részlege fejlett, így az implementációk előtti terheléses tesztelés kultúrája létezik. Tapasztalataim szerint általában erre kell rávenni a vásárlót, mert a költségek magasak és a haszon nem mindig nyilvánvaló. Vannak olyan számítások, ahol hibázhat? Valójában az ilyen tesztek olyan helyeket tárnak fel, ahol gondolták, de nem tudták ellenőrizni.

telepítés

Hat szerver, a konfiguráció a következő:

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Nem fértünk hozzá a vevő tárolórendszeréhez, sőt, mint szolgáltatást nyújtották. De tudjuk, hogy létezik minden-flash. Nem tudjuk, melyik all-flash, de a partíciók 10 TB-osak. VDI - VMware az ügyfél választása szerint, mivel az informatikai csapat már ismeri a stacket, és minden szervesen kiegészítve egy teljes infrastruktúrát alkot. A VMware nagyon „kiakadt” az ökoszisztémáján, de ha van elegendő beszerzési költségvetés, akkor évekig nem lesz gond. De ez gyakran nagyon nagy „ha”. Jó árengedményünk van, és a vásárló tud róla.

Elkezdjük a teszteket, mert az IT csapat szinte semmit nem ad termelésbe tesztek nélkül. A VDI-t nem lehet elindítani, majd elfogadni. A felhasználók fokozatosan töltődnek be, és hat hónap elteltével lehetséges, hogy problémák merülnek fel. Amit persze senki sem akar.

450 „felhasználó” a tesztben, a terhelés helyileg generálódik. A Robo-userek egyszerre különböző műveleteket hajtanak végre, az egyes műveletek idejét több órányi munka során mérjük:

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Lássuk, hogyan fognak viselkedni a szerverek és a tárolórendszerek. A VDI képes lesz-e létrehozni a szükséges számú virtuális asztalt stb. Mivel a megrendelő nem a hiperkonvergencia útját járta, hanem all-flash tárolórendszert választott, ezért a méretezés helyességét is ellenőrizni kellett.

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Buktatók VDI-re váltáskor: mit kell előre tesztelni, hogy ne legyen elviselhetetlenül fájdalmas

Valójában, ha valahol lelassul valami, meg kell változtatni a VDI-farm beállításait, különösen az erőforrások elosztását a különböző kategóriákba tartozó felhasználók között.

Periféria

Általában három helyzet van a perifériákkal:

  • Az ügyfél egyszerűen azt mondja, hogy nem csatlakoztatunk semmit (na jó, a headsetet leszámítva általában „dobozból” láthatóak). Az elmúlt körülbelül öt évben nagyon-nagyon ritkán láttam olyan headsetet, amelyet nem vett fel maguktól, és amelyeket a VMware nem vett fel.
  • A második megközelítés a perifériák átvétele és cseréje a VDI bevezetési projekt részeként: azt vesszük, amit mi és az ügyfél teszteltünk és támogattunk. Az eset érthetően ritka.
  • A harmadik megközelítés a meglévő hardver átdobása.

A lapolvasók problémájáról már tudtok: köztes szoftvert kell telepíteni egy munkaállomásra (vékony kliens), amely fogadja az USB adatfolyamot, tömöríti a képet és elküldi a VDI-re. Számos funkció miatt ez nem mindig lehetséges: ha Win klienseken (otthoni számítógépeken és vékonyklienseken) minden rendben van, akkor a *nix buildeknél a VDI szállítója általában egy adott disztribúciót támogat, és elkezdődnek a táncok a tamburával, mivel Mac klienseken. Emlékeim szerint kevesen csatlakoztattak helyi nyomtatókat Linux-telepítésekből, hogy azok a hibakeresési szakaszban működjenek anélkül, hogy állandóan hívnák a támogatást. De ez már jó, régen - még csak dolgozni is.

Videokonferencia – előbb-utóbb minden ügyfél azt akarja, hogy működjön és jól működjön. Ha a farm jól van megtervezve, akkor jól működik, ha rosszul, akkor olyan helyzetet kapunk, hogy egy audiokonferencia során megnő a csatorna terhelése, plusz ezen kívül az a probléma, hogy rosszul jelenik meg a kép (nincs teljes HD, 9–16 pixeles felület). Nagyon erős járulékos késleltetés lép fel, amikor hurok jelenik meg a kliens, a VDI munkaállomás, a videokonferencia szerver és onnan a második VDI és a második kliens között. Helyes a kliensről közvetlenül csatlakozni a videokonferencia szerverhez, amihez egy másik kiegészítő komponens telepítése szükséges.

USB kulcsok - semmi probléma velük, intelligens kártyák és hasonlók, minden működik a dobozból. Nehézségek adódhatnak vonalkód-leolvasókkal, címkenyomtatókkal, gépekkel (igen, volt ilyen), pénztárgépekkel. De minden megoldódik. Nüanszokkal és nem meglepetések nélkül, de végül megoldva.

Ha a felhasználó egy VDI-állomásról nézi a YouTube-ot, ez a legrosszabb helyzet mind a terhelés, mind a csatorna szempontjából. A legtöbb megoldás HTML5-videó-átirányítást kínál. A tömörített fájl átkerül a kliensbe, ahol megjelenik. Vagy az ügyfél kap egy linket a közvetlen kommunikációhoz a böngésző és a videotárhely között (ez ritkábban fordul elő).

biztonság

A biztonság jellemzően az összetevő-interfészeken és a kliens eszközökön történik. Egy ökoszisztéma csomópontjainál, szavakkal, mindennek jól kell működnie. A gyakorlatban ez az esetek 90%-ában megtörténik, és valamit még be kell fejezni. Az elmúlt években a Vmvara újabb vásárlása nagyon kényelmesnek bizonyult - hozzáadták az MDM-et az ökoszisztémához, hogy a vállalaton belül kezeljék az eszközöket. A virtuális gépek a közelmúltban szereztek be érdekes hálózati kiegyenlítőket (korábban Avi Networks), amelyek lehetővé teszik például a VDI befejezése után egy évvel az áramláselosztás kérdésének lezárását. Egy másik tisztán első féltől származó szolgáltatás a fiókok jó optimalizálása, köszönhetően annak, hogy friss vásárlást végeztek, amikor felvették a VeloCloud céget, amely SD-WAN-t gyárt fiókhálózatokhoz.

A végfelhasználó szemszögéből az architektúra és az eladó szinte láthatatlan. Globálisan fontos, hogy minden eszközhöz legyen kliens; csatlakozhat táblagépről, Macről vagy Windows vékonykliensről. Még a televízióknak is voltak kliensei, de most szerencsére már nincsenek meg.

A VDI telepítések sajátossága most, hogy a végfelhasználónak egyszerűen nincs otthon számítógépe. Gyakran gyenge Android táblagéped van (néha még egérrel vagy billentyűzettel is), de még az is lehet, hogy szerencséd van és kapsz egy Win XP-t futtató számítógépet. Ami, ahogy sejthető, egy ideje nem frissült. És soha többé nem lesz frissítve. Vagy nagyon gyenge gépek, ahol nincs telepítve a kliens, nem működnek az alkalmazások, a felhasználó nem tud dolgozni. Szerencsére a nagyon gyenge eszközök is megfelelőek (nem mindig kényelmesek, de megfelelőek), és ez a VDI nagy előnye. Nos, ami a biztonságot illeti, tesztelni kell a kliensrendszerek kompromisszumát. Ez elég gyakran megtörténik.

A Rospotrebnadzor COVID-19 veszélynek kitett vállalkozások munkájának megszervezésére vonatkozó ajánlásai fényében nagyon fontos, hogy az irodában kapcsolódjon a munkahelyéhez. Úgy tűnik, ez a sztori sokáig fog tartani, és igen, ha a VDI-n gondolkoztál, akkor elkezdheted a tesztelést. Jól fog jönni. Az ajánlások a következők itt, pontosítások itt. Fontos, hogy a VDI használható terek utólagos felszerelésére is, hogy megfeleljenek a megfelelőségi követelményeknek. A szabályozó bizonyos távolságtartási szabványokat vezet be. Például egy 50 négyzetméteres irodában. m nem lehet több mint öt alkalmazott.

Nos, ha kérdései vannak a VDI-vel kapcsolatban, amelyek nem kommentálhatók, itt van az e-mailem: [e-mail védett].

Forrás: will.com

Hozzászólás