One-cloud - տվյալների կենտրոնի մակարդակի ՕՀ Օդնոկլասնիկիում

Ալոհա, ժողովուրդ! Ես Օլեգ Անաստասևն եմ, աշխատում եմ Odnoklassniki-ում Պլատֆորմի թիմում: Եվ բացի ինձնից, Օդնոկլասնիկիում շատ տեխնիկա է աշխատում։ Մենք ունենք չորս տվյալների կենտրոն՝ մոտ 500 դարակներով՝ ավելի քան 8 հազար սերվերով։ Որոշակի պահի մենք հասկացանք, որ կառավարման նոր համակարգի ներդրումը թույլ կտա մեզ ավելի արդյունավետ բեռնել սարքավորումները, հեշտացնել մուտքի կառավարումը, ավտոմատացնել հաշվողական ռեսուրսների (վեր)բաշխումը, արագացնել նոր ծառայությունների գործարկումը և արագացնել արձագանքները: խոշոր չափի վթարների.

Ի՞նչ ստացվեց դրանից:

Բացի ինձանից և մի շարք սարքավորումներից, կան նաև մարդիկ, ովքեր աշխատում են այս սարքաշարով. ինժեներներ, որոնք գտնվում են անմիջապես տվյալների կենտրոններում. ցանցային աշխատողներ, ովքեր ստեղծում են ցանցային ծրագրակազմ; ադմինիստրատորներ կամ SRE-ներ, որոնք ապահովում են ենթակառուցվածքի ճկունություն. և զարգացման թիմերը, որոնցից յուրաքանչյուրը պատասխանատու է պորտալի գործառույթների մի մասի համար: Նրանց ստեղծած ծրագրաշարն աշխատում է այսպես.

Օգտատիրոջ հարցումները ստացվում են ինչպես հիմնական պորտալի ճակատներում www.ok.ru, և մյուսների վրա, օրինակ՝ երաժշտական ​​API-ի ճակատներում: Բիզնեսի տրամաբանությունը մշակելու համար նրանք կանչում են հավելվածի սերվեր, որը հարցումը մշակելիս կանչում է անհրաժեշտ մասնագիտացված միկրոծառայություններ՝ մեկ գրաֆիկ (սոցիալական կապերի գրաֆիկ), օգտատեր-քեշ (օգտատերերի պրոֆիլների քեշ) և այլն։

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

Ինչո՞ւ է այդպես։ Այս մոտեցումը մի քանի առավելություն ուներ.

• Թեթևացած զանգվածային կառավարում. Ենթադրենք, առաջադրանքը պահանջում է որոշ գրադարաններ, որոշ կարգավորումներ: Եվ այնուհետև սերվերը նշանակվում է հենց մեկ կոնկրետ խմբի, նկարագրված է cfengine քաղաքականությունը այս խմբի համար (կամ այն ​​արդեն նկարագրված է), և այս կոնֆիգուրացիան կենտրոնացված և ավտոմատ կերպով տարածվում է այս խմբի բոլոր սերվերների վրա:
• Պարզեցված ախտորոշում. Ենթադրենք, դուք նայում եք կենտրոնական պրոցեսորի ավելացած բեռնվածությանը և հասկանում, որ այդ բեռը կարող է առաջանալ միայն այս ապարատային պրոցեսորի վրա աշխատող առաջադրանքից: Մեղադրողի որոնումները շատ արագ ավարտվում են։
• Պարզեցված Դիտարկման. Եթե ​​սերվերի հետ ինչ-որ բան այն չէ, մոնիտորը հաղորդում է այն, և դուք հստակ գիտեք, թե ով է մեղավոր:

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

Այս մոտեցումն էլ մեզ թույլ տվեց մասնագիտացված երկաթի կոնֆիգուրացիաներ այս սերվերում աշխատող առաջադրանքի համար: Եթե ​​առաջադրանքը պահպանում է մեծ քանակությամբ տվյալներ, ապա մենք օգտագործում ենք 4U սերվեր՝ 38 սկավառակով շասսիով: Եթե ​​առաջադրանքը զուտ հաշվողական է, ապա մենք կարող ենք գնել ավելի էժան 1U սերվեր: Սա հաշվողականորեն արդյունավետ է: Ի թիվս այլ բաների, այս մոտեցումը մեզ թույլ է տալիս չորս անգամ ավելի քիչ մեքենաներ օգտագործել մեկ ընկերական սոցիալական ցանցի հետ համեմատելի ծանրաբեռնվածությամբ:

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

Հասկանալով, որ դա այդպես է, մենք որոշեցինք հաշվարկել, թե որքան արդյունավետ ենք օգտագործում դարակաշարերը:
Մենք վերցրել ենք ամենահզոր սերվերի գինը տնտեսապես արդարացնողներից, հաշվարկել ենք, թե քանի այդպիսի սերվեր կարող ենք տեղադրել դարակաշարերում, քանի առաջադրանք կգործարկենք դրանց վրա՝ հիմնվելով «մեկ սերվեր = մեկ առաջադրանք» հին մոդելի վրա և որքան այդպիսին։ առաջադրանքները կարող են օգտագործել սարքավորումները: Հաշվեցին ու արցունք թափեցին։ Պարզվեց, որ դարակաշարերի օգտագործման մեր արդյունավետությունը մոտ 11% է: Եզրակացությունն ակնհայտ է՝ պետք է բարձրացնել տվյալների կենտրոնների օգտագործման արդյունավետությունը։ Թվում է, թե լուծումն ակնհայտ է՝ դուք պետք է միանգամից մի քանի առաջադրանք կատարեք մեկ սերվերի վրա։ Բայց այստեղից են սկսվում դժվարությունները։

Զանգվածային կոնֆիգուրացիան դառնում է կտրուկ ավելի բարդ. այժմ անհնար է որևէ մեկ խումբ վերագրել սերվերին: Ի վերջո, այժմ տարբեր հրամանների մի քանի առաջադրանքներ կարող են գործարկվել մեկ սերվերի վրա: Բացի այդ, կոնֆիգուրացիան կարող է հակասական լինել տարբեր հավելվածների համար: Ախտորոշումը նույնպես ավելի բարդ է դառնում. եթե սերվերի վրա տեսնում եք պրոցեսորի կամ սկավառակի սպառման ավելացում, դուք չգիտեք, թե որ առաջադրանքն է խանգարում:

Բայց գլխավորն այն է, որ նույն մեքենայի վրա աշխատող առաջադրանքների միջև մեկուսացում չկա: Ահա, օրինակ, սերվերի առաջադրանքի միջին արձագանքման ժամանակի գրաֆիկը նույն սերվերում մեկ այլ հաշվողական հավելվածի գործարկումից առաջ և հետո, որը ոչ մի կերպ կապված չէ առաջինի հետ. հիմնական առաջադրանքի արձագանքման ժամանակը զգալիորեն աճել է:

Ակնհայտ է, որ դուք պետք է առաջադրանքներ կատարեք կամ բեռնարկղերում կամ վիրտուալ մեքենաներում: Քանի որ մեր գրեթե բոլոր առաջադրանքները աշխատում են մեկ ՕՀ-ի (Linux) տակ կամ հարմարեցված են դրա համար, մենք կարիք չունենք աջակցելու բազմաթիվ տարբեր օպերացիոն համակարգերին: Համապատասխանաբար, վիրտուալացումն անհրաժեշտ չէ լրացուցիչ ծախսերի պատճառով, այն ավելի քիչ արդյունավետ կլինի, քան կոնտեյներացումը:

Որպես կոնտեյներների ներդրում ուղղակիորեն սերվերների վրա առաջադրանքների կատարման համար, Docker-ը լավ թեկնածու է. ֆայլային համակարգի պատկերները լավ լուծում են հակասական կոնֆիգուրացիաների հետ կապված խնդիրները: Այն փաստը, որ պատկերները կարող են կազմված լինել մի քանի շերտերից, մեզ թույլ է տալիս զգալիորեն նվազեցնել տվյալների քանակը, որոնք անհրաժեշտ են դրանք ենթակառուցվածքում տեղակայելու համար՝ բաժանելով ընդհանուր մասերը առանձին բազային շերտերի: Այնուհետև հիմնական (և ամենածավալուն) շերտերը բավականին արագ կպահվեն ամբողջ ենթակառուցվածքում, և շատ տարբեր տեսակի հավելվածներ և տարբերակներ տրամադրելու համար անհրաժեշտ կլինի տեղափոխել միայն փոքր շերտեր:

Բացի այդ, պատրաստի ռեեստրը և Docker-ում պատկերների պիտակավորումը մեզ տալիս են պատրաստի պրիմիտիվներ՝ տարբերակման և կոդն արտադրություն հասցնելու համար:

Docker-ը, ինչպես ցանկացած այլ նմանատիպ տեխնոլոգիա, մեզ տրամադրում է տուփից դուրս գտնվող կոնտեյների մեկուսացման որոշակի մակարդակ: Օրինակ, հիշողության մեկուսացում. յուրաքանչյուր կոնտեյների տրվում է մեքենայի հիշողության օգտագործման սահմանափակում, որից այն կողմ այն ​​չի սպառվի: Կարող եք նաև մեկուսացնել տարաները՝ հիմնվելով պրոցեսորի օգտագործման վրա: Մեզ համար, սակայն, ստանդարտ մեկուսացումը բավարար չէր։ Բայց դրա մասին ավելին ստորև:

Սերվերների վրա կոնտեյներների ուղղակի գործարկումը խնդրի միայն մի մասն է: Մյուս մասը կապված է սերվերների վրա կոնտեյներների հոսթինգի հետ։ Դուք պետք է հասկանաք, թե որ կոնտեյները որ սերվերի վրա կարող է տեղադրվել: Սա այնքան էլ հեշտ խնդիր չէ, քանի որ կոնտեյներները պետք է հնարավորինս խիտ տեղադրվեն սերվերների վրա՝ չնվազեցնելով դրանց արագությունը։ Նման տեղադրումը կարող է դժվար լինել նաև սխալների հանդուրժողականության տեսանկյունից: Հաճախ մենք ցանկանում ենք միևնույն ծառայության կրկնօրինակները տեղադրել տարբեր դարակներում կամ նույնիսկ տվյալների կենտրոնի տարբեր սենյակներում, որպեսզի եթե դարակը կամ սենյակը ձախողվի, մենք անմիջապես չկորցնենք ծառայության բոլոր կրկնօրինակները:

Կոնտեյներներ ձեռքով բաժանելը տարբերակ չէ, երբ ունես 8 հազար սերվեր և 8-16 հազար կոնտեյներ։

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

Ակնհայտ է, որ մեզ անհրաժեշտ է կառավարման շերտ, որը դա կանի ավտոմատ կերպով:

Այսպիսով, մենք հասանք մի պարզ և հասկանալի պատկերի, որը պաշտում են բոլոր ճարտարապետները՝ երեք քառակուսի:

one-cloud masters-ը ամպային նվագախմբի համար պատասխանատու ֆայլվեր կլաստեր է: Մշակողը վարպետին մանիֆեստ է ուղարկում, որը պարունակում է ծառայությունը հյուրընկալելու համար անհրաժեշտ բոլոր տեղեկությունները: Դրա հիման վրա վարպետը հրամաններ է տալիս ընտրված մինիոններին (կոնտեյներներ գործարկելու համար նախատեսված մեքենաներ): Մինիոններն ունեն մեր գործակալը, որը ստանում է հրամանը, տալիս է իր հրամանները Docker-ին, իսկ Docker-ը կարգավորում է Linux միջուկը՝ գործարկելու համապատասխան կոնտեյները։ Բացի հրամանների կատարումից, գործակալը շարունակաբար զեկուցում է վարպետին թե՛ minion մեքենայի, թե՛ դրա վրա աշխատող բեռնարկղերի վիճակի փոփոխությունների մասին:

Ռեսուրսների բաշխում

Հիմա եկեք նայենք շատ մինիոնների համար ավելի բարդ ռեսուրսների բաշխման խնդրին:

Մեկ ամպում հաշվողական ռեսուրսը հետևյալն է.

• Կոնկրետ առաջադրանքի կողմից սպառվող պրոցեսորի էներգիայի քանակը:
• Առաջադրանքին հասանելի հիշողության քանակը:
• Ցանցային տրաֆիկ. Մինիոններից յուրաքանչյուրն ունի հատուկ ցանցային ինտերֆեյս՝ սահմանափակ թողունակությամբ, ուստի անհնար է առաջադրանքները բաշխել՝ առանց հաշվի առնելու տվյալների քանակությունը, որը նրանք փոխանցում են ցանցով։
• Սկավառակներ. Բացի այդ, ակնհայտորեն, այս առաջադրանքների համար նախատեսված տարածքին մենք հատկացնում ենք նաև սկավառակի տեսակը՝ HDD կամ SSD: Սկավառակները կարող են սպասարկել վայրկյանում սահմանափակ թվով հարցումներ՝ IOPS: Հետևաբար, առաջադրանքների համար, որոնք առաջացնում են ավելի շատ IOPS, քան մեկ սկավառակը կարող է կառավարել, մենք նաև հատկացնում ենք «spindles», այսինքն՝ սկավառակի սարքեր, որոնք պետք է բացառապես վերապահված լինեն առաջադրանքի համար:

Այնուհետև ինչ-որ ծառայության համար, օրինակ՝ օգտագործողի քեշի համար, մենք կարող ենք գրանցել սպառված ռեսուրսներն այս կերպ՝ 400 պրոցեսորային միջուկ, 2,5 ՏԲ հիշողություն, 50 Գբիտ/վ երթևեկություն երկու ուղղություններով, 6 ՏԲ HDD տարածություն՝ տեղակայված 100 spindles-ի վրա: Կամ ավելի ծանոթ ձևով, ինչպիսին է սա.

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

Օգտատերերի քեշի սպասարկման ռեսուրսները սպառում են արտադրական ենթակառուցվածքում առկա բոլոր ռեսուրսների միայն մի մասը: Հետևաբար, ես ուզում եմ համոզվել, որ հանկարծ, օպերատորի սխալի պատճառով, թե ոչ, օգտագործողի քեշը չի սպառում ավելի շատ ռեսուրսներ, քան իրեն հատկացված է: Այսինքն՝ մենք պետք է սահմանափակենք ռեսուրսները։ Բայց ինչի՞ հետ կարող ենք կապել քվոտան։

Եկեք վերադառնանք բաղադրիչների փոխազդեցության մեր մեծապես պարզեցված դիագրամին և այն ավելի մանրամասն նկարագրենք՝ այսպես.

Ինչն է գրավում ձեր աչքը.

• Վեբ ճակատը և երաժշտությունը օգտագործում են նույն հավելվածի սերվերի մեկուսացված կլաստերները:
• Մենք կարող ենք տարբերակել տրամաբանական շերտերը, որոնց պատկանում են այս կլաստերները՝ ճակատներ, քեշեր, տվյալների պահպանման և կառավարման շերտ:
• Frontend-ը տարասեռ է, այն բաղկացած է տարբեր ֆունկցիոնալ ենթահամակարգերից:
• Քեշերը կարող են նաև ցրվել ենթահամակարգով, որի տվյալները պահվում են:

Եկեք նորից նկարենք նկարը.

Բահ! Այո, մենք տեսնում ենք հիերարխիա: Սա նշանակում է, որ դուք կարող եք բաշխել ռեսուրսները ավելի մեծ կտորներով. նշանակեք պատասխանատու մշակող այս հիերարխիայի հանգույցին, որը համապատասխանում է ֆունկցիոնալ ենթահամակարգին (ինչպես նկարում պատկերված «երաժշտությունը»), և կցեք քվոտա հիերարխիայի նույն մակարդակին: Այս հիերարխիան նաև թույլ է տալիս մեզ ավելի ճկուն կազմակերպել ծառայությունները՝ կառավարումը հեշտացնելու համար: Օրինակ, մենք ամբողջ վեբը բաժանում ենք, քանի որ սա սերվերների շատ մեծ խմբավորում է, մի քանի փոքր խմբերի, որոնք նկարում ներկայացված են որպես group1, group2:

Հավելյալ տողերը հեռացնելով՝ մենք կարող ենք մեր նկարի յուրաքանչյուր հանգույց գրել ավելի հարթ ձևով. group1.web.front, api.music.front, user-cache.cache.

Ահա թե ինչպես ենք հանգում «հիերարխիկ հերթ» հասկացությանը։ Այն ունի «group1.web.front» անուն: Դրան հատկացվում է ռեսուրսների և օգտատերերի իրավունքների քվոտա: Մենք DevOps-ից օգտվողին իրավունք կտանք ծառայություն ուղարկելու հերթում, և այդպիսի աշխատակիցը կարող է ինչ-որ բան գործարկել հերթում, իսկ OpsDev-ից օգտվողը կունենա ադմինիստրատորի իրավունքներ, և այժմ նա կարող է կառավարել հերթը, մարդկանց նշանակել այնտեղ, տալ այս մարդկանց իրավունքներ և այլն: Այս հերթում աշխատող ծառայությունները կաշխատեն հերթի քվոտայի շրջանակներում: Եթե ​​հերթի հաշվողական քվոտան բավարար չէ բոլոր ծառայությունները միանգամից կատարելու համար, ապա դրանք կկատարվեն հաջորդաբար՝ այդպիսով ձևավորելով հերթը:

Եկեք ավելի սերտ նայենք ծառայություններին: Ծառայությունն ունի լիովին որակավորված անվանում, որը միշտ ներառում է հերթի անվանումը: Այնուհետև ճակատային վեբ ծառայությունը կունենա անունը ok-web.group1.web.front. Եվ կկանչվի հավելվածի սերվերի ծառայությունը, որին հասանելի է ok-app.group1.web.front. Յուրաքանչյուր ծառայություն ունի մանիֆեստ, որը սահմանում է բոլոր անհրաժեշտ տեղեկությունները հատուկ մեքենաների վրա տեղադրելու համար. քանի ռեսուրս է սպառում այս առաջադրանքը, ինչ կոնֆիգուրացիա է անհրաժեշտ դրա համար, քանի կրկնօրինակներ պետք է լինեն, հատկություններ այս ծառայության խափանումները կարգավորելու համար: Եվ այն բանից հետո, երբ ծառայությունը տեղադրվում է անմիջապես մեքենաների վրա, հայտնվում են դրա օրինակները։ Դրանք նաև անվանվում են միանշանակ՝ որպես օրինակի համար և ծառայության անվանում. 1.ok-web.group1.web.front, 2.ok-web.group1.web.front,…

Սա շատ հարմար է՝ նայելով միայն հոսող տարայի անվանումը, մենք անմիջապես կարող ենք շատ բան պարզել։

Հիմա եկեք ավելի սերտ նայենք, թե իրականում ինչ են կատարում այս դեպքերը՝ առաջադրանքներ:

Առաջադրանքների մեկուսացման դասեր

OK-ի բոլոր առաջադրանքները (և, հավանաբար, ամենուր) կարելի է բաժանել խմբերի.

• Short Latency Tasks - արդ. Նման առաջադրանքների և ծառայությունների համար շատ կարևոր է պատասխանի հետաձգումը (լատենտությունը), թե որքան արագ է յուրաքանչյուր հարցումը մշակվելու համակարգի կողմից։ Առաջադրանքների օրինակներ՝ վեբ ճակատներ, քեշեր, հավելվածների սերվերներ, OLTP պահեստավորում և այլն:
• Հաշվարկման խնդիրներ - խմբաքանակ. Այստեղ յուրաքանչյուր կոնկրետ հարցման մշակման արագությունը կարևոր չէ։ Նրանց համար կարևոր է, թե որքան հաշվարկներ կանի այս առաջադրանքը որոշակի (երկար) ժամանակահատվածում (արտադրողականություն): Սրանք կլինեն MapReduce-ի, Hadoop-ի, մեքենայական ուսուցման, վիճակագրության ցանկացած առաջադրանք:
• Ֆոնային առաջադրանքներ՝ անգործուն. Նման առաջադրանքների համար ոչ ուշացումը, ոչ թողունակությունը շատ կարևոր չեն: Սա ներառում է տարբեր թեստեր, միգրացիաներ, վերահաշվարկներ և տվյալների փոխակերպում մի ձևաչափից մյուսը: Մի կողմից՝ դրանք նման են հաշվարկվածներին, մյուս կողմից՝ մեզ համար կարևոր չէ, թե որքան արագ են դրանք ավարտվում։

Տեսնենք, թե ինչպես են նման առաջադրանքները սպառում ռեսուրսները, օրինակ՝ կենտրոնական պրոցեսորը։

Կարճ հետաձգման առաջադրանքներ. Նման առաջադրանքը կունենա պրոցեսորի սպառման օրինաչափություն, որը նման է հետևյալին.

Օգտագործողի կողմից հարցում է ստացվում մշակման համար, առաջադրանքը սկսում է օգտագործել բոլոր հասանելի պրոցեսորային միջուկները, մշակում է այն, վերադարձնում է պատասխան, սպասում է հաջորդ հարցումին և կանգ է առնում: Հերթական հարցումը եկավ. մենք նորից ընտրեցինք այն ամենը, ինչ կար, հաշվարկեցինք և սպասում ենք հաջորդին։

Նման առաջադրանքի նվազագույն հետաձգումը երաշխավորելու համար մենք պետք է վերցնենք նրա սպառած առավելագույն ռեսուրսները և պահպանենք անհրաժեշտ քանակի միջուկներ minion-ի վրա (մեքենան, որը կկատարի առաջադրանքը): Այնուհետև մեր խնդրի ամրագրման բանաձևը կլինի հետևյալը.

alloc: cpu = 4 (max)

իսկ եթե մենք ունենք 16 միջուկ ունեցող մինիոն մեքենա, ապա դրա վրա կարելի է տեղադրել ուղիղ չորս այդպիսի առաջադրանք։ Մենք հատկապես նշում ենք, որ նման առաջադրանքների միջին պրոցեսորային սպառումը հաճախ շատ ցածր է, ինչը ակնհայտ է, քանի որ ժամանակի զգալի մասը առաջադրանքը սպասում է հարցմանը և ոչինչ չի անում:

Հաշվարկային առաջադրանքներ. Նրանց օրինաչափությունը մի փոքր տարբեր կլինի.

Նման առաջադրանքների համար պրոցեսորի ռեսուրսների միջին սպառումը բավականին բարձր է: Հաճախ մենք ցանկանում ենք, որ հաշվարկային առաջադրանքը կատարվի որոշակի ժամանակում, ուստի մենք պետք է պահպանենք անհրաժեշտ պրոցեսորների նվազագույն քանակը, որպեսզի ամբողջ հաշվարկն ավարտվի ընդունելի ժամանակում: Դրա ամրագրման բանաձևը կունենա հետևյալ տեսքը.

alloc: cpu = [1,*)

«Խնդրում եմ, դրեք այն մինիոնի վրա, որտեղ կա առնվազն մեկ ազատ միջուկ, և ինչքան շատ լինի, այն կխժռի ամեն ինչ»:

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

Բայց ինչպես դա անել:

Նախ, եկեք նայենք prod-ին և դրա հատկացմանը. cpu = 4: Մենք պետք է պահենք չորս միջուկ: Docker run-ում դա կարելի է անել երկու եղանակով.

• Օգտագործելով տարբերակը --cpuset=1-4, այսինքն՝ հատկացնել չորս հատուկ միջուկներ մեքենայի վրա առաջադրանքին:
• Օգտագործման համար --cpuquota=400_000 --cpuperiod=100_000, նշանակեք պրոցեսորի ժամանակի քվոտա, այսինքն՝ նշեք, որ յուրաքանչյուր 100 մվ իրական ժամանակում առաջադրանքը սպառում է ոչ ավելի, քան 400 մվ պրոցեսորի ժամանակ։ Ստացվում են նույն չորս միջուկները։

Բայց այս մեթոդներից որն է հարմար:

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

Եկեք պարզենք, թե ինչպես կարելի է ամրագրումներ կատարել Docker-ում միջուկների նվազագույն քանակի հիման վրա: Խմբային առաջադրանքների քվոտան այլևս կիրառելի չէ, քանի որ առավելագույնը սահմանափակելու կարիք չկա, բավական է միայն նվազագույնը երաշխավորել։ Եվ այստեղ տարբերակը լավ է տեղավորվում docker run --cpushares.

Մենք պայմանավորվեցինք, որ եթե խմբաքանակը պահանջում է երաշխիք առնվազն մեկ միջուկի համար, ապա մենք նշում ենք --cpushares=1024, և եթե կա առնվազն երկու միջուկ, ապա մենք նշում ենք --cpushares=2048. Cpu-ի բաժնետոմսերը ոչ մի կերպ չեն խանգարում պրոցեսորի ժամանակի բաշխմանը, քանի դեռ այն բավարար է: Այսպիսով, եթե prod-ը ներկայումս չի օգտագործում իր բոլոր չորս միջուկները, խմբաքանակի առաջադրանքները սահմանափակող ոչինչ չկա, և նրանք կարող են օգտագործել լրացուցիչ պրոցեսորի ժամանակ: Բայց մի իրավիճակում, երբ պրոցեսորների պակաս կա, եթե prod-ը սպառել է իր բոլոր չորս միջուկները և հասել է իր քվոտային, մնացած պրոցեսորի ժամանակը կբաժանվի համաչափ cpushare-ներին, այսինքն՝ երեք ազատ միջուկների իրավիճակում, մեկը կլինի: տրված է առաջադրանքի 1024 cpushare-ով, իսկ մնացած երկուսը տրվելու են 2048 cpushare-ով առաջադրանքին:

Բայց քվոտայի և բաժնետոմսերի օգտագործումը բավարար չէ։ Մենք պետք է համոզվենք, որ պրոցեսորի ժամանակ հատկացնելիս կարճ ուշացումով առաջադրանքն առաջնահերթություն է ստանում խմբաքանակային առաջադրանքից: Առանց նման առաջնահերթության, խմբաքանակի առաջադրանքը կզբաղեցնի պրոցեսորի ամբողջ ժամանակը այն պահին, երբ դա անհրաժեշտ կլինի արտադրողին: Docker գործարկման մեջ բեռնարկղերի առաջնահերթության ընտրանքներ չկան, սակայն Linux պրոցեսորի ժամանակացույցի քաղաքականությունը հարմար է: Դրանց մասին մանրամասն կարող եք կարդալ այստեղ, և այս հոդվածի շրջանակներում համառոտ կանցնենք դրանց.

• SCHED_OTHER
  Լռելյայնորեն, բոլոր սովորական օգտատիրոջ գործընթացները Linux մեքենայի վրա ստանում են:
• SCHED_BATCH
  Նախատեսված է ռեսուրսների ինտենսիվ գործընթացների համար: Պրոցեսորի վրա առաջադրանք դնելիս ներդրվում է այսպես կոչված ակտիվացման տույժ. նման առաջադրանքը պրոցեսորի ռեսուրսներ ստանալու ավելի քիչ հավանական է, եթե այն ներկայումս օգտագործվում է SCHED_OTHER-ի հետ առաջադրանքով:
• SCHED_IDLE
  Ֆոնային գործընթաց՝ շատ ցածր առաջնահերթությամբ, նույնիսկ ավելի ցածր, քան գեղեցիկ -19-ը: Մենք օգտագործում ենք մեր բաց կոդով գրադարանը մեկ-նիո, կոնտեյները զանգահարելով գործարկելիս անհրաժեշտ քաղաքականություն սահմանելու համար

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

Բայց նույնիսկ եթե դուք չեք ծրագրավորում Java-ում, նույնը կարելի է անել՝ օգտագործելով chrt հրամանը.

chrt -i 0 $pid

Պարզության համար եկեք ամփոփենք մեր մեկուսացման բոլոր մակարդակները մեկ աղյուսակում.

Մեկուսացման դաս
Բաշխել օրինակ
Docker գործարկման ընտրանքներ
sched_setscheduler chrt*

Գրգռել
պրոցեսոր = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

Կապոց
Cpu = [1, *)
--cpushares=1024
SCHED_BATCH

պարապ
Cpu= [2, *)
--cpushares=2048
SCHED_IDLE

*Եթե դուք chrt եք անում կոնտեյների ներսից, ձեզ կարող է անհրաժեշտ լինել sys_nice հնարավորությունը, քանի որ լռելյայնորեն Docker-ը հեռացնում է այս հնարավորությունը կոնտեյները գործարկելիս:

Բայց առաջադրանքները սպառում են ոչ միայն պրոցեսորը, այլև տրաֆիկը, որն ավելի շատ է ազդում ցանցային առաջադրանքի հետաձգման վրա, քան պրոցեսորի ռեսուրսների սխալ բաշխումը: Հետևաբար, մենք բնականաբար ցանկանում ենք ստանալ ճիշտ նույն պատկերը երթևեկության համար: Այսինքն, երբ պրոդային առաջադրանքը որոշ փաթեթներ է ուղարկում ցանց, մենք սահմանափակում ենք առավելագույն արագությունը (բանաձև հատկացում՝ lan=[*,500mbps) ), որի հետ արդյունահանումը կարող է դա անել: Իսկ խմբաքանակի համար մենք երաշխավորում ենք միայն նվազագույն թողունակությունը, բայց չենք սահմանափակում առավելագույնը (բանաձև հատկացում՝ lan=[10Mbps,*) ) Այս դեպքում արտադրանքի տրաֆիկը պետք է առաջնահերթություն ստանա խմբաքանակային առաջադրանքների նկատմամբ:
Այստեղ Docker-ը չունի պրիմիտիվներ, որոնք մենք կարող ենք օգտագործել: Բայց դա գալիս է մեզ օգնության Linux-ի տրաֆիկի վերահսկում. Կարգապահության օգնությամբ կարողացանք ցանկալի արդյունքի հասնել Հիերարխիկ արդար սպասարկման կոր. Նրա օգնությամբ մենք առանձնացնում ենք թրաֆիկի երկու դաս՝ բարձր առաջնահերթ արդյունահանում և ցածր առաջնահերթ խմբաքանակ/անգործություն: Արդյունքում, ելքային տրաֆիկի կոնֆիգուրացիան այսպիսին է.

այստեղ 1:0-ը hsfc կարգապահության «արմատային qdisc»-ն է. 1:1 - hsfc մանկական դաս 8 Գբիթ/վ ընդհանուր թողունակության սահմանաչափով, որի տակ տեղադրված են բոլոր կոնտեյներների մանկական դասերը. 1:2 - hsfc երեխայի դասը ընդհանուր է բոլոր խմբաքանակային և անգործուն առաջադրանքների համար՝ «դինամիկ» սահմանաչափով, որը քննարկվում է ստորև: Մնացած hsfc մանկական դասերը հատուկ դասեր են ներկայումս գործարկվող արդյունահանման կոնտեյներների համար, որոնց մանիֆեստներին համապատասխան սահմանաչափեր՝ 450 և 400 Մբիթ/վ: Յուրաքանչյուր hsfc դասի վերագրվում է qdisc հերթ fq կամ fq_codel՝ կախված Linux միջուկի տարբերակից՝ երթևեկության պայթյունների ժամանակ փաթեթների կորստից խուսափելու համար:

Սովորաբար, tc առարկաները ծառայում են առաջնահերթություն տալ միայն ելքային երթևեկությանը: Բայց մենք ցանկանում ենք նաև առաջնահերթություն տալ մուտքային երթևեկությանը. ի վերջո, որոշ խմբաքանակային առաջադրանքներ կարող են հեշտությամբ ընտրել ամբողջ մուտքային ալիքը՝ ստանալով, օրինակ, մուտքային տվյալների մեծ խմբաքանակ՝ քարտեզի և կրճատման համար: Դրա համար մենք օգտագործում ենք մոդուլը եթեբ, որը ստեղծում է ifbX վիրտուալ ինտերֆեյս յուրաքանչյուր ցանցային ինտերֆեյսի համար և վերահղում մուտքային տրաֆիկը միջերեսից դեպի ifbX-ի ելքային տրաֆիկ։ Ավելին, ifbX-ի համար բոլոր նույն առարկաները աշխատում են ելքային երթևեկությունը վերահսկելու համար, որի համար hsfc կոնֆիգուրացիան շատ նման կլինի.

Փորձերի ընթացքում մենք պարզեցինք, որ hsfc-ն ցույց է տալիս լավագույն արդյունքները, երբ 1:2 դասի ոչ առաջնահերթ խմբաքանակի/անգործուն երթևեկությունը սահմանափակվում է մինիոն մեքենաների վրա ոչ ավելի, քան որոշակի ազատ գոտի: Հակառակ դեպքում, ոչ առաջնահերթ երթևեկությունը չափազանց մեծ ազդեցություն ունի արդյունահանվող առաջադրանքների հետաձգման վրա: miniond-ը յուրաքանչյուր վայրկյան որոշում է ազատ թողունակության ընթացիկ քանակությունը՝ չափելով տրաֆիկի միջին սպառումը տվյալ minion-ի բոլոր պրոդ-առաջադրանքների համար: և այն հանելով ցանցային ինտերֆեյսի թողունակությունից փոքր մարժայով, այսինքն.

Շղթաները սահմանվում են ինքնուրույն՝ մուտքային և ելքային տրաֆիկի համար: Եվ ըստ նոր արժեքների, miniond-ը վերակազմավորում է ոչ առաջնահերթ դասի սահմանը 1:2:

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

Մեր բոլոր ընկերները Վեբ и երաժշտություն ապա ճակատները տեղադրվում են հիերարխիայում՝ արդ. Օրինակ, խմբաքանակի տակ, եկեք տեղադրենք ծառայությունը երաժշտական ​​կատալոգ, որը պարբերաբար կազմում է Odnoklassniki-ում վերբեռնված mp3 ֆայլերի հավաքածուից թրեքների կատալոգ: Անգործության տակ գտնվող ծառայության օրինակ կլինի երաժշտական ​​տրանսֆորմատոր, որը նորմալացնում է երաժշտության ձայնի մակարդակը։

Լրացուցիչ տողերը նորից հեռացնելով, մենք կարող ենք ավելի հարթ գրել մեր ծառայության անունները՝ ավելացնելով առաջադրանքի մեկուսացման դասը լրիվ ծառայության անվան վերջում. web.front.prod, catalog.music.batch, transformer.music.idle.

Եվ հիմա, նայելով ծառայության անվանումը, հասկանում ենք ոչ միայն այն, թե ինչ գործառույթ է այն կատարում, այլև դրա մեկուսացման դասը, ինչը նշանակում է դրա կրիտիկականությունը և այլն։

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

Ինչին հաջողվեց հասնել. եթե խմբաքանակն ինտենսիվ սպառում է միայն Պրոցեսորի ռեսուրսները, այնուհետև ներկառուցված Linux պրոցեսորի ժամանակացույցը շատ լավ է կատարում իր աշխատանքը, և գործնականում ոչ մի ազդեցություն չի թողնում պրոցեսորի առաջադրանքը: Բայց եթե այս խմբաքանակային առաջադրանքը սկսում է ակտիվորեն աշխատել հիշողության հետ, ապա փոխադարձ ազդեցությունն արդեն հայտնվում է։ Դա տեղի է ունենում այն ​​պատճառով, որ պրոցեսորի հիշողության քեշերից «լվանալ» է արդյունահանման առաջադրանքը. արդյունքում քեշի բացթողումները մեծանում են, և պրոցեսորն ավելի դանդաղ է մշակում պրոցեսորի առաջադրանքը: Նման խմբաքանակային առաջադրանքը կարող է 10%-ով մեծացնել մեր բնորոշ արտադրանքի կոնտեյների ուշացումը:

Երթևեկության մեկուսացումն էլ ավելի դժվար է այն պատճառով, որ ժամանակակից ցանցային քարտերն ունեն փաթեթների ներքին հերթ: Եթե ​​խմբաքանակի առաջադրանքից փաթեթը առաջինը հասնի այնտեղ, ապա այն կլինի առաջինը, որը կփոխանցվի մալուխի վրայով, և ոչինչ հնարավոր չէ անել դրա դեմ:

Բացի այդ, մեզ առայժմ հաջողվել է լուծել միայն TCP տրաֆիկի առաջնահերթության խնդիրը. hsfc մոտեցումը UDP-ի համար չի աշխատում: Եվ նույնիսկ TCP տրաֆիկի դեպքում, եթե խմբաքանակային առաջադրանքը առաջացնում է մեծ թրաֆիկ, սա նաև մոտ 10%-ով ավելացնում է արդյունահանման առաջադրանքի հետաձգումը:

սխալների հանդուրժողականություն

Մեկ ամպի մշակման նպատակներից մեկը Odnoklassniki-ի սխալների հանդուրժողականության բարելավումն էր: Հետևաբար, հաջորդիվ կցանկանայի ավելի մանրամասն դիտարկել ձախողումների և վթարների հնարավոր սցենարները: Սկսենք պարզ սցենարից՝ կոնտեյների ձախողում:

Բեռնարկղը ինքնին կարող է ձախողվել մի քանի ձևով. Սա կարող է լինել ինչ-որ փորձ, վրիպակ կամ մանիֆեստում սխալ, որի պատճառով prod առաջադրանքը սկսում է ավելի շատ ռեսուրսներ սպառել, քան նշված է մանիֆեստում: Մենք մի դեպք ունեինք. մի ծրագրավորող ներդրեց մեկ բարդ ալգորիթմ, այն բազմիցս վերամշակեց, մտածեց և այնքան շփոթվեց, որ ի վերջո խնդիրը լուծվեց շատ ոչ տրիվիալ ձևով: Եվ քանի որ արդյունահանման առաջադրանքն ավելի բարձր առաջնահերթություն ունի, քան բոլոր մյուսները նույն minions-ի վրա, այն սկսեց սպառել բոլոր հասանելի պրոցեսորային ռեսուրսները: Այս իրավիճակում մեկուսացումը, ավելի ճիշտ՝ պրոցեսորի ժամանակային քվոտան փրկեց օրը։ Եթե ​​առաջադրանքին քվոտա հատկացվի, առաջադրանքն ավելի շատ չի սպառի: Հետևաբար, խմբաքանակի և այլ արդյունահանման առաջադրանքները, որոնք աշխատում էին նույն մեքենայի վրա, ոչինչ չնկատեցին:

Երկրորդ հնարավոր խնդիրը տարայի ընկնելն է։ Եվ այստեղ վերագործարկման քաղաքականությունը փրկում է մեզ, բոլորը գիտեն դրանք, Docker-ն ինքը հիանալի աշխատանք է կատարում: Գրեթե բոլոր արտադրական առաջադրանքներն ունեն միշտ վերագործարկման քաղաքականություն: Երբեմն մենք օգտագործում ենք on_failure-ը խմբաքանակային առաջադրանքների կամ արդյունահանման բեռնարկղերի վրիպազերծման համար:

Ի՞նչ կարող եք անել, եթե մի ամբողջ մինիոն անհասանելի է:

Ակնհայտ է, որ բեռնարկղը գործարկեք մեկ այլ մեքենայի վրա: Հետաքրքիրն այստեղ այն է, թե ինչ է տեղի ունենում կոնտեյներին հատկացված IP հասցե(ների) հետ:

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

Ծառայության հայտնաբերումը հարմար է: Սպասարկման ռեեստրի կազմակերպման համար շուկայում առկա են տարբեր աստիճանի սխալների հանդուրժողականության բազմաթիվ լուծումներ: Հաճախ նման լուծումներն իրականացնում են բեռի հավասարակշռման տրամաբանություն, պահպանում են լրացուցիչ կոնֆիգուրացիան KV պահեստավորման տեսքով և այլն:
Այնուամենայնիվ, մենք կցանկանայինք խուսափել առանձին ռեեստրի ներդրման անհրաժեշտությունից, քանի որ դա կնշանակի ներմուծել կրիտիկական համակարգ, որն օգտագործվում է արտադրության բոլոր ծառայությունների կողմից: Սա նշանակում է, որ սա պոտենցիալ ձախողման կետ է, և դուք պետք է ընտրեք կամ մշակեք շատ սխալ հանդուրժող լուծում, որն ակնհայտորեն շատ դժվար է, ժամանակատար և թանկ:

Եվ ևս մեկ մեծ թերություն. որպեսզի մեր հին ենթակառուցվածքը աշխատի նորի հետ, մենք պետք է վերաշարադրենք բացարձակապես բոլոր առաջադրանքները՝ ծառայության հայտնաբերման ինչ-որ համակարգ օգտագործելու համար: Շատ աշխատանք կա, և որոշ տեղերում դա գրեթե անհնար է, երբ խոսքը վերաբերում է ցածր մակարդակի սարքերին, որոնք աշխատում են OS միջուկի մակարդակով կամ ուղղակիորեն սարքավորման հետ: Այս ֆունկցիոնալության իրականացումը` օգտագործելով լուծումների հաստատված օրինաչափությունները, ինչպիսիք են կողային մեքենա որոշ տեղերում կնշանակի լրացուցիչ ծանրաբեռնվածություն, որոշ տեղերում՝ շահագործման բարդացում և ձախողման լրացուցիչ սցենարներ։ Մենք չէինք ուզում բարդացնել ամեն ինչ, ուստի որոշեցինք Ծառայության հայտնաբերման օգտագործումը կամընտիր դարձնել:

Մեկ ամպում IP-ն հետևում է կոնտեյներին, այսինքն՝ առաջադրանքի յուրաքանչյուր օրինակ ունի իր IP հասցեն: Այս հասցեն «ստատիկ» է. այն նշանակվում է յուրաքանչյուր օրինակին, երբ ծառայությունն առաջին անգամ ուղարկվում է ամպ: Եթե ​​ծառայությունն իր կյանքի ընթացքում ունեցել է տարբեր թվով օրինակներ, ապա ի վերջո նրան կհատկացվի այնքան IP հասցե, որքան եղել են առավելագույն օրինակներ:

Հետագայում այդ հասցեները չեն փոխվում. դրանք նշանակվում են մեկ անգամ և շարունակում են գոյություն ունենալ արտադրության ծառայության ողջ կյանքի ընթացքում: IP հասցեները հետևում են բեռնարկղերին ամբողջ ցանցում: Եթե ​​բեռնարկղը փոխանցվի մեկ այլ մինիոնի, ապա հասցեն կհետևի դրան:

Այսպիսով, ծառայության անվան քարտեզագրումը IP հասցեների ցանկին շատ հազվադեպ է փոխվում: Եթե ​​նորից նայեք այն ծառայության օրինակների անուններին, որոնք մենք նշեցինք հոդվածի սկզբում (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), մենք կիմանանք, որ դրանք նման են DNS-ում օգտագործվող FQDN-ներին։ Ճիշտ է, ծառայության օրինակների անունները նրանց IP հասցեներին քարտեզագրելու համար մենք օգտագործում ենք DNS արձանագրությունը: Ավելին, այս DNS-ը վերադարձնում է բոլոր բեռնարկղերի բոլոր վերապահված IP հասցեները՝ և՛ գործարկվող, և՛ դադարեցված (ասենք, որ օգտագործվում են երեք կրկնօրինակներ, և մենք ունենք այնտեղ պահված հինգ հասցե. բոլոր հինգը կվերադարձվեն): Հաճախորդները, ստանալով այս տեղեկատվությունը, կփորձեն կապ հաստատել բոլոր հինգ կրկնօրինակների հետ և այդպիսով որոշել նրանց, որոնք աշխատում են: Հասանելիության որոշման այս տարբերակը շատ ավելի հուսալի է, այն չի ներառում ոչ DNS, ոչ էլ Ծառայության հայտնաբերում, ինչը նշանակում է, որ այդ համակարգերի արդիականությունը և սխալների հանդուրժողականությունը ապահովելու համար դժվար խնդիրներ չկան: Ավելին, կարևոր ծառայություններում, որոնցից կախված է ամբողջ պորտալի աշխատանքը, մենք ընդհանրապես չենք կարող օգտագործել DNS, այլ պարզապես կոնֆիգուրացիայի մեջ մուտքագրել IP հասցեներ:

Նման IP փոխանցման իրականացումը կոնտեյներների հետևում կարող է լինել աննշան, և մենք կնայենք, թե ինչպես է այն աշխատում հետևյալ օրինակով.

Ենթադրենք, մեկ ամպի վարպետը հրաման է տալիս minion M1-ին գործարկել 1.ok-web.group1.web.front.prod 1.1.1.1 հասցեով։ Աշխատում է մինիոնի վրա ԲԻՐԴ, որը գովազդում է այս հասցեն հատուկ սերվերներին երթուղու արտացոլիչ. Վերջիններս ունենում են BGP նիստ ցանցային ապարատով, որի մեջ թարգմանվում է M1.1.1.1-ի 1 հասցեի երթուղին։ M1-ն ուղղորդում է փաթեթները կոնտեյների ներսում՝ օգտագործելով Linux: Կան երեք երթուղային ռեֆլեկտոր սերվերներ, քանի որ սա մեկ ամպային ենթակառուցվածքի շատ կարևոր մասն է. առանց դրանց ցանցը մեկ ամպի մեջ չի աշխատի: Մենք դրանք տեղադրում ենք տարբեր դարակաշարերի մեջ, որոնք հնարավորության դեպքում տեղակայված են տվյալների կենտրոնի տարբեր սենյակներում, որպեսզի նվազեցնենք երեքի միաժամանակ ձախողման հավանականությունը:

Այժմ ենթադրենք, որ կապը մեկ ամպի վարպետի և M1 մինիոնի միջև կորել է։ Մեկ ամպի վարպետն այժմ կգործի այն ենթադրության հիման վրա, որ M1-ը լիովին ձախողվել է: Այսինքն՝ M2 minion-ին գործարկելու հրաման կտա web.group1.web.front.prod նույն հասցեով 1.1.1.1. Այժմ մենք ունենք երկու հակասական երթուղիներ ցանցում 1.1.1.1-ի համար՝ M1-ում և M2-ում: Նման հակամարտությունները լուծելու համար մենք օգտագործում ենք Multi Exit Discriminator-ը, որը նշված է BGP-ի հայտարարության մեջ: Սա թիվ է, որը ցույց է տալիս գովազդվող երթուղու կշիռը։ Հակասական երթուղիներից կընտրվի ավելի ցածր MED արժեքով երթուղին: Մեկ ամպի վարպետը աջակցում է MED-ին՝ որպես կոնտեյների IP հասցեների անբաժանելի մաս: Առաջին անգամ հասցեն գրվում է բավական մեծ MED = 1 Նման վթարային կոնտեյների փոխանցման իրավիճակում վարպետը նվազեցնում է MED-ը, և M000-ն արդեն կստանա 000 հասցեն MED = գովազդելու հրաման: 2 Մ1.1.1.1-ով աշխատող օրինակը կմնա այս դեպքում կապ չկա, և նրա հետագա ճակատագիրը մեզ քիչ է հետաքրքրում, քանի դեռ կապը վարպետի հետ չի վերականգնվել, երբ նա կկանգնեցվի ինչպես հին մեքենան:

Վթարներ

Տվյալների կենտրոնների կառավարման բոլոր համակարգերը միշտ ընդունելի կերպով են ընդունում աննշան ձախողումները: Բեռնարկղերի վարարումը նորմա է գրեթե ամենուր:

Եկեք նայենք, թե ինչպես ենք մենք վարվում արտակարգ իրավիճակների հետ, ինչպիսիք են տվյալների կենտրոնի մեկ կամ մի քանի սենյակներում հոսանքի խափանումը:

Ի՞նչ է նշանակում դժբախտ պատահար տվյալների կենտրոնի կառավարման համակարգի համար: Նախ, սա շատ մեքենաների զանգվածային միանվագ ձախողումն է, և կառավարման համակարգը պետք է միևնույն ժամանակ տեղափոխի բազմաթիվ բեռնարկղեր: Բայց եթե աղետը շատ լայնածավալ է, ապա կարող է պատահել, որ բոլոր առաջադրանքները չեն կարող վերաբաշխվել այլ մինիոնների վրա, քանի որ տվյալների կենտրոնի ռեսուրսների հզորությունը իջնում ​​է բեռի 100%-ից ցածր:

Հաճախ դժբախտ պատահարները ուղեկցվում են կառավարման շերտի ձախողմամբ: Դա կարող է տեղի ունենալ դրա սարքավորումների խափանման պատճառով, բայց ավելի հաճախ այն պատճառով, որ վթարները չեն փորձարկվում, և կառավարման շերտը ինքնին ընկնում է ավելացված բեռի պատճառով:

Ի՞նչ կարող ես անել այս ամենի հետ կապված:

Զանգվածային միգրացիաները նշանակում են, որ ենթակառուցվածքներում տեղի են ունենում մեծ թվով գործողություններ, միգրացիաներ և տեղակայումներ: Միգրացիայից յուրաքանչյուրը կարող է որոշակի ժամանակ պահանջել՝ բեռնարկղերի պատկերները մինիոններին առաքելու և բացելու, կոնտեյներների գործարկման և սկզբնավորման համար և այլն: Հետևաբար, ցանկալի է, որ ավելի կարևոր առաջադրանքները գործարկվեն ավելի քիչ կարևոր առաջադրանքներից առաջ:

Եկեք նորից նայենք մեզ ծանոթ ծառայությունների հիերարխիային և փորձենք որոշել, թե որ առաջադրանքն ենք ուզում առաջինը կատարել:

Իհարկե, սրանք այն գործընթացներն են, որոնք անմիջականորեն ներգրավված են օգտվողների հարցումների մշակման մեջ, այսինքն. Մենք դա նշում ենք տեղաբաշխման առաջնահերթությունը — թիվ, որը կարող է վերագրվել հերթին: Եթե ​​հերթն ավելի բարձր առաջնահերթություն ունի, ապա դրա ծառայությունները տեղադրվում են առաջինը:

Արտադրանքի վրա մենք ավելի բարձր առաջնահերթություններ ենք նշանակում՝ 0; խմբաքանակի վրա - մի փոքր ավելի ցածր, 100; անգործության վրա՝ նույնիսկ ավելի ցածր՝ 200։ Առաջնահերթությունները կիրառվում են հիերարխիկորեն։ Հիերարխիայում ցածր բոլոր առաջադրանքները կունենան համապատասխան առաջնահերթություն։ Եթե ​​մենք ցանկանում ենք, որ արդյունահանման ներսում գտնվող քեշերը գործարկվեն առջևից առաջ, ապա մենք առաջնահերթությունները վերագրում ենք քեշին = 0 և առջևի ենթահերթերին = 1: Եթե, օրինակ, ցանկանում ենք, որ հիմնական պորտալը գործարկվի առաջին առջևից, և միայն երաժշտական ​​ճակատը: ապա, ապա վերջինիս կարող ենք ավելի ցածր առաջնահերթություն տալ՝ 10։

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

Ի տարբերություն տեղաբաշխման առաջնահերթության, մենք չենք կարող անխտիր զոհաբերել բոլոր խմբաքանակային առաջադրանքները, որոնք կարևոր են պորտալի շահագործման համար: Հետեւաբար, մենք առանձնացրել ենք առանձին կանխարգելման առաջնահերթություն առաջադրանքներ. Երբ տեղադրվում է, ավելի բարձր առաջնահերթ առաջադրանքը կարող է կանխարգելել, այսինքն՝ դադարեցնել, ավելի ցածր առաջնահերթ առաջադրանքը, եթե այլևս ազատ մինիոններ չկան: Այս դեպքում ցածր առաջնահերթություն ունեցող առաջադրանքը հավանաբար կմնա անտեղի, այսինքն՝ դրա համար այլևս չի լինի համապատասխան մինիոն՝ բավականաչափ ազատ ռեսուրսներով:

Մեր հիերարխիայում շատ պարզ է նախապատվության առաջնահերթություն նշելը, այնպես որ արդյունահանման և խմբաքանակի առաջադրանքները կանխում կամ դադարեցնում են անգործուն առաջադրանքները, բայց ոչ միմյանց՝ նշելով 200-ի պարապության համար առաջնահերթություն: Ճիշտ ինչպես տեղաբաշխման առաջնահերթության դեպքում, մենք կարող է օգտագործել մեր հիերարխիան՝ ավելի բարդ կանոններ նկարագրելու համար: Օրինակ՝ նշենք, որ մենք զոհաբերում ենք երաժշտության ֆունկցիան, եթե չունենք բավարար ռեսուրսներ հիմնական վեբ պորտալի համար՝ համապատասխան հանգույցների առաջնահերթությունը սահմանելով ավելի ցածր՝ 10։

Ամբողջական DC վթարներ

Ինչու՞ կարող է ամբողջ տվյալների կենտրոնը ձախողվել: Տարր. Լավ գրառում էր փոթորիկը ազդել է տվյալների կենտրոնի աշխատանքի վրա. Տարերքները կարելի է համարել անօթևան մարդիկ, ովքեր ժամանակին այրել են օպտիկան բազմազանության մեջ, և տվյալների կենտրոնն ամբողջությամբ կորցրել է կապը այլ կայքերի հետ։ Խափանման պատճառը կարող է լինել նաև մարդկային գործոնը՝ օպերատորը այնպիսի հրաման կտա, որ ամբողջ տվյալների կենտրոնը կընկնի։ Դա կարող է տեղի ունենալ մեծ սխալի պատճառով: Ընդհանուր առմամբ, տվյալների կենտրոնների փլուզումը հազվադեպ չէ: Սա մեզ հետ տեղի է ունենում ամիսը մեկ անգամ:

Եվ սա այն է, ինչ մենք անում ենք, որպեսզի որևէ մեկը չթվիթերի #կենդանի:

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

Այս մոտեցումը ոչ միայն պաշտպանում է ֆիզիկական ձախողումից, այլ նաև կարող է պաշտպանել օպերատորի սխալներից:

Էլ ի՞նչ կարելի է անել մարդկային գործոնի հետ։ Երբ օպերատորը ամպին ինչ-որ տարօրինակ կամ պոտենցիալ վտանգավոր հրաման է տալիս, նրան կարող են հանկարծ խնդրել լուծել մի փոքր խնդիր՝ տեսնելու, թե որքան լավ է նա մտածել: Օրինակ, եթե սա շատ կրկնօրինակների զանգվածային կանգառ է կամ պարզապես տարօրինակ հրաման է՝ կրճատել կրկնօրինակների թիվը կամ փոխել պատկերի անունը, և ոչ միայն նոր մանիֆեստում տարբերակի համարը:

Արդյունքները

Մեկ ամպի տարբերակիչ առանձնահատկությունները.

• Ծառայությունների և բեռնարկղերի անվանման հիերարխիկ և տեսողական սխեման, որը թույլ է տալիս շատ արագ պարզել, թե որն է առաջադրանքը, ինչի հետ է այն վերաբերում և ինչպես է այն աշխատում և ով է պատասխանատու դրա համար։
• Մենք դիմում ենք մեր արտադրանքի և խմբաքանակի համադրման տեխնիկաառաջադրանքներ մինիոնների վրա՝ բարելավելու մեքենաների փոխանակման արդյունավետությունը: Cpuset-ի փոխարեն մենք օգտագործում ենք պրոցեսորի քվոտաներ, բաժնետոմսեր, պրոցեսորի ժամանակացույցի քաղաքականություն և Linux QoS:
• Հնարավոր չի եղել ամբողջությամբ մեկուսացնել նույն մեքենայի վրա աշխատող բեռնարկղերը, սակայն դրանց փոխադարձ ազդեցությունը մնում է 20%-ի սահմաններում։
• Ծառայությունների կազմակերպումը հիերարխիայի մեջ օգնում է աղետից ավտոմատ վերականգնումը՝ օգտագործելով տեղաբաշխման և կանխարգելման առաջնահերթությունները.

ՀՏՀ

Ինչո՞ւ պատրաստի լուծում չընդունեցինք։

• Առաջադրանքների մեկուսացման տարբեր դասեր պահանջում են տարբեր տրամաբանություն, երբ տեղադրվում են մինիոնների վրա: Եթե ​​արդյունահանման առաջադրանքները կարող են տեղադրվել պարզապես ռեսուրսներ վերապահելով, ապա խմբաքանակային և անգործուն առաջադրանքները պետք է տեղադրվեն՝ հետևելով ռեսուրսների իրական օգտագործմանը minion մեքենաների վրա:
• Առաջադրանքների կողմից սպառվող ռեսուրսները հաշվի առնելու անհրաժեշտությունը, ինչպիսիք են.
  • ցանցի թողունակություն;
  • սկավառակների տեսակները և «spindles»:
• Արտակարգ իրավիճակների արձագանքման ժամանակ ծառայությունների առաջնահերթությունները, ռեսուրսների համար հրամանների իրավունքներն ու քվոտաները նշելու անհրաժեշտությունը, որը լուծվում է մեկ ամպում հիերարխիկ հերթերի միջոցով:
• Դժբախտ պատահարներին և միջադեպերին արձագանքելու ժամանակը նվազեցնելու համար բեռնարկղերի մարդկային անվանումների անհրաժեշտությունը
• Ծառայությունների բացահայտման մեկանգամյա համատարած իրականացման անհնարինությունը. Երկար ժամանակ գոյակցելու անհրաժեշտությունը ապարատային հոսթերի վրա տեղակայված առաջադրանքների հետ. մի բան, որը լուծվում է կոնտեյներների հետևող «ստատիկ» IP հասցեներով, և, որպես հետևանք, ցանցային մեծ ենթակառուցվածքի հետ եզակի ինտեգրման անհրաժեշտություն:

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

Վերջին տողերը կարդացողներին, շնորհակալություն համբերության և ուշադրության համար:

Source: www.habr.com