Kunden ville ha VDI. De vurderte sterkt kombinasjonen SimpliVity + VDI Citrix Virtual Desktop. For alle operatĂžrer, kontoransatte i byene osv. Der er fem tusen brukere bare i den fĂžrste bĂžlgen av migrering, og derfor insisterte de pĂ„ belastningstesting. VDI kan begynne Ă„ hakke, det kan koble fra â og det skjer ikke alltid pĂ„ grunn av problemer med kanalen. Vi kjĂžpte en veldig kraftig testpakke spesifikt for VDI og belastet infrastrukturen til den krasjet pĂ„ disker og prosessor.
SÄ, vi trenger en plastflaske, programvaren LoginVSI for avanserte VDI-tester. Vi har den med lisenser for 300 brukere. Deretter tok vi HPE SimpliVity 380-maskinvaren som er egnet for oppgaven med maksimal tetthet av brukere per server, delte opp virtuelle maskiner med god gjenoppretting, installerte kontorprogramvare pÄ Win10 og begynte Ä teste.
LÄt oss köra!
Systemet
To noder (servere) HPE SimpliVity 380 Gen10. Hver av dem:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Hoved diskcontroller: HPE Smart Array P816i-a SR Gen10.
- Harddisker: 9 x 1.92 TB SATA 6Gb/s SSD (med RAID6 7+2-konfigurasjon, dvs. dette er Medium-modellen i HPE SimpliVity-termer).
- Nettverkskort: 4 x 1Gb Eth (brukerdata), 2 x 10Gb Eth (SimpliVity-backend og vMotion).
- Spesielle innebygde FPGA-kort i hver node for deduplisering/komprimering.
Nodene er koblet sammen med 10Gb Ethernet interconnect direkte uten ekstern svitsj, som brukes som SimpliVity backend og for Ă„ overfĂžre data for virtuelle maskiner via NFS. Dataene for virtuelle maskiner i klyngen blir alltid speilet mellom to noder.
Nodene er samlet i en Vmware vSphere-klynge under administrasjon av vCenter.
For testing er en domenecontroller og Citrix-tilkoblingsmegler rullet ut. Domenecontrolleren, megleren og vCenter er plassert pÄ en separat klynge.
Som testinfrastruktur er 300 virtuelle skrivebord rullet ut i Dedicated â Full Copy-konfigurasjon, dvs. hvert skrivebord er en full kopi av det originale bildet av den virtuelle maskinen og lagrer alle endringer gjort av brukerne.
Hver virtuell maskin har 2vCPU og 4GB RAM:
FÞlgende programvare ble installert pÄ de virtuelle maskinene, nÞdvendige for testing:
- Windows 10 (64-bit), versjon 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Mellan noderna finns synkron replikering. Varje datablok i klustret har tvÄ kopior. Det innebÀr att den fullstÀndiga datasamlingen finns pÄ varje nod. För kluster med tre eller fler noder finns kopior av blocken pÄ tvÄ olika platser. NÀr en ny VM skapas görs en extra kopia pÄ en av noderna i klustret. Om en nod gÄr ner startas alla VMer som tidigare kördes pÄ den automatiskt om pÄ andra noder dÀr de har sina kopior. Om noden Àr nere under en lÀngre tid pÄbörjas en gradvis ÄterstÀllning av redundansen, och klustret ÄtervÀnder till N+1 reservdelning.
BelastningsutjÀmning och lagring av data sker pÄ nivÄn av den programvarulagring som SimpliVity erbjuder.
Virtuella maskiner startar ett virtualiseringskluster, och de Àr placerade pÄ programvarulagret. Arbetsstationerna följde en standardmall: vi testade arbetsstationer för finansiÀrer och operatörer (detta Àr tvÄ olika mallar).
Testning
För testningen anvÀndes testpaketet LoginVSI 4.1. LoginVSI-paketet, som bestÄr av en styrserver och 12 maskiner för testanslutningar, implementerades pÄ en separat fysisk vÀrd.
Testningen utfördes i tre lÀgen:
Benchmark-lĂ€get â belastningsalternativen 300 Knowledge workers och 300 Storage workers.
StandardlĂ€get â belastningsalternativet 300 Power workers.
För att möjliggöra arbete för Power workers och öka variationen i belastningen lades en samling ytterligare filer, Power Library, till i LoginVSI-paketet. För att sÀkerstÀlla upprepbarheten av resultaten lÀmnades alla instÀllningar pÄ testbÀnken som standard.
Tester av Knowledge och Power workers simulerar verklig belastning för anvÀndare som arbetar pÄ virtuella arbetsstationer.
Testet av Storage workers skapades specifikt för att testa lagringssystem och ligger lÄngt ifrÄn verkliga belastningar, och bestÄr mestadels av anvÀndarens arbete med ett stort antal filer av olika storlekar.
Under testningen loggar anvÀndare in pÄ arbetsstationer under en period av 48 minuter, ungefÀr en anvÀndare var tionde sekund.
Resultat
Det primÀra resultatet av LoginVSI-testet Àr metric VSImax, som sammanstÀlls av tiden det tar att utföra olika uppgifter som anvÀndaren startar. Till exempel: tiden för att öppna en fil i anteckningar, tiden för att komprimera en fil i 7-Zip, osv.
Detaljerad beskrivning av mÀtpunkter finns i den officiella dokumentationen om .
Med andra ord efterliknar LoginVSI en typisk belastningsmodell, simulerar anvÀndarens ÄtgÀrder i ett kontorsprogram, nÀr man lÀser PDF-filer och sÄ vidare, och mÀter olika fördröjningar. Det finns en kritisk nivÄ av fördröjning dÀr "allt segar, det gÄr inte att arbeta", och nÀr detta tillstÄnd nÄs anses det att det maximala antalet anvÀndare inte Àr nÄtt. Om svarstiden Àr under 1 000 ms snabbare Àn tillstÄndet "allt segar", anses systemet fungera normalt och fler anvÀndare kan lÀggas till.
HÀr Àr de viktigaste mÀtpunkterna:
MĂ€tpunkt
Utförda ÄtgÀrder
Detaljerad beskrivning
Belastade komponenter
NSLD
Tid för öppning av textfil
med en storlek pÄ 1 500 Kb
Anteckningsbladet startar och
öppnar ett slumpmÀssigt dokument pÄ 1 500 Kb, som Àr kopierat frÄn resurspoolen
Resurser
CPU och I/O
NFO
Tid för öppning av dialogruta i Anteckningar
Ăppning av fil i VSI-Notepad [Ctrl+O]
CPU, RAM och I/O
ZHC*
Â
Tid för skapande av zip-fil med hög komprimering
Komprimering av en lokal
slumptalsfil i .pst-format med en storlek pÄ 5 MB, som Àr kopierad frÄn
resurspoolen
ZLC*
CPU och I/O
Tid för skapande av zip-fil med lÄg komprimering
I/O
slumptalsfil i .pst-format med en storlek pÄ 5 MB, som Àr kopierad frÄn
resurspoolen
ZLC*
BerÀkning av en stor
Â
CPU
matris av slumpmÀssiga data
Skapande av en stor matris
slumptalsdata som ska anvÀndas i en I/O-timer
Vid testning berÀknas först basmÀtningen VSIbase, som visar hastigheten för uppgifter utan belastning pÄ systemet. Baserat pÄ detta bestÀms VSImax-tröskeln, som Àr lika med VSIbase + 1 000 ms.
CPU
Slutsatser om systemets prestanda görs baserat pÄ tvÄ mÀtpunkter: VSIbase, som definierar systemets hastighet, och VSImax-tröskeln, som definierar det maximala antalet anvÀndare som systemet tÄl utan betydande nedgradering.
300 Knowledge workers benchmark
Knowledge workers Àr anvÀndare som regelbundet belastar minnet, CPU och I/O med olika smÄ toppar. Programvaran simulerar belastning frÄn krÀvande kontorsanvÀndare, som om de stÀndigt trycker pÄ nÄgot (PDF, Java, kontorsprogram, bildvisning, 7-Zip). NÀr anvÀndare lÀggs till frÄn noll till 300 ökar varje försening gradvis.
Data frÄn VSImax-statistik:
VSIbase = 986 ms, VSI-tröskeln har inte uppnÄtts.
Statistik över belastning pÄ lagringssystemet frÄn SimpliVity-övervakning:
Lastbilbelastningsstatistik frÄn SimpliVity-övervakningen:
Vid denna typ av belastning klarar systemet av att öka belastningen nÀstan utan nÄgon nedgÄng i prestanda. AnvÀndartiden vÀxer stadigt, och systemets svarstid förÀndras inte under testningen och ligger pÄ upp till 3 ms för skrivning och upp till 1 ms för lÀsning.
Slutsats: 300 kunskapsanvÀndare arbetar utan problem i den aktuella klustret och stör inte varandra, vilket uppnÄr en överskrivning av pCPU/vCPU 1 till 6. De totala fördröjningarna ökar jÀmnt med ökad belastning, men den uppsatta grÀnsen har inte nÄtts.
300 lagringsarbetare benchmark
Detta Àr anvÀndare som stÀndigt skriver och lÀser i förhÄllandet 30 till 70. Detta test genomfördes mer som ett experiment. Statistikdata frÄn VSImax:
VSIbase = 1673, VSI-grÀns nÄdd vid 240 anvÀndare.
Lastbilbelastningsstatistik frÄn SimpliVity-övervakningen:
Denna typ av belastning Àr i grunden ett stresstest av lagringssystemet. Under detta test skriver varje anvÀndare en mÀngd slumpmÀssiga filer av olika storlekar pÄ disken. HÀr kan vi se att nÀr belastningen överskrider ett visst tröskelvÀrde ökar tiden för att utföra skrivuppgifter för en del av anvÀndarna. Samtidigt förÀndras belastningen pÄ lagringssystemet, processor och minne pÄ vÀrdarna inte mÀrkbart, sÄ det gÄr för nÀrvarande inte att exakt faststÀlla vad som orsakar fördröjningarna.
Slutsatser om systemets prestanda frĂ„n detta test kan endast göras i jĂ€mförelse med resultaten frĂ„n tester pĂ„ andra system, eftersom sĂ„dana belastningar Ă€r syntetiska och orealistiska. ĂndĂ„ klarade sig testet överlag ganska bra. Fram till 210 sessioner gick allt bra, och sedan började oförklarliga svar, som för övrigt inte rapporterades nĂ„gonstans utom i Login VSI.
300 kraftanvÀndare
Detta Àr anvÀndare som Àlskar processor, minne och hög IO. Dessa "avancerade anvÀndare" kör regelbundet komplexa uppgifter med lÄnga toppar, sÄsom installation av ny programvara och uppackning av stora arkiv. Statistikdata frÄn VSImax:
VSIbase = 970, VSI-grÀns nÄdd har inte uppnÄtts.
Lastbilbelastningsstatistik frÄn SimpliVity-övervakningen:
Under testningen nÄddes belastningströskeln för processorer pÄ en av systemets noder, men detta hade ingen betydande inverkan pÄ dess drift:
I det hÀr fallet klarar systemet av ökad belastning utan att prestandan försÀmras avsevÀrt. Tiden för anvÀndaruppgifter ökar gradvis, och systemets svarstid förblir konstant under testning och ligger pÄ upp till 3 ms för skrivning och upp till 1 ms för lÀsning.
De vanliga testerna var inte tillrÀckliga för kunden, sÄ vi gick vidare: vi ökade VM:ns specifikationer (antal vCPU för att bedöma ökad överskridning och storleken pÄ disken) och lade till en extrabelastning.
Vid genomförandet av de ytterligare testerna anvÀndes följande konfiguration av testmiljön:
300 virtuella skrivbord distribuerades med konfigurationen 4vCPU, 4GB RAM, 80GB HDD.
Konfigurationen av en av testmaskinerna:
Maskinerna distribuerades i Dedicated â Full Copy-alternativet:
300 Knowledge workers benchmark med överskridning 12
VSIbase = 986 ms, VSI-tröskeln har inte uppnÄtts.
VSIbase = 921 ms, VSI Threshold nÄddes inte.
Lastbilbelastningsstatistik frÄn SimpliVity-övervakningen:
De erhÄllna resultaten motsvarar testningen av den tidigare VM-konfigurationen.
300 Power workers med överskridning 12
VSIbase = 986 ms, VSI-tröskeln har inte uppnÄtts.
VSIbase = 933, VSI Threshold nÄddes inte.
Lastbilbelastningsstatistik frÄn SimpliVity-övervakningen:
Vid denna testning uppnÄddes Àven tröskeln för belastningen pÄ processorerna, men detta pÄverkade inte prestandan avsevÀrt:
De erhÄllna resultaten motsvarar testningen av den tidigare konfigurationen.
Vad hÀnder om vi kör belastningen i 10 timmar?
Nu tittar vi pÄ om det kommer att finnas en "ackumulerande effekt" och vi kör tester under 10 timmar i rad.
LÄnga tester och beskrivning av avsnittet bör fokusera pÄ att vi ville kontrollera om det skulle uppstÄ nÄgra problem med klustret vid lÄngvarig belastning pÄ det.
300 Knowledge workers benchmark + 10 timmar
Ytterligare testning genomfördes av alternativet 300 knowledge workers med fortsatt anvÀndning av anvÀndare under 10 timmar.
VSIbase = 986 ms, VSI-tröskeln har inte uppnÄtts.
VSIbase = 919 ms, VSI Threshold nÄddes inte.
Data frÄn statistiken VSImax Detailed:
Enligt grafen syns det att det under hela testet inte förekommer nÄgon prestandaförsÀmring.
Lastbilbelastningsstatistik frÄn SimpliVity-övervakningen:
Prestandan hos lagringssystemet förblir pÄ samma nivÄ under hela testet.
Ytterligare testning med tillÀgg av syntetisk belastning
Kunden bad om att införa en hög belastning pÄ disken. För att göra detta lades en uppgift till systemlagringen pÄ varje anvÀndares virtuella maskin för att starta en syntetisk belastning pÄ disken vid anvÀndarinloggning. Belastningen tillhandahölls av verktyget fio, som gör det möjligt att styra diskbelastningen efter antal IOPS. En uppgift för att starta en extra belastning pÄ 22 IOPS 70 %/30 % Random Read/Write kördes pÄ varje maskin.
300 kunskapsarbetare benchmark + 22 IOPS per anvÀndare
Vid den initiala testningen upptÀcktes det att fio skapade en betydande extra belastning pÄ CPU:n i de virtuella maskinerna. Detta ledde till en snabb överbelastning av vÀrdar pÄ CPU och pÄverkade systemets prestanda kraftigt.
Belastning pÄ vÀrdarnas CPU:
Fördröjningarna i systemlagringen ökade ocksÄ pÄ ett förutsÀgbart sÀtt:
Bristen pÄ datorkraft blev kritisk vid cirka 240 anvÀndare:
Som en följd av resultaten beslutades det att genomföra testning som belastar CPU mindre.
230 kontorsarbetare benchmark + 22 IOPS per anvÀndare
För att minska belastningen pÄ CPU valdes en typ av belastning för kontorsarbetare, och varje session fick ocksÄ 22 IOPS syntetisk belastning.
Testet begrÀnsades till 230 sessioner för att inte överskrida den maximala belastningen pÄ CPU.
Testet genomfördes med efterföljande anvÀndarbeteende under 10 timmar för att kontrollera systemets stabilitet vid lÄngvarig belastning nÀra det maximala.
VSIbase = 986 ms, VSI-tröskeln har inte uppnÄtts.
VSIbase = 918 ms, VSI-tröskeln nÄddes inte.
Data frÄn statistiken VSImax Detailed:
Enligt grafen syns det att det under hela testet inte förekommer nÄgon prestandaförsÀmring.
Statistikdata om belastningen pÄ CPU:
Vid genomförandet av detta test var belastningen pÄ vÀrdarnas CPU praktiskt taget maximal.
Lastbilbelastningsstatistik frÄn SimpliVity-övervakningen:
Prestandan hos lagringssystemet förblir pÄ samma nivÄ under hela testet.
Belastningen pĂ„ systemlagringen under testet var cirka 6 500 IOPS med en fördelning pĂ„ 60/40 (3 900 IOPS â lĂ€sning, 2 600 IOPS â skrivning), vilket motsvarar cirka 28 IOPS per arbetsstation.
Svarstiden var i genomsnitt 3 ms för skrivning och upp till 1 ms för lÀsning.
Resultat
Vid simulering av verkliga belastningar pÄ HPE SimpliVity-infrastrukturen erhölls resultat som bekrÀftade systemets förmÄga att stödja drift av virtuella skrivbord med minst 300 Full Clone-maskiner pÄ ett par SimpliVity-noder. Under hela testningen höll systemlagringens svarstid en optimal nivÄ.
Vi uppskattar verkligen tillvÀgagÄngssÀttet med lÄnga tester och jÀmförelse av lösningar innan implementering. Vi kan testa prestandan Àven för dina belastningar om du vill. Detta inkluderar Àven andra hyperkonvergerande lösningar. Den nÀmnda kunden avslutar just nu tester pÄ en annan lösning parallellt. Deras nuvarande infrastruktur Àr bara en samling datorer, en domÀn och mjukvara pÄ varje arbetsplats. Att migrera till VDI utan tester Àr sjÀlvklart ganska svÄrt. Specifikt Àr det svÄrt att förstÄ de verkliga möjligheterna hos VDI-farmen utan att migrera riktiga anvÀndare dit. Dessa tester gör det möjligt att snabbt uppskatta de verkliga möjligheterna hos olika system utan att involvera vanliga anvÀndare. DÀrför uppstod denna studie.
Det andra viktiga tillvÀgagÄngssÀttet Àr att kunden omedelbart tog hÀnsyn till rÀtt skalning. HÀr kan man köpa till servrar och lÀgga till en farm, till exempel för 100 anvÀndare, allt Àr förutsÀgbart per anvÀndare. Till exempel, nÀr de behöver lÀgga till ytterligare 300 anvÀndare, vet de att de behöver tvÄ servrar i en redan bestÀmd konfiguration, och inte behöva se över möjligheterna till att uppgradera sin infrastruktur som helhet.
Möjligheterna till federation med HPE SimpliVity Ă€r intressanta. Verksamheten Ă€r geografiskt spridd, sĂ„ det ger mening att sĂ€tta upp en egen VDI-hĂ„rdvara i fjĂ€rrkontoret. I federationen SimpliVity replikerar varje virtuell maskin enligt schema med möjlighet att snabbt göra detta mellan geografiskt avlĂ€gsna kluster utan belastning pĂ„ kanalen â det Ă€r en inbyggd backup av mycket hög kvalitet. Vid replikering av VM mellan platserna utnyttjas kanalen sĂ„ minimalt som möjligt, och detta ger möjligheter att bygga mycket intressanta DR-arkitekturer med en enhetlig styrcentral och mĂ„nga decentraliserade lagringsplatser.
Allt detta tillsammans ger möjlighet att bedöma den ekonomiska sidan vĂ€ldigt detaljerat, och att sĂ€tta kostnaderna för VDI i relation till företagets tillvĂ€xtplaner, samt att förstĂ„ hur snabbt lösningen kommer att betala sig och hur den kommer att fungera. Eftersom varje VDI Ă€r en lösning som i slutĂ€ndan sparar massor av resurser, men som troligen inte har ekonomiskt fördelaktiga möjligheter att bytas ut under 5â7 Ă„rs anvĂ€ndning.
Om du har nÄgra frÄgor som inte Àr avsedda för kommentarer, skriv till mig pÄ mk@croc.ru.
KĂ€lla: habr.com
