Մենք շարունակում ենք ձեզ ներկայացնել Cisco HyperFlex հիպերկոնվերգացիոն համակարգը:
2019 թվականի ապրիլին Cisco-ն հերթական անգամ իրականացնում է Cisco HyperFlex նոր հիպերկոնվերգացիոն լուծման ցուցադրությունների շարք Ռուսաստանի և Ղազախստանի մարզերում։ Դուք կարող եք գրանցվել ցուցադրության համար՝ օգտագործելով հետադարձ կապի ձևը՝ հետևելով հղմանը: Միացեք մեզ!
Մենք նախկինում հրապարակել ենք հոդված 2017 թվականին անկախ ESG լաբորատորիայի կողմից իրականացված բեռի փորձարկումների մասին: 2018 թվականին Cisco HyperFlex լուծման (տարբերակ HX 3.0) արդյունավետությունը զգալիորեն բարելավվել է։ Բացի այդ, մրցակցային լուծումները նույնպես շարունակում են բարելավվել: Ահա թե ինչու մենք հրապարակում ենք ESG-ի սթրեսային չափանիշների նոր, ավելի թարմ տարբերակը:
2018 թվականի ամռանը ESG լաբորատորիան կրկին համեմատեց Cisco HyperFlex-ը իր մրցակիցների հետ։ Հաշվի առնելով Ծրագրային ապահովման կողմից սահմանված լուծումների օգտագործման ներկայիս միտումը՝ համեմատական վերլուծությանը ավելացվել են նաև նմանատիպ հարթակներ արտադրողները։
Փորձարկման կոնֆիգուրացիաներ
Որպես թեստավորման մաս՝ HyperFlex-ը համեմատվել է երկու լիովին ծրագրային հիպերկոնվերգացիոն համակարգերի հետ, որոնք տեղադրված են ստանդարտ x86 սերվերների վրա, ինչպես նաև մեկ ծրագրային և ապարատային լուծումների հետ: Թեստավորումն իրականացվել է հիպերկոնվերգացիոն համակարգերի համար ստանդարտ ծրագրաշարի միջոցով՝ HCIBench, որն օգտագործում է Oracle Vdbench գործիքը և ավտոմատացնում է թեստավորման գործընթացը: Մասնավորապես, HCIBench-ը ավտոմատ կերպով ստեղծում է վիրտուալ մեքենաներ, կոորդինացնում է դրանց միջև բեռը և ստեղծում հարմար և հասկանալի հաշվետվություններ:
Մեկ կլաստերի համար ստեղծվել է 140 վիրտուալ մեքենա (կլաստերային հանգույցում՝ 35): Յուրաքանչյուր վիրտուալ մեքենա օգտագործում էր 4 vCPU, 4 ԳԲ RAM: Տեղական VM սկավառակը 16 ԳԲ էր, իսկ լրացուցիչը՝ 40 ԳԲ:
Հետևյալ կլաստերային կազմաձևերը մասնակցել են փորձարկմանը.
- Cisco HyperFlex 220C չորս հանգույցների կլաստեր 1 x 400 ԳԲ SSD քեշի համար և 6 x 1.2 TB SAS HDD տվյալների համար;
- Մրցակից Վաճառող Չորս հանգույցներից բաղկացած կլաստեր 2 x 400 ԳԲ SSD քեշի համար և 4 x 1 ՏԲ SATA HDD տվյալների համար;
- մրցակից Վաճառող B կլաստեր չորս հանգույցներից 2 x 400 ԳԲ SSD քեշի համար և 12 x 1.2 TB SAS HDD տվյալների համար;
- մրցակից Վաճառող C կլաստեր չորս հանգույցներից 4 x 480 ԳԲ SSD քեշի համար և 12 x 900 ԳԲ SAS HDD տվյալների համար:
Բոլոր լուծումների պրոցեսորներն ու օպերատիվ հիշողությունը նույնական էին։
Վիրտուալ մեքենաների քանակի ստուգում
Փորձարկումը սկսվեց աշխատանքային ծանրաբեռնվածությամբ, որը նախատեսված էր ստանդարտ OLTP թեստը ընդօրինակելու համար՝ կարդալ/գրել (RW) 70%/30%, 100% FullRandom՝ յուրաքանչյուր վիրտուալ մեքենայի համար (VM) 800 IOPS թիրախով: Փորձարկումն իրականացվել է 140 VM-ների վրա յուրաքանչյուր կլաստերում երեքից չորս ժամ տևողությամբ: Թեստի նպատակն է հնարավորինս շատ VM-ների վրա գրել ուշացումները պահել մինչև 5 միլիվայրկյան կամ ավելի ցածր:
Փորձարկման արդյունքում (տե՛ս ստորև բերված գրաֆիկը), HyperFlex-ը միակ հարթակն էր, որն ավարտեց այս թեստը նախնական 140 VM-ով և 5 ms-ից (4,95 ms) ցածր ուշացումներով: Մյուս կլաստերներից յուրաքանչյուրի համար թեստը վերսկսվեց՝ մի քանի կրկնությունների ընթացքում VM-ների թիվը փորձնականորեն հարմարեցնելու նպատակային ուշացմանը՝ 5 ms:
Վաճառող A-ն հաջողությամբ կառավարել է 70 VM՝ 4,65 ms արձագանքման միջին ժամանակով:
Վաճառող B-ն հասել է 5,37 ms պահանջվող հետաձգմանը: միայն 36 VM-ով:
Վաճառող C-ն կարողացել է կառավարել 48 վիրտուալ մեքենաներ՝ 5,02 ms արձագանքման ժամանակով
SQL Server Load Emulation
Հաջորդը, ESG Lab-ը նմանակեց SQL Server-ի բեռնվածությունը: Թեստը օգտագործել է տարբեր բլոկի չափեր և կարդալ/գրել հարաբերակցություններ: Թեստն իրականացվել է նաև 140 վիրտուալ մեքենաների վրա:
Ինչպես ցույց է տրված ստորև նկարում, Cisco HyperFlex կլաստերը գերազանցել է A և B վաճառողներին IOPS-ում գրեթե կրկնակի, իսկ C վաճառողին՝ ավելի քան հինգ անգամ: Cisco HyperFlex-ի միջին արձագանքման ժամանակը 8,2 ms էր: Համեմատության համար նշենք, որ A վաճառողի համար միջին արձագանքման ժամանակը եղել է 30,6 ms, վաճառողի B-ի համար՝ 12,8 ms, իսկ վաճառողի C-ի համար՝ 10,33 ms:
Բոլոր թեստերի ժամանակ մի հետաքրքիր դիտարկում է արվել. Վաճառողը B ցույց է տվել IOPS-ի միջին կատարողականի զգալի փոփոխություն տարբեր VM-ների վրա: Այսինքն՝ ծանրաբեռնվածությունը բաշխվել է ծայրահեղ անհավասարաչափ, որոշ VM-ներ աշխատել են 1000 IOPS+ միջին արժեքով, իսկ որոշները՝ 64 IOPS արժեքով։ Cisco HyperFlex-ն այս դեպքում շատ ավելի կայուն տեսք ուներ, բոլոր 140 VM-ները պահեստավորման ենթահամակարգից ստացան միջինը 600 IOPS, այսինքն՝ վիրտուալ մեքենաների միջև բեռը շատ հավասարաչափ բաշխվեց:
Կարևոր է նշել, որ IOPS-ի նման անհավասար բաշխում վիրտուալ մեքենաների վրա վաճառողի B-ում նկատվել է փորձարկման յուրաքանչյուր կրկնության ժամանակ:
Իրական արտադրության մեջ համակարգի այս պահվածքը կարող է մեծ խնդիր լինել ադմինիստրատորների համար, իրականում առանձին վիրտուալ մեքենաներ պատահականորեն սկսում են սառչել, և գործնականում չկա այս գործընթացը վերահսկելու միջոց: Բալանսը բեռնելու միակ, ոչ այնքան հաջող միջոցը, երբ օգտագործում եք լուծում վաճառողի կողմից, այս կամ այն QoS կամ հավասարակշռող իրականացումն օգտագործելն է:
Արտադրողականություն
Եկեք մտածենք, թե Cisco Hyperflex-ն ինչ վիրտուալ մեքենա ունի 140 ֆիզիկական հանգույցի համար՝ 1 կամ պակաս այլ լուծումների դիմաց: Բիզնեսի համար սա նշանակում է, որ Hyperflex-ում նույն թվով հավելվածներ աջակցելու համար ձեզ անհրաժեշտ են 70 անգամ ավելի քիչ հանգույցներ, քան մրցակից լուծումներում, այսինքն. վերջնական համակարգը շատ ավելի էժան կլինի։ Եթե այստեղ ավելացնենք ցանցի, սերվերների և պահեստավորման հարթակի HX Data Platform-ի պահպանման բոլոր գործողությունների ավտոմատացման մակարդակը, պարզ է դառնում, թե ինչու են Cisco Hyperflex լուծումներն այդքան արագ ժողովրդականություն ձեռք բերում շուկայում:
Ընդհանուր առմամբ, ESG Labs-ը հաստատել է, որ Cisco HyperFlex Hybrid HX 3.0-ն ապահովում է ավելի արագ և հետևողական կատարում, քան մյուս համեմատելի լուծումները:
Միևնույն ժամանակ, HyperFlex հիբրիդային կլաստերները նույնպես առաջ են անցել մրցակիցներից IOPS-ի և Latency-ի առումով: Հավասարապես կարևոր է, որ HyperFlex-ի կատարումը ձեռք է բերվել շատ լավ բաշխված բեռով ողջ պահեստում:
Հիշեցնենք, որ Cisco Hyperflex լուծումը կարող եք տեսնել և ստուգել դրա հնարավորությունները հենց հիմա։ Համակարգը հասանելի է բոլորին ցուցադրելու համար.
Source: www.habr.com