Հե՜յ Հաբր։ Ձեր ուշադրությանն եմ ներկայացնում հոդվածի թարգմանությունը Ադիբ Դավի կողմից:
Եթե այդ վերնագիրը մի փոքր դող չի առաջացնում ձեր ողնաշարի մեջ, դուք պետք է անցնեք հաջորդ պարբերությանը կամ այցելեք մեր էջը, որը նվիրված է դրան. -Մենք կցանկանայինք խոսել։
ով ենք մենք
Մենք 4 պինգվիններից բաղկացած թիմ ենք, ովքեր սիրում են կոդ գրել և աշխատել սարքավորումների հետ: Մեր ազատ ժամանակում մենք պատասխանատու ենք Linux-ով աշխատող ավելի քան 7000 ֆիզիկական սերվերների նավատորմի տեղակայման, պահպանման և շահագործման համար, որոնք բաշխված են 3 տարբեր տվյալների կենտրոններում Միացյալ Նահանգներում:
Մենք նաև հնարավորություն ունեինք դա անել 10 կմ հեռավորության վրա գտնվող վայրերից, մեր սեփական գրասենյակի հարմարավետությունից, որը գտնվում է Միջերկրական ծովի լողափից կարճ ճանապարհով:
Մասշտաբի խնդիրներ
Թեև իմաստ ունի, որ ստարտափը սկսի իր ենթակառուցվածքը ամպում հյուրընկալելով՝ համեմատաբար ցածր նախնական ներդրումների պատճառով, մենք Outbrain-ում որոշեցինք օգտագործել մեր սեփական սերվերները: Մենք դա արեցինք, քանի որ ամպային ենթակառուցվածքի ծախսերը որոշակի մակարդակով գերազանցում են տվյալների կենտրոններում տեղակայված մեր սեփական սարքավորումների շահագործման ծախսերը: Բացի այդ, ձեր սերվերն ապահովում է վերահսկման և անսարքությունների վերացման ամենաբարձր մակարդակը:
Քանի որ մենք զարգանում ենք, խնդիրները միշտ մոտ են: Ավելին, նրանք սովորաբար գալիս են խմբերով։ Սերվերի կյանքի ցիկլի կառավարումը պահանջում է մշտական ինքնակատարելագործում, որպեսզի կարողանա պատշաճ կերպով գործել սերվերների քանակի արագ աճի համատեքստում: Տվյալների կենտրոններում սերվերային խմբերը կառավարելու ծրագրային մեթոդներն արագ դառնում են անգործունակ: QoS ստանդարտներին համապատասխանող ձախողումները հայտնաբերելը, անսարքությունները վերացնելը և մեղմելը դառնում է սարքավորումների չափազանց բազմազան զանգվածների, տարբեր աշխատանքային ծանրաբեռնվածությունների, արդիականացման վերջնաժամկետների և այլ լավ բաների խնդիր, որոնց մասին ոչ ոք չի ուզում անհանգստանալ:
Վարպետեք ձեր տիրույթները
Այս խնդիրներից շատերը լուծելու համար մենք Outbrain-ում սերվերի կյանքի ցիկլը բաժանեցինք նրա հիմնական բաղադրիչների և դրանք անվանեցինք տիրույթներ: Օրինակ՝ մի տիրույթն ընդգրկում է սարքավորումների պահանջները, մյուսը՝ լոգիստիկա՝ կապված գույքագրման կյանքի ցիկլի հետ, իսկ երրորդը՝ դաշտային անձնակազմի հետ հաղորդակցությունը: Կա ևս մեկը, որը վերաբերում է ապարատային դիտարկելիությանը, բայց մենք չենք նկարագրի բոլոր կետերը: Մեր նպատակն էր ուսումնասիրել և սահմանել տիրույթներ, որպեսզի դրանք վերացվեն կոդով: Աշխատանքային աբստրակցիան մշակվելուց հետո այն փոխանցվում է ձեռքով գործընթացի, որը տեղակայվում, փորձարկվում և ճշգրտվում է: Վերջապես, տիրույթը կազմաձևված է այլ տիրույթների հետ API-ների միջոցով ինտեգրվելու համար՝ ձևավորելով ամբողջական, դինամիկ և անընդհատ զարգացող ապարատային կյանքի ցիկլի համակարգ, որը կարող է տեղակայվել, փորձարկվել և դիտարկելի։ Ինչպես մեր բոլոր արտադրական համակարգերը:
Այս մոտեցման ընդունումը թույլ տվեց մեզ ճիշտ լուծել բազմաթիվ խնդիրներ՝ ստեղծելով գործիքներ և ավտոմատացում։
Անհրաժեշտ է տիրույթ
Թեև էլեկտրոնային փոստը և աղյուսակները վաղ օրերին պահանջարկը բավարարելու կենսունակ միջոց էին, դա հաջող լուծում չէր, հատկապես, երբ սերվերների քանակը և մուտքային հարցումների ծավալը հասնում էին որոշակի մակարդակի: Արագ ընդլայնման պայմաններում մուտքային հարցումներն ավելի լավ կազմակերպելու և առաջնահերթություն տալու համար մենք ստիպված էինք օգտագործել տոմսերի վաճառքի համակարգ, որը կարող էր առաջարկել.
- Միայն համապատասխան դաշտերի տեսքը հարմարեցնելու ունակություն (պարզ)
- Բաց API-ներ (ընդլայնելի)
- Հայտնի է մեր թիմին (հասկանալի է)
- Ինտեգրում մեր առկա աշխատանքային հոսքերին (միասնական)
Քանի որ մենք օգտագործում ենք Jira-ն մեր սպրինտները և ներքին առաջադրանքները կառավարելու համար, մենք որոշեցինք ստեղծել մեկ այլ նախագիծ, որը կօգնի մեր հաճախորդներին ներկայացնել տոմսեր և հետևել դրանց արդյունքներին: Jira-ի օգտագործումը մուտքային հարցումների և ներքին առաջադրանքների կառավարման համար մեզ թույլ տվեց ստեղծել մեկ Kanban տախտակ, որը թույլ էր տալիս մեզ դիտել բոլոր գործընթացները որպես ամբողջություն: Մեր ներքին «հաճախորդները» տեսան միայն սարքավորումների հարցումներ՝ չխորանալով լրացուցիչ առաջադրանքների պակաս կարևոր մանրամասների մեջ (օրինակ՝ գործիքների կատարելագործում, սխալների շտկում):
Kanban տախտակ Ժիրայում
Որպես բոնուս, այն փաստը, որ հերթերն ու առաջնահերթությունները այժմ տեսանելի էին բոլորի համար, հնարավորություն տվեց հասկանալ, թե «հերթում որտեղ է» կոնկրետ հարցումը և ինչն է դրան նախորդել: Սա թույլ է տվել սեփականատերերին վերահաստատել իրենց հարցումները՝ առանց մեզ հետ կապվելու: Քաշեք այն և վերջ: Այն նաև թույլ տվեց մեզ վերահսկել և գնահատել մեր SLA-ները՝ ըստ հարցումների տեսակների, որոնք հիմնված են Jira-ում ստեղծված չափումների վրա:
Սարքավորումների կյանքի ցիկլի տիրույթ
Փորձեք պատկերացնել յուրաքանչյուր սերվերի դարակում օգտագործվող սարքաշարի կառավարման բարդությունը: Ավելի վատն այն է, որ ապարատային շատ կտորներ (RAM, ROM) կարող են պահեստից տեղափոխվել սերվերի սենյակ և ետ: Դրանք նույնպես ձախողվում են կամ դուրս են գրվում և փոխարինվում և վերադարձվում մատակարարին փոխարինման/վերանորոգման համար: Այս ամենը պետք է տեղեկացվի սարքավորումների ֆիզիկական սպասարկման մեջ ներգրավված տեղակայման ծառայության աշխատակիցներին: Այս խնդիրները լուծելու համար մենք ստեղծեցինք ներքին գործիք, որը կոչվում է Floppy: Նրա խնդիրն է.
- Դաշտային անձնակազմի հետ հաղորդակցության կառավարում, ամբողջ տեղեկատվության համախմբում;
- «Պահեստի» տվյալների թարմացում յուրաքանչյուր ավարտված և ստուգված սարքավորումների սպասարկման աշխատանքից հետո:
Պահեստն իր հերթին վիզուալիզացվում է Grafana-ի միջոցով, որը մենք օգտագործում ենք մեր բոլոր ցուցանիշները գծագրելու համար: Այսպիսով, մենք օգտագործում ենք նույն գործիքը պահեստի վիզուալիզացիայի և արտադրության այլ կարիքների համար:
Պահեստային սարքավորումների կառավարման վահանակ Գրաֆանայում
Սերվերային սարքերի համար, որոնք երաշխիքի տակ են, մենք օգտագործում ենք մեկ այլ գործիք, որը կոչվում է «Դիսպետչեր»: Նա.
- Հավաքում է համակարգի տեղեկամատյանները;
- Ստեղծում է հաշվետվություններ վաճառողի կողմից պահանջվող ձևաչափով.
- Ստեղծում է հարցում վաճառողից API-ի միջոցով.
- Ստանում և պահում է հավելվածի նույնացուցիչը՝ դրա առաջընթացին հետագա հետևելու համար:
Երբ մեր հայցն ընդունվում է (սովորաբար աշխատանքային ժամերի ընթացքում), պահեստամասն ուղարկվում է համապատասխան տվյալների կենտրոն և ընդունվում անձնակազմի կողմից:
Jenkins կոնսոլի ելք
Հաղորդակցման տիրույթ
Մեր բիզնեսի արագ աճին հետևելու համար, որը պահանջում է անընդհատ աճող կարողություններ, մենք ստիպված էինք հարմարեցնել տեղական տվյալների կենտրոնների տեխնիկական մասնագետների հետ աշխատելու ձևը: Եթե սկզբում մեծացումը նշանակում էր գնել նոր սերվերներ, ապա համախմբման նախագծից հետո (հիմնված Kubernetes-ին անցնելու վրա) այն դարձավ բոլորովին այլ բան: Մեր էվոլյուցիան «դարակաշարերի ավելացումից» մինչև «սերվերների վերաբաշխում»:
Նոր մոտեցման կիրառումը պահանջում էր նաև նոր գործիքներ, որոնք հնարավորություն տվեցին ավելի հարմարավետ փոխգործակցել տվյալների կենտրոնի անձնակազմի հետ: Այս գործիքները պահանջվում էին.
- Պարզություն;
- Ինքնավարություն;
- Արդյունավետություն;
- Հուսալիություն
Մենք պետք է մեզ դուրս գայինք շղթայից և կառուցեցինք աշխատանքը այնպես, որ տեխնիկները կարողանան ուղղակիորեն աշխատել սերվերային սարքավորումների հետ: Առանց մեր միջամտության և առանց կանոնավոր կերպով բարձրաձայնելու այս բոլոր խնդիրները՝ կապված աշխատանքային ծանրաբեռնվածության, աշխատանքային ժամերի, սարքավորումների առկայության և այլնի հետ:
Դրան հասնելու համար մենք iPad-ներ տեղադրեցինք տվյալների յուրաքանչյուր կենտրոնում: Սերվերին միանալուց հետո տեղի կունենա հետևյալը.
- Սարքը հաստատում է, որ այս սերվերն իսկապես պահանջում է որոշակի աշխատանք.
- Սերվերում աշխատող հավելվածները փակ են (անհրաժեշտության դեպքում);
- Աշխատանքային հրահանգների մի շարք տեղադրվում է Slack ալիքում՝ բացատրելով պահանջվող քայլերը.
- Աշխատանքի ավարտից հետո սարքը ստուգում է սերվերի վերջնական վիճակի ճշգրտությունը.
- Անհրաժեշտության դեպքում վերագործարկում է հավելվածները:
Բացի այդ, մենք պատրաստել ենք նաև Slack բոտ՝ տեխնիկին օգնելու համար: Հնարավորությունների լայն շրջանակի շնորհիվ (մենք անընդհատ ընդլայնում էինք ֆունկցիոնալությունը), բոտը հեշտացրեց նրանց աշխատանքը և շատ ավելի հեշտացրեց մեր կյանքը: Այս կերպ մենք օպտիմիզացրել ենք սերվերների վերագործարկման և պահպանման գործընթացի մեծ մասը՝ ինքներս մեզ հեռացնելով աշխատանքային հոսքից:
iPad մեր տվյալների կենտրոններից մեկում
Սարքավորման տիրույթ
Մեր տվյալների կենտրոնի ենթակառուցվածքի հուսալի մասշտաբը պահանջում է լավ տեսանելիություն յուրաքանչյուր բաղադրիչի մեջ, օրինակ՝
- Սարքավորումների ձախողման հայտնաբերում
- Սերվերի վիճակները (ակտիվ, հոսթինգ, զոմբի և այլն)
- Էլեկտրաէներգիայի սպառումը
- Որոնվածի տարբերակը
- Վերլուծություն այս ամբողջ բիզնեսի համար
Մեր լուծումները թույլ են տալիս մեզ որոշումներ կայացնել այն մասին, թե ինչպես, որտեղ և երբ գնել սարքավորումներ, երբեմն նույնիսկ նախքան դրա իրական անհրաժեշտությունը: Բացի այդ, որոշելով տարբեր սարքավորումների բեռնվածության մակարդակը, մենք կարողացանք հասնել ռեսուրսների բարելավված բաշխման: Մասնավորապես, էներգիայի սպառումը. Այժմ մենք կարող ենք տեղեկացված որոշումներ կայացնել սերվերի տեղադրման վերաբերյալ՝ նախքան այն տեղադրվելը դարակաշարում և միացված լինել էներգիայի աղբյուրին, դրա ողջ կյանքի ցիկլի ընթացքում և մինչև վերջնական թոշակի անցնելը:
Էներգետիկ վահանակ Գրաֆանայում
Եվ հետո հայտնվեց COVID-19-ը...
Մեր թիմը ստեղծում է տեխնոլոգիաներ, որոնք հնարավորություն են տալիս մեդիա ընկերություններին և հրատարակիչներին առցանց՝ օգնելու այցելուներին գտնել համապատասխան բովանդակություն, ապրանքներ և ծառայություններ, որոնք կարող են հետաքրքրել իրենց: Մեր ենթակառուցվածքը նախագծված է սպասարկելու թրաֆիկը, որը առաջանում է, երբ հրապարակվում են որոշ հետաքրքիր նորություններ:
COVID-19-ի շուրջ ԶԼՄ-ների ինտենսիվ լուսաբանումը, զուգորդված երթևեկության աճի հետ, նշանակում էր, որ մենք շտապ պետք է սովորեինք, թե ինչպես հաղթահարել այդ ճնշումները: Ավելին, այս ամենը պետք է արվեր համաշխարհային ճգնաժամի ժամանակ, երբ մատակարարման շղթաները խաթարված էին, իսկ անձնակազմի մեծ մասը տանը էր։
Բայց, ինչպես ասացինք, մեր մոդելն արդեն ենթադրում է, որ.
- Մեր տվյալների կենտրոնների սարքավորումները, մեծ մասամբ, ֆիզիկապես անհասանելի են մեզ համար.
- Մենք գրեթե բոլոր ֆիզիկական աշխատանքները կատարում ենք հեռակա կարգով.
- Աշխատանքը կատարվում է ասինխրոն, ինքնավար և մեծ մասշտաբով.
- Մենք բավարարում ենք սարքավորումների պահանջարկը նոր սարքավորումներ ձեռք բերելու փոխարեն «կառուցել մասերից» մեթոդով.
- Մենք ունենք պահեստ, որը թույլ է տալիս ստեղծել նոր բան, այլ ոչ թե սովորական վերանորոգումներ իրականացնել:
Այսպիսով, գլոբալ սահմանափակումները, որոնք թույլ չտվեցին բազմաթիվ ընկերությունների ֆիզիկական մուտք ունենալ իրենց տվյալների կենտրոններ, քիչ ազդեցություն ունեցան մեզ վրա, իսկ պահեստամասերի և սերվերների մասով, այո, մենք փորձեցինք ապահովել սարքավորումների կայուն աշխատանքը: Բայց դա արվել է հնարավոր միջադեպերը կանխելու նպատակով, երբ հանկարծ պարզվում է, որ ինչ-որ սարքավորում չկա։ Մենք ապահովել ենք, որ մեր պահուստները լրացվեն՝ չնպատակ ունենալով բավարարել ընթացիկ պահանջարկը։
Ամփոփելով, ես կցանկանայի ասել, որ տվյալների կենտրոնների արդյունաբերության մեջ աշխատելու մեր մոտեցումը ապացուցում է, որ հնարավոր է կիրառել լավ կոդի ձևավորման սկզբունքները տվյալների կենտրոնի ֆիզիկական կառավարման համար: Եվ միգուցե ձեզ հետաքրքիր կլինի:
Բնագիր `
Source: www.habr.com