Jätkame Cisco HyperFlexi hüperkonvergeeritud süsteemi tutvustamist.
2019. aasta aprillis viib Cisco Venemaa ja Kasahstani piirkondades taas läbi rea uue hüperkonvergeeritud lahenduse Cisco HyperFlex esitlusi. Demonstratsioonile registreerumiseks saate kasutada tagasisidevormi, järgides linki. Liitu meiega!
Varem avaldasime artikli sõltumatu ESG Labi 2017. aastal tehtud koormustestide kohta. 2018. aastal on Cisco HyperFlexi lahenduse (versioon HX 3.0) jõudlus oluliselt paranenud. Lisaks paranevad jätkuvalt ka konkurentsivõimelised lahendused. Seetõttu avaldame ESG stressinäitajate uue, värskema versiooni.
2018. aasta suvel võrdles ESG labor Cisco HyperFlexi uuesti konkurentidega. Võttes arvesse praegust Tarkvara defineeritud lahenduste kasutamise trendi, lisati võrdlusanalüüsi ka sarnaste platvormide tootjad.
Testi konfiguratsioone
Testimise osana võrreldi HyperFlexi kahe täistarkvaralise hüperkonvergeeritud süsteemiga, mis on installitud standardsetesse x86 serveritesse, samuti ühe tarkvara- ja riistvaralahendusega. Testimisel kasutati hüperkonvergeeritud süsteemide standardtarkvara – HCIBenchi, mis kasutab Oracle Vdbenchi tööriista ja automatiseerib testimisprotsessi. Eelkõige loob HCIBench automaatselt virtuaalseid masinaid, koordineerib nende vahelist koormust ning genereerib mugavaid ja arusaadavaid aruandeid.
Ühe klastri kohta loodi 140 virtuaalmasinat (35 klastri sõlme kohta). Iga virtuaalmasin kasutas 4 vCPU-d ja 4 GB muutmälu. Kohalik VM ketas oli 16 GB ja lisaketas 40 GB.
Testimisel osalesid järgmised klastri konfiguratsioonid:
- neljast Cisco HyperFlex 220C sõlmest koosnev klaster 1 x 400 GB SSD vahemälu jaoks ja 6 x 1.2 TB SAS HDD andmete jaoks;
- konkurent Tarnija Neljast sõlmest koosnev klaster 2 x 400 GB SSD vahemälu jaoks ja 4 x 1 TB SATA HDD andmete jaoks;
- konkurendi Vendor B neljast sõlmest koosnev klaster 2 x 400 GB SSD vahemälu jaoks ja 12 x 1.2 TB SAS HDD andmete jaoks;
- konkurent Vendor C neljast sõlmest koosnev klaster 4 x 480 GB SSD vahemälu jaoks ja 12 x 900 GB SAS HDD andmete jaoks.
Kõigi lahenduste protsessorid ja RAM olid identsed.
Virtuaalsete masinate arvu testimine
Testimine algas töökoormusega, mis oli mõeldud standardse OLTP-testi emuleerimiseks: lugemine/kirjutamine (RW) 70%/30%, 100% FullRandom eesmärgiga 800 IOPS-i virtuaalmasina (VM) kohta. Test viidi läbi 140 virtuaalmasinal igas klastris kolm kuni neli tundi. Testi eesmärk on hoida võimalikult paljude VM-ide kirjutamise latentsusaeg kuni 5 millisekundit.
Testi tulemusel (vt allolevat graafikut) oli HyperFlex ainus platvorm, mis viis selle testi läbi esialgse 140 VM-iga ja latentsusaega alla 5 ms (4,95 ms). Iga teise klastri puhul taaskäivitati test, et katseliselt kohandada VM-ide arvu mitme iteratsiooni jooksul sihtlatentsusajaga 5 ms.
Tarnija A käsitles edukalt 70 VM-i keskmise reaktsiooniajaga 4,65 ms.
Tarnija B saavutas vajaliku latentsusaja 5,37 ms. ainult 36 VM-iga.
Tarnija C sai hakkama 48 virtuaalse masinaga, mille reageerimisaeg oli 5,02 ms
SQL Serveri laadimise emulatsioon
Järgmisena emuleeris ESG Lab SQL serveri laadimist. Testis kasutati erinevaid ploki suurusi ja lugemis-/kirjutussuhteid. Test viidi läbi ka 140 virtuaalmasinas.
Nagu on näidatud alloleval joonisel, edestas Cisco HyperFlexi klaster IOPS-is tarnijat A ja B peaaegu kaks korda ning tarnijat C enam kui viis korda. Cisco HyperFlexi keskmine reaktsiooniaeg oli 8,2 ms. Võrdluseks, tarnija A keskmine reaktsiooniaeg oli 30,6 ms, hankija B puhul 12,8 ms ja hankija C puhul 10,33 ms.
Kõigi katsete ajal tehti huvitav tähelepanek. Tarnija B näitas erinevate VM-ide IOPS-i keskmise jõudluse märkimisväärset erinevust. See tähendab, et koormus jaotus äärmiselt ebaühtlaselt, mõned VM-id töötasid keskmise väärtusega 1000 IOPS+ ja mõned - väärtusega 64 IOPS. Cisco HyperFlex nägi antud juhul välja palju stabiilsem, kõik 140 VM-i said salvestusalamsüsteemist keskmiselt 600 IOPS-i ehk koormus jaotus virtuaalmasinate vahel väga ühtlaselt.
Oluline on märkida, et IOPS-i ebaühtlast jaotumist tarnija B virtuaalmasinate vahel täheldati iga testimise iteratsiooni käigus.
Reaalses tootmises võib selline süsteemi käitumine olla administraatoritele suureks probleemiks, tegelikult hakkavad üksikud virtuaalmasinad suvaliselt külmuma ja seda protsessi pole praktiliselt võimalik juhtida. Ainus, mitte eriti edukas viis koormuse tasakaalu saavutamiseks, kui kasutada müüja B lahendust, on kasutada ühte või teist QoS-i või tasakaalustamise rakendust.
Väljund
Mõelgem sellele, millised on Cisco Hyperflexil 140 virtuaalmasinat 1 füüsilise sõlme kohta võrreldes 70 või vähemaga muude lahenduste jaoks? Äri jaoks tähendab see, et sama arvu rakenduste toetamiseks Hyperflexis on vaja 2 korda vähem sõlme kui konkurentide lahendustes, s.t. lõplik süsteem tuleb palju odavam. Kui siia lisada kõigi võrgu, serverite ja salvestusplatvormi HX Data Platform hooldamise toimingute automatiseerituse tase, saab selgeks, miks Cisco Hyperflexi lahendused turul nii kiiresti populaarsust koguvad.
Üldiselt on ESG Labs kinnitanud, et Cisco HyperFlex Hybrid HX 3.0 tagab kiirema ja ühtlasema jõudluse kui teised võrreldavad lahendused.
Samal ajal olid HyperFlexi hübriidklastrid konkurentidest ees ka IOPS-i ja latentsuse poolest. Sama oluline on see, et HyperFlexi jõudlus saavutati väga hästi jaotatud koormusega kogu salvestusruumis.
Tuletame meelde, et näete Cisco Hyperflexi lahendust ja saate kontrollida selle võimalusi juba praegu. Süsteem on kõigile demonstreerimiseks saadaval:
Allikas: www.habr.com