Menaxhimi efikas dhe i besueshëm i grupimeve në çdo shkallë me Tupperware
Sot në ne prezantuam Tupperware, sistemin tonë të menaxhimit të grupimeve që orkestron kontejnerët në miliona serverë që drejtojnë pothuajse të gjitha shërbimet tona. Ne vendosëm për herë të parë Tupperware në 2011, dhe që atëherë infrastruktura jonë është rritur në tërësi . Gjatë gjithë kësaj kohe, Tupperware nuk qëndroi ende dhe u zhvillua me ne. Ne do t'ju tregojmë se si Tupperware ofron menaxhimin e grupeve të klasit të parë, duke përfshirë mbështetje të përshtatshme për shërbimet shtetërore, një panel të vetëm kontrolli për të gjitha qendrat e të dhënave dhe aftësinë për të shpërndarë kapacitetin midis shërbimeve në kohë reale. Ne gjithashtu do të ndajmë mësimet që kemi mësuar ndërsa infrastruktura jonë zhvillohet.
Tupperware kryen detyra të ndryshme. Zhvilluesit e aplikacioneve e përdorin atë për të ofruar dhe menaxhuar aplikacionet. Ai paketon kodin e aplikacionit dhe varësitë në një imazh dhe ia dërgon serverëve si kontejnerë. Kontejnerët ofrojnë izolim midis aplikacioneve në të njëjtin server, në mënyrë që zhvilluesit të merren me logjikën e aplikacionit dhe të mos shqetësohen për gjetjen e serverëve ose menaxhimin e përditësimeve. Tupperware gjithashtu monitoron performancën e serverit dhe nëse gjen një dështim, ai transferon kontejnerët nga serveri problematik.
Inxhinierët e planifikimit të kapacitetit përdorin Tupperware për të shpërndarë kapacitetin e serverit tek ekipet bazuar në buxhetin dhe kufizimet. Ata gjithashtu e përdorin atë për të përmirësuar përdorimin e serverit. Operatorët e qendrave të të dhënave i drejtohen Tupperware për të shpërndarë siç duhet kontejnerët nëpër qendrat e të dhënave dhe për të ndaluar ose lëvizur kontejnerët gjatë mirëmbajtjes. Falë kësaj, mirëmbajtja e serverëve, rrjeteve dhe pajisjeve kërkon ndërhyrje minimale njerëzore.
Arkitektura Tupperware
Arkitektura Tupperware PRN është një nga rajonet e qendrave tona të të dhënave. Rajoni përbëhet nga disa ndërtesa të qendrave të të dhënave (PRN1 dhe PRN2) të vendosura afër. Ne planifikojmë të bëjmë një panel kontrolli që do të menaxhojë të gjithë serverët në një rajon.
Zhvilluesit e aplikacioneve ofrojnë shërbime në formën e punëve të Tupperware. Një punë përbëhet nga kontejnerë të shumtë, dhe të gjithë zakonisht ekzekutojnë të njëjtin kod aplikacioni.
Tupperware është përgjegjës për sigurimin e kontejnerëve dhe menaxhimin e ciklit të tyre të jetës. Ai përbëhet nga disa komponentë:
- Frontend Tupperware ofron API për ndërfaqen e përdoruesit, CLI dhe mjete të tjera automatizimi përmes të cilave mund të ndërveproni me Tupperware. Ata fshehin të gjithë strukturën e brendshme nga pronarët e punës së Tupperware.
- Tupperware Scheduler është një panel kontrolli përgjegjës për menaxhimin e kontejnerit dhe ciklit jetësor të punës. Ai vendoset në nivele rajonale dhe globale, ku planifikuesi rajonal menaxhon serverët në një rajon dhe planifikuesi global menaxhon serverë nga rajone të ndryshme. Planifikuesi ndahet në copëza dhe çdo copëz menaxhon një sërë punësh.
- Proxy Scheduler i Tupperware fsheh ndarjen e brendshme dhe ofron një panel të vetëm xhami të përshtatshëm për përdoruesit e Tupperware.
- Alokuesi Tupperware cakton kontejnerë në serverë. Planifikuesi trajton ndalimin, fillimin, përditësimin dhe dështimin e kontejnerëve. Aktualisht, një alokues mund të menaxhojë të gjithë rajonin pa u ndarë në copa. (Vini re ndryshimin në terminologji. Për shembull, programuesi në Tupperware korrespondon me panelin e kontrollit në , dhe alokuesi Tupperware quhet planifikues në Kubernetes.)
- Ndërmjetësi i burimeve ruan burimin e së vërtetës për serverin dhe ngjarjet e shërbimit. Ne drejtojmë një ndërmjetës burimesh për çdo qendër të dhënash, dhe ai ruan të gjitha informacionet rreth serverëve në atë qendër të dhënash. Ndërmjetësi i burimeve dhe sistemi i menaxhimit të kapacitetit, ose sistemi i sigurimit të burimeve, vendosin në mënyrë dinamike se cili planifikues i dorëzimit kontrollon cilin server. Shërbimi i kontrollit shëndetësor monitoron serverët dhe ruan të dhëna për shëndetin e tyre në ndërmjetësin e burimeve. Nëse një server ka probleme ose ka nevojë për mirëmbajtje, ndërmjetësi i burimeve i thotë alokuesit dhe planifikuesit të ndalojnë kontejnerët ose t'i zhvendosin në serverë të tjerë.
- Agjenti Tupperware është një demon që funksionon në çdo server që përgatit dhe heq kontejnerët. Aplikimet funksionojnë brenda një kontejneri, gjë që u jep atyre më shumë izolim dhe riprodhueshmëri. Aktiv Ne kemi përshkruar tashmë se si krijohen kontejnerët individualë të Tupperware duke përdorur imazhe, btrfs, cgroupv2 dhe systemd.
Karakteristikat dalluese të Tupperware
Tupperware është i ngjashëm në shumë mënyra me sistemet e tjera të menaxhimit të grupimeve si Kubernetes dhe , por ka edhe dallime:
- Mbështetje e integruar për shërbimet shtetërore.
- Një panel i vetëm kontrolli për serverët në qendra të ndryshme të të dhënave për të automatizuar shpërndarjen e kontejnerëve bazuar në qëllimin, çmontimin e grupimeve dhe mirëmbajtjen.
- Pastroni ndarjen e panelit të kontrollit për zmadhimin.
- Llogaritja elastike ju lejon të shpërndani fuqinë midis shërbimeve në kohë reale.
Ne i zhvilluam këto veçori interesante për të mbështetur një sërë aplikacionesh pa shtetësi dhe shtetësi në një flotë të madhe globale të serverëve të përbashkët.
Mbështetje e integruar për shërbimet shtetërore.
Tupperware operon një sërë shërbimesh kritike shtetërore që ruajnë të dhëna të vazhdueshme të produktit për Facebook, Instagram, Messenger dhe WhatsApp. Këto mund të jenë dyqane të mëdha të çifteve me vlerë kyçe (p.sh. ) dhe monitorimin e depove të të dhënave (për shembull, и ). Mbajtja e shërbimeve shtetërore nuk është e lehtë, sepse sistemi duhet të sigurojë që furnizimi me kontejnerë mund të përballojë ndërprerjet në shkallë të gjerë, duke përfshirë ndërprerjet e rrjetit ose ndërprerjet e energjisë. Dhe ndërsa teknikat konvencionale, të tilla si shpërndarja e kontejnerëve nëpër domenet e gabimeve, funksionojnë mirë për shërbimet pa shtetësi, shërbimet shtetërore kanë nevojë për mbështetje shtesë.
Për shembull, nëse një dështim i serverit e bën të padisponueshëm një kopje të bazës së të dhënave, a duhet të aktivizoni mirëmbajtjen automatike që do të përditësojë bërthamat në 50 serverë nga një grup prej 10? Varet nga situata. Nëse njëri nga këta 50 serverë ka një kopje tjetër të së njëjtës bazë të dhënash, është më mirë të prisni dhe të mos humbni 2 kopje menjëherë. Për të marrë në mënyrë dinamike vendime për mirëmbajtjen dhe performancën e sistemit, ne kemi nevojë për informacion në lidhje me riprodhimin e të dhënave të brendshme dhe logjikën e vendosjes së çdo shërbimi të gjendjes.
Ndërfaqja TaskControl lejon shërbimet shtetërore të ndikojnë në vendimet që ndikojnë në disponueshmërinë e të dhënave. Duke përdorur këtë ndërfaqe, planifikuesi njofton aplikacionet e jashtme në lidhje me operacionet e kontejnerit (rinisja, përditësimi, migrimi, mirëmbajtja). Një shërbim shtetëror zbaton një kontrollues që i tregon Tupperware kur është i sigurt për të kryer çdo operacion dhe këto operacione mund të ndërrohen ose të vonohen përkohësisht. Në shembullin e mësipërm, kontrolluesi i bazës së të dhënave mund t'i thotë Tupperware të përditësojë 49 nga 50 serverët, por të lërë vetëm një server specifik (X) për momentin. Si rezultat, nëse periudha e përditësimit të kernelit kalon dhe baza e të dhënave nuk është ende në gjendje të rivendosë kopjen problematike, Tupperware do të vazhdojë të përditësojë serverin X.
Shumë shërbime shtetërore në Tupperware përdorin TaskControl jo drejtpërdrejt, por përmes ShardManager, një platformë e zakonshme për krijimin e shërbimeve shtetërore në Facebook. Me Tupperware, zhvilluesit mund të specifikojnë qëllimin e tyre për saktësisht se si duhet të shpërndahen kontejnerët nëpër qendrat e të dhënave. Me ShardManager, zhvilluesit specifikojnë qëllimin e tyre për mënyrën se si duhet të shpërndahen pjesët e të dhënave nëpër kontejnerë. ShardManager është i vetëdijshëm për vendosjen e të dhënave dhe përsëritjen e aplikacioneve të tij dhe komunikon me Tupperware përmes ndërfaqes TaskControl për të planifikuar operacionet e kontejnerëve pa përfshirje të drejtpërdrejtë të aplikacionit. Ky integrim thjeshton shumë menaxhimin e shërbimeve shtetërore, por TaskControl është i aftë për më shumë. Për shembull, niveli ynë i gjerë i uebit është pa shtetësi dhe përdor TaskControl për të rregulluar në mënyrë dinamike shkallën e përditësimeve në kontejnerë. Përfundimisht në ditë pa kompromentuar disponueshmërinë.
Menaxhimi i serverëve në qendrat e të dhënave
Kur Tupperware u lançua për herë të parë në 2011, çdo grup serverësh menaxhohej nga një programues i veçantë. Në atë kohë, një grup i Facebook ishte një grup raftesh serverësh të lidhur me një ndërprerës rrjeti dhe qendra e të dhënave strehonte disa grupime. Planifikuesi mund të menaxhonte serverët vetëm në një grup, që do të thotë se puna nuk mund të përhapej në grupe të shumta. Infrastruktura jonë u rrit, ne i fshinim gjithnjë e më shumë grupimet. Meqenëse Tupperware nuk mund ta zhvendoste punën nga grupi i çmontuar në grupe të tjera pa ndryshime, ai kërkonte shumë përpjekje dhe koordinim të kujdesshëm midis zhvilluesve të aplikacioneve dhe operatorëve të qendrave të të dhënave. Ky proces rezultoi në humbje të burimeve kur serverët ishin të papunë për muaj të tërë për shkak të procedurave të çaktivizimit.
Ne krijuam një ndërmjetës burimesh për të zgjidhur problemin e çmontimit të grupeve dhe për të koordinuar llojet e tjera të detyrave të mirëmbajtjes. Ndërmjetësi i burimeve mban gjurmët e të gjithë informacionit fizik të lidhur me një server dhe vendos në mënyrë dinamike se cili planifikues kontrollon secilin server. Lidhja dinamike e serverëve me planifikuesit i lejon planifikuesit të menaxhojë serverët në qendra të ndryshme të të dhënave. Meqenëse një punë e Tupperware nuk është më e kufizuar në një grup të vetëm, përdoruesit e Tupperware mund të specifikojnë se si duhet të shpërndahen kontejnerët nëpër domenet e gabimeve. Për shembull, një zhvillues mund të deklarojë qëllimin e tij (le të themi: "drejtoj punën time në 2 domene me gabime në rajonin PRN") pa specifikuar zona specifike të disponueshmërisë. Vetë Tupperware do të gjejë serverë të përshtatshëm për të zbatuar këtë qëllim, edhe nëse grupi ose shërbimi është i çaktivizuar.
I shkallëzuar për të mbështetur të gjithë sistemin global
Historikisht, infrastruktura jonë është ndarë në qindra grupe serverësh të dedikuar për ekipe individuale. Për shkak të fragmentimit dhe mungesës së standardeve, ne kishim kosto të larta operacionale dhe serverët e papunë ishin më të vështirë për t'u përdorur përsëri. Në konferencën e vitit të kaluar kemi paraqitur , i cili duhet të bashkojë infrastrukturën tonë në një park të madh serverësh të vetëm. Por një park i vetëm server ka vështirësitë e veta. Ai duhet të plotësojë disa kërkesa:
- Shkallëzueshmëria. Infrastruktura jonë u rrit ndërsa shtuam qendrat e të dhënave në çdo rajon. Serverët janë bërë më të vegjël dhe më efikas në energji, kështu që ka shumë më tepër prej tyre në çdo rajon. Si rezultat, një programues i vetëm për rajon nuk mund të përballojë numrin e kontejnerëve që mund të ekzekutohen në qindra mijëra serverë në çdo rajon.
- Besueshmëria. Edhe nëse planifikuesi mund të rritet kaq shumë, shtrirja e madhe e planifikuesit do të thotë se ekziston një rrezik më i lartë gabimesh dhe një rajon i tërë kontejnerësh mund të bëhet i pamenaxhueshëm.
- Toleranca ndaj gabimeve. Në rast të një dështimi të madh të infrastrukturës (për shembull, serverët që drejtojnë planifikuesin dështojnë për shkak të një dështimi të rrjetit ose ndërprerjes së energjisë), pasojat negative duhet të prekin vetëm një pjesë të serverëve në rajon.
- Lehtësia e përdorimit. Mund të duket se ju duhet të ekzekutoni disa planifikues të pavarur për një rajon. Por nga një këndvështrim komoditeti, një pikë e vetme hyrjeje në grupin e përbashkët të një rajoni e bën më të lehtë menaxhimin e kapaciteteve dhe vendeve të punës.
Ne e ndamë planifikuesin në copa për të zgjidhur problemet e mbajtjes së një pishinë të madhe të përbashkët. Çdo copë planifikuesi menaxhon grupin e vet të punëve në rajon dhe kjo zvogëlon rrezikun që lidhet me planifikuesin. Ndërsa grupi i përbashkët rritet, ne mund të shtojmë më shumë copëza të planifikuesit. Për përdoruesit e Tupperware, copëzat dhe përfaqësuesit e programuesit duken si një panel kontrolli. Ata nuk duhet të punojnë me një tufë copëzash që orkestrojnë detyrat. Pjesët e Scheduler janë thelbësisht të ndryshme nga planifikuesit e grupimeve që kemi përdorur më parë, kur paneli i kontrollit u nda pa e ndarë statikisht grupin e përbashkët të serverëve sipas topologjisë së rrjetit.
Përmirësoni efikasitetin e përdorimit me llogaritjen elastike
Sa më e madhe infrastruktura jonë, aq më e rëndësishme është përdorimi i serverëve tanë në mënyrë efikase për të optimizuar kostot e infrastrukturës dhe për të zvogëluar ngarkesën. Ekzistojnë dy mënyra për të rritur efikasitetin e përdorimit të serverit:
- Llogaritja elastike - zvogëloni shërbimet në internet gjatë orëve të qeta dhe përdorni serverë të liruar për ngarkesat e punës jashtë linje, të tilla si mësimi i makinerive dhe punët në MapReduce.
- Mbingarkimi - Vendosni shërbimet në linjë dhe ngarkesat e punës në grup në të njëjtët serverë në mënyrë që ngarkesat e punës së grupit të funksionojnë me prioritet të ulët.
Gryka e ngushtë në qendrat tona të të dhënave është . Prandaj, ne preferojmë serverë të vegjël me efikasitet energjetik që së bashku ofrojnë më shumë fuqi përpunuese. Fatkeqësisht, në serverë të vegjël me pak CPU dhe memorie, mbingarkesa është më pak efektive. Sigurisht, ne mund të vendosim disa kontejnerë shërbimesh të vogla në një server të vogël me efikasitet energjie që konsumojnë pak burime procesori dhe memorie, por shërbimet e mëdha do të kenë performancë të ulët në këtë situatë. Prandaj, ne i këshillojmë zhvilluesit e shërbimeve tona të mëdha që t'i optimizojnë ato në mënyrë që të përdorin serverë të tërë.
Në thelb, ne përmirësojmë efikasitetin e përdorimit duke përdorur llogaritjen elastike. Shumë nga shërbimet tona kryesore, të tilla si Furnizimi i lajmeve, veçoria e mesazheve dhe niveli i faqes në internet, ndryshojnë në varësi të kohës së ditës. Ne i zvogëlojmë qëllimisht shërbimet në internet gjatë orëve të qeta dhe përdorim serverë të liruar për ngarkesat e punës jashtë linje, si mësimi i makinerive dhe punët në MapReduce.
Ne e dimë nga përvoja se është më mirë të sigurohen serverë të tërë si njësi të kapacitetit elastik, sepse shërbimet e mëdha janë edhe donatorë kryesorë edhe konsumatorë kryesorë të kapacitetit elastik, dhe janë të optimizuara për të përdorur serverë të tërë. Kur serveri lirohet nga shërbimi online gjatë orëve të qeta, ndërmjetësi i burimeve ia jep me qira serverin planifikuesit për të ekzekutuar ngarkesat e punës jashtë linje në të. Nëse shërbimi online përjeton një ngarkesë maksimale, ndërmjetësi i burimeve rikujton shpejt serverin e huazuar dhe, së bashku me planifikuesin, e kthen atë në shërbimin online.
Mësimet e nxjerra dhe planet për të ardhmen
Gjatë 8 viteve të fundit, ne kemi zhvilluar Tupperware për të vazhduar me rritjen e shpejtë të Facebook. Ne ndajmë atë që kemi mësuar dhe shpresojmë se do t'i ndihmojë të tjerët të menaxhojnë infrastrukturat me rritje të shpejtë:
- Vendosni një lidhje fleksibël midis panelit të kontrollit dhe serverëve që ai menaxhon. Ky fleksibilitet i lejon panelit të kontrollit të menaxhojë serverët në qendra të ndryshme të të dhënave, ndihmon në automatizimin e çaktivizimit dhe mirëmbajtjes së grupeve dhe mundëson shpërndarjen dinamike të kapacitetit duke përdorur llogaritjen elastike.
- Me një panel të vetëm kontrolli në rajon, bëhet më i përshtatshëm për të punuar me detyrat dhe më i lehtë për të menaxhuar një flotë të madhe të përbashkët të serverëve. Vini re se paneli i kontrollit mban një pikë të vetme hyrjeje, edhe nëse struktura e tij e brendshme është e ndarë për arsye të shkallës ose tolerancës së defekteve.
- Duke përdorur një model shtesë, paneli i kontrollit mund të njoftojë aplikacionet e jashtme për operacionet e ardhshme të kontejnerëve. Për më tepër, shërbimet shtetërore mund të përdorin ndërfaqen e shtojcave për të personalizuar menaxhimin e kontejnerëve. Me këtë model shtojce, paneli i kontrollit ofron thjeshtësi ndërsa shërben në mënyrë efikase shumë shërbime të ndryshme shtetërore.
- Ne besojmë se llogaritja elastike, ku heqim serverë të tërë nga shërbimet e donatorëve për punë grupore, mësimin e makinerive dhe shërbime të tjera jo urgjente, është mënyra optimale për të përmirësuar efikasitetin e serverëve të vegjël me efikasitet energjie.
Ne sapo kemi filluar të zbatojmë . Aktualisht rreth 20% e serverëve tanë janë në një grup të përbashkët. Për të arritur 100%, duhen adresuar shumë çështje, duke përfshirë mbajtjen e një grupi të përbashkët ruajtjeje, automatizimin e mirëmbajtjes, menaxhimin e kërkesave të ndër-qiramarrësve, përmirësimin e përdorimit të serverit dhe përmirësimin e mbështetjes për ngarkesat e punës së mësimit të makinerive. Mezi presim t'i marrim këto sfida dhe të ndajmë sukseset tona.
Burimi: www.habr.com