Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt
Har du noen gang lurt på hva en skanner gjør med en VDI-stasjon? Til å begynne med ser alt bra ut: det videresendes som en vanlig USB-enhet og er "gjennomsiktig" synlig fra den virtuelle maskinen. Så gir brukeren en kommando om å skanne, og alt går til helvete. I beste fall - skannerdriveren, enda verre - i løpet av et par minutter skannerprogramvaren, så kan det påvirke andre brukere av klyngen. Hvorfor? For for å få et fem megabyte komprimert bilde, må du sende to til tre størrelsesordener mer data via USB 2.0. Bussgjennomstrømning er 480 Mbit/s.

Så du må teste tre ting: UX, periferiutstyr og sikkerhet - et must. Det er forskjell på hvordan du tester. Du kan installere agenter lokalt på hver virtuelle arbeidsstasjon. Dette er relativt billig, men viser ikke belastningen på kanalen og beregner ikke belastningen på prosessoren helt nøyaktig. Det andre alternativet er å distribuere det nødvendige antallet emulatorroboter på et annet sted og begynne å koble dem til ekte jobber som ekte brukere. Lasten fra overføringsprotokollen for skjermvideostrøm (mer presist, endrede piksler), parsing og sending av nettverkspakker vil bli lagt til, og belastningen på kanalen blir tydelig. Kanalen sjekkes generelt svært sjelden.

UX er hastigheten sluttbrukeren utfører ulike handlinger med. Det er testpakker som laster installasjonen med hundrevis av brukere og gjør typiske handlinger for dem: lanserer kontorpakker, les PDF-er, surfer, ser sjelden på porno i arbeidstiden, og så videre.

Et ganske godt eksempel på hvorfor slike tester er viktige på forhånd var i den siste installasjonen. Der flytter tusen brukere til VDI, de har kontor, nettleser og SAP. Selskapets IT-avdeling er utviklet, så det er en kultur med belastningstesting før implementeringer. Min erfaring er at kunden vanligvis må overtales til å gjøre dette, fordi kostnadene er høye og fordelene ikke alltid åpenbare. Finnes det noen beregninger der du kan gjøre feil? Faktisk avslører slike tester steder hvor de tenkte, men ikke kunne sjekke.

installasjon

Seks servere, konfigurasjonen er:

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

Vi hadde ikke tilgang til kundens lagringssystem, det ble gitt som et sted som en tjeneste, faktisk. Men vi vet at det er all-flash. Vi vet ikke hvilken all-flash det er, men partisjonene er på 10 TB. VDI - VMware etter kundens valg, siden IT-teamet allerede er kjent med stabelen, og alt er ganske organisk supplert for å danne en komplett infrastruktur. VMware er veldig "hooked" på økosystemet sitt, men hvis du har nok innkjøpsbudsjett, kan det hende du ikke har noen problemer på flere år. Men dette er ofte et veldig stort "hvis". Vi har god rabatt, og det vet kunden om.

Vi starter tester, fordi IT-teamet slipper nesten noe i produksjon uten tester. VDI er ikke noe du kan starte og deretter godta. Brukere laster gradvis, og det er fullt mulig å støte på problemer etter seks måneder. Noe ingen selvfølgelig vil ha.

450 "brukere" i testen, lasten genereres lokalt. Robo-brukere utfører forskjellige handlinger samtidig, vi måler tiden for hver operasjon over flere timers arbeid:

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

La oss se hvordan serverne og lagringssystemene vil oppføre seg. Vil VDI kunne lage det nødvendige antallet virtuelle skrivebord, og så videre. Siden kunden ikke fulgte veien til hyperkonvergens, men tok et all-flash-lagringssystem, var det nødvendig å kontrollere riktigheten av dimensjoneringen også.

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

Fallgruver når du bytter til VDI: hva du skal teste på forhånd for ikke å være uutholdelig smertefullt

Faktisk, hvis noe bremser et sted, må du endre innstillingene til VDI-farmen, spesielt fordelingen av ressurser mellom brukere av forskjellige kategorier.

Utkanten

Det er vanligvis tre situasjoner med periferiutstyr:

  • Kunden sier ganske enkelt at vi ikke kobler til noe (vel, bortsett fra hodesett, er de vanligvis synlige "ut av esken"). I løpet av de siste fem årene eller så har jeg veldig, veldig sjelden sett hodesett som ikke har blitt plukket opp på egen hånd, og som ikke har blitt plukket opp av VMware.
  • Den andre tilnærmingen er å ta og endre periferiutstyret som en del av VDI-implementeringsprosjektet: vi tar det vi og kunden har testet og støttet. Saken er forståelig nok sjelden.
  • Den tredje tilnærmingen er å kaste gjennom den eksisterende maskinvaren.

Du vet allerede om problemet med skannere: du må installere mellomvare på en arbeidsstasjon (tynn klient), som mottar en USB-strøm, komprimerer bildet og sender det til VDI. På grunn av en rekke funksjoner er dette ikke alltid mulig: hvis alt er bra på Win-klienter (hjemmedatamaskiner og tynnklienter), så støtter VDI-leverandøren for *nix-bygg vanligvis en spesifikk distribusjon og dansene med en tamburin begynner, ettersom på Mac-klienter. I mitt minne var det få som koblet til lokale skrivere fra Linux-installasjoner slik at de ville fungere på feilsøkingsstadiet uten konstante oppfordringer til støtte. Men dette er allerede bra, for en tid siden – til og med bare for å jobbe.

Videokonferanse – alle kunder vil før eller siden at det skal fungere og fungere godt. Hvis gården er utformet riktig, så fungerer den bra, hvis feil, får vi en situasjon der under en lydkonferanse øker belastningen på kanalen, pluss i tillegg til dette er det et problem at bildet vises dårlig (ingen full HD, et ansikt på 9–16 piksler). En veldig sterk ekstra forsinkelse oppstår når en sløyfe vises mellom klienten, VDI-arbeidsstasjonen, videokonferanseserveren, og derfra den andre VDI og den andre klienten. Det er riktig å koble direkte fra klienten til videokonferanseserveren, som krever installasjon av en annen tilleggskomponent.

USB-nøkler - det er ingen problemer med dem i det hele tatt, smartkort og lignende, alt fungerer ut av esken. Det kan oppstå vanskeligheter med strekkodeskannere, etikettskrivere, maskiner (ja, det var noe slikt) og kasseapparater. Men alt blir løst. Med nyanser og ikke uten overraskelser, men til slutt løst.

Når en bruker ser på YouTube fra en VDI-stasjon, er dette den verste situasjonen for både belastningen og kanalen. De fleste løsninger tilbyr HTML5-videoomdirigering. Den komprimerte filen overføres til klienten, hvor den vises. Eller klienten får tilsendt en lenke for direkte kommunikasjon mellom nettleseren og videohosting (dette er mindre vanlig).

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

Sikkerhet skjer vanligvis ved komponentgrensesnitt og på klientenheter. I knutepunktene i ett økosystem skal med ord alt fungere bra. I praksis skjer dette i 90 % av tilfellene, og noe gjenstår fortsatt. De siste årene har et annet kjøp av Vmvara vist seg å være veldig praktisk - de la MDM til økosystemet for å administrere enheter i selskapet. VM-er har nylig anskaffet interessante nettverksbalansere (tidligere Avi Networks), som lar deg lukke problemet med flytdistribusjon et år etter ferdigstillelsen av VDI, for eksempel. En annen ren førstepartsfunksjon er god optimalisering av filialer takket være deres ferske shopping da de tok på seg VeloCloud-selskapet, som lager SD-WAN for filialnett.

Fra sluttbrukerens synspunkt er arkitekturen og leverandøren nesten usynlig. Det som er globalt viktig er at det er en klient for enhver enhet; du kan koble til fra et nettbrett, Mac eller Windows tynnklient. Det var til og med kunder for fjernsyn, men nå er de heldigvis ikke lenger der.

Det særegne med VDI-installasjoner nå er at sluttbrukeren rett og slett ikke har en datamaskin hjemme. Ofte har du et svakt Android-nettbrett (noen ganger til og med med mus eller tastatur), eller du kan til og med være heldig og få en datamaskin som kjører Win XP. Som du kan gjette, ikke har blitt oppdatert på en stund. Og den vil aldri bli oppdatert igjen. Eller veldig svake maskiner, hvor klienten ikke er installert, applikasjoner ikke fungerer, brukeren kan ikke jobbe. Heldigvis er selv veldig svake enheter egnet (ikke alltid komfortable, men passende), og dette anses som et stort pluss med VDI. Vel, når det gjelder sikkerhet, er det nødvendig å teste kompromisset til klientsystemer. Dette skjer ganske ofte.

I lys av anbefalingene fra Rospotrebnadzor om organisering av arbeidet til bedrifter under risiko for COVID-19, er det veldig viktig å koble seg til arbeidsplassene dine på kontoret. Det ser ut til at denne historien vil vare lenge, og ja, hvis du tenkte på VDI, kan du begynne å teste. Det vil komme godt med. Anbefalinger er her, avklaringer her. Viktigere er at VDI også kan brukes til å ettermontere rom for å møte samsvarskrav. Regulatoren introduserer visse avstandsstandarder. For eksempel på et kontor på 50 kvm. m det kan ikke være mer enn fem ansatte.

Vel, hvis du har spørsmål om VDI som ikke er for kommentar, her er e-posten min: [e-postbeskyttet].

Kilde: www.habr.com

Legg til en kommentar