Բարև, Habr ընթերցողներ: Այս հոդվածի թեման կլինի աղետի վերականգնման գործիքների ներդրումը AERODISK Engine պահեստավորման համակարգերում: Սկզբում ցանկանում էինք մեկ հոդվածում գրել երկու գործիքների մասին՝ replication և metrocluster, բայց, ցավոք, հոդվածը չափազանց երկար ստացվեց, ուստի հոդվածը բաժանեցինք երկու մասի։ Եկեք անցնենք պարզից բարդի: Այս հոդվածում մենք կստեղծենք և կփորձարկենք համաժամանակյա վերարտադրությունը. մենք կթողնենք մեկ տվյալների կենտրոն, ինչպես նաև կխախտենք տվյալների կենտրոնների միջև կապի ալիքը և կտեսնենք, թե ինչ է տեղի ունենում:
Մեր հաճախորդները հաճախ մեզ տարբեր հարցեր են տալիս կրկնօրինակման վերաբերյալ, ուստի նախքան կրկնօրինակների տեղադրմանն ու փորձարկմանը անցնելը, մենք ձեզ մի փոքր կպատմենք այն մասին, թե ինչ է իրենից ներկայացնում կրկնօրինակումը պահեստում:
Մի քիչ տեսություն
Պահպանման համակարգերում կրկնօրինակումը մի քանի պահեստավորման համակարգերի վրա տվյալների նույնականության ապահովման շարունակական գործընթաց է: Տեխնիկապես կրկնօրինակումն իրականացվում է երկու եղանակով.
Սինխրոն կրկնօրինակում – սա տվյալների պատճենումն է հիմնական պահեստային համակարգից պահուստային, որին հաջորդում է երկու պահեստավորման համակարգերի պարտադիր հաստատում, որ տվյալները գրանցվել և հաստատվել են: Երկու կողմից (երկու պահեստավորման համակարգեր) հաստատումից հետո է, որ տվյալները համարվում են գրանցված և կարող են աշխատել: Սա ապահովում է տվյալների երաշխավորված նույնականությունը կրկնօրինակմանը մասնակցող բոլոր պահեստավորման համակարգերում:
Այս մեթոդի առավելությունները.
- Բոլոր պահեստավորման համակարգերում տվյալները միշտ նույնական են
Դեմ:
- Լուծման բարձր արժեքը (արագ կապի ալիքներ, թանկարժեք օպտիկական մանրաթել, երկար ալիքային հաղորդիչ և այլն)
- Հեռավորության սահմանափակումներ (մի քանի տասնյակ կիլոմետրի սահմաններում)
- Տրամաբանական տվյալների կոռուպցիայի դեմ պաշտպանություն չկա (եթե տվյալները կոռումպացված են (դիտավորյալ կամ պատահաբար) հիմնական պահեստային համակարգում, այն ավտոմատ և ակնթարթորեն կփչանա պահուստային համակարգում, քանի որ տվյալները միշտ նույնական են (դա պարադոքսն է)
Ասինխրոն կրկնօրինակում – սա նաև տվյալների պատճենումն է հիմնական պահեստային համակարգից պահուստային, բայց որոշակի ուշացումով և առանց մյուս կողմից գրառումը հաստատելու անհրաժեշտության: Տվյալների հետ կարող եք աշխատել հիմնական պահպանման համակարգում գրանցելուց անմիջապես հետո, իսկ պահեստային պահպանման համակարգում տվյալները հասանելի կլինեն որոշ ժամանակ անց: Տվյալների նույնականությունն այս դեպքում, իհարկե, բացարձակապես ապահովված չէ։ Պահուստային պահպանման համակարգի տվյալները միշտ մի փոքր «անցյալում են»:
Ասինխրոն կրկնօրինակման առավելությունները.
- Էժան լուծում (ցանկացած կապի ուղիներ, օպտիկա կամընտիր)
- Հեռավորության սահմանափակում չկա
- Պահուստային պահեստավորման համակարգում տվյալները չեն վատթարանում, եթե դրանք վնասված են հիմնականում (առնվազն որոշ ժամանակով), եթե տվյալները փչանան, դուք միշտ կարող եք դադարեցնել կրկնօրինակը, որպեսզի կանխեք տվյալների կոռուպցիան պահեստային պահեստավորման համակարգում:
Դեմ:
- Տարբեր տվյալների կենտրոններում տվյալները միշտ նույնական չեն
Այսպիսով, կրկնօրինակման ռեժիմի ընտրությունը կախված է բիզնեսի նպատակներից: Եթե ձեզ համար կարևոր է, որ պահեստային տվյալների կենտրոնը պարունակի նույն տվյալները, ինչ հիմնական տվյալների կենտրոնը (այսինքն՝ RPO = 0 բիզնեսի պահանջը), ապա դուք ստիպված կլինեք գումար վերցնել և համակերպվել համաժամանակյա սահմանափակումների հետ։ կրկնօրինակը. Իսկ եթե տվյալների վիճակի ուշացումը ընդունելի է կամ պարզապես գումար չկա, ապա անպայման պետք է օգտագործել ասինխրոն մեթոդը։
Առանձին առանձնացնենք նաև նման ռեժիմը (ավելի ճիշտ՝ տոպոլոգիան), որպես մետրոկլաստեր։ Մետրոկլաստերային ռեժիմում օգտագործվում է համաժամանակյա կրկնօրինակում, սակայն, ի տարբերություն սովորական կրկնօրինակի, մետրոկլաստերը թույլ է տալիս երկու պահեստավորման համակարգերին աշխատել ակտիվ ռեժիմում: Նրանք. դուք չունեք տարանջատում ակտիվ և սպասման տվյալների կենտրոնների միջև: Հավելվածները միաժամանակ աշխատում են երկու պահեստավորման համակարգերի հետ, որոնք ֆիզիկապես տեղակայված են տվյալների տարբեր կենտրոններում։ Նման տոպոլոգիայում վթարների ժամանակ խափանումները շատ փոքր են (RTO, սովորաբար րոպեներ): Այս հոդվածում մենք չենք դիտարկի մետրոկլաստերի մեր իրականացումը, քանի որ սա շատ մեծ և տարողունակ թեմա է, ուստի դրան կհատկացնենք առանձին հաջորդ հոդված՝ այս մեկի շարունակությամբ:
Բացի այդ, շատ հաճախ, երբ խոսում ենք պահեստավորման համակարգերի միջոցով կրկնօրինակման մասին, շատերի մոտ առաջանում է ողջամիտ հարց. Ավելի լավ է, թե ավելի վատ:
Այստեղ հստակ պատասխան չկա, ուստի ահա ԿՈՂՄԻ և ԴԵՄ փաստարկները.
Փաստարկներ պահեստավորման կրկնօրինակման համար.
- Լուծման պարզությունը. Մեկ գործիքի միջոցով դուք կարող եք կրկնօրինակել ձեր ամբողջ տվյալների հավաքածուն՝ անկախ բեռի տեսակից և կիրառությունից: Եթե դուք օգտագործում եք հավելվածների կրկնօրինակը, դուք պետք է կարգավորեք յուրաքանչյուր հավելված առանձին: Եթե դրանք 2-ից ավելի են, ապա սա չափազանց աշխատատար և թանկ է (հավելվածի կրկնօրինակումը սովորաբար պահանջում է առանձին և ոչ անվճար լիցենզիա յուրաքանչյուր դիմումի համար: Բայց դրա մասին ավելին ստորև):
- Դուք կարող եք կրկնօրինակել ցանկացած բան՝ ցանկացած հավելված, ցանկացած տվյալ, և այն միշտ կլինի հետևողական: Շատ (շատ) հավելվածներ չունեն կրկնօրինակման հնարավորություններ, և պահեստավորման համակարգից կրկնօրինակները աղետներից պաշտպանվելու միակ միջոցն են:
- Հավելվածի կրկնօրինակման ֆունկցիոնալության համար ավելորդ վճարման կարիք չկա: Որպես կանոն, այն էժան չէ, ինչպես պահեստավորման համակարգի կրկնօրինակի լիցենզիաները: Բայց դուք պետք է վճարեք լիցենզիայի համար պահեստավորման կրկնօրինակման համար մեկ անգամ, և հավելվածի կրկնօրինակի լիցենզիա պետք է գնել յուրաքանչյուր հավելվածի համար առանձին: Եթե կան շատ նման հավելվածներ, ապա դա արժե բավականին կոպեկ, և պահեստավորման կրկնօրինակման լիցենզիաների արժեքը դառնում է մի կաթիլ դույլի մեջ:
Փաստարկներ Պահեստավորման վերարտադրության դեմ.
- Հավելվածների միջոցով կրկնօրինակումն ավելի շատ ֆունկցիոնալություն ունի հենց հավելվածների տեսանկյունից, հավելվածն ավելի լավ գիտի իր տվյալները (ակնհայտորեն), ուստի դրանց հետ աշխատելու ավելի շատ տարբերակներ կան:
- Որոշ հավելվածների արտադրողները չեն երաշխավորում իրենց տվյալների համապատասխանությունը, եթե կրկնօրինակումը կատարվում է երրորդ կողմի գործիքների միջոցով: *
* - հակասական թեզ. Օրինակ, DBMS-ի հայտնի արտադրողը շատ երկար ժամանակ պաշտոնապես հայտարարում է, որ իրենց DBMS-ը կարող է կրկնօրինակվել միայն սովորական միջոցներով, իսկ մնացած կրկնօրինակումը (ներառյալ պահեստավորման համակարգերը) «ճիշտ չէ»: Բայց կյանքը ցույց տվեց, որ դա այդպես չէ։ Ամենայն հավանականությամբ (բայց դա հաստատ չէ) սա պարզապես հաճախորդներին ավելի շատ լիցենզիաներ վաճառելու ամենաազնիվ փորձը չէ:
Արդյունքում, շատ դեպքերում կրկնօրինակումը պահեստային համակարգից ավելի լավ է, քանի որ Սա ավելի պարզ և էժան տարբերակ է, բայց կան բարդ դեպքեր, երբ անհրաժեշտ է հատուկ հավելվածի ֆունկցիոնալություն, և անհրաժեշտ է աշխատել հավելվածի մակարդակի կրկնօրինակման հետ:
Ավարտվեց տեսությունից, այժմ պրակտիկա
Մենք կկարգավորենք կրկնօրինակը մեր լաբորատորիայում: Լաբորատոր պայմաններում մենք նմանակեցինք երկու տվյալների կենտրոններ (իրականում երկու հարակից դարակ, որոնք կարծես տարբեր շենքերում էին): Ստենդը բաղկացած է երկու Engine N2 պահեստավորման համակարգերից, որոնք միմյանց հետ կապված են օպտիկական մալուխներով։ Windows Server 2016-ով աշխատող ֆիզիկական սերվերը միացված է երկու պահեստային համակարգերին՝ օգտագործելով 10 Գբ Ethernet: Ստենդը բավականին պարզ է, բայց դա չի փոխում էությունը։
Սխեմատիկորեն դա հետևյալն է.
Տրամաբանորեն կրկնօրինակումը կազմակերպվում է հետևյալ կերպ.
Հիմա եկեք նայենք կրկնօրինակման գործառույթին, որը մենք ունենք հիմա:
Աջակցվում է երկու ռեժիմ՝ ասինխրոն և համաժամանակյա: Տրամաբանական է, որ համաժամանակյա ռեժիմը սահմանափակված է հեռավորությամբ և կապի ալիքով։ Մասնավորապես, համաժամանակյա ռեժիմը պահանջում է օպտիկամանրաթել որպես ֆիզիկա և 10 Գիգաբիթ Ethernet (կամ ավելի բարձր):
Սինխրոն կրկնօրինակման համար աջակցվող հեռավորությունը 40 կիլոմետր է, տվյալների կենտրոնների միջև օպտիկական ալիքի հետաձգման արժեքը մինչև 2 միլիվայրկյան է: Ընդհանուր առմամբ, այն կաշխատի մեծ ուշացումներով, բայց հետո ձայնագրման ժամանակ ուժեղ դանդաղումներ կլինեն (ինչը նույնպես տրամաբանական է), այնպես որ, եթե դուք պլանավորում եք համաժամանակյա վերարտադրություն տվյալների կենտրոնների միջև, ապա պետք է ստուգեք օպտիկայի որակը և ուշացումները:
Ասինխրոն կրկնօրինակման պահանջներն այնքան էլ լուրջ չեն։ Ավելի ճիշտ՝ ընդհանրապես չկան։ Ցանկացած աշխատող Ethernet կապ կհաջողվի:
Ներկայումս AERODISK ENGINE պահեստավորման համակարգը աջակցում է բլոկ սարքերի (LUNs) կրկնօրինակմանը Ethernet արձանագրության միջոցով (պղնձի կամ օպտիկական): Այն նախագծերի համար, որտեղ պահանջվում է կրկնօրինակում SAN գործվածքով օպտիկամանրաթելային ալիքով, մենք ներկայումս ավելացնում ենք համապատասխան լուծում, բայց այն դեռ պատրաստ չէ, ուստի մեր դեպքում՝ միայն Ethernet:
Replication-ը կարող է աշխատել ցանկացած ENGINE շարքի պահեստավորման համակարգերի միջև (N1, N2, N4)՝ կրտսեր համակարգերից մինչև ավելի հին և հակառակը:
Երկու կրկնօրինակման ռեժիմների ֆունկցիոնալությունը լիովին նույնական է: Ստորև բերված են ավելի շատ մանրամասներ այն մասին, թե ինչ կա.
- Կրկնօրինակեք «մեկը մեկ» կամ «մեկը մեկ», այսինքն, դասական տարբերակը երկու տվյալների կենտրոններով, հիմնական և պահեստային:
- Կրկնօրինակումը «մեկը շատերին» կամ «մեկը շատերին» է, այսինքն. մեկ LUN-ը կարող է վերարտադրվել միանգամից մի քանի պահեստային համակարգերի
- Ակտիվացրեք, ապաակտիվացրեք և «հակադարձ» կրկնօրինակումը, համապատասխանաբար, միացնելու, անջատելու կամ փոխելու ուղղությունը
- Կրկնօրինակումը հասանելի է ինչպես RDG (Raid Distributed Group), այնպես էլ DDP (Dynamic Disk Pool) լողավազանների համար: Այնուամենայնիվ, RDG լողավազանի LUN-ները կարող են վերարտադրվել միայն մեկ այլ RDG-ի: Նույնը DDP-ի դեպքում:
Կան շատ ավելի փոքր առանձնահատկություններ, բայց դրանք թվարկելը առանձնահատուկ իմաստ չունի. մենք դրանք կնշենք, երբ ստեղծենք:
Կրկնօրինակման կարգավորում
Կարգավորման գործընթացը բավականին պարզ է և բաղկացած է երեք փուլից.
- Ցանցի կոնֆիգուրացիա
- Պահպանման կարգավորում
- Կանոնների (միացումների) կարգավորում և քարտեզագրում
Կրկնօրինակման տեղադրման կարևոր կետն այն է, որ առաջին երկու փուլերը պետք է կրկնվեն հեռավոր պահեստավորման համակարգում, երրորդ փուլը՝ միայն հիմնականի վրա:
Ցանցի ռեսուրսների կարգավորում
Առաջին քայլը ցանցի պորտերի կազմաձևումն է, որոնց միջոցով կփոխանցվի կրկնօրինակման տրաֆիկը: Դա անելու համար դուք պետք է միացնեք նավահանգիստները և սահմանեք դրանց IP հասցեները Front-end adapters բաժնում:
Դրանից հետո մենք պետք է ստեղծենք լողավազան (մեր դեպքում՝ RDG) և վերարտադրման համար վիրտուալ IP (VIP): VIP-ը լողացող IP հասցե է, որը կապված է պահեստավորման կարգավորիչների երկու «ֆիզիկական» հասցեների հետ (մենք նոր կազմաձևած նավահանգիստները): Սա կլինի կրկնօրինակման հիմնական ինտերֆեյսը: Կարող եք նաև աշխատել ոչ թե VIP-ով, այլ VLAN-ով, եթե ձեզ անհրաժեշտ է աշխատել պիտակավորված տրաֆիկի հետ:
Replica-ի համար VIP ստեղծելու գործընթացը շատ չի տարբերվում I/O-ի համար VIP (NFS, SMB, iSCSI) ստեղծելուց: Այս դեպքում մենք ստեղծում ենք սովորական VIP (առանց VLAN), բայց անպայման նշում ենք, որ այն կրկնօրինակման համար է (առանց այս ցուցիչի՝ հաջորդ քայլում մենք չենք կարողանա VIP ավելացնել կանոնին)։
VIP-ը պետք է լինի նույն ենթացանցում, ինչ IP պորտերը, որոնց միջև այն լողում է:
Մենք կրկնում ենք այս կարգավորումները հեռավոր պահեստավորման համակարգում, իհարկե, այլ IP-ով:
Տարբեր պահպանման համակարգերից VIP-ները կարող են լինել տարբեր ենթացանցերում, գլխավորն այն է, որ նրանց միջև կա երթուղի: Մեր դեպքում այս օրինակը ճշգրիտ ցուցադրված է (192.168.3.XX և 192.168.2.XX)
Սա ավարտում է ցանցային մասի պատրաստումը:
Պահեստի կարգավորում
Կրկնօրինակի պահեստավորման կարգավորումը սովորականից տարբերվում է միայն նրանով, որ մենք քարտեզագրում ենք «Replication Mapping» հատուկ ընտրացանկի միջոցով: Հակառակ դեպքում ամեն ինչ նույնն է, ինչ սովորական կարգավորումներում: Հիմա, կարգով.
Նախկինում ստեղծված R02 լողավազանում դուք պետք է ստեղծեք LUN: Եկեք ստեղծենք այն և կոչենք այն LUN1:
Մենք նաև պետք է ստեղծենք նույն LUN-ը նույն չափի հեռավոր պահեստավորման համակարգի վրա: Մենք ստեղծում ենք. Շփոթմունքից խուսափելու համար եկեք անվանենք հեռակառավարվող LUN LUN1R
Եթե մեզ անհրաժեշտ լիներ վերցնել LUN, որն արդեն գոյություն ունի, ապա կրկնօրինակը կարգավորելիս մենք պետք է ապամոնտաժենք այս արդյունավետ LUN-ը հյուրընկալողից և պարզապես ստեղծենք նույն չափի դատարկ LUN հեռավոր պահեստավորման համակարգում:
Պահպանման կարգավորումն ավարտված է, եկեք անցնենք կրկնօրինակման կանոնի ստեղծմանը:
Վերարտադրման կանոնների կամ վերարտադրման հղումների կարգավորում
Պահպանման համակարգում LUN-ներ ստեղծելուց հետո, որն այս պահին կլինի առաջնայինը, մենք կարգավորում ենք կրկնօրինակման կանոնը LUN1-ը պահեստավորման համակարգում 1-ից մինչև LUN1R-ը պահեստավորման համակարգ 2-ում:
Կարգավորումը կատարվում է «Remote Replication» ցանկում
Եկեք կանոն ստեղծենք. Դա անելու համար դուք պետք է նշեք կրկնօրինակի ստացողին: Այնտեղ մենք սահմանում ենք նաև կապի անվանումը և կրկնօրինակման տեսակը (սինխրոն կամ ասինխրոն):
«Հեռակա համակարգեր» դաշտում մենք ավելացնում ենք մեր պահեստավորման համակարգը2: Ավելացնելու համար դուք պետք է օգտագործեք կառավարման IP պահեստավորման համակարգերը (MGR) և հեռավոր LUN-ի անվանումը, որի մեջ մենք կկատարենք վերարտադրություն (մեր դեպքում՝ LUN1R): Վերահսկիչ IP-ները անհրաժեշտ են միայն կապի ավելացման փուլում, դրանց միջոցով վերարտադրվող տրաֆիկը չի փոխանցվի, դրա համար կօգտագործվի նախկինում կազմաձևված VIP-ը:
Արդեն այս փուլում մենք կարող ենք ավելացնել մեկից ավելի հեռավոր համակարգ «մեկից շատ» տոպոլոգիայի համար. սեղմեք «ավելացնել հանգույց» կոճակը, ինչպես ստորև նկարում:
Մեր դեպքում կա միայն մեկ հեռավոր համակարգ, ուստի մենք սահմանափակվում ենք դրանով:
Կանոնը պատրաստ է. Խնդրում ենք նկատի ունենալ, որ այն ավտոմատ կերպով ավելացվում է կրկնօրինակման բոլոր մասնակիցների վրա (մեր դեպքում դրանք երկուսն են): Դուք կարող եք ստեղծել այնքան կանոններ, որքան ցանկանում եք, ցանկացած քանակի LUN-ի և ցանկացած ուղղությամբ: Օրինակ, բեռը հավասարակշռելու համար մենք կարող ենք կրկնօրինակել LUN-ների մի մասը պահեստային համակարգից 1-ից մինչև պահեստային համակարգ 2, իսկ մյուս մասը, ընդհակառակը, պահեստային համակարգից 2-ից մինչև պահեստային համակարգ 1:
Պահպանման համակարգ 1. Ստեղծվելուց անմիջապես հետո սկսվեց համաժամացումը։
Պահպանման համակարգ 2. Մենք տեսնում ենք նույն կանոնը, բայց համաժամացումն արդեն ավարտվել է։
LUN1-ը պահեստավորման համակարգ 1-ում գտնվում է Առաջնային դերում, այսինքն՝ այն ակտիվ է: LUN1R-ը պահեստավորման համակարգ 2-ում գտնվում է Երկրորդականի դերում, այսինքն՝ այն գտնվում է սպասման վիճակում, եթե 1-ին պահեստային համակարգը խափանվի:
Այժմ մենք կարող ենք միացնել մեր LUN-ը հյուրընկալողին:
Մենք կապվելու ենք iSCSI-ի միջոցով, թեև դա կարող է կատարվել նաև FC-ի միջոցով: iSCSI LUN-ի միջոցով քարտեզագրումը կրկնօրինակում գործնականում չի տարբերվում սովորական սցենարից, ուստի մենք այստեղ մանրամասն չենք քննարկի դա: Եթե ինչ-որ բան, ապա այս գործընթացը նկարագրված է հոդվածում «.
Միակ տարբերությունն այն է, որ մենք քարտեզագրում ենք ստեղծում «Replication Mapping» ցանկում
Մենք ստեղծեցինք քարտեզագրում և LUN-ը տվեցինք հյուրընկալողին: Հաղորդավարը տեսել է LUN.
Մենք այն ձևավորում ենք տեղական ֆայլային համակարգի:
Վերջ, կարգավորումն ավարտված է: Թեստերը կգան հաջորդիվ:
Փորձարկում
Մենք կփորձարկենք երեք հիմնական սցենար.
- Դերերի կանոնավոր փոխարկում Երկրորդական > Առաջնային: Կանոնավոր դերերի փոխարկում է անհրաժեշտ, եթե, օրինակ, մենք պետք է որոշ կանխարգելիչ գործողություններ կատարենք հիմնական տվյալների կենտրոնում և այդ ընթացքում, որպեսզի տվյալները հասանելի լինեն, մենք բեռը տեղափոխում ենք պահեստային տվյալների կենտրոն:
- Արտակարգ իրավիճակների դերերի փոխարկում Երկրորդական > Առաջնային (տվյալների կենտրոնի խափանում): Սա հիմնական սցենարն է, որի համար գոյություն ունի կրկնօրինակում, որը կարող է օգնել գոյատևել տվյալների կենտրոնի ամբողջական ձախողումից՝ առանց ընկերությանը երկարաժամկետ դադարեցնելու:
- Տվյալների կենտրոնների միջև կապի ուղիների խզում: Երկու պահեստավորման համակարգերի ճիշտ վարքագծի ստուգում այն պայմաններում, երբ ինչ-ինչ պատճառներով տվյալների կենտրոնների միջև կապի ալիքը անհասանելի է (օրինակ, էքսկավատորը սխալ տեղում փորել և կոտրել է մութ օպտիկան):
Նախ, մենք կսկսենք գրել տվյալներ մեր LUN-ում (պատահական տվյալներով ֆայլեր գրել): Մենք անմիջապես տեսնում ենք, որ օգտագործվում է պահեստավորման համակարգերի միջև կապի ալիքը: Սա հեշտ է հասկանալ, եթե բացեք այն նավահանգիստների բեռնվածության մոնիտորինգը, որոնք պատասխանատու են վերարտադրության համար:
Երկու պահեստավորման համակարգերն այժմ ունեն «օգտակար» տվյալներ, մենք կարող ենք սկսել թեստը:
Ամեն դեպքում, եկեք նայենք ֆայլերից մեկի հեշ գումարներին և գրենք դրանք:
Դերերի կանոնավոր փոխարկում
Դերերի փոխարկման գործողությունը (վերարտադրման ուղղությունը փոխելը) կարող է կատարվել ցանկացած պահեստավորման համակարգով, բայց դուք դեռ պետք է անցնեք երկուսին, քանի որ ձեզ անհրաժեշտ կլինի անջատել քարտեզագրումը Հիմնականում և միացնել այն Երկրորդականում (որը կդառնա Առաջնային: ).
Թերևս հիմա խելամիտ հարց է ծագում՝ ինչո՞ւ չավտոմատացնել սա: Պատասխանն այն է. դա պարզ է, կրկնօրինակումը աղետներին դիմակայելու պարզ միջոց է, որը հիմնված է բացառապես ձեռքով գործողությունների վրա: Այս գործողությունները ավտոմատացնելու համար կա մետրոկլաստերային ռեժիմ, այն լիովին ավտոմատացված է, բայց դրա կոնֆիգուրացիան շատ ավելի բարդ է: Մետրոկլաստերի ստեղծման մասին կգրենք հաջորդ հոդվածում։
Հիմնական պահեստավորման համակարգում մենք անջատում ենք քարտեզագրումը, որպեսզի համոզվենք, որ ձայնագրումը դադարում է:
Այնուհետև պահեստային համակարգերից մեկում (կարևոր չէ, հիմնական կամ պահեստային) «Remote replication» ընտրացանկից ընտրեք մեր կապը REPL1 և սեղմեք «Փոխել դերը»:
Մի քանի վայրկյան հետո LUN1R-ը (պահուստային պահեստավորման համակարգ) դառնում է Հիմնական:
Մենք քարտեզագրում ենք LUN1R-ը պահեստավորման համակարգով2:
Դրանից հետո մեր E: դրայվը ավտոմատ կերպով կցվում է հոսթին, միայն այս անգամ այն «ժամանել» է LUN1R-ից։
Ամեն դեպքում, մենք համեմատում ենք հեշ գումարները:
Նույնատիպ. Թեստն անցավ.
Failover. Տվյալների կենտրոնի ձախողում
Այս պահին հիմնական պահեստային համակարգը կանոնավոր միացումից հետո պահեստավորման համակարգն է 2 և LUN1R, համապատասխանաբար: Դժբախտ պատահարի նմանակման համար մենք կանջատենք երկու պահեստային կարգավորիչները2:
Այլևս մուտք չկա դրան:
Տեսնենք, թե ինչ է կատարվում պահեստային համակարգ 1-ում (պահուստայինն այս պահին):
Մենք տեսնում ենք, որ առաջնային LUN (LUN1R) անհասանելի է: Սխալի հաղորդագրություն հայտնվեց տեղեկամատյաններում, տեղեկատվական վահանակում, ինչպես նաև հենց կրկնօրինակման կանոնում: Համապատասխանաբար, հաղորդավարի տվյալները ներկայումս անհասանելի են:
Փոխեք LUN1-ի դերը հիմնականի:
Ես քարտեզագրում եմ տանտիրոջը:
Համոզվեք, որ E drive-ը հայտնվում է հոսթի վրա:
Մենք ստուգում ենք հեշը:
Ամեն ինչ լավ է. Պահպանման համակարգը հաջողությամբ վերապրեց տվյալների կենտրոնի անկումը, որն ակտիվ էր: Մոտավոր ժամանակը, որը մենք ծախսեցինք կրկնօրինակման «վերադարձը» միացնելու և LUN-ը պահուստային տվյալների կենտրոնից միացնելու համար, մոտ 3 րոպե էր: Հասկանալի է, որ իրական արտադրության մեջ ամեն ինչ շատ ավելի բարդ է, և ի լրումն պահեստավորման համակարգերի գործողությունների, դուք պետք է շատ ավելի շատ գործողություններ կատարեք ցանցում, հոսթինգների վրա, հավելվածներում: Իսկ կյանքում այս ժամանակահատվածը շատ ավելի երկար կլինի։
Այստեղ ես ուզում եմ գրել, որ ամեն ինչ, թեստը հաջողությամբ ավարտվել է, բայց եկեք չշտապենք: Հիմնական պահեստավորման համակարգը «պառկած» է, մենք գիտենք, որ երբ այն «ընկավ», առաջնային դերում էր: Ի՞նչ կլինի, եթե այն հանկարծակի միանա: Կլինեն երկու առաջնային դերեր, ինչը հավասար է տվյալների կոռուպցիային: Եկեք ստուգենք այն հիմա:
Եկեք հանկարծ միացնենք հիմքում ընկած պահեստավորման համակարգը:
Այն բեռնվում է մի քանի րոպե, այնուհետև վերադառնում է ծառայության կարճ համաժամացումից հետո, բայց երկրորդականի դերում:
Ամեն ինչ լավ է. Ուղեղի պառակտում տեղի չունեցավ. Մենք մտածում էինք այս մասին, և միշտ անկումից հետո պահեստավորման համակարգը բարձրանում է Երկրորդականի դերի, անկախ նրանից, թե ինչ դեր է ունեցել «կյանքի ընթացքում»: Այժմ վստահաբար կարող ենք ասել, որ տվյալների կենտրոնի ձախողման թեստը հաջող է անցել։
Տվյալների կենտրոնների միջև կապի ուղիների ձախողում
Այս թեստի հիմնական խնդիրն է համոզվել, որ պահեստավորման համակարգը չի սկսում տարօրինակ գործել, եթե այն ժամանակավորապես կորցնում է կապի ուղիները երկու պահեստավորման համակարգերի միջև և այնուհետև նորից հայտնվում է:
Այսպիսով. Մենք անջատում ենք լարերը պահեստավորման համակարգերի միջև (պատկերացնենք, որ դրանք փորված են էքսկավատորով):
Հիմնականում մենք տեսնում ենք, որ Միջնակարգի հետ կապ չկա:
Երկրորդականի վրա մենք տեսնում ենք, որ առաջնայինի հետ կապ չկա:
Ամեն ինչ լավ է աշխատում, և մենք շարունակում ենք տվյալները գրել հիմնական պահեստային համակարգում, այսինքն՝ երաշխավորված է, որ դրանք տարբերվում են պահեստայինից, այսինքն՝ «առանձնացել են»։
Մի քանի րոպեից մենք «վերանորոգում» ենք կապի ալիքը։ Հենց որ պահեստավորման համակարգերը տեսնում են միմյանց, տվյալների համաժամացումը ավտոմատ կերպով ակտիվանում է: Այստեղ ադմինիստրատորից ոչինչ չի պահանջվում։
Որոշ ժամանակ անց համաժամացումը ավարտված է:
Կապը վերականգնվել է, կապի ուղիների կորուստը արտակարգ իրավիճակներ չի առաջացրել, իսկ միացումից հետո համաժամացումը տեղի է ունեցել ավտոմատ կերպով։
Արդյունքները
Մենք վերլուծեցինք տեսությունը՝ ինչ է պետք և ինչու, որտեղ են դրական կողմերը և որտեղ՝ դեմները: Այնուհետև մենք ստեղծեցինք համաժամանակյա վերարտադրություն երկու պահեստավորման համակարգերի միջև:
Այնուհետև, հիմնական թեստեր են իրականացվել նորմալ միացման, տվյալների կենտրոնի խափանման և կապի ալիքի խափանման համար: Բոլոր դեպքերում պահեստավորման համակարգը լավ է աշխատել։ Տվյալների կորուստ չկա, և ադմինիստրատիվ գործողությունները նվազագույնի են հասցվում ձեռքով ստեղծված սցենարի համար:
Հաջորդ անգամ մենք կբարդացնենք իրավիճակը և ցույց կտանք, թե ինչպես է այս ամբողջ տրամաբանությունը աշխատում ավտոմատացված մետրոկլաստերում ակտիվ-ակտիվ ռեժիմում, այսինքն, երբ երկու պահեստավորման համակարգերն էլ առաջնային են, և պահման համակարգի խափանումների դեպքում պահվածքը լիովին ավտոմատացված է:
Խնդրում ենք գրել մեկնաբանություններ, մենք ուրախ կլինենք ստանալ առողջ քննադատություն և գործնական խորհուրդներ:
Մինչև հաջորդ անգամ։
Source: www.habr.com