Vi fortsætter med at introducere dig til Cisco HyperFlex hyperkonvergeret system.
I april 2019 gennemfører Cisco igen en række demonstrationer af den nye hyperkonvergerede løsning Cisco HyperFlex i regionerne Rusland og Kasakhstan. Du kan tilmelde dig en demonstration ved at bruge feedbackformularen ved at følge linket. Kom med os!
Vi har tidligere publiceret en artikel om belastningstest udført af det uafhængige ESG Lab i 2017. I 2018 er ydeevnen af Cisco HyperFlex-løsningen (version HX 3.0) blevet væsentligt forbedret. Derudover forbedres konkurrencedygtige løsninger også. Derfor udgiver vi en ny, nyere version af ESGs stressbenchmarks.
I sommeren 2018 gensammenlignede ESG-laboratoriet Cisco HyperFlex med sine konkurrenter. Under hensyntagen til den moderne trend med at bruge softwaredefinerede løsninger blev producenter af lignende platforme også tilføjet til den sammenlignende analyse.
Test konfigurationer
Som en del af testen blev HyperFlex sammenlignet med to fuldt software-hyperkonvergerede systemer, der er installeret på standard x86-servere, samt med én software- og hardwareløsning. Test blev udført ved hjælp af standardsoftware til hyperkonvergerede systemer - HCIBench, som bruger Oracle Vdbench-værktøjet og automatiserer testprocessen. Især opretter HCIBench automatisk virtuelle maskiner, koordinerer belastningen mellem dem og genererer praktiske og forståelige rapporter.
140 virtuelle maskiner blev oprettet pr. klynge (35 pr. klynge node). Hver virtuel maskine brugte 4 vCPU'er, 4 GB RAM. Den lokale VM-disk var 16 GB, og den ekstra disk var 40 GB.
Følgende klyngekonfigurationer deltog i testen:
- klynge af fire Cisco HyperFlex 220C-noder 1 x 400 GB SSD til cache og 6 x 1.2 TB SAS HDD til data;
- konkurrent Leverandør En klynge af fire noder 2 x 400 GB SSD til cache og 4 x 1 TB SATA HDD til data;
- konkurrent Vendor B-klynge med fire noder 2 x 400 GB SSD til cache og 12 x 1.2 TB SAS HDD til data;
- konkurrent Vendor C-klynge af fire noder 4 x 480 GB SSD til cache og 12 x 900 GB SAS HDD til data.
Processorerne og RAM i alle løsninger var identiske.
Test for antallet af virtuelle maskiner
Testning begyndte med en arbejdsbelastning designet til at efterligne en standard OLTP-test: læse/skrive (RW) 70%/30%, 100% FullRandom med et mål på 800 IOPS pr. virtuel maskine (VM). Testen blev udført på 140 VM'er i hver klynge i tre til fire timer. Målet med testen er at holde skriveforsinkelser på så mange VM'er som muligt på 5 millisekunder eller lavere.
Som et resultat af testen (se grafen nedenfor), var HyperFlex den eneste platform, der gennemførte denne test med de første 140 VM'er og med latenser under 5 ms (4,95 ms). For hver af de andre klynger blev testen genstartet for eksperimentelt at justere antallet af VM'er til mållatenstiden på 5 ms over flere iterationer.
Leverandør A håndterede med succes 70 VM'er med en gennemsnitlig responstid på 4,65 ms.
Leverandør B opnåede den påkrævede latenstid på 5,37 ms. kun med 36 VM'er.
Leverandør C var i stand til at håndtere 48 virtuelle maskiner med en responstid på 5,02 ms
SQL Server Load Emulation
Dernæst emulerede ESG Lab SQL Server-belastningen. Testen brugte forskellige blokstørrelser og læse/skrive-forhold. Testen blev også kørt på 140 virtuelle maskiner.
Som vist i figuren nedenfor klarede Cisco HyperFlex-klyngen leverandør A og B i IOPS næsten det dobbelte og leverandør C mere end fem gange. Den gennemsnitlige responstid for Cisco HyperFlex var 8,2 ms. Til sammenligning var den gennemsnitlige svartid for leverandør A 30,6 ms, for leverandør B var 12,8 ms, og for leverandør C var 10,33 ms.
En interessant observation blev lavet under alle tests. Leverandør B viste en signifikant variation i den gennemsnitlige ydeevne i IOPS på forskellige VM'er. Det vil sige, at belastningen var ekstremt ujævnt fordelt, nogle VM'er arbejdede med en gennemsnitsværdi på 1000 IOPS+, og nogle - med en værdi på 64 IOPS. Cisco HyperFlex så i dette tilfælde meget mere stabil ud, alle 140 VM'er modtog i gennemsnit 600 IOPS fra lagerundersystemet, det vil sige, at belastningen mellem de virtuelle maskiner blev fordelt meget jævnt.
Det er vigtigt at bemærke, at en sådan ujævn fordeling af IOPS på tværs af virtuelle maskiner hos leverandør B blev observeret i hver iteration af test.
I virkelig produktion kan denne opførsel af systemet være et stort problem for administratorer; faktisk begynder individuelle virtuelle maskiner tilfældigt at fryse, og der er praktisk talt ingen måde at kontrollere denne proces på. Den eneste, ikke særlig vellykkede måde at load balance på, når du bruger en løsning fra leverandør B, er at bruge en eller anden QoS eller balanceringsimplementering.
Output
Lad os tænke på, hvad Cisco Hyperflex har 140 virtuelle maskiner pr. 1 fysisk node versus 70 eller mindre for andre løsninger? For erhvervslivet betyder det, at for at understøtte det samme antal applikationer på Hyperflex, skal du bruge 2 gange færre noder end i konkurrerende løsninger, dvs. det endelige system bliver meget billigere. Hvis vi her tilføjer automatiseringsniveauet for alle operationer til vedligeholdelse af netværket, serverne og lagringsplatformen HX Data Platform, bliver det klart, hvorfor Cisco Hyperflex-løsninger så hurtigt vinder popularitet på markedet.
Samlet set har ESG Labs bekræftet, at Cisco HyperFlex Hybrid HX 3.0 leverer hurtigere og mere ensartet ydeevne end andre sammenlignelige løsninger.
Samtidig var HyperFlex hybridklynger også foran konkurrenterne med hensyn til IOPS og Latency. Lige så vigtigt er det, at HyperFlex-ydelsen blev opnået med en meget godt fordelt belastning over hele lageret.
Lad os minde dig om, at du kan se Cisco Hyperflex-løsningen og verificere dens muligheder lige nu. Systemet er tilgængeligt for demonstration for alle:
Kilde: www.habr.com