Kunden Ăžnskede VDI. De kiggede meget pĂ„ kombinationen SimpliVity + VDI Citrix Virtual Desktop. For alle operatĂžrer, medarbejdere pĂ„ kontorer i byerne osv. Der er fem tusinde brugere kun i fĂžrste bĂžlge af migreringen, og derfor insisterede de pĂ„ belastningstestning. VDI kan begynde at blive langsom, kan ogsĂ„ kaste sig tilbage â og det sker ikke altid pĂ„ grund af problemer med forbindelsen. Vi kĂžbte en meget kraftfuld testpakke specielt til VDI og belastede infrastrukturen, indtil den brĂžd sammen i diske og processor.
SÄ vi har brug for en plastflaske, softwaren LoginVSI til avancerede VDI-tests. Vi har licenser til 300 brugere. Derefter fik vi HPE SimpliVity 380 hardware, der er velegnet til opgaven med maksimal bruger tÊthed pr. server, delte virtuelle maskiner med god genfordeling, installerede kontorsoftware pÄ Win10 og begyndte at teste.
Lad os komme i gang!
System
To noder (servere) HPE SimpliVity 380 Gen10. PĂ„ hver:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- PrimĂŠr diskcontroller: HPE Smart Array P816i-a SR Gen10.
- Harddiske: 9 x 1.92 TB SATA 6Gb/s SSD (i RAID6 7+2 konfiguration, dvs. det er model Medium i HPE SimpliVity-termer).
- NetvĂŠrkskort: 4 x 1Gb Eth (brugerdata), 2 x 10Gb Eth (SimpliVity backend og vMotion).
- Specialiserede indbyggede FPGA-kort i hver node til deduplikerings/komprimering.
Noderne er forbundet med 10Gb Ethernet interconnect direkte uden ekstern switch, som bruges som SimpliVity backend og til dataoverfĂžrsel af virtuelle maskiner via NFS. Datafra virtuelle maskiner i klyngen bliver altid spejlet mellem de to noder.
Noderne er samlet i en Vmware vSphere klynge styret af vCenter.
Til testning er der implementeret en domĂŠnecontroller og Citrix forbindelsesbroker. DomĂŠnecontrolleren, brokeren og vCenter er placeret i en separat klynge.
Som testinfrastruktur er der implementeret 300 virtuelle arbejdsstationer i Dedicated â Full Copy konfiguration, dvs. hver arbejdsstation er en fuld kopi af det originale billede af den virtuelle maskine og gemmer alle ĂŠndringer, der er foretaget af brugerne.
Hver virtuel maskine har 2vCPU og 4GB RAM:
FÞlgende software blev installeret pÄ de virtuelle maskiner, som er nÞdvendige til testningen:
- Windows 10 (64-bit), version 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Mellem noderne er der synkron replikation. Hver datablok i klyngen har to kopier. Det betyder, at det nu er et komplet datasÊt pÄ hver af noderne. Ved en klynge med tre eller flere noder ligger kopierne af blokkene pÄ to forskellige steder. NÄr en ny VM oprettes, oprettes der en ekstra kopi pÄ en af noderne i klyngen. Hvis en node svigter, genstartes alle VMs, som tidligere kÞrte pÄ den, automatisk pÄ andre noder, hvor de har deres replikater. Hvis noden svigter i lÊngere tid, begynder en gradvis genopretning af redundansen, og klyngen vender tilbage til N+1 reservedele.
Lastbalancering og datalagring sker pÄ niveauet af den programmÊssige lagring i SimpliVity.
Virtuelle maskiner starter virtualiseringsklyngen, som ogsÄ placerer dem pÄ den programmÊssige lagerenhed. De faktiske arbejdsstationer blev taget fra en standard skabelon: finansfolk og operatÞrer deltog i testen (dette er to forskellige skabeloner).
Testning
Til testningen blev testkomplekset LoginVSI 4.1 anvendt. LoginVSI-komplekset bestod af en styringsserver og 12 maskiner til testforbindelser, som blev implementeret pÄ en separat fysisk vÊrt.
Testningen blev udfĂžrt i tre tilstande:
Benchmark-tilstand - belastningsmuligheder for 300 Knowledge workers og 300 Storage workers.
Standardtilstand - belastningsmulighed for 300 Power workers.
For at muliggÞre arbejde for Power workers og Þge belastningsvariationen blev en bibliotek af yderligere filer, Power Library, tilfÞjet til LoginVSI-komplekset. For at sikre gentagelighed af resultaterne blev alle indstillinger pÄ testplatformen efterladt som Default.
Tests for Knowledge og Power workers simulerer den faktiske belastning af brugere, der arbejder pÄ virtuelle arbejdsstationer.
Testen af Storage workers blev specifikt oprettet til at teste datalagringssystemer, er langt fra virkelige belastninger og bestÄr primÊrt af brugerens interaktion med et stort antal filer af forskellige stÞrrelser.
Under testningen logger brugerne ind pÄ arbejdsstationerne i lÞbet af 48 minutter, cirka en bruger hver 10. sekund.
Resultater
Den primĂŠre resultatmetrik for LoginVSI-analyserne er VSImax, som sammensĂŠttes af tiden for udfĂžrelsen af forskellige opgaver, der udfĂžres af brugeren. For eksempel: tiden til at Ă„bne en fil i Notesblok, tiden til at komprimere en fil i 7-Zip osv.
En detaljeret beskrivelse af metric-beregning er tilgĂŠngelig i den officielle dokumentation for .
Med andre ord simulerer LoginVSI en typisk belastningsprofil, der efterligner brugerens handlinger i et kontorprogram, nÄr de lÊser PDF-filer osv., og mÄler forskellige forsinkelser. Der er et kritisk niveau af forsinkelser ('alt gÄr i stÄ, det er umuligt at arbejde'), som skal nÄs, fÞr det betragtes, at det maksimale antal brugere ikke er nÄet. Hvis svartiden er 1.000 ms hurtigere end denne 'alt gÄr i stÄ'-tilstand, betragtes systemet som fungerende korrekt, og der kan tilfÞjes flere brugere.
Her er de vigtigste metrikker:
Metrik
UdfĂžrte handlinger
Detaljeret beskrivelse
Belastede komponenter
NSLD
Tid til at Ă„bne en tekstfil
pÄ 1.500 KB
Notepad startes og
Äbner et tilfÊldigt dokument pÄ 1.500 KB, der er kopieret fra puljen
af ressourcer
CPU og I/O
NFO
Tid til at Ă„bne dialogvinduet i Notepad
Ă
bning af filen VSI-Notepad [Ctrl+O]
CPU, RAM og I/O
ZHC*
Â
Tid til at oprette en zip-fil med stĂŠrk kompression
Komprimering af en lokal
tilfÊldig fil i .pst-format pÄ 5 MB, der er kopieret fra
ressourcer.
ZLC*
CPU og I/O
Tid til at oprette en zip-fil med svag kompression
I/O
tilfÊldig fil i .pst-format pÄ 5 MB, der er kopieret fra
ressourcer.
ZLC*
Beregning af en stor
Â
CPU
matrix af tilfĂŠldige data
Oprettelse af en stor matrix
af tilfĂŠldige data, der vil blive brugt i I/O-timeren
NÄr testen udfÞres, beregnes den grundlÊggende metrik VSIbase fÞrst, som viser hastigheden pÄ opgaverne uden belastning pÄ systemet. PÄ baggrund af dette bestemmes VSImax Threshold, som er lig med VSIbase + 1.000 ms.
CPU
Resultater om systemets ydeevne er baseret pÄ to metrikker: VSIbase, som definerer systemets arbejds hastighed, og VSImax threshold, som definerer det maksimale antal brugere, som systemet kan klare uden vÊsentlig nedgang i ydeevnen.
300 Knowledge workers benchmark
Knowledge workers er brugere, der regelmÊssigt belaster hukommelsen, CPU'en og I/O med forskellige smÄ spidser. Softwaren emulerer belastningen fra krÊvende kontorbrugere, som om de konstant interagerer (PDF, Java, kontorpakke, billedvisning, 7-Zip). Som antallet af brugere stiger fra nul til 300, vokser forsinkelsen for hver enkelt gradvist.
VSImax-statistik:
VSIbase = 986 ms, VSI-threshold blev ikke nÄet.
Statistik for belastningen pÄ lagersystemet fra overvÄgningen af SimpliVity:
Statistik for belastningen pÄ lagersystemet fra overvÄgningen af SimpliVity:
Under this type of load, the system can handle an increase in load with virtually no degradation in performance. The execution time for user tasks rises smoothly, and the system's response time remains stable during testing, measuring up to 3 ms for writes and up to 1 ms for reads.
Output: 300 knowledge users operate on the current cluster without any issues, not interfering with each other, achieving a pCPU/vCPU over-subscription ratio of 1 to 6. Overall latencies increase uniformly with the load, but the established threshold has not been reached.
300 Storage workers benchmark
These are users who constantly read and write at a ratio of 30 to 70, respectively. This test was conducted more for the sake of experimentation. VSImax statistics data:
VSIbase = 1673, VSI Threshold was reached at 240 users.
Statistik for belastningen pÄ lagersystemet fra overvÄgningen af SimpliVity:
This type of load essentially serves as a stress test for the storage system. In this test, each user writes numerous random files of varying sizes to the disk. It is evident that when the load exceeds a certain threshold, some users experience increased execution times for file writing tasks. However, the load on the storage system, processors, and memory of the hosts does not significantly change, making it currently impossible to accurately determine the cause of the delays.
Performance conclusions about the system based on this test can only be drawn in comparison with test results from other systems, as such loads are synthetic and unrealistic. Nevertheless, the test overall went well. Up to 210 sessions went smoothly, after which there were unexplained responses that were not tracked anywhere but in Login VSI.
300 Power workers
These are users who demand superior CPU, memory, and high I/O. These 'advanced users' regularly execute complex tasks with long peaks, such as installing new software and unpacking large archives. VSImax statistics data:
VSIbase = 970, VSI Threshold was not reached.
Statistik for belastningen pÄ lagersystemet fra overvÄgningen af SimpliVity:
During the testing, a threshold load on processors was reached on one of the system's nodes, but this did not significantly impact its performance:
I dette tilfÊlde klarer systemet en stigning i belastningen uden vÊsentlig nedgang i ydeevnen. Brugernes opgavetid stiger gradvist, og systemets svartid Êndrer sig ikke i lÞbet af testen og er pÄ op til 3 ms ved skrivning og op til 1 ms ved lÊsning.
De normale tests var ikke tilstrÊkkelige for kunden, sÄ vi gik videre: vi opgraderede VM'ens specifikationer (antal vCPU'er for at vurdere stigning i overtegning og diskstÞrrelse) og tilfÞjede ekstra belastning.
Under udfĂžrelsen af de ekstra tests blev fĂžlgende standkonfiguration anvendt:
300 virtuelle arbejdsstationer blev rullet ud i konfigurationen 4vCPU, 4GB RAM, 80GB HDD.
Konfigurationen af en af testmaskinerne:
Maskinerne er rullet ud i Dedicated â Full Copy-varianten:
300 Knowledge workers benchmark med overtegning 12
VSIbase = 986 ms, VSI-threshold blev ikke nÄet.
VSIbase = 921 ms, VSI Threshold blev ikke nÄet.
Statistik for belastningen pÄ lagersystemet fra overvÄgningen af SimpliVity:
De opnÄede resultater er sammenlignelige med testen af den tidligere VM-konfiguration.
300 Power workers med overtegning 12
VSIbase = 986 ms, VSI-threshold blev ikke nÄet.
VSIbase = 933, VSI Threshold blev ikke nÄet.
Statistik for belastningen pÄ lagersystemet fra overvÄgningen af SimpliVity:
Ved denne test blev der ogsÄ nÄet en belastningsgrÊnse for processorerne, men det havde ikke vÊsentlig indflydelse pÄ ydeevnen:
De opnÄede resultater er sammenlignelige med testen af den tidligere konfiguration.
Hvad sker der, hvis belastningen kĂžres i 10 timer?
Nu ser vi, om der vil vĂŠre en 'akkumulerings-effekt', og vi kĂžrer tests i 10 timer i trĂŠk.
Langvarige tests og beskrivelsen af sektionen bÞr fokusere pÄ, hvad vi Þnskede at undersÞge, nemlig om der ville opstÄ problemer med farmen ved langvarig belastning.
300 Knowledge workers benchmark + 10 timer
Der blev desuden udfĂžrt test af belastningen med 300 knowledge workers med efterfĂžlgende brugeraktivitet i 10 timer.
VSIbase = 986 ms, VSI-threshold blev ikke nÄet.
VSIbase = 919 ms, VSI Threshold blev ikke nÄet.
Statistikdata VSImax Detaljeret:
Grafen viser, at der ikke observeres nogen nedgang i ydeevnen i hele testen.
Statistik for belastningen pÄ lagersystemet fra overvÄgningen af SimpliVity:
Ydeevnen af lagersystemet forbliver konstant gennem hele testen.
Yderligere test med tilfĂžjelse af syntetisk belastning
Kunden bad om at tilfÞje en intens belastning pÄ harddisken. For dette blev der tilfÞjet en opgave til lagringssystemet i hver af brugernes virtuelle maskiner til at starte en syntetisk belastning pÄ disken ved brugerens login. Belastningen blev leveret af vÊrktÞjet fio, som gÞr det muligt at begrÊnse diskbelastningen efter antal IOPS. I hver maskine blev en opgave til at starte en ekstra belastning pÄ 22 IOPS 70 %/30 % Random Read/Write aktiveret.
300 Vidensarbejdere benchmark + 22 IOPS pr. bruger
Ved den indledende test blev det konstateret, at fio skabte en betydelig ekstra belastning pÄ processorene i de virtuelle maskiner. Dette resulterede i hurtig overbelastning af vÊrtsmaskinerne pÄ CPU og pÄvirkede systemets samlede funktionalitet negativt.
Belastning pÄ vÊrtsmaskinernes CPU:
Forsinkelsen pÄ lagringssystemet steg ogsÄ i overensstemmelse med dette:
Mangel pÄ beregningskraft blev kritisk ved omkring 240 brugere:
Som fÞlge af de opnÄede resultater blev det besluttet at udfÞre testning, som belaster CPU mindre.
230 Kontorarbejdere benchmark + 22 IOPS pr. bruger
For at reducere belastningen pÄ CPU blev typen af belastning valgt til kontorarbejdere, hvor der ogsÄ blev tilfÞjet 22 IOPS syntetisk belastning pr. session.
Testen blev begrÊnset til 230 sessioner for ikke at overskride den maksimale belastning pÄ CPU.
Testen blev kÞrt med efterfÞlgende brug fra brugerne i 10 timer for at kontrollere systemets stabilitet ved langvarigt arbejde under en belastning tÊt pÄ det maksimale.
VSIbase = 986 ms, VSI-threshold blev ikke nÄet.
VSIbase = 918 ms, VSI-grÊnsen blev ikke nÄet.
Statistikdata VSImax Detaljeret:
Grafen viser, at der ikke observeres nogen nedgang i ydeevnen i hele testen.
Statistikker for CPU-belastningen:
Under udfÞrelsen af denne test var belastningen pÄ vÊrtsmaskinernes CPU nÊsten maksimal.
Statistik for belastningen pÄ lagersystemet fra overvÄgningen af SimpliVity:
Ydeevnen af lagersystemet forbliver konstant gennem hele testen.
Belastningen pĂ„ lagringssystemet under testen var omkring 6.500 IOPS i forholdet 60/40 (3.900 IOPS â til lĂŠsning, 2.600 IOPS â til skrivning), hvilket svarer til cirka 28 IOPS pr. arbejdsstation.
Svarstiden var i gennemsnit 3 ms for skrivning og op til 1 ms for lĂŠsning.
Resultat
Ved simulering af de reelle belastninger pÄ HPE SimpliVity-infrastrukturen blev der opnÄet resultater, der bekrÊfter systemets evne til at understÞtte drift af virtuelle skriveselv med ikke mindre end 300 Full Clone-maskiner pÄ et par SimpliVity-noder. Herunder blev lagringssystemets svarstid opretholdt pÄ et optimalt niveau gennem hele testen.
Vi vÊrdsÊtter meget tilgangen til langvarige tests og sammenligning af lÞsninger fÞr implementering. Vi kan teste ydeevnen for jeres belastning, hvis I Þnsker det. OgsÄ pÄ andre hyperkonvergerende lÞsninger. Den nÊvnte kunde afslutter nu testene af en anden lÞsning parallelt. Deres nuvÊrende infrastruktur bestÄr blot af en samling PC'er, et domÊne og software pÄ hver arbejdsplads. At skifte til VDI uden tests er naturligvis ret vanskeligt. Specifikt er det svÊrt at forstÄ de reelle muligheder for VDI-farmen uden at have migreret rigtige brugere til den. Og disse tests gÞr det muligt hurtigt at vurdere de reelle muligheder for et bestemt system uden at involvere almindelige brugere. Herfra opstod denne undersÞgelse.
En anden vigtig tilgang er, at kunden straks lÊgger op til den rigtige skalerbarhed. Her kan man kÞbe en server og tilfÞje en farm, for eksempel til 100 brugere, alt er forudsigeligt pr. bruger. For eksempel, nÄr de fÄr brug for at tilfÞje 300 brugere mere, vil de vide, at de har brug for to servere i en allerede defineret konfiguration, og ikke skulle overveje mulighederne for at opgradere deres infrastruktur generelt.
Mulighederne for HPE SimpliVity-federation er interessante. Forretning er geografisk opdelt, sĂ„ det giver mening at have en separat VDI-lĂžsning i den fjerne kontor. I SimpliVity-federationen replikeres hver virtuel maskine efter en tidsplan med mulighed for hurtigt at skabe forbindelse mellem geografisk adskilte klynger uden at belaste netvĂŠrket â det er en indbygget backup af meget hĂžj kvalitet. Ved replikering af VM'er mellem lokationerne anvendes bĂ„ndbredden minimalt, og det giver muligheder for at opbygge meget interessante DR-arkitekturer med en enkelt administrationscentral og mange decentrale lagringssteder.
Alt dette samlet giver mulighed for at vurdere de finansielle aspekter meget detaljeret, og at relatere omkostningerne ved VDI til virksomhedens vÊkstplaner, og forstÄ, hvor hurtigt lÞsningen vil betale sig tilbage, og hvordan den vil fungere. Fordi enhver VDI er en lÞsning, der i sidste ende sparer en masse ressourcer, men som sandsynligvis ikke vil spare Þkonomisk pÄ muligheden for at Êndre den inden for 5-7 Ärs brug.
Generelt, hvis du har spÞrgsmÄl, der ikke er til kommentarer, sÄ skriv til mig pÄ mk@croc.ru.
Kilde: habr.com
