AERODISK Շարժիչ. աղետների դիմադրություն: Մաս 2. Մետրոկլաստեր

Բարև, Habr ընթերցողներ: Վերջին հոդվածում մենք խոսեցինք AERODISK ENGINE պահեստավորման համակարգերում աղետի վերականգնման պարզ միջոցի՝ կրկնօրինակման մասին։ Այս հոդվածում մենք կխորանանք ավելի բարդ և հետաքրքիր թեմայի մեջ՝ մետրոկլաստեր, այսինքն՝ երկու տվյալների կենտրոնների աղետներից ավտոմատացված պաշտպանության միջոց, որը թույլ է տալիս տվյալների կենտրոններին աշխատել ակտիվ-ակտիվ ռեժիմով: Մենք ձեզ կասենք, ցույց կտանք, կկոտրենք ու կշտկենք։

Ինչպես միշտ, նախ տեսությունը

Մետրոկլաստերը մի կլաստեր է, որը տարածված է քաղաքի կամ տարածաշրջանի մի քանի վայրերում: «Կլաստեր» բառը մեզ հստակ ակնարկում է, որ համալիրը ավտոմատացված է, այսինքն՝ խափանումների դեպքում կլաստերի հանգույցների անցումը տեղի է ունենում ավտոմատ կերպով:

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

Ինչ է դա անել:

Հիմնական նպատակը, որին հետևում են հաճախորդները, երբ օգտագործում են որոշակի մետրոկլաստերների իրականացում, նվազագույնի հասցնելն է RTO-ն (Վերականգնման ժամանակի նպատակը): Այսինքն՝ ձախողումից հետո ՏՏ ծառայությունների վերականգնման ժամանակը նվազագույնի հասցնել։ Եթե ​​դուք օգտագործում եք կանոնավոր կրկնօրինակում, ապա վերականգնման ժամանակը միշտ ավելի երկար կլինի, քան մետրոկլաստերի վերականգնման ժամանակը: Ինչո՞ւ։ Շատ պարզ. Ադմինիստրատորը պետք է լինի իր գրասեղանի մոտ և ձեռքով փոխի վերարտադրությունը, և մետրոկլաստերը դա անում է ավտոմատ կերպով:

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

Համապատասխանաբար, RTO-ն ադմինիստրատորի հերթապահ ծառայության 99-րդ մակարդակի մետրոկլաստերի կամ անմահ ադմինի բացակայության դեպքում հավասար կլինի բոլոր համակարգերի միացման ժամանակի գումարին և այն առավելագույն ժամանակահատվածին, որից հետո ադմինիստրատորը երաշխավորված է սկսել աշխատանքը: պահեստավորման համակարգերով և հարակից համակարգերով:

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

Ինչպես է դա աշխատում.

Ստորին մակարդակում մետրոկլաստերը օգտագործում է տվյալների համաժամանակյա վերարտադրության մեխանիզմ, որը մենք նկարագրել ենք նախորդ հոդվածում (տես. ՈՒղեցույց) Քանի որ կրկնօրինակումը համաժամանակյա է, դրա համար պահանջները համապատասխան են, ավելի ճիշտ.

• օպտիկական մանրաթել, որպես ֆիզիկա, 10 գիգաբիթ Ethernet (կամ ավելի բարձր);
• տվյալների կենտրոնների միջև հեռավորությունը 40 կիլոմետրից ոչ ավելի է.
• օպտիկական ալիքի հետաձգումը տվյալների կենտրոնների միջև (պահեստավորման համակարգերի միջև) կազմում է մինչև 5 միլիվայրկյան (օպտիմալը 2):

Այս բոլոր պահանջներն իրենց բնույթով խորհրդատվական են, այսինքն՝ մետրոկլաստերը կաշխատի, նույնիսկ եթե այդ պահանջները չկատարվեն, բայց մենք պետք է հասկանանք, որ այդ պահանջներին չհամապատասխանելու հետևանքները հավասար են երկու պահեստային համակարգերի աշխատանքի դանդաղմանը։ մետրոկլաստերը։

Այսպիսով, համաժամանակյա կրկնօրինակն օգտագործվում է տվյալների պահպանման համակարգերի միջև փոխանցելու համար, և ինչպե՞ս են կրկնօրինակները ավտոմատ կերպով փոխարկվում և, ամենակարևորը, ինչպես խուսափել ուղեղի պառակտումից: Դա անելու համար ավելի բարձր մակարդակում օգտագործվում է լրացուցիչ սուբյեկտ՝ արբիտր:

Ինչպե՞ս է աշխատում արբիտրը և ո՞րն է նրա խնդիրը:

Արբիտրը փոքր վիրտուալ մեքենա է կամ ապարատային կլաստեր, որը պետք է գործարկվի երրորդ կայքում (օրինակ՝ գրասենյակում) և ապահովի մուտք դեպի պահեստավորման համակարգ ICMP-ի և SSH-ի միջոցով: Գործարկումից հետո արբիտրը պետք է սահմանի IP-ն, այնուհետև պահեստային կողմից նշի դրա հասցեն, գումարած հեռակառավարման սարքերի հասցեները, որոնք մասնակցում են մետրոկլաստերին: Սրանից հետո մրցավարը պատրաստ է աշխատել։

Արբիտրը մշտապես վերահսկում է մետրոկլաստերի բոլոր պահեստավորման համակարգերը և եթե որոշակի պահեստային համակարգ անհասանելի է, ապա կլաստերի մեկ այլ անդամից («կենդանի» պահպանման համակարգերից մեկը) անհասանելիությունը հաստատելուց հետո նա որոշում է սկսել վերարտադրման կանոնների փոխարկման ընթացակարգը: և քարտեզագրում։

Շատ կարևոր կետ. Արբիտրը միշտ պետք է տեղակայված լինի այնպիսի վայրում, որտեղ գտնվում են պահեստավորման համակարգերը, այսինքն՝ ոչ տվյալների կենտրոնում 1, որտեղ տեղադրված է պահեստային համակարգը 1, և ոչ էլ տվյալների կենտրոնում 2, որտեղ տեղադրված է պահեստային համակարգը 2:

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

Հիմա եկեք խորանանք արբիտրի աշխատանքի մանրամասների մեջ:

Արբիտրը վարում է մի քանի ծառայություններ, որոնք մշտապես հարցում են անում պահեստավորման բոլոր կարգավորիչներին: Եթե ​​հարցման արդյունքը տարբերվում է նախորդից (հասանելի/անհասանելի), ապա այն գրանցվում է փոքր տվյալների բազայում, որն աշխատում է նաև արբիտրի վրա։

Եկեք ավելի մանրամասն նայենք արբիտրի աշխատանքի տրամաբանությանը։

Քայլ 1. Որոշել անհասանելիությունը: Պահպանման համակարգի ձախողման իրադարձությունը 5 վայրկյանի ընթացքում նույն պահեստային համակարգի երկու կարգավորիչներից պինգի բացակայությունն է:

Քայլ 2. Սկսեք միացման ընթացակարգը: Այն բանից հետո, երբ մրցավարը հասկանում է, որ պահեստավորման համակարգերից մեկը անհասանելի է, նա հարցում է ուղարկում «կենդանի» պահպանման համակարգին, որպեսզի համոզվի, որ «մեռած» պահեստավորման համակարգը իսկապես մեռած է:

Արբիտրից նման հրաման ստանալուց հետո երկրորդ (կենդանի) պահեստավորման համակարգը լրացուցիչ ստուգում է ընկած առաջին պահեստավորման համակարգի առկայությունը և, եթե այն չկա, հաստատում է ուղարկում իր գուշակության արբիտրին: Պահպանման համակարգն իսկապես անհասանելի է:

Նման հաստատում ստանալուց հետո արբիտրը սկսում է վերարտադրությունը փոխելու և քարտեզագրումը բարձրացնելու հեռակա ընթացակարգ այն կրկնօրինակների վրա, որոնք ակտիվ էին (առաջնային) ընկած պահեստավորման համակարգում, և հրաման է ուղարկում պահեստավորման երկրորդ համակարգին՝ այդ կրկնօրինակները երկրորդականից առաջնային և փոխելու համար: բարձրացնել քարտեզագրումը. Դե, երկրորդ պահեստավորման համակարգը, համապատասխանաբար, կատարում է այս ընթացակարգերը, այնուհետև ինքն իրենից ապահովում է կորցրած LUN-ների մուտքը:

Ինչու է անհրաժեշտ լրացուցիչ ստուգում: Քվորումի համար. Այսինքն՝ կլաստերի անդամների ընդհանուր կենտ (3) թվի մեծամասնությունը պետք է հաստատի կլաստերի հանգույցներից մեկի անկումը։ Միայն այդ դեպքում այս որոշումը միանշանակ ճիշտ կլինի։ Սա անհրաժեշտ է սխալ փոխարկումից և, համապատասխանաբար, ուղեղի պառակտումից խուսափելու համար:

Ժամանակի քայլ 2-ը տևում է մոտավորապես 5-10 վայրկյան, հետևաբար, հաշվի առնելով անհասանելիությունը որոշելու համար պահանջվող ժամանակը (5 վայրկյան), վթարից հետո 10-15 վայրկյանի ընթացքում, ընկած պահեստավորման համակարգից LUN-ները ավտոմատ կերպով հասանելի կլինեն ուղիղ կապի հետ աշխատելու համար: պահեստավորման համակարգ.

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

Սպասեք մի վայրկյան, պարզվում է, որ եթե մետրոկլաստերի հետ ամեն ինչ այդքան լավ է, ինչի՞ն է մեզ ընդհանրապես պետք կանոնավոր կրկնօրինակումը:

Իրականում ամեն ինչ այնքան էլ պարզ չէ.

Դիտարկենք մետրոկլաստերի դրական և բացասական կողմերը

Այսպիսով, մենք հասկացանք, որ մետրոկլաստերի ակնհայտ առավելությունները սովորական վերարտադրության համեմատ հետևյալն են.

• Ամբողջական ավտոմատացում՝ ապահովելով նվազագույն վերականգնման ժամանակ աղետի դեպքում;
• Այսքանը :-):

Եվ հիմա, ուշադրություն, թերություններ.

• Լուծման արժեքը. Չնայած Aerodisk համակարգերում մետրոկլաստերը չի պահանջում լրացուցիչ լիցենզավորում (նույն լիցենզիան օգտագործվում է, ինչ կրկնօրինակի համար), լուծման արժեքը դեռ ավելի բարձր կլինի, քան համաժամանակյա կրկնօրինակումը: Դուք պետք է կատարեք բոլոր պահանջները համաժամանակյա կրկնօրինակի համար, գումարած պահանջները մետրոկլաստերի համար, որոնք կապված են լրացուցիչ անջատման և լրացուցիչ կայքէջի հետ (տես մետրոկլաստերային պլանավորում);
• Լուծման բարդությունը. Մետրոկլաստերը շատ ավելի բարդ է, քան սովորական կրկնօրինակը և պահանջում է շատ ավելի մեծ ուշադրություն և ջանք պլանավորման, կազմաձևման և փաստաթղթավորման համար:

Ի վերջո. Metrocluster-ը, անշուշտ, շատ տեխնոլոգիապես առաջադեմ և լավ լուծում է, երբ իսկապես անհրաժեշտ է RTO տրամադրել վայրկյանների կամ րոպեների ընթացքում: Բայց եթե նման խնդիր չկա, իսկ RTO-ն ժամերով նորմալ է բիզնեսի համար, ապա իմաստ չունի թնդանոթից ճնճղուկներ կրակել։ Սովորական բանվոր-գյուղացի կրկնօրինակումը բավարար է, քանի որ մետրոպոլիտենի կլաստերը լրացուցիչ ծախսեր և ՏՏ ենթակառուցվածքի բարդացում կառաջացնի:

Մետրոկլաստերի պլանավորում

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

Վայրեր

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

Տվյալների կենտրոնների միջև առաջարկվող հեռավորությունը 40 կիլոմետրից ոչ ավելի է: Ավելի մեծ հեռավորությունը կարող է առաջացնել լրացուցիչ ուշացումներ, որոնք մետրոկլաստերի դեպքում չափազանց անցանկալի են: Հիշեցնենք, որ ուշացումները պետք է լինեն մինչև 5 միլիվայրկյան, թեև ցանկալի է դրանք պահել 2-ի սահմաններում։

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

Ինչ վերաբերում է արբիտրի առջև ուշացումներին (այսինքն՝ երրորդ կայքի և առաջին երկուսի միջև), ապա առաջարկվող ուշացման շեմը մինչև 200 միլիվայրկյան է, այսինքն՝ հարմար է սովորական կորպորատիվ VPN կապը ինտերնետով:

Անցում և ցանցային միացում

Ի տարբերություն կրկնօրինակման սխեմայի, որտեղ բավական է միացնել պահեստավորման համակարգերը տարբեր կայքերից, մետրոկլաստերային սխեման պահանջում է միացնել հոսթները երկու պահեստային համակարգերի հետ տարբեր կայքերում: Որպեսզի ավելի պարզ լինի, թե որն է տարբերությունը, երկու սխեմաները ներկայացված են ստորև:

Ինչպես երևում է գծապատկերից, մեր կայքի 1-ի հոսթերը նայում են և՛ պահեստավորման համակարգ 1, և՛ պահեստավորման համակարգ 2։ Այսինքն, յուրաքանչյուր հյուրընկալող տեսնում է երկու պահեստավորման համակարգերը: Սա նախապայման է մետրոկլաստերի շահագործման համար։

Իհարկե, կարիք չկա յուրաքանչյուր հոսթին միացնել օպտիկական լարով մեկ այլ տվյալների կենտրոնին, ոչ մի նավահանգիստ կամ լար բավարար չի լինի: Այս բոլոր միացումները պետք է իրականացվեն Ethernet 10G+ կամ FibreChannel 8G+ անջատիչների միջոցով (FC-ը նախատեսված է միայն IO-ի հոսթինգների և պահեստավորման համակարգերի միացման համար, իսկ վերարտադրման ալիքը ներկայումս հասանելի է միայն IP-ի միջոցով (Ethernet 10G+):

Հիմա մի քանի խոսք ցանցի տոպոլոգիայի մասին։ Կարևոր կետը ենթացանցերի ճիշտ կազմաձևումն է: Անհրաժեշտ է անհապաղ սահմանել մի քանի ենթացանցեր տրաֆիկի հետևյալ տեսակների համար.

• Կրկնվող ենթացանց, որի միջոցով տվյալները կհամաժամեցվեն պահեստավորման համակարգերի միջև: Դրանցից կարող են լինել մի քանիսը, այս դեպքում դա նշանակություն չունի, ամեն ինչ կախված է ընթացիկ (արդեն իրականացված) ցանցի տոպոլոգիայից։ Եթե ​​դրանցից երկուսը կան, ապա ակնհայտորեն երթուղավորումը պետք է կազմաձևվի նրանց միջև.
• Պահպանման ենթացանցեր, որոնց միջոցով հոսթները մուտք կունենան պահեստային ռեսուրսներ (եթե դա iSCSI է): Յուրաքանչյուր տվյալների կենտրոնում պետք է լինի մեկ այդպիսի ենթացանց.
• Վերահսկիչ ենթացանցեր, այսինքն՝ երեք ուղղորդվող ենթացանցեր երեք կայքերում, որոնցից կառավարվում են պահեստավորման համակարգերը, և այնտեղ է գտնվում նաև արբիտրը։

Մենք այստեղ չենք համարում ենթացանցեր՝ հյուրընկալող ռեսուրսներ մուտք գործելու համար, քանի որ դրանք մեծապես կախված են առաջադրանքներից:

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

Արբիտրի կոնֆիգուրացիա

Արբիտրը պետք է ապահովի մուտք դեպի պահեստավորման համակարգի բոլոր կառավարման միջերեսներ ICMP և SSH արձանագրությունների միջոցով: Պետք է նաև մտածել արբիտրի անհաջողության մասին: Այստեղ մի նրբերանգ կա.

Արբիտրի ձախողումը շատ ցանկալի է, բայց ոչ պարտադիր: Ի՞նչ է պատահում, եթե մրցավարը վթարի է ենթարկվում սխալ ժամանակ:

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

Ի՞նչ է հետևում սրանից։ Եթե ​​դուք իսկապես պետք է ապահովեք նվազագույն RTO, դուք պետք է ապահովեք, որ արբիտրը սխալների նկատմամբ հանդուրժող է: Դրա համար կա երկու տարբերակ.

• Գործարկեք վիրտուալ մեքենա արբիտրի հետ սխալ հանդուրժող հիպերվիզորի վրա, բարեբախտաբար բոլոր չափահաս հիպերվիզորները աջակցում են սխալների հանդուրժողականությանը;
• Եթե ​​երրորդ կայքում (սովորական գրասենյակում) դուք չափազանց ծույլ եք տեղադրել սովորական կլաստեր, և չկա գոյություն ունեցող hypervozor կլաստեր, ապա մենք տրամադրել ենք արբիտրի ապարատային տարբերակը, որը պատրաստված է 2U տուփի մեջ, որի մեջ կան երկու սովորական x-86 սերվերները աշխատում են, և որոնք կարող են գոյատևել տեղական ձախողումից:

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

Լուծման ճարտարապետություն

Հաշվի առնելով վերը նշված պահանջները, մենք ստանում ենք լուծման հետևյալ ընդհանուր ճարտարապետությունը.

LUN-ները պետք է հավասարաչափ բաշխվեն երկու տեղամասերում՝ խիստ ծանրաբեռնվածությունից խուսափելու համար: Միևնույն ժամանակ, երկու տվյալների կենտրոններում չափերը չափելիս պետք է ներառել ոչ միայն կրկնակի ծավալ (որն անհրաժեշտ է տվյալների միաժամանակ պահպանման համար երկու պահեստային համակարգերում), այլ նաև կրկնակի կատարողականություն IOPS-ում և ՄԲ/վ-ում՝ կիրառման դեգրադացիան կանխելու համար: տվյալների կենտրոններից մեկի խափանման դեպքը. ov.

Առանձին-առանձին մենք նշում ենք, որ չափերի ճիշտ մոտեցմամբ (այսինքն՝ պայմանով, որ մենք տրամադրել ենք IOPS-ի և ՄԲ/վ-ի պատշաճ վերին սահմանները, ինչպես նաև անհրաժեշտ պրոցեսորային և RAM ռեսուրսները), եթե պահեստային համակարգերից մեկը մետրոյի կլաստերը խափանում է, մեկ պահեստավորման համակարգի վրա ժամանակավոր աշխատանքի պայմաններում կատարողականի լուրջ անկում չի լինի։

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

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

Մետրոկլաստերի ստեղծում

Metrocluster-ի ստեղծումը շատ նման է սովորական կրկնօրինակման տեղադրմանը, որը մենք նկարագրել ենք նախորդ հոդվածը. Ուստի կենտրոնանանք միայն տարբերությունների վրա։ Մենք լաբորատորիայում տեղադրեցինք նստարան՝ հիմնվելով վերը նշված ճարտարապետության վրա, միայն նվազագույն տարբերակով՝ երկու պահեստային համակարգ միացված 10G Ethernet-ի միջոցով, երկու 10G անջատիչներ և մեկ հոսթ, որը նայում է 10G պորտով երկու պահեստային համակարգերի անջատիչների միջով: Արբիտրն աշխատում է վիրտուալ մեքենայի վրա:

Վիրտուալ IP-ները (VIP) կրկնօրինակի համար կարգավորելիս պետք է ընտրել VIP տեսակը՝ մետրոկլաստերի համար:

Մենք ստեղծեցինք երկու վերարտադրող հղում երկու LUN-ի համար և դրանք բաշխեցինք երկու պահեստավորման համակարգերում՝ LUN TEST Primary պահեստավորման համակարգում 1 (METRO հղում), LUN TEST2 Հիմնական պահեստավորման համակարգի համար 2 (METRO2 հղում):

Նրանց համար մենք կազմաձևեցինք երկու նույնական թիրախներ (մեր դեպքում iSCSI, բայց FC-ն նույնպես ապահովված է, տեղադրման տրամաբանությունը նույնն է):

Պահպանման համակարգ 1:

Պահպանման համակարգ 2:

Կրկնօրինակման միացումների համար քարտեզագրումներ են կատարվել յուրաքանչյուր պահեստավորման համակարգի վրա:

Պահպանման համակարգ 1:

Պահպանման համակարգ 2:

Մենք ստեղծեցինք բազմուղի և ներկայացրեցինք հյուրընկալողին:

Արբիտրի ստեղծում

Ձեզ հարկավոր չէ որևէ հատուկ բան անել արբիտրի հետ, պարզապես անհրաժեշտ է այն միացնել երրորդ կայքում, տալ IP և կարգավորել մուտքը դեպի այն ICMP-ի և SSH-ի միջոցով: Կարգավորումն ինքնին կատարվում է հենց պահեստավորման համակարգերից: Այս դեպքում բավական է մեկ անգամ կարգավորել արբիտրը մետրոկլաստերի պահեստային կարգավորիչներից որևէ մեկի վրա, այս կարգավորումները ավտոմատ կերպով կբաշխվեն բոլոր կարգավորիչներին:

Բաժնում Remote replication>> Metrocluster (ցանկացած կարգավորիչի վրա)>> «Կարգավորել» կոճակը:

Մենք մուտքագրում ենք արբիտրի IP-ն, ինչպես նաև երկու հեռակառավարման կարգավորիչների կառավարման միջերեսները:

Դրանից հետո դուք պետք է միացնեք բոլոր ծառայությունները («Վերագործարկեք ամեն ինչ» կոճակը): Ապագայում վերակազմավորվելու դեպքում ծառայությունները պետք է վերագործարկվեն, որպեսզի կարգավորումներն ուժի մեջ մտնեն:

Մենք ստուգում ենք, որ բոլոր ծառայություններն աշխատում են:

Սա ավարտում է մետրոկլաստերի կարգավորումը:

Վթարի թեստ

Խափանման թեստը մեր դեպքում կլինի բավականին պարզ և արագ, քանի որ վերարտադրման գործառույթը (անջատում, հետևողականություն և այլն) քննարկվել է ս. վերջին հոդվածը. Հետևաբար, մետրոկլաստերի հուսալիությունը ստուգելու համար մեզ համար բավական է ստուգել խափանումների հայտնաբերման ավտոմատացումը, անջատումը և գրանցման կորուստների բացակայությունը (I/O կանգառներ):

Դա անելու համար մենք ընդօրինակում ենք պահեստավորման համակարգերից մեկի ամբողջական ձախողումը` ֆիզիկապես անջատելով դրա երկու կարգավորիչները, նախ սկսելով մեծ ֆայլ պատճենել LUN-ում, որը պետք է ակտիվացվի մյուս պահեստավորման համակարգում:

Անջատեք մեկ պահպանման համակարգը: Երկրորդ պահեստավորման համակարգում մենք տեսնում ենք տեղեկամատյաններում ահազանգեր և հաղորդագրություններ այն մասին, որ կապը հարևան համակարգի հետ կորել է: Եթե ​​SMTP կամ SNMP մոնիտորինգի միջոցով ծանուցումները կազմաձևված են, ադմինիստրատորը կստանա համապատասխան ծանուցումներ:

Ուղիղ 10 վայրկյան անց (տեսանելի է երկու սքրինշոթներում), METRO-ի կրկնօրինակման կապը (այն, որը առաջնային էր ձախողված պահեստավորման համակարգում) ավտոմատ կերպով դարձել է Առաջնային աշխատող պահեստավորման համակարգում: Օգտագործելով գոյություն ունեցող քարտեզագրումը, LUN TEST-ը հասանելի մնաց հաղորդավարին, ձայնագրությունը մի փոքր ընկավ (խոստացված 10 տոկոսի սահմաններում), բայց չընդհատվեց:

Թեստը հաջողությամբ ավարտվեց:

Ամփոփելով

AERODISK Engine N- շարքի պահեստավորման համակարգերում մետրոկլաստերի ներկայիս ներդրումը լիովին թույլ է տալիս լուծել այն խնդիրները, որտեղ անհրաժեշտ է վերացնել կամ նվազագույնի հասցնել ՏՏ ծառայությունների համար անգործությունը և ապահովել դրանց շահագործումը 24/7/365՝ նվազագույն աշխատուժի ծախսերով:

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

Շնորհակալություն, մենք ակնկալում ենք արդյունավետ քննարկում:

Source: www.habr.com