Հե՜յ Հաբր։
Ամանորյա տոներից հետո մենք վերագործարկեցինք աղետներից պաշտպանված ամպը, որը հիմնված էր երկու կայքերի վրա: Այսօր մենք ձեզ կպատմենք, թե ինչպես է այն աշխատում և ցույց կտանք, թե ինչ է տեղի ունենում հաճախորդի վիրտուալ մեքենաների հետ, երբ կլաստերի առանձին տարրերը ձախողվում են, և ամբողջ կայքը խափանում է (սպոյլեր – նրանց մոտ ամեն ինչ կարգին է):
Աղետներին դիմացկուն ամպային պահեստավորման համակարգ OST կայքում:
Whats ներսում
Կափարիչի տակ կլաստերը ունի Cisco UCS սերվերներ VMware ESXi հիպերվիզորով, երկու INFINIDAT InfiniBox F2240 պահեստավորման համակարգեր, Cisco Nexus ցանցային սարքավորումներ, ինչպես նաև Brocade SAN անջատիչներ: Կլաստերը բաժանված է երկու կայքի՝ OST և NORD, այսինքն՝ յուրաքանչյուր տվյալների կենտրոն ունի սարքավորումների նույնական հավաքածու: Իրականում հենց դա է դարձնում այն աղետից պաշտպանված:
Մեկ կայքի ներսում հիմնական տարրերը նույնպես կրկնօրինակվում են (հոսթներ, SAN անջատիչներ, ցանցեր):
Երկու տեղամասերը միացված են հատուկ օպտիկամանրաթելային երթուղիներով, որոնք նույնպես վերապահված են:
Մի քանի խոսք պահեստավորման համակարգերի մասին. Մենք NetApp-ում կառուցեցինք աղետներից պաշտպանված ամպի առաջին տարբերակը: Այստեղ մենք ընտրեցինք INFINIDAT-ը, և ահա թե ինչու.
- Ակտիվ-Ակտիվ կրկնօրինակման տարբերակ: Այն թույլ է տալիս վիրտուալ մեքենային աշխատել, նույնիսկ եթե պահեստավորման համակարգերից մեկն ամբողջությամբ ձախողվի: Ես ձեզ ավելի ուշ կասեմ կրկնօրինակման մասին:
- Երեք սկավառակի կարգավորիչներ՝ համակարգի սխալների հանդուրժողականությունը բարձրացնելու համար: Սովորաբար երկուսն են.
- Պատրաստ լուծում. Մենք ստացանք նախապես հավաքված դարակ, որը պարզապես անհրաժեշտ է միացնել ցանցին և կարգավորել:
- Ուշադիր տեխնիկական աջակցություն: INFINIDAT-ի ինժեներները մշտապես վերլուծում են պահեստավորման համակարգի տեղեկամատյանները և իրադարձությունները, տեղադրում են որոնվածի նոր տարբերակներ և օգնում կազմաձևման հարցում:
Ահա մի քանի լուսանկարներ փաթեթավորումից.
Ինչպես է այն աշխատում
Ամպն իր ներսում արդեն իսկ անսխալական է: Այն պաշտպանում է հաճախորդին առանձին ապարատային և ծրագրային ապահովման ձախողումներից: Աղետներին դիմակայելը կօգնի պաշտպանվել մեկ կայքի ներսում զանգվածային խափանումներից. օրինակ՝ պահեստավորման համակարգի խափանում (կամ SDS կլաստերի, որը շատ հաճախ է պատահում 🙂), պահեստային ցանցի զանգվածային սխալներից և այլն: Դե, և ամենակարևորը. նման ամպը խնայում է, երբ մի ամբողջ կայք դառնում է անհասանելի հրդեհի, անջատման, ռեյդերների կողմից գրավման կամ այլմոլորակայինների վայրէջքի պատճառով:
Այս բոլոր դեպքերում հաճախորդի վիրտուալ մեքենաները շարունակում են աշխատել, և ահա թե ինչու:
Կլաստերի ձևավորումը նախագծված է այնպես, որ հաճախորդի վիրտուալ մեքենաներով ցանկացած ESXi հոսթ կարողանա մուտք գործել պահեստավորման երկու համակարգերից որևէ մեկը: Եթե OST-ի կայքում պահեստավորման համակարգը ձախողվի, վիրտուալ մեքենաները կշարունակեն աշխատել. հոսթերը, որոնց վրա նրանք աշխատում են, մուտք կունենան NORD-ի պահեստավորման համակարգ տվյալների համար:
Ահա թե ինչ տեսք ունի կլաստերի միացման դիագրամը:
Սա հնարավոր է շնորհիվ այն փաստի, որ երկու կայքերի SAN գործվածքների միջև կազմաձևված է Inter-Switch Link. Fabric A OST SAN անջատիչը միացված է Fabric A NORD SAN անջատիչին, և նմանապես Fabric B SAN անջատիչների համար:
Դե, որպեսզի SAN գործարանների այս բոլոր բարդությունները իմաստ ունենան, Active-Active կրկնօրինակումը կազմաձևված է երկու պահեստավորման համակարգերի միջև. տեղեկատվությունը գրեթե միաժամանակ գրվում է տեղական և հեռավոր պահեստավորման համակարգերում, RPO = 0: Պարզվում է, որ սկզբնական տվյալները պահվում են մի պահեստավորման համակարգում, իսկ դրա կրկնօրինակը՝ մյուսում։ Տվյալները կրկնօրինակվում են պահեստավորման ծավալների մակարդակով, և VM-ի տվյալները (դրա սկավառակները, կազմաձևման ֆայլը, փոխանակման ֆայլը և այլն) պահվում են դրանց վրա:
ESXi հյուրընկալողը տեսնում է հիմնական ծավալը և դրա կրկնօրինակը որպես մեկ սկավառակի սարք (Պահպանման սարք): ESXi հոսթից դեպի յուրաքանչյուր սկավառակի սարք կա 24 ուղի.
12 ուղիները միացնում են այն տեղական պահեստավորման համակարգին (օպտիմալ ուղիներ), իսկ մնացած 12-ը՝ հեռավոր պահեստավորման համակարգին (ոչ օպտիմալ ուղիներ): Նորմալ իրավիճակում ESXi-ն մուտք է գործում տեղական պահեստային համակարգի տվյալների՝ օգտագործելով «օպտիմալ» ուղիներ: Երբ այս պահեստավորման համակարգը ձախողվում է, ESXi-ն կորցնում է օպտիմալ ուղիները և անցնում «ոչ օպտիմալների»: Ահա թե ինչ տեսք ունի գծապատկերում.
Աղետներից պաշտպանված կլաստերի սխեման:
Հաճախորդների բոլոր ցանցերը միացված են երկու կայքերին ընդհանուր ցանցային հյուսվածքի միջոցով: Յուրաքանչյուր կայք գործարկում է Մատակարարի եզր (PE), որի վրա հաճախորդի ցանցերն ավարտված են: PE-ները միավորված են ընդհանուր կլաստերի մեջ: Եթե PE-ն ձախողվում է մեկ կայքում, ամբողջ տրաֆիկը վերահղվում է դեպի երկրորդ կայք: Դրա շնորհիվ առանց PE-ի մնացած կայքի վիրտուալ մեքենաները ցանցի միջոցով հասանելի են մնում հաճախորդին:
Հիմա տեսնենք, թե ինչ կլինի հաճախորդի վիրտուալ մեքենաների հետ տարբեր խափանումների ժամանակ: Սկսենք ամենաթեթև տարբերակներից և ավարտենք ամենալուրջով` ամբողջ կայքի ձախողմամբ: Օրինակներում հիմնական հարթակը կլինի OST-ը, իսկ պահեստային հարթակը տվյալների կրկնօրինակներով՝ NORD-ը։
Ի՞նչ է պատահում հաճախորդի վիրտուալ մեքենայի հետ, եթե...
Replication Link-ը ձախողվում է: Երկու տեղամասերի պահեստավորման համակարգերի միջև կրկնօրինակումը դադարում է:
ESXi-ն կաշխատի միայն տեղական սկավառակային սարքերի հետ (օպտիմալ ուղիներով):
Վիրտուալ մեքենաները շարունակում են աշխատել.
ISL-ը (Inter-Switch Link) խախտում է: Դեպքը քիչ հավանական է։ Եթե ինչ-որ խելագար էքսկավատոր միանգամից մի քանի օպտիկական երթուղի չի փորում, որոնք աշխատում են անկախ երթուղիներով և տարբեր մուտքերի միջոցով բերվում տեղամասեր: Բայց ամեն դեպքում. Այս դեպքում, ESXi հոսթորդները կորցնում են ուղիների կեսը և կարող են մուտք գործել միայն իրենց տեղական պահեստավորման համակարգերը: Կրկնօրինակները հավաքվում են, բայց հյուրընկալողները չեն կարողանա մուտք գործել դրանք:
Վիրտուալ մեքենաները նորմալ աշխատում են։
SAN անջատիչը ձախողվում է կայքերից մեկում: ESXi հոսթորդները կորցնում են պահեստավորման համակարգի որոշ ուղիներ: Այս դեպքում հոսթները այն վայրում, որտեղ անջատիչը ձախողվեց, կաշխատի միայն իրենց HBA-ներից մեկի միջոցով:
Վիրտուալ մեքենաները շարունակում են նորմալ աշխատել։
Կայքերից մեկի բոլոր SAN անջատիչները ձախողվում են: Ենթադրենք, նման աղետ է տեղի ունեցել ՕՍՏ կայքում։ Այս դեպքում, այս կայքի ESXi հոսթերը կկորցնեն իրենց սկավառակի սարքերի բոլոր ուղիները: Գործում է ստանդարտ VMware vSphere HA մեխանիզմը. այն կվերագործարկի OST կայքի բոլոր վիրտուալ մեքենաները NORD-ում առավելագույնը 140 վայրկյանում:
Վիրտուալ մեքենաները, որոնք աշխատում են NORD կայքի հոսթերում, նորմալ աշխատում են:
ESXi հոսթինգը ձախողվում է մեկ կայքում: Այստեղ vSphere HA մեխանիզմը կրկին աշխատում է. ձախողված հոսթից վիրտուալ մեքենաները վերագործարկվում են այլ հոսթների վրա՝ նույն կամ հեռավոր կայքում: Վիրտուալ մեքենայի վերագործարկման ժամանակը մինչև 1 րոպե է:
Եթե OST-ի կայքի բոլոր ESXi հոսթերը ձախողվեն, տարբերակներ չկան. VM-ները վերագործարկվում են մեկ ուրիշի վրա: Վերագործարկման ժամանակը նույնն է:
Պահպանման համակարգը ձախողվում է մեկ վայրում: Ենթադրենք, պահպանման համակարգը ձախողվում է OST-ի կայքում: Այնուհետև OST կայքի ESXi հոսթերն անցնում են NORD-ում պահեստավորման կրկնօրինակների հետ աշխատելուն: Այն բանից հետո, երբ ձախողված պահեստային համակարգը կվերադառնա ծառայության, տեղի կունենա հարկադիր վերարտադրություն, և ESXi OST հոսթորդները նորից կսկսեն մուտք գործել տեղական պահեստավորման համակարգ:
Վիրտուալ մեքենաներն այս ամբողջ ընթացքում նորմալ աշխատում էին։
Կայքերից մեկը ձախողվում է: Այս դեպքում բոլոր վիրտուալ մեքենաները կվերագործարկվեն պահուստային կայքում՝ vSphere HA մեխանիզմի միջոցով: VM-ի վերագործարկման ժամանակը 140 վայրկյան է: Այս դեպքում վիրտուալ մեքենայի բոլոր ցանցային կարգավորումները կպահպանվեն, և այն հասանելի կլինի հաճախորդի համար ցանցի միջոցով:
Ապահովելու համար, որ պահեստային կայքում մեքենաների վերագործարկումը սահուն է ընթանում, յուրաքանչյուր կայք լցված է միայն կիսով չափ: Երկրորդ կեսը ռեզերվ է այն դեպքում, եթե բոլոր վիրտուալ մեքենաները տեղափոխվեն երկրորդ, վնասված կայքից:
Աղետներին դիմացկուն ամպը, որը հիմնված է տվյալների երկու կենտրոնների վրա, պաշտպանում է նման խափանումներից:
Այս հաճույքը էժան չէ, քանի որ, բացի հիմնական ռեսուրսներից, երկրորդ տեղում պահուստ է անհրաժեշտ։ Հետևաբար, բիզնեսի համար կարևոր ծառայությունները տեղադրվում են այնպիսի ամպի մեջ, որի երկարաժամկետ աշխատանքը հանգեցնում է մեծ ֆինանսական և հեղինակության կորուստների, կամ եթե տեղեկատվական համակարգը ենթակա է աղետներին դիմակայելու պահանջներին կարգավորող մարմիններից կամ ընկերության ներքին կանոնակարգերից:
Աղբյուրները
Source: www.habr.com