Vi fortsetter å introdusere deg til Cisco HyperFlex hyperkonvergerte system.
I april 2019 gjennomfører Cisco nok en gang en serie demonstrasjoner av den nye hyperkonvergerte løsningen Cisco HyperFlex i regionene Russland og Kasakhstan. Du kan registrere deg for en demonstrasjon ved å bruke tilbakemeldingsskjemaet ved å følge lenken. Bli med oss!
Vi har tidligere publisert en artikkel om belastningstester utført av det uavhengige ESG Lab i 2017. I 2018 har ytelsen til Cisco HyperFlex-løsningen (versjon HX 3.0) blitt betydelig forbedret. I tillegg fortsetter også konkurransedyktige løsninger å forbedre seg. Derfor publiserer vi en ny, nyere versjon av ESGs stressbenchmarks.
Sommeren 2018 sammenlignet ESG-laboratoriet Cisco HyperFlex på nytt med sine konkurrenter. Med tanke på den nåværende trenden med bruk av programvaredefinerte løsninger, ble produsenter av lignende plattformer også lagt til den komparative analysen.
Test konfigurasjoner
Som en del av testingen ble HyperFlex sammenlignet med to fullt programvare hyperkonvergerte systemer som er installert på standard x86-servere, samt med én programvare- og maskinvareløsning. Testing ble utført ved bruk av standard programvare for hyperkonvergerte systemer - HCIBench, som bruker Oracle Vdbench-verktøyet og automatiserer testprosessen. Spesielt oppretter HCIBench automatisk virtuelle maskiner, koordinerer belastningen mellom dem og genererer praktiske og forståelige rapporter.
140 virtuelle maskiner ble opprettet per klynge (35 per klyngennode). Hver virtuell maskin brukte 4 vCPUer, 4 GB RAM. Den lokale VM-disken var 16 GB og den ekstra disken var 40 GB.
Følgende klyngekonfigurasjoner deltok i testingen:
- klynge med fire Cisco HyperFlex 220C-noder 1 x 400 GB SSD for cache og 6 x 1.2 TB SAS HDD for data;
- konkurrent Leverandør En klynge med fire noder 2 x 400 GB SSD for cache og 4 x 1 TB SATA HDD for data;
- konkurrent Vendor B-klynge med fire noder 2 x 400 GB SSD for cache og 12 x 1.2 TB SAS HDD for data;
- konkurrent Vendor C-klynge med fire noder 4 x 480 GB SSD for cache og 12 x 900 GB SAS HDD for data.
Prosessorene og RAM-en til alle løsningene var identiske.
Test for antall virtuelle maskiner
Testingen begynte med en arbeidsbelastning designet for å emulere en standard OLTP-test: lese/skrive (RW) 70 %/30 %, 100 % FullRandom med et mål på 800 IOPS per virtuell maskin (VM). Testen ble utført på 140 VM-er i hver klynge i tre til fire timer. Målet med testen er å holde skriveforsinkelser på så mange VM-er som mulig til 5 millisekunder eller lavere.
Som et resultat av testen (se grafen nedenfor), var HyperFlex den eneste plattformen som fullførte denne testen med innledende 140 VM-er og med ventetider under 5 ms (4,95 ms). For hver av de andre klyngene ble testen startet på nytt for å eksperimentelt justere antall VM-er til mållatenstiden på 5 ms over flere iterasjoner.
Leverandør A håndterte 70 VM-er med en gjennomsnittlig responstid på 4,65 ms.
Leverandør B oppnådde den nødvendige ventetiden på 5,37 ms. bare med 36 VM-er.
Leverandør C var i stand til å håndtere 48 virtuelle maskiner med en responstid på 5,02 ms
SQL Server Load Emulation
Deretter emulerte ESG Lab SQL Server-belastningen. Testen brukte forskjellige blokkstørrelser og lese-/skriveforhold. Testen ble også kjørt på 140 virtuelle maskiner.
Som vist i figuren nedenfor, overgikk Cisco HyperFlex-klyngen leverandørene A og B i IOPS med nesten det dobbelte, og leverandør C med mer enn fem ganger. Gjennomsnittlig responstid for Cisco HyperFlex var 8,2 ms. Til sammenligning var gjennomsnittlig responstid 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 observasjon ble gjort under alle testene. Leverandør B viste en betydelig variasjon i gjennomsnittlig ytelse i IOPS på forskjellige VM-er. Det vil si at lasten ble fordelt ekstremt ujevnt, noen VM-er jobbet med en gjennomsnittsverdi på 1000 IOPS+, og noen - med en verdi på 64 IOPS. Cisco HyperFlex i dette tilfellet så mye mer stabilt ut, alle 140 VM-er mottok et gjennomsnitt på 600 IOPS fra lagringsundersystemet, det vil si at belastningen mellom de virtuelle maskinene ble fordelt veldig jevnt.
Det er viktig å merke seg at en slik ujevn fordeling av IOPS på tvers av virtuelle maskiner hos leverandør B ble observert i hver iterasjon av testing.
I ekte produksjon kan denne oppførselen til systemet være et stort problem for administratorer; faktisk begynner individuelle virtuelle maskiner tilfeldig å fryse, og det er praktisk talt ingen måte å kontrollere denne prosessen. Den eneste, ikke særlig vellykkede måten å lastebalanse på, når du bruker en løsning fra leverandør B, er å bruke en eller annen QoS eller balanseringsimplementering.
Utgang
La oss tenke på hva Cisco Hyperflex har 140 virtuelle maskiner per 1 fysisk node mot 70 eller mindre for andre løsninger? For bedrifter betyr dette at for å støtte like mange applikasjoner på Hyperflex trenger du 2 ganger færre noder enn i konkurrentløsninger, dvs. det endelige systemet vil bli mye billigere. Hvis vi her legger til automatiseringsnivået for alle operasjoner for vedlikehold av nettverket, serverne og lagringsplattformen HX Data Platform, blir det klart hvorfor Cisco Hyperflex-løsninger er så raskt økende i popularitet i markedet.
Samlet sett har ESG Labs bekreftet at Cisco HyperFlex Hybrid HX 3.0 leverer raskere og mer konsistent ytelse enn andre sammenlignbare løsninger.
Samtidig var HyperFlex hybridklynger også foran konkurrentene når det gjelder IOPS og Latency. Like viktig, HyperFlex-ytelse ble oppnådd med en veldig godt fordelt belastning over hele lageret.
La oss minne deg på at du kan se Cisco Hyperflex-løsningen og verifisere funksjonene akkurat nå. Systemet er tilgjengelig for demonstrasjon for alle:
Kilde: www.habr.com