Ներածություն

Որոշ ժամանակ առաջ ինձ հանձնարարվեց մշակել «failover» կլաստեր PostgreSQL, որը գործում է մի քանի տվյալների կենտրոններում, որոնք միացված են օպտիկական մանրաթելով մեկ քաղաքում և կարող են դիմակայել մեկ տվյալների կենտրոնի խափանումներին (օրինակ՝ անջատմանը): Որպես ծրագրակազմ, որը պատասխանատու է սխալների հանդուրժողականության համար, ես ընտրեցի Pacemakerքանի որ սա RedHat-ի պաշտոնական լուծումն է՝ ձախողման կլաստերներ ստեղծելու համար: Դա լավ է, քանի որ RedHat-ը ապահովում է դրա աջակցությունը, և քանի որ այս լուծումը ունիվերսալ է (մոդուլային): Նրա օգնությամբ հնարավոր կլինի ապահովել ոչ միայն PostgreSQL-ի, այլև այլ ծառայությունների սխալների հանդուրժողականությունը՝ կա՛մ օգտագործելով ստանդարտ մոդուլներ, կա՛մ ստեղծելով դրանք հատուկ կարիքների համար:

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

Հիմա ղեկավարությունը թույլ է տվել բացել նախագիծը բաց կոդով համայնքի համար MIT լիցենզիայի ներքո. README-ը շուտով կթարգմանվի անգլերեն (քանի որ ակնկալվում է, որ հիմնական սպառողները կլինեն Pacemaker և PostgreSQL մշակողները), և ես որոշեցի այս հոդվածի տեսքով ներկայացնել README-ի հին ռուսերեն տարբերակը (մասնակի):

Կլաստերները տեղակայված են վիրտուալ մեքենաների վրա VirtualBox- ը. Ընդհանուր առմամբ կտեղակայվեն 12 վիրտուալ մեքենաներ (ընդհանուր առմամբ 36 ԳԲ), որոնք ձևավորում են 4 անսարքության հանդուրժող կլաստերներ (տարբեր տարբերակներ): Առաջին երկու կլաստերները բաղկացած են երկու PostgreSQL սերվերներից, որոնք տեղակայված են տվյալների տարբեր կենտրոններում, և ընդհանուր սերվերից: վկա c քվորում սարք (տեղակայված է էժան վիրտուալ մեքենայի վրա երրորդ տվյալների կենտրոնում), որը լուծում է անորոշությունը 50% / 50%, ձեր ձայնը տալով կողմերից մեկին։ Երրորդ կլաստերը երեք տվյալների կենտրոններում՝ մեկ վարպետ, երկու ստրուկ, ոչ քվորում սարք. Չորրորդ կլաստերը բաղկացած է չորս PostgreSQL սերվերներից, երկուսը յուրաքանչյուր տվյալների կենտրոնից. մեկ վարպետ, մնացածը կրկնօրինակներ, ինչպես նաև օգտագործում է վկա c քվորում սարք. Չորրորդը կարող է դիմակայել երկու սերվերի կամ մեկ տվյալների կենտրոնի ձախողմանը: Անհրաժեշտության դեպքում այս լուծումը կարող է չափվել ավելի մեծ թվով կրկնօրինակների:

Ժամանակի ճշգրիտ սպասարկում ntpd Նաև վերակազմավորվել է սխալների հանդուրժողականության համար, բայց այն օգտագործում է ինքնին մեթոդը ntpd (որբ ռեժիմ) Համօգտագործվող սերվեր վկա գործում է որպես կենտրոնական NTP սերվեր՝ իր ժամանակը բաշխելով բոլոր կլաստերներին՝ դրանով իսկ համաժամացնելով բոլոր սերվերները միմյանց հետ։ Եթե վկա ձախողվում է կամ դառնում է մեկուսացված, ապա կլաստերի սերվերներից մեկը (կլաստերի ներսում) կսկսի բաշխել իր ժամանակը: Օժանդակ քեշավորում HTTP վստահված անձ նույնպես բարձրացվել է վկա, նրա օգնությամբ այլ վիրտուալ մեքենաներ մուտք ունեն Yum պահեստներ։ Իրականում, այնպիսի ծառայություններ, ինչպիսիք են ճշգրիտ ժամանակը և վստահված անձինք, ամենայն հավանականությամբ, կտեղակայվեն հատուկ սերվերների վրա, բայց այն տաղավարում, որտեղ նրանք տեղակայված են վկա միայն վիրտուալ մեքենաների քանակն ու տարածքը խնայելու համար:

Versions

v0. Աշխատում է CentOS 7-ի և PostgreSQL 11-ի հետ VirtualBox 6.1-ում:

Կլաստերային կառուցվածքը

Բոլոր կլաստերները նախագծված են մի քանի տվյալների կենտրոններում տեղակայվելու համար՝ միավորված մեկ հարթ ցանցում և պետք է դիմակայեն մեկ տվյալների կենտրոնի խափանումներին կամ ցանցային մեկուսացմանը: Ահա թե ինչու անհնար է օգտագործել պաշտպանվելու համար պառակտված ուղեղ Ստանդարտ Pacemaker տեխնոլոգիան կոչվում է ՍՏՈՆԻԹ (Shoot The Other Node In The Head) կամ ցանկապատում. Դրա էությունը. եթե կլաստերի հանգույցները սկսում են կասկածել, որ ինչ-որ բան այն չէ ինչ-որ հանգույցի հետ, այն չի արձագանքում կամ սխալ է վարվում, ապա նրանք բռնի կերպով անջատում են այն «արտաքին» սարքերի միջոցով, օրինակ՝ IPMI կամ UPS կառավարման քարտ: . Բայց սա կաշխատի միայն այն դեպքերում, երբ մեկ ձախողման դեպքում IPMI կամ UPS սերվերը շարունակում է աշխատել: Այստեղ մենք նախատեսում ենք պաշտպանվել շատ ավելի աղետալի ձախողումից, երբ ամբողջ տվյալների կենտրոնը խափանում է (օրինակ՝ կորցնում է էներգիան): Եվ նման մերժմամբ՝ ամեն ինչ ստոնիթ- սարքերը (IPMI, UPS և այլն) նույնպես չեն աշխատի:

Փոխարենը, համակարգը հիմնված է քվորումի գաղափարի վրա։ Բոլոր հանգույցներն ունեն ձայն, և միայն նրանք, ովքեր կարող են տեսնել բոլոր հանգույցների կեսից ավելին, կարող են աշխատել: «Կես + 1» այս մեծությունը կոչվում է քվորում. Եթե ​​քվորում չկա, ապա հանգույցը որոշում է, որ այն գտնվում է ցանցի մեկուսացման մեջ և պետք է անջատի իր ռեսուրսները, այսինքն. սա այն է, ինչ կա պառակտված ուղեղի պաշտպանություն. Եթե ​​ծրագրաշարը, որը պատասխանատու է այս վարքագծի համար, չի աշխատում, ապա պետք է աշխատի մի պահակ, օրինակ, որը հիմնված է IPMI-ի վրա:

Եթե ​​հանգույցների թիվը զույգ է (կլաստեր երկու տվյալների կենտրոններում), ապա կարող է առաջանալ այսպես կոչված անորոշություն. 50% / 50% (հիսուն հիսուն) երբ ցանցի մեկուսացումը բաժանում է կլաստերը ուղիղ կիսով չափ: Հետեւաբար, զույգ թվով հանգույցների համար մենք ավելացնում ենք քվորում սարք անպահանջատեր է, որը կարող է գործարկվել երրորդ տվյալների կենտրոնի ամենաէժան վիրտուալ մեքենայի վրա: Նա իր ձայնը տալիս է հատվածներից մեկին (որը տեսնում է) և դրանով իսկ լուծում է 50%/50% անորոշությունը։ Ես անվանեցի սերվերը, որի վրա կգործարկվի քվորում սարքը վկա (տերմինաբանություն repmgr-ից, ինձ դուր եկավ):

Ռեսուրսները կարող են տեղից տեղ տեղափոխվել, օրինակ՝ անսարք սերվերներից առողջ սերվերներ կամ համակարգի ադմինիստրատորների հրամանով: Որպեսզի հաճախորդները իմանան, թե որտեղ են գտնվում իրենց անհրաժեշտ ռեսուրսները (որտե՞ղ միանալ): լողացող IP (float IP) Սրանք IP-ներ են, որոնք Pacemaker-ը կարող է տեղաշարժվել հանգույցների շուրջ (ամեն ինչ հարթ ցանցում է): Նրանցից յուրաքանչյուրը խորհրդանշում է ռեսուրս (ծառայություն) և կգտնվի այնտեղ, որտեղ դուք պետք է միանաք այս ծառայությանը (մեր դեպքում՝ տվյալների բազա) մուտք գործելու համար:

Տուչանկա 1 (կոմպակտ շղթա)

Կառուցվածք

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

Յուրաքանչյուր տվյալների կենտրոն ունի մեկ սերվեր: Յուրաքանչյուր սերվեր ունի երկու PostgreSQL օրինակ (PostgreSQL տերմինաբանությամբ դրանք կոչվում են կլաստերներ, բայց շփոթությունից խուսափելու համար ես դրանք կանվանեմ օրինակներ (այլ տվյալների շտեմարանների նմանությամբ), և ես կանվանեմ միայն Pacemaker կլաստերների կլաստերներ): Մեկ օրինակն աշխատում է հիմնական ռեժիմով, և միայն նա է ծառայություններ մատուցում (միայն float IP-ն է տանում դրան): Երկրորդ ատյանը աշխատում է որպես ստրուկ երկրորդ տվյալների կենտրոնի համար և ծառայություններ կտրամադրի միայն այն դեպքում, եթե դրա տերը ձախողվի: Քանի որ ժամանակի մեծ մասում երկուսից միայն մեկը (վարպետը) ծառայություններ է մատուցում (կատարում է հարցումներ), սերվերի բոլոր ռեսուրսները օպտիմիզացված են հիմնականի համար (հիշողությունը հատկացվում է shared_buffers քեշին և այլն), բայց այնպես, որ երկրորդ օրինակը ունի նաև բավարար ռեսուրսներ (թեև ֆայլային համակարգի քեշի միջոցով ոչ օպտիմալ շահագործման համար) տվյալների կենտրոններից մեկի ձախողման դեպքում: Կլաստերի բնականոն աշխատանքի ժամանակ ստրուկը ծառայություններ չի մատուցում (չի կատարում միայն կարդալու հարցումներ), որպեսզի նույն մեքենայի վրա ռեսուրսների համար պատերազմ չլինի:

Երկու հանգույցների դեպքում սխալների հանդուրժողականությունը հնարավոր է միայն ասինխրոն վերարտադրման դեպքում, քանի որ համաժամանակյա վերարտադրության դեպքում ստրուկի ձախողումը կհանգեցնի վարպետի կանգառին:

Վկայություն չցուցաբերելը

Վկայություն չցուցաբերելը (քվորում սարք) Ես կդիտարկեմ միայն Tuchanka1 կլաստերի համար, մնացած բոլորի հետ նույն պատմությունը կլինի։ Եթե ​​վկան ձախողվի, ապա կլաստերի կառուցվածքում ոչինչ չի փոխվի, ամեն ինչ կշարունակի գործել այնպես, ինչպես արեց: Բայց քվորումը կդառնա 2-ը 3-ից, և հետևաբար ցանկացած հետագա ձախողում ճակատագրական կլինի կլաստերի համար։ Այն դեռ պետք է շտապ շտկել։

Tuchanka1 մերժում

Tuchanka1-ի տվյալների կենտրոններից մեկի խափանումը: Այս դեպքում վկա ձայն է տալիս երկրորդ տվյալների կենտրոնի երկրորդ հանգույցին: Այնտեղ նախկին ստրուկը վերածվում է վարպետի, արդյունքում երկու վարպետներն էլ աշխատում են նույն սերվերի վրա, և նրանց երկու float IP-ները մատնանշում են նրանց։

Tuchanka2 (դասական)

Կառուցվածք

Երկու հանգույցների դասական սխեման. Մեկի վրա աշխատում է տերը, երկրորդի վրա՝ ստրուկը։ Երկուսն էլ կարող են կատարել հարցումներ (ստրուկը միայն կարդալու է), այնպես որ երկուսն էլ մատնանշվում են float IP-ով. krogan2-ը գլխավորն է, krogan2s1-ը ստրուկն է: Ե՛վ տերը, և՛ ստրուկը կունենան սխալ հանդուրժողականություն:

Երկու հանգույցների դեպքում սխալների հանդուրժողականությունը հնարավոր է միայն ասինխրոն կրկնօրինակման դեպքում, քանի որ համաժամանակյա վերարտադրության դեպքում ստրուկի ձախողումը կհանգեցնի վարպետի կանգառին:

Tuchanka2 մերժում

Եթե ​​տվյալների կենտրոններից մեկը ձախողվի վկա քվեարկում է երկրորդի օգտին. Միակ աշխատող տվյալների կենտրոնի վրա վարպետը կբարձրացվի, և երկու լողացող IP-ները մատնացույց կանեն դեպի այն՝ վարպետը և ստրուկը: Իհարկե, օրինակը պետք է կարգավորվի այնպես, որ այն ունենա բավարար ռեսուրսներ (միացման սահմանափակումներ և այլն)՝ միաժամանակ ընդունելու բոլոր կապերն ու հարցումները հիմնական և ստրուկ float IP-ից։ Այսինքն՝ նորմալ շահագործման ժամանակ այն պետք է ունենա սահմանների բավարար պաշար։

Tuchanka4 (շատ ստրուկներ)

Կառուցվածք

Արդեն մեկ այլ ծայրահեղություն. Կան տվյալների շտեմարաններ, որոնք ստանում են շատ միայն կարդալու հարցումներ (բարձր բեռնված կայքի տիպիկ դեպք): Tuchanka4-ը մի իրավիճակ է, երբ կարող են լինել երեք կամ ավելի ստրուկներ, որոնք կարող են լուծել նման հարցումները, բայց դեռևս շատ չեն: Շատ մեծ թվով ստրուկների դեպքում անհրաժեշտ կլինի հորինել հիերարխիկ կրկնօրինակման համակարգ: Նվազագույն դեպքում (նկարում) երկու տվյալների կենտրոններից յուրաքանչյուրն ունի երկու սերվեր, որոնցից յուրաքանչյուրը ունի PostgreSQL օրինակ:

Այս սխեմայի մեկ այլ առանձնահատկությունն այն է, որ արդեն հնարավոր է կազմակերպել մեկ սինխրոն կրկնօրինակում: Այն կազմաձևված է այնպես, որ հնարավորության դեպքում կրկնօրինակվի մեկ այլ տվյալների կենտրոնի, այլ ոչ թե կրկնօրինակի նույն տվյալների կենտրոնում, ինչ հիմնականը: Վարպետը և յուրաքանչյուր ստրուկ մատնանշվում են լողացող IP-ով: Բարեբախտաբար, ստրուկների միջև անհրաժեշտ կլինի ինչ-որ կերպ հավասարակշռել հարցումները sql վստահված անձ, օրինակ, հաճախորդի կողմից: Հաճախորդների տարբեր տեսակներ կարող են պահանջել տարբեր տեսակներ sql վստահված անձ, և միայն հաճախորդ մշակողները գիտեն, թե ում ինչն է պետք: Այս ֆունկցիոնալությունը կարող է իրականացվել կամ արտաքին դեյմոնի կամ հաճախորդի գրադարանի միջոցով (միացման լողավազան) և այլն: Այս ամենը դուրս է գալիս ձախողման տվյալների բազայի կլաստերի թեմայից (failover SQL վստահված անձ կարող է իրականացվել ինքնուրույն՝ հաճախորդի սխալների հանդուրժողականության հետ միասին):

Tuchanka4 մերժում

Եթե ​​տվյալների մեկ կենտրոնը (այսինքն՝ երկու սերվեր) ձախողվի, վկաները քվեարկում են երկրորդի օգտին: Արդյունքում, երկրորդ տվյալների կենտրոնում աշխատում են երկու սերվեր. մեկը գործարկում է Master, և Master float IP-ն մատնանշում է այն (կարդալ-գրելու հարցումներ ստանալու համար); իսկ երկրորդ սերվերի վրա կա slave, որն աշխատում է համաժամանակյա կրկնօրինակմամբ, և slave float IP-ներից մեկը մատնանշում է այն (միայն կարդալու հարցումների համար):

Առաջին բանը, որ պետք է նշել, այն է, որ ոչ բոլոր slave float IP-ները կլինեն աշխատող, այլ միայն մեկը: Եվ դրա հետ ճիշտ աշխատելու համար դա անհրաժեշտ կլինի sql վստահված անձ վերահղեց բոլոր հարցումները դեպի միակ մնացած float IP-ն. եւ եթե sql վստահված անձ ոչ, ապա կապի URL-ում կարող եք թվարկել բոլոր float IP ստրուկները, որոնք բաժանված են ստորակետերով: Այս դեպքում, հետ libpq կապը կլինի առաջին աշխատանքային IP-ին, դա արվում է ավտոմատ թեստավորման համակարգում։ Միգուցե այլ գրադարաններում, օրինակ՝ JDBC-ում, դա չի աշխատի և անհրաժեշտ է sql վստահված անձ. Դա արվում է այն պատճառով, որ slave-ների համար float IP-ները արգելվում են միաժամանակ բարձրացնել մեկ սերվերի վրա, որպեսզի դրանք հավասարաչափ բաշխվեն ստրուկ սերվերների միջև, եթե նրանցից մի քանիսը աշխատում են:

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

Tuchanka3 (3 տվյալների կենտրոն)

Կառուցվածք

Սա կլաստեր է մի իրավիճակի համար, որտեղ կան երեք լիարժեք գործող տվյալների կենտրոններ, որոնցից յուրաքանչյուրն ունի տվյալների բազայի լիարժեք գործող սերվեր: Այս դեպքում քվորում սարք անհրաժեշտ չէ. Տվյալների մեկ կենտրոնում աշխատում է վարպետը, մյուս երկուսը` ստրուկները: Replication-ը համաժամանակյա է՝ տիպ ANY (slave1, slave2), այսինքն՝ հաճախորդը կստանա commit-ի հաստատում, երբ ստրուկներից որևէ մեկն առաջինն է պատասխանում, որ ընդունել է պարտավորությունը։ Ռեսուրսները նշվում են մեկ float IP-ով գլխավորի համար և երկուսը՝ ստրուկների համար: Ի տարբերություն Tuchanka4-ի, բոլոր երեք float IP-ները սխալ հանդուրժող են: Միայն կարդալու SQL հարցումները հավասարակշռելու համար կարող եք օգտագործել sql վստահված անձ (առանձին սխալների հանդուրժողականությամբ), կամ մեկ ստրկական լողացող IP նշանակեք հաճախորդների կեսին, իսկ մյուս կեսը՝ երկրորդին:

Tuchanka3 մերժում

Եթե ​​տվյալների կենտրոններից մեկը ձախողվի, երկուսը մնում են: Մեկում գլխավոր և float IP-ն բարձրացվում են վարպետից, երկրորդում՝ slave և երկուսն էլ slave float IP-ները (օրինակը պետք է ունենա ռեսուրսների կրկնակի պահուստ, որպեսզի ընդունի բոլոր կապերը երկու slave float IP-ներից): Սինխրոն կրկնօրինակում տերերի և ստրուկների միջև: Բացի այդ, կլաստերը կպահի տեղեկատվությունը կատարված և հաստատված գործարքների մասին (տեղեկատվության կորուստ չի լինի) երկու տվյալների կենտրոնների ոչնչացման դեպքում (եթե դրանք միաժամանակ չոչնչացվեն):

Ես որոշեցի չներառել ֆայլի կառուցվածքի և տեղակայման մանրամասն նկարագրությունը: Յուրաքանչյուր ոք, ով ցանկանում է խաղալ շուրջը, կարող է կարդալ այն ամենը README-ում: Ես տրամադրում եմ միայն ավտոմատացված թեստավորման նկարագրությունը:

Ավտոմատ փորձարկման համակարգ

Կլաստերների անսարքության հանդուրժողականությունը ստուգելու համար զանազան անսարքությունների մոդելավորման միջոցով ստեղծվել է ավտոմատ թեստավորման համակարգ։ Գործարկվել է սցենարով test/failure. Սցենարը կարող է որպես պարամետր վերցնել այն կլաստերների թիվը, որոնք դուք ցանկանում եք ստուգել: Օրինակ այս հրամանը.

test/failure 2 3

կփորձարկի միայն երկրորդ և երրորդ կլաստերը: Եթե ​​պարամետրերը նշված չեն, ապա բոլոր կլաստերները կփորձարկվեն: Բոլոր կլաստերները փորձարկվում են զուգահեռ, և արդյունքը ցուցադրվում է tmux վահանակում: Tmux-ն օգտագործում է հատուկ tmux սերվեր, այնպես որ սկրիպտը կարող է գործարկվել լռելյայն tmux-ից, ինչի արդյունքում հայտնվում է nested tmux: Ես խորհուրդ եմ տալիս օգտագործել տերմինալը մեծ պատուհանում և փոքր տառատեսակով: Նախքան փորձարկումը սկսելը, բոլոր վիրտուալ մեքենաները վերադառնում են ակնթարթային պատկերին՝ սցենարի ավարտի պահին: setup.

Տերմինալը բաժանված է սյունակների՝ ըստ փորձարկվող կլաստերների քանակի, լռելյայն (սքրինշոթում) կան չորս: Ես կնկարագրեմ սյունակների բովանդակությունը՝ օգտագործելով Tuchanka2-ի օրինակը։ Սքրինշոթի վահանակները համարակալված են.

1. Թեստի վիճակագրությունը ցուցադրվում է այստեղ: Սյունակներ:
   • անհաջողություն — թեստի անվանումը (գործառույթը սկրիպտում), որը նմանակում է սխալը:
   • ռեակցիա — միջին թվաբանական ժամանակը վայրկյաններով, որի ընթացքում կլաստերը վերականգնել է իր ֆունկցիոնալությունը: Այն չափվում է սկրիպտի սկզբից՝ ընդօրինակելով սխալը մինչև այն պահը, երբ կլաստերը վերականգնում է իր ֆունկցիոնալությունը և կարող է շարունակել ծառայություններ մատուցել: Եթե ​​ժամանակը շատ կարճ է, օրինակ՝ վեց վայրկյան (դա տեղի է ունենում մի քանի ստրուկներով կլաստերներում (Tuchanka3 և Tuchanka4)), դա նշանակում է, որ սխալը եղել է ասինխրոն ստրուկի վրա և որևէ կերպ չի ազդել կատարման վրա. կլաստերի վիճակի անջատիչներ:
   • շեղում — ցույց է տալիս արժեքի տարածումը (ճշգրտությունը): ռեակցիա օգտագործելով ստանդարտ շեղման մեթոդը:
   • հաշվել — քանի անգամ է կատարվել այս թեստը:
2. Կարճ գրանցամատյանը թույլ է տալիս գնահատել, թե ինչ է անում կլաստերը ներկայումս: Ցուցադրվում են կրկնության (փորձարկման) համարը, գործողության ժամանակի դրոշմը և անվանումը: Չափազանց երկար վազելը (> 5 րոպե) վկայում է խնդրի մասին:
3. սիրտ (սիրտ) - ընթացիկ ժամանակը: Կատարման տեսողական գնահատման համար վարպետներ Ընթացիկ ժամանակը անընդհատ գրվում է իր աղյուսակում՝ օգտագործելով float IP master-ը: Հաջողության դեպքում արդյունքը կցուցադրվի այս վահանակում:
4. ծեծել (զարկերակ) - «ընթացիկ ժամանակը», որը նախկինում ձայնագրվել է սցենարով սիրտ տիրապետել, հիմա կարդացեք ստրուկ իր float IP-ի միջոցով: Թույլ է տալիս տեսողականորեն գնահատել ստրուկի և կրկնօրինակման կատարումը: Tuchanka1-ում float IP-ով ստրուկներ չկան (ծառայություններ մատուցող ստրուկներ չկան), բայց կա երկու օրինակ (DB), ուստի այն այստեղ չի ցուցադրվի: ծեծելԻսկ սիրտ երկրորդ ատյանի։
5. Կլաստերների առողջության մոնիտորինգ՝ օգտագործելով կոմունալ ծրագիրը pcs mon. Ցույց է տալիս հանգույցների կառուցվածքը, ռեսուրսների բաշխումը և այլ օգտակար տեղեկատվություն:
6. Այստեղ ցուցադրվում է համակարգի մոնիտորինգը կլաստերի յուրաքանչյուր վիրտուալ մեքենայից: Նման վահանակները կարող են ավելի շատ լինել՝ կախված նրանից, թե քանի վիրտուալ մեքենա ունի կլաստերը: Երկու գրաֆիկ CPU բեռնվածություն (վիրտուալ մեքենաներն ունեն երկու պրոցեսոր), վիրտուալ մեքենայի անվանումը, Համակարգի բեռնվածություն (կոչվել է Load Average, քանի որ միջինը գնահատվում է 5, 10 և 15 րոպեի ընթացքում), տվյալների մշակման և հիշողության բաշխում:
7. Թեստավորում կատարող սցենարի հետք: Անսարքության դեպքում՝ աշխատանքի հանկարծակի ընդհատում կամ անվերջ սպասման ցիկլ, այստեղ կարող եք տեսնել այս պահվածքի պատճառը:

Թեստավորումն իրականացվում է երկու փուլով. Նախ, սցենարը անցնում է բոլոր տեսակի թեստերով, պատահականորեն ընտրելով վիրտուալ մեքենա, որի վրա պետք է կիրառվի այս թեստը: Այնուհետև կատարվում է թեստավորման անվերջ ցիկլ, վիրտուալ մեքենաներն ու սխալը ամեն անգամ ընտրվում են պատահականորեն: Փորձարկման սցենարի հանկարծակի դադարեցումը (ներքևի վահանակը) կամ ինչ-որ բանի սպասելու անվերջ օղակը (> 5 րոպե կատարման ժամանակ մեկ գործողության համար, դա երևում է հետագծում) ցույց է տալիս, որ այս կլաստերի որոշ թեստեր ձախողվել են:

Յուրաքանչյուր թեստ բաղկացած է հետևյալ գործողություններից.

1. Գործարկեք մի գործառույթ, որը նմանակում է սխալը:
2. Ready? — սպասել կլաստերի վերականգնմանը (երբ բոլոր ծառայությունները մատուցվեն):
3. Ցույց է տալիս կլաստերի վերականգնման ժամկետը (ռեակցիա).
4. ուղղել — կլաստերը «վերանորոգվում է»։ Որից հետո այն պետք է վերադառնա լիարժեք գործառնական վիճակի և պատրաստ լինի հաջորդ անսարքությանը:

Ահա թեստերի ցանկը՝ նկարագրելով, թե ինչ են նրանք անում.

• ForkBombՍտեղծում է «Հիշողությունից դուրս»՝ օգտագործելով պատառաքաղ ռումբ:
• ՕֆսփեյսԿոշտ սկավառակը լցված է: Բայց թեստը բավականին խորհրդանշական է, քանի որ այն աննշան ծանրաբեռնվածությամբ, որը ստեղծվում է փորձարկման ժամանակ, PostgreSQL-ը սովորաբար չի ձախողվում, երբ կոշտ սկավառակը լցված է:
• Պոստգրես-ՍՊԱՆԵԼսպանում է PostgreSQL հրամանով killall -KILL postgres.
• Postgres-STOPկախված է PostgreSQL հրամանը killall -STOP postgres.
• Poweroff- ըհրամանով «անջատում է էներգիան» վիրտուալ մեքենան VBoxManage controlvm "виртуалка" poweroff.
• Նորից դնել: գերբեռնում է վիրտուալ մեքենան հրամանով VBoxManage controlvm "виртуалка" reset.
• SBD-STOPհրամանով կասեցվում է SBD դևը killall -STOP sbd.
• Անջատումը: հրաման է ուղարկում վիրտուալ մեքենային SSH-ի միջոցով systemctl poweroff, համակարգը նրբորեն անջատվում է:
• Անջատել կապըՑանցի մեկուսացում, հրաման VBoxManage controlvm "виртуалка" setlinkstate1 off.

Ավարտելով փորձարկումը կամ օգտագործելով ստանդարտ tmux հրամանը «kill-window» Ctrl-b &, կամ «deach-client» հրամանը Ctrl-b դԱյս պահին թեստավորումն ավարտվում է, tmux-ը փակվում է, վիրտուալ մեքենաներն անջատված են:

Փորձարկման ընթացքում հայտնաբերված խնդիրներ

• Այս պահին պահապան դև sbd աշխատում է դիտարկված դևերին կանգնեցնելու, բայց չսառեցնելու վրա: Եվ, արդյունքում, անսարքություններ, որոնք հանգեցնում են միայն սառեցման Corosync и Pacemaker, բայց ոչ կախված sbd. Ստուգման համար Corosync արդեն ունի PR # 83 (GitHub-ում ժամը sbd), ընդունվել է շարանը վարպետ. Նրանք խոստացան (PR#83-ում), որ նման բան կլինի Pacemaker-ի համար, հուսով եմ, որ մինչև RedHat 8- ը կանի. Բայց նման «անսարքությունները» սպեկուլյատիվ են և կարող են հեշտությամբ նմանակվել արհեստականորեն՝ օգտագործելով, օրինակ. killall -STOP corosync, բայց երբեք չհանդիպեք իրական կյանքում:

• У Pacemaker համար տարբերակում CentOS 7- ը սխալ դրված sync_timeout у քվորում սարք, որպես արդյունք եթե մի հանգույց ձախողվեց, որոշ հավանականությամբ երկրորդ հանգույցը նույնպես վերագործարկվեց, որտեղ պետք է տեղափոխվեր վարպետը։ Բուժվում է ընդլայնմամբ sync_timeout у քվորում սարք տեղակայման ժամանակ (սկրիպտով setup/setup1) Այս փոփոխությունը չի ընդունվել մշակողների կողմից PacemakerՓոխարենը նրանք խոստացան վերանախագծել ենթակառուցվածքն այնպես (որևէ չճշտված ապագայում), որ այս ժամկետը ավտոմատ կերպով հաշվարկվի։

• Եթե ​​տվյալների բազայի կոնֆիգուրացիան դա սահմանում է LC_MESSAGES (տեքստային հաղորդագրություններ) Յունիկոդը կարող է օգտագործվել, օրինակ. ru_RU.UTF-8, ապա գործարկման ժամանակ postgres մի միջավայրում, որտեղ տեղայնացումը UTF-8 չէ, ասենք դատարկ միջավայրում (այստեղ սրտանոթ+pgsqlms(paf) վազում postgres), դա գրանցամատյանը UTF-8 տառերի փոխարեն կպարունակի հարցական նշաններ. PostgreSQL մշակողները համաձայնության չեն եկել, թե ինչ անել այս դեպքում: Արժե, դուք պետք է տեղադրեք LC_MESSAGES=en_US.UTF-8 տվյալների բազայի օրինակ կարգավորելիս (ստեղծելիս):

• Եթե ​​wal_receiver_timeout-ը սահմանված է (կանխադրված է 60 վրկ), ապա tuchanka3 և tuchanka4 կլաստերներում Master-ի PostgreSQL-STOP թեստի ժամանակ կրկնօրինակումը չի նորից միանում նոր վարպետին. Այնտեղ կրկնօրինակումը համաժամանակյա է, ուստի ոչ միայն ստրուկը կանգ է առնում, այլև նոր տերը: Աշխատում է wal_receiver_timeout=0 սահմանելով PostgreSQL-ը կարգավորելիս:

• Երբեմն ես նկատում էի, թե ինչպես են կրկնօրինակումները սառեցնում PostgreSQL-ում ForkBomb թեստում (հիշողության հորդացում): ForkBomb-ից հետո երբեմն ստրուկները չեն կարող նորից միանալ նոր տիրոջը. Ես սրան հանդիպել եմ միայն tuchanka3 և tuchanka4 կլաստերներում, որտեղ վարպետը սառել է սինխրոն կրկնօրինակման պատճառով: Խնդիրն ինքնին անհետացավ երկար ժամանակ (մոտ երկու ժամ) հետո: Սա շտկելու համար անհրաժեշտ է ավելի շատ հետազոտություն: Ախտանիշները նման են նախորդ բագին, որն առաջացել է այլ պատճառով, բայց նույն հետևանքներով։

Կրոգանի նկարը վերցված է deviant Art հեղինակի թույլտվությամբ.

Source: www.habr.com