Gondoltál már arra, hogy mit csinál a szkenner egy VDI állomással? Eleinte minden jól néz ki: simán USB eszközként csatlakozik, és "átláthatóan" látható a virtuális gépről. Aztán a felhasználó parancsot ad a szkennelésre, és minden a francba megy. Legjobb esetben – a szkenner drivere, rosszabb esetben – néhány perc elteltével a szkenner szoftvere, ami aztán más felhasználókat is érinthet a klaszterben. Miért? Mert ahhoz, hogy egy öt megabájtos tömörített képet kapjunk, USB 2.0-n keresztül két-három nagyságrenddel több adatot kell átküldeni. A busz sávszélessége 480 Mbit/s.
Tehát három dolgot kell tesztelni: UX, perifériák és biztonság – kötelező. Van különbség a tesztelés módja között. Lokálisan telepítheted az ügynököket minden virtuális munkagépre. Ez viszonylag költséghatékony, de nem mutatja a sávterhelést, és nem számolja teljesen pontosan a processzorterhelést. A másik lehetőség, hogy egy másik helyen a szükséges számú robot-emulátort telepítesz, és elkezded őket valódi munkaterületekhez csatlakoztatni, mint igazi felhasználók. További terhelést ad hozzá a képernyő videófolyama (pontosabban, a megváltozott pixelek), a hálózati csomagok elemzése és küldése, érthető lesz a sávterhelés. A sávszélességet egyáltalán nagyon ritkán ellenőrzik.
Az UX az a különböző tevékenységek végrehajtásának sebessége a végfelhasználó által. Vannak tesztcsomagok, amelyek százakra terhelik az installációt és végrehajtják a tipikus tevékenységeiket: indítanak irodai csomagokat, olvasnak PDF-ket, böngésznek, ritkán néznek pornót munkaidőben, stb.
Egy elég jó példa arra, hogy miért fontosak ezek a tesztek előre, a legutolsó installációban volt. Ott ezer felhasználó költözik a VDI-ba, nekik irodájuk, böngészőjük és SAP-juk van. A vállalat IT részlege fejlett, így van terheléses tesztelési kultúra a bevezetések előtt. Tapasztalatom szerint általában meggyőzni kell az ügyfelet egy ilyen dologról, mert magasak a költségek, és a haszon nem mindig nyilvánvaló. Vannak számítások, ahol lehet tévedni? A valóságban – ezek a tesztek feltárják azokat a helyeket, amelyeket gondoltak, de nem tudtak ellenőrizni.
Telepítés
Hat szerver, a konfiguráció a következő:
A megrendelő tárolójához nem volt hozzáférésünk, azt már szolgáltatásként nyújtották, gyakorlatilag. De tudjuk, hogy teljes flash. Hogy pontosan milyen flash, azt nem tudjuk, de 10 TB-os szekciók vannak. A VDI a megrendelő döntése szerint VMware, mivel az IT csapat már ismeri a stacket, és minden elég szervesen egészíti ki az infrastruktúrát. A VMware nagyon „ráhúz” a saját ökoszisztémájára, de ha van elegendő költségvetés vásárlásra — évekig problémamentes lehet. De ez gyakran egy nagyon nagy „ha”. Jó kedvezményünk van, és a megrendelő tud erről.
Elkezdjük a teszteket, mert az IT csapat szinte semmit sem enged a termelésbe tesztek nélkül. A VDI nem az a dolog, amit elindíthatunk, majd később elfogadhatunk. A felhasználók fokozatosan csatlakoznak, és hat hónap múlva problémákba is ütközhetünk. Amit természetesen senki sem akar.
450 „felhasználó” a teszten, a terhelést helyben generáljuk. A robotfelhasználók egyszerre végeznek különböző műveleteket, az egyes műveletek idejét néhány órás működés során mérjük:
Nézzük, hogyan viselkednek a kiszolgálók, a tároló. Képes lesz a VDI létrehozni a szükséges számú virtuális munkahelyet, és így tovább. Mivel a megrendelő nem az hiper-konvergencia irányába ment, hanem flash tárolót választott, a méretezés helyességét is be kellett ellenőrizni.
Ha valahol megakad a rendszer — módosítani kell 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ájú felhasználók között.
Periféria
A perifériákkal általában három helyzet van:
- A megrendelő egyszerűen azt mondja, hogy semmit nem csatlakoztatunk (hát, a fejhallgatók kivételével, azok általában „do it yourself” alapon működnek). Az utóbbi körülbelül öt évben nagyon ritkán látok olyan fejhallgatókat, amelyek nem csatlakoztak volna maguktól, és amelyeket ne fogott volna fel a VMware.
- A második megközelítés — a VDI implementálása keretein belül cseréljük a perifériákat: tesztelt eszközöket választunk, amelyeket a megrendelő is támogatott. Ez a helyzet érthető okok miatt ritka.
- A harmadik megközelítés — az existing hardware-t használjuk.
A problémáról a szkennerekkel már tudtok: köztes szoftvert kell telepíteni a munkaállomásra (vékony kliens), amely USB adatfolyamot fogad, összenyomja a képet, és elküldi a VDI-nek. Különböző okok miatt ez nem mindig lehetséges: míg a Windows kliensek (otthoni számítógépek és vékony kliensek) esetében minden rendben van, a *nix-kiadások esetében általában a VDI szállítója valamilyen konkrét disztribúciót támogat, amely miatt sokszor bonyodalmak adódnak, akárcsak a Mac klienseknél. A tapasztalatom szerint nagyon kevesen csatlakoztattak helyi nyomtatókat Linux telepítésekről úgy, hogy azok a hibaelhárítási fázisban folyamatos támogatás hívások nélkül működjenek. De ez már jó, mert nemrég még csak annyira működtek, hogy működjenek.
A videokonferencia minden ügyfél előbb-utóbb szeretné, ha ez jól működne. Ha a farmot jól tervezték meg, akkor ez jól működik, ellenkező esetben olyan helyzetet kapunk, amikor az audiokonferencia során nő a sávszélesség terhelése, ráadásul a kép minősége is gyenge (full HD nélkül, arc 9–16 pixeles méretben). Nagyon erős késlekedés lép fel, amikor kialakul egy hurkok a kliens, a VDI munkaállomás, a VKS szerver, onnan a második VDI és a második kliens között. Helyesen kell csatlakozni közvetlenül a kliensről a VKS szerverhez, ami megköveteli egy újabb komponens telepítését.
USB kulcsokkal általában nincsenek problémák, a smart kártyák és hasonlóak is működnek dobozból kivéve. Nehézségek merülhetnek fel vonalkód-olvasók, címkenyomtatók, gépek (igen, volt már ilyen), pénztárgépek esetében. De mindez megoldható. Előfordulhatnak nehézségek és meglepetések, de végül is megoldásra találunk.
Amikor a felhasználó YouTube-ot néz egy VDI állomásról, ez a legrosszabb helyzet, mind terhelés, mind a sávszélesség szempontjából. A legtöbb megoldás HTML5 videó átirányítást javasol. A tömörített fájlt elküldik a kliensnek, ahol megjelenítik. Vagy a kliensnek egy hivatkozást adnak meg, ami közvetlen kapcsolatot teremt a böngésző és a videómegosztó között (ez ritkább).
Biztonság
A biztonság általában a komponens-összekapcsolások és az ügyfél eszközök helyein szikrázik. Az ökoszisztéma egyes kapcsolódási pontjain elméletben minden jól működik. A valóságban azonban ez a 90%-os esetekben igaz, és mindig van valami, amit még be kell fejezni. Az utóbbi években az egyik hasznos vásárlás a VMware számára egy MDM megoldás lett, amely lehetővé teszi a vállalati eszközök kezelését. A VMware mostanában érdekes hálózati terheléselosztókat kínál (korábbi Avi Networks), amelyek lehetővé teszik a forgalom elosztásának megoldását például egy évvel a VDI átadása után. Egy másik kifejezetten VMware jellegzetesség a fiókok jó optimalizálása a friss vásárlásuknak köszönhetően, amikor a VeloCloud céget szerezték meg, amely SD-WAN megoldásokat kínál a fiókhálózatok számára.
A végfelhasználó szempontjából az architektúra és a szállító szinte észrevétlen. Globálisan fontos, hogy van kliens bármilyen eszközre, táblagépről, Mac-ről, Windows vékony kliensről is csatlakozhatunk. Volt olyan kliens, amely tévékhez készült, de mostanra, szerencsére, már nincsenek.
A VDI telepítések sajátossága manapság az, hogy a végfelhasználónak otthon egyszerűen nincs számítógépe. Gyakran van egy gyenge Android táblagépe (néha egérrel vagy billentyűzettel), vagy szerencsés esetben egy Windows XP számítógépe. Amint kitalálhatja, ezt egy ideje már nem frissítették. És soha nem is fogják. Vagy nagyon gyenge gépek, ahol a kliens nem telepíthető, az alkalmazások nem működnek, a felhasználó nem tud dolgozni. Szerencsére még a nagyon gyenge eszközök is megfelelnek (nem mindig kényelmes, de elfogadható), és ezt a VDI nagy előnyének tartják. Na és a biztonságról — tesztelni kell az ügyfél rendszerek kompromittálódását. Ez elég gyakran megtörténik.
A COVID-19 kockázata alatti vállalatok munkájának megszervezésére vonatkozó Rospotrebnadzor ajánlásainak fényében a munkatársaink irodai helyeikhez való csatlakozása nagyon aktuális. Úgy tűnik, hogy ez a történet hosszú távú, és igen, ha a VDI-ről gondolkodtál — érdemes elkezdeni a tesztelést. Hasznos lesz. Az ajánlások itt találhatók , a magyarázatok . Fontos, hogy a VDI segítségével az irodák újra átalakíthatók a követelményeknek megfelelően. A szabályozó bizonyos távolságtartási normákat vezet be. Például egy 50 m²-es irodában legfeljebb öt dolgozó tartózkodhat.
Ha kérdései vannak a VDI-ről, amelyeket nem kommentálna — itt az e-mail címem: SSkryl@croc.ru.
Forrás: habr.com
