Effizient an zouverlässeg Gestioun vu Stärekéip op all Skala mat Tupperware
Haut op mir hunn Tupperware agefouert, eise Cluster Management System deen Container iwwer Millioune Server orchestréiert, déi bal all eis Servicer lafen. Mir hunn Tupperware fir d'éischt am 2011 agesat, an zënterhier ass eis Infrastruktur gewuess zu ganz . All dës Zäit huet Tupperware net stoe stoen an mat eis entwéckelt. Mir weisen Iech wéi Tupperware éischtklasseg Clustermanagement ubitt, inklusiv praktesch Ënnerstëtzung fir statesch Servicer, eng eenzeg Kontrollpanel fir all Datenzenter, an d'Fäegkeet fir Kapazitéit tëscht Servicer an Echtzäit ze verdeelen. Mir wäerten och d'Lektioune deelen, déi mir geléiert hunn wéi eis Infrastruktur sech entwéckelt.
Tupperware mécht verschidden Aufgaben. Applikatioun Entwéckler benotzen et fir Uwendungen ze liwweren an ze managen. Et packt den Applikatiounscode an Ofhängegkeeten an e Bild a liwwert et op Serveren als Container. Container bidden Isolatioun tëscht Uwendungen um selwechte Server sou datt d'Entwéckler mat der Applikatiounslogik beschäftegen an sech keng Suergen maache fir Serveren ze fannen oder Updates ze managen. Tupperware iwwerwaacht och d'Performance vum Server, a wann et e Feeler fënnt, transferéiert se Container vum problematesche Server.
Kapazitéitsplanungsingenieuren benotzen Tupperware fir Serverkapazitéit un Teams ze verdeelen baséiert op Budget a Contrainten. Si benotzen et och fir d'Servernotzung ze verbesseren. Datacenterbetreiber wenden sech op Tupperware fir Containeren iwwer Datenzenteren richteg ze verdeelen a Container während der Ënnerhalt ze stoppen oder ze réckelen. Dank dësem erfuerdert d'Erhalen vun Serveren, Netzwierker an Ausrüstung minimal mënschlech Interventioun.
Tupperware Architektur
Tupperware PRN Architektur ass eng vun de Regioune vun eisen Datenzenteren. D'Regioun besteet aus verschiddenen Datenzentergebaier (PRN1 an PRN2) an der Géigend. Mir plangen eng Kontrollpanel ze maachen déi all Server an enger Regioun verwalten.
Applikatioun Entwéckler liwweren Servicer a Form vun Tupperware Aarbechtsplazen. Eng Aarbecht besteet aus MÉI Container, a si lafen all typesch déi selwecht Applikatioun Code.
Tupperware ass verantwortlech fir d'Behälter zur Verfügung ze stellen an hire Liewenszyklus ze managen. Et besteet aus e puer Komponenten:
- Den Tupperware Frontend bitt APIs fir d'Benotzerinterface, CLI, an aner Automatisatiounsinstrumenter, duerch déi Dir mat Tupperware interagéiere kënnt. Si verstoppen déi ganz intern Struktur vun Tupperware Aarbechtsbesëtzer.
- Tupperware Scheduler ass e Kontrollpanel verantwortlech fir de Container an den Job Liewenszyklus ze managen. Et gëtt op regionalen a globalen Niveauen ofgesat, wou de regionale Scheduler Serveren an enger Regioun geréiert an de globalen Scheduler Serveren aus verschiddene Regiounen geréiert. De Scheduler ass a Schnëtt opgedeelt, an all Schnéi geréiert eng Rei vun Aarbechtsplazen.
- Tupperware's Scheduler Proxy verstoppt den internen Schnëtt a bitt eng praktesch eenzeg Glasfënster fir Tupperware Benotzer.
- Den Tupperware Allocator gëtt Container op Serveren zou. De Scheduler handhabt Stoppen, Starten, Aktualiséierung a Failover vu Container. De Moment kann een Allocator d'ganz Regioun verwalten ouni sech a Schnëtt opzedeelen. (Notéiert den Ënnerscheed an der Terminologie. Zum Beispill, de Scheduler an Tupperware entsprécht der Kontrollpanel an , an den Tupperware Allocator gëtt e Scheduler an Kubernetes genannt.)
- De Ressource Broker späichert d'Quell vun der Wourecht fir de Server a Serviceevenementer. Mir lafen eng Ressource Broker fir all Datenzenter, an et späichert all Informatioun iwwer d'Serveren an deem Datenzenter. De Ressourcebroker an de Kapazitéitsmanagementsystem, oder de Ressourcebestëmmungssystem, entscheeden dynamesch wéi eng Scheduler Liwwerung kontrolléiert wéi ee Server. De Gesondheetscheckservice iwwerwaacht Serveren a späichert Daten iwwer hir Gesondheet am Ressourcebroker. Wann e Server Problemer huet oder Ënnerhalt brauch, seet de Ressourcebroker dem Allocator an dem Scheduler fir d'Container ze stoppen oder se op aner Serveren ze réckelen.
- Den Tupperware Agent ass en Daemon deen op all Server leeft, deen d'Bestëmmung an d'Entfernung vu Container handhabt. Uwendungen lafen an engem Container, wat hinnen méi Isolatioun a Reproduktioun gëtt. Op Mir hu scho beschriwwen wéi eenzel Tupperware Container mat Biller, btrfs, cgroupv2 a systemd erstallt ginn.
Distinctive Fonctiounen vun Tupperware
Tupperware ass op ville Weeër ähnlech wéi aner Cluster Management Systemer wéi Kubernetes an , awer et ginn och Ënnerscheeder:
- Built-in Ënnerstëtzung fir stateful Servicer.
- Eng eenzeg Kontrollpanel fir Serveren a verschiddene Rechenzentren fir d'Liwwerung vu Container ze automatiséieren op Basis vun Absicht, Ofbau vu Cluster an Ënnerhalt.
- Kloer Divisioun vun der Kontrollpanel fir ze zoomen.
- Elastesch Informatik erlaabt Iech Kraaft tëscht Servicer an Echtzäit ze verdeelen.
Mir hunn dës cool Fonctiounen entwéckelt fir eng Vielfalt vun stateless a stateful Uwendungen iwwer eng riseg global gemeinsam Serverflott z'ënnerstëtzen.
Built-in Ënnerstëtzung fir stateful Servicer.
Tupperware bedreift eng Vielfalt vu kriteschen staatleche Servicer déi persistent Produktdaten fir Facebook, Instagram, Messenger a WhatsApp späicheren. Dëst kéinte grouss Geschäfter vu Schlësselwäertpaaren sinn (z. ) an Iwwerwaachung vun Datenrepositories (zum Beispill, и ). Staatlech Servicer z'erhalen ass net einfach, well de System muss suergen, datt d'Versuergung vu Container grouss-Skala Stéierunge widderstoen kann, dorënner Reseau Stéierungen oder Muecht Stéierungen. A wärend konventionell Techniken, wéi d'Verdeelung vu Container iwwer Feelerberäicher, gutt funktionnéieren fir stateless Servicer, brauche stateful Servicer zousätzlech Ënnerstëtzung.
Zum Beispill, wann e Serverfehler eng Datebank Replika net verfügbar mécht, sollt Dir automatesch Ënnerhalt aktivéieren déi d'Kären op 50 Serveren aus engem Pool vun 10 aktualiséieren? Hänkt vun der Situatioun of. Wann ee vun dësen 50 Serveren eng aner Replica vun der selwechter Datebank huet, ass et besser ze waarden an net 2 Repliken op eemol ze verléieren. Fir dynamesch Entscheedungen iwwer Systemerhaltung a Leeschtung ze treffen, brauche mir Informatioun iwwer intern Datereplikatioun an d'Placementlogik vun all staatleche Service.
D'TaskControl Interface erlaabt statesch Servicer fir Entscheedungen ze beaflossen déi d'Disponibilitéit beaflossen. Mat dësem Interface informéiert de Scheduler extern Uwendungen iwwer Containeroperatiounen (Neistart, Update, Migratioun, Ënnerhalt). E staatleche Service implementéiert e Controller deen Tupperware seet wann et sécher ass fir all Operatioun auszeféieren, an dës Operatiounen kënnen temporär gewiesselt oder verspéit ginn. Am Beispill hei uewen kann den Datebank Controller Tupperware soen fir 49 vun den 50 Serveren ze aktualiséieren, awer e spezifesche Server (X) eleng fir de Moment. Als Resultat, wann d'Kernel Update Period passéiert an d'Datebank nach ëmmer net fäeg ass déi problematesch Replika ze restauréieren, wäert Tupperware ëmmer nach den X Server aktualiséieren.
Vill staatlech Servicer an Tupperware benotzen TaskControl net direkt, mee duerch ShardManager, eng gemeinsam Plattform fir statesch Servicer op Facebook ze kreéieren. Mat Tupperware kënnen d'Entwéckler hir Intent spezifizéieren fir genau wéi Container iwwer Datenzenteren verdeelt solle ginn. Mat ShardManager spezifizéieren d'Entwéckler hir Intent fir wéi d'Datescheren iwwer Container verdeelt solle ginn. ShardManager ass bewosst iwwer d'Dateplacement an d'Replikatioun vu sengen Uwendungen a kommunizéiert mat Tupperware iwwer d'TaskControl Interface fir Container Operatiounen ze plangen ouni direkt Uwendungsbedeelegung. Dës Integratioun vereinfacht immens d'Gestioun vu staatleche Servicer, awer TaskControl ass fäeg fir méi. Zum Beispill, eis extensiv Web Tier ass stateless a benotzt TaskControl fir dynamesch den Taux vun Aktualiséierungen op Container unzepassen. Eventuell pro Dag ouni Kompromëss Disponibilitéit.
Verwalte Serveren an Datenzenteren
Wann Tupperware fir d'éischt am 2011 gestart gouf, gouf all Servercluster vun engem separaten Scheduler geréiert. Deemools war e Facebook-Cluster eng Grupp vu Serverracks, déi mat engem Netzwierkschalter verbonne sinn, an den Datenzenter huet e puer Cluster ënnerbruecht. De Scheduler konnt nëmmen Serveren an engem Cluster verwalten, dat heescht datt d'Aarbecht net iwwer verschidde Cluster verbreet konnt. Eis Infrastruktur ass gewuess, mir hunn ëmmer méi Cluster ofgeschriwwen. Zënter datt Tupperware d'Aarbecht vum ofgebaute Cluster net ouni Ännerungen an aner Cluster konnt réckelen, huet et vill Effort a virsiichteg Koordinatioun tëscht Applikatiounsentwéckler an Datenzenterbetreiber erfuerdert. Dëse Prozess huet zu verschwendene Ressourcen gefouert wann d'Servere fir Méint idle waren wéinst Ofbauprozeduren.
Mir hunn e Ressource Broker erstallt fir de Cluster Decommissioning Problem ze léisen an aner Aarte vun Ënnerhaltsaufgaben ze koordinéieren. De Ressource Broker hält all déi kierperlech Informatioun, déi mat engem Server assoziéiert ass, an entscheet dynamesch wéi ee Scheduler all Server kontrolléiert. Dynamesch Verknëppung vu Servere mat Scheduler erlaabt dem Scheduler Serveren a verschiddenen Datenzenteren ze verwalten. Zënter datt en Tupperware Job net méi op en eenzege Stärekoup limitéiert ass, kënnen Tupperware Benotzer spezifizéieren wéi Container iwwer Feelerdomänen verdeelt solle ginn. Zum Beispill kann en Entwéckler seng Absicht deklaréieren (soen: "Fuer meng Aarbecht op 2 Feeler Domainen an der PRN Regioun") ouni spezifesch Disponibilitéitszonen ze spezifizéieren. Tupperware selwer fënnt gëeegent Serveren fir dës Absicht ëmzesetzen, och wann de Cluster oder de Service ofgebaut gëtt.
Skalierbar fir de ganze globale System z'ënnerstëtzen
Historesch ass eis Infrastruktur an Honnerte vun dedizéierten Serverpools fir eenzel Teams opgedeelt. Wéinst Fragmentatioun a Mangel u Standarden hate mir héich Operatiounskäschte, an Idle Server ware méi schwéier erëm ze benotzen. Op der Konferenz vum leschte Joer mir presentéiert , déi eis Infrastruktur an e groussen eenzege Serverpark solle verbannen. Mä een eenzege Server Park huet seng eege Schwieregkeeten. Et muss bestëmmte Viraussetzunge treffen:
- Skalierbarkeet. Eis Infrastruktur ass gewuess wéi mir Datenzenteren an all Regioun bäigefüügt hunn. Servere si méi kleng a méi energieeffizient ginn, sou datt et vill méi vun hinnen an all Regioun sinn. Als Resultat kann een eenzege Scheduler pro Regioun d'Zuel vun de Container net handhaben, déi op Honnerte vun Dausende vu Serveren an all Regioun lafen kënnen.
- Zuverlässegkeet Och wann de Scheduler esou vill opgeschrauft ka ginn, heescht de groussen Ëmfang vum Scheduler datt et e méi héije Risiko vu Feeler ass an eng ganz Regioun vu Container kann onmanéierbar ginn.
- Feeler Toleranz. Am Fall vun engem riesegen Infrastrukturfehler (zum Beispill d'Server, déi de Scheduler lafen, versoen wéinst engem Netzwierkausfall oder Stroumausfall), sollten déi negativ Konsequenzen nëmmen en Deel vun de Serveren an der Regioun beaflossen.
- Einfach ze benotzen. Et kann schéngen datt Dir e puer onofhängeg Scheduler fir eng Regioun muss lafen. Awer aus enger Komfortperspektive mécht en eenzegen Entrée an de gemeinsame Pool vun enger Regioun et méi einfach d'Kapazitéit an d'Aarbechtsplazen ze managen.
Mir hunn de Scheduler opgedeelt fir d'Problemer ze léisen fir e grousse gemeinsame Pool z'erhalen. All Stonneplang Shard geréiert seng eege Formatioun vun Aarbechtsplazen an der Regioun, an dëst reduzéiert de Risiko verbonne mat der Zäitplang. Wéi de gemeinsame Pool wiisst, kënne mir méi Scheduler Schnëtt addéieren. Fir Tupperware Benotzer, Shards an Scheduler Proxy kucken wéi eng Kontrollpanel. Si mussen net mat enger Rëtsch Schnëtt schaffen, déi Aufgaben orchestréieren. Scheduler Shards sinn grondsätzlech anescht wéi de Cluster Scheduler déi mir virdru benotzt hunn, wann d'Kontrollpanel opgedeelt gouf ouni statesch de gemeinsame Pool vu Serveren no der Netzwierktopologie opzedeelen.
Verbessert d'Benotzungseffizienz mat elastesche Rechen
Wat méi grouss eis Infrastruktur ass, dest méi wichteg ass et eis Serveren effizient ze benotzen fir d'Infrastrukturkäschten ze optimiséieren an d'Laascht ze reduzéieren. Et ginn zwou Weeër fir d'Effizienz vum Serververbrauch ze erhéijen:
- Elastesch Rechenzäit - Skala erof online Servicer während roueg Stonnen a benotzt befreit Serveren fir offline Aarbechtslaaschten, sou wéi Maschinnléieren a MapReduce Aarbechtsplazen.
- Iwwerbelaaschtung - Plaz Online Servicer a Batch Aarbechtslaascht op déiselwecht Serveren, sou datt Batch Aarbechtslaascht mat niddereger Prioritéit lafen.
De Flaschenhals an eisen Datenzenteren ass . Dofir léiwer mir kleng, energieeffizient Serveren déi zesummen méi Veraarbechtungskraaft ubidden. Leider, op klenge Serveren mat wéineg CPU an Erënnerung, Iwwerlaascht ass manner effektiv. Natierlech kënne mir e puer Container vu klenge Servicer op engem klengen energieeffizienten Server setzen, dee wéineg Prozessorressourcen an Erënnerung verbrauchen, awer grouss Servicer wäerten an dëser Situatioun niddereg Leeschtung hunn. Dofir rode mir Entwéckler vun eise grousse Servicer fir se ze optimiséieren sou datt se ganz Server benotzen.
Prinzipiell verbesseren mir d'Benotzungseffizienz mat elastesche Rechen. Vill vun eise grousse Servicer, wéi d'News Feed, Messagerie Feature, a Front-End Web Tier, variéieren jee no der Zäit vum Dag. Mir Skala bewosst online Servicer während roueg Stonnen erof a benotzen fräi Serveren fir offline Aarbechtslaascht, wéi Maschinn Léieren a MapReduce Aarbechtsplazen.
Mir wëssen aus Erfahrung datt et am beschten ass fir ganz Serveren als Eenheeten vun der elastescher Kapazitéit ze bidden, well grouss Servicer souwuel grouss Donateuren wéi och grouss Konsumenten vun der elastescher Kapazitéit sinn a optimiséiert sinn fir ganz Serveren ze benotzen. Wann de Server aus dem Online-Service während rouege Stonnen fräigelooss gëtt, leet de Ressourcebroker de Server un de Scheduler fir offline Aarbechtslaascht drop ze lafen. Wann den Online-Service eng Spëtzbelaaschtung erliewt, erënnert de Ressourcebroker séier un de geléinte Server an, zesumme mam Scheduler, bréngt en an den Online-Service zréck.
Lektioune geléiert a Pläng fir d'Zukunft
An de leschten 8 Joer hu mir Tupperware entwéckelt fir mat dem schnelle Wuesstum vu Facebook ze halen. Mir deelen wat mir geléiert hunn an hoffen et hëlleft anerer séier wuessend Infrastrukturen ze managen:
- Setzt eng flexibel Verbindung tëscht der Kontrollpanel an de Serveren déi se geréiert. Dës Flexibilitéit erlaabt d'Kontrollpanel fir Serveren a verschiddenen Rechenzentren ze verwalten, hëlleft den Ofbau an den Ënnerhalt vu Cluster ze automatiséieren an erméiglecht eng dynamesch Kapazitéitsallokatioun mat elastesche Rechen.
- Mat enger eenzeger Kontrollpanel an der Regioun gëtt et méi praktesch mat Aufgaben ze schaffen a méi einfach eng grouss gemeinsam Serverflott ze managen. Bedenkt datt d'Kontrollpanel en eenzegen Entréespunkt behält, och wann seng intern Struktur aus Skala- oder Fehltoleranzgrënn getrennt ass.
- Mat engem Plugin-Modell kann d'Kontrollpanel extern Uwendunge vun zukünfteg Containeroperatiounen informéieren. Ausserdeem kënne statesch Servicer d'Plugin-Interface benotze fir d'Containermanagement ze personaliséieren. Mat dësem Plugin Modell bitt d'Kontrollpanel Einfachheet wärend effizient vill verschidde staatlech Servicer servéiert.
- Mir gleewen datt elastesch Informatik, wou mir ganz Serveren aus Spenderservicer fir Batchjobs, Maschinnléieren an aner net-dréngend Servicer huelen, den optimale Wee ass fir d'Effizienz vu klengen, energieeffizienten Serveren ze verbesseren.
Mir fänken just ëmzesetzen . De Moment sinn ongeféier 20% vun eise Serveren an engem gemeinsame Pool. Fir 100% z'erreechen, musse vill Themen ugeschwat ginn, dorënner d'Erhalen vun engem gemeinsame Späicherpool, d'Automatiséierung vum Ënnerhalt, d'Gestioun vu Cross-Tenant Ufuerderunge, d'Verbesserung vun der Servernotzung, an d'Verbesserung vun der Ënnerstëtzung fir d'Maschinn Léieren Aarbechtslaascht. Mir kënnen net waarden fir dës Erausfuerderungen unzehuelen an eis Erfolleger ze deelen.
Source: will.com