Jätkame teid tutvustamist hüperkonvergeeritud süsteemiga Cisco HyperFlex.
Aprillis 2019 korraldab Cisco taas seeria demonstratsioone uue hüperkonvergeeritud lahenduse Cisco HyperFlex kohta Venemaa ja Kasahstani piirkondades. Registreerimine demonstratsioonile toimub tagasiside vormi kaudu, minnes lingile. Liituge!
Varem avaldasime artikli koormustestidest, mille viis läbi iseseisev labor ESG Lab 2017. aastal. 2018. aastal paranes Cisco HyperFlexi (versioon HX 3.0) jõudlus märgatavalt. Samuti jätkavad konkurentsivõimelised lahendused täiustamist. Seetõttu avaldame uusi, värskemaid võrreldavaid koormusteste ESG-lt.
Suvel 2018 viis labor ESG läbi uue võrdleva analüüsi Cisco HyperFlexi ja konkurentide vahel. Arvestades tänapäevast suundumust tarkvaradefinitsiooniga lahenduste kasutamisel, lisati võrdlevasse analüüsi ka sarnaste platvormide tootjad.
Testkonfiguratsioonid
Hüperkonvergeeritud süsteemi testimise raames võrreldi HyperFlexi kahte täiesti tarkvarapõhist hüperkonvergeeritud süsteemi, mis on paigaldatud standardsetele x86 serveritele, ning ühte tarkvara-riistvara lahendust. Testimine viidi läbi hüperkonvergeeritud süsteemide standardse tarkvaraga – HCIBench, mis kasutab tööriista Oracle Vdbench ja automatiseerib testimisprotsessi. Eelkõige loob HCIBench automaatselt virtuaalmasinad, koordineerib koormust nende vahel ja genereerib mugavad ja arusaadavad aruanded.
Klastrisse loodi 140 virtuaalmasinat (35 iga klastrinoodi kohta). Iga virtuaalmasin kasutas 4 vCPU ja 4 GB RAM-i. VM-i kohalik ketas oli 16 GB ja täiendav ketas 40 GB.
Testimises osalesid järgmised klastrite konfiguratsioonid:
- klaster neljast Cisco HyperFlex 220C sõlmest 1 x 400 GB SSD vahemäluks ja 6 x 1,2 TB SAS HDD andmete jaoks;
- konkurendi Vendor A klaster neljast sõlmest 2 x 400 GB SSD vahemäluks ja 4 x 1 TB SATA HDD andmete jaoks;
- konkurendi Vendor B klaster neljast sõlmest 2 x 400 GB SSD vahemäluks ja 12 x 1,2 TB SAS HDD andmete jaoks;
- konkurendi Vendor C klaster neljast sõlmest 4 x 480 GB SSD vahemäluks ja 12 x 900 GB SAS HDD andmete jaoks.
Kõikide lahenduste protsessorid ja mälu olid identsed.
Virtuaalsete masinate arvu test
Testimine algas töökoormusest, mis oli mõeldud standardse OLTP-testi emuleerimiseks: 70% lugemist/kirjutamist (RW) ja 100% FullRandom, mille eesmärk oli saavutada 800 IOPS ühe virtuaalse masina (VM) kohta. Test viidi läbi 140 VM-iga igas klastris kolme-nelja tunni jooksul. Testi eesmärk oli hoida kirjutamise latentsust maksimaalselt 5 millisekundi või alla selle enamiku VM-ide korral.
Testi tulemuste kohaselt (vt allolevat graafikut) oli HyperFlex ainus platvorm, mis lõpetas testi 140 VM-iga alguses ja latentsuse alla 5 ms (4,95 ms). Iga teise klastri puhul test viidi mitmel korral uuesti läbi, et praktiliselt kohandada VM-ide arvu sihtlatentsuse 5 ms saavutamiseks.
Vendor A suutis edukalt hallata 70 VM-i keskmise reageerimise ajaga 4,65 ms.
Vendor B tagas nõutud latentsuse 5,37 ms. vaid 36 VM-i korral.
Vendor C suutis toetada 48 virtuaalset masinat reageerimise ajaga 5,02 ms
SQL Serveri koormuse emuleerimine
Edasi emuleeris ESG Lab SQL Serveri koormust. Testis kasutati erinevaid ploki suurusi ja lugemise/kirjutamise suhteid. Test viidi samuti läbi 140 virtuaalsel masinal.
Nagu allolevalt jooniselt näha, ületas Cisco HyperFlex peaaegu kahekordselt Vendor A ja B IOPS-i ning Vendor C-d rohkem kui viis korda. Cisco HyperFlexi keskmine reageerimise aeg oli 8,2 ms. Võrdluseks, Vendor A keskmine vastusaeg oli 30,6 ms, Vendor B 12,8 ms ja Vendor C 10,33 ms.
Kogu testimise vältel tehti huvitav tähelepanek. Vendor B näitas erinevatel VM-idel IOPS-i keskmise jõudluse kohta suurt varieeruvust. See tähendab, et koormus jaotati äärmiselt ebaühtlaselt, mõned VM-id töötasid keskmisega 1000 IOPS+ ja mõned vaid 64 IOPS-iga. Cisco HyperFlex nägi sellel juhul välja palju stabiilsem, kõik 140 VM-i said keskmiselt 600 IOPS andmesalvestussüsteemilt, mis tähendas, et koormus jaotati virtuaalsete masinate vahel väga ühtlaselt.
Oluline on märkida, et Vendor B-l esines sarnast ebaühtlast IOPS-i jaotust virtuaalsete masinate vahel igas testimise iteratsioonis.
Tegelikus tootmises võib süsteemi selline käitumine administraatoritele suur probleem olla, kuna eraldi virtuaalmasinad hakkavad juhuslikult 'ültama' ja praktiliselt pole nende protsesside kontrollimiseks mingeid viise. Ainuke, kuigi mitte väga efektiivne, koormuse tasakaalu meetod B-tootja lahenduse kasutamisel on mingisugune QoS-i või tasakaalustamise rakendamine.
Kokkuvõte
Mõelgem hetkeks, mis on 140 virtuaalmasina puhul Cisco Hyperflexi ühe füüsilise sõlme peal võrreldes 70 või vähem muude lahendustega? Äri jaoks tähendab see, et sama palju rakendusi Hyperflexil hoidmiseks on vajalikke sõlmi kaks korda vähem kui konkurentide lahendustes, st lõplik süsteem on oluliselt odavam. Kui lisada siia ka kõigi võrgu, serverite ja HX Data Platformi säilitamise operatsioonide automatiseerimise tase, on selge, miks Cisco Hyperflexi lahendused turul nii kiiresti populaarsust koguvad.
Üldiselt kinnitas ESG laboratoorium, et hübriidne Cisco HyperFlex versioon HX 3.0 pakub kõrgemat ja stabiilsemat jõudlust kui teised sarnased lahendused.
Samuti ületasid hübriidklastrid HyperFlex konkurente IOPS-i ja Latency näitajates. Samuti on oluline, et HyperFlexi jõudlust tagati kogu salvestamise koormuse tõhusas jaotuses.
Tuletame meelde, et saate juba praegu näha Cisco Hyperflexi lahendust ja veenduda selle võimalustes. Süsteem on kõigile soovijatele demonstreerimiseks saadaval:
Allikas: habr.com
