Doeltreffende en betroubare bestuur van trosse op enige skaal met Tupperware
Vandag aan ons het Tupperware bekendgestel, ons groepbestuurstelsel wat houers oor miljoene bedieners orkestreer wat byna al ons dienste gebruik. Ons het Tupperware die eerste keer in 2011 ontplooi, en sedertdien het ons infrastruktuur gegroei te heel . Al hierdie tyd het Tupperware nie stilgestaan en saam met ons ontwikkel nie. Ons sal jou wys hoe Tupperware eersteklas groepbestuur verskaf, insluitend gerieflike ondersteuning vir staatkundige dienste, 'n enkele beheerpaneel vir alle datasentrums, en die vermoë om kapasiteit tussen dienste in reële tyd te versprei. Ons sal ook die lesse wat ons geleer het deel soos ons infrastruktuur ontwikkel.
Tupperware voer verskillende take uit. Toepassingsontwikkelaars gebruik dit om toepassings te lewer en te bestuur. Dit verpak die toepassingskode en afhanklikhede in 'n beeld en lewer dit aan bedieners as houers. Houers verskaf isolasie tussen toepassings op dieselfde bediener sodat ontwikkelaars die toepassingslogika hanteer en nie hoef te bekommer oor die vind van bedieners of die bestuur van opdaterings nie. Tupperware monitor ook die werkverrigting van die bediener, en as dit 'n fout vind, dra dit houers van die problematiese bediener af.
Kapasiteitbeplanningsingenieurs gebruik Tupperware om bedienerkapasiteit aan spanne toe te wys op grond van begroting en beperkings. Hulle gebruik dit ook om bedienergebruik te verbeter. Datasentrumoperateurs wend hulle tot Tupperware om houers behoorlik oor datasentrums te versprei en houers te stop of te skuif tydens instandhouding. Danksy dit vereis die instandhouding van bedieners, netwerke en toerusting minimale menslike ingryping.
Tupperware argitektuur
Tupperware PRN-argitektuur is een van die streke van ons datasentrums. Die streek bestaan uit verskeie datasentrumgeboue (PRN1 en PRN2) wat naby geleë is. Ons beplan om een beheerpaneel te maak wat alle bedieners in een streek sal bestuur.
Toepassingsontwikkelaars lewer dienste in die vorm van Tupperware-take. 'n Werk bestaan uit veelvuldige houers, en hulle loop gewoonlik almal dieselfde toepassingskode uit.
Tupperware is verantwoordelik vir die voorsiening van houers en die bestuur van hul lewensiklus. Dit bestaan uit verskeie komponente:
- Die Tupperware-frontend bied API's vir die gebruikerskoppelvlak, CLI en ander outomatiseringsinstrumente waardeur u met Tupperware kan kommunikeer. Hulle verberg die hele interne struktuur vir Tupperware-werkeienaars.
- Tupperware Scheduler is 'n beheerpaneel wat verantwoordelik is vir die bestuur van die houer- en werklewensiklus. Dit word op streek- en wêreldvlakke ontplooi, waar die streekskeduleerder bedieners in een streek bestuur en die globale skeduleerder bedieners van verskillende streke bestuur. Die skeduleerder word in skerwe verdeel, en elke skerf bestuur 'n stel take.
- Tupperware se Scheduler Proxy verberg die interne versnippering en bied 'n gerieflike enkele ruit vir Tupperware-gebruikers.
- Die Tupperware-toewyser ken houers aan bedieners toe. Die skeduleerder hanteer die stop, begin, opdatering en failover van houers. Tans kan een toewyser die hele streek bestuur sonder om in skerwe te verdeel. (Let op die verskil in terminologie. Byvoorbeeld, die skeduleerder in Tupperware stem ooreen met die beheerpaneel in , en die Tupperware-toewyser word 'n skeduleerder in Kubernetes genoem.)
- Die hulpbronmakelaar stoor die bron van waarheid vir die bediener- en diensgebeurtenisse. Ons bestuur een hulpbronmakelaar vir elke datasentrum, en dit stoor alle inligting oor die bedieners in daardie datasentrum. Die hulpbronmakelaar en die kapasiteitbestuurstelsel, of hulpbronvoorsieningstelsel, besluit dinamies watter skeduleerderlewering watter bediener beheer. Die gesondheidskontrolediens monitor bedieners en stoor data oor hul gesondheid in die hulpbronmakelaar. As 'n bediener probleme het of instandhouding benodig, sê die hulpbronmakelaar aan die toewyser en skeduleerder om die houers te stop of na ander bedieners te skuif.
- Die Tupperware Agent is 'n daemoon wat op elke bediener loop wat die voorsiening en verwydering van houers hanteer. Toepassings loop binne 'n houer, wat hulle meer isolasie en reproduceerbaarheid gee. Aan Ons het reeds beskryf hoe individuele Tupperware-houers geskep word deur beelde, btrfs, cgroupv2 en systemd te gebruik.
Kenmerkende kenmerke van Tupperware
Tupperware is in baie opsigte soortgelyk aan ander groepbestuurstelsels soos Kubernetes en , maar daar is ook verskille:
- Ingeboude ondersteuning vir staatkundige dienste.
- 'n Enkele beheerpaneel vir bedieners in verskillende datasentrums om die aflewering van houers te outomatiseer op grond van voorneme, ontmanteling van groepe en instandhouding.
- Duidelike verdeling van die beheerpaneel vir zoem.
- Elastiese rekenaars laat jou toe om krag tussen dienste intyds te versprei.
Ons het hierdie oulike kenmerke ontwikkel om 'n verskeidenheid staatlose en statige toepassings oor 'n groot globale gedeelde bedienervloot te ondersteun.
Ingeboude ondersteuning vir staatkundige dienste.
Tupperware bedryf 'n verskeidenheid kritieke staatkundige dienste wat volgehoue produkdata vir Facebook, Instagram, Messenger en WhatsApp stoor. Dit kan groot winkels van sleutel-waarde-pare wees (bv. ) en monitering van databewaarplekke (byvoorbeeld, и ). Om staatkundige dienste te handhaaf is nie maklik nie, want die stelsel moet verseker dat die toevoer van houers grootskaalse ontwrigtings, insluitend netwerkonderbrekings of kragonderbrekings, kan weerstaan. En hoewel konvensionele tegnieke, soos die verspreiding van houers oor foutdomeine, goed werk vir staatlose dienste, benodig staatkundige dienste bykomende ondersteuning.
Byvoorbeeld, as 'n bedienerfout een databasisreplika onbeskikbaar maak, moet jy outomatiese instandhouding aktiveer wat die kerns op 50 bedieners vanaf 'n poel van 10 50 sal opdateer? Hang af van die situasie. As een van hierdie 2 bedieners 'n ander replika van dieselfde databasis het, is dit beter om te wag en nie XNUMX replikas op een slag te verloor nie. Om besluite oor stelselinstandhouding en -werkverrigting dinamies te neem, benodig ons inligting oor interne data-replikasie en die plasingslogika van elke staatkundige diens.
Die TaskControl-koppelvlak laat staatkundige dienste toe om besluite te beïnvloed wat die beskikbaarheid van data beïnvloed. Deur hierdie koppelvlak te gebruik, stel die skeduleerder eksterne toepassings in kennis van houerbedrywighede (herbegin, opdatering, migrasie, instandhouding). 'n Staatkundige diens implementeer 'n beheerder wat Tupperware vertel wanneer dit veilig is om elke operasie uit te voer, en hierdie operasies kan tydelik omgeruil of vertraag word. In die voorbeeld hierbo, kan die databasisbeheerder vir Tupperware sê om 49 van die 50 bedieners op te dateer, maar laat 'n spesifieke bediener (X) vir eers. As gevolg hiervan, as die kernopdateringsperiode verbygaan en die databasis steeds nie die problematiese replika kan herstel nie, sal Tupperware steeds die X-bediener opdateer.
Baie stateful dienste in Tupperware gebruik TaskControl nie direk nie, maar deur ShardManager, 'n algemene platform vir die skep van stateful dienste op Facebook. Met Tupperware kan ontwikkelaars hul bedoeling spesifiseer vir presies hoe houers oor datasentrums versprei moet word. Met ShardManager spesifiseer ontwikkelaars hul bedoeling vir hoe dataskerwe oor houers versprei moet word. ShardManager is bewus van die dataplasing en replikasie van sy toepassings en kommunikeer met Tupperware deur die TaskControl-koppelvlak om houerbedrywighede te skeduleer sonder direkte toepassingsbetrokkenheid. Hierdie integrasie vergemaklik die bestuur van staatkundige dienste aansienlik, maar TaskControl is tot meer in staat. Byvoorbeeld, ons uitgebreide webvlak is staatloos en gebruik TaskControl om die tempo van opdaterings aan houers dinamies aan te pas. Uiteindelik per dag sonder om beskikbaarheid in te boet.
Bestuur van bedieners in datasentrums
Toe Tupperware die eerste keer in 2011 bekendgestel is, is elke bedienerkluster deur 'n aparte skeduleerder bestuur. Destyds was 'n Facebook-groepering 'n groep bedienerrakke wat aan een netwerkskakelaar gekoppel is, en die datasentrum het verskeie groepe gehuisves. Die skeduleerder kon slegs bedieners in een groep bestuur, wat beteken dat die werk nie oor veelvuldige groepe kon versprei nie. Ons infrastruktuur het gegroei, ons het toenemend trosse afgeskryf. Aangesien Tupperware nie die taak sonder veranderinge van die ontmantelde groepering na ander groepe kon skuif nie, het dit baie moeite en noukeurige koördinering tussen toepassingsontwikkelaars en datasentrumoperateurs geverg. Hierdie proses het gelei tot vermorsing van hulpbronne toe bedieners maande lank ledig was as gevolg van ontmantelingsprosedures.
Ons het 'n hulpbronmakelaar geskep om die groep-ontmantelingsprobleem op te los en ander soorte instandhoudingstake te koördineer. Die hulpbronmakelaar hou boek van al die fisiese inligting wat met 'n bediener geassosieer word en besluit dinamies watter skeduleerder elke bediener beheer. Deur bedieners dinamies aan skeduleerders te koppel, kan die skeduleerder bedieners in verskillende datasentrums bestuur. Aangesien 'n Tupperware-werk nie meer tot 'n enkele groepering beperk is nie, kan Tupperware-gebruikers spesifiseer hoe houers oor foutdomeine versprei moet word. Byvoorbeeld, 'n ontwikkelaar kan sy voorneme verklaar (sê: "hardloop my werk op 2 foutdomeine in die PRN-streek") sonder om spesifieke beskikbaarheidsones te spesifiseer. Tupperware sal self geskikte bedieners vind om hierdie voorneme te implementeer, selfs al is die groepering of diens uit diens gestel.
Skaalbaar om die hele globale stelsel te ondersteun
Histories is ons infrastruktuur in honderde toegewyde bedienerpoele vir individuele spanne verdeel. As gevolg van fragmentasie en gebrek aan standaarde het ons hoë bedryfskoste gehad, en ledige bedieners was moeiliker om weer te gebruik. By verlede jaar se konferensie ons aangebied het , wat ons infrastruktuur in 'n groot enkele bedienerpark moet verenig. Maar 'n enkele bedienerpark het sy eie probleme. Dit moet aan sekere vereistes voldoen:
- Skaalbaarheid. Ons infrastruktuur het gegroei namate ons datasentrums in elke streek bygevoeg het. Bedieners het kleiner en meer energiedoeltreffend geword, so daar is baie meer van hulle in elke streek. Gevolglik kan 'n enkele skeduleerder per streek nie die aantal houers hanteer wat op honderdduisende bedieners in elke streek uitgevoer kan word nie.
- Betroubaarheid. Selfs al kan die skeduleerder soveel opgeskaal word, beteken die groot omvang van die skeduleerder dat daar 'n groter risiko van foute is en dat 'n hele streek van houers onhanteerbaar kan word.
- Fout verdraagsaamheid. In die geval van 'n groot infrastruktuurfout (byvoorbeeld, die bedieners wat die skeduleerder gebruik, misluk as gevolg van 'n netwerkonderbreking of kragonderbreking), behoort die negatiewe gevolge slegs 'n gedeelte van die bedieners in die streek te raak.
- Gemak van gebruik. Dit mag lyk asof jy verskeie onafhanklike skeduleers vir een streek moet gebruik. Maar vanuit 'n geriefsperspektief maak 'n enkele toegangspunt tot 'n streek se gedeelde poel dit makliker om kapasiteit en werksgeleenthede te bestuur.
Ons het die skeduleerder in skerwe verdeel om die probleme van die instandhouding van 'n groot gedeelde swembad op te los. Elke skeduleerder-skerf bestuur sy eie stel take in die streek, en dit verminder die risiko verbonde aan die skeduleerder. Soos die gedeelde swembad groei, kan ons meer skeduleerder-skerwe byvoeg. Vir Tupperware-gebruikers lyk skerwe en skeduleerdergevolmagtigdes soos een beheerpaneel. Hulle hoef nie met 'n klomp skerwe te werk wat take orkestreer nie. Skeduleerder-skerwe verskil fundamenteel van die groepskeduleerders wat ons voorheen gebruik het, toe die beheerpaneel gepartisioneer is sonder om die gedeelde poel bedieners staties volgens die netwerktopologie te verdeel.
Verbeter Gebruiksdoeltreffendheid met Elastic Computing
Hoe groter ons infrastruktuur, hoe belangriker is dit om ons bedieners doeltreffend te gebruik om infrastruktuurkoste te optimaliseer en las te verminder. Daar is twee maniere om die doeltreffendheid van bedienergebruik te verhoog:
- Elastiese rekenaar - skaal aanlyn dienste af gedurende stil ure en gebruik vrygestelde bedieners vir vanlyn werkladings, soos masjienleer en MapReduce-take.
- Oorlading - Plaas aanlyn dienste en bondelwerkladings op dieselfde bedieners sodat bondelwerkladings met lae prioriteit loop.
Die bottelnek in ons datasentrums is . Daarom verkies ons klein, energiedoeltreffende bedieners wat saam meer verwerkingskrag verskaf. Ongelukkig, op klein bedieners met min SVE en geheue, is oorlading minder effektief. Natuurlik kan ons verskeie houers met klein dienste op een klein energiedoeltreffende bediener plaas wat min verwerkerhulpbronne en geheue verbruik, maar groot dienste sal in hierdie situasie lae werkverrigting hê. Daarom raai ons die ontwikkelaars van ons groot dienste aan om hulle te optimaliseer sodat hulle die hele bedieners gebruik.
Basies verbeter ons gebruiksdoeltreffendheid met behulp van elastiese rekenaars. Baie van ons belangrikste dienste, soos die Nuusvoer, Boodskapfunksie en die voorste webvlak, wissel na gelang van die tyd van die dag. Ons skaal doelbewus aanlyn dienste af gedurende stil ure en gebruik vrygestelde bedieners vir vanlyn werkladings, soos masjienleer en MapReduce-take.
Ons weet uit ondervinding dat dit die beste is om hele bedieners as eenhede van elastiese kapasiteit te voorsien, want groot dienste is beide groot skenkers en groot verbruikers van elastiese kapasiteit, en is geoptimaliseer om hele bedieners te gebruik. Wanneer die bediener tydens stil ure van aanlyndiens vrygestel word, verhuur die hulpbronmakelaar die bediener aan die skeduleerder om vanlyn werkladings daarop uit te voer. As die aanlyn diens 'n pieklading ervaar, herroep die hulpbronmakelaar vinnig die geleende bediener en stuur dit saam met die skeduleerder terug na die aanlyn diens.
Lesse geleer en planne vir die toekoms
Oor die afgelope 8 jaar het ons Tupperware ontwikkel om tred te hou met die vinnige groei van Facebook. Ons deel wat ons geleer het en hoop dit sal ander help om vinnig groeiende infrastruktuur te bestuur:
- Stel 'n buigsame verbinding op tussen die beheerpaneel en die bedieners wat dit bestuur. Hierdie buigsaamheid stel die beheerpaneel in staat om bedieners in verskillende datasentrums te bestuur, help om die ontmanteling en instandhouding van groepe te outomatiseer, en maak dinamiese kapasiteitstoewysing moontlik deur gebruik te maak van elastiese rekenaars.
- Met 'n enkele beheerpaneel in die streek, word dit geriefliker om met take te werk en makliker om 'n groot gedeelde bedienervloot te bestuur. Let daarop dat die beheerpaneel 'n enkele toegangspunt handhaaf, selfs al is sy interne struktuur geskei vir redes van skaal of fouttoleransie.
- Deur 'n inpropmodel te gebruik, kan die beheerpaneel eksterne toepassings in kennis stel van komende houerbedrywighede. Boonop kan statige dienste die inprop-koppelvlak gebruik om houerbestuur aan te pas. Met hierdie inpropmodel bied die beheerpaneel eenvoud terwyl dit baie verskillende staatkundige dienste doeltreffend bedien.
- Ons glo dat elastiese rekenaars, waar ons hele bedieners van skenkerdienste wegneem vir bondeltake, masjienleer en ander nie-dringende dienste, die optimale manier is om die doeltreffendheid van klein, energiedoeltreffende bedieners te verbeter.
Ons begin net implementeer . Tans is ongeveer 20% van ons bedieners in 'n gedeelde swembad. Om 100% te bereik, moet baie kwessies aangespreek word, insluitend die instandhouding van 'n gedeelde stoorpoel, die outomatisering van instandhouding, die bestuur van kruishuurvereistes, die verbetering van bedienergebruik en die verbetering van ondersteuning vir masjienleerwerkladings. Ons kan nie wag om hierdie uitdagings aan te pak en ons suksesse te deel nie.
Bron: will.com