Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt
Har du någonsin undrat vad en skanner gör med en VDI-station? Till en början ser allt bra ut: det vidarebefordras som en vanlig USB-enhet och är "transparent" synlig från den virtuella maskinen. Sedan ger användaren ett kommando att skanna, och allt går åt helvete. I bästa fall - skannerdrivrutinen, värre - på ett par minuter skannerprogramvaran, då kan det påverka andra användare av klustret. Varför? För för att få en komprimerad bild på fem megabyte behöver du skicka två till tre storleksordningar mer data via USB 2.0. Bussgenomströmningen är 480 Mbit/s.

Så du behöver testa tre saker: UX, kringutrustning och säkerhet - ett måste. Det är skillnad på hur man testar. Du kan installera agenter lokalt på varje virtuell arbetsstation. Detta är relativt billigt, men visar inte belastningen på kanalen och beräknar inte riktigt belastningen på processorn. Det andra alternativet är att distribuera det erforderliga antalet emulatorrobotar på en annan plats och börja koppla dem till riktiga jobb som riktiga användare. Belastningen från överföringsprotokollet för skärmens videoström (mer exakt, ändrade pixlar), parsning och sändning av nätverkspaket kommer att läggas till och belastningen på kanalen blir tydlig. Kanalen kontrolleras i allmänhet mycket sällan.

UX är den hastighet med vilken slutanvändaren utför olika åtgärder. Det finns testpaket som laddar installationen med hundratals användare och gör typiska åtgärder för dem: starta kontorspaket, läsa PDF-filer, bläddra, sällan titta på porr under arbetstid och så vidare.

Ett ganska bra exempel på varför sådana tester är viktiga i förväg var i den senaste installationen. Där flyttar tusen användare till VDI, de har kontor, webbläsare och SAP. Företagets IT-avdelning är utvecklad, så det finns en kultur av belastningstester inför implementeringar. Enligt min erfarenhet måste kunden vanligtvis övertalas att göra detta, eftersom kostnaderna är höga och fördelarna inte alltid uppenbara. Finns det några beräkningar där man kan göra fel? Faktum är att sådana tester avslöjar platser där de tänkte, men inte kunde kontrollera.

installation

Sex servrar, konfigurationen är:

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Vi hade inte tillgång till kundens lagringssystem, det tillhandahölls faktiskt som en plats som en tjänst. Men vi vet att det finns all-flash. Vi vet inte vilken all-flash det är, men partitionerna är 10 TB. VDI - VMware efter kundens val, eftersom IT-teamet redan är bekant med stacken, och allt är ganska organiskt kompletterat för att bilda en komplett infrastruktur. VMware är väldigt "hooked" på sitt ekosystem, men om du har tillräckligt med inköpsbudget kanske du inte har några problem på flera år. Men detta är ofta ett väldigt stort "om". Vi har en bra rabatt, och kunden vet om det.

Vi startar tester, eftersom IT-teamet inte släpper nästan vad som helst i produktion utan tester. VDI är inget du kan starta och sedan acceptera. Användare laddas gradvis, och det är fullt möjligt att stöta på problem efter sex månader. Vilket naturligtvis ingen vill ha.

450 "användare" i testet genereras belastningen lokalt. Robo-användare utför olika åtgärder samtidigt, vi mäter tiden för varje operation under flera timmars arbete:

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Låt oss se hur servrarna och lagringssystemen kommer att bete sig. Kommer VDI att kunna skapa det antal virtuella skrivbord som krävs och så vidare. Eftersom kunden inte följde hyperkonvergensens väg, utan tog ett all-flash-lagringssystem, var det nödvändigt att kontrollera storleken på korrektheten också.

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Fallgropar när du byter till VDI: vad ska man testa i förväg för att inte vara oerhört smärtsamt

Faktiskt, om något saktar ner någonstans, måste du ändra inställningarna för VDI-farmen, särskilt fördelningen av resurser mellan användare av olika kategorier.

Periferi

Det finns vanligtvis tre situationer med kringutrustning:

  • Kunden säger helt enkelt att vi inte ansluter någonting (nåja, förutom headset är de vanligtvis synliga "out of the box"). Under de senaste fem åren eller så har jag väldigt, väldigt sällan sett headset som inte har plockats upp på egen hand och som inte har plockats upp av VMware.
  • Det andra tillvägagångssättet är att ta och ändra kringutrustningen som en del av VDI-implementeringsprojektet: vi tar vad vi och kunden har testat och stöttat. Fallet är förståeligt sällsynt.
  • Det tredje tillvägagångssättet är att kasta igenom den befintliga hårdvaran.

Du vet redan om problemet med skannrar: du måste installera mellanprogram på en arbetsstation (tunn klient), som tar emot en USB-ström, komprimerar bilden och skickar den till VDI. På grund av ett antal funktioner är detta inte alltid möjligt: ​​om allt är bra på Win-klienter (hemdatorer och tunna klienter), så för *nix-byggen stöder VDI-leverantören vanligtvis en specifik distribution och danserna med en tamburin börjar, eftersom på Mac-klienter. I mitt minne var det få som kopplade ihop lokala skrivare från Linux-installationer så att de skulle fungera i felsökningsstadiet utan ständiga anrop till support. Men det här är redan bra, för ett tag sedan - till och med bara för att jobba.

Videokonferenser – alla kunder vill förr eller senare att det ska fungera och fungera bra. Om gården är rätt utformad så fungerar den bra, om den är felaktig får vi en situation där under en ljudkonferens belastningen på kanalen ökar, plus att det utöver detta är problem med att bilden visas dåligt (ingen full HD, ett ansikte på 9–16 pixlar). En mycket kraftig ytterligare fördröjning uppstår när en loop uppstår mellan klienten, VDI-arbetsstationen, videokonferensservern och därifrån den andra VDI:n och den andra klienten. Det är korrekt att ansluta direkt från klienten till videokonferensservern, vilket kräver installation av ytterligare en komponent.

USB-nycklar - det är inga problem med dem alls, smartkort och liknande, allt fungerar ur kartongen. Det kan uppstå svårigheter med streckkodsläsare, etikettskrivare, maskiner (ja, det fanns något sådant) och kassaapparater. Men allt håller på att lösas. Med nyanser och inte utan överraskningar, men i slutändan löst.

När en användare tittar på YouTube från en VDI-station är detta den värsta situationen för både belastningen och kanalen. De flesta lösningar erbjuder HTML5-videoomdirigering. Den komprimerade filen överförs till klienten, där den visas. Eller så skickas klienten en länk för direkt kommunikation mellan webbläsaren och videohosting (detta är mindre vanligt).

Безопасность

Säkerhet sker vanligtvis vid komponentgränssnitt och på klientenheter. Vid knutpunkterna i ett ekosystem ska med ord allt fungera bra. I praktiken sker detta i 90 % av fallen, och något måste fortfarande slutföras. Under de senaste åren har ytterligare ett köp av Vmvara visat sig vara mycket bekvämt - de lade till MDM till ekosystemet för att hantera enheter inom företaget. VM:er har nyligen skaffat intressanta nätverksbalanserare (tidigare Avi Networks), som gör att du kan avsluta frågan om flödesdistribution ett år efter färdigställandet av VDI, till exempel. En annan rent förstapartsfunktion är bra optimering av filialer tack vare deras fräscha inköp när de tog sig an företaget VeloCloud som gör SD-WAN för filialnät.

Ur slutanvändarens synvinkel är arkitekturen och leverantören nästan osynliga. Det som är globalt viktigt är att det finns en klient för vilken enhet som helst; du kan ansluta från en surfplatta, Mac eller Windows tunn klient. Det fanns till och med kunder för tv-apparater, men nu finns de som tur är inte längre där.

Det speciella med VDI-installationer nu är att slutanvändaren helt enkelt inte har en dator hemma. Ofta har du en svag Android-surfplatta (ibland även med mus eller tangentbord), eller så kanske du till och med har tur och får en dator som kör Win XP. Vilket, som ni kan gissa, inte har uppdaterats på ett tag. Och den kommer aldrig att uppdateras igen. Eller mycket svaga maskiner, där klienten inte är installerad, applikationer inte fungerar, användaren kan inte arbeta. Lyckligtvis är även mycket svaga enheter lämpliga (inte alltid bekväma, men lämpliga), och detta anses vara ett stort plus med VDI. Nåväl, när det gäller säkerhet är det nödvändigt att testa kompromissen med klientsystem. Detta händer ganska ofta.

I ljuset av Rospotrebnadzors rekommendationer om att organisera arbetet i företag som riskerar covid-19, är det mycket viktigt att ansluta till dina arbetsplatser på kontoret. Det ser ut som att den här historien kommer att pågå länge, och ja, om du tänkte på VDI kan du börja testa. Det kommer väl till pass. Rekommendationer är här, förtydliganden just här. Viktigt är att VDI också kan användas för att eftermontera utrymmen för att uppfylla kraven. Tillsynsmyndigheten inför vissa avståndsstandarder. Till exempel på ett kontor på 50 kvm. m det får inte vara fler än fem anställda.

Tja, om du har frågor om VDI som inte är för kommentarer, här är min e-post: [e-postskyddad].

Källa: will.com

Lägg en kommentar