Kunden ville ha VDI. Jag tittade verkligen på kombinationen SimpliVity + VDI Citrix Virtual Desktop. För alla operatörer, stadskontorsanställda och så vidare. Det finns fem tusen användare enbart i den första migrationsvågen, och därför insisterade de på belastningstestning. VDI kan börja sakta ner, den kan lugnt ligga ner - och det händer inte alltid på grund av problem med kanalen. Vi köpte ett mycket kraftfullt testpaket specifikt för VDI och laddade infrastrukturen tills det blev för tungt på diskarna och processorn.
Så vi kommer att behöva en plastflaska och LoginVSI-mjukvara för sofistikerade VDI-tester. Vi har den med licenser för 300 användare. Sedan tog vi HPE SimpliVity 380-hårdvara i ett paket som lämpar sig för uppgiften med maximal användardensitet per server, skar upp virtuella maskiner med bra överabonnemang, installerade kontorsprogram på Win10 på dem och började testa.
Låt oss gå!
System
Två HPE SimpliVity 380 Gen10-noder (servrar). På varje:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- RAM: 768 GB, 12 x 64 GB LRDIMM DDR4 2666MHz.
- Primär diskkontroller: HPE Smart Array P816i-a SR Gen10.
- Hårddiskar: 9 x 1.92 TB SATA 6 Gb/s SSD (i RAID6 7+2-konfiguration, dvs. detta är en mediummodell i HPE SimpliVity-termer).
- Nätverkskort: 4 x 1 Gb Eth (användardata), 2 x 10 Gb Eth (SimpliVity och vMotion backend).
- Särskilda inbyggda FPGA-kort i varje nod för deduplicering/komprimering.
Noderna är anslutna till varandra via en 10 Gb Ethernet-interconnect direkt utan en extern switch, som används som SimpliVity-backend och för överföring av virtuell maskindata via NFS. Virtuell maskindata i ett kluster speglas alltid mellan två noder.
Noderna kombineras till ett Vmware vSphere-kluster som hanteras av vCenter.
För testning användes en domänkontrollant och en Citrix-anslutningsmäklare. Domänkontrollanten, mäklaren och vCenter placeras på ett separat kluster.
Som en testinfrastruktur distribuerades 300 virtuella skrivbord i Dedicated – Full Copy-konfigurationen, det vill säga varje skrivbord är en komplett kopia av den ursprungliga bilden av den virtuella maskinen och sparar alla ändringar som görs av användare.
Varje virtuell maskin har 2vCPU och 4GB RAM:
Följande programvara som krävs för testning installerades på de virtuella datorerna:
- Windows 10 (64-bitars), version 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7-uppdatering 13.
- Microsoft Office Professional Plus 2016.
Mellan noder - synkron replikering. Varje datablock i klustret har två kopior. Det vill säga, nu finns det en komplett uppsättning data på var och en av noderna. Med ett kluster av tre eller fler noder finns kopior av block på två olika platser. När du skapar en ny virtuell dator skapas ytterligare en kopia på en av klusternoderna. När en nod misslyckas, startas alla virtuella datorer som tidigare körts på den automatiskt om på andra noder där de har repliker. Om en nod misslyckas under en lång tid, börjar gradvis återställning av redundans, och klustret återgår till N+1 redundans.
Databalansering och lagring sker på mjukvarulagringsnivån för SimpliVity själv.
Virtuella maskiner kör ett virtualiseringskluster, som också placerar dem på programvarulagring. Själva skrivborden togs enligt en standardmall: finansiärers och operationsofficers skrivbord kom för testet (detta är två olika mallar).
testning
För testning användes LoginVSI 4.1 mjukvarutestsviten. LoginVSI-komplexet, bestående av en kontrollserver och 12 maskiner för testanslutningar, distribuerades på en separat fysisk värd.
Testning utfördes i tre lägen:
Benchmark-läge - lastfall 300 kunskapsarbetare och 300 lagerarbetare.
Standardläge - lastfall 300 kraftarbetare.
För att göra det möjligt för Power-arbetare att arbeta och öka belastningsdiversiteten lades ett bibliotek med ytterligare Power Library-filer till LoginVSI-komplexet. För att säkerställa repeterbarhet av resultaten lämnades alla testbänksinställningar som standard.
Knowledge and Power Workers-testen simulerar den verkliga arbetsbelastningen för användare som arbetar på virtuella arbetsstationer.
Storage workers-testet skapades specifikt för att testa datalagringssystem, det är långt ifrån riktiga arbetsbelastningar och innebär oftast att användaren arbetar med ett stort antal filer av olika storlekar.
Under testning loggar användare in på arbetsstationer i 48 minuter med en hastighet av ungefär en användare var 10:e sekund.
Resultat
Huvudresultatet av LoginVSI-testning är VSImax-måttet, som sammanställs från exekveringstiden för olika uppgifter som startats av användaren. Till exempel: dags att öppna en fil i Anteckningar, dags att komprimera en fil i 7-Zip, etc.
En detaljerad beskrivning av metrikberäkning finns i den officiella dokumentationen för .
Med andra ord, LoginVSI upprepar ett typiskt belastningsmönster, simulerar användaråtgärder i en kontorssvit, läser en PDF och så vidare, och mäter olika latenser. Det finns en kritisk nivå av förseningar "allt saktar ner, det är omöjligt att fungera"), innan det anses att det maximala antalet användare inte har nåtts. Om svarstiden är 1 000 ms snabbare än detta tillstånd "allt är långsamt", anses systemet fungera normalt och fler användare kan läggas till.
Här är huvudmåtten:
Metrik
Vidtagna åtgärder
detaljerade описание
Laddade komponenter
N.S.L.D.
Sms:s öppningstid
fil som väger 1 500 KB
Anteckningsblock öppnas och
öppnar ett slumpmässigt dokument på 1 500 KB som kopieras från poolen
Resurser
CPU och I/O
NFO
Öppettid för dialog
fönster i anteckningsblock
Öppna en VSI-Anteckningsbok-fil [Ctrl+O]
CPU, RAM och I/O
ZHC*
Dags att skapa en mycket komprimerad zip-fil
Lokal komprimering
slumpmässig 5MB .pst-fil kopierad från
resurspool
CPU och I/O
ZLC*
Dags att skapa en svagt komprimerad zip-fil
Lokal komprimering
slumpmässig 5MB .pst-fil kopierad från
resurspool
I / O
CPU
Räknar stort
slumpmässig datamatris
Skapa en stor array
slumpmässiga data som kommer att användas i in-/utgångstimern (I/O-timer)
CPU
När testning utförs beräknas initialt VSIbase-måttet, som visar den hastighet med vilken jobb utförs utan belastning på systemet. Baserat på det bestäms VSImax Threshold, vilket är lika med VSIbase + 1 000 ms.
Slutsatser om systemprestanda görs baserat på två mått: VSIbase, som bestämmer hastigheten på systemet, och VSImax-tröskeln, som bestämmer det maximala antalet användare som systemet kan hantera utan betydande försämring.
Benchmark för 300 kunskapsarbetare
Kunskapsarbetare är användare som regelbundet laddar minne, processor och IO med olika små toppar. Programvaran emulerar arbetsbelastningen för krävande kontorsanvändare, som om de ständigt petade på något (PDF, Java, kontorspaket, fotovisning, 7-Zip). När du lägger till användare från noll till 300, ökar fördröjningen för var och en gradvis.
VSImax statistikdata:
VSIbase = 986ms, VSI-tröskeln nåddes inte.
Laddningsstatistik för lagringssystem från SimpliVity-övervakning:
Med denna typ av belastning kan systemet motstå ökad belastning med praktiskt taget ingen försämring av prestanda. Tiden det tar att slutföra användaruppgifter ökar smidigt, systemets svarstid ändras inte under testning och är upp till 3 ms för skrivning och upp till 1 ms för läsning.
Slutsats: 300 kunskapsanvändare arbetar på det aktuella klustret utan problem och stör inte varandra och når pCPU/vCPU-överabonnemang på 1 till 6. De totala förseningarna växer jämnt när belastningen ökar, men den angivna gränsen har inte uppnåtts.
Benchmark för 300 lagerarbetare
Det är användare som ständigt skriver och läser i förhållandet 30 till 70 respektive. Detta test utfördes mer för experimentets skull. VSImax statistikdata:
VSIbase = 1673, VSI-tröskeln nådd på 240 användare.
Laddningsstatistik för lagringssystem från SimpliVity-övervakning:
Denna typ av belastning är i huvudsak ett stresstest av lagringssystemet. När det körs skriver varje användare många slumpmässiga filer av olika storlekar till disken. I det här fallet kan man se att när en viss belastningströskel överskrids för vissa användare, ökar tiden det tar att slutföra uppgifter för att skriva filer. Samtidigt förändras inte belastningen på lagringssystemet, processorn och minnet hos värdarna nämnvärt, så det är för närvarande omöjligt att avgöra exakt vad som orsakar förseningarna.
Slutsatser om systemprestanda med detta test kan endast dras i jämförelse med testresultat på andra system, eftersom sådana belastningar är syntetiska och orealistiska. Men på det hela taget gick testet bra. Allt gick bra fram till 210 sessioner, och sedan började konstiga svar, som inte spårades någonstans förutom Login VSI.
300 kraftarbetare
Det här är användare som älskar CPU, minne och hög IO. Dessa "power users" kör regelbundet komplexa uppgifter med långa skurar, som att installera ny programvara och packa upp stora arkiv. VSImax statistikdata:
VSIbase = 970, VSI-tröskeln nåddes inte.
Laddningsstatistik för lagringssystem från SimpliVity-övervakning:
Under testningen nåddes processorbelastningströskeln på en av systemnoderna, men detta hade ingen betydande inverkan på dess funktion:
I detta fall kan systemet motstå ökad belastning utan betydande prestandaförsämring. Tiden det tar att slutföra användaruppgifter ökar smidigt, systemets svarstid ändras inte under testning och är upp till 3 ms för skrivning och upp till 1 ms för läsning.
Regelbundna tester var inte tillräckligt för kunden, och vi gick längre: vi ökade VM-egenskaperna (antal vCPU:er för att utvärdera ökningen av överabonnemang och diskstorlek) och lade till ytterligare belastning.
Vid ytterligare tester användes följande stativkonfiguration:
300 virtuella skrivbord distribuerades i en 4vCPU, 4GB RAM, 80GB HDD-konfiguration.
Konfiguration av en av testmaskinerna:
Maskinerna distribueras i alternativet Dedikerad – Fullständig kopia:
Benchmark för 300 kunskapsarbetare med överteckning 12
VSImax statistikdata:
VSIbase = 921 ms, VSI-tröskeln nåddes inte.
Laddningsstatistik för lagringssystem från SimpliVity-övervakning:
De erhållna resultaten liknar att testa den tidigare VM-konfigurationen.
300 kraftarbetare med 12 överabonnemang
VSImax statistikdata:
VSIbase = 933, VSI-tröskeln nåddes inte.
Laddningsstatistik för lagringssystem från SimpliVity-övervakning:
Under denna testning nåddes också processorbelastningströskeln, men detta hade ingen betydande inverkan på prestandan:
De erhållna resultaten liknar att testa den tidigare konfigurationen.
Vad händer om du kör belastningen i 10 timmar?
Låt oss nu se om det blir en "ackumuleringseffekt" och kör tester i 10 timmar i rad.
Långtidstesterna och beskrivningen av sektionen ska syfta till att vi ville kontrollera om det skulle uppstå några problem med fackverket under långvarig belastning på den.
300 Kunskapsarbetare benchmark + 10 timmar
Dessutom testades ett belastningsfall på 300 kunskapsarbetare, följt av användararbete under 10 timmar.
VSImax statistikdata:
VSIbase = 919 ms, VSI-tröskeln nåddes inte.
VSImax Detaljerad statistikdata:
Grafen visar att det inte har observerats någon prestandaförsämring under hela testet.
Laddningsstatistik för lagringssystem från SimpliVity-övervakning:
Lagringssystemets prestanda förblir densamma under hela testet.
Ytterligare testning med tillägg av syntetisk belastning
Kunden bad om att lägga till en vild laddning till disken. För att göra detta lades en uppgift till lagringssystemet i var och en av användarens virtuella maskiner för att köra en syntetisk belastning på disken när användaren loggar in i systemet. Belastningen tillhandahölls av fio-verktyget, som låter dig begränsa belastningen på disken med antalet IOPS. I varje maskin lanserades en uppgift för att starta en extra laddning i mängden 22 IOPS 70%/30% Random Read/Write.
Benchmark för 300 kunskapsarbetare + 22 IOPS per användare
I de första testerna visade sig fio lägga på betydande CPU-overhead på virtuella maskiner. Detta ledde till snabb CPU-överbelastning av värdarna och påverkade i hög grad driften av systemet som helhet.
Värd CPU-belastning:
Samtidigt ökade lagringssystemens förseningar naturligtvis också:
Bristen på datorkraft blev kritisk runt 240 användare:
På grund av de erhållna resultaten beslutades det att utföra tester som var mindre CPU-intensiva.
230 kontorsanställda benchmark + 22 IOPS per användare
För att minska belastningen på CPU:n valdes belastningstypen för Office-arbetare, och 22 IOPS syntetisk belastning lades också till varje session.
Testet var begränsat till 230 sessioner för att inte överskrida den maximala CPU-belastningen.
Testet kördes med användare som körde i 10 timmar för att kontrollera systemets stabilitet under långvarig drift med nära maximal belastning.
VSImax statistikdata:
VSIbase = 918 ms, VSI-tröskeln nåddes inte.
VSImax Detaljerad statistikdata:
Grafen visar att det inte har observerats någon prestandaförsämring under hela testet.
CPU-belastningsstatistik:
När detta test utfördes var belastningen på värdarnas CPU nästan maximal.
Laddningsstatistik för lagringssystem från SimpliVity-övervakning:
Lagringssystemets prestanda förblir densamma under hela testet.
Belastningen på lagringssystemet under testet var cirka 6 500 IOPS i förhållandet 60/40 (3 900 IOPS läsning, 2 600 IOPS skrivning), vilket är cirka 28 IOPS per arbetsstation.
Svarstiden var i genomsnitt 3 ms för skrivning och upp till 1 ms för läsning.
Totalt
Vid simulering av verkliga belastningar på HPE SimpliVity-infrastrukturen erhölls resultat som bekräftar systemets förmåga att stödja virtuella skrivbord på minst 300 Full Clone-maskiner på ett par SimpliVity-noder. Samtidigt hölls responstiden för lagringssystemet på en optimal nivå under hela testningen.
Vi är mycket imponerade av tillvägagångssättet med långa tester och jämförelse av lösningar innan implementering. Vi kan testa prestanda för dina arbetsbelastningar också om du vill. Inklusive andra hyperkonvergerade lösningar. Nämnda kund avslutar nu tester på en annan lösning parallellt. Dess nuvarande infrastruktur är helt enkelt en flotta av datorer, en domän och programvara på varje arbetsplats. Att gå över till VDI utan tester är förstås ganska svårt. Specifikt är det svårt att förstå den verkliga kapaciteten hos en VDI-farm utan att migrera riktiga användare till den. Och dessa tester låter dig snabbt utvärdera de verkliga funktionerna hos ett visst system utan att behöva involvera vanliga användare. Det är härifrån denna studie kom.
Det andra viktiga tillvägagångssättet är att kunden omedelbart engagerar sig för korrekt skalning. Här kan du köpa en extra server och lägga till en farm, till exempel för 100 användare, allt är förutsägbart till användarpriset. Till exempel, när de behöver lägga till 300 fler användare kommer de att veta att de behöver två servrar i en redan definierad konfiguration, snarare än att ompröva att uppgradera hela sin infrastruktur.
Möjligheterna med HPE SimpliVity-federationen är intressanta. Verksamheten är geografiskt åtskild, så det är vettigt att installera din egen separata VDI-hårdvara på ett avlägset kontor. I SimpliVity-federationen replikeras varje virtuell maskin enligt ett schema med möjlighet att replikera mellan geografiskt avlägsna kluster mycket snabbt och utan belastning på kanalen – detta är en inbyggd backup på en mycket bra nivå. Vid replikering av virtuella datorer mellan sajter används kanalen så minimalt som möjligt, och detta gör det möjligt att bygga mycket intressanta DR-arkitekturer i närvaro av ett enda kontrollcenter och ett gäng decentraliserade lagringsplatser.
Allt detta tillsammans gör det möjligt att utvärdera den finansiella sidan i detalj, och att lägga kostnaderna för VDI på företagets tillväxtplaner, och att förstå hur snabbt lösningen kommer att löna sig och hur den kommer att fungera. Eftersom vilken VDI som helst är en lösning som i slutändan sparar mycket resurser, men samtidigt, med största sannolikhet, utan den kostnadseffektiva möjligheten att ändra den inom 5-7 års användning.
I allmänhet, om du har några frågor som inte är för kommentarer, skriv till mig via e-post [e-postskyddad].
Källa: will.com