Klusterren kudeaketa eraginkorra eta fidagarria edozein eskalatan Tupperwarerekin
Gaur aurrera Tupperware aurkeztu genuen, gure kluster kudeaketa sistema, ia gure zerbitzu guztiak exekutatzen dituzten milioika zerbitzaritan edukiontziak orkestratzen dituena. 2011n zabaldu genuen lehen aldiz Tupperware, eta orduz geroztik gure azpiegitura handitu egin da osotara . Denbora honetan guztian, Tupperware ez zen geldirik egon eta gurekin garatu zen. Tupperware-k lehen mailako kluster kudeaketa nola eskaintzen duen erakutsiko dizugu, egoera-zerbitzuetarako laguntza erosoa, datu-zentro guztien kontrol-panel bakarra eta zerbitzuen artean denbora errealean ahalmena banatzeko gaitasuna barne. Gure azpiegiturak eboluzionatu ahala, ikasitako ikasgaiak ere partekatuko ditugu.
Tupperware-k zeregin desberdinak egiten ditu. Aplikazioen garatzaileek aplikazioak entregatzeko eta kudeatzeko erabiltzen dute. Aplikazio-kodea eta mendekotasunak irudi batean paketatzen ditu eta zerbitzarietara edukiontzi gisa entregatzen ditu. Edukiontziek zerbitzari bereko aplikazioen arteko isolamendua eskaintzen dute, garatzaileek aplikazioen logikari aurre egiteko eta zerbitzariak aurkitzeko edo eguneraketak kudeatzeko kezkatu beharrik izan ez dezaten. Tupperware-k zerbitzariaren errendimendua ere kontrolatzen du, eta hutsegiterik aurkitzen badu, zerbitzari problematikotik edukiontziak transferitzen ditu.
Edukiera planifikatzeko ingeniariek Tupperware erabiltzen dute zerbitzariaren gaitasuna taldeei aurrekontuaren eta murrizketen arabera esleitzeko. Zerbitzariaren erabilera hobetzeko ere erabiltzen dute. Datu zentroetako operadoreek Tupperware-ra jotzen dute datu-zentroetan edukiontziak behar bezala banatzeko eta mantentze-lanetan edukiontziak gelditzeko edo mugitzeko. Horri esker, zerbitzariak, sareak eta ekipoak mantentzeak giza esku-hartze minimoa eskatzen du.
Tupperware arkitektura
Tupperware PRN arkitektura gure datu-zentroetako eskualdeetako bat da. Eskualdea inguruan kokatutako hainbat datu zentroko eraikinek (PRN1 eta PRN2) osatzen dute. Zerbitzari guztiak eskualde batean kudeatuko dituen kontrol panel bat egiteko asmoa dugu.
Aplikazioen garatzaileek zerbitzuak eskaintzen dituzte Tupperware lanpostu moduan. Lan batek hainbat edukiontziz osatuta dago, eta guztiek normalean aplikazio-kode bera exekutatzen dute.
Tupperware-k edukiontziak hornitzeaz eta haien bizi-zikloa kudeatzeaz arduratzen da. Hainbat osagaiz osatuta dago:
- Tupperware frontend-ak erabiltzaile-interfazerako, CLIrako eta beste automatizazio-tresnetarako APIak eskaintzen ditu Tupperware-rekin elkarreragin dezakezun. Barne egitura osoa ezkutatzen dute Tupperware lan-jabeei.
- Tupperware Scheduler edukiontzia eta lanaren bizi-zikloa kudeatzeaz arduratzen den kontrol-panela da. Eskualde eta mundu mailan zabaltzen da, non eskualdeko programatzaileak eskualde bateko zerbitzariak kudeatzen dituen eta programatzaile globalak eskualde ezberdinetako zerbitzariak kudeatzen dituen. Antolatzailea zatitan banatzen da, eta zati bakoitzak lan multzo bat kudeatzen du.
- Tupperware-ren Scheduler Proxy-k barne zatiketa ezkutatzen du eta Tupperware-ren erabiltzaileentzako beira-panela erosoa eskaintzen du.
- Tupperware esleitzaileak edukiontziak zerbitzariei esleitzen dizkie. Antolatzaileak edukiontzien gelditzea, abiaraztea, eguneratzea eta hutsegitea kudeatzen du. Gaur egun, esleitzaile batek eskualde osoa kudea dezake zatitan banatu gabe. (Kontuan izan terminologia desberdina. Adibidez, Tupperware-ko programatzailea kontrol panelari dagokio , eta Tupperware esleitzaileari Kubernetesen programatzaile deitzen zaio.)
- Baliabide-artekariak zerbitzariaren eta zerbitzuaren gertaeren egiaren iturria gordetzen du. Datu-zentro bakoitzeko baliabide-artekari bat exekutatzen dugu, eta datu-zentro horretako zerbitzariei buruzko informazio guztia gordetzen du. Baliabide-artekariak eta edukiera kudeatzeko sistemak, edo baliabideak hornitzeko sistemak, dinamikoki erabakitzen dute zein programatzaileren entrega kontrolatzen duen zerbitzaria. Osasuna egiaztatzeko zerbitzuak zerbitzariak kontrolatzen ditu eta haien osasunari buruzko datuak baliabide-artekarian gordetzen ditu. Zerbitzari batek arazoak baditu edo mantentze-lanak behar baditu, baliabideen bitartekariak esleitzaile eta programatzaileari esaten dio edukiontziak gelditzeko edo beste zerbitzarietara eramateko.
- Tupperware Agent zerbitzari bakoitzean exekutatzen den deabru bat da, edukiontziak hornitzea eta kentzea kudeatzen duena. Aplikazioak edukiontzi baten barruan exekutatzen dira, eta horrek isolamendu eta errepikagarritasun handiagoa ematen die. On Dagoeneko deskribatu dugu nola sortzen diren Tupperware edukiontziak irudiak, btrfs, cgroupv2 eta systemd erabiliz.
Tupperware-ren ezaugarri bereizgarriak
Tupperware modu askotan antzekoa da beste kluster kudeaketa sistemekin, hala nola Kubernetes eta , baina aldeak ere badaude:
- Estatuko zerbitzuetarako laguntza integratua.
- Datu-zentro ezberdinetako zerbitzarientzako kontrol-panel bakarra edukiontzien bidalketa automatizatzeko asmoaren, klusterren desafektazioan eta mantentze-lanetan oinarrituta.
- Kontrol-panelaren banaketa garbia zooma egiteko.
- Informatika elastikoak zerbitzuen artean potentzia denbora errealean banatzeko aukera ematen du.
Ezaugarri polit hauek garatu ditugu estaturik gabeko eta estaturik gabeko hainbat aplikazio onartzeko, partekatutako zerbitzarien flota global handi batean.
Estatuko zerbitzuetarako laguntza integratua.
Tupperware-k Facebook, Instagram, Messenger eta WhatsApp-en produktuen datu iraunkorrak gordetzen dituzten egoera-zerbitzu kritiko ugari ditu. Hauek gako-balio bikoteen biltegi handiak izan daitezke (adibidez. ) eta datu-biltegien jarraipena (adibidez, и ). Egoera-zerbitzuak mantentzea ez da erraza, sistemak bermatu behar duelako edukiontzien hornikuntzak etenaldi handiak jasan ditzakeela, sarearen etenaldiak edo argindar etenaldiak barne. Eta ohiko teknikak, esate baterako, edukiontziak akatsen domeinuetan banatzea, estaturik gabeko zerbitzuetarako ondo funtzionatzen duten arren, egoera-zerbitzuek laguntza gehigarria behar dute.
Adibidez, zerbitzariaren hutsegite batek datu-basearen erreplika bat erabilgarri ez uzten badu, 50 multzoko 10 zerbitzarietako nukleoak eguneratuko dituen mantentze automatikoa gaitu behar duzu? Egoeraren araberakoa da. 50 zerbitzari hauetako batek datu-base beraren beste erreplika bat badu, hobe da itxarotea eta aldi berean 2 erreplika ez galtzea. Sistemaren mantentzeari eta errendimenduari buruzko erabakiak dinamikoki hartzeko, barneko datuen erreplikazioari eta egoera-zerbitzu bakoitzaren kokapen-logikari buruzko informazioa behar dugu.
TaskControl interfazeari esker, egoera-zerbitzuek datuen erabilgarritasuna eragiten duten erabakietan eragina izan dezakete. Interfaze hau erabiliz, programatzaileak kanpoko aplikazioei jakinarazten die edukiontzien eragiketei buruz (berrabiarazi, eguneratu, migrazioa, mantentze-lanak). Egoera-zerbitzu batek eragiketa bakoitza egitea segurua noiz den esaten dion kontroladore bat ezartzen du Tupperware-i, eta eragiketa horiek aldi baterako trukatu edo atzeratu daitezke. Goiko adibidean, datu-basearen kontrolatzaileak Tupperwareri esan diezaioke 49 zerbitzarietatik 50 eguneratzeko, baina oraingoz zerbitzari zehatz bat (X) bakarrik utzi. Ondorioz, nukleoa eguneratzeko epea igarotzen bada eta datu-baseak ezin badu erreplika problematikoa berreskuratu, Tupperware-k X zerbitzaria eguneratuko du.
Tupperware-ko egoera-zerbitzu askok TaskControl erabiltzen dute ez zuzenean, ShardManager-en bidez baizik, Facebook-en egoera-zerbitzuak sortzeko plataforma arrunta. Tupperware-rekin, garatzaileek datu-zentroetan edukiontziak nola banatu behar diren zehatz-mehatz zehaztu dezakete. ShardManager-ekin, garatzaileek datu zatiak edukiontzien artean nola banatu behar diren jakiteko asmoa zehazten dute. ShardManager-ek bere aplikazioen datuak jartzeaz eta erreplikatzeaz jabetzen da eta Tupperware-rekin komunikatzen da TaskControl interfazearen bidez edukiontzien eragiketak antolatzeko aplikazio zuzeneko inplikaziorik gabe. Integrazio honek asko errazten du egoera zerbitzuen kudeaketa, baina TaskControl gehiago egiteko gai da. Adibidez, gure web maila zabala estaturik gabekoa da eta TaskControl erabiltzen du edukiontzien eguneratze-tasa dinamikoki doitzeko. Azkenean egunean, erabilgarritasuna arriskuan jarri gabe.
Datu-zentroetako zerbitzariak kudeatzea
Tupperware 2011n abiarazi zenean, zerbitzari-kluster bakoitza programatzaile bereizi batek kudeatzen zuen. Orduan, Facebook kluster bat sareko etengailu batera konektatutako zerbitzari-rack talde bat zen, eta datu-zentroak hainbat kluster zeuden. Antolatzaileak kluster batean soilik kudeatu ditzake zerbitzariak, hau da, lana ezin izan da kluster askotan zabaldu. Gure azpiegiturak hazi egin ziren, gero eta gehiago desagerrarazi genituen klusterrak. Tupperware-k ezin zuenez lana aldatu gabe utzitako kluster batetik beste kluster batzuetara eraman aldaketarik gabe, esfortzu handia eta koordinazio zorrotza behar zituen aplikazioen garatzaileen eta datu-zentroko operadoreen artean. Prozesu honek baliabideak alferrik galtzea eragin zuen zerbitzariak hilabetez inaktibo egon zirenean desafektatzeko prozeduren ondorioz.
Baliabide-artekari bat sortu dugu kluster desafektatzeko arazoa konpontzeko eta beste mantentze-lan mota batzuk koordinatzeko. Baliabide-artekariak zerbitzari bati lotutako informazio fisiko guztiaren jarraipena egiten du eta dinamikoki erabakitzen du zein programatzaileak kontrolatzen duen zerbitzari bakoitza. Zerbitzariak programatzaileekin dinamikoki lotzeak datu-zentro ezberdinetako zerbitzariak kudeatzeko aukera ematen dio programatzaileak. Tupperware-ren lana jada kluster bakar batera mugatzen ez denez, Tupperware-ko erabiltzaileek ontziak akatsen domeinuetan nola banatu behar diren zehaztu dezakete. Adibidez, garatzaile batek bere asmoa deklaratu dezake (esan: "exekutatu nire lana 2 akatsen domeinuetan PRN eskualdean") erabilgarritasun-eremu zehatzak zehaztu gabe. Tupperware-k berak asmo hori ezartzeko zerbitzari egokiak aurkituko ditu, nahiz eta klusterra edo zerbitzua deskargatuta egon.
Sistema global osoa onartzen duen eskalagarria
Historikoki, gure azpiegitura talde indibidualentzako ehunka zerbitzari dedikatutan banatu da. Zatikatze- eta estandarrik ezaren ondorioz, eragiketa-kostu handiak genituen, eta inaktibo zerbitzariak berriro erabiltzea zailagoa zen. Iazko jardunaldietan aurkeztu genuen , gure azpiegiturak zerbitzari parke bakarrean batu beharko lituzkeena. Baina zerbitzari parke bakar batek bere zailtasunak ditu. Baldintza batzuk bete behar ditu:
- Eskalagarritasuna. Gure azpiegiturak hazi egin ziren eskualde bakoitzean datu-zentroak gehitu ahala. Zerbitzariak txikiagoak eta energia eraginkorragoak bihurtu dira, beraz, eskualde bakoitzean askoz gehiago daude. Ondorioz, eskualde bakoitzeko programatzaile bakar batek ezin du kudeatu eskualde bakoitzeko ehunka mila zerbitzaritan exekutatu daitezkeen edukiontzi kopurua.
- Fidagarritasuna. Antolatzailea hainbeste eskala daitekeen arren, programatzailearen esparru handiak esan nahi du erroreak izateko arrisku handiagoa dagoela eta edukiontzien eskualde oso bat kudeatu ezina izan daitekeela.
- Akatsen tolerantzia. Azpiegituraren hutsegite handi bat gertatuz gero (adibidez, programatzailea exekutatzen duten zerbitzariek huts egiten dute sarearen hutsegite baten ondorioz edo elektrizitatearen etenaldi baten ondorioz), ondorio negatiboek eskualdeko zerbitzarien zati bati bakarrik eragin beharko liokete.
- Erabilera erraza. Badirudi eskualde baterako hainbat programatzaile independente exekutatu behar dituzula. Baina erosotasunaren ikuspegitik, eskualde bateko igerileku partekatuan sartzeko puntu bakar batek errazten du gaitasuna eta lanpostuak kudeatzea.
Antolatzailea zatitan banatu dugu, partekatutako igerileku handi bat mantentzeko arazoak konpontzeko. Antolatzaileen zati bakoitzak bere lan multzoa kudeatzen du eskualdean, eta horrek programatzailearekin lotutako arriskua murrizten du. Partekatutako igerilekua hazten doan heinean, programatzaile zati gehiago gehi ditzakegu. Tupperware-ren erabiltzaileentzat, zatiak eta programatzaileen proxyek kontrol-panel bat dirudite. Ez dute zereginak orkestratzen dituzten zati mordo batekin lan egin beharrik. Antolatzaileen zatiak lehen erabiltzen genituen kluster-antolatzaileetatik oso desberdinak dira, non kontrol-panela partikatutako zerbitzarien multzoa sare-topologiaren arabera estatikoki banatu gabe.
Erabilera-eraginkortasuna hobetzea Elastic Computing-ekin
Zenbat eta azpiegitura handiagoa izan, orduan eta garrantzitsuagoa da gure zerbitzariak eraginkortasunez erabiltzea azpiegitura-kostuak optimizatzeko eta karga murrizteko. Zerbitzariaren erabileraren eraginkortasuna areagotzeko bi modu daude:
- Informatika elastikoa: murriztu lineako zerbitzuak ordu lasaietan eta erabili askatutako zerbitzariak lineaz kanpoko lan-kargak egiteko, adibidez, ikaskuntza automatikoa eta MapReduce lanetarako.
- Gainkarga - Jarri lineako zerbitzuak eta batch lan-kargak zerbitzari berdinetan, sorta-lanak lehentasun txikian exekutatzeko.
Gure datu-zentroetako oztopoa da . Hori dela eta, nahiago ditugu prozesatzeko ahalmen handiagoa ematen duten zerbitzari txiki eta energetikoki eraginkorrak. Zoritxarrez, CPU eta memoria gutxi duten zerbitzari txikietan, gainkargatzea ez da hain eraginkorra. Jakina, zerbitzu txikien hainbat edukiontzi jar ditzakegu energetikoki eraginkorra den zerbitzari txiki batean, prozesadorearen baliabide eta memoria gutxi kontsumitzen dutenak, baina zerbitzu handiek errendimendu baxua izango dute egoera honetan. Hori dela eta, gure zerbitzu handien garatzaileei horiek optimizatzeko aholkatzen diegu, zerbitzari osoak erabil ditzaten.
Funtsean, erabileraren eraginkortasuna hobetzen dugu informatika elastikoa erabiliz. Gure zerbitzu nagusietako asko, hala nola Albiste-jarioa, Mezularitza eginbidea eta frontend web maila, eguneko orduaren arabera aldatzen dira. Nahita eskalatzen ditugu lineako zerbitzuak ordu lasaietan eta askatutako zerbitzariak erabiltzen ditugu lineaz kanpoko lan-kargak egiteko, adibidez, ikaskuntza automatikoa eta MapReduce lanetarako.
Esperientziaz dakigu hobe dela zerbitzari osoak gaitasun elastikoko unitate gisa hornitzea, zerbitzu handiak emaile eta gaitasun elastikoen kontsumitzaile handiak direlako, eta zerbitzari osoak erabiltzeko optimizatuta daudelako. Zerbitzaria lineako zerbitzutik kaleratzen denean ordu lasaietan, baliabide-artekariak zerbitzaria alokatzen dio programatzaileari lineaz kanpoko lan-kargak exekutatzeko. Lineako zerbitzuak karga goren bat jasaten badu, baliabide-artekariak azkar gogoratzen du mailegatutako zerbitzaria eta, programatzailearekin batera, lineako zerbitzura itzultzen du.
Ikasgaiak eta etorkizunerako planak
Azken 8 urteetan, Tupperware garatzen aritu gara Facebook-en hazkunde azkarrari jarraitzeko. Ikasitakoa partekatzen dugu eta espero dugu besteei lagungarri izatea azkar hazten ari diren azpiegiturak kudeatzen:
- Konfiguratu konexio malgu bat kontrol panelaren eta kudeatzen dituen zerbitzarien artean. Malgutasun horri esker, kontrol-panelak datu-zentro ezberdinetako zerbitzariak kudeatzen ditu, klusterren desafektazioa eta mantentze-lanak automatizatzen laguntzen du eta gaitasun dinamikoa esleitzen du informatika elastikoa erabiliz.
- Eskualdean kontrol-panel bakarra izanik, erosoagoa da zereginekin lan egitea eta errazagoa da partekatutako zerbitzari flota handi bat kudeatzea. Kontuan izan kontrol-panelak sarrera-puntu bakarra mantentzen duela, nahiz eta bere barne-egitura bereizita egon eskala edo akatsen tolerantziagatik.
- Plugin eredu bat erabiliz, kontrol panelak kanpoko aplikazioei jakinarazi diezaieke datozen edukiontzien eragiketen berri. Gainera, egoera-zerbitzuek pluginen interfazea erabil dezakete edukiontzien kudeaketa pertsonalizatzeko. Plugin-eredu honekin, kontrol-panelak sinpletasuna eskaintzen du, eta modu eraginkorrean hainbat egoera zerbitzu eskaintzen ditu.
- Uste dugu informatika elastikoa, non emaileen zerbitzuetatik zerbitzari osoak kentzen ditugun batch lanetarako, ikaskuntza automatikorako eta premiazkoak ez diren beste zerbitzu batzuetarako, zerbitzari txiki eta energetikoki eraginkorrak direnen eraginkortasuna hobetzeko modurik egokiena dela.
Inplementatzen hasi besterik ez gara . Gaur egun gure zerbitzarien % 20 inguru igerileku partekatu batean daude. % 100 lortzeko, arazo asko konpondu behar dira, besteak beste, biltegiratze partekatutako biltegiratze bat mantentzea, mantentze-lanak automatizatzea, maizter arteko eskakizunak kudeatzea, zerbitzariaren erabilera hobetzea eta ikaskuntza automatikoko lan-kargaren laguntza hobetzea. Ezin dugu itxaron erronka horiei aurre egiteko eta gure arrakastak partekatzeko.
Iturria: www.habr.com