Pokračujeme v seznámení s hyperkonvergovaným systémem Cisco HyperFlex.
V dubnu 2019 společnost Cisco znovu pořádá sérii demonstrací nového hyperkonvergovaného řešení Cisco HyperFlex v regionech Ruska a Kazachstánu. Na demonstraci se můžete přihlásit prostřednictvím kontaktního formuláře kliknutím na odkaz. Připojte se!
Dříve jsme publikovali článek o zátěžových testech provedených nezávislou laboratoří ESG Lab v roce 2017. V roce 2018 se vlastnosti řešení Cisco HyperFlex (verze HX 3.0) výrazně zlepšily. Kromě toho se i konkurenční řešení nadále vyvíjejí. Proto publikujeme novou, aktuálnější verzi srovnávacích zátěžových testů od ESG.
V létě 2018 laboratoř ESG provedla opakované srovnání Cisco HyperFlex s konkurencí. Vzhledem k současným trendům využívání řešení definovaných softwarem byly do srovnávací analýzy zahrnuti také výrobci podobných platforem.
Testovací konfigurace
V rámci testování byl HyperFlex srovnáván s dvěma plně softwarovými hyperkonvergovanými systémy, které jsou instalovány na standardních x86 serverech, a také s jedním softwarově-hardwarem řešením. Testování probíhalo za použití standardního softwaru pro hyperkonvergované systémy – HCIBench, který využívá nástroj Oracle Vdbench a automatizuje proces testování. HCIBench automaticky vytváří virtuální stroje, koordinuje zátěž mezi nimi a generuje přehledné a srozumitelné zprávy.
Bylo vytvořeno 140 virtuálních strojů na cluster (35 na uzel clusteru). Každý virtuální stroj použil 4 vCPU, 4 GB RAM. Místní disk VM byl 16 GB a další disk 40 GB.
V testování byly použity následující konfigurace clusterů:
- čtyřuzlový cluster Cisco HyperFlex 220C 1 x 400 GB SSD pro cache a 6 x 1,2 TB SAS HDD pro data;
- čtyřuzlový cluster kompetitora Vendor A 2 x 400 GB SSD pro cache a 4 x 1 TB SATA HDD pro data;
- čtyřuzlový cluster kompetitora Vendor B 2 x 400 GB SSD pro cache a 12 x 1,2 TB SAS HDD pro data;
- čtyřuzlový cluster kompetitora Vendor C 4 x 480 GB SSD pro cache a 12 x 900 GB SAS HDD pro data.
Procesory a operační paměť všech řešení byly identické.
Test počtu virtuálních strojů
Testování začalo s pracovním zatížením, které mělo emulovat standardní OLTP test: čtení/zápis (RW) 70%/30%, 100% FullRandom s cílovou hodnotou 800 IOPS na jeden virtuální stroj (VM). Test byl prováděn na 140 VM v každém clusteru po dobu tří až čtyř hodin. Cílem testu bylo udržet latenci při zápisu na co největším počtu VM na úrovni 5 milisekund nebo nižší.
Výsledek testu (viz graf níže) ukázal, že HyperFlex byla jedinou platformou, která tento test dokončila s počátečními 140 VM a latencí nižší než 5 ms (4,95 ms). Pro každý z ostatních clusterů byl test znovu spuštěn, aby bylo možné empiricky upravit počet VM podle cílové latence 5 ms.
Dodavatel A úspěšně zvládl 70 VM se střední dobou odezvy 4,65 ms.
Dodavatel B zajistil požadovanou latenci 5,37 ms pouze s 36 VM.
Dodavatel C dokázal udržet 48 virtuálních strojů se dobou odezvy 5,02 ms.
Emulace zátěže SQL Serveru
Dále ESG Lab emuloval zátěž SQL Serveru. V testu byly použity různé velikosti bloků a poměry čtení/zápis. Test byl spuštěn také na 140 virtuálních strojích.
Jak je znázorněno na obrázku níže, cluster Cisco HyperFlex téměř dvojnásobně překonal IOPS dodavatele A a B, zatímco dodavatel C více než pětkrát. Průměrná doba odezvy Cisco HyperFlex byla 8,2 ms. Pro srovnání, průměrná doba odezvy dodavatele A byla 30,6 ms, dodavatele B — 12,8 ms, a dodavatele C — 10,33 ms.
Zajímavé pozorování bylo učiněno během všech testů. Dodavatel B vykázal značný rozptyl průměrné výkonnosti v IOPS na různých VM. To znamená, že zátěž byla rozložena velmi nerovnoměrně, některé VM pracovaly se střední hodnotou 1000 IOPS+, zatímco jiné se 64 IOPS. V tomto případě se Cisco HyperFlex jevil mnohem stabilněji, všech 140 VM dostávalo v průměru 600 IOPS od úložiště, tedy zátěž mezi virtuálními stroji byla rozdělena velmi rovnoměrně.
Je důležité poznamenat, že takové nerovnoměrné rozložení IOPS mezi virtuálními stroji dodavatele B bylo pozorováno v každé iteraci testování.
V reálném provozu může takové chování systému představovat velký problém pro administrátory, protože izolované virtuální stroje náhodně začínají "zamrzat" a prakticky neexistuje žádný způsob, jak tento proces sledovat. Jediným, ne zcela optimálním způsobem vyrovnání zátěže při použití řešení od dodavatele B, je implementace QoS nebo load balancing.
Výstup
Zamysleme se nad tím, co znamená 140 virtuálních strojů u Cisco Hyperflex na 1 fyzický uzel v porovnání s 70 nebo méně u jiných řešení? Pro podniky to znamená, že pro udržení stejného počtu aplikací na Hyperflex je potřeba dvakrát méně uzlů než u konkurenčních řešení, tedy celkový systém bude výrazně levnější. Pokud k tomu přidáme i úroveň automatizace všech operací spojených s údržbou sítě, serverů a platformy HX Data Platform, je jasné, proč řešení Cisco Hyperflex tak rychle získávají popularitu na trhu.
Celkově laboratoř ESG potvrdila, že hybridní verze Cisco HyperFlex HX 3.0 poskytují vyšší a stabilnější výkon než jiná srovnatelná řešení.
Hybridní clustery HyperFlex navíc předčily konkurenci v ukazatelích IOPS a latence. Neméně důležité je, že výkon HyperFlex byl zajištěn při velmi dobře rozložené zátěži na celé úložiště.
Připomínáme, že řešení Cisco Hyperflex si můžete prohlédnout a vyzkoušet jeho možnosti již nyní. Systém je k dispozici k předvedení všem zájemcům:
Zdroj: habr.com
