Kunden ønsket VDI. Jeg så virkelig på SimpliVity + VDI Citrix Virtual Desktop-kombinasjonen. For alle operatører, ansatte i bykontoret og så videre. Det er fem tusen brukere i den første migrasjonsbølgen alene, og derfor insisterte de på belastningstesting. VDI kan begynne å avta, den kan ligge rolig - og dette skjer ikke alltid på grunn av problemer med kanalen. Vi kjøpte en veldig kraftig testpakke spesielt for VDI og lastet infrastrukturen til den ble for tung på diskene og prosessoren.
Så vi trenger en plastflaske og LoginVSI-programvare for sofistikerte VDI-tester. Vi har den med lisenser for 300 brukere. Så tok vi HPE SimpliVity 380-maskinvare i en pakke egnet for oppgaven med maksimal brukertetthet per server, kuttet opp virtuelle maskiner med godt overabonnement, installerte kontorprogramvare på Win10 på dem og begynte å teste.
La oss gå!
System
To HPE SimpliVity 380 Gen10-noder (servere). På hver:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- RAM: 768 GB, 12 x 64 GB LRDIMM-er DDR4 2666MHz.
- Primær diskkontroller: HPE Smart Array P816i-a SR Gen10.
- Harddisker: 9 x 1.92 TB SATA 6Gb/s SSD (i RAID6 7+2-konfigurasjon, dvs. dette er en medium modell i HPE SimpliVity-termer).
- Nettverkskort: 4 x 1 Gb Eth (brukerdata), 2 x 10 Gb Eth (SimpliVity og vMotion backend).
- Spesielle innebygde FPGA-kort i hver node for deduplisering/komprimering.
Nodene er koblet til hverandre via en 10 Gb Ethernet-forbindelse direkte uten en ekstern svitsj, som brukes som SimpliVity-backend og for overføring av virtuell maskindata via NFS. Virtuelle maskindata i en klynge speiles alltid mellom to noder.
Nodene er kombinert til en Vmware vSphere-klynge administrert av vCenter.
For testing ble en domenekontroller og en Citrix-tilkoblingsmegler distribuert. Domenekontrolleren, megleren og vCenter er plassert på en egen klynge.
Som en testinfrastruktur ble 300 virtuelle skrivebord distribuert i konfigurasjonen Dedikert – Full kopi, det vil si at hvert skrivebord er en komplett kopi av det originale bildet av den virtuelle maskinen og lagrer alle endringer som er gjort av brukere.
Hver virtuell maskin har 2vCPU og 4GB RAM:
Følgende programvare som kreves for testing ble installert på de virtuelle maskinene:
- Windows 10 (64-bit), versjon 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7-oppdatering 13.
- Microsoft Office Professional Plus 2016.
Mellom noder - synkron replikering. Hver datablokk i klyngen har to kopier. Det vil si at nå er det et komplett sett med data på hver av nodene. Med en klynge på tre eller flere noder, er kopier av blokker på to forskjellige steder. Når du oppretter en ny VM, opprettes en ekstra kopi på en av klyngenodene. Når en node feiler, startes alle VM-er som tidligere har kjørt på den automatisk på nytt på andre noder der de har replikaer. Hvis en node svikter i lang tid, begynner gradvis gjenoppretting av redundans, og klyngen går tilbake til N+1 redundans.
Databalansering og lagring skjer på programvarelagringsnivået til SimpliVity selv.
Virtuelle maskiner kjører en virtualiseringsklynge, som også plasserer dem på programvarelagring. Selve pultene ble tatt etter en standard mal: pultene til finansfolk og operasjonsoffiserer kom på prøve (dette er to forskjellige maler).
Testing
For testing ble LoginVSI 4.1-programvaretestpakken brukt. LoginVSI-komplekset, bestående av en kontrollserver og 12 maskiner for testforbindelser, ble utplassert på en egen fysisk vert.
Testingen ble utført i tre moduser:
Benchmark-modus - lasttilfeller 300 Kunnskapsarbeidere og 300 Lagerarbeidere.
Standard modus - lastekasse 300 Strømarbeidere.
For å gjøre det mulig for Power-arbeidere å jobbe og øke belastningsmangfoldet, ble et bibliotek med ytterligere Power Library-filer lagt til LoginVSI-komplekset. For å sikre repeterbarhet av resultatene ble alle testbenkinnstillinger stående som standard.
Knowledge and Power Workers-testene simulerer den reelle arbeidsbelastningen til brukere som jobber på virtuelle arbeidsstasjoner.
Storage workers-testen ble laget spesielt for å teste datalagringssystemer; den er langt fra reelle arbeidsbelastninger og involverer for det meste at brukeren jobber med et stort antall filer i forskjellige størrelser.
Under testing logger brukere på arbeidsstasjoner i 48 minutter med en hastighet på omtrent én bruker hvert 10. sekund.
Funn
Hovedresultatet av LoginVSI-testing er VSImax-metrikken, som er kompilert fra utførelsestiden for forskjellige oppgaver som er lansert av brukeren. For eksempel: tid for å åpne en fil i Notisblokk, tid for å komprimere en fil i 7-Zip, etc.
En detaljert beskrivelse av metrikkberegning er tilgjengelig i den offisielle dokumentasjonen for .
Med andre ord, LoginVSI gjentar et typisk belastningsmønster, simulerer brukerhandlinger i en kontorpakke, leser en PDF og så videre, og måler ulike latenser. Det er et kritisk nivå av forsinkelser "alt bremser ned, det er umulig å fungere"), før det anses at det maksimale antallet brukere ikke er nådd. Hvis responstiden er 1 ms raskere enn denne tilstanden "alt er sakte", anses systemet for å fungere normalt, og flere brukere kan legges til.
Her er hovedberegningene:
Beregninger
Handlinger tatt
Detaljert описание
Lastede komponenter
N.S.L.D.
Tekst åpningstid
fil som veier 1 KB
Notisblokk åpnes og
åpner et tilfeldig dokument på 1 KB som kopieres fra bassenget
ressurser
CPU og I/O
NFO
Dialogåpningstid
vinduer i notisblokk
Åpne en VSI-Notepad-fil [Ctrl+O]
CPU, RAM og I/O
ZHC*
På tide å lage en svært komprimert zip-fil
Lokal kompresjon
tilfeldig 5MB .pst-fil kopiert fra
ressurspool
CPU og I/O
ZLC*
På tide å lage en svakt komprimert zip-fil
Lokal kompresjon
tilfeldig 5MB .pst-fil kopiert fra
ressurspool
I / O
prosessor
Regner stort
tilfeldig datamatrise
Opprette et stort utvalg
tilfeldige data som vil bli brukt i input/output timer (I/O timer)
prosessor
Når testing utføres, beregnes den grunnleggende VSIbase-metrikken i utgangspunktet, som viser hastigheten jobbene utføres med uten belastning på systemet. Basert på den bestemmes VSImax Threshold, som er lik VSIbase + 1ms.
Konklusjoner om systemytelse er laget basert på to beregninger: VSIbase, som bestemmer hastigheten til systemet, og VSImax-terskel, som bestemmer det maksimale antallet brukere som systemet kan håndtere uten vesentlig forringelse.
300 Kunnskapsarbeidere benchmark
Kunnskapsarbeidere er brukere som jevnlig laster inn minne, prosessor og IO med ulike små topper. Programvaren emulerer arbeidsmengden til krevende kontorbrukere, som om de hele tiden pirket i noe (PDF, Java, kontorpakke, bildevisning, 7-Zip). Når du legger til brukere fra null til 300, øker forsinkelsen for hver enkelt gradvis.
VSImax statistikkdata:
VSIbase = 986ms, VSI-terskelen ble ikke nådd.
Lastestatistikk for lagringssystem fra SimpliVity-overvåking:
Med denne typen belastning kan systemet tåle økt belastning med praktisk talt ingen forringelse av ytelsen. Tiden det tar å fullføre brukeroppgaver øker jevnt, systemets responstid endres ikke under testing og er opptil 3 ms for skriving og opptil 1 ms for lesing.
Konklusjon: 300 kunnskapsbrukere jobber på den nåværende klyngen uten problemer og forstyrrer ikke hverandre, og når pCPU/vCPU overabonnement på 1 til 6. De totale forsinkelsene vokser jevnt etter hvert som belastningen øker, men den fastsatte grensen er ikke nådd.
300 lagerarbeidere benchmark
Dette er brukere som hele tiden skriver og leser i et forhold på henholdsvis 30 til 70. Denne testen ble utført mer for eksperimentets skyld. VSImax statistikkdata:
VSIbase = 1673, VSI-terskel nådd på 240 brukere.
Lastestatistikk for lagringssystem fra SimpliVity-overvåking:
Denne typen last er i hovedsak en stresstest av lagringssystemet. Når den utføres, skriver hver bruker mange tilfeldige filer av forskjellige størrelser til disken. I dette tilfellet kan det ses at når en viss belastningsterskel overskrides for noen brukere, øker tiden det tar å fullføre oppgaver for å skrive filer. Samtidig endres ikke belastningen på lagringssystemet, prosessoren og minnet til vertene nevneverdig, så det er foreløpig umulig å fastslå nøyaktig hva som forårsaker forsinkelsene.
Konklusjoner om systemytelse ved bruk av denne testen kan kun gjøres i sammenligning med testresultater på andre systemer, siden slike belastninger er syntetiske og urealistiske. Men totalt sett gikk testen bra. Alt gikk bra frem til 210 økter, og så begynte merkelige svar, som ikke ble sporet andre steder enn Login VSI.
300 kraftarbeidere
Dette er brukere som elsker CPU, minne og høy IO. Disse "kraftbrukerne" kjører regelmessig komplekse oppgaver med lange serier, som å installere ny programvare og pakke ut store arkiver. VSImax statistikkdata:
VSIbase = 970, VSI-terskel ble ikke nådd.
Lastestatistikk for lagringssystem fra SimpliVity-overvåking:
Under testing ble prosessorbelastningsterskelen nådd på en av systemnodene, men dette hadde ingen betydelig innvirkning på driften:
I dette tilfellet tåler systemet økt belastning uten vesentlig forringelse av ytelsen. Tiden det tar å fullføre brukeroppgaver øker jevnt, systemets responstid endres ikke under testing og er opptil 3 ms for skriving og opptil 1 ms for lesing.
Regelmessige tester var ikke nok for kunden, og vi gikk lenger: vi økte VM-karakteristikkene (antall vCPUer for å evaluere økningen i overabonnement og diskstørrelse) og la til ekstra belastning.
Ved utførelse av ytterligere tester ble følgende stativkonfigurasjon brukt:
300 virtuelle skrivebord ble distribuert i en 4vCPU, 4GB RAM, 80GB HDD-konfigurasjon.
Konfigurasjon av en av testmaskinene:
Maskinene er distribuert i alternativet Dedikert – Full kopi:
300 kunnskapsarbeidere benchmark med overtegning 12
VSImax statistikkdata:
VSIbase = 921 ms, VSI-terskelen ble ikke nådd.
Lastestatistikk for lagringssystem fra SimpliVity-overvåking:
Resultatene som er oppnådd ligner på å teste den forrige VM-konfigurasjonen.
300 kraftarbeidere med 12 overabonnement
VSImax statistikkdata:
VSIbase = 933, VSI-terskel ble ikke nådd.
Lastestatistikk for lagringssystem fra SimpliVity-overvåking:
Under denne testingen ble også prosessorbelastningsterskelen nådd, men dette hadde ingen signifikant innvirkning på ytelsen:
Resultatene som er oppnådd ligner på å teste den forrige konfigurasjonen.
Hva skjer hvis du kjører belastningen i 10 timer?
La oss nå se om det vil være en "akkumuleringseffekt" og kjøre tester i 10 timer på rad.
Langtidstestene og beskrivelsen av seksjonen skulle ta sikte på at vi ønsket å sjekke om det ville oppstå problemer med fagverket under langvarig belastning på det.
300 Kunnskapsarbeidere benchmark + 10 timer
I tillegg ble en belastningstilfelle på 300 kunnskapsarbeidere testet, etterfulgt av brukerarbeid i 10 timer.
VSImax statistikkdata:
VSIbase = 919 ms, VSI-terskelen ble ikke nådd.
VSImax Detaljert statistikkdata:
Grafen viser at det ikke er observert ytelsesforringelse gjennom hele testen.
Lastestatistikk for lagringssystem fra SimpliVity-overvåking:
Lagringssystemets ytelse forblir den samme gjennom hele testen.
Ytterligere testing med tillegg av syntetisk belastning
Kunden ba om å legge til en vill belastning på disken. For å gjøre dette ble en oppgave lagt til lagringssystemet i hver av brukerens virtuelle maskiner for å kjøre en syntetisk belastning på disken når brukeren logger på systemet. Lasten ble levert av fio-verktøyet, som lar deg begrense belastningen på disken med antall IOPS. I hver maskin ble det lansert en oppgave for å starte en ekstra belastning i mengden 22 IOPS 70%/30% Random Read/Write.
300 kunnskapsarbeidere benchmark + 22 IOPS per bruker
I innledende testing ble fio funnet å pålegge virtuelle maskiner betydelig CPU-overhead. Dette førte til rask CPU-overbelastning av vertene og påvirket i stor grad driften av systemet som helhet.
Verts CPU-belastning:
Samtidig økte forsinkelser i lagringssystem naturlig nok:
Mangelen på datakraft ble kritisk rundt 240 brukere:
På grunn av resultatene som ble oppnådd, ble det besluttet å gjennomføre tester som var mindre CPU-intensive.
230 kontorarbeidere benchmark + 22 IOPS per bruker
For å redusere belastningen på CPU-en ble belastningstypen for kontorarbeidere valgt, og 22 IOPS syntetisk belastning ble også lagt til hver økt.
Testen var begrenset til 230 økter for ikke å overskride maksimal CPU-belastning.
Testen ble kjørt med brukere som kjørte i 10 timer for å sjekke stabiliteten til systemet under langtidsdrift ved nær maksimal belastning.
VSImax statistikkdata:
VSIbase = 918 ms, VSI-terskelen ble ikke nådd.
VSImax Detaljert statistikkdata:
Grafen viser at det ikke er observert ytelsesforringelse gjennom hele testen.
CPU-belastningsstatistikk:
Når du utførte denne testen, var belastningen på vertens CPU nesten maksimal.
Lastestatistikk for lagringssystem fra SimpliVity-overvåking:
Lagringssystemets ytelse forblir den samme gjennom hele testen.
Belastningen på lagringssystemet under testen var ca. 6 IOPS i et 500/60-forhold (40 IOPS-lesing, 3 IOPS-skriving), som er ca. 900 IOPS per arbeidsstasjon.
Responstiden var i gjennomsnitt 3 ms for skriving og opptil 1 ms for lesing.
Total
Ved simulering av reelle belastninger på HPE SimpliVity-infrastrukturen ble det oppnådd resultater som bekrefter systemets evne til å støtte virtuelle skrivebord på minst 300 Full Clone-maskiner på et par SimpliVity-noder. Samtidig ble responstiden til lagringssystemet holdt på et optimalt nivå gjennom hele testingen.
Vi er veldig imponert over tilnærmingen til lange tester og sammenligning av løsninger før implementering. Vi kan teste ytelsen for arbeidsbelastningene dine også hvis du ønsker det. Inkludert andre hyperkonvergerte løsninger. Nevnte kunde avslutter nå tester på en annen løsning parallelt. Den nåværende infrastrukturen er ganske enkelt en flåte av PC-er, et domene og programvare på hver arbeidsplass. Å gå over til VDI uten tester er selvfølgelig ganske vanskelig. Spesifikt er det vanskelig å forstå de virkelige egenskapene til en VDI-farm uten å migrere ekte brukere til den. Og disse testene lar deg raskt evaluere de virkelige egenskapene til et bestemt system uten å måtte involvere vanlige brukere. Det er her denne studien kom fra.
Den andre viktige tilnærmingen er at kunden umiddelbart forplikter seg til riktig skalering. Her kan du kjøpe en ekstra server og legge til en farm, for eksempel for 100 brukere, alt er forutsigbart til brukerpris. For eksempel, når de trenger å legge til 300 flere brukere, vil de vite at de trenger to servere i en allerede definert konfigurasjon, i stedet for å revurdere å oppgradere hele infrastrukturen.
Mulighetene til HPE SimpliVity-forbundet er interessante. Virksomheten er geografisk adskilt, så det er fornuftig å installere din egen separate VDI-maskinvare på et fjerntliggende kontor. I SimpliVity-forbundet replikeres hver virtuell maskin i henhold til en tidsplan med mulighet til å replikere mellom geografisk fjerne klynger svært raskt og uten belastning på kanalen – dette er en innebygd sikkerhetskopi av et meget godt nivå. Når du replikerer VM-er mellom nettsteder, brukes kanalen så minimalt som mulig, og dette gjør det mulig å bygge svært interessante DR-arkitekturer i nærvær av et enkelt kontrollsenter og en haug med desentraliserte lagringssteder.
Alt dette til sammen gjør det mulig å evaluere den økonomiske siden i detalj, og legge kostnadene til VDI over selskapets vekstplaner, og å forstå hvor raskt løsningen vil lønne seg og hvordan den vil fungere. Fordi enhver VDI er en løsning som til syvende og sist sparer mye ressurser, men samtidig, mest sannsynlig, uten den kostnadseffektive muligheten til å endre den innen 5-7 års bruk.
Generelt, hvis du har spørsmål som ikke er for kommentar, skriv til meg på e-post [e-postbeskyttet].
Kilde: www.habr.com