Ինչու՞ է կարևոր վավերացնել ծրագրակազմը ձեր բարձր հասանելիության պահեստում (99,9999%)

Որոնվածի ո՞ր տարբերակն է առավել «ճիշտ» և «աշխատող»: Եթե ​​պահեստավորման համակարգը երաշխավորում է 99,9999% անսարքության հանդուրժողականություն, դա նշանակում է, որ այն կաշխատի անխափան նույնիսկ առանց ծրագրային ապահովման թարմացման: Կամ, ընդհակառակը, սխալների առավելագույն հանդուրժողականություն ստանալու համար միշտ պետք է տեղադրել նորագույն որոնվածը: Մենք կփորձենք պատասխանել այս հարցերին մեր փորձից ելնելով:

Փոքր ներածություն

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

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

Այս եզրակացության ենք եկել, ինչպես ասում են, փորձով։ Օգտագործելով մեր աշխատանքի օրինակը, մենք ձեզ կասենք, թե ինչու պահեստավորման համակարգերի խոստացված 99,9999% հուսալիությունը ոչինչ չի նշանակում, եթե դուք անհապաղ չվերահսկեք ծրագրաշարի թարմացումներն ու նկարագրությունները: Մեր գործը հարմար է ցանկացած վաճառողի պահեստային համակարգերի օգտագործողների համար, քանի որ նմանատիպ իրավիճակ կարող է տեղի ունենալ ցանկացած արտադրողի ապարատների դեպքում:

Ընտրելով նոր պահեստային համակարգ

Անցյալ տարեվերջին մեր ենթակառուցվածքում ավելացվեց տվյալների պահպանման հետաքրքիր համակարգ՝ IBM FlashSystem 5000 շարքի կրտսեր մոդել, որը գնման պահին կոչվում էր Storwize V5010e: Այժմ այն ​​վաճառվում է FlashSystem 5010 անունով, բայց իրականում դա նույն ապարատային բազան է՝ ներսում նույն Spectrum Virtualize-ով։ 

Միասնական կառավարման համակարգի առկայությունը, ի դեպ, IBM FlashSystem-ի հիմնական տարբերությունն է։ Երիտասարդ սերիայի մոդելների համար այն գործնականում չի տարբերվում ավելի արդյունավետ մոդելներից: Կոնկրետ մոդելի ընտրությունը ապահովում է միայն համապատասխան ապարատային բազա, որի բնութագրիչները հնարավորություն են տալիս օգտագործել այս կամ այն ​​ֆունկցիոնալությունը կամ ապահովել լայնածավալության ավելի բարձր մակարդակ: Ծրագրային ապահովումը նույնականացնում է սարքաշարը և ապահովում է այս հարթակի համար անհրաժեշտ և բավարար ֆունկցիոնալությունը:

IBM FlashSystem 5010

Համառոտ մեր 5010 մոդելի մասին: Սա մուտքի մակարդակի երկակի վերահսկիչ բլոկի պահեստավորման համակարգ է: Այն կարող է տեղավորել NLSAS, SAS, SSD սկավառակներ: NVMe տեղադրումը հասանելի չէ դրանում, քանի որ պահեստավորման այս մոդելը տեղակայված է խնդիրների լուծման համար, որոնք չեն պահանջում NVMe կրիչներ:

Պահպանման համակարգը գնվել է արխիվային տեղեկատվության կամ տվյալների հաճախակի հասանելիություն չստացող արխիվային տեղեկատվության տեղակայման համար: Հետևաբար, մեզ համար բավարար էր նրա ֆունկցիոնալության ստանդարտ փաթեթը՝ Tiering (Easy Tier), Thin Provision: Մեզ համար բավականին գոհացուցիչ էր նաև NLSAS սկավառակների վրա 1000-2000 IOPS մակարդակի կատարումը:

Մեր փորձը. ինչպես մենք ժամանակին չթարմացրինք որոնվածը

Հիմա հենց ծրագրային ապահովման թարմացման մասին: Գնման պահին համակարգն արդեն ուներ Spectrum Virtualize ծրագրաշարի մի փոքր հնացած տարբերակը, մասնավորապես. 8.2.1.3:

Մենք ուսումնասիրեցինք որոնվածի նկարագրությունները և նախատեսեցինք թարմացում 8.2.1.9. Եթե ​​մենք մի փոքր ավելի արդյունավետ լինեինք, այս հոդվածը գոյություն չէր ունենա. սխալը չէր առաջանա ավելի նոր որոնվածի վրա: Սակայն որոշակի պատճառներով այս համակարգի թարմացումը հետաձգվեց։

Արդյունքում թարմացման աննշան ուշացումը հանգեցրեց չափազանց տհաճ պատկերի, ինչպես նկարագրության մեջ նշված է հղումով. https://www.ibm.com/support/pages/node/6172341. 

Այո, այդ տարբերակի որոնվածում տեղին էր այսպես կոչված APAR (Authorized Program Analysis Report) HU02104։ Այն հայտնվում է հետևյալ կերպ. Բեռի տակ, որոշակի հանգամանքներում, քեշը սկսում է լցվել, այնուհետև համակարգը անցնում է պաշտպանիչ ռեժիմի, որում անջատում է լողավազանի մուտքը/ելքը: Մեր դեպքում RAID 3 ռեժիմում RAID խմբի համար 6 ​​սկավառակ անջատելը թվաց: Անջատումը տեղի է ունենում 6 րոպեով: Այնուհետև վերականգնվում է լողավազանում գտնվող ծավալների մուտքը:

Եթե ​​որևէ մեկը ծանոթ չէ IBM Spectrum Virtualize-ի համատեքստում տրամաբանական սուբյեկտների կառուցվածքին և անվանումներին, ես հիմա հակիրճ կբացատրեմ:

Պահպանման համակարգի տրամաբանական տարրերի կառուցվածքը

Սկավառակները հավաքվում են խմբերի, որոնք կոչվում են MDisk (Կառավարվող սկավառակ): MDisk-ը կարող է լինել դասական RAID (0,1,10,5,6) կամ վիրտուալացված՝ DRAID (Distributed RAID): DRAID-ի օգտագործումը թույլ է տալիս բարձրացնել զանգվածի կատարումը, քանի որ... Խմբի բոլոր սկավառակները կօգտագործվեն, և վերակառուցման ժամանակը կկրճատվի, քանի որ միայն որոշ բլոկներ պետք է վերականգնվեն, և ոչ բոլոր տվյալները ձախողված սկավառակից:

Տվյալների բլոկների բաշխում սկավառակների վրա՝ RAID-5 ռեժիմում բաշխված RAID (DRAID) օգտագործման դեպքում:

Եվ այս դիագրամը ցույց է տալիս տրամաբանությունը, թե ինչպես է աշխատում DRAID-ի վերակառուցումը մեկ սկավառակի ձախողման դեպքում.

DRAID-ի վերակառուցման տրամաբանությունը, երբ մեկ սկավառակը ձախողվում է

Հաջորդը, մեկ կամ մի քանի MDdisk-ը կազմում է այսպես կոչված Pool: Միևնույն լողավազանի ներսում խորհուրդ չի տրվում օգտագործել RAID/DRAID տարբեր մակարդակներով MDisk նույն տեսակի սկավառակների վրա: Սրա մեջ շատ չենք խորանա, քանի որ... մենք նախատեսում ենք այս մասին անդրադառնալ հաջորդ հոդվածներից մեկում: Դե, փաստորեն, Pool-ը բաժանված է հատորների, որոնք ներկայացվում են հյուրընկալողներին արգելափակման մուտքի այս կամ այն ​​արձանագրության միջոցով:

Այսպիսով, մենք նկարագրված իրավիճակի արդյունքում APAR HU02104, երեք սկավառակների տրամաբանական ձախողման պատճառով MDisk-ը դադարեց գործել, ինչն իր հերթին հանգեցրեց Pool-ի և համապատասխան Volumes-ի խափանմանը։

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

Դրա շնորհիվ խնդիրը լուծվեց բավականին արագ, և աջակցության ծառայությունից ստացվեց արագ առաջարկություն՝ թարմացնել մեր համակարգը նախկինում ընտրված 8.2.1.9 որոնվածին, որն այն ժամանակ արդեն շտկվել էր: Այն հաստատում է համապատասխան թողարկման նշում.

Արդյունքները և մեր առաջարկությունները

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

Մենք ստացել ենք հաստատում, որ նույնիսկ 99,9999% խոստացված հասանելիությամբ հուսալի համակարգերը պահանջում են ուշադրություն և ժամանակին սպասարկում: Ելնելով ստեղծված իրավիճակից՝ մենք մեզ համար մի շարք եզրակացություններ ենք արել և կիսում ենք մեր առաջարկությունները.

• Հրամայական է վերահսկել թարմացումների թողարկումը, ուսումնասիրել Թողարկման նշումները հնարավոր կարևոր խնդիրների ուղղման համար և ժամանակին իրականացնել պլանավորված թարմացումները:

  Սա կազմակերպչական և նույնիսկ բավականին ակնհայտ կետ է, որի վրա, կարծես թե, չարժե կենտրոնանալ։ Այնուամենայնիվ, այս «մակարդակի վրա» դուք կարող եք բավականին հեշտությամբ սայթաքել: Փաստորեն, հենց այս պահն է ավելացրել վերը նկարագրված անախորժությունները։ Եղեք շատ զգույշ թարմացման կանոնակարգերը կազմելիս և ոչ պակաս ուշադիր հետևեք դրանց համապատասխանությանը: Այս կետն ավելի շատ վերաբերում է «կարգապահություն» հասկացությանը:

• Միշտ ավելի լավ է համակարգը պահել ծրագրաշարի վերջին տարբերակով: Ավելին, ներկան այն չէ, որն ունի ավելի մեծ թվային նշում, այլ ավելի ուշ թողարկման ամսաթիվ ունեցողը: 

  Օրինակ, IBM-ը թարմացնում է առնվազն երկու ծրագրային թողարկում իր պահեստավորման համակարգերի համար: Այս գրելու պահին դրանք 8.2 և 8.3 են: 8.2-ի թարմացումները ավելի վաղ են դուրս եկել: 8.3-ի նմանատիպ թարմացումը սովորաբար թողարկվում է մի փոքր ուշացումով:

  Թողարկումը 8.3-ն ունի մի շարք ֆունկցիոնալ առավելություններ, օրինակ՝ MDisk-ը (DRAID ռեժիմում) ընդլայնելու հնարավորություն՝ ավելացնելով մեկ կամ մի քանի նոր սկավառակ (այս հատկությունը հայտնվել է 8.3.1 տարբերակից հետո): Սա բավականին տարրական ֆունկցիոնալություն է, բայց 8.2-ում, ցավոք, նման հատկություն չկա:

• Եթե ​​ինչ-ինչ պատճառներով հնարավոր չէ թարմացնել, ապա 8.2.1.9 և 8.3.1.0 տարբերակներից առաջ Spectrum Virtualize ծրագրաշարի տարբերակների համար (որտեղ վերը նկարագրված սխալը տեղին է), դրա առաջացման ռիսկը նվազեցնելու համար, IBM-ի տեխնիկական աջակցությունը խորհուրդ է տալիս: սահմանափակելով համակարգի կատարումը լողավազանի մակարդակում, ինչպես ցույց է տրված ստորև նկարում (նկարը վերցված է GUI-ի ռուսացված տարբերակում): 10000 IOPS-ի արժեքը ցուցադրվում է որպես օրինակ և ընտրվում է ըստ ձեր համակարգի բնութագրերի:

IBM պահեստավորման աշխատանքի սահմանափակում

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

  • գործողության տեսակը՝ կարդալ կամ գրել,

  • շահագործման բլոկի չափը,

  • կարդալու և գրելու գործառնությունների տոկոսը ընդհանուր I/O հոսքում:

  Նաև գործողությունների արագության վրա ազդում է տվյալների բլոկների ընթերցման եղանակը՝ հաջորդաբար կամ պատահական կարգով: Հավելվածի կողմից տվյալների հասանելիության մի քանի գործողություններ կատարելիս գոյություն ունի կախված գործողություններ հասկացությունը: Ցանկալի է նաև դա հաշվի առնել։ Այս ամենը կարող է օգնել տեսնելու տվյալների ամբողջականությունը ՕՀ-ի, պահեստավորման համակարգից, սերվերներից/հիպերվիզորներից, ինչպես նաև հասկանալու հավելվածների, DBMS-ների և սկավառակի ռեսուրսների այլ «սպառողների» գործառնական առանձնահատկությունները:

• Եվ վերջապես, համոզվեք, որ պահուստային պատճեններ ունեք թարմացված և աշխատող: Պահուստավորման ժամանակացույցը պետք է կազմաձևվի՝ հիմնվելով բիզնեսի համար ընդունելի RPO արժեքների վրա, և կրկնօրինակների ամբողջականության պարբերական ստուգումները պետք է ստուգվեն (պահուստային ծրագրային ապահովման մի քանի վաճառողներ ունեն ավտոմատացված ստուգում իրենց արտադրանքներում)՝ ապահովելու ընդունելի RTO արժեք:

Շնորհակալություն մինչև վերջ կարդալու համար։
Մենք պատրաստ ենք պատասխանել ձեր հարցերին և մեկնաբանություններին: Նաև Հրավիրում ենք բաժանորդագրվել մեր հեռագրային ալիքին, որում մենք կանոնավոր ակցիաներ ենք անցկացնում (զեղչեր IaaS-ում և նվերներ գովազդային կոդերի համար մինչև 100% VPS-ում), գրում ենք հետաքրքիր նորություններ և հայտարարում նոր հոդվածներ Habr բլոգում։

Source: www.habr.com