Հիպերկոնվերգացված լուծում AERODISK vair. Հիմքը ARDFS ֆայլային համակարգն է

Ողջույն, Habr ընթերցողներ: Այս հոդվածով մենք բացում ենք մի շարք, որը կխոսի մեր մշակած AERODISK vaIR հիպերկոնվերգացիոն համակարգի մասին: Սկզբում մենք ուզում էինք ամեն ինչ պատմել ամեն ինչի մասին առաջին հոդվածում, բայց համակարգը բավականին բարդ է, ուստի մենք կուտենք փղին մաս-մաս։

Սկսենք պատմությունը համակարգի ստեղծման պատմությունից, խորանանք ARDFS ֆայլային համակարգի մեջ, որը հանդիսանում է vAIR-ի հիմքը, ինչպես նաև մի փոքր խոսենք ռուսական շուկայում այս լուծման դիրքավորման մասին:

Հետագա հոդվածներում մենք ավելի մանրամասն կխոսենք տարբեր ճարտարապետական ​​բաղադրիչների մասին (կլաստեր, հիպերվիզոր, բեռնվածքի հավասարակշռող, մոնիտորինգի համակարգ և այլն), կազմաձևման գործընթացի, լիցենզավորման հարցերը բարձրացնելու, առանձին-առանձին ցուցադրելու վթարի թեստեր և, իհարկե, գրել բեռների թեստավորման և չափագրում. Մենք նաև առանձին հոդված կնվիրենք vAIR-ի համայնքային տարբերակին:

Արդյո՞ք Aerodisk-ը պատմություն է պահեստավորման համակարգերի մասին: Կամ ինչու՞ սկզբում սկսեցինք հիպերկոնվերգենցիա անել:

Սկզբում մեր սեփական հիպերկոնվերգենցիան ստեղծելու գաղափարը մեզ մոտ ծագեց մոտ 2010 թ. Այն ժամանակ շուկայում չկար ոչ Aerodisk, ոչ էլ նմանատիպ լուծումներ (առևտրային տուփով հիպերկոնվերգացված համակարգեր): Մեր խնդիրը հետևյալն էր. տեղական սկավառակներով սերվերների մի շարքից, որոնք միավորված էին փոխկապակցման միջոցով Ethernet արձանագրության միջոցով, անհրաժեշտ էր ստեղծել ընդլայնված պահեստ և գործարկել այնտեղ վիրտուալ մեքենաներ և ծրագրային ցանց: Այս ամենը պետք է իրականացվեր առանց պահեստավորման համակարգերի (որովհետև պահեստավորման համակարգերի և դրա սարքավորումների համար փող պարզապես չկար, և մենք դեռ չէինք հորինել մեր սեփական պահեստավորման համակարգերը):

Մենք փորձեցինք բազմաթիվ բաց կոդով լուծումներ և վերջապես լուծեցինք այս խնդիրը, բայց լուծումը շատ բարդ էր և դժվար կրկնվող: Բացի այդ, այս լուծումը «Արդյո՞ք աշխատում է. Մի՛ դիպչիր։ Հետևաբար, լուծելով այդ խնդիրը, մենք հետագայում չզարգացրինք մեր աշխատանքի արդյունքը լիարժեք արտադրանքի վերածելու գաղափարը։

Այդ դեպքից հետո մենք հեռացանք այս մտքից, բայց դեռ այն զգացողությունն ունեինք, որ այս խնդիրը լիովին լուծելի է, իսկ նման լուծման առավելություններն առավել քան ակնհայտ էին։ Հետագայում արտասահմանյան ընկերությունների թողարկված HCI արտադրանքը միայն հաստատեց այս զգացումը:

Հետևաբար, 2016 թվականի կեսերին մենք վերադարձանք այս առաջադրանքին՝ որպես լիարժեք արտադրանքի ստեղծման մաս: Այն ժամանակ մենք դեռևս որևէ հարաբերություն չունեինք ներդրողների հետ, ուստի մենք ստիպված էինք գնել զարգացման ստենդ մեր սեփական ոչ այնքան մեծ գումարների համար: Avito-ում օգտագործված սերվերներ և անջատիչներ հավաքելով՝ մենք գործի անցանք:

Հիմնական նախնական խնդիրն էր ստեղծել մեր սեփական, թեև պարզ, բայց մեր սեփական ֆայլային համակարգը, որը կարող էր ավտոմատ և հավասարաչափ բաշխել տվյալները վիրտուալ բլոկների տեսքով n-րդ համարի կլաստերային հանգույցների վրա, որոնք միացված են Ethernet-ի միջոցով փոխկապակցման միջոցով: Միևնույն ժամանակ, FS-ը պետք է լավ և հեշտությամբ մասշտաբի և անկախ լինի հարակից համակարգերից, այսինքն. օտարվել vAIR-ից՝ «պարզապես պահեստավորման օբյեկտի» տեսքով:

Առաջին vAIR հայեցակարգը

Մենք միտումնավոր հրաժարվեցինք պատրաստի բաց կոդով լուծումների օգտագործումից՝ ձգված պահեստավորման կազմակերպման համար (ceph, gluster, luster և այլն) հօգուտ մեր սեփական զարգացման, քանի որ մենք արդեն ունեինք դրանց հետ նախագծային մեծ փորձ: Իհարկե, այս լուծումներն իրենք գերազանց են, և մինչ «Աերոդիսկի» վրա աշխատելը, մենք նրանց հետ իրականացրել ենք մեկից ավելի ինտեգրացիոն նախագիծ: Բայց մի բան է մեկ հաճախորդի համար կոնկրետ առաջադրանք իրականացնելը, անձնակազմին պատրաստելը և, հնարավոր է, գնել մեծ վաճառողի աջակցությունը, և բոլորովին այլ բան է ստեղծել հեշտությամբ կրկնվող արտադրանք, որը կօգտագործվի տարբեր խնդիրների համար, որոնք մենք՝ որպես վաճառող, գուցե նույնիսկ մեր մասին իմանանք, մենք չգիտենք: Երկրորդ նպատակով գոյություն ունեցող բաց կոդով արտադրանքները մեզ հարմար չէին, ուստի մենք որոշեցինք ինքներս ստեղծել բաշխված ֆայլային համակարգ։
Երկու տարի անց մի քանի ծրագրավորողներ (որոնք համատեղեցին vAIR-ի վրա աշխատանքը դասական Engine պահեստավորման համակարգի վրա) հասան որոշակի արդյունքի:

Մինչև 2018 թվականը մենք գրել էինք պարզ ֆայլային համակարգ և լրացրել այն անհրաժեշտ սարքավորումներով։ Համակարգը ներքին փոխկապակցման միջոցով միավորեց ֆիզիկական (տեղական) սկավառակները տարբեր սերվերներից մեկ հարթ լողավազանի մեջ և «կտրեց» դրանք վիրտուալ բլոկների, այնուհետև վիրտուալ բլոկներից ստեղծվեցին անսարքության տարբեր աստիճանի հանդուրժողականությամբ սարքեր, որոնց վրա ստեղծվեցին վիրտուալները։ և իրականացվել է KVM հիպերվիզոր մեքենաների միջոցով:

Մենք շատ չանհանգստացանք ֆայլային համակարգի անվան հետ և համառոտ այն անվանեցինք ARDFS (գուշակեք, թե ինչ է դա նշանակում))

Այս նախատիպը լավ տեսք ուներ (ոչ վիզուալ, իհարկե, դեռ վիզուալ դիզայն չկար) և լավ արդյունքներ ցույց տվեց կատարողականի և մասշտաբի առումով։ Առաջին իրական արդյունքից հետո մենք գործի դրեցինք այս նախագիծը՝ կազմակերպելով զարգացման լիարժեք միջավայր և առանձին թիմ, որը զբաղվում էր միայն vAIR-ով:

Հենց այդ ժամանակ արդեն հասունացել էր լուծման ընդհանուր ճարտարապետությունը, որը դեռ մեծ փոփոխությունների չի ենթարկվել։

Սուզվել ARDFS ֆայլային համակարգում

ARDFS-ը vAIR-ի հիմքն է, որն ապահովում է բաշխված, սխալ հանդուրժող տվյալների պահպանում ողջ կլաստերի վրա: ARDFS-ի (բայց ոչ միակ) տարբերակիչ առանձնահատկություններից մեկն այն է, որ այն չի օգտագործում որևէ լրացուցիչ հատուկ սերվեր մետատվյալների և կառավարման համար: Սա ի սկզբանե ստեղծվել էր լուծման կոնֆիգուրացիան պարզեցնելու և դրա հուսալիության համար:

Պահպանման կառուցվածքը

Կլաստերի բոլոր հանգույցներում ARDFS-ը կազմակերպում է տրամաբանական լողավազան բոլոր հասանելի սկավառակի տարածությունից: Կարևոր է հասկանալ, որ լողավազանը դեռևս տվյալների կամ ձևաչափված տարածք չէ, այլ պարզապես նշում է, այսինքն. Տեղադրված vAIR-ով ցանկացած հանգույց, երբ ավելացվում է կլաստերին, ավտոմատ կերպով ավելացվում են ընդհանուր ARDFS լողավազանում, իսկ սկավառակի ռեսուրսները ավտոմատ կերպով համօգտագործվում են ամբողջ կլաստերում (և հասանելի են ապագա տվյալների պահպանման համար): Այս մոտեցումը թույլ է տալիս արագորեն ավելացնել և հեռացնել հանգույցներ՝ առանց արդեն գործող համակարգի վրա որևէ լուրջ ազդեցության: Նրանք. համակարգը շատ հեշտ է մասշտաբավորել «աղյուսներով»՝ անհրաժեշտության դեպքում ավելացնելով կամ հեռացնելով կլաստերի հանգույցները:

ARDFS լողավազանի վերևում ավելացվում են վիրտուալ սկավառակներ (վիրտուալ մեքենաների պահեստավորման օբյեկտներ), որոնք կառուցված են 4 մեգաբայթ չափի վիրտուալ բլոկներից: Վիրտուալ սկավառակներն ուղղակիորեն պահում են տվյալները: Սխալների հանդուրժողականության սխեման նույնպես սահմանված է վիրտուալ սկավառակի մակարդակում:

Ինչպես արդեն կռահեցիք, սկավառակի ենթահամակարգի սխալ հանդուրժողականության համար մենք չենք օգտագործում RAID (անկախ սկավառակների ավելորդ զանգված), այլ օգտագործում ենք RAIN (անկախ հանգույցների ավելորդ զանգված): Նրանք. Սխալների հանդուրժողականությունը չափվում, ավտոմատացված և կառավարվում է ոչ թե սկավառակների, այլ հանգույցների հիման վրա: Սկավառակները, իհարկե, նաև պահեստավորման օբյեկտ են, դրանք, ինչպես և մնացած ամեն ինչ, վերահսկվում են, դրանցով կարող եք կատարել բոլոր ստանդարտ գործողությունները, ներառյալ տեղական ապարատային RAID հավաքելը, բայց կլաստերը գործում է հատուկ հանգույցների վրա:

Իրավիճակում, երբ դուք իսկապես ցանկանում եք RAID (օրինակ, մի սցենար, որն աջակցում է փոքր կլաստերների բազմաթիվ ձախողումների), ոչինչ չի խանգարում ձեզ օգտագործել տեղական RAID կարգավորիչներ և կառուցել երկարացված պահեստ և RAIN ճարտարապետություն վերևում: Այս սցենարը բավականին կենդանի է և աջակցվում է մեր կողմից, ուստի մենք կխոսենք դրա մասին vAIR-ի օգտագործման բնորոշ սցենարների մասին հոդվածում:

Պահպանման սխալների հանդուրժողականության սխեմաներ

VAIR-ում վիրտուալ սկավառակների անսարքության հանդուրժողականության երկու սխեման կարող է լինել.

1) Կրկնօրինակման գործոն կամ պարզապես կրկնօրինակում - սխալների հանդուրժողականության այս մեթոդը նույնքան պարզ է, որքան փայտը և պարանը: Սինխրոն կրկնօրինակումը կատարվում է հանգույցների միջև՝ 2 գործակցով (2 օրինակ մեկ կլաստերում) կամ 3 (համապատասխանաբար 3 օրինակ): RF-2-ը թույլ է տալիս վիրտուալ սկավառակին դիմակայել կլաստերի մեկ հանգույցի ձախողմանը, բայց «ուտում» է օգտակար ծավալի կեսը, իսկ RF-3-ը կդիմանա կլաստերի 2 հանգույցների ձախողմանը, բայց պահում է կլաստերի 2/3-ը։ օգտակար ծավալ իր կարիքների համար: Այս սխեման շատ նման է RAID-1-ին, այսինքն՝ RF-2-ում կազմաձևված վիրտուալ սկավառակը դիմացկուն է կլաստերի որևէ հանգույցի ձախողմանը: Այս դեպքում տվյալների հետ ամեն ինչ լավ կլինի, և նույնիսկ I/O-ն չի կանգնի: Երբ ընկած հանգույցը վերադառնում է ծառայության, կսկսվի տվյալների ավտոմատ վերականգնումը/համաժամացումը:

Ստորև բերված են RF-2 և RF-3 տվյալների բաշխման օրինակներ նորմալ ռեժիմում և ձախողման իրավիճակում:

Մենք ունենք 8 ՄԲ եզակի (օգտակար) տվյալներ ունեցող վիրտուալ մեքենա, որն աշխատում է 4 vAIR հանգույցների վրա։ Հասկանալի է, որ իրականում քիչ հավանական է, որ այդքան փոքր ծավալ լինի, բայց ARDFS-ի շահագործման տրամաբանությունն արտացոլող սխեմայի համար այս օրինակն ամենից հասկանալին է։ AB-ն 4 ՄԲ վիրտուալ բլոկներ են, որոնք պարունակում են եզակի վիրտուալ մեքենայի տվյալներ: RF-2-ը ստեղծում է այս բլոկների երկու օրինակ՝ համապատասխանաբար A1+A2 և B1+B2: Այս բլոկները «դասավորվում են» հանգույցների միջով՝ խուսափելով նույն հանգույցի վրա նույն տվյալների հատումից, այսինքն՝ պատճենը A1-ը չի գտնվի նույն հանգույցում, ինչ A2 պատճենը: Նույնը B1-ի և B2-ի դեպքում:

Եթե ​​հանգույցներից մեկը ձախողվի (օրինակ՝ թիվ 3 հանգույցը, որը պարունակում է B1-ի պատճենը), այս պատճենը ավտոմատ կերպով ակտիվանում է այն հանգույցում, որտեղ չկա դրա պատճենը (այսինքն՝ B2-ի պատճենը)։

Այսպիսով, վիրտուալ սկավառակը (և VM, համապատասխանաբար) կարող է հեշտությամբ գոյատևել RF-2 սխեմայի մեկ հանգույցի ձախողումից:

Կրկնօրինակման սխեման, թեև պարզ և հուսալի լինելով, տառապում է նույն խնդրից, ինչ RAID1-ը՝ ոչ բավարար օգտագործելի տարածք:

2) Ջնջման կոդավորումը կամ ջնջման կոդավորումը (նաև հայտնի է որպես «ավելորդ կոդավորում», «ջնջման կոդավորում» կամ «ավելորդության կոդ») գոյություն ունի վերը նշված խնդիրը լուծելու համար: EC-ը ավելորդության սխեմա է, որն ապահովում է տվյալների բարձր հասանելիություն՝ համեմատած կրկնօրինակման հետ համեմատած սկավառակի ավելի ցածր տարածության հետ: Այս մեխանիզմի շահագործման սկզբունքը նման է RAID 5, 6, 6P-ին:

Կոդավորելիս EC գործընթացը բաժանում է վիրտուալ բլոկը (4 ՄԲ լռելյայն) մի քանի ավելի փոքր «տվյալների կտորների»՝ կախված EC սխեմայից (օրինակ, 2+1 սխեման յուրաքանչյուր 4 ՄԲ բլոկը բաժանում է 2 2 ՄԲ-ի): Հաջորդը, այս գործընթացը առաջացնում է «հավասարաչափ կտորներ» «տվյալների կտորների» համար, որոնք ավելի մեծ չեն, քան նախկինում բաժանված մասերից մեկը: Վերծանելիս EC-ն առաջացնում է բացակայող հատվածները՝ կարդալով «գոյատեւած» տվյալները ողջ կլաստերի վրա:

Օրինակ, 2 + 1 EC սխեմայով վիրտուալ սկավառակը, որն իրականացվում է 4 կլաստերային հանգույցների վրա, հեշտությամբ կդիմանա կլաստերի մեկ հանգույցի ձախողմանը, ինչպես RF-2-ը: Այս դեպքում վերադիր ծախսերը ավելի ցածր կլինեն, մասնավորապես, RF-2-ի համար օգտակար հզորության գործակիցը 2 է, իսկ EC 2+1-ի համար՝ 1,5։

Ավելի պարզ նկարագրելու համար, էությունն այն է, որ վիրտուալ բլոկը բաժանված է 2-8 (ինչու 2-ից 8-ը, տես ստորև) «կտորների», և այդ կտորների համար հաշվարկվում են նույն ծավալի հավասարության «կտորներ»:

Արդյունքում, տվյալները և պարիտետը հավասարաչափ բաշխվում են կլաստերի բոլոր հանգույցներում: Միևնույն ժամանակ, ինչպես վերարտադրման դեպքում, ARDFS-ը ավտոմատ կերպով տվյալներ է բաշխում հանգույցների միջև այնպես, որ կանխի նույնական տվյալների (տվյալների պատճենները և դրանց հավասարությունը) պահպանումը նույն հանգույցում, որպեսզի վերացնի տվյալների կորստի հնարավորությունը: այն փաստին, որ տվյալները և դրանց հավասարությունը հանկարծ կհայտնվեն մեկ պահեստային հանգույցի վրա, որը ձախողվում է:

Ստորև բերված է օրինակ՝ նույն 8 ՄԲ վիրտուալ մեքենայով և 4 հանգույցով, բայց EC 2+1 սխեմայով։

A և B բլոկները բաժանված են երկու մասի՝ յուրաքանչյուրը 2 ՄԲ (երկուսը, քանի որ 2+1), այսինքն՝ A1+A2 և B1+B2։ Ի տարբերություն կրկնօրինակի՝ A1-ը A2-ի կրկնօրինակը չէ, այն վիրտուալ A բլոկ է, որը բաժանված է երկու մասի, նույնը՝ B բլոկը: Ընդհանուր առմամբ, մենք ստանում ենք 4 ՄԲ-ի երկու հավաքածու, որոնցից յուրաքանչյուրը պարունակում է երկու երկու ՄԲ կտոր: Հաջորդը, այս հավաքածուներից յուրաքանչյուրի համար հավասարությունը հաշվարկվում է մեկ հատից ոչ ավելի ծավալով (այսինքն՝ 2 ՄԲ), մենք ստանում ենք լրացուցիչ + 2 պարիտետ (AP և BP): Ընդհանուր առմամբ մենք ունենք 4×2 տվյալ + 2×2 պարիտետ։

Հաջորդը, կտորները «դասված» են հանգույցների միջև, որպեսզի տվյալները չհատվեն դրանց հավասարության հետ: Նրանք. A1-ը և A2-ը չեն լինի նույն հանգույցում, ինչ AP-ն:

Մի հանգույցի (օրինակ՝ նաև երրորդի) ձախողման դեպքում ընկած B1 բլոկը ավտոմատ կերպով կվերականգնվի BP պարիտետից, որը պահվում է թիվ 2 հանգույցում և կակտիվանա այն հանգույցում, որտեղ կա։ ոչ B-պարիտետ, այսինքն. կտոր BP. Այս օրինակում սա թիվ 1 հանգույցն է

Համոզված եմ, որ ընթերցողի մոտ հարց է առաջանում.

«Այն ամենը, ինչ դուք նկարագրել եք, վաղուց իրականացվել է ինչպես մրցակիցների, այնպես էլ բաց կոդով լուծումներում, ո՞րն է տարբերությունը ARDFS-ում EC-ի ձեր ներդրման միջև»:

Եվ հետո կլինեն ARDFS-ի հետաքրքիր առանձնահատկություններ:

Ջնջել կոդավորումը՝ կենտրոնանալով ճկունության վրա

Սկզբում մենք տրամադրեցինք բավականին ճկուն EC X+Y սխեմա, որտեղ X-ը հավասար է 2-ից մինչև 8 թվի, իսկ Y-ը հավասար է 1-ից 8 թվի, բայց միշտ փոքր է կամ հավասար է X-ին: Այս սխեման ներկայացված է: ճկունության համար։ Տվյալների մասերի (X) քանակի ավելացումը, որոնց բաժանվում է վիրտուալ բլոկը, թույլ է տալիս նվազեցնել ընդհանուր ծախսերը, այսինքն՝ ավելացնել օգտագործելի տարածքը:
Պարիտետների (Y) քանակի ավելացումը մեծացնում է վիրտուալ սկավառակի հուսալիությունը: Որքան մեծ է Y արժեքը, այնքան շատ հանգույցներ կլաստերի մեջ կարող են ձախողվել: Իհարկե, պարիտետի ծավալի ավելացումը նվազեցնում է օգտագործելի հզորության քանակը, բայց դա հուսալիության համար վճարվող գին է:

Կատարման կախվածությունը EC սխեմաներից գրեթե ուղղակի է. որքան շատ «կտորներ», այնքան ցածր է կատարումը, այստեղ, իհարկե, անհրաժեշտ է հավասարակշռված տեսակետ:

Այս մոտեցումը թույլ է տալիս ադմինիստրատորներին կարգավորել ձգված պահեստը առավելագույն ճկունությամբ: ARDFS լողավազանի ներսում կարող եք օգտագործել սխալների հանդուրժողականության ցանկացած սխեման և դրանց համակցությունները, ինչը, մեր կարծիքով, նույնպես շատ օգտակար է:

Ստորև բերված է աղյուսակ, որը համեմատում է ՌԴ և ԵՀ մի քանի (ոչ բոլոր հնարավոր) սխեմաները:

Աղյուսակը ցույց է տալիս, որ նույնիսկ EC 8+7 ամենահզոր համակցությունը, որը թույլ է տալիս միաժամանակ կորցնել մինչև 7 հանգույց կլաստերի մեջ, «ուտում» է ավելի քիչ օգտագործելի տարածք (1,875 ընդդեմ 2-ի), քան ստանդարտ վերարտադրությունը և պաշտպանում է 7 անգամ ավելի լավ։ , ինչը դարձնում է այս պաշտպանության մեխանիզմը, թեև ավելի բարդ, բայց շատ ավելի գրավիչ այն իրավիճակներում, երբ անհրաժեշտ է ապահովել առավելագույն հուսալիություն սկավառակի սահմանափակ տարածության պայմաններում: Միևնույն ժամանակ, դուք պետք է հասկանաք, որ X-ի կամ Y-ի յուրաքանչյուր «գումարած» կլինի լրացուցիչ կատարողականություն, ուստի հուսալիության, խնայողությունների և կատարողականի միջև եռանկյունու մեջ պետք է շատ ուշադիր ընտրել: Այդ իսկ պատճառով մենք առանձին հոդված կնվիրենք ջնջելու կոդավորման չափերը:

Ֆայլային համակարգի հուսալիություն և ինքնավարություն

ARDFS-ն աշխատում է լոկալ կլաստերի բոլոր հանգույցների վրա և համաժամացնում է դրանք՝ օգտագործելով իր սեփական միջոցները հատուկ Ethernet միջերեսների միջոցով: Կարևոր կետն այն է, որ ARDFS-ն ինքնուրույն համաժամացնում է ոչ միայն տվյալները, այլև պահեստավորման հետ կապված մետատվյալները։ ARDFS-ի վրա աշխատելիս մենք միաժամանակ ուսումնասիրեցինք մի շարք գոյություն ունեցող լուծումներ և հայտնաբերեցինք, որ շատերը համաժամացնում են ֆայլային համակարգի մետա՝ օգտագործելով արտաքին բաշխված DBMS, որը մենք օգտագործում ենք նաև համաժամացման համար, բայց միայն կոնֆիգուրացիաներ, ոչ թե FS մետատվյալներ (այս և հարակից այլ ենթահամակարգերի մասին: հաջորդ հոդվածում):

Արտաքին DBMS-ի միջոցով FS մետատվյալների համաժամացումը, իհարկե, աշխատանքային լուծում է, բայց այդ դեպքում ARDFS-ում պահվող տվյալների հետևողականությունը կախված կլինի արտաքին DBMS-ից և նրա վարքագծից (և, անկեղծ ասած, դա քմահաճ տիկին է), որը. մեր կարծիքը վատ է. Ինչո՞ւ։ Եթե ​​FS-ի մետատվյալները վնասվում են, FS-ի տվյալները կարող են նաև ասել «ցտեսություն», ուստի մենք որոշեցինք գնալ ավելի բարդ, բայց հուսալի ճանապարհով:

Մենք ինքներս ենք ստեղծել ARDFS-ի մետատվյալների համաժամացման ենթահամակարգը, և այն ապրում է հարակից ենթահամակարգերից լիովին անկախ: Նրանք. ոչ մի այլ ենթահամակարգ չի կարող փչացնել ARDFS տվյալները: Մեր կարծիքով, սա ամենահուսալի և ճիշտ ճանապարհն է, բայց ժամանակը ցույց կտա՝ իրականում այդպես է։ Բացի այդ, այս մոտեցմամբ կա լրացուցիչ առավելություն. ARDFS-ը կարող է օգտագործվել անկախ vAIR-ից, ճիշտ այնպես, ինչպես ձգված պահեստավորումը, որը մենք անպայման կօգտագործենք ապագա արտադրանքներում:

Արդյունքում, մշակելով ARDFS-ը, մենք ստացանք ճկուն և հուսալի ֆայլային համակարգ, որը հնարավորություն է տալիս ընտրություն կատարել, որտեղ դուք կարող եք խնայել հզորությունը կամ հրաժարվել ամեն ինչ կատարողականից, կամ ստեղծել ծայրահեղ հուսալի պահեստավորում ողջամիտ գնով, բայց նվազեցնելով կատարողականի պահանջները:

Պարզ լիցենզավորման քաղաքականության և առաքման ճկուն մոդելի հետ մեկտեղ (առաջին նայելով, vAIR-ը լիցենզավորված է հանգույցով և առաքվում է որպես ծրագրակազմ կամ որպես ծրագրային փաթեթ), սա թույլ է տալիս շատ ճշգրիտ լուծումը հարմարեցնել հաճախորդի պահանջներին և պահանջներին: ապա հեշտությամբ պահպանեք այս հավասարակշռությունը:

Ո՞ւմ է պետք այս հրաշքը։

Մի կողմից, կարելի է ասել, որ շուկայում արդեն կան խաղացողներ, որոնք լուրջ լուծումներ ունեն հիպերկոնվերգենցիայի ոլորտում, և մենք իրականում դեպի այստեղ ենք գնում։ Թվում է, թե այս հայտարարությունը ճիշտ է, ԲԱՅՑ...

Մյուս կողմից, երբ մենք դաշտ ենք դուրս գալիս և շփվում հաճախորդների հետ, մենք և մեր գործընկերները տեսնում ենք, որ դա ամենևին էլ այդպես չէ։ Հիպերկոնվերգենցիայի համար շատ առաջադրանքներ կան, որոշ տեղերում մարդիկ պարզապես չգիտեին, որ նման լուծումներ կան, որոշ տեղերում դա թանկ էր թվում, մյուսներում այլընտրանքային լուծումների անհաջող փորձարկումներ են եղել, իսկ որոշ տեղերում նրանք ընդհանրապես արգելում են գնել պատժամիջոցների պատճառով: Ընդհանրապես դաշտը չհերկվեց, գնացինք կուսական հող բարձրացնելու))):

Ե՞րբ է պահեստավորման համակարգը ավելի լավը, քան GCS-ը:

Շուկայի հետ աշխատելիս մեզ հաճախ հարցնում են, թե երբ է ավելի լավ օգտագործել դասական սխեման պահեստավորման համակարգերով, և երբ օգտագործել հիպերկոնվերգենտ: GCS արտադրող շատ ընկերություններ (հատկապես նրանք, որոնք չունեն պահեստավորման համակարգեր իրենց պորտֆելում) ասում են. «Պահպանման համակարգերը դառնում են հնացած, միայն հիպերկոնվերգացիոն»: Սա համարձակ հայտարարություն է, բայց այն ամբողջությամբ չի արտացոլում իրականությունը:

Իրականում պահեստավորման շուկան իսկապես շարժվում է դեպի հիպերկոնվերգենցիա և նմանատիպ լուծումներ, բայց միշտ կա «բայց»:

Նախ, տվյալների կենտրոնները և ՏՏ ենթակառուցվածքները, որոնք կառուցված են դասական սխեմայով պահեստավորման համակարգերով, չեն կարող հեշտությամբ վերակառուցվել, ուստի նման ենթակառուցվածքների արդիականացումը և ավարտը դեռևս ժառանգություն է 5-7 տարի:

Երկրորդ, ներկայումս կառուցվող ենթակառուցվածքը մեծ մասամբ (նկատի ունի Ռուսաստանի Դաշնությունը) կառուցված է դասական սխեմայով, օգտագործելով պահեստավորման համակարգեր, և ոչ թե այն պատճառով, որ մարդիկ չգիտեն հիպերկոնվերգենցիայի մասին, այլ այն պատճառով, որ հիպերկոնվերգենցիայի շուկան նոր է, լուծումներ և Չափանիշները դեռ չեն հաստատվել, ՏՏ ոլորտի մարդիկ դեռ վերապատրաստված չեն, նրանք քիչ փորձ ունեն, բայց այստեղ և հիմա պետք է տվյալների կենտրոններ կառուցեն: Եվ այս միտումը կտևի ևս 3-5 տարի (իսկ հետո մեկ այլ ժառանգություն, տե՛ս կետ 1):

Երրորդ, կա զուտ տեխնիկական սահմանափակում յուրաքանչյուր գրման համար 2 միլիվայրկյանանոց լրացուցիչ փոքր ուշացումների մեջ (իհարկե, բացառությամբ տեղական քեշի), որոնք բաշխված պահեստավորման արժեքն են:

Դե, եկեք չմոռանանք մեծ ֆիզիկական սերվերների օգտագործման մասին, որոնք սիրում են սկավառակի ենթահամակարգի ուղղահայաց մասշտաբումը:

Կան բազմաթիվ անհրաժեշտ և հայտնի առաջադրանքներ, որտեղ պահեստավորման համակարգերն իրենց ավելի լավ են պահում, քան GCS-ը: Այստեղ, իհարկե, այն արտադրողները, ովքեր չունեն պահեստավորման համակարգեր իրենց արտադրանքի պորտֆելում, մեզ հետ չեն համաձայնվի, բայց մենք պատրաստ ենք ողջամտորեն վիճել։ Իհարկե, մենք, որպես երկու արտադրանքի մշակողներ, անպայման կհամեմատենք պահեստավորման համակարգերը և GCS-ն մեր ապագա հրապարակումներից մեկում, որտեղ մենք հստակ ցույց կտանք, թե որն է ավելի լավը, ինչ պայմաններում:

Իսկ որտե՞ղ հիպերկոնվերգացված լուծումներն ավելի լավ կաշխատեն, քան պահեստավորման համակարգերը:

Ելնելով վերը նշված կետերից՝ կարելի է երեք ակնհայտ եզրակացություն անել.

1. Այն դեպքում, երբ ձայնագրման համար լրացուցիչ 2 միլիվայրկյան ուշացում, որը հետևողականորեն տեղի է ունենում ցանկացած արտադրանքի մեջ (հիմա մենք չենք խոսում սինթետիկների մասին, նանվայրկյանները կարող են ցուցադրվել սինթետիկների վրա), անկրիտիկ են, հիպերկոնվերգենտը հարմար է:
2. Այնտեղ, որտեղ մեծ ֆիզիկական սերվերներից բեռը կարող է վերածվել շատ փոքր վիրտուալների և բաշխվել հանգույցների միջև, հիպերկոնվերգենցիան նույնպես լավ կաշխատի այնտեղ:
3. Այնտեղ, որտեղ հորիզոնական մասշտաբն ավելի առաջնահերթություն է, քան ուղղահայաց մասշտաբը, GCS-ն այնտեղ նույնպես լավ կաշխատի:

Որո՞նք են այս լուծումները:

1. Բոլոր ստանդարտ ենթակառուցվածքային ծառայությունները (տեղեկատուի ծառայություն, փոստ, EDMS, ֆայլային սերվերներ, փոքր կամ միջին ERP և BI համակարգեր և այլն): Մենք սա անվանում ենք «ընդհանուր հաշվարկ»:
2. Ամպային մատակարարների ենթակառուցվածքը, որտեղ անհրաժեշտ է արագ և ստանդարտացված հորիզոնական ընդլայնել և հեշտությամբ «կտրել» հաճախորդների համար մեծ թվով վիրտուալ մեքենաներ:
3. Վիրտուալ աշխատասեղանի ենթակառուցվածք (VDI), որտեղ շատ փոքր օգտվողների վիրտուալ մեքենաներ աշխատում են և հանգիստ «լողում» միասնական կլաստերի մեջ:
4. Մասնաճյուղերի ցանցեր, որտեղ յուրաքանչյուր մասնաճյուղի կարիք ունի 15-20 վիրտուալ մեքենաների ստանդարտ, սխալ հանդուրժող, բայց ոչ թանկ ենթակառուցվածք:
5. Ցանկացած բաշխված հաշվարկ (օրինակ, մեծ տվյալների ծառայություններ): Որտեղ բեռը գնում է ոչ թե «խորքով», այլ «լայնությամբ»:
6. Փորձարկման միջավայրեր, որտեղ լրացուցիչ փոքր ուշացումները ընդունելի են, բայց կան բյուջեի սահմանափակումներ, քանի որ դրանք թեստեր են:

Այս պահին հենց այս խնդիրների համար ենք մենք արել AERODISK vair-ը և դրանց վրա ենք կենտրոնանում (առայժմ հաջողությամբ): Միգուցե դա շուտով կփոխվի, քանի որ... աշխարհը կանգ չի առնում.

Այսպիսով ...

Սա լրացնում է հոդվածների մեծ շարքի առաջին մասը, հաջորդ հոդվածում մենք կխոսենք լուծման ճարտարապետության և օգտագործվող բաղադրիչների մասին:

Մենք ողջունում ենք հարցեր, առաջարկություններ և կառուցողական վեճեր:

Source: www.habr.com