Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt
Har du nogensinde spekuleret på, hvad en scanner gør med en VDI-station? Til at begynde med ser alt godt ud: det videresendes som en almindelig USB-enhed og er "gennemsigtigt" synlig fra den virtuelle maskine. Så giver brugeren en kommando om at scanne, og alt går ad helvede til. I bedste tilfælde - scannerdriveren, værre - i et par minutter scannersoftwaren, så kan det påvirke andre brugere af klyngen. Hvorfor? For for at få et fem megabyte komprimeret billede skal du sende to til tre størrelsesordener flere data via USB 2.0. Busgennemstrømning er 480 Mbit/s.

Så du skal teste tre ting: UX, periferiudstyr og sikkerhed – et must. Der er forskel på, hvordan man tester. Du kan installere agenter lokalt på hver virtuel arbejdsstation. Dette er relativt billigt, men viser ikke belastningen på kanalen og beregner ikke belastningen på processoren helt nøjagtigt. Den anden mulighed er at installere det nødvendige antal emulatorrobotter et andet sted og begynde at forbinde dem til rigtige job som rigtige brugere. Belastningen fra skærmvideostreamtransmissionsprotokollen (mere præcist, ændrede pixels), parsing og afsendelse af netværkspakker vil blive tilføjet, og belastningen på kanalen bliver tydelig. Kanalen kontrolleres generelt meget sjældent.

UX er den hastighed, hvormed slutbrugeren udfører forskellige handlinger. Der er testpakker, der indlæser installationen med hundredvis af brugere og udfører typiske handlinger for dem: lancere kontorpakker, læse PDF'er, gennemse, sjældent se porno i arbejdstiden og så videre.

Et ret godt eksempel på, hvorfor sådanne test er vigtige på forhånd, var i den seneste installation. Der flytter tusinde brugere til VDI, de har kontor, browser og SAP. Virksomhedens IT-afdeling er udviklet, så der er en kultur med belastningstest før implementeringer. Min erfaring er, at kunden som regel skal overtales til at gøre dette, fordi omkostningerne er høje og fordelene ikke altid åbenlyse. Er der nogen beregninger, hvor du kan lave en fejl? Faktisk afslører sådanne test steder, hvor de tænkte, men ikke kunne kontrollere.

Installation

Seks servere, konfigurationen er:

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Vi havde ikke adgang til kundens lagersystem; det blev faktisk leveret som et sted som en service. Men vi ved, at der er alt-flash. Vi ved ikke, hvilken all-flash det er, men partitionerne er på 10 TB. VDI - VMware efter kundens valg, da IT-teamet allerede er bekendt med stakken, og alt er ret organisk suppleret til at danne en komplet infrastruktur. VMware er meget "hooked" på sit økosystem, men hvis du har nok indkøbsbudget, har du måske ikke problemer i årevis. Men dette er ofte et meget stort "hvis". Vi har en god rabat, og det kender kunden til.

Vi starter test, fordi IT-teamet ikke frigiver næsten noget i produktion uden test. VDI er ikke noget, du kan starte og derefter acceptere. Brugere loader gradvist, og det er meget muligt at støde på problemer efter seks måneder. Hvilket selvfølgelig ingen ønsker.

450 "brugere" i testen genereres belastningen lokalt. Robo-brugere udfører forskellige handlinger samtidigt, vi måler tiden for hver operation over flere timers arbejde:

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Lad os se, hvordan serverne og lagersystemerne vil opføre sig. Vil VDI være i stand til at oprette det nødvendige antal virtuelle skriveborde og så videre. Da kunden ikke fulgte hyperkonvergensens vej, men tog et all-flash-lagringssystem, var det også nødvendigt at kontrollere rigtigheden af ​​dimensioneringen.

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Faldgruber ved skift til VDI: hvad skal man teste på forhånd for ikke at være uhyggeligt smertefuldt

Faktisk, hvis noget bremser et sted, skal du ændre indstillingerne for VDI-farmen, især fordelingen af ​​ressourcer mellem brugere af forskellige kategorier.

periferi

Der er normalt tre situationer med periferiudstyr:

  • Kunden siger blot, at vi ikke forbinder noget (nå, bortset fra headsets, er de normalt synlige "ud af boksen"). I løbet af de sidste fem år eller deromkring har jeg meget, meget sjældent set headset, der ikke er blevet samlet op af sig selv, og som ikke er blevet samlet op af VMware.
  • Den anden tilgang er at tage og ændre periferiudstyret som en del af VDI-implementeringsprojektet: vi tager det, vi og kunden har testet og understøttet. Sagen er forståeligt nok sjælden.
  • Den tredje tilgang er at kaste igennem den eksisterende hardware.

Du kender allerede til problemet med scannere: du skal installere middleware på en arbejdsstation (tynd klient), som modtager en USB-stream, komprimerer billedet og sender det til VDI. På grund af en række funktioner er dette ikke altid muligt: ​​hvis alt er fint på Win-klienter (hjemmecomputere og tynde klienter), så understøtter VDI-leverandøren for *nix builds normalt en specifik distribution, og dansene med en tamburin begynder, da på Mac-klienter. I min erindring var det få mennesker, der tilsluttede lokale printere fra Linux-installationer, så de ville fungere på fejlfindingsstadiet uden konstante opkald til support. Men det her er allerede godt for noget tid siden - endda bare for at arbejde.

Videokonference – alle kunder vil før eller siden have det til at fungere og fungere godt. Hvis gården er designet rigtigt, så fungerer det godt, hvis det er forkert, får vi en situation, hvor belastningen på kanalen øges under en lydkonference, plus derudover er der et problem, at billedet vises dårligt (ingen fuld HD, et ansigt på 9–16 pixels). En meget kraftig yderligere forsinkelse opstår, når der opstår en loop mellem klienten, VDI-arbejdsstationen, videokonferenceserveren og derfra den anden VDI og den anden klient. Det er korrekt at forbinde direkte fra klienten til videokonferenceserveren, hvilket kræver installation af en anden ekstra komponent.

USB nøgler - der er ingen problemer med dem overhovedet, smart cards og lignende, alt fungerer ud af æsken. Der kan opstå vanskeligheder med stregkodescannere, etiketprintere, maskiner (ja, der var sådan noget) og kasseapparater. Men alt er ved at blive løst. Med nuancer og ikke uden overraskelser, men i sidste ende løst.

Når en bruger ser YouTube fra en VDI-station, er dette den værste situation for både belastningen og kanalen. De fleste løsninger tilbyder HTML5-videoomdirigering. Den komprimerede fil overføres til klienten, hvor den vises. Eller klienten får tilsendt et link til direkte kommunikation mellem browseren og videohosting (dette er mindre almindeligt).

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

Sikkerhed opstår typisk ved komponentgrænseflader og på klientenheder. Ved knudepunkterne i ét økosystem burde alt med ord fungere godt. I praksis sker det i 90 % af tilfældene, og noget mangler stadig at blive afsluttet. I de seneste år har endnu et køb af Vmvara vist sig at være meget praktisk - de tilføjede MDM til økosystemet for at administrere enheder i virksomheden. VM'er har for nylig anskaffet interessante netværksbalancere (tidligere Avi Networks), som giver dig mulighed for at lukke spørgsmålet om flowdistribution et år efter færdiggørelsen af ​​VDI, for eksempel. En anden ren førstepartsfunktion er god optimering af filialer takket være deres friske indkøb, da de tog fat på VeloCloud-virksomheden, som laver SD-WAN til filialnet.

Fra slutbrugerens synspunkt er arkitekturen og leverandøren næsten usynlig. Det, der er globalt vigtigt, er, at der er en klient til enhver enhed; du kan oprette forbindelse fra en tablet, Mac eller tynd Windows-klient. Der var endda kunder til fjernsyn, men nu er de der heldigvis ikke længere.

Det særlige ved VDI-installationer er nu, at slutbrugeren simpelthen ikke har en computer derhjemme. Ofte har du en svag Android-tablet (nogle gange endda med mus eller tastatur), eller du kan endda være heldig og få en computer, der kører Win XP. Hvilket, som du kan gætte, ikke er blevet opdateret i et stykke tid. Og den bliver aldrig opdateret igen. Eller meget svage maskiner, hvor klienten ikke er installeret, applikationer ikke virker, brugeren kan ikke arbejde. Heldigvis er selv meget svage enheder egnede (ikke altid komfortable, men velegnede), og dette betragtes som et stort plus ved VDI. Nå, hvad angår sikkerhed, er det nødvendigt at teste kompromitteringen af ​​klientsystemer. Dette sker ret ofte.

I lyset af anbefalingerne fra Rospotrebnadzor om at organisere arbejdet i virksomheder under risiko for COVID-19, er det meget vigtigt at forbinde til dine arbejdspladser på kontoret. Det ser ud til, at denne historie vil vare i lang tid, og ja, hvis du tænkte på VDI, kan du begynde at teste. Det vil komme til nytte. Anbefalinger er her, præciseringer her. Vigtigt er det, at VDI også kan bruges til at eftermontere rum for at opfylde overensstemmelseskravene. Regulatoren indfører visse afstandsstandarder. For eksempel på et kontor på 50 kvm. m der ikke kan være mere end fem ansatte.

Nå, hvis du har spørgsmål om VDI, der ikke er til kommentar, her er min e-mail: [e-mail beskyttet].

Kilde: www.habr.com

Tilføj en kommentar