Efika kaj fidinda administrado de aretoj je ajna skalo kun Tupperware
Hodiaŭ plu ni prezentis Tupperware, nian mastruman sistemon, kiu regas ujojn tra milionoj da serviloj, kiuj funkcias preskaŭ ĉiujn niajn servojn. Ni unue deplojis Tupperware en 2011, kaj ekde tiam nia infrastrukturo kreskis al tuta . Dum ĉi tiu tempo, Tupperware ne staris kaj disvolviĝis kun ni. Ni montros al vi kiel Tupperware provizas unuaklasan grapoladministradon, inkluzive de oportuna subteno por ŝtataj servoj, ununura kontrolpanelo por ĉiuj datumcentroj kaj la kapablo distribui kapaciton inter servoj en reala tempo. Ni ankaŭ dividos la lecionojn, kiujn ni lernis dum nia infrastrukturo evoluas.
Tupperware plenumas malsamajn taskojn. Programistoj de aplikaĵoj uzas ĝin por liveri kaj administri aplikojn. Ĝi pakas la aplikaĵkodon kaj dependecojn en bildon kaj liveras ĝin al serviloj kiel ujoj. Ujoj provizas izolecon inter aplikaĵoj sur la sama servilo por ke programistoj traktu la aplikaĵlogikon kaj ne devas zorgi pri trovado de serviloj aŭ administrado de ĝisdatigoj. Tupperware ankaŭ kontrolas la agadon de la servilo, kaj se ĝi trovas malsukceson, ĝi transdonas ujojn de la problema servilo.
Kapacitplanaj inĝenieroj uzas Tupperware por asigni servilan kapaciton al teamoj bazitaj sur buĝeto kaj limoj. Ili ankaŭ uzas ĝin por plibonigi servila uzado. Datencentrofunkciigistoj turnas sin al Tupperware por konvene distribui ujojn tra datumcentroj kaj halti aŭ movi ujojn dum prizorgado. Danke al ĉi tio, konservi servilojn, retojn kaj ekipaĵojn postulas minimuman homan intervenon.
Tupperware-arkitekturo
Tupperware PRN-arkitekturo estas unu el la regionoj de niaj datumcentroj. La regiono konsistas el pluraj datencentrokonstruaĵoj (PRN1 kaj PRN2) situantaj proksime. Ni planas fari unu kontrolpanelon, kiu administros ĉiujn servilojn en unu regiono.
Programistoj de aplikaĵoj liveras servojn en formo de laboroj de Tupperware. Laboro konsistas el pluraj ujoj, kaj ili ĉiuj kutime funkcias la saman aplikan kodon.
Tupperware respondecas pri provizado de ujoj kaj administrado de ilia vivociklo. Ĝi konsistas el pluraj komponantoj:
- La fasado de Tupperware provizas API-ojn por la uzantinterfaco, CLI kaj aliaj aŭtomatigaj iloj per kiuj vi povas interagi kun Tupperware. Ili kaŝas la tutan internan strukturon de Tupperware-laborposedantoj.
- Tupperware Scheduler estas kontrolpanelo respondeca por administri la ujon kaj laborvivciklon. Ĝi estas deplojita sur regionaj kaj tutmondaj niveloj, kie la regiona planisto administras servilojn en unu regiono kaj la tutmonda planisto administras servilojn de malsamaj regionoj. La planilo estas dividita en pecetojn, kaj ĉiu peceto administras aron da laborpostenoj.
- La Scheduler Proxy de Tupperware kaŝas la internan sharding kaj provizas oportunan ununuran vitron por uzantoj de Tupperware.
- La Tupperware-asignilo asignas ujojn al serviloj. La planilo pritraktas ĉesigon, startadon, ĝisdatigon kaj malsukceson de ujoj. Nuntempe, unu asignanto povas administri la tutan regionon sen dividiĝi en pecetojn. (Notu la diferencon en terminologio. Ekzemple, la planilo en Tupperware respondas al la kontrolpanelo en , kaj la Tupperware-asignilo estas nomita planilo en Kubernetes.)
- La rimedmakleristo konservas la fonton de vero por la servilo kaj servokazaĵoj. Ni kuras unu rimedmakleriston por ĉiu datumcentro, kaj ĝi konservas ĉiujn informojn pri la serviloj en tiu datumcentro. La rimedmakleristo kaj la kapacita mastruma sistemo, aŭ rimeda provizosistemo, dinamike decidas kiu planilo livero kontrolas kiun servilon. La sankontrolservo kontrolas servilojn kaj konservas datumojn pri ilia sano en la rimedmakleristo. Se servilo havas problemojn aŭ bezonas prizorgadon, la rimedmakleristo diras al la asignanto kaj planisto haltigi la ujojn aŭ movi ilin al aliaj serviloj.
- La Tupperware Agento estas demono funkcianta sur ĉiu servilo kiu pritraktas la provizon kaj forigon de ujoj. Aplikoj funkcias ene de ujo, kio donas al ili pli da izoliteco kaj reproduktebleco. On Ni jam priskribis kiel individuaj ujoj de Tupperware estas kreitaj per bildoj, btrfs, cgroupv2 kaj systemd.
Karakterizaĵoj de Tupperware
Tupperware estas simila en multaj manieroj al aliaj cluster-administradsistemoj kiel ekzemple Kubernetes kaj , sed estas ankaŭ diferencoj:
- Enkonstruita subteno por ŝtataj servoj.
- Ununura kontrolpanelo por serviloj en malsamaj datumcentroj por aŭtomatigi la liveron de ujoj surbaze de intenco, malfunkciigo de aretoj kaj prizorgado.
- Klara divido de la kontrolpanelo por zomi.
- Elasta komputado permesas vin distribui potencon inter servoj en reala tempo.
Ni evoluigis ĉi tiujn bonegajn funkciojn por subteni diversajn sennaciajn kaj ŝtatajn aplikojn tra grandega tutmonda komuna servila floto.
Enkonstruita subteno por ŝtataj servoj.
Tupperware funkciigas diversajn kritikajn ŝtatajn servojn, kiuj stokas konstantajn produktajn datumojn por Facebook, Instagram, Messenger kaj WhatsApp. Ĉi tiuj povus esti grandaj butikoj de ŝlosil-valoraj paroj (ekz. ) kaj monitorado de datumdeponejoj (ekzemple, и ). Subteni ŝtatajn servojn ne estas facila, ĉar la sistemo devas certigi, ke la provizo de ujoj povas elteni grandskalajn interrompojn, inkluzive de retaj senĉesoj aŭ elektropaneoj. Kaj dum konvenciaj teknikoj, kiel distribuado de ujoj trans misfunkciaj domajnoj, funkcias bone por sennaciaj servoj, ŝtataj servoj bezonas plian subtenon.
Ekzemple, se servila fiasko malhavas unu datumbazan kopion, ĉu vi ebligu aŭtomatan prizorgadon, kiu ĝisdatigos la kernojn de 50 serviloj el aro de 10? Dependas de la situacio. Se unu el ĉi tiuj 50 serviloj havas alian kopion de la sama datumbazo, estas pli bone atendi kaj ne perdi 2 kopiojn samtempe. Por dinamike fari decidojn pri sistema prizorgado kaj rendimento, ni bezonas informojn pri interna datumreproduktado kaj la lokiga logiko de ĉiu ŝtata servo.
La TaskControl-interfaco permesas al ŝtataj servoj influi decidojn, kiuj influas la haveblecon de datumoj. Uzante ĉi tiun interfacon, la planisto sciigas eksterajn aplikaĵojn pri ujoperacioj (rekomenco, ĝisdatigo, migrado, prizorgado). Ŝtata servo efektivigas regilon kiu rakontas al Tupperware kiam estas sekure plenumi ĉiun operacion, kaj ĉi tiuj operacioj povas esti interŝanĝitaj aŭ prokrastitaj provizore. En la supra ekzemplo, la datumbaza regilo povus diri al Tupperware ĝisdatigi 49 el la 50 serviloj, sed lasi specifan servilon (X) por nun. Kiel rezulto, se la kerna ĝisdatiga periodo pasas kaj la datumbazo ankoraŭ ne povas restarigi la probleman kopion, Tupperware ankoraŭ ĝisdatigos la X-servilon.
Multaj ŝtataj servoj en Tupperware uzas TaskControl ne rekte, sed per ShardManager, ofta platformo por krei ŝtatajn servojn en Facebook. Kun Tupperware, programistoj povas specifi sian intencon pri ĝuste kiel ujoj devas esti distribuitaj tra datumcentroj. Kun ShardManager, programistoj precizigas sian intencon pri kiel datumpartoj devus esti distribuitaj tra ujoj. ShardManager konscias pri la datumlokigo kaj reproduktado de ĝiaj aplikoj kaj komunikas kun Tupperware per la TaskControl-interfaco por plani ujajn operaciojn sen rekta aplikaĵa implikiĝo. Ĉi tiu integriĝo multe simpligas la administradon de ŝtataj servoj, sed TaskControl kapablas pli. Ekzemple, nia ampleksa retnivelo estas sennacia kaj uzas TaskControl por dinamike ĝustigi la indicon de ĝisdatigoj al ujoj. Fine tage sen kompromiti la haveblecon.
Administri servilojn en datumcentroj
Kiam Tupperware unue lanĉis en 2011, ĉiu servila areto estis administrita per aparta planisto. Tiam, Facebook-areto estis grupo de servilaj rakoj ligitaj al unu retoŝaltilo, kaj la datumcentro enhavis plurajn aretojn. La planisto povis nur administri servilojn en unu areto, kio signifas, ke la laboro ne povis disvastiĝi tra pluraj aretoj. Nia infrastrukturo kreskis, ni ĉiam pli forigis aretojn. Ĉar Tupperware ne povis movi la laboron de la malmendita areto al aliaj aretoj sen ŝanĝoj, ĝi postulis multe da penado kaj zorgema kunordigo inter aplikaĵprogramistoj kaj datumcentraj funkciigistoj. Ĉi tiu procezo rezultigis malŝparitajn resursojn kiam serviloj estis neaktivaj dum monatoj pro malmendi proceduroj.
Ni kreis resursan makleriston por solvi la problemon pri malfunkciado de grapo kaj kunordigi aliajn specojn de prizorgaj taskoj. La rimedmakleristo konservas trakon de ĉiuj fizikaj informoj asociitaj kun servilo kaj dinamike decidas kiu planisto kontrolas ĉiun servilon. Dinamike ligi servilojn al planistoj permesas al la planisto administri servilojn en malsamaj datencentroj. Ĉar Tupperware-laboro ne plu estas limigita al ununura areto, Tupperware-uzantoj povas specifi kiel ujoj devas esti distribuitaj tra misfunkciaj domajnoj. Ekzemple, programisto povas deklari sian intencon (diru: "funkciigi mian laboron sur 2 misfunkciaj domajnoj en la PRN-regiono") sen specifi specifajn havebleczonojn. Tupperware mem trovos taŭgajn servilojn por efektivigi ĉi tiun intencon, eĉ se la areto aŭ servo estas malmendita.
Skalebla por subteni la tutan tutmondan sistemon
Historie, nia infrastrukturo estis dividita en centojn da diligentaj servilaj naĝejoj por individuaj teamoj. Pro fragmentiĝo kaj manko de normoj, ni havis altajn funkciajn kostojn, kaj neaktivaj serviloj estis pli malfacile reuzeblaj. En la pasintjara konferenco ni prezentis , kiu devus unuigi nian infrastrukturon en grandan ununuran servilan parkon. Sed ununura servila parko havas siajn proprajn malfacilaĵojn. Ĝi devas plenumi iujn postulojn:
- Skalebleco. Nia infrastrukturo kreskis dum ni aldonis datumcentrojn en ĉiu regiono. Serviloj fariĝis pli malgrandaj kaj pli energiaj efikaj, do estas multaj pli da ili en ĉiu regiono. Kiel rezulto, ununura planilo per regiono ne povas pritrakti la nombron da ujoj kiuj povas esti rulitaj sur centoj da miloj da serviloj en ĉiu regiono.
- Fidindeco Eĉ se la planilo povas esti tiel pligrandigita, la granda amplekso de la planilo signifas, ke ekzistas pli alta risko de eraroj kaj tuta regiono de ujoj povus iĝi neregebla.
- Kulpo toleremo. Okaze de grandega infrastruktura fiasko (ekzemple, la serviloj kurantaj la planilon malsukcesas pro reto-malfunkcio aŭ elektropaneo), la negativaj sekvoj devus influi nur parton de la serviloj en la regiono.
- La komforto de uzo. Eble ŝajnas, ke vi devas ruli plurajn sendependajn programistojn por unu regiono. Sed de oportuna perspektivo, ununura punkto de eniro en la komunan naĝejon de regiono faciligas administri kapaciton kaj laborlokojn.
Ni dividis la planilon en pecetojn por solvi la problemojn pri konservado de granda komuna naĝejo. Ĉiu planisto-peceto administras sian propran aron de laborpostenoj en la regiono, kaj ĉi tio reduktas la riskon asociitan kun la planisto. Dum la komuna naĝejo kreskas, ni povas aldoni pli da horaraj fragmentoj. Por uzantoj de Tupperware, fragmentoj kaj prokuriloj de planilo aspektas kiel unu kontrolpanelo. Ili ne devas labori kun amaso da pecetoj, kiuj regas taskojn. Scheduler-fragmentoj estas fundamente diferencaj de la clusterplanistoj, kiujn ni uzis antaŭe, kiam la kontrolpanelo estis dividita sen statike dividi la komunan aron de serviloj laŭ la retotopologio.
Plibonigu Uzadon-Efikecon per Elasta Komputado
Ju pli granda nia infrastrukturo, des pli gravas uzi niajn servilojn efike por optimumigi infrastrukturkostojn kaj redukti ŝarĝon. Estas du manieroj pliigi la efikecon de servila uzo:
- Elasta komputado - malgrandigu interretajn servojn dum trankvilaj horoj kaj uzu liberigitajn servilojn por eksterretaj laborkvantoj, kiel maŝinlernado kaj MapReduce-laboroj.
- Troŝarĝado - Metu interretajn servojn kaj grupajn laborŝarĝojn sur la samajn servilojn por ke grupaj laborkvantoj funkcias kun malalta prioritato.
La proplemkolo en niaj datumcentroj estas . Tial ni preferas malgrandajn, energiefikajn servilojn, kiuj kune provizas pli da pretigpovo. Bedaŭrinde, ĉe malgrandaj serviloj kun malmulte da CPU kaj memoro, troŝarĝado estas malpli efika. Kompreneble, ni povas meti plurajn ujojn da malgrandaj servoj sur unu malgranda energi-efika servilo, kiu konsumas malmulte da procesoraj rimedoj kaj memoro, sed grandaj servoj havos malaltan rendimenton en ĉi tiu situacio. Tial ni konsilas al la programistoj de niaj grandaj servoj optimumigi ilin por ke ili uzu la tutajn servilojn.
Esence, ni plibonigas uzado-efikecon uzante elastan komputadon. Multaj el niaj ĉefaj servoj, kiel la Novaĵfluo, Messaging-funkcio kaj front-fina TTT-nivelo, varias laŭ la horo de la tago. Ni intence malgrandigas interretajn servojn dum trankvilaj horoj kaj uzas liberigitajn servilojn por eksterretaj laborŝarĝoj, kiel maŝinlernado kaj MapReduce-laboroj.
Ni scias per sperto, ke estas plej bone provizi tutajn servilojn kiel unuojn de elasta kapacito ĉar grandaj servoj estas kaj ĉefaj donacantoj kaj ĉefaj konsumantoj de elasta kapacito, kaj estas optimumigitaj por uzi tutajn servilojn. Kiam la servilo estas liberigita de interreta servo dum trankvilaj horoj, la rimedmakleristo luas la servilon al la planisto por funkcii eksterretajn laborŝarĝojn sur ĝi. Se la reta servo spertas pintan ŝarĝon, la rimedmakleristo rapide revokas la pruntitan servilon kaj, kune kun la planilo, resendas ĝin al la reta servo.
Lecionoj lernitaj kaj planoj por la estonteco
Dum la pasintaj 8 jaroj, ni disvolvis Tupperware por daŭrigi la rapidan kreskon de Facebook. Ni dividas tion, kion ni lernis kaj esperas, ke ĝi helpos aliajn administri rapide kreskantajn infrastrukturojn:
- Agordu flekseblan konekton inter la kontrolpanelo kaj la serviloj kiujn ĝi administras. Ĉi tiu fleksebleco permesas al la kontrolpanelo administri servilojn en malsamaj datumcentroj, helpas aŭtomatigi la malfunkciadon kaj prizorgadon de aretoj, kaj ebligas dinamikan kapacitan atribuon uzante elastan komputadon.
- Kun ununura kontrolpanelo en la regiono, fariĝas pli oportune labori kun taskoj kaj pli facile administri grandan komunan servilan floton. Notu, ke la kontrolpanelo konservas ununuran punkton de eniro, eĉ se ĝia interna strukturo estas apartigita pro kialoj de skalo aŭ faŭltoleremo.
- Uzante kromprogramon, la kontrolpanelo povas sciigi eksterajn aplikojn pri venontaj ujoperacioj. Plie, ŝtataj servoj povas uzi la krominterfacon por personecigi ujadministradon. Kun ĉi tiu kromprogramo, la kontrolpanelo provizas simplecon dum efike servas multajn malsamajn ŝtatajn servojn.
- Ni kredas, ke elasta komputado, kie ni forprenas tutajn servilojn de helpdonaj servoj por bataj laboroj, maŝinlernado kaj aliaj ne-urĝaj servoj, estas la optimuma maniero plibonigi la efikecon de malgrandaj, energiefikaj serviloj.
Ni ĵus komencas efektivigi . Nuntempe ĉirkaŭ 20% de niaj serviloj estas en komuna naĝejo. Por atingi 100%, multaj aferoj devas esti traktitaj, inkluzive de konservado de komuna stokado, aŭtomatigo de bontenado, administrado de kruc-luantpostuloj, plibonigo de servila utiligo kaj plibonigo de subteno por maŝinlernado de laborkvantoj. Ni ne povas atendi preni ĉi tiujn defiojn kaj dividi niajn sukcesojn.
fonto: www.habr.com