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

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

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

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

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

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

Versions

տարբերակ 0։ Աշխատում է CentOS 7-ի և PostgreSQL 11-ի հետ VirtualBox 6.1-ի վրա։

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

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

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

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

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

Տուչանկա1 (սխեմա՝ խտացմամբ)

Կառուցվածք

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

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

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

Վկայի հրաժարումը

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

Տուչանկա1-ի մերժումը

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

Տուչանկա 2 (դասական)

Կառուցվածք

Դասական երկու հանգույցի դիզայն։ Տերը մեկի վրա է աշխատում, ստրուկը՝ մյուսի վրա։ Երկուսն էլ կարող են կատարել հարցումներ (slave-ը միայն ընթերցման է), ուստի երկուսն էլ ունեն լողացող IP հասցեներ՝ krogan2՝ master-ին, krogan2s1՝ slave-ին։ Ե՛վ տերը, և՛ ծառան կլինեն թերությունների նկատմամբ հանդուրժող։

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

Տուչանկա2-ի մերժումը

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

Տուչանկա4 (շատ ստրուկներ)

Կառուցվածք

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

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

Տուչանկա4-ի մերժումը

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

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

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

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

Կառուցվածք

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

Տուչանկա3-ի մերժումը

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

Ես որոշեցի չներառել ֆայլի կառուցվածքի և տեղակայման մանրամասն նկարագրությունը։ Եթե ուզում եք փորձել, կարող եք ամեն ինչ կարդալ README-ում։ Ես միայն ավտոմատացված թեստավորման նկարագրություն եմ տալիս։

Ավտոմատ թեստավորման համակարգ

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

test/failure 2 3

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

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

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

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

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

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

Ահա թեստերի ցանկը՝ նրանց գործողությունների նկարագրությամբ.

Ֆորքբոմբստեղծում է «Հիշողությունից դուրս» ֆունկցիան՝ օգտագործելով պատառաքաղ-ռումբ։
Տիեզերքից դուրս: կոշտ սկավառակը լիքն է։ Բայց փորձությունը բավականին խորհրդանշական է։ Փորձարկման ընթացքում ստեղծված աննշան բեռով, երբ կոշտ սկավառակը լիքն է, PostgreSQL-ը սովորաբար չի ձախողվում։
Postgres-KILL: ոչնչացնում է 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 &, կամ «detach-client» հրամանով Ctrl-b dԱյս պահին թեստավորումն ավարտվում է, tmux-ը փակվում է, և վիրտուալ մեքենաները անջատվում են։

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

Այս պահին պահակ դև sbd կարգավորում է դիտարկվող դևերի կանգնեցումը, բայց ոչ դրանց կախումը։ Եվ, որպես արդյունք, սխալները ճիշտ չեն մշակվում, ինչը հանգեցնում է միայն սառեցման Corosync и Pacemaker, բայց կախված չէ սբդ. Հաստատման համար Corosync արդեն ունի PR # 83 (GitHub-ում հետևյալ հասցեով՝ սբդ), ընդունվել է մասնաճյուղում վարպետ. Նրանք խոստացան (PR#83-ում), որ Pacemaker-ի համար նմանատիպ բան կլինի, հուսով եմ՝ մինչև Կարմիր գլխարկ 8 նրանք կանեն դա։ Սակայն նման «անսարքությունները» ենթադրական են և կարող են հեշտությամբ մոդելավորվել արհեստականորեն՝ օգտագործելով, օրինակ, killall -STOP corosync, բայց երբեք չեն հանդիպում իրական կյանքում։
У Pacemaker տարբերակում CentOS 7- ը սխալ տեղադրված համաժամեցման_ժամանակի_ավարտ у քվորումի սարք, որպես արդյունք եթե մեկ հանգույցը ձախողվեր, որոշակի հավանականություն կար, որ երկրորդ հանգույցը նույնպես կվերագործարկվեր, որտեղ պետք է տեղափոխվեր վարպետը։ Բուժվում է մեծացնելով համաժամեցման_ժամանակի_ավարտ у քվորումի սարք տեղակայման ընթացքում (սկրիպտում 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 կլաստերներում գլխավորի վրա PostgreSQL-STOP թեստի ժամանակ Կրկնօրինակումը չի վերամիանում նոր վարպետին. Այնտեղ կրկնօրինակումը համաժամանակյա է, ուստի ոչ միայն ստրուկը, այլև նոր վարպետը կանգ են առնում։ Լուծում. PostgreSQL-ը կարգավորելիս սահմանեք wal_receiver_timeout=0:
ForkBomb թեստում PostgreSQL-ում հազվադեպ է նկատվում կրկնօրինակման սառեցում (հիշողության գերբեռնվածություն): ForkBomb-ից հետո, երբեմն ստրուկները կարող են չվերամիավորվել նոր տիրոջ հետ։. Ես սա հանդիպել եմ միայն tuchanka3 և tuchanka4 կլաստերներում, որտեղ master-ը կախվում էր համաժամանակյա կրկնօրինակման պատճառով։ Խնդիրն ինքնուրույն անհետացավ որոշ ժամանակ անց (մոտ երկու ժամ): Սա շտկելու համար անհրաժեշտ են հետագա հետազոտություններ։ Ախտանիշները նման են նախորդ բագին, որը պայմանավորված է այլ պատճառով, բայց նույն հետևանքներով։