Folytatjuk, hogy megismertessük Önöket a Cisco HyperFlex hipo-konvergens rendszerrel.
2019 áprilisában a Cisco ismét sorozatot rendez az új Cisco HyperFlex hipo-konvergens megoldás bemutatására Oroszország és Kazahsztán régióiban. A bemutatóra való jelentkezés az ajánlatkérő űrlap kitöltésével lehetséges, az alább található linken. Csatlakozzon hozzánk!
Korábban közzétettünk egy cikket a független ESG Lab által 2017-ben végzett terhelési tesztekről. 2018-ban a Cisco HyperFlex (HX 3.0 verzió) jellemzői jelentősen javultak. Továbbá a versenytárs megoldások is folyamatosan fejlődnek. Éppen ezért közzétesszük az ESG által végzett újabb, frissebb összehasonlító terhelési teszteket.
2018 nyarán az ESG laboratórium megismételte a Cisco HyperFlex és versenytársai összehasonlítását. Figyelembe véve a modern szoftveralapú megoldások használatának tendenciáját, a versenytársak közé hasonló platformok gyártói is bekerültek a összehasonlításba.
Tesztkonfigurációk
A HyperFlex tesztelése során két teljesen szoftveres hipo-konvergens rendszert hasonlítottak össze, amelyeket szabványos x86 szerverekre telepítenek, valamint egy hibrid szoftver-hardver megoldást. A tesztelés a hipo-konvergens rendszerekhez standard szoftverrel – HCIBench– zajlott, amely az Oracle Vdbench eszközt használja és automatizálja a tesztelési folyamatot. Különösen a HCIBench automatikusan létrehozza a virtuális gépeket, koordinálja a terhelést közöttük és kényelmes, érthető jelentéseket generál.
140 virtuális gép jött létre a klaszterben (35 gép csomópontonként). Minden virtuális gép 4 vCPU-t és 4 GB RAM-ot használt. A VM helyi lemez mérete 16 GB, míg a kiegészítő lemez 40 GB volt.
A következő klaszterconfigurációk vettek részt a tesztelésben:
- Cisco HyperFlex 220C klaszter négy csomópontból, 1 x 400 GB SSD a gyorsításhoz és 6 x 1.2 TB SAS HDD az adatokhoz;
- A Vendor A klaszter négy csomópontból, 2 x 400 GB SSD a gyorsításhoz és 4 x 1 TB SATA HDD az adatokhoz;
- A Vendor B klaszter négy csomópontból, 2 x 400 GB SSD a gyorsításhoz és 12 x 1.2 TB SAS HDD az adatokhoz;
- A Vendor C klaszter négy csomópontból, 4 x 480 GB SSD a gyorsításhoz és 12 x 900 GB SAS HDD az adatokhoz.
Minden megoldás processzorai és RAM-ja azonos volt.
Virtuális gépek számának tesztje
A teszt egy standard OLTP teszt emulálására tervezett munkaterheléssel kezdődött: olvasás/írás (RW) 70%/30%, 100% teljes véletlenszerűség, célértékkel 800 IOPS egy virtuális gépen (VM). A teszt 140 VM-en zajlott minden klaszterben három-négy órán keresztül. A teszt célja, hogy az írási késleltetéseket a maximális számú VM esetén 5 milliszekundum vagy annál alacsonyabb szinten tartsa.
A teszt eredményeképpen (lásd az alábbi grafikont) a HyperFlex volt az egyetlen platform, amely 140 VM kezdeti állapotban és 5 ms alatti késleltetéssel teljesítette ezt a tesztet (4,95 ms). A többi klaszternél a tesztet újraindították, hogy tapasztalati úton, több iteráción keresztül beállítsák a VM-ek számát az 5 ms célkésleltetéshez.
A Vendor A sikeresen kezelte a 70 VM-et 4,65 ms átlagos válaszidővel.
A Vendor B a kívánt késleltetéseket 5,37 ms értéken biztosította csak 36 VM-es esetén.
A Vendor C 48 virtuális gépet tudott kezelni 5,02 ms válaszidővel.
SQL Server terhelés emuláció
Továbbiakban az ESG Lab emulálta a SQL Server terhelést. A teszt különböző blokkméreteket és olvasás/írás arányokat használt. A teszt szintén 140 virtuális gépen futott.
Ahogy az az alábbi ábrán látható, a Cisco HyperFlex majdnem kétszer annyi IOPS-t ért el, mint az A és B beszállítók, míg a C beszállító esetében több mint ötször. A Cisco HyperFlex átlagos válaszideje 8,2 ms volt. Összehasonlításul, az A beszállító átlagos válaszideje 30,6 ms, a B-é 12,8 ms, a C-é pedig 10,33 ms volt.
Érdekes megfigyelést tettek a tesztek során. A Vendor B jelentős szórást mutatott az IOPS átlagos teljesítményében a különböző VM-ek között. Ez azt jelenti, hogy a terhelés rendkívül egyenlőtlenül oszlott meg, néhány VM átlagosan 1000 IOPS+ teljesítménnyel dolgozott, míg mások 64 IOPS értéknél. A Cisco HyperFlex ebben az esetben sokkal stabilabbnak tűnt, mind a 140 VM átlagosan 600 IOPS-t kapott az adattároló alrendszertől, ami azt jelenti, hogy a terhelés nagyon egyenletesen oszlott meg a virtuális gépek között.
Fontos megjegyezni, hogy az IOPS egyenlőtlen eloszlása a B beszállító virtuális gépei között minden tesztelési iteráció során megfigyelhető volt.
A valós termelésben az ilyen rendszer viselkedés nagy problémát jelenthet az adminisztrátorok számára, mivel egyes virtuális gépek véletlenszerűen "akadoznak", és szinte nincs mód ezen folyamat ellenőrzésére. Az egyetlen, nem túl hatékony módja a terhelés kiegyenlítésének a B gyártó megoldása esetén a QoS vagy a terheléselosztás valamilyen megvalósítása.
Következtetés
Gondoljunk csak bele, mi is az a 140 virtuális gép a Cisco Hyperflexen egy fizikai csomóponton szemben a többi megoldás 70-nel vagy annál kevesebbel? Ez a vállalkozások számára azt jelenti, hogy a Hyperflexen ugyanannyi alkalmazás fenntartásához kétszer kevesebb csomópont szükséges, mint a versenytársak megoldásaiban, tehát a végső rendszer lényegesen olcsóbb lesz. Ha mindehhez hozzáadjuk a hálózat, a szerverek és az HX Data Platform tárolási platform karbantartási műveleteinek automatizálásának szintjét, világossá válik, miért népszerűsödnek annyira gyorsan a Cisco Hyperflex megoldások a piacon.
Összességében az ESG labor megerősítette, hogy a Cisco HyperFlex HX 3.0 hibrid verziói magasabb és stabilabb teljesítményt nyújtanak, mint más hasonló megoldások.
Közben a HyperFlex hibrid klaszterei a IOPS és a Latency mutatókban is megelőzték a versenytársakat. Nem kevésbé fontos, hogy a HyperFlex teljesítménye nagyon jól elosztott terhelés mellett valósult meg az egész tárolóban.
Emlékeztetjük Önöket, hogy a Cisco Hyperflex megoldásait megtekinthetik és lehetőségük van megbizonyosodni a képességeiről már most is. A rendszer minden érdeklődő számára elérhető bemutatóra:
Forrás: habr.com
