Kunden ønskede VDI. Jeg kiggede virkelig på SimpliVity + VDI Citrix Virtual Desktop-kombinationen. For alle operatører, ansatte i bykontoret og så videre. Der er fem tusinde brugere alene i den første migrationsbølge, og derfor insisterede de på belastningstest. VDI kan begynde at sænke farten, den kan roligt lægge sig ned – og det sker ikke altid på grund af problemer med kanalen. Vi købte en meget kraftfuld testpakke specifikt til VDI og indlæste infrastrukturen, indtil den var for tung på diskene og processoren.
Så vi skal bruge en plastikflaske og LoginVSI-software til sofistikerede VDI-tests. Vi har den med licenser til 300 brugere. Så tog vi HPE SimpliVity 380-hardware i en pakke, der var egnet til opgaven med maksimal brugertæthed pr. server, skar virtuelle maskiner op med godt overabonnement, installerede kontorsoftware på Win10 på dem og begyndte at teste.
Lad os gå!
System
To HPE SimpliVity 380 Gen10 noder (servere). På hver:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- RAM: 768GB, 12 x 64GB LRDIMM'er DDR4 2666MHz.
- Primær diskcontroller: HPE Smart Array P816i-a SR Gen10.
- Harddiske: 9 x 1.92 TB SATA 6 Gb/s SSD (i RAID6 7+2 konfiguration, dvs. dette er en medium model i HPE SimpliVity termer).
- Netværkskort: 4 x 1 Gb Eth (brugerdata), 2 x 10 Gb Eth (SimpliVity og vMotion backend).
- Særlige indbyggede FPGA-kort i hver node til deduplikering/komprimering.
Noderne er forbundet med hinanden via en 10Gb Ethernet-forbindelse direkte uden en ekstern switch, som bruges som SimpliVity-backend og til overførsel af virtuelle maskindata via NFS. Virtuel maskindata i en klynge spejles altid mellem to noder.
Noderne er kombineret til en Vmware vSphere-klynge, der administreres af vCenter.
Til test blev der indsat en domænecontroller og en Citrix-forbindelsesmægler. Domænecontrolleren, mægleren og vCenter er placeret på en separat klynge.
Som en testinfrastruktur blev 300 virtuelle desktops implementeret i Dedicated - Full Copy-konfigurationen, dvs. hver desktop er en komplet kopi af det originale billede af den virtuelle maskine og gemmer alle ændringer foretaget af brugere.
Hver virtuel maskine har 2vCPU og 4GB RAM:
Følgende software, der kræves til test, blev installeret på de virtuelle maskiner:
- Windows 10 (64-bit), version 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 opdatering 13.
- Microsoft Office Professional Plus 2016.
Mellem noder - synkron replikation. Hver datablok i klyngen har to kopier. Det vil sige, at der nu er et komplet sæt data på hver af noderne. Med en klynge på tre eller flere noder er kopier af blokke to forskellige steder. Når du opretter en ny VM, oprettes en ekstra kopi på en af klyngens noder. Når en node fejler, genstartes alle VM'er, der tidligere har kørt på den, automatisk på andre noder, hvor de har replikaer. Hvis en node svigter i lang tid, begynder gradvis genoprettelse af redundans, og klyngen vender tilbage til N+1 redundans.
Databalancering og lagring finder sted på selve SimpliVitys softwarelagerniveau.
Virtuelle maskiner kører en virtualiseringsklynge, som også placerer dem på softwarelager. Selve skrivebordene blev taget efter en standardskabelon: skrivebordene fra finansfolk og operationsofficerer kom til testen (dette er to forskellige skabeloner).
Test
Til test blev LoginVSI 4.1 softwaretestpakken brugt. LoginVSI-komplekset, bestående af en kontrolserver og 12 maskiner til testforbindelser, blev installeret på en separat fysisk vært.
Testen blev udført i tre tilstande:
Benchmark-tilstand - load cases 300 vidensarbejdere og 300 lagerarbejdere.
Standardtilstand - lastkasse 300 Power workers.
For at sætte Power-arbejdere i stand til at arbejde og øge belastningsdiversiteten, blev der tilføjet et bibliotek med yderligere Power Library-filer til LoginVSI-komplekset. For at sikre resultaternes repeterbarhed blev alle testbænkindstillinger efterladt som standard.
Knowledge- og Power-arbejdertestene simulerer den reelle arbejdsbyrde for brugere, der arbejder på virtuelle arbejdsstationer.
Storage workers-testen blev skabt specifikt til at teste datalagringssystemer; den er langt fra reelle arbejdsbelastninger og involverer for det meste, at brugeren arbejder med et stort antal filer af forskellig størrelse.
Under test logger brugere på arbejdsstationer i 48 minutter med en hastighed på cirka én bruger hvert 10. sekund.
Fund
Hovedresultatet af LoginVSI-testning er VSImax-metrikken, som er kompileret ud fra udførelsestiden for forskellige opgaver, som er startet af brugeren. For eksempel: tid til at åbne en fil i Notesblok, tid til at komprimere en fil i 7-Zip osv.
En detaljeret beskrivelse af metrikberegning er tilgængelig i den officielle dokumentation for .
Med andre ord gentager LoginVSI et typisk belastningsmønster, simulerer brugerhandlinger i en kontorpakke, læser en PDF og så videre og måler forskellige latenser. Der er et kritisk niveau af forsinkelser "alt går langsommere, det er umuligt at arbejde"), før det vurderes, at det maksimale antal brugere ikke er nået. Hvis responstiden er 1 ms hurtigere end denne "alt er langsom" tilstand, anses systemet for at fungere normalt, og flere brugere kan tilføjes.
Her er de vigtigste målinger:
Metrics
Handlinger taget
detaljeret описание
Indlæste komponenter
N.S.L.D.
Tekst åbningstid
fil, der vejer 1 KB
Notesblok åbner og
åbner et tilfældigt 1 KB dokument, der kopieres fra puljen
ressourcer
CPU og I/O
NFO
Dialogåbningstid
vinduer i notesblok
Åbning af en VSI-Notepad-fil [Ctrl+O]
CPU, RAM og I/O
ZHC*
Tid til at oprette en meget komprimeret zip-fil
Lokal kompression
tilfældig 5MB .pst-fil kopieret fra
ressourcepulje
CPU og I/O
ZLC*
Tid til at oprette en svagt komprimeret zip-fil
Lokal kompression
tilfældig 5MB .pst-fil kopieret fra
ressourcepulje
I / O
CPU
Regner stort
tilfældig dataarray
Oprettelse af et stort array
tilfældige data, der vil blive brugt i input/output timeren (I/O timer)
CPU
Når test udføres, beregnes den grundlæggende VSIbase-metrik, som viser den hastighed, hvormed job udføres uden belastning på systemet. Ud fra den bestemmes VSImax Threshold, som er lig med VSIbase + 1ms.
Konklusioner om systemets ydeevne er lavet ud fra to målinger: VSIbase, som bestemmer systemets hastighed, og VSImax-tærskel, som bestemmer det maksimale antal brugere, som systemet kan håndtere uden væsentlig forringelse.
Benchmark for 300 videnarbejdere
Videnarbejdere er brugere, der regelmæssigt indlæser hukommelse, processor og IO med forskellige små peaks. Softwaren emulerer arbejdsbyrden for krævende kontorbrugere, som om de konstant kikket i noget (PDF, Java, kontorpakke, fotovisning, 7-Zip). Når du tilføjer brugere fra nul til 300, øges forsinkelsen for hver enkelt gradvist.
VSImax statistikdata:
VSIbase = 986ms, VSI Threshold blev ikke nået.
Lagersystembelastningsstatistik fra SimpliVity-overvågning:
Med denne type belastning kan systemet modstå øget belastning med stort set ingen forringelse af ydeevnen. Den tid, det tager at udføre brugeropgaver, øges jævnt, systemets responstid ændres ikke under test og er op til 3 ms til skrivning og op til 1 ms til læsning.
Konklusion: 300 vidensbrugere arbejder på den nuværende klynge uden problemer og forstyrrer ikke hinanden, og når pCPU/vCPU overabonnement på 1 til 6. De samlede forsinkelser vokser jævnt efterhånden som belastningen stiger, men den fastsatte grænse er ikke nået.
Benchmark for 300 lagerarbejdere
Det er brugere, der konstant skriver og læser i et forhold på henholdsvis 30 til 70. Denne test blev udført mere for eksperimentets skyld. VSImax statistikdata:
VSIbase = 1673, VSI-tærskel nået på 240 brugere.
Lagersystembelastningsstatistik fra SimpliVity-overvågning:
Denne type belastning er i det væsentlige en stresstest af lagersystemet. Når det udføres, skriver hver bruger mange tilfældige filer af forskellig størrelse til disken. I dette tilfælde kan det ses, at når en vis belastningstærskel overskrides for nogle brugere, øges tiden det tager at udføre opgaver til at skrive filer. Samtidig ændres belastningen på lagersystemet, processoren og hukommelsen hos værterne ikke væsentligt, så det er i øjeblikket umuligt at fastslå præcis, hvad der forårsager forsinkelserne.
Konklusioner om systemets ydeevne ved brug af denne test kan kun drages i sammenligning med testresultater på andre systemer, da sådanne belastninger er syntetiske og urealistiske. Men alt i alt gik testen godt. Alt gik godt indtil 210 sessioner, og så begyndte mærkelige svar, som ikke blev sporet andre steder end Login VSI.
300 kraftarbejdere
Det er brugere, der elsker CPU, hukommelse og høj IO. Disse "power-brugere" kører regelmæssigt komplekse opgaver med lange bursts, såsom installation af ny software og udpakning af store arkiver. VSImax statistikdata:
VSIbase = 970, VSI-tærskel blev ikke nået.
Lagersystembelastningsstatistik fra SimpliVity-overvågning:
Under testning blev processorbelastningstærsklen nået på en af systemknuderne, men dette havde ikke en væsentlig indflydelse på dens drift:
I dette tilfælde kan systemet modstå øget belastning uden væsentlig forringelse af ydeevnen. Den tid, det tager at udføre brugeropgaver, øges jævnt, systemets responstid ændres ikke under test og er op til 3 ms til skrivning og op til 1 ms til læsning.
Regelmæssige test var ikke nok for kunden, og vi gik videre: Vi øgede VM-egenskaberne (antal vCPU'er for at evaluere stigningen i overabonnement og diskstørrelse) og tilføjede yderligere belastning.
Ved udførelse af yderligere test blev følgende stativkonfiguration brugt:
300 virtuelle desktops blev implementeret i en 4vCPU, 4GB RAM, 80GB HDD-konfiguration.
Konfiguration af en af testmaskinerne:
Maskinerne er implementeret i indstillingen Dedikeret – fuld kopi:
Benchmark for 300 videnarbejdere med overtegning 12
VSImax statistikdata:
VSIbase = 921 ms, VSI-tærskel blev ikke nået.
Lagersystembelastningsstatistik fra SimpliVity-overvågning:
De opnåede resultater svarer til at teste den tidligere VM-konfiguration.
300 Elarbejdere med 12 overtegninger
VSImax statistikdata:
VSIbase = 933, VSI-tærskel blev ikke nået.
Lagersystembelastningsstatistik fra SimpliVity-overvågning:
Under denne test blev processorbelastningstærsklen også nået, men dette havde ikke en væsentlig indflydelse på ydeevnen:
De opnåede resultater svarer til at teste den tidligere konfiguration.
Hvad sker der, hvis du kører belastningen i 10 timer?
Lad os nu se, om der vil være en "akkumulationseffekt" og køre test i 10 timer i træk.
Langtidstestene og beskrivelsen af sektionen skulle rettes mod, at vi ønskede at tjekke, om der ville opstå problemer med spærværket under længere tids belastning af det.
300 videnarbejdere benchmark + 10 timer
Derudover blev en belastningssag på 300 vidensarbejdere testet, efterfulgt af brugerarbejde i 10 timer.
VSImax statistikdata:
VSIbase = 919 ms, VSI-tærskel blev ikke nået.
VSImax Detaljerede statistikdata:
Grafen viser, at der ikke er observeret nogen ydeevneforringelse gennem hele testen.
Lagersystembelastningsstatistik fra SimpliVity-overvågning:
Lagersystemets ydeevne forbliver den samme under hele testen.
Yderligere test med tilføjelse af syntetisk belastning
Kunden bad om at tilføje en vild belastning til disken. For at gøre dette blev der tilføjet en opgave til lagersystemet i hver af brugerens virtuelle maskiner for at køre en syntetisk belastning på disken, når brugeren logger ind på systemet. Indlæsningen blev leveret af fio-værktøjet, som giver dig mulighed for at begrænse belastningen på disken med antallet af IOPS. I hver maskine blev der startet en opgave for at starte en ekstra belastning på 22 IOPS 70%/30% Random Read/Write.
Benchmark for 300 videnarbejdere + 22 IOPS pr. bruger
I den indledende test blev fio fundet at pålægge virtuelle maskiner betydelige CPU-omkostninger. Dette førte til hurtig CPU-overbelastning af værterne og påvirkede i høj grad driften af systemet som helhed.
Værts CPU-belastning:
Samtidig er forsinkelser i lagringssystemet naturligvis også øget:
Manglen på computerkraft blev kritisk omkring 240 brugere:
På grund af de opnåede resultater blev det besluttet at udføre test, der var mindre CPU-intensiv.
Benchmark for 230 kontorarbejdere + 22 IOPS pr. bruger
For at reducere belastningen på CPU'en blev belastningstypen Office-medarbejdere valgt, og 22 IOPS syntetisk belastning blev også tilføjet til hver session.
Testen var begrænset til 230 sessioner for ikke at overskride den maksimale CPU-belastning.
Testen blev kørt med brugere, der kørte i 10 timer for at kontrollere systemets stabilitet under langtidsdrift ved tæt på maksimal belastning.
VSImax statistikdata:
VSIbase = 918 ms, VSI-tærskel blev ikke nået.
VSImax Detaljerede statistikdata:
Grafen viser, at der ikke er observeret nogen ydeevneforringelse gennem hele testen.
CPU-belastningsstatistik:
Når denne test blev udført, var belastningen på værternes CPU næsten maksimal.
Lagersystembelastningsstatistik fra SimpliVity-overvågning:
Lagersystemets ydeevne forbliver den samme under hele testen.
Belastningen på lagersystemet under testen var ca. 6 IOPS i et 500/60-forhold (40 IOPS-læsning, 3 IOPS-skrivning), hvilket er ca. 900 IOPS pr. arbejdsstation.
Svartiden var i gennemsnit 3 ms til skrivning og op til 1 ms til læsning.
Total
Ved simulering af reelle belastninger på HPE SimpliVity-infrastrukturen blev der opnået resultater, der bekræftede systemets evne til at understøtte virtuelle desktops på mindst 300 Full Clone-maskiner på et par SimpliVity-noder. Samtidig blev lagersystemets responstid holdt på et optimalt niveau gennem hele testen.
Vi er meget imponerede over tilgangen med lange test og sammenligning af løsninger før implementering. Vi kan også teste ydeevnen for dine arbejdsbelastninger, hvis du ønsker det. Herunder andre hyperkonvergerede løsninger. Den nævnte kunde er nu ved at afslutte test på en anden løsning sideløbende. Dens nuværende infrastruktur er simpelthen en flåde af pc'er, et domæne og software på hver arbejdsplads. At flytte til VDI uden test er selvfølgelig ret svært. Specifikt er det svært at forstå de reelle muligheder i en VDI-farm uden at migrere rigtige brugere til den. Og disse test giver dig mulighed for hurtigt at evaluere de reelle muligheder for et bestemt system uden at skulle involvere almindelige brugere. Det er her denne undersøgelse kom fra.
Den anden vigtige tilgang er, at kunden straks forpligter sig til korrekt skalering. Her kan du købe en ekstra server og tilføje en farm, for eksempel til 100 brugere, alt er forudsigeligt til brugerprisen. For eksempel, når de skal tilføje 300 flere brugere, vil de vide, at de har brug for to servere i en allerede defineret konfiguration, i stedet for at genoverveje at opgradere hele deres infrastruktur.
HPE SimpliVity-forbundets muligheder er interessante. Forretningen er geografisk adskilt, så det giver mening at installere din egen separate VDI-hardware på et fjerntliggende kontor. I SimpliVity-føderationen replikeres hver virtuel maskine efter en tidsplan med mulighed for at replikere mellem geografisk fjerntliggende klynger meget hurtigt og uden belastning på kanalen - dette er en indbygget backup af et meget godt niveau. Ved replikering af VM'er mellem steder, bruges kanalen så minimalt som muligt, og det gør det muligt at bygge meget interessante DR-arkitekturer i nærvær af et enkelt kontrolcenter og en masse decentraliserede lagersteder.
Alt dette tilsammen gør det muligt at evaluere den økonomiske side meget detaljeret og at overlejre omkostningerne ved VDI på virksomhedens vækstplaner og at forstå, hvor hurtigt løsningen vil betale sig, og hvordan den vil fungere. Fordi enhver VDI er en løsning, der i sidste ende sparer en masse ressourcer, men samtidig højst sandsynligt uden den omkostningseffektive mulighed for at ændre den inden for 5-7 års brug.
Generelt, hvis du har spørgsmål, der ikke er til kommentar, så skriv til mig på e-mail [e-mail beskyttet].
Kilde: www.habr.com