Veiksmingas ir patikimas bet kokio masto klasterių valdymas naudojant Tupperware
Šiandien toliau pristatėme Tupperware, mūsų klasterių valdymo sistemą, kuri surenka konteinerius milijonuose serverių, kuriuose veikia beveik visos mūsų paslaugos. Pirmą kartą „Tupperware“ įdiegėme 2011 m., o nuo to laiko mūsų infrastruktūra išaugo į visą . Visą šį laiką Tupperware nestovėjo vietoje ir vystėsi kartu su mumis. Parodysime, kaip „Tupperware“ teikia aukščiausios klasės klasterių valdymą, įskaitant patogų būsenos paslaugų palaikymą, vieną valdymo skydelį visiems duomenų centrams ir galimybę paskirstyti pajėgumus tarp paslaugų realiuoju laiku. Taip pat pasidalinsime pamokomis, kurias išmokome vystantis mūsų infrastruktūrai.
Tupperware atlieka įvairias užduotis. Programų kūrėjai ją naudoja programoms pristatyti ir valdyti. Jis supakuoja programos kodą ir priklausomybes į vaizdą ir pateikia jį serveriams kaip konteinerius. Konteineriai suteikia atskirų programų tame pačiame serveryje, kad kūrėjai susidorotų su programų logika ir jiems nereikėtų jaudintis ieškant serverių ar tvarkant naujinimus. Tupperware taip pat stebi serverio veikimą, o jei nustato gedimą, perkelia konteinerius iš probleminio serverio.
Pajėgumų planavimo inžinieriai naudoja Tupperware, kad paskirstytų serverio pajėgumus komandoms pagal biudžetą ir apribojimus. Jie taip pat naudoja jį norėdami pagerinti serverio naudojimą. Duomenų centrų operatoriai kreipiasi į Tupperware, kad galėtų tinkamai paskirstyti konteinerius duomenų centruose ir sustabdyti arba perkelti konteinerius priežiūros metu. Dėl šios priežasties serverių, tinklų ir įrangos priežiūra reikalauja minimalaus žmogaus įsikišimo.
Tupperware architektūra
Tupperware PRN architektūra yra vienas iš mūsų duomenų centrų regionų. Regioną sudaro keli netoliese esantys duomenų centrų pastatai (PRN1 ir PRN2). Planuojame padaryti vieną valdymo pultą, kuris valdys visus serverius viename regione.
Programų kūrėjai teikia paslaugas Tupperware užduočių forma. Užduotį sudaro keli konteineriai ir jie visi paprastai vykdo tą patį programos kodą.
„Tupperware“ yra atsakinga už konteinerių aprūpinimą ir jų gyvavimo ciklo valdymą. Jį sudaro keli komponentai:
- „Tupperware“ sąsaja teikia vartotojo sąsajos API, CLI ir kitus automatizavimo įrankius, kuriais galite bendrauti su „Tupperware“. Jie slepia visą vidinę struktūrą nuo Tupperware darbų savininkų.
- „Tupperware Scheduler“ yra valdymo skydelis, atsakingas už konteinerio ir darbo ciklo valdymą. Jis įdiegtas regioniniu ir pasauliniu lygiu, kai regioninis planuoklis valdo serverius viename regione, o pasaulinis planuoklis valdo serverius iš skirtingų regionų. Planuoklis yra padalintas į šukes, o kiekviena skeveldra valdo užduočių rinkinį.
- „Tupperware“ planavimo tarpinis serveris paslepia vidinį skilimą ir suteikia patogią vieną stiklo plokštę „Tupperware“ naudotojams.
- Tupperware skirstytuvas priskiria konteinerius serveriams. Planavimo priemonė tvarko konteinerių stabdymą, paleidimą, atnaujinimą ir failų perkėlimą. Šiuo metu vienas skirstytuvas gali valdyti visą regioną, neskirstydamas į šukes. (Atkreipkite dėmesį į terminų skirtumus. Pavyzdžiui, Tupperware planavimo priemonė atitinka valdymo skydelį , o Tupperware skirstytuvas Kubernetes vadinamas planuotoju.)
- Išteklių brokeris saugo serverio ir paslaugų įvykių tiesos šaltinį. Kiekvienam duomenų centrui vadovaujame po vieną išteklių tarpininką, kuris saugo visą informaciją apie tame duomenų centre esančius serverius. Išteklių tarpininkas ir pajėgumų valdymo sistema arba išteklių aprūpinimo sistema dinamiškai nusprendžia, kuris planuotojas valdo kurį serverį. Sveikatos patikrinimo paslauga stebi serverius ir saugo duomenis apie jų būklę išteklių brokeryje. Jei serveryje kyla problemų arba reikia priežiūros, išteklių tarpininkas nurodo skirstytuvui ir planuokliui sustabdyti konteinerius arba perkelti juos į kitus serverius.
- „Tupperware Agent“ yra demonas, veikiantis kiekviename serveryje, kuris tvarko konteinerių aprūpinimą ir pašalinimą. Programos veikia konteineryje, todėl jos yra labiau izoliuotos ir atkuriamos. Įjungta Jau aprašėme, kaip atskiri Tupperware konteineriai sukuriami naudojant vaizdus, btrfs, cgroupv2 ir systemd.
Išskirtinės Tupperware savybės
„Tupperware“ daugeliu atžvilgių yra panaši į kitas klasterių valdymo sistemas, tokias kaip „Kubernetes“ ir , tačiau yra ir skirtumų:
- Integruotas palaikymas valstybinėms paslaugoms.
- Vienas valdymo pultas skirtinguose duomenų centruose esantiems serveriams, skirtas automatizuoti konteinerių pristatymą pagal paskirtį, klasterių eksploatavimo nutraukimą ir priežiūrą.
- Aiškus valdymo skydelio padalijimas priartinimui.
- Elastingas skaičiavimas leidžia paskirstyti galią tarp paslaugų realiuoju laiku.
Sukūrėme šias puikias funkcijas, kad palaikytume įvairias be būsenos ir būsenos programas didžiuliame pasauliniame bendrame serverių parke.
Integruotas palaikymas valstybinėms paslaugoms.
„Tupperware“ teikia įvairias svarbias būsenos paslaugas, kuriose saugomi nuolatiniai „Facebook“, „Instagram“, „Messenger“ ir „WhatsApp“ produktų duomenys. Tai gali būti didelės raktų ir verčių porų parduotuvės (pvz., ) ir stebėjimo duomenų saugyklos (pvz., и ). Išlaikyti valstybines paslaugas nėra lengva, nes sistema turi užtikrinti, kad konteinerių tiekimas atlaikytų didelio masto sutrikimus, įskaitant tinklo ar elektros energijos tiekimo sutrikimus. Ir nors įprastiniai metodai, pvz., konteinerių paskirstymas tarp gedimų sričių, gerai veikia teikiant paslaugas be būsenos, būsenos paslaugoms reikia papildomos paramos.
Pavyzdžiui, jei dėl serverio gedimo viena duomenų bazės kopija tampa nepasiekiama, ar turėtumėte įjungti automatinę priežiūrą, kuri atnaujins 50 serverių branduolius iš 10 50 serverių? Priklauso nuo situacijos. Jei vienas iš šių 2 serverių turi kitą tos pačios duomenų bazės kopiją, geriau palaukti ir neprarasti XNUMX kopijų iš karto. Kad galėtume dinamiškai priimti sprendimus dėl sistemos priežiūros ir našumo, mums reikia informacijos apie vidinį duomenų replikavimą ir kiekvienos būsenos paslaugos išdėstymo logiką.
„TaskControl“ sąsaja leidžia būsenos paslaugoms daryti įtaką sprendimams, turintiems įtakos duomenų prieinamumui. Naudodamas šią sąsają, planuoklis praneša išorinėms programoms apie konteinerio operacijas (paleidimą iš naujo, atnaujinimą, perkėlimą, priežiūrą). Būsenos paslauga įdiegia valdiklį, kuris praneša Tupperware, kada saugu atlikti kiekvieną operaciją, ir šias operacijas galima laikinai pakeisti arba atidėti. Aukščiau pateiktame pavyzdyje duomenų bazės valdiklis gali nurodyti Tupperware atnaujinti 49 iš 50 serverių, bet kol kas palikti konkretų serverį (X). Dėl to, jei branduolio atnaujinimo laikotarpis praeina ir duomenų bazė vis tiek negali atkurti probleminės kopijos, Tupperware vis tiek atnaujins X serverį.
Daugelis būseną teikiančių paslaugų „Tupperware“ naudoja „TaskControl“ ne tiesiogiai, o per „ShardManager“ – bendrą platformą, skirtą „Facebook“ paslaugoms kurti. Naudodami „Tupperware“, kūrėjai gali tiksliai nurodyti, kaip konteineriai turėtų būti paskirstyti duomenų centruose. Naudodami ShardManager kūrėjai nurodo savo ketinimą, kaip duomenų šukės turėtų būti paskirstytos konteineriuose. „ShardManager“ žino apie duomenų išdėstymą ir savo programų replikaciją ir bendrauja su „Tupperware“ per „TaskControl“ sąsają, kad suplanuotų konteinerio operacijas be tiesioginio programos dalyvavimo. Ši integracija labai supaprastina būseną palaikančių paslaugų valdymą, tačiau „TaskControl“ gali daugiau. Pavyzdžiui, mūsų plati žiniatinklio pakopa yra be būsenos ir naudoja TaskControl, kad dinamiškai koreguotų konteinerių naujinimų dažnį. Galų gale per dieną nepakenkiant prieinamumui.
Serverių valdymas duomenų centruose
Kai Tupperware pirmą kartą buvo paleista 2011 m., kiekvieną serverių grupę valdė atskiras planuoklis. Tada „Facebook“ klasteris buvo serverių stelažų, prijungtų prie vieno tinklo jungiklio, grupė, o duomenų centre buvo keletas grupių. Planuoklis galėjo valdyti serverius tik viename klasteryje, o tai reiškia, kad užduotis negalėjo išplisti keliose grupėse. Mūsų infrastruktūra augo, vis dažniau nurašėme klasterius. Kadangi Tupperware be pakeitimų negalėjo perkelti darbo iš nebeeksploatuojamo klasterio į kitas grupes, tai pareikalavo daug pastangų ir kruopštaus koordinavimo tarp programų kūrėjų ir duomenų centrų operatorių. Dėl šio proceso buvo švaistomi ištekliai, kai serveriai kelis mėnesius neveikė dėl eksploatavimo nutraukimo procedūrų.
Sukūrėme išteklių brokerį, kuris išspręstų klasterio eksploatavimo nutraukimo problemą ir koordinuotų kitų tipų priežiūros užduotis. Išteklių brokeris seka visą fizinę informaciją, susietą su serveriu, ir dinamiškai nusprendžia, kuris planuoklis valdo kiekvieną serverį. Dinaminis serverių susiejimas su planuokliais leidžia planuotojui valdyti serverius skirtinguose duomenų centruose. Kadangi Tupperware užduotis nebėra apribota vienu klasteriu, Tupperware vartotojai gali nurodyti, kaip konteineriai turi būti paskirstyti gedimų srityse. Pavyzdžiui, kūrėjas gali pareikšti savo ketinimą (tarkim: „vykdyti mano darbą 2 gedimų srityse PRN regione“) nenurodydamas konkrečių pasiekiamumo zonų. Pati „Tupperware“ suras tinkamus serverius šiam ketinimui įgyvendinti, net jei klasteris ar paslauga bus nutraukta.
Galima keisti, kad palaikytų visą pasaulinę sistemą
Istoriškai mūsų infrastruktūra buvo padalinta į šimtus dedikuotų serverių telkinių, skirtų atskiroms komandoms. Dėl susiskaidymo ir standartų trūkumo turėjome didelių veiklos sąnaudų, o neveikiančius serverius vėl buvo sunkiau naudoti. Praėjusių metų konferencijoje pristatėme , kuris turėtų sujungti mūsų infrastruktūrą į didelį vieną serverių parką. Tačiau vienas serverių parkas turi savų sunkumų. Jis turi atitikti tam tikrus reikalavimus:
- Mastelio keitimas. Mūsų infrastruktūra išaugo, kai kiekviename regione pridėjome duomenų centrus. Serveriai tapo mažesni ir taupesni energiją, todėl kiekviename regione jų yra kur kas daugiau. Todėl vienas regiono planuoklis negali apdoroti konteinerių skaičiaus, kuris gali būti paleistas šimtuose tūkstančių serverių kiekviename regione.
- Patikimumas. Net jei planuoklį galima tiek padidinti, didelė planavimo priemonės apimtis reiškia, kad yra didesnė klaidų rizika ir visas konteinerių regionas gali tapti nevaldomas.
- Gedimų tolerancija. Didžiulio infrastruktūros gedimo atveju (pavyzdžiui, serveriai, kuriuose veikia planuotojas, sugenda dėl tinklo gedimo ar elektros energijos tiekimo nutraukimo), neigiamos pasekmės turėtų paveikti tik dalį regiono serverių.
- Naudojimo patogumas. Gali atrodyti, kad vienam regionui reikia paleisti kelis nepriklausomus planuoklius. Tačiau patogumo požiūriu, vienas įėjimo taškas į bendrą regiono telkinį leidžia lengviau valdyti pajėgumus ir darbo vietas.
Tvarkaraštį padalijome į šukes, kad išspręstume didelio bendro telkinio priežiūros problemas. Kiekviena planuotojo dalis valdo savo užduočių rinkinį regione, o tai sumažina su planuotoju susijusią riziką. Didėjant bendram telkiniui galime pridėti daugiau planavimo priemonių šukių. „Tupperware“ naudotojams skeveldros ir planavimo tarpiniai serveriai atrodo kaip vienas valdymo skydelis. Jiems nereikia dirbti su krūva šukių, kurios atlieka užduotis. Planuoklio skeveldros iš esmės skiriasi nuo anksčiau naudotų klasterių planuoklių, kai valdymo pultas buvo padalintas į skaidinius, statiškai nepaskirstant bendro serverių telkinio pagal tinklo topologiją.
Padidinkite naudojimo efektyvumą naudodami elastingą skaičiavimą
Kuo didesnė mūsų infrastruktūra, tuo svarbiau efektyviai naudoti serverius, kad būtų optimizuotos infrastruktūros sąnaudos ir sumažinta apkrova. Yra du būdai, kaip padidinti serverio naudojimo efektyvumą:
- Elastingas kompiuteris – sumažinkite internetinių paslaugų mastelį tyliomis valandomis ir naudokite atlaisvintus serverius darbo krūviams neprisijungus, pvz., mašininiam mokymuisi ir MapReduce darbams.
- Perkrovimas – įdėkite internetines paslaugas ir paketinius darbo krūvius tuose pačiuose serveriuose, kad paketiniai darbo krūviai veiktų žemu prioritetu.
Mūsų duomenų centrų kliūtis yra . Todėl pirmenybę teikiame mažiems, energiją taupantiems serveriams, kurie kartu suteikia daugiau apdorojimo galios. Deja, mažuose serveriuose su mažai procesoriaus ir atminties perkrova yra mažiau efektyvi. Žinoma, viename mažame, energiją taupančiame serveryje galime patalpinti kelis konteinerius mažų paslaugų, kurios sunaudoja mažai procesoriaus resursų ir atminties, tačiau didelės paslaugos šioje situacijoje turės mažą našumą. Todėl mūsų didelių paslaugų kūrėjams patariame jas optimizuoti taip, kad jie naudotų visus serverius.
Iš esmės mes pageriname naudojimo efektyvumą naudodami elastingą skaičiavimą. Daugelis pagrindinių mūsų paslaugų, pvz., naujienų kanalas, pranešimų siuntimo funkcija ir sąsajos žiniatinklio pakopa, skiriasi priklausomai nuo paros laiko. Tyliai sumažiname internetines paslaugas tyliomis valandomis ir naudojame atlaisvintus serverius darbo krūviams neprisijungus, pvz., mašininiam mokymuisi ir MapReduce darbams.
Iš patirties žinome, kad geriausia teikti ištisus serverius kaip elastingos talpos vienetus, nes didelės paslaugos yra ir pagrindiniai elastingos talpos donorai, ir pagrindiniai vartotojai, ir yra optimizuotos naudoti visus serverius. Kai serveris atleidžiamas nuo internetinės paslaugos ramiomis valandomis, išteklių tarpininkas išnuomoja serverį planuokliui, kad jame būtų vykdomi darbo krūviai neprisijungus. Jei internetinė paslauga patiria didžiausią apkrovą, išteklių brokeris greitai atšaukia pasiskolintą serverį ir kartu su planuotoju grąžina jį į internetinę paslaugą.
Išmoktos pamokos ir ateities planai
Per pastaruosius 8 metus kūrėme Tupperware, kad neatsiliktų nuo spartaus Facebook augimo. Dalinamės tuo, ką išmokome, ir tikimės, kad tai padės kitiems valdyti sparčiai augančią infrastruktūrą:
- Nustatykite lankstų ryšį tarp valdymo pulto ir jo valdomų serverių. Šis lankstumas leidžia valdymo pultui valdyti serverius skirtinguose duomenų centruose, padeda automatizuoti klasterių eksploatavimo nutraukimą ir priežiūrą bei leidžia dinamiškai paskirstyti pajėgumus naudojant elastingą skaičiavimą.
- Su vienu valdymo skydeliu regione tampa patogiau dirbti su užduotimis ir lengviau valdyti didelį bendrą serverių parką. Atkreipkite dėmesį, kad valdymo pultas palaiko vieną įėjimo tašką, net jei jo vidinė struktūra yra atskirta dėl masto ar gedimų tolerancijos.
- Naudojant papildinio modelį, valdymo skydelis gali pranešti išorinėms programoms apie būsimas konteinerio operacijas. Be to, būseną palaikančios paslaugos gali naudoti papildinio sąsają, kad tinkintų konteinerių valdymą. Su šiuo papildinio modeliu valdymo skydelis suteikia paprastumo ir efektyviai aptarnauja daugybę skirtingų būseną nurodančių paslaugų.
- Manome, kad elastingas skaičiavimas, kai iš donorų paslaugų atimame ištisus serverius, skirtus paketiniams darbams, mašininiam mokymuisi ir kitoms neskubioms paslaugoms, yra optimalus būdas pagerinti mažų, energiją taupančių serverių efektyvumą.
Mes tik pradedame įgyvendinti . Šiuo metu apie 20% mūsų serverių yra bendrame baseine. Norint pasiekti 100 proc., reikia išspręsti daugybę problemų, įskaitant bendro saugyklos telkinio palaikymą, priežiūros automatizavimą, kelių nuomininkų reikalavimų valdymą, serverio naudojimo gerinimą ir mašininio mokymosi darbo krūvių palaikymą. Nekantraujame priimti šiuos iššūkius ir pasidalinti savo sėkme.
Šaltinis: www.habr.com