Սա միֆ է, որը բավականին տարածված է սերվերի ապարատային ոլորտում։ Գործնականում հիպերկոնվերգացված լուծումներ (երբ ամեն ինչ մեկում է) անհրաժեշտ են շատ բաների համար։ Պատմականորեն առաջին ճարտարապետությունները մշակվել են Amazon-ի և Google-ի կողմից իրենց ծառայությունների համար: Հետո գաղափարն այն էր, որ միանման հանգույցներից հաշվողական ֆերմա պատրաստելն էր, որոնցից յուրաքանչյուրն ուներ իր սեփական սկավառակները: Այս ամենը միավորվել է համակարգ ձևավորող որոշ ծրագրերով (հիպերվիզոր) և բաժանվել վիրտուալ մեքենաների։ Հիմնական նպատակը մեկ հանգույցի սպասարկման համար նվազագույն ջանք է գործադրում և մասշտաբավորման ժամանակ նվազագույն խնդիրներ. պարզապես գնել ևս մեկ հազար կամ երկու նույն սերվերներ և միացնել դրանք մոտակայքում: Գործնականում սրանք մեկուսացված դեպքեր են, և շատ ավելի հաճախ մենք խոսում ենք ավելի փոքր թվով հանգույցների և մի փոքր այլ ճարտարապետության մասին:
Բայց գումարածը մնում է նույնը` մասշտաբի և կառավարման անհավանական հեշտությունը: Բացասական կողմն այն է, որ տարբեր առաջադրանքներն այլ կերպ են սպառում ռեսուրսները, և որոշ տեղերում կլինեն շատ լոկալ սկավառակներ, որոշ տեղերում՝ քիչ RAM և այլն, այսինքն՝ տարբեր տեսակի առաջադրանքների համար ռեսուրսների օգտագործումը կնվազի։
Ստացվում է, որ դուք 10-15% ավելի շատ եք վճարում տեղադրման հեշտության համար: Ահա թե ինչն է առաջացրել վերնագրի առասպելը: Մենք երկար ժամանակ փնտրեցինք, թե որտեղ է տեխնոլոգիան օպտիմալ կերպով կիրառվելու, և գտանք այն: Փաստն այն է, որ Cisco-ն չուներ սեփական պահեստավորման համակարգեր, բայց նրանք ցանկանում էին ամբողջական սերվերների շուկա: Եվ նրանք պատրաստեցին Cisco Hyperflex-ը՝ լուծում հանգույցների վրա տեղային պահեստով:
Եվ սա հանկարծ պարզվեց, որ շատ լավ լուծում է պահեստային տվյալների կենտրոնների համար (Disaster Recovery): Հիմա կասեմ՝ ինչու և ինչպես: Եվ ես ձեզ ցույց կտամ կլաստերի թեստերը:
Այնտեղ, որտեղ անհրաժեշտ է
Հիպերկոնվերգենցիան հետևյալն է.
- Սկավառակների փոխանցում հաշվողական հանգույցներին:
- Պահպանման ենթահամակարգի ամբողջական ինտեգրումը վիրտուալացման ենթահամակարգին:
- Փոխանցում/ինտեգրում ցանցի ենթահամակարգին:
Այս համադրությունը թույլ է տալիս վիրտուալիզացիայի մակարդակում իրականացնել պահեստավորման համակարգի բազմաթիվ առանձնահատկություններ և բոլորը մեկ կառավարման պատուհանից:
Մեր ընկերությունում ավելորդ տվյալների կենտրոնների նախագծման նախագծերը մեծ պահանջարկ ունեն, և հիպերկոնվերգացված լուծումը հաճախ ընտրվում է կրկնօրինակման մի շարք տարբերակների պատճառով (մինչև մետրոկլաստեր):
Պահուստային տվյալների կենտրոնների դեպքում մենք սովորաբար խոսում ենք քաղաքի մյուս կողմում գտնվող կայքում կամ ընդհանրապես մեկ այլ քաղաքում գտնվող հեռավոր օբյեկտի մասին: Այն թույլ է տալիս վերականգնել կարևոր համակարգերը հիմնական տվյալների կենտրոնի մասնակի կամ ամբողջական ձախողման դեպքում: Վաճառքի տվյալները անընդհատ կրկնօրինակվում են այնտեղ, և այդ կրկնօրինակումը կարող է լինել հավելվածի կամ բլոկային սարքի (պահեստավորման) մակարդակում:
Հետևաբար, հիմա ես կխոսեմ համակարգի նախագծման և թեստերի մասին, այնուհետև մի քանի իրական կիրառական սցենարների մասին՝ խնայողությունների տվյալներով:
Թեստեր
Մեր օրինակը բաղկացած է չորս սերվերից, որոնցից յուրաքանչյուրն ունի 10 ԳԲ ծավալով 960 SSD սկավառակ: Կա հատուկ սկավառակ՝ գրելու գործողությունները քեշավորելու և ծառայության վիրտուալ մեքենան պահելու համար: Լուծումն ինքնին չորրորդ տարբերակն է։ Առաջինն անկեղծորեն անմշակ է (դատելով ակնարկներից), երկրորդը խոնավ է, երրորդն արդեն բավականին կայուն է, և սա կարելի է անվանել թողարկում լայն հանրության համար բետա թեստավորման ավարտից հետո: Փորձարկման ժամանակ ես ոչ մի խնդիր չտեսա, ամեն ինչ աշխատում է ժամացույցի պես:
Փոփոխություններ v4-ումՄի փունջ սխալներ շտկվել են:
Սկզբում հարթակը կարող էր աշխատել միայն VMware ESXi հիպերվիզորի հետ և աջակցում էր փոքր թվով հանգույցների։ Նաև տեղակայման գործընթացը միշտ չէ, որ հաջողությամբ ավարտվում էր, որոշ քայլեր պետք է վերագործարկվեին, խնդիրներ կային ավելի հին տարբերակներից թարմացնելու հետ կապված, GUI-ում տվյալները միշտ չէ, որ ճիշտ էին ցուցադրվում (չնայած ես դեռ գոհ չեմ կատարողականի գծապատկերների ցուցադրումից: ), երբեմն խնդիրներ են առաջանում վիրտուալացման միջերեսում:
Այժմ մանկության բոլոր խնդիրները շտկվել են, HyperFlex-ը կարող է կարգավորել և՛ ESXi, և՛ Hyper-V, գումարած, որ հնարավոր է.
- Ձգված կլաստերի ստեղծում:
- Գրասենյակների համար կլաստերի ստեղծում՝ առանց Fabric Interconnect-ի օգտագործման, երկուից չորս հանգույց (մենք գնում ենք միայն սերվերներ):
- Արտաքին պահեստավորման համակարգերի հետ աշխատելու ունակություն:
- Աջակցություն բեռնարկղերի և Kubernetes-ի համար:
- Հասանելիության գոտիների ստեղծում.
- Ինտեգրում VMware SRM-ի հետ, եթե ներկառուցված ֆունկցիոնալությունը բավարար չէ:
Ճարտարապետությունը շատ չի տարբերվում իր հիմնական մրցակիցների լուծումներից՝ նրանք հեծանիվ չեն ստեղծել։ Ամեն ինչ աշխատում է VMware կամ Hyper-V վիրտուալացման հարթակի վրա: Սարքավորումը տեղակայված է սեփական Cisco UCS սերվերների վրա: Կան նրանք, ովքեր ատում են հարթակը սկզբնական տեղադրման հարաբերական բարդության, շատ կոճակների, ձևանմուշների և կախվածությունների ոչ տրիվիալ համակարգի համար, բայց կան նաև այնպիսիք, ովքեր սովորել են Զենին, ոգեշնչված են գաղափարով և այլևս չեն ուզում։ աշխատել այլ սերվերների հետ:
Մենք կդիտարկենք լուծումը VMware-ի համար, քանի որ լուծումն ի սկզբանե ստեղծվել է դրա համար և ունի ավելի շատ ֆունկցիոնալություն; Hyper-V-ն ավելացվել է ճանապարհին, որպեսզի չընկնի մրցակիցների հետ և բավարարի շուկայի ակնկալիքները:
Կա սկավառակներով լի սերվերների կլաստեր: Կան տվյալների պահպանման սկավառակներ (SSD կամ HDD՝ ըստ ձեր ճաշակի և կարիքների), կա մեկ SSD սկավառակ՝ քեշավորման համար։ Տվյալների պահեստում տվյալներ գրելիս տվյալները պահվում են քեշավորման շերտում (նվիրված SSD սկավառակ և ծառայության VM RAM): Զուգահեռաբար տվյալների բլոկ է ուղարկվում կլաստերի հանգույցներին (հանգույցների թիվը կախված է կլաստերի կրկնօրինակման գործակիցից): Բոլոր հանգույցներից հաջող ձայնագրման հաստատումից հետո ձայնագրության հաստատումն ուղարկվում է հիպերվիզորին, այնուհետև VM-ին: Ձայնագրված տվյալները կրկնօրինակվում են, սեղմվում և գրվում են ֆոնային պահեստային սկավառակների վրա: Միևնույն ժամանակ, մեծ բլոկը միշտ գրվում է պահեստային սկավառակների վրա և հաջորդաբար, ինչը նվազեցնում է պահեստային սկավառակների բեռը:
Կրկնօրինակումը և սեղմումը միշտ միացված են և չեն կարող անջատվել: Տվյալները կարդում են անմիջապես պահեստային սկավառակներից կամ RAM-ի քեշից: Եթե օգտագործվում է հիբրիդային կոնֆիգուրացիա, ընթերցումները նույնպես պահվում են SSD-ի վրա:
Տվյալները կապված չեն վիրտուալ մեքենայի ընթացիկ գտնվելու վայրի հետ և հավասարապես բաշխվում են հանգույցների միջև: Այս մոտեցումը թույլ է տալիս հավասարապես բեռնել բոլոր սկավառակները և ցանցային միջերեսները: Կա մի ակնհայտ թերություն. մենք չենք կարող հնարավորինս նվազեցնել ընթերցման հետաձգումը, քանի որ տեղական տվյալների հասանելիության երաշխիք չկա: Բայց ես կարծում եմ, որ սա չնչին զոհաբերություն է՝ համեմատած ստացված օգուտների հետ։ Ավելին, ցանցի հետաձգումները հասել են այնպիսի արժեքների, որ դրանք գործնականում չեն ազդում ընդհանուր արդյունքի վրա։
Հատուկ ծառայության VM Cisco HyperFlex Data Platform կարգավորիչը, որը ստեղծվել է յուրաքանչյուր պահեստավորման հանգույցի վրա, պատասխանատու է սկավառակի ենթահամակարգի ողջ գործառնական տրամաբանության համար: Մեր ծառայության VM կոնֆիգուրացիայում հատկացվել է ութ vCPU և 72 ԳԲ օպերատիվ հիշողություն, ինչն այնքան էլ քիչ չէ։ Հիշեցնեմ, որ հոսթն ինքն ունի 28 ֆիզիկական միջուկ և 512 ԳԲ օպերատիվ հիշողություն։
VM ծառայությունը մուտք ունի ֆիզիկական սկավառակներ ուղղակիորեն՝ փոխանցելով SAS վերահսկիչը VM-ին: Հիպերվիզորի հետ հաղորդակցությունը տեղի է ունենում հատուկ IOVisor մոդուլի միջոցով, որը ընդհատում է I/O գործողությունները և օգտագործելով գործակալ, որը թույլ է տալիս հրամաններ ուղարկել հիպերվիզորի API-ին: Գործակալը պատասխանատու է HyperFlex snapshots-ի և clones-ի հետ աշխատելու համար:
Սկավառակի ռեսուրսները տեղադրվում են հիպերվիզորում որպես NFS կամ SMB բաժնետոմսեր (կախված հիպերվիզորի տեսակից, գուշակեք, թե որն է որտեղ է): Եվ գլխարկի տակ սա բաշխված ֆայլային համակարգ է, որը թույլ է տալիս ավելացնել մեծահասակների լիարժեք պահեստավորման համակարգերի առանձնահատկությունները. բարակ ծավալի տեղաբաշխում, սեղմում և կրկնօրինակում, նկարահանումներ Redirect-on-Write տեխնոլոգիայի օգտագործմամբ, համաժամանակյա/ասինխրոն կրկնօրինակում:
VM ծառայությունն ապահովում է մուտք դեպի HyperFlex ենթահամակարգի WEB կառավարման ինտերֆեյս: Կա ինտեգրում vCenter-ի հետ, և ամենօրյա առաջադրանքների մեծ մասը կարող է կատարվել դրանից, բայց տվյալների պահեստները, օրինակ, ավելի հարմար է կտրել առանձին վեբ-տեսախցիկից, եթե արդեն անցել եք արագ HTML5 ինտերֆեյսի կամ օգտագործում եք լիարժեք Flash հաճախորդ: ամբողջական ինտեգրմամբ։ Ծառայության վեբ-տեսախցիկում կարող եք դիտել համակարգի աշխատանքը և մանրամասն կարգավիճակը:
Կլաստերում կա մեկ այլ տեսակի հանգույց՝ հաշվողական հանգույցներ։ Սրանք կարող են լինել դարակային կամ blade սերվերներ առանց ներկառուցված սկավառակների: Այս սերվերները կարող են գործարկել VM-ներ, որոնց տվյալները պահվում են սկավառակներով սերվերների վրա: Տվյալների հասանելիության տեսանկյունից տարբերություն չկա հանգույցների տեսակների միջև, քանի որ ճարտարապետությունը ներառում է տվյալների ֆիզիկական տեղակայման վերացականում։ Հաշվողական հանգույցների և պահեստավորման հանգույցների առավելագույն հարաբերակցությունը 2:1 է:
Հաշվարկային հանգույցների օգտագործումը մեծացնում է ճկունությունը կլաստերային ռեսուրսների չափման ժամանակ. մենք ստիպված չենք լինի լրացուցիչ հանգույցներ գնել սկավառակներով, եթե մեզ անհրաժեշտ է միայն CPU/RAM: Բացի այդ, մենք կարող ենք ավելացնել blade cage և խնայել սերվերների դարակների տեղադրումը:
Արդյունքում մենք ունենք հիպերկոնվերգացված հարթակ հետևյալ հատկանիշներով.
- Կլաստերում մինչև 64 հանգույց (մինչև 32 պահեստային հանգույց):
- Կլաստերում հանգույցների նվազագույն թիվը երեքն է (երկուսը Edge կլաստերի համար):
- Տվյալների ավելցուկային մեխանիզմ. արտացոլում կրկնօրինակման գործոնով 2 և 3:
- Մետրոյի կլաստեր.
- Ասինխրոն VM կրկնօրինակում մեկ այլ HyperFlex կլաստերի:
- VM-ները հեռավոր տվյալների կենտրոնին անցնելու կազմակերպում:
- Բնական պատկերներ՝ օգտագործելով Redirect-on-Write տեխնոլոգիան:
- Մինչև 1 PB օգտագործելի տարածք կրկնօրինակման գործակցով 3 և առանց կրկնօրինակման: Մենք հաշվի չենք առնում կրկնօրինակման գործոնը 2, քանի որ սա լուրջ վաճառքի տարբերակ չէ։
Մեկ այլ հսկայական առավելություն կառավարման և տեղակայման հեշտությունն է: UCS սերվերների տեղադրման բոլոր բարդությունները հոգում է Cisco-ի ինժեներների կողմից պատրաստված մասնագիտացված VM-ը:
Փորձարկման նստարանի կոնֆիգուրացիա.
- 2 x Cisco UCS Fabric Interconnect 6248UP որպես կառավարման կլաստեր և ցանցի բաղադրիչներ (48 պորտ, որը գործում է Ethernet 10G/FC 16G ռեժիմում):
- Չորս Cisco UCS HXAF240 M4 սերվեր:
Սերվերի բնութագրերը.
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 ԳԲ DDR4-2400-MHz RDIMM/PC4-19200/երկակի աստիճան/x4/1.2v
Ցանց
UCSC-MLOM-CSC-02 (VIC 1227): 2 10G Ethernet պորտ
Պահպանման HBA
Cisco 12G մոդուլային SAS Անցում վերահսկիչի միջոցով
Պահպանման սկավառակներ
1 x SSD Intel S3520 120 ԳԲ, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 ԳԲ
Կազմաձևման ավելի շատ տարբերակներԲացի ընտրված սարքաշարից, ներկայումս հասանելի են հետևյալ տարբերակները.
- HXAF240c M5.
- Մեկ կամ երկու պրոցեսոր՝ Intel Silver 4110-ից մինչև Intel Platinum I8260Y: Երկրորդ սերունդը հասանելի է:
- Հիշողության 24 սլոտ, ժապավեններ 16 ԳԲ RDIMM 2600-ից մինչև 128 ԳԲ LRDIMM 2933:
- 6-ից 23 տվյալների սկավառակ, մեկ քեշավորման սկավառակ, մեկ համակարգային սկավառակ և մեկ բեռնման սկավառակ:
Հզորության կրիչներ
- HX-SD960G61X-EV 960GB 2.5 Inch Enterprise Value 6G SATA SSD (1X դիմացկունություն) SAS 960 GB:
- HX-SD38T61X-EV 3.8TB 2.5 inch Enterprise Value 6G SATA SSD (1X տոկունություն) SAS 3.8 TB:
- Սկավառակների քեշավորում
- HX-NVMEXPB-I375 375GB 2.5 դյույմ Intel Optane Drive, Extreme Perf & Endurance:
- HX-NVMEHW-H1600* 1.6TB 2.5 դյույմ Ent. Պերֆ. NVMe SSD (3X դիմացկունություն) NVMe 1.6 TB:
- HX-SD400G12TX-EP 400GB 2.5 դյույմ Ent. Պերֆ. 12G SAS SSD (10X դիմացկունություն) SAS 400 ԳԲ:
- HX-SD800GBENK9** 800GB 2.5 դյույմ Ent. Պերֆ. 12G SAS SED SSD (10X դիմացկունություն) SAS 800 ԳԲ:
- HX-SD16T123X-EP 1.6TB 2.5 դյույմ Ձեռնարկությունների կատարողականություն 12G SAS SSD (3X դիմացկունություն):
Համակարգի/տեղեկամատյանների կրիչներ
- HX-SD240GM1X-EV 240GB 2.5 դյույմ ձեռնարկության արժեք 6G SATA SSD (Պահանջում է թարմացում):
Բեռնարկիչ կրիչներ
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB:
Միացեք ցանցին 40G, 25G կամ 10G Ethernet պորտերի միջոցով:
FI-ն կարող է լինել HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G):
Թեստի ինքնին
Սկավառակի ենթահամակարգը փորձարկելու համար ես օգտագործել եմ HCIBench 2.2.1: Սա անվճար կոմունալ ծրագիր է, որը թույլ է տալիս ավտոմատացնել բազմաթիվ վիրտուալ մեքենաներից բեռի ստեղծումը: Բեռը ինքնին առաջանում է սովորական fio-ով:
Մեր կլաստերը բաղկացած է չորս հանգույցներից, կրկնօրինակման գործակից 3, բոլոր սկավառակները Flash են:
Փորձարկման համար ես ստեղծեցի չորս տվյալների պահեստ և ութ վիրտուալ մեքենաներ: Գրելու թեստերի համար ենթադրվում է, որ քեշավորման սկավառակը լի չէ:
Թեստի արդյունքները հետևյալն են.
100% Կարդացեք 100% Պատահական
0% Կարդացեք 100% Պատահական
Արգելափակման/հերթի խորությունը
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36ms 374348 IOPS
2.47 ms 414116 IOPS
4,86ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Թավը ցույց է տալիս արժեքներ, որոնցից հետո արտադրողականության աճ չի նկատվում, երբեմն նույնիսկ դեգրադացիա է երևում: Դա պայմանավորված է նրանով, որ մենք սահմանափակված ենք ցանցի/կարգավորիչների/սկավառակների աշխատանքով:
- Հերթական ընթերցում 4432 ՄԲ/վ:
- Հերթական գրություն 804 ՄԲ/վ:
- Եթե վերահսկիչներից մեկը ձախողվի (վիրտուալ մեքենայի կամ հյուրընկալողի ձախողում), կատարողականի անկումը կրկնակի է:
- Եթե պահեստավորման սկավառակը ձախողվի, ապա կրճատումը 1/3 է: Սկավառակի վերակառուցումը վերցնում է յուրաքանչյուր վերահսկիչի ռեսուրսների 5%-ը:
Փոքր բլոկի վրա մենք սահմանափակվում ենք վերահսկիչի (վիրտուալ մեքենայի) գործունակությամբ, նրա պրոցեսորը բեռնված է 100%-ով, իսկ երբ բլոկը մեծանում է, մենք սահմանափակվում ենք պորտի թողունակությամբ: 10 Գբիտ/վրկ արագությունը բավարար չէ AllFlash համակարգի ներուժը բացելու համար: Ցավոք, տրամադրված ցուցադրական ստենդի պարամետրերը թույլ չեն տալիս փորձարկել աշխատանքը 40 Գբիթ/վրկ արագությամբ:
Իմ տպավորությամբ՝ թեստերից և ճարտարապետությունը ուսումնասիրելուց, ալգորիթմի շնորհիվ, որը տվյալները տեղադրում է բոլոր հոսթների միջև, մենք ստանում ենք մասշտաբային, կանխատեսելի կատարում, բայց սա նաև սահմանափակում է կարդալիս, քանի որ հնարավոր կլինի ավելի շատ քամել տեղական սկավառակներից, Այստեղ այն կարող է խնայել ավելի արդյունավետ ցանց, օրինակ՝ հասանելի է FI 40 Գբիտ/վ արագությամբ:
Բացի այդ, քեշավորման և կրկնօրինակման մեկ սկավառակը կարող է սահմանափակում լինել, փաստորեն, այս փորձնական հարթակում մենք կարող ենք գրել չորս SSD սկավառակի վրա: Հիանալի կլիներ, եթե կարողանայիք ավելացնել քեշավորման կրիչների քանակը և տեսնել տարբերությունը:
Իրական օգտագործումը
Պահուստային տվյալների կենտրոն կազմակերպելու համար կարող եք օգտագործել երկու մոտեցում (մենք չենք դիտարկում հեռավոր կայքում պահուստավորման տեղադրումը).
- Ակտիվ-պասիվ. Բոլոր հավելվածները տեղակայված են տվյալների հիմնական կենտրոնում: Կրկնօրինակումը համաժամանակյա կամ ասինխրոն է: Եթե հիմնական տվյալների կենտրոնը ձախողվի, մենք պետք է ակտիվացնենք պահեստայինը: Դա կարելի է անել ձեռքով/սկրիպտներ/նվագախմբի հավելվածներ: Այստեղ մենք կստանանք RPO, որը համարժեք է կրկնօրինակման հաճախականությանը, և RTO-ն կախված է ադմինիստրատորի արձագանքից և հմտություններից և փոխարկման պլանի մշակման/վրիպազերծման որակից:
- Ակտիվ-Ակտիվ. Այս դեպքում կա միայն համաժամանակյա կրկնօրինակում, տվյալների կենտրոնների առկայությունը որոշվում է քվորումի/արբիտրի կողմից, որը գտնվում է խստորեն երրորդ կայքում: RPO = 0, իսկ RTO-ն կարող է հասնել 0-ի (եթե հավելվածը թույլ է տալիս) կամ հավասար է վիրտուալացման կլաստերի հանգույցի ձախողման ժամանակին: Վիրտուալացման մակարդակում ստեղծվում է ձգված (Metro) կլաստեր, որը պահանջում է Active-Active պահեստավորում:
Սովորաբար մենք տեսնում ենք, որ հաճախորդները հիմնական տվյալների կենտրոնում արդեն ներդրել են ճարտարապետություն դասական պահեստավորման համակարգով, ուստի մենք նախագծում ենք ևս մեկը կրկնօրինակման համար: Ինչպես նշեցի, Cisco HyperFlex-ն առաջարկում է ասինխրոն կրկնօրինակում և ձգված վիրտուալացման կլաստերի ստեղծում: Միևնույն ժամանակ, մեզ անհրաժեշտ չէ հատուկ պահպանման համակարգ՝ միջին և ավելի բարձր մակարդակի, թանկարժեք կրկնօրինակման գործառույթներով և երկու պահեստավորման համակարգերի վրա Active-Active տվյալների հասանելիությամբ:
Սցենար 1: Մենք ունենք առաջնային և պահեստային տվյալների կենտրոններ, վիրտուալացման հարթակ VMware vSphere-ում: Բոլոր արտադրողական համակարգերը տեղակայված են տվյալների հիմնական կենտրոնում, և վիրտուալ մեքենաների վերարտադրությունն իրականացվում է հիպերվիզորի մակարդակով, ինչը թույլ կտա խուսափել VM-ները միացված պահուստային տվյալների կենտրոնում: Մենք կրկնօրինակում ենք տվյալների բազաները և հատուկ հավելվածները՝ օգտագործելով ներկառուցված գործիքները և միացված ենք պահում VM-ները: Եթե հիմնական տվյալների կենտրոնը ձախողվի, մենք համակարգեր ենք գործարկում պահեստային տվյալների կենտրոնում: Մենք կարծում ենք, որ ունենք մոտ 100 վիրտուալ մեքենա։ Մինչ հիմնական տվյալների կենտրոնը գործում է, սպասման տվյալների կենտրոնը կարող է գործարկել փորձնական միջավայրեր և այլ համակարգեր, որոնք կարող են անջատվել, եթե առաջնային տվյալների կենտրոնը միանա: Հնարավոր է նաև, որ մենք օգտագործում ենք երկկողմանի կրկնօրինակում: Սարքավորման տեսանկյունից ոչինչ չի փոխվի։
Դասական ճարտարապետության դեպքում մենք յուրաքանչյուր տվյալների կենտրոնում կտեղադրենք հիբրիդային պահեստավորման համակարգ՝ հասանելիությամբ FibreChannel-ի միջոցով, աստիճանավորում, կրկնօրինակում և սեղմում (բայց ոչ առցանց), 8 սերվեր յուրաքանչյուր կայքի համար, 2 FibreChannel անջատիչ և 10G Ethernet: Դասական ճարտարապետության մեջ կրկնօրինակման և փոխարկման կառավարման համար մենք կարող ենք օգտագործել VMware գործիքներ (Replication + SRM) կամ երրորդ կողմի գործիքներ, որոնք կլինեն մի փոքր ավելի էժան և երբեմն ավելի հարմար:
Նկարը ցույց է տալիս դիագրամը:
Cisco HyperFlex-ն օգտագործելիս ստացվում է հետևյալ ճարտարապետությունը.
HyperFlex-ի համար ես օգտագործել եմ CPU/RAM մեծ ռեսուրսներով սերվերներ, քանի որ... Ռեսուրսների մի մասը կգնա HyperFlex վերահսկիչ VM-ին, պրոցեսորի և հիշողության առումով ես նույնիսկ մի փոքր վերակազմավորեցի HyperFlex-ի կոնֆիգուրացիան, որպեսզի չխաղամ Cisco-ի հետ և երաշխավորեմ ռեսուրսներ մնացած VM-ների համար: Բայց մենք կարող ենք հրաժարվել FibreChannel անջատիչներից, և մեզ անհրաժեշտ չեն լինի Ethernet պորտեր յուրաքանչյուր սերվերի համար, տեղական տրաֆիկը փոխարկվում է FI-ի ներսում:
Արդյունքը յուրաքանչյուր տվյալների կենտրոնի համար հետևյալ կազմաձևումն էր.
Սերվերներ
8 x 1U սերվեր (384 ԳԲ RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 ԳԲ RAM, 2 x Intel Gold 6150, 3,2 ԳԲ SSD, 10 x 6 TB NL-SAS)
SHD
Հիբրիդային պահեստավորման համակարգ FC Front-End-ով (20TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet անջատիչ 10G 12 պորտ
-
SAN
2 x FC switch 32/16Gb 24 պորտ
2 x Cisco UCS FI 6332
Լիցենզիա
VMware Ent Plus
VM փոխարկման կրկնօրինակում և (կամ) կազմակերպում
VMware Ent Plus
Ես չեմ տրամադրել կրկնօրինակման ծրագրային ապահովման լիցենզիաներ Hyperflex-ի համար, քանի որ սա մեզ համար հասանելի է առանց տուփի:
Դասական ճարտարապետության համար ես ընտրեցի մի վաճառող, ով հաստատվել է որպես բարձրորակ և էժան արտադրող: Երկու տարբերակի համար էլ կոնկրետ լուծման համար կիրառեցի ստանդարտ զեղչ, և արդյունքում ստացա իրական գներ։
Cisco HyperFlex լուծումը պարզվեց, որ 13%-ով ավելի էժան է։
Սցենար 2: երկու ակտիվ տվյալների կենտրոնների ստեղծում: Այս սցենարում մենք նախագծում ենք ձգված կլաստեր VMware-ի վրա:
Դասական ճարտարապետությունը բաղկացած է վիրտուալացման սերվերներից, SAN-ից (FC արձանագրություն) և երկու պահեստավորման համակարգերից, որոնք կարող են կարդալ և գրել իրենց միջև ձգված ծավալով: Յուրաքանչյուր պահեստավորման համակարգի վրա մենք տեղադրում ենք պահեստավորման օգտակար հզորություն:
HyperFlex-ում մենք պարզապես ստեղծում ենք Stretch Cluster երկու կայքերում նույն թվով հանգույցներով: Այս դեպքում օգտագործվում է 2+2 կրկնօրինակման գործակից:
Արդյունքը հետևյալ կոնֆիգուրացիան է.
դասական ճարտարապետություն
HyperFlex
Սերվերներ
16 x 1U սերվեր (384 ԳԲ RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 ԳԲ RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x AllFlash պահեստավորման համակարգեր (150 TB SSD)
-
LAN
4 x Ethernet անջատիչ 10G 24 պորտ
-
SAN
4 x FC switch 32/16Gb 24 պորտ
4 x Cisco UCS FI 6332
Լիցենզիա
VMware Ent Plus
VMware Ent Plus
Բոլոր հաշվարկներում ես հաշվի չեմ առել ցանցային ենթակառուցվածքը, տվյալների կենտրոնի ծախսերը և այլն. դրանք նույնը կլինեն դասական ճարտարապետության և HyperFlex լուծման համար:
Արժեքի առումով HyperFlex-ը 5%-ով ավելի թանկ է ստացվել։ Այստեղ հարկ է նշել, որ CPU/RAM ռեսուրսների առումով ես Cisco-ի համար թեքություն ունեի, քանի որ կոնֆիգուրացիայի մեջ ես հավասարաչափ լցրեցի հիշողության կարգավորիչի ալիքները: Արժեքը մի փոքր ավելի բարձր է, բայց ոչ մեծության կարգով, ինչը հստակ ցույց է տալիս, որ հիպերկոնվերգենցիան պարտադիր չէ, որ «խաղալիք լինի հարուստների համար», բայց կարող է մրցակցել տվյալների կենտրոն կառուցելու ստանդարտ մոտեցման հետ: Սա կարող է նաև հետաքրքրել նրանց, ովքեր արդեն ունեն Cisco UCS սերվերներ և նրանց համար համապատասխան ենթակառուցվածք:
Առավելություններից մենք ստանում ենք SAN և պահեստավորման համակարգերի կառավարման ծախսերի բացակայություն, առցանց սեղմում և կրկնօրինակում, աջակցության մեկ մուտքի կետ (վիրտուալացում, սերվերներ, դրանք նաև պահեստավորման համակարգեր են), տարածքի խնայողություն (բայց ոչ բոլոր սցենարներում): հեշտացնելով աշխատանքը.
Ինչ վերաբերում է աջակցությանը, այստեղ այն ստանում եք մեկ վաճառողից՝ Cisco-ից: Դատելով Cisco UCS սերվերների հետ իմ փորձից՝ ինձ այն դուր է գալիս, ես ստիպված չէի բացել այն HyperFlex-ում, ամեն ինչ նույնն էր աշխատում: Ինժեներները արագ արձագանքում են և կարող են լուծել ոչ միայն բնորոշ խնդիրները, այլև բարդ եզրային դեպքեր: Երբեմն ես դիմում եմ նրանց հարցերով. կամ «Ես ինչ-որ բան կարգավորեցի այստեղ, և այն չի ուզում աշխատել: Օգնություն!" - այնտեղ համբերատար կգտնեն անհրաժեշտ ուղեցույցը և մատնանշեն ճիշտ գործողությունները, չեն պատասխանի. «Մենք միայն ապարատային խնդիրներ ենք լուծում»։
Սայլակ
- Իմ փոստը - [էլեկտրոնային փոստով պաշտպանված]
Source: www.habr.com