Cloister → պարզ OTP կլաստերի կառավարում

Գրեթե յուրաքանչյուր հաջողված բիզնես հավելված վաղ թե ուշ մտնում է մի փուլ, որտեղ հորիզոնական մասշտաբավորում է պահանջվում: Շատ դեպքերում դուք կարող եք պարզապես սկսել նոր օրինակ և նվազեցնել բեռի միջինը: Բայց կան նաև ավելի քիչ տրիվիալ դեպքեր, երբ մենք պետք է ապահովենք, որ տարբեր հանգույցները իմանան միմյանց մասին և ուշադիր բաշխեն ծանրաբեռնվածությունը:

Այնքան բախտավոր է ստացվել, որ էրլանգ, որը մենք ընտրել ենք իր հաճելի շարահյուսության և դրա շուրջ աղմուկի համար, ունի առաջին կարգի աջակցություն բաշխված համակարգերին. Տեսականորեն սա հնչում է բոլորովին չնչին.

Տարբեր հանգույցների վրա պրոցեսների, ինչպես նաև հղումների և մոնիտորների միջև փոխանցվող հաղորդագրությունը թափանցիկ է […]

Գործնականում ամեն ինչ մի փոքր ավելի բարդ է: Բաշխված էրլանգ մշակվել է այն ժամանակ, երբ «կոնտեյներ» նշանակում է երկաթե մեծ տուփ՝ բեռնափոխադրման համար, իսկ «նավատորմը» պարզապես երկարափնյա մարդի հոմանիշն էր: IN IP4 կային բազմաթիվ չօգտագործված հասցեներ, ցանցի խափանումները սովորաբար առաջանում էին մալուխների միջով ծամող առնետների պատճառով, և արտադրական համակարգի միջին գործունակությունը չափվում էր տասնամյակներով:

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

ՆշումԵս տեղյակ եմ, որ կա libcluster. Դա իսկապես հիանալի է, այն ունի ավելի քան հազար աստղ, հեղինակը հայտնի է համայնքում, և այդ ամենը: Եթե ​​կլաստերի ստեղծման և պահպանման այս փաթեթի առաջարկած մեթոդները բավարար են ձեզ համար, ես ուրախ եմ ձեզ համար: Ցավոք, ինձ շատ ավելին է պետք։ Ես ուզում եմ մանրամասնորեն վերահսկել կարգավորումը և չլինել արտաքին հանդիսատես կլաստերային վերակազմավորման թատրոնում:

Պահանջներ

Ինձ անձամբ անհրաժեշտ էր գրադարանը, որը կստանձներ կլաստերի կառավարումը և կունենար հետևյալ հատկությունները.

• թափանցիկ աշխատանք ինչպես հանգույցների կոշտ կոդավորված ցանկի, այնպես էլ ծառայությունների միջոցով դինամիկ հայտնաբերման հետ էրլանգ;
• լիովին ֆունկցիոնալ հետադարձ զանգ յուրաքանչյուր տոպոլոգիայի փոփոխության համար (հանգույց այնտեղ, հանգույց այստեղ, ցանցի անկայունություն, պառակտումներ);
• թափանցիկ ինտերֆեյս՝ երկար և կարճ անուններով կլաստերի գործարկման համար, ինչպես :nonode@nohost;
• Docker աջակցություն տուփից դուրս՝ առանց ենթակառուցվածքի կոդ գրելու:

Վերջինս նշանակում է, որ այն բանից հետո, երբ ես փորձարկեցի հավելվածը տեղական տարածքում :nonode@nohost, կամ արհեստականորեն բաշխված միջավայրում՝ օգտագործելով test_cluster_task, ես ուղղակի ուզում եմ վազել docker-compose up --scale my_app=3 և տեսեք, թե ինչպես է այն կատարում երեք օրինակ docker-ում՝ առանց կոդի որևէ փոփոխության: Ես նաև ուզում եմ կախյալ հավելվածներ, ինչպիսիք են mnesia - երբ տոպոլոգիան փոխվում է, կուլիսների հետևում նրանք վերակառուցում են կլաստերը՝ առանց հավելվածի որևէ լրացուցիչ հարվածի:

Վան Նախատեսված չէր լինել գրադարան, որն ի վիճակի է ամեն ինչի` կլաստերից մինչև սուրճ պատրաստելը: Դա արծաթե փամփուշտ չէ, որը նպատակ ունի լուսաբանել բոլոր հնարավոր դեպքերը կամ լինել ակադեմիական ամբողջական լուծում այն ​​առումով, որ տեսաբանները CS դնել այս տերմինի մեջ: Այս գրադարանը նախագծված է ծառայելու շատ հստակ նպատակի, բայց իր ոչ այնքան մեծ գործը կատարելապես կատարի: Այս նպատակն է լինելու ապահովել ամբողջական թափանցիկություն տեղական զարգացման միջավայրի և բաշխված առաձգական միջավայրի միջև, որը լի է թշնամական տարաներով:

Ընտրված մոտեցում

Վան նախատեսված է գործարկել որպես հավելված, չնայած առաջադեմ օգտվողները կարող են ձեռքով աշխատել կլաստերի հավաքման և սպասարկման հետ՝ ուղղակիորեն գործարկելով Cloister.Manager թիրախային հավելվածի վերահսկիչ ծառում:

Երբ աշխատում է որպես հավելված, գրադարանը հենվում է config, որտեղից կարդում է հետևյալ հիմնական արժեքները.

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

Վերոնշյալ պարամետրերը բառացիորեն նշանակում են հետևյալը. Վան օգտագործվում է OTP հավելվածի համար :my_app, օգտագործում erlang ծառայության բացահայտում հանգույցներ միացնելու համար, առնվազն երեք, և MyApp.Listener մոդուլ (իրականացում @behaviour Cloister.Listener) կազմաձևված է տոպոլոգիայի փոփոխությունների մասին ծանուցումներ ստանալու համար: Ամբողջական կազմաձևման մանրամասն նկարագրությունը կարելի է գտնել այստեղ փաստաթղթավորում.

Այս կոնֆիգուրացիայով հավելվածը Վան կամք մեկնարկը փուլերով, հետաձգելով հիմնական հավելվածի մեկնարկի գործընթացը մինչև կոնսենսուսի հասնելը (երեք հանգույց միացված և միացված են, ինչպես վերը նշված օրինակում): Սա հիմնական հավելվածին հնարավորություն է տալիս ենթադրելու, որ երբ այն սկսվում է, կլաստերն արդեն հասանելի է: Ամեն անգամ, երբ տոպոլոգիան փոխվի (դրանցից շատերը կլինեն, քանի որ հանգույցները լիովին համաժամանակյա չեն սկսվում), կկանչվի կարգավորիչը. MyApp.Listener.on_state_change/2. Ժամանակի մեծ մասը մենք կատարում ենք գործողություն, երբ ստանում ենք կարգավիճակի հաղորդագրություն %Cloister.Monitor{status: :up}, ինչը նշանակում է. «Բարև, կլաստերը հավաքված է»:

Շատ դեպքերում տեղադրումը consensus: 3 օպտիմալ է, քանի որ նույնիսկ եթե մենք ակնկալում ենք, որ ավելի շատ հանգույցներ միանան, հետ կանչը կանցնի status: :rehashing → status: :up ցանկացած նոր ավելացված կամ հեռացված հանգույցի վրա:

Մշակման ռեժիմում սկսելիս պարզապես անհրաժեշտ է սահմանել consensus: 1 и Վան ուրախությամբ բաց կթողնի կլաստերի հավաքման սպասումը, երբ տեսնի :nonode@nohostԿամ :node@hostԿամ :[email protected] - կախված նրանից, թե ինչպես է կազմաձևվել հանգույցը (:none | :shortnames | :longnames).

Բաշխված հավելվածների կառավարում

Բաշխված հավելվածները, որոնք վակուումում չեն, սովորաբար ներառում են բաշխված կախվածություններ, ինչպիսիք են mnesia. Մեզ համար հեշտ է կարգավորել դրանց վերակազմավորումը նույն հետադարձ զանգից on_state_change/2. Ահա, օրինակ, մանրամասն նկարագրություն, թե ինչպես կարելի է վերակազմավորել mnesia թռչելիս ներս փաստաթղթավորում Վան.

Օգտագործման հիմնական առավելությունը Վան այն է, որ այն կատարում է բոլոր անհրաժեշտ գործողությունները տոպոլոգիայի փոփոխությունից հետո կլաստերը վերակառուցելու համար կափարիչի տակ. Հավելվածը պարզապես աշխատում է արդեն պատրաստված բաշխված միջավայրում, բոլոր հանգույցները միացված են՝ անկախ նրանից՝ մենք նախապես գիտենք IP հասցեները և հետևաբար հանգույցների անունները, թե դրանք դինամիկ կերպով նշանակվել/փոխվել են: Սա բացարձակապես չի պահանջում դոկերի կոնֆիգուրացիայի հատուկ կարգավորումներ, և հավելվածի մշակողի տեսանկյունից տարբերություն չկա բաշխված միջավայրում աշխատելու կամ տեղականում աշխատելու միջև: :nonode@nohost. Այս մասին ավելին կարող եք կարդալ այստեղ փաստաթղթավորում.

Չնայած տոպոլոգիայի փոփոխությունների բարդ կառավարումը հնարավոր է մաքսային իրականացման միջոցով MyApp.Listener, միշտ կարող են լինել եզրային դեպքեր, երբ գրադարանի այս սահմանափակումները և կազմաձևման կողմնակալությունները ապացուցում են որպես իրականացման հիմնաքար: Դա լավ է, պարզապես վերցրեք վերը նշվածը libcluster, որն ավելի ընդհանուր նշանակության է, կամ նույնիսկ ինքներդ կարգավորեք ցածր մակարդակի կլաստերը: Այս կոդերի գրադարանի նպատակն է ոչ թե լուսաբանել բոլոր հնարավոր սցենարները, այլ օգտագործել ամենատարածված սցենարը առանց ավելորդ ցավի և ծանր պատճենահանման:

Նշում: Բնօրինակում այս պահին կար «Happy clustering» արտահայտությունը, և Yandex-ը, որով ես թարգմանում եմ (ես ստիպված չեմ ինքս բառարաններով անցնել), ինձ առաջարկեց «Happy clustering» տարբերակը: Ավելի լավ թարգմանություն, հատկապես ներկայիս աշխարհաքաղաքական իրավիճակի լույսի ներքո, թերեւս անհնար է պատկերացնել:

Source: www.habr.com