Мы працягваем знаёміць вас з гіперканвергентнай сістэмай Cisco HyperFlex.
У красавіку 2019 года кампанія Cisco у чарговы раз праводзіць серыю дэманстрацый новага гіперканвергентнага рашэння Cisco HyperFlex у рэгіёнах Расіі і ў Казахстане. Запісацца на дэманстрацыю можна праз форму зваротнай сувязі, перайшоўшы па спасылцы. Далучайцеся!
Раней мы публікавалі артыкул аб нагрузачных тэстах, выкананых незалежнай лабараторыяй ESG Lab у 2017-ым годзе. У 2018 годзе характарыстыкі рашэння Cisco HyperFlex (версія HX 3.0) значна палепшыліся. Акрамя таго, канкурэнтныя рашэнні таксама працягваюць удасканальвацца. Менавіта таму мы публікуем новую, свежую версію параўнальных нагрузачных тэстаў ад ESG.
Улетку 2018. Лабараторыя ESG правяла паўторнае параўнанне Cisco HyperFlex з канкурэнтамі. Улічваючы сучасную тэндэнцыю выкарыстання Software-defined-рашэнняў, у параўнальны аналіз былі таксама дададзены вытворцы падобных платформаў.
Тэставыя канфігурацыі
У рамках тэставання HyperFlex параўноўваўся з дзвюма цалкам праграмнымі гіперканвергентнымі сістэмамі, якія ўстанаўліваюцца на стандартныя x86 серверы, а таксама з адным праграмна-апаратным рашэннем. Тэставанне праводзілася з выкарыстаннем стандартнага для гіперканвергентных сістэм ПА - HCIBench, якое выкарыстоўвае інструмент Oracle Vdbench і аўтаматызуе працэс тэставання. У прыватнасці, HCIBench аўтаматычна стварае віртуальныя машыны, каардынуе нагрузку паміж імі і генеруе зручныя і зразумелыя справаздачы.
Было створана 140 віртуальных машын на кластар (35 на ноду кластара). Кожная віртуальная машына выкарыстоўвала 4 vCPU, 4 ГБ RAM. Лакальная кружэлка ВМ быў 16 ГБ і дадатковыя дыск 40 ГБ.
У тэставанні ўдзельнічалі наступныя канфігурацыі кластараў:
- кластар з чатырох вузлоў Cisco HyperFlex 220C 1 x 400 ГБ SSD для кэша і 6 x 1.2/XNUMX ТБ SAS HDD для дадзеных;
- кластар канкурэнта Vendor A з чатырох вузлоў 2 x 400 ГБ SSD для кэша і 4 x 1 ТБ SATA HDD для даных;
- кластар канкурэнта Vendor B з чатырох вузлоў 2 x 400 ГБ SSD для кэша і 12 x 1.2/XNUMX ТБ SAS HDD для дадзеных;
- кластар канкурэнта Vendor C з чатырох вузлоў 4 x 480 Гб SSD для кэша і 12 x 900 Гб SAS HDD для дадзеных.
Працэсары і аператыўная памяць усіх рашэнняў былі ідэнтычнымі.
Тэст на колькасць віртуальных машын
Тэставанне пачалося з працоўнай нагрузкі, прызначанай для эмуляцыі стандартнага OLTP-тэсту: чытанне/запіс (RW) 70%/30%, 100% FullRandom з мэтавым значэннем 800 IOPS на адну віртуальную машыну (ВМ). Тэст праводзіўся на 140 ВМ у кожным кластары на працягу трох-чатырох гадзін. Мэта тэсту - захаваць затрымкі пры запісе на максімальнай колькасці ВМ на ўзроўні 5 мілісекунд ці ніжэй.
У выніку тэсту (гл. графік ніжэй) HyperFlex апынуўся адзінай платформай, якая завяршыла гэты тэст з пачатковымі 140 ВМ і пры затрымках ніжэй за 5 мс (4,95 мс). Для кожнага з іншых кластараў тэст быў перазапушчаны для таго, каб дасведчаным шляхам за некалькі ітэрацый падагнаць колькасць ВМ пад мэтавую затрымку 5 мс.
Vendor A паспяхова зладзіўся з 70-цю ВМ са сярэднім часам водгуку 4,65 мс.
Vendor B забяспечыў патрабаваныя затрымкі ў 5,37 мс. толькі з 36-цю ВМ.
Vendor C змог вытрымаць 48 віртуальных машын з часам водгуку 5,02 мс
Эмуляцыя нагрузкі SQL Server
Далей ESG Lab эмулявала нагрузку SQL Server-а. У цесцю выкарыстоўваліся розныя памеры блокаў і суадносіны чытання/запісы. Тэст быў запушчаны таксама на 140 віртуальных машынах.
Як паказана на малюнку ніжэй, кластар Cisco HyperFlex амаль удвая перасягнуў па IOPS-ам вендара A і В, а вендара З больш чым у пяць разоў. Сярэдні час водгуку Cisco HyperFlex склала 8,2 мс. Для параўнання, сярэдні час адказу вендара А склала 30,6 мсек, вендара В - 12,8 мс, а вендара С - 10,33 мс.
Цікавае назіранне было зроблена падчас усіх тэстаў. Vendor B паказаў значны роскід сярэдняй прадукцыйнасці ў IOPS-ах на розных ВМ. Гэта значыць нагрузка размяркоўвалася вельмі нераўнамерна, некаторыя ВМ працавалі са сярэднім значэннем 1000 IOPS+, а некаторыя - са значэннем 64 IOPS. Cisco HyperFlex у дадзеным выпадку выглядаў значна стабільней, усе 140 ВМ атрымлівалі ў сярэднім 600 IOPS ад падсістэмы захоўвання дадзеных, гэта значыць нагрузка паміж віртуальнымі машынамі была размеркавана вельмі раўнамерна.
Важна адзначыць, што такое нераўнамернае размеркаванне IOPS па віртуальных машынах у вендара B назіралася ў кожнай ітэрацыі тэставання.
У рэальным прадуктыве такія паводзіны сістэмы можа быць вялікай праблемай для адміністратараў, у сутнасці, асобныя віртуальныя машыны выпадковым чынам пачынаюць «падвісаць» і практычна ніякага спосабу для кантролю гэтага працэсу не існуе. Адзіным, не вельмі ўдалым спосабам выраўноўвання нагрузкі, пры выкарыстанні рашэння ад вендара B, з'яўляецца выкарыстанне той ці іншай рэалізацыі QoS ці балансаванні.
Выснова
Давайце задумаемся, што такое 140 віртуальных машын у Cisco Hyperflex на 1 фізічны вузел супраць 70-ці ці менш у іншых рашэнняў? Для бізнэсу гэта азначае, што для падтрымання той жа колькасці прыкладанняў на Hyperflex трэба ў 2 разы менш вузлоў, чым у рашэннях канкурэнтаў, г.зн. выніковая сістэма будзе моцна таннейшай. Калі дадаць сюды яшчэ ўзровень аўтаматызацыі ўсіх аперацый па абслугоўванні сеткі, сервераў і платформы захоўвання HX Data Platform, становіцца зразумела, чаму рашэнні Cisco Hyperflex так імкліва заваёўваюць папулярнасць на рынку.
У цэлым, лабараторыя ESG пацвердзіла, што гібрыдныя Cisco HyperFlex версіі HX 3.0 забяспечваюць больш высокую і стабільную прадукцыйнасць, чым іншыя аналагічныя рашэнні.
Пры гэтым гібрыдныя кластары HyperFlex яшчэ і апярэджвалі канкурэнтаў па паказчыках IOPS і Latency. Не менш важна і тое, што прадукцыйнасць HyperFlex была забяспечана пры вельмі добра размеркаванай нагрузцы па ўсім сховішчы.
Нагадаем, што ўбачыць рашэнне Cisco Hyperflex і пераканацца ў яго магчымасцях вы можаце ўжо зараз. Сістэма даступная для дэманстрацыі ўсім жадаючым:
Крыніца: habr.com