Բարև, Հաբր։ Ես Արտեմ Քարամիշևն եմ, համակարգի կառավարման թիմի ղեկավարը։ Անցած տարվա ընթացքում մենք ունեցել ենք բազմաթիվ նոր արտադրանքի թողարկումներ: Մենք ցանկանում էինք համոզվել, որ API ծառայությունները հեշտությամբ մասշտաբելի են, խափանումներին դիմացկուն և պատրաստ են օգտատերերի ծանրաբեռնվածության արագ աճին: Մեր հարթակը ներդրված է OpenStack-ում, և ես ուզում եմ ձեզ պատմել, թե որ բաղադրիչների խափանումներին դիմացկունության խնդիրներն ենք ստիպված եղել լուծել՝ խափանումներին դիմացկուն համակարգ ստանալու համար: Կարծում եմ՝ սա հետաքրքիր կլինի նրանց համար, ովքեր նաև OpenStack-ում արտադրանք են մշակում:
Հարթակի ընդհանուր կայունությունը կազմված է դրա բաղադրիչների կայունությունից։ Այսպիսով, մենք աստիճանաբար կանցնենք բոլոր այն մակարդակներով, որտեղ մենք հայտնաբերել ենք ռիսկեր և փակել դրանք։
Այս պատմության տեսաերիզը, որի սկզբնական աղբյուրը Uptime day 4 կոնֆերանսի ժամանակ ներկայացված ներկայացումն էր, որը կազմակերպվել էր , կարող եք նայել .
Ֆիզիկական ճարտարապետության խափանումների հանդուրժողականություն
MCS ամպի հանրային մասը ներկայումս տեղակայված է երկու Tier III տվյալների կենտրոններում, որոնց միջև կա մասնավոր մութ մանրաթել, որը ֆիզիկական մակարդակով պահուստավորված է տարբեր երթուղիներով՝ 200 Գբ/վ թողունակությամբ: Tier III մակարդակը ապահովում է ֆիզիկական ենթակառուցվածքի համար անհրաժեշտ խափանումների հանդուրժողականության մակարդակը:
Մութ մանրաթելը ավելորդ է թե՛ ֆիզիկական, թե՛ տրամաբանական մակարդակներում: Ալիքների ավելորդության գործընթացը կրկնվող էր, առաջացան խնդիրներ, և մենք անընդհատ բարելավում ենք տվյալների կենտրոնների միջև կապը:
Օրինակ՝ ոչ այնքան վաղուց, տվյալների կենտրոններից մեկի մոտ գտնվող հորատանցքում աշխատանքների ժամանակ, էքսկավատորը ծակեց խողովակը, և ինչպես գլխավոր, այնպես էլ պահուստային օպտիկական մալուխները գտնվում էին այդ խողովակի ներսում։ Մեր խափանումներին դիմակայող կապի ալիքը տվյալների կենտրոնի հետ մի պահ՝ հորատանցքում, խոցելի դարձավ։ Հետևաբար, մենք կորցրեցինք ենթակառուցվածքների մի մասը։ Մենք եզրակացություններ արեցինք, ձեռնարկեցինք մի շարք գործողություններ, այդ թվում՝ հարևան հորատանցքի միջով լրացուցիչ օպտիկա անցկացնելը։
Տվյալների կենտրոններն ունեն կապի մատակարարների ներկայության կետեր, որոնց մենք հեռարձակում ենք մեր նախածանցները BGP-ի միջոցով: Յուրաքանչյուր ցանցային ուղղության համար ընտրվում է լավագույն չափանիշը, որը թույլ է տալիս մեզ ապահովել լավագույն կապի որակը տարբեր հաճախորդների համար: Եթե մեկ մատակարարի միջոցով կապը անջատվում է, մենք վերակառուցում ենք մեր երթուղայնացումը առկա մատակարարների միջոցով:
Մատակարարի խափանման դեպքում մենք ավտոմատ կերպով անցնում ենք հաջորդին։ Տվյալների կենտրոններից մեկի խափանման դեպքում մեր ծառայությունների հայելային պատճենը գտնվում է երկրորդ տվյալների կենտրոնում, որն էլ իր վրա է վերցնում ամբողջ բեռը։
Ֆիզիկական ենթակառուցվածքների դիմադրողականություն
Ինչ ենք մենք օգտագործում կիրառական մակարդակի սխալների հանդուրժողականության համար
Մեր ծառայությունը կառուցված է մի շարք բաց կոդով բաղադրիչների վրա։
ExaBGP — ծառայություն, որն իրականացնում է մի շարք գործառույթներ՝ օգտագործելով BGP-ի վրա հիմնված դինամիկ երթուղայնացման արձանագրությունը։ Մենք այն ակտիվորեն օգտագործում ենք մեր սպիտակ IP հասցեները հայտարարելու համար, որոնց միջոցով օգտատերերը մուտք են ստանում API-ին։
HAProxy — բարձր ծանրաբեռնվածության հավասարակշռիչ, որը թույլ է տալիս կարգավորել շատ ճկուն երթևեկության հավասարակշռման կանոններ OSI մոդելի տարբեր մակարդակներում: Մենք այն օգտագործում ենք բոլոր ծառայություններից առաջ հավասարակշռելու համար՝ տվյալների բազաներ, հաղորդագրությունների բրոքերներ, API ծառայություններ, վեբ ծառայություններ, մեր ներքին նախագծեր՝ ամեն ինչ գտնվում է HAProxy-ի հետևում:
API հավելված — Python լեզվով գրված վեբ հավելված, որի օգնությամբ օգտատերը կառավարում է իր ենթակառուցվածքը, իր ծառայությունը։
Աշխատողի դիմում (այսուհետ՝ պարզապես աշխատող) — OpenStack ծառայություններում սա ենթակառուցվածքային դեմոն է, որը թույլ է տալիս API հրամանները փոխանցել ենթակառուցվածքին։ Օրինակ, սկավառակի ստեղծումը տեղի է ունենում worker-ում, իսկ ստեղծման հարցումը՝ API հավելվածում։
OpenStack հավելվածի ստանդարտ ճարտարապետություն
OpenStack-ի համար մշակված ծառայությունների մեծ մասը փորձում է հետևել մեկ մոդելի: Ծառայությունը սովորաբար բաղկացած է 2 մասից՝ API և աշխատողներ (backend կատարողներ): Որպես կանոն, API-ն Python-ով WSGI ծրագիր է, որը գործարկվում է կամ որպես անկախ գործընթաց (daemon), կամ պատրաստի Nginx, Apache վեբ սերվերի օգնությամբ: API-ն մշակում է օգտատիրոջ հարցումը և հետագա հրահանգները փոխանցում աշխատող ծրագրին: Փոխանցումը տեղի է ունենում հաղորդագրությունների բրոքերի միջոցով, սովորաբար RabbitMQ, մնացածը վատ են աջակցվում: Երբ հաղորդագրությունները հասնում են բրոքերին, դրանք մշակվում են աշխատողների կողմից և, անհրաժեշտության դեպքում, վերադարձնում են պատասխան:
Այս մոդելը ենթադրում է մեկուսացված ընդհանուր խափանման կետեր՝ RabbitMQ-ն և տվյալների բազան։ Սակայն RabbitMQ-ն մեկուսացված է մեկ ծառայության շրջանակներում և, տեսականորեն, կարող է լինել անհատական յուրաքանչյուր ծառայության համար։ Այսպիսով, MCS-ում մենք հնարավորինս առանձնացնում ենք այս ծառայությունները, յուրաքանչյուր առանձին նախագծի համար ստեղծում ենք առանձին տվյալների բազա, առանձին RabbitMQ։ Այս մոտեցումը լավ է, քանի որ որոշ խոցելի կետերում վթարի դեպքում ոչ թե ամբողջ ծառայությունը է խափանվում, այլ միայն դրա մի մասը։
Աշխատող ծրագրերի քանակի սահմանափակում չկա, ուստի API-ը կարող է հեշտությամբ մասշտաբավորվել հորիզոնականորեն հավասարակշռիչների հետևում՝ արտադրողականությունը և սխալների նկատմամբ հանդուրժողականությունը բարձրացնելու համար։
Որոշ ծառայություններ պահանջում են համակարգում ծառայության ներսում՝ երբ API-ի և աշխատողների միջև տեղի են ունենում բարդ հաջորդական գործողություններ: Այս դեպքում օգտագործվում է մեկ համակարգման կենտրոն՝ կլաստերային համակարգ, ինչպիսիք են Redis-ը, Memcache-ը և այլն, որը թույլ է տալիս մեկ աշխատողին ասել մյուսին, որ այս առաջադրանքը հանձնարարված է իրեն («խնդրում եմ, մի՛ վերցրեք այն»): Մենք օգտագործում ենք etcd-ն: Որպես կանոն, աշխատողները ակտիվորեն շփվում են տվյալների բազայի հետ, գրում և կարդում են տեղեկատվություն դրանից: Որպես տվյալների բազա, մենք օգտագործում ենք mariadb-ը, որը գտնվում է մեր բազմամաստեր կլաստերում:
Այսպիսի դասական մեկ ծառայությունը կազմակերպված է OpenStack-ի համար ընդհանուր առմամբ ընդունված ձևով։ Այն կարելի է դիտարկել որպես փակ համակարգ, որի համար մասշտաբավորման և սխալների նկատմամբ հանդուրժողականության մեթոդները բավականին ակնհայտ են։ Օրինակ, API-ների սխալների նկատմամբ հանդուրժողականության համար բավական է դրանց առջև հավասարակշռիչ դնել։ Աշխատողների մասշտաբավորումը իրականացվում է նրանց թիվը մեծացնելով։
Ամբողջ սխեմայի թույլ կողմը RabbitMQ-ն և MariaDB-ն են: Նրանց ճարտարապետությունը արժանի է առանձին հոդվածի: Այս հոդվածում ես ուզում եմ կենտրոնանալ API-ի սխալների նկատմամբ հանդուրժողականության վրա:
Openstack հավելվածի ճարտարապետություն։ Ամպային հարթակի հավասարակշռում և խափանումների հանդուրժողականություն։
HAProxy բեռի հավասարակշռիչի խափանումների նկատմամբ հանդուրժողականության բարձրացում ExaBGP-ի միջոցով
Մեր API-ները մասշտաբայնելի, արագ և խափանումների նկատմամբ դիմացկուն դարձնելու համար մենք դրանց առջև դրեցինք հավասարակշռիչ։ Մենք ընտրեցինք HAProxy-ն։ Իմ կարծիքով, այն ունի մեր առաջադրանքի համար անհրաժեշտ բոլոր բնութագրերը՝ հավասարակշռում մի քանի OSI մակարդակներում, կառավարման ինտերֆեյս, ճկունություն և մասշտաբայնություն, հավասարակշռման մեծ թվով մեթոդներ, սեսիայի աղյուսակների աջակցություն։
Առաջին խնդիրը, որը պետք է լուծվեր, հավասարակշռիչի խափանումների նկատմամբ հանդուրժողականությունն էր։ Հավասարակշռիչի պարզապես տեղադրումը նույնպես ստեղծում է ձախողման կետ. հավասարակշռիչը խափանվում է, այսինքն՝ ծառայությունը խափանվում է։ Դա կանխելու համար մենք օգտագործեցինք HAProxy-ն ExaBGP-ի հետ միասին։
ExaBGP-ն թույլ է տալիս ներդնել ծառայության առողջության ստուգման մեխանիզմ: Մենք օգտագործել ենք այս մեխանիզմը՝ HAProxy-ի առողջությունը ստուգելու և խնդիրների դեպքում BGP-ից HAProxy ծառայությունը անջատելու համար:
ExaBGP+HAProxy սխեմա
- Մենք անհրաժեշտ ծրագրերը՝ ExaBGP-ն և HAProxy-ն, տեղադրում ենք երեք սերվերների վրա։
- Սերվերներից յուրաքանչյուրի վրա մենք ստեղծում ենք loopback ինտերֆեյս։
- Բոլոր երեք սերվերների վրա մենք գրանցում ենք նույն սպիտակ IP հասցեն այս ինտերֆեյսի վրա։
- Սպիտակ IP հասցեն ինտերնետին հայտարարվում է ExaBGP-ի միջոցով։
Խափանումների նկատմամբ հանդուրժողականությունը ապահովվում է բոլոր երեք սերվերներից նույն IP հասցեն հայտարարելով։ Ցանցի տեսանկյունից, նույն հասցեն հասանելի է երեք տարբեր հաջորդական ցատկերից։ Ռաութերը տեսնում է երեք նույնական երթուղիներ, ընտրում է ամենաբարձր առաջնահերթությունը՝ հիմնվելով իր սեփական չափանիշի վրա (սովորաբար նույն տարբերակը), և երթևեկությունը գնում է սերվերներից միայն մեկին։
HAProxy-ի աշխատանքի կամ սերվերի խափանման դեպքում ExaBGP-ն դադարեցնում է երթուղու գովազդը, և երթևեկությունը սահուն կերպով անցնում է մեկ այլ սերվերի։
Այսպիսով, մենք հասանք հավասարակշռիչի մեղքի հանդուրժողականությանը։
HAProxy բեռի հավասարակշռիչի խափանումների հանդուրժողականություն
Սխեման անկատար դուրս եկավ. մենք սովորեցինք HAProxy-ն ամրագրել, բայց չսովորեցինք բեռը բաշխել ծառայությունների միջև։ Հետևաբար, մենք մի փոքր ընդլայնեցինք այս սխեման. մենք անցանք մի քանի սպիտակ IP հասցեների միջև հավասարակշռման։
DNS-ի վրա հիմնված հավասարակշռում գումարած BGP
Մեր HAProxy-ի առջև բեռի հավասարակշռման խնդիրը մնում է չլուծված։ Այնուամենայնիվ, այն կարող է լուծվել բավականին պարզ, ինչպես մենք արեցինք մերում։
Երեք սերվերների հավասարակշռման համար ձեզ անհրաժեշտ կլինեն երեք սպիտակ IP հասցեներ և հին, լավ DNS: Այս հասցեներից յուրաքանչյուրը սահմանվում է յուրաքանչյուր HAProxy-ի loopback ինտերֆեյսի վրա և հայտարարվում է ինտերնետին:
OpenStack-ում ռեսուրսները կառավարելու համար օգտագործվում է ծառայությունների կատալոգ, որտեղ նշված է որոշակի ծառայության API վերջնակետը: Այս կատալոգում մենք նշում ենք դոմեյնի անունը՝ public.infra.mail.ru, որը DNS-ի միջոցով լուծվում է երեք տարբեր IP հասցեներով: Արդյունքում, DNS-ի միջոցով ստանում ենք բեռի բաշխում երեք հասցեների միջև:
Սակայն, քանի որ մենք չենք վերահսկում սերվերի ընտրության առաջնահերթությունները՝ սպիտակ ցուցակում ներառված IP հասցեները հայտարարելիս, սա դեռևս հավասարակշռություն չէ։ Սովորաբար, IP հասցեի ավագության հիման վրա կընտրվի միայն մեկ սերվեր, իսկ մյուս երկուսը կլինեն անգործուն, քանի որ BGP-ում որևէ չափանիշ նշված չէ։
Մենք սկսեցինք ExaBGP-ի միջոցով երթուղիներ տրամադրել տարբեր չափանիշներով: Յուրաքանչյուր հավասարակշռիչ հայտարարում է բոլոր երեք սպիտակ IP հասցեները, բայց դրանցից մեկը՝ այս հավասարակշռիչի հիմնականը, հայտարարվում է նվազագույն չափանիշով: Այսպիսով, մինչ բոլոր երեք հավասարակշռիչները գործում են, առաջին IP հասցեին ուղղված հարցումները գնում են առաջին հավասարակշռիչին, երկրորդին՝ երկրորդին, երրորդին՝ երրորդին:
Ի՞նչ է պատահում, երբ հավասարակշռիչներից մեկը խափանվում է։ Երբ որևէ հավասարակշռիչ խափանվում է, նրա հիմնական հասցեն դեռևս գովազդվում է մյուս երկուսից, և երթևեկությունը վերաբաշխվում է նրանց միջև։ Այսպիսով, մենք օգտատիրոջը միաժամանակ մի քանի IP հասցե ենք տալիս DNS-ի միջոցով։ DNS-ի և տարբեր չափանիշների միջոցով հավասարակշռելով՝ մենք ստանում ենք բեռի հավասարաչափ բաշխում բոլոր երեք հավասարակշռիչների վրա։ Եվ միևնույն ժամանակ, մենք չենք կորցնում խափանումների նկատմամբ հանդուրժողականությունը։
HAProxy բեռի հավասարակշռում DNS + BGP-ի հիման վրա
ExaBGP-ի և HAProxy-ի փոխազդեցությունը
Այսպիսով, մենք ներդրել ենք խափանումների հանդուրժողականություն սերվերի խափանման դեպքում՝ հիմնվելով երթուղային հայտարարությունների դադարեցման վրա: Սակայն HAProxy-ն կարող է անջատվել նաև սերվերի խափանումից բացի այլ պատճառներով՝ կառավարման սխալներ, ծառայության ներսում խափանումներ: Այս դեպքերում նույնպես մենք ցանկանում ենք հեռացնել խափանված հավասարակշռիչը ծանրաբեռնվածությունից, և մեզ անհրաժեշտ է մեկ այլ մեխանիզմ:
Հետևաբար, նախորդ սխեման ընդլայնելով, մենք իրականացրեցինք ExaBGP-ի և HAProxy-ի միջև փոխազդեցության փոխազդեցության ծրագրային իրականացում, երբ ExaBGP-ն օգտագործում է հատուկ սկրիպտներ՝ հավելվածների կարգավիճակը ստուգելու համար։
Դրա համար դուք պետք է ExaBGP կոնֆիգուրացիայում կարգավորեք առողջության ստուգիչ, որը կարող է ստուգել HAProxy-ի կարգավիճակը: Մեր դեպքում մենք HAProxy-ում կարգավորել ենք առողջության backend-ը, և ExaBGP-ի կողմից մենք ստուգում ենք պարզ GET հարցման միջոցով: Եթե հայտարարությունը դադարում է, ապա HAProxy-ն, ամենայն հավանականությամբ, չի աշխատում, և դրա մասին հայտարարելու կարիք չկա:
HAProxy-ի առողջության ստուգում
HAProxy Peers: Սեսիայի համաժամեցում
Հաջորդ բանը, որ պետք էր անել, սեսիաների համաժամեցումն էր։ Բաշխված հավասարակշռիչների միջոցով աշխատելիս դժվար է կազմակերպել հաճախորդի սեսիաների մասին տեղեկատվության պահպանումը։ Սակայն HAProxy-ն այն քիչ հավասարակշռիչներից մեկն է, որը կարող է դա անել Peers ֆունկցիոնալության շնորհիվ՝ սեսիայի աղյուսակը տարբեր HAProxy պրոցեսների միջև փոխանցելու հնարավորությամբ։
Կան հավասարակշռման տարբեր մեթոդներ՝ պարզերը, օրինակ՝ , և ընդլայնվածները, երբ հաճախորդի սեսիան հիշվում է, և ամեն անգամ, երբ նա հասնում է նույն սերվերին, ինչ նախկինում։ Մենք ցանկանում էինք իրականացնել երկրորդ տարբերակը։
HAProxy-ն օգտագործում է stick աղյուսակներ՝ այս մեխանիզմի հաճախորդի սեսիաները պահելու համար: Դրանք պահում են հաճախորդի աղբյուրի IP հասցեն, ընտրված թիրախային հասցեն (backend) և որոշ ծառայության տեղեկություններ: Stick աղյուսակները սովորաբար օգտագործվում են աղբյուրի IP + նպատակակետի IP զույգը պահելու համար, ինչը հատկապես օգտակար է այն ծրագրերի համար, որոնք չեն կարող փոխանցել օգտատիրոջ սեսիայի համատեքստը մեկ այլ հավասարակշռիչի անցնելիս, օրինակ՝ RoundRobin հավասարակշռման ռեժիմում:
Եթե մենք սովորեցնենք stick աղյուսակին տեղաշարժվել տարբեր HAProxy պրոցեսների միջև (որոնց միջև տեղի է ունենում հավասարակշռում), մեր հավասարակշռիչները կկարողանան աշխատել stick աղյուսակների մեկ խմբի հետ։ Սա թույլ կտա անխափան փոխարկում կատարել հաճախորդի ցանցում, երբ հավասարակշռիչներից մեկը խափանվի, հաճախորդի սեսիաների հետ աշխատանքը կշարունակվի նույն backend-ներում, որոնք ընտրվել են ավելի վաղ։
Ճիշտ աշխատանքի համար պետք է լուծվի այն հավասարակշռիչի աղբյուրի IP հասցեի խնդիրը, որից սեսիան հաստատվում է: Մեր դեպքում սա դինամիկ հասցե է loopback ինտերֆեյսի վրա:
Հասկացողները ճիշտ են աշխատում միայն որոշակի պայմաններում։ Այսինքն՝ TCP-ի ժամանակի ավարտը պետք է բավականաչափ մեծ լինի, կամ փոխարկումը պետք է լինի բավականաչափ արագ, որպեսզի TCP սեսիան ժամանակ չունենա ընդհատվելու։ Այնուամենայնիվ, սա թույլ է տալիս անխափան փոխարկում։
Մենք ունենք IaaS ծառայություն, որը կառուցված է նույն տեխնոլոգիայի վրա։ Սա է , որը կոչվում է Octavia: Այն հիմնված է երկու HAProxy գործընթացների վրա, սկզբից ի վեր ունի ներկառուցված գործընկերների աջակցություն: Նրանք ապացուցել են, որ գերազանց են այս ծառայությունում:
Նկարում սխեմատիկորեն ցույց է տրված peer աղյուսակների տեղաշարժը երեք HAProxy ինստանսների միջև, և առաջարկվում է կարգավորում, թե ինչպես կարելի է այն կարգավորել։
HAProxy Peers (սեսիայի համաժամեցում)
Եթե դուք ներդնում եք նույն սխեման, ապա պետք է այն ուշադիր փորձարկեք։ Փաստ չէ, որ այն նույն ձևով կաշխատի դեպքերի 100%-ում։ Բայց առնվազն դուք չեք կորցնի stick աղյուսակները, երբ անհրաժեշտ լինի հիշել հաճախորդի սկզբնական IP հասցեն։
Նույն հաճախորդից միաժամանակյա հարցումների քանակի սահմանափակում
Ցանկացած հանրային հասանելի ծառայություն, այդ թվում՝ մեր API-ները, կարող են ենթարկվել հարցումների ձնահոսքի։ Դրանց պատճառները կարող են բոլորովին տարբեր լինել՝ օգտատիրոջ սխալներից մինչև թիրախային հարձակումներ։ Մենք պարբերաբար ենթարկվում ենք DDoS հարձակումների IP հասցեների միջոցով։ Հաճախորդները հաճախ սխալներ են թույլ տալիս իրենց սկրիպտներում, ինչը հանգեցնում է մինի-DDoS հարձակումների։
Այսպես թե այնպես, պետք է ապահովվի լրացուցիչ պաշտպանություն: Ակնհայտ լուծումը API-ին ուղղված հարցումների քանակը սահմանափակելն է և մշակողի ժամանակը չվատնել չարամիտ հարցումները մշակելու վրա:
Նման սահմանափակումներ իրականացնելու համար մենք օգտագործում ենք արագության սահմանափակումներ, որոնք կազմակերպված են HAProxy-ի հիման վրա՝ օգտագործելով նույն աղյուսակները: Սահմանափակումները կարգավորվում են բավականին պարզ և թույլ են տալիս սահմանափակել օգտատիրոջը API-ին ուղղված հարցումների քանակով: Ալգորիթմը հիշում է այն աղբյուրի IP-ն, որից կատարվում են հարցումները, և սահմանափակում է մեկ օգտատիրոջից միաժամանակյա հարցումների քանակը: Իհարկե, մենք հաշվարկել ենք API-ի միջին ծանրաբեռնվածության պրոֆիլը յուրաքանչյուր ծառայության համար և սահմանել այս արժեքից ≈ 10 անգամ մեծ սահմանաչափ: Մենք շարունակում ենք ուշադիր հետևել իրավիճակին՝ հետևելով իրավիճակին:
Ինչպե՞ս է սա երևում գործնականում։ Մենք ունենք հաճախորդներ, որոնք անընդհատ օգտագործում են մեր API-ները ավտոմատ մասշտաբավորման համար։ Նրանք առավոտյան մոտ ստեղծում են մոտ երկու կամ երեք հարյուր վիրտուալ մեքենա և երեկոյան մոտ ջնջում դրանք։ OpenStack-ի համար վիրտուալ մեքենա ստեղծելը, հատկապես PaaS ծառայություններով, առնվազն 1000 API հարցում է, քանի որ ծառայությունների միջև փոխազդեցությունը նույնպես տեղի է ունենում API-ի միջոցով։
Նման առաջադրանքների փոխանցումները բավականին մեծ ծանրաբեռնվածություն են առաջացնում։ Մենք գնահատել ենք այս ծանրաբեռնվածությունը, հավաքել օրական գագաթնակետերը, տասնապատկել դրանք, և սա դարձել է մեր արագության սահմանաչափը։ Մենք հետևում ենք մեր արագությանը։ Մենք հաճախ տեսնում ենք բոտեր, սկաներներ, որոնք փորձում են տեսնել, թե արդյոք մենք ունենք որևէ CGA սկրիպտ, որը կարող է գործարկվել, մենք ակտիվորեն անջատում ենք դրանք։
Ինչպես թարմացնել կոդի բազան՝ առանց օգտատերերի նկատելու
Մենք նաև ներդնում ենք սխալների նկատմամբ հանդուրժողականություն կոդի տեղակայման գործընթացների մակարդակում: Տեղադրման ընթացքում լինում են խափանումներ, բայց դրանց ազդեցությունը ծառայության մատչելիության վրա կարելի է նվազագույնի հասցնել:
Մենք անընդհատ թարմացնում ենք մեր ծառայությունները և պետք է ապահովենք, որ կոդի բազան թարմացվի առանց օգտատերերի վրա ազդելու։ Մենք դրան հասել ենք՝ օգտագործելով HAProxy-ի կառավարման հնարավորությունները և մեր ծառայություններում ներդնելով Graceful Shutdown-ը։
Այս խնդիրը լուծելու համար անհրաժեշտ էր ապահովել հավասարակշռության կառավարումը և ծառայությունների «ճիշտ» անջատումը.
- HAProxy-ի դեպքում կառավարումը կատարվում է stats ֆայլի միջոցով, որը, ըստ էության, socket է և սահմանված է HAProxy կոնֆիգուրացիայում: Դուք կարող եք հրամաններ փոխանցել դրան stdio-ի միջոցով: Բայց մեր հիմնական կոնֆիգուրացիայի կառավարման գործիքը ansible-ն է, ուստի այն ունի ներկառուցված մոդուլ HAProxy-ն կառավարելու համար: Որը մենք ակտիվորեն օգտագործում ենք:
- Մեր API և Engine ծառայությունների մեծ մասը աջակցում է նրբագեղ անջատման տեխնոլոգիաներ. անջատելիս դրանք սպասում են ընթացիկ առաջադրանքի ավարտին, լինի դա http հարցում, թե որևէ ծառայողական առաջադրանք: Նույնը կատարվում է նաև աշխատողի հետ: Այն գիտի իր կատարած բոլոր առաջադրանքները և ավարտում է աշխատանքը, երբ ամեն ինչ հաջողությամբ ավարտում է:
Այս երկու կետերի շնորհիվ մեր անվտանգ տեղակայման ալգորիթմը այսպիսի տեսք ունի։
- Մշակողը կառուցում է նոր կոդի փաթեթ (մեր դեպքում դա RPM է), փորձարկում է այն մշակողի միջավայրում, փորձարկում է այն բեմում և թողնում է բեմի պահոցում։
- Մշակողը տեղադրում է տեղակայման առաջադրանք՝ «արտեֆակտների» առավել մանրամասն նկարագրությամբ՝ նոր փաթեթի տարբերակը, նոր ֆունկցիոնալության նկարագրությունը և անհրաժեշտության դեպքում տեղակայման վերաբերյալ այլ մանրամասներ։
- Համակարգի ադմինիստրատորը սկսում է թարմացումը։ Գործարկում է Ansible-ի ուղեցույցը, որն իր հերթին կատարում է հետևյալը.
- Վերցնում է փաթեթ բեյսի պահոցից և թարմացնում է փաթեթի տարբերակը ապրանքի պահոցում՝ հիմնվելով դրա վրա։
- Կազմում է թարմացվող ծառայության backend-ների ցանկը։
- Անջատում է HAProxy-ի առաջին թարմացվող ծառայությունը և սպասում է դրա գործընթացների ավարտին: Անխափան անջատումը ապահովում է, որ բոլոր ընթացիկ հաճախորդների հարցումները հաջողությամբ կավարտվեն:
- API-ի, աշխատողների և HAProxy-ի անջատումից հետո կոդը թարմացվում է։
- Ansible-ը սկսում է ծառայություններ մատուցել։
- Յուրաքանչյուր ծառայության համար կիրառվում են որոշակի «բռնակներ», որոնք կատարում են միավորային թեստավորում նախապես սահմանված մի շարք բանալիային թեստերի վրա: Տեղի է ունենում նոր կոդի հիմնական ստուգում:
- Եթե նախորդ քայլում սխալներ չեն հայտնաբերվել, backend-ը ակտիվանում է։
- Եկեք անցնենք հաջորդ backend-ին։
- Բոլոր backend-ները թարմացնելուց հետո կատարվում են ֆունկցիոնալ թեստեր։ Եթե դրանք բացակայում են, մշակողը դիտարկում է իր կողմից արված ցանկացած նոր ֆունկցիոնալություն։
Սա ավարտում է տեղակայումը։
Ծառայության թարմացման ցիկլ
Այս սխեման չէր աշխատի, եթե մենք չունենայինք մեկ կանոն։ Մենք մարտում միաժամանակ աջակցում ենք հին և նոր տարբերակները։ Նախապես, ծրագրային ապահովման մշակման փուլում, սահմանված է, որ նույնիսկ եթե ծառայության տվյալների բազայում փոփոխություններ լինեն, դրանք չեն խախտի նախորդ կոդը։ Արդյունքում, տեղի է ունենում կոդի բազայի աստիճանական թարմացում։
Ամփոփում
Կիսվելով սխալներին դիմացկուն վեբ ճարտարապետության վերաբերյալ իմ սեփական մտքերով՝ կցանկանայի ևս մեկ անգամ ընդգծել դրա հիմնական կետերը.
- ֆիզիկական թերությունների նկատմամբ հանդուրժողականություն;
- ցանցի խափանումների հանդուրժողականություն (հավասարակշռիչներ, BGP);
- օգտագործված և մշակված ծրագրաշարի սխալների նկատմամբ հանդուրժողականությունը։
Բոլորիդ կայուն անխափան աշխատանք ունեցեք։
Source: www.habr.com
