Turpinām iepazīstināt jūs ar hiperkonverģentu sistēmu Cisco HyperFlex.
2019. gada aprīlī uzņēmums Cisco vēlreiz rīko jauno hiperkonverģento risinājumu Cisco HyperFlex demonstrāciju sēriju Krievijas reģionos un Kazahstānā. Pieteikties demonstrācijai var, izmantojot atgriezeniskās saites veidlapu, sekojot saitei. Pievienojieties!
Iepriekš mēs publicējām rakstu par slodzes testiem, ko veica neatkarīga laboratorija ESG Lab 2017. gadā. 2018. gadā risinājuma Cisco HyperFlex (versija HX 3.0) raksturojums būtiski uzlabojās. Turklāt konkurentiem piederošie risinājumi arī turpināja attīstīties. Tāpēc mēs publicējam jauno, svaigāko salīdzinošu slodzes testu versiju no ESG.
2018. gada vasarā laboratorija ESG veica atkārtotu Cisco HyperFlex salīdzināšanu ar konkurentiem. Ņemot vērā mūsdienu tendenci izmantot programmatūras definētos risinājumus, salīdzinošajā analīzē tika iekļauti arī vairāki šādu platformu ražotāji.
Testa konfigurācijas
Testējot, HyperFlex tika salīdzināts ar divām pilnīgi programmatūras hiperkonverģentām sistēmām, kuras tiek uzstādītas uz standarta x86 serveriem, kā arī ar vienu programmatūras un aparatūras risinājumu. Testēšana tika veikta, izmantojot standartu hiperkonverģentām sistēmām - HCIBench, kas izmanto Oracle Vdbench rīku un automatizē testēšanas procesu. Proti, HCIBench automātiski izveido virtuālās mašīnas, koordinē slodzi starp tām un ģenerē ērtus un saprotamus ziņojumus.
Tika izveidotas 140 virtuālās mašīnas klasterim (35 katrai klastera vienībai). Katra virtuālā mašīna izmantoja 4 vCPU, 4 GB RAM. Vietējais VM disks bija 16 GB un papildus disks 40 GB.
Testēšanā piedalījās šādas klasteru konfigurācijas:
- klasteris ar četriem mezgliem Cisco HyperFlex 220C 1 x 400 GB SSD kešatmiņai un 6 x 1.2 TB SAS HDD datiem;
- konkurenta Vendor A klasteris ar četriem mezgliem 2 x 400 GB SSD kešatmiņai un 4 x 1 TB SATA HDD datiem;
- konkurenta Vendor B klasteris ar četriem mezgliem 2 x 400 GB SSD kešatmiņai un 12 x 1.2 TB SAS HDD datiem;
- konkurenta Vendor C klasteris ar četriem mezgliem 4 x 480 GB SSD kešatmiņai un 12 x 900 GB SAS HDD datiem.
Visi risinājumi izmantoja identiskus procesorus un operatīvo atmiņu.
Virsbūves testēšana par virtuālajām mašīnām
Testēšana sākās ar slodzi, kas tika izstrādāta, lai simulētu standarta OLTP testu: lasīšana/rakstīšana (RW) 70%/30%, 100% FullRandom ar mērķa vērtību 800 IOPS vienai virtuālajai mašīnai (VM). Tests tika veikts uz 140 VM katrā klasterī trīs līdz četru stundu garumā. Testa mērķis bija saglabāt rakstīšanas aizturi maksimālajā VM skaitā līdz 5 milisekundēm vai zemāk.
Testa rezultātā (skatīt grafiku zemāk) HyperFlex izrādījās vienīgā platforma, kas pabeidza šo testu ar sākotnējiem 140 VM un ar aizturi zem 5 ms (4,95 ms). Katram citam klasterim tests tika atkārtots, lai praktiski pielāgotu VM skaitu mērķa aizturi 5 ms robežās.
Vendor A veiksmīgi tikt galā ar 70 VM ar vidējo atbildes laiku 4,65 ms.
Vendor B nodrošināja nepieciešamās aiztures 5,37 ms, tikai ar 36 VM.
Vendor C spēja izturēt 48 virtuālās mašīnas ar atbildes laiku 5,02 ms.
SQL Server slodzes simulācija
Pēc tam ESG Laboratorija simulēja SQL Server slodzi. Testā tika izmantoti dažādi blokķēdes izmēri un lasīšanas/rakstīšanas attiecības. Tests tika veikts arī uz 140 virtuālajām mašīnām.
Kā redzams attēlā zemāk, Cisco HyperFlex gandrīz divreiz pārspēja IOPS rādījumus Vendor A un B, un Vendor C vairāk nekā piecas reizes. Vidējais atbildes laiks Cisco HyperFlex bija 8,2 ms. Salīdzinājumam, Vendor A vidējais atbildes laiks bija 30,6 ms, Vendor B – 12,8 ms, un Vendor C – 10,33 ms.
Interesants novērojums tika veikts visu testu laikā. Vendor B rādīja ievērojamu svārstību vidējo veiktspēju IOPS kopsummā dažādās VM. Proti, slodze tika sadalīta ļoti nevienmērīgi, dažas VM strādāja ar vidējo 1000 IOPS+, bet citas – ar 64 IOPS. Cisco HyperFlex šajā gadījumā izrādījās ievērojami stabilāks, visas 140 VM saņēma vidēji 600 IOPS no datu glabāšanas sistēmas, tātad slodze starp virtuālajām mašīnām bija ļoti vienmērīgi sadalīta.
Ir svarīgi atzīmēt, ka šāda nevienmērīga IOPS sadalīšana starp virtuālajām mašīnām Vendor B tika novērota katrā testēšanas iterācijā.
Reālajā produktivitātē šāda sistēmas uzvedība var radīt lielas problēmas administratoriem, jo būtībā atsevišķas virtuālās mašīnas sāk nejauši "iestrēgt", un praktiski nav nekādu iespēju kontrolēt šo procesu. Vienīgais, ne tik veiksmīgs slodzes līdzsvarošanas veids, izmantojot B piegādātāja risinājumu, ir QoS vai līdzsvarošana.
Izvade
Piedomāsim par to, ko nozīmē 140 virtuālo mašīnu Cisco Hyperflex uz 1 fizisko mezglu pret 70 vai mazāk uz citām sistēmām? Biznesam tas nozīmē, ka, lai uzturētu to pašu aplikāciju skaitu uz Hyperflex, ir nepieciešami 2 reizes mazāk mezglu nekā konkurentu risinājumos, t.i., gala sistēma būs ievērojami lētāka. Ja šim pievieno arī visu tīkla, serveru un HX Data Platform apkopes operāciju automatizācijas līmeni, kļūst skaidrs, kāpēc Cisco Hyperflex risinājumi tik ātri iegūst popularitāti tirgū.
Kopumā ESG laboratorija apstiprināja, ka hibrīdā Cisco HyperFlex versija HX 3.0 nodrošina augstākus un stabilākus veiktspējas rādītājus nekā citas līdzīgas sistēmas.
Turklāt hibrīda HyperFlex klasteri pārspēja konkurentus IOPS un Latency rādītājos. Ne mazāk svarīgi ir tas, ka HyperFlex veiktspēja tika nodrošināta ar ļoti labi sadalītu slodzi pa visu krātuvi.
Atgādinām, ka jūs jau tagad varat redzēt Cisco Hyperflex risinājumu un pārliecināties par tā iespējām. Sistēma ir pieejama demonstrācijām ikvienam, kas vēlas:
Avots: habr.com
