🥇Cisco HyperFlex vs. konkurrenter: vi tester ytelse

Vi fortsetter å introdusere deg for det hyperkonvergente systemet Cisco HyperFlex.

I april 2019 arrangerer Cisco nok en serie demonstrasjoner av den nye hyperkonvergente løsningen Cisco HyperFlex i regionene Russland og Kasakhstan. Du kan melde deg på demonstrasjonen via kontaktskjemaet ved å følge lenken. Bli med!

Tidligere publiserte vi en artikkel om belastningstester utført av det uavhengige laboratoriet ESG Lab i 2017. I 2018 ble egenskapene til løsningen Cisco HyperFlex (versjon HX 3.0) betydelig forbedret. I tillegg fortsetter konkurrentenes løsninger også å utvikle seg. Derfor publiserer vi en ny, mer oppdatert versjon av de sammenlignende belastningstestene fra ESG.

Sommer 2018 gjennomførte laboratoriet ESG en ny sammenligning av Cisco HyperFlex med konkurrentene. Gitt den moderne trenden med bruk av programvaredefinerte løsninger, ble produsenter av lignende plattformer også inkludert i den sammenlignende analysen.

Testkonfigurasjoner

Under testen ble HyperFlex sammenlignet med to fullt programvaredrevne hyperkonvergente systemer som installeres på standard x86-servere, samt med én programvare-hardware-løsning. Testingen ble utført med standard programvaren for hyperkonvergente systemer – HCIBench, som bruker verktøyet Oracle Vdbench og automatiserer testprosessen. Spesielt oppretter HCIBench automatisk virtuelle maskiner, koordinerer belastningen mellom dem og genererer brukervennlige og forståelige rapporter.

Det ble opprettet 140 virtuelle maskiner per klynge (35 per nod i klyngen). Hver virtuell maskin brukte 4 vCPU, 4 GB RAM. Den lokale disken på VM var 16 GB og en ekstra disk på 40 GB.

Testing inkluderte følgende klyngekonfigurasjoner:

klynge med fire noder Cisco HyperFlex 220C 1 x 400 GB SSD for cache og 6 x 1,2 TB SAS HDD for data;
konkurrentens klynge Vendor A med fire noder 2 x 400 GB SSD for cache og 4 x 1 TB SATA HDD for data;
konkurrentens klynge Vendor B med fire noder 2 x 400 GB SSD for cache og 12 x 1,2 TB SAS HDD for data;
konkurrentens klynge Vendor C med fire noder 4 x 480 GB SSD for cache og 12 x 900 GB SAS HDD for data.

Prosessorene og minnet for alle løsningene var identiske.

Test av antall virtuelle maskiner

Testing began with a workload designed to simulate a standard OLTP test: read/write (RW) 70%/30%, 100% FullRandom aiming for 800 IOPS per virtual machine (VM). The test was conducted on 140 VMs in each cluster for three to four hours. The goal of the test was to maintain write latencies on the maximum number of VMs at 5 milliseconds or lower.

As a result of the test (see the graph below), HyperFlex was the only platform that completed this test with the initial 140 VMs and with latencies below 5 ms (4.95 ms). For each of the other clusters, the test was restarted to adjust the number of VMs to achieve the target latency of 5 ms through multiple iterations.

Vendor A successfully handled 70 VMs with an average response time of 4.65 ms.
Vendor B achieved the required latency of 5.37 ms with only 36 VMs.
Vendor C managed to handle 48 virtual machines with a response time of 5.02 ms.

SQL Server Load Emulation

Next, ESG Lab emulated a SQL Server load. The test used various block sizes and read/write ratios. The test was also run on 140 virtual machines.

As shown in the figure below, the Cisco HyperFlex cluster outperformed Vendor A and B in IOPS nearly twofold, and Vendor C more than fivefold. The average response time of Cisco HyperFlex was 8.2 ms. In comparison, the average response time for Vendor A was 30.6 ms, Vendor B was 12.8 ms, and Vendor C was 10.33 ms.

An interesting observation was made during all tests. Vendor B showed a significant variation in average performance in IOPS across different VMs. In other words, the load was distributed extremely unevenly, with some VMs operating with an average of 1000 IOPS+, while others had 64 IOPS. In this case, Cisco HyperFlex appeared significantly more stable, with all 140 VMs receiving an average of 600 IOPS from the storage subsystem, meaning the load was distributed very evenly among the virtual machines.

It is important to note that this uneven distribution of IOPS across virtual machines for Vendor B was observed in every iteration of the testing.

I et virkelig produksjonsmiljø kan denne systemoppførselen være et stort problem for administratorer, ettersom enkelte virtuelle maskiner tilfeldig begynner å "henge", og det finnes nesten ingen måte å kontrollere denne prosessen på. Den eneste, ikke så vellykkede metoden for å balansere belastningen når man bruker løsning fra leverandør B, er å implementere en eller annen form for QoS eller lastbalansering.

Utdata

La oss tenke over hva 140 virtuelle maskiner på Cisco Hyperflex på 1 fysisk node betyr i forhold til 70 eller færre på andre løsninger? For bedriften betyr dette at for å opprettholde det samme antallet applikasjoner på Hyperflex, trenger man halvparten så mange noder som i konkurrentenes løsninger, altså vil det totale systemet bli betydelig billigere. Hvis vi også legger til et nivå av automatisering av alle operasjoner som angår vedlikehold av nettverk, servere og lagringsplattformer med HX Data Platform, blir det klart hvorfor Cisco Hyperflex-løsningene så raskt vinner popularitet i markedet.

Generelt har ESG-laboratoriet bekreftet at de hybride Cisco HyperFlex-versjonene HX 3.0 gir høyere og mer stabil ytelse enn andre lignende løsninger.

Samtidig oversteg de hybride klusterne HyperFlex konkurrentene med hensyn til IOPS og Latency. Ikke mindre viktig er det at ytelsen til HyperFlex ble oppnådd med en svært godt fordelt belastning over hele lagringssystemet.

Vi minner om at du allerede nå kan se løsningen Cisco Hyperflex og bli kjent med dens muligheter. Systemet er tilgjengelig for demonstrasjon for alle interesserte:

Kilde: habr.com

Cisco HyperFlex vs. konkurrenter: vi testar prestanda

Testkonfigurasjoner

Test av antall virtuelle maskiner

SQL Server Load Emulation

Utdata