Effektiv og pålidelig styring af klynger i enhver skala med Tupperware
I dag på vi introducerede Tupperware, vores klyngestyringssystem, der orkestrerer containere på tværs af millioner af servere, der kører næsten alle vores tjenester. Vi implementerede Tupperware første gang i 2011, og siden da er vores infrastruktur vokset fra op til helhed . Hele denne tid stod Tupperware ikke stille og udviklede sig sammen med os. Vi viser dig, hvordan Tupperware leverer førsteklasses klyngestyring, herunder praktisk support til stateful services, et enkelt kontrolpanel til alle datacentre og muligheden for at fordele kapacitet mellem tjenester i realtid. Vi deler også de erfaringer, vi har lært, efterhånden som vores infrastruktur udvikler sig.
Tupperware udfører forskellige opgaver. Applikationsudviklere bruger det til at levere og administrere applikationer. Det pakker applikationskoden og afhængigheder i et billede og leverer det til servere som containere. Containere giver isolering mellem applikationer på den samme server, så udviklere håndtere applikationslogikken og ikke behøver at bekymre sig om at finde servere eller administrere opdateringer. Tupperware overvåger også serverens ydeevne, og hvis den finder en fejl, overfører den containere fra den problematiske server.
Kapacitetsplanlægningsingeniører bruger Tupperware til at allokere serverkapacitet til teams baseret på budget og begrænsninger. De bruger det også til at forbedre serverudnyttelsen. Datacenteroperatører henvender sig til Tupperware for at distribuere containere korrekt på tværs af datacentre og stoppe eller flytte containere under vedligeholdelse. Takket være dette kræver vedligeholdelse af servere, netværk og udstyr minimal menneskelig indgriben.
Tupperware arkitektur
Tupperware PRN-arkitektur er en af regionerne i vores datacentre. Regionen består af flere datacenterbygninger (PRN1 og PRN2) beliggende i nærheden. Vi planlægger at lave ét kontrolpanel, der skal administrere alle servere i én region.
Applikationsudviklere leverer tjenester i form af Tupperware-job. Et job består af flere containere, og de kører typisk alle den samme applikationskode.
Tupperware er ansvarlig for at klargøre containere og administrere deres livscyklus. Den består af flere komponenter:
- Tupperware-frontenden giver API'er til brugergrænsefladen, CLI og andre automatiseringsværktøjer, hvorigennem du kan interagere med Tupperware. De skjuler hele den interne struktur for Tupperware jobejere.
- Tupperware Scheduler er et kontrolpanel, der er ansvarlig for at styre containerens og joblivscyklussen. Det er implementeret på regionalt og globalt niveau, hvor den regionale planlægger administrerer servere i én region, og den globale planlægger administrerer servere fra forskellige regioner. Planlæggeren er opdelt i shards, og hver shard administrerer et sæt job.
- Tupperwares Scheduler Proxy skjuler den interne skæring og giver en praktisk enkelt rude til Tupperware-brugere.
- Tupperware-allokatoren tildeler containere til servere. Planlæggeren håndterer stop, start, opdatering og failover af containere. I øjeblikket kan én tildeler administrere hele regionen uden at opdele i skår. (Bemærk forskellen i terminologi. For eksempel svarer planlæggeren i Tupperware til kontrolpanelet i , og Tupperware-allokatoren kaldes en skemalægger i Kubernetes.)
- Ressourcemægleren gemmer kilden til sandhed for server- og servicebegivenheder. Vi driver én ressourcemægler for hvert datacenter, og det gemmer al information om serverne i det pågældende datacenter. Ressourcemægleren og kapacitetsstyringssystemet eller ressourceforsyningssystemet bestemmer dynamisk, hvilken planlæggerlevering, der styrer hvilken server. Sundhedstjektjenesten overvåger servere og gemmer data om deres helbred i ressourcemægleren. Hvis en server har problemer eller har brug for vedligeholdelse, fortæller ressourcemægleren allokatoren og planlæggeren om at stoppe containerne eller flytte dem til andre servere.
- Tupperware-agenten er en dæmon, der kører på hver server, og som håndterer klargøring og fjernelse af containere. Applikationer kører inde i en container, hvilket giver dem mere isolation og reproducerbarhed. På Vi har allerede beskrevet, hvordan individuelle Tupperware-containere oprettes ved hjælp af billeder, btrfs, cgroupv2 og systemd.
Karakteristiske træk ved Tupperware
Tupperware ligner på mange måder andre klyngestyringssystemer såsom Kubernetes og , men der er også forskelle:
- Indbygget support til stateful services.
- Et enkelt kontrolpanel til servere i forskellige datacentre til at automatisere leveringen af containere baseret på hensigt, nedlukning af klynger og vedligeholdelse.
- Tydelig opdeling af kontrolpanelet til zoom.
- Elastisk databehandling giver dig mulighed for at fordele strøm mellem tjenester i realtid.
Vi udviklede disse fede funktioner til at understøtte en række statsløse og stateful applikationer på tværs af en enorm global delt serverflåde.
Indbygget support til stateful services.
Tupperware driver en række kritiske stateful-tjenester, der gemmer vedvarende produktdata til Facebook, Instagram, Messenger og WhatsApp. Disse kunne være store lagre af nøgleværdi-par (f.eks. ) og overvågning af datalagre (f.eks. и ). At vedligeholde stateful services er ikke let, for systemet skal sikre, at forsyningen af containere kan modstå storstilede forstyrrelser, herunder netafbrydelser eller strømafbrydelser. Og mens konventionelle teknikker, såsom distribution af containere på tværs af fejldomæner, fungerer godt for statsløse tjenester, har stateful-tjenester brug for yderligere support.
Hvis en serverfejl f.eks. gør en databasereplika utilgængelig, skal du så aktivere automatisk vedligeholdelse, der opdaterer kernerne på 50 servere fra en pulje på 10? Afhænger af situationen. Hvis en af disse 50 servere har en anden replika af den samme database, er det bedre at vente og ikke miste 2 replikaer på én gang. For dynamisk at træffe beslutninger om systemvedligeholdelse og ydeevne har vi brug for information om intern datareplikering og placeringslogikken for hver stateful service.
TaskControl-grænsefladen giver stateful services mulighed for at påvirke beslutninger, der påvirker datatilgængeligheden. Ved hjælp af denne grænseflade giver skemalæggeren besked til eksterne applikationer om containeroperationer (genstart, opdatering, migrering, vedligeholdelse). En stateful service implementerer en controller, der fortæller Tupperware, hvornår det er sikkert at udføre hver operation, og disse operationer kan udskiftes eller forsinkes midlertidigt. I eksemplet ovenfor kunne databasecontrolleren fortælle Tupperware at opdatere 49 af de 50 servere, men lade en bestemt server (X) være i fred indtil videre. Som et resultat, hvis kerneopdateringsperioden går, og databasen stadig ikke er i stand til at gendanne den problematiske replika, vil Tupperware stadig opdatere X-serveren.
Mange stateful tjenester i Tupperware bruger TaskControl ikke direkte, men gennem ShardManager, en fælles platform til at skabe stateful tjenester på Facebook. Med Tupperware kan udviklere specificere deres hensigt med præcis, hvordan containere skal fordeles på tværs af datacentre. Med ShardManager specificerer udviklere deres hensigt med, hvordan datashards skal fordeles på tværs af containere. ShardManager er opmærksom på dataplacering og replikering af dets applikationer og kommunikerer med Tupperware gennem TaskControl-grænsefladen for at planlægge containeroperationer uden direkte applikationsinvolvering. Denne integration forenkler i høj grad administrationen af stateful services, men TaskControl er i stand til mere. For eksempel er vores omfattende web-tier statsløs og bruger TaskControl til dynamisk at justere hastigheden af opdateringer til containere. Til sidst om dagen uden at gå på kompromis med tilgængeligheden.
Håndtering af servere i datacentre
Da Tupperware først blev lanceret i 2011, blev hver serverklynge administreret af en separat planlægger. Dengang var en Facebook-klynge en gruppe serverracks forbundet til én netværksswitch, og datacentret husede flere klynger. Planlæggeren kunne kun administrere servere i én klynge, hvilket betyder, at jobbet ikke kunne spredes på tværs af flere klynger. Vores infrastruktur voksede, vi afskrev i stigende grad klynger. Da Tupperware ikke kunne flytte jobbet fra den nedlagte klynge til andre klynger uden ændringer, krævede det en stor indsats og omhyggelig koordinering mellem applikationsudviklere og datacenteroperatører. Denne proces resulterede i spildte ressourcer, når servere var inaktive i flere måneder på grund af nedlukningsprocedurer.
Vi oprettede en ressourcemægler til at løse klyngedekommissioneringsproblemet og koordinere andre typer vedligeholdelsesopgaver. Ressourcemægleren holder styr på al den fysiske information, der er knyttet til en server, og bestemmer dynamisk, hvilken planlægger, der styrer hver server. Dynamisk kobling af servere til planlæggere gør det muligt for planlæggeren at administrere servere i forskellige datacentre. Da et Tupperware-job ikke længere er begrænset til en enkelt klynge, kan Tupperware-brugere angive, hvordan containere skal fordeles på tværs af fejldomæner. For eksempel kan en udvikler erklære sin hensigt (sige: "kør mit job på 2 fejldomæner i PRN-regionen") uden at angive specifikke tilgængelighedszoner. Tupperware vil selv finde passende servere til at implementere denne hensigt, selvom klyngen eller tjenesten er nedlagt.
Skalerbar til at understøtte hele det globale system
Historisk set er vores infrastruktur blevet opdelt i hundredvis af dedikerede serverpuljer til individuelle teams. På grund af fragmentering og mangel på standarder havde vi høje driftsomkostninger, og inaktive servere var sværere at bruge igen. Ved sidste års konference vi præsenterede , som skal forene vores infrastruktur til en stor enkelt serverpark. Men en enkelt serverpark har sine egne vanskeligheder. Det skal opfylde visse krav:
- Skalerbarhed. Vores infrastruktur voksede, efterhånden som vi tilføjede datacentre i hver region. Servere er blevet mindre og mere energieffektive, så der er mange flere af dem i hver region. Som følge heraf kan en enkelt skemalægger pr. region ikke håndtere antallet af containere, der kan køres på hundredtusindvis af servere i hver region.
- Pålidelighed. Selvom planlæggeren kan skaleres så meget op, betyder det store omfang af planlæggeren, at der er en højere risiko for fejl, og en hel region af containere kan blive uoverskuelig.
- Fejltolerance. I tilfælde af et stort infrastruktursvigt (f.eks. fejler de servere, der kører planlæggeren, på grund af et netværkssvigt eller strømafbrydelse), bør de negative konsekvenser kun påvirke en del af serverne i regionen.
- Brugervenlighed. Det kan se ud til, at du skal køre flere uafhængige planlæggere for én region. Men fra et bekvemmelighedsperspektiv gør et enkelt indgangspunkt til en regions fælles pulje det nemmere at administrere kapacitet og arbejdspladser.
Vi delte planlæggeren op i shards for at løse problemerne med at opretholde en stor fælles pulje. Hvert planlægger-shard administrerer sit eget sæt af job i regionen, og dette reducerer risikoen forbundet med planlæggeren. Efterhånden som den delte pulje vokser, kan vi tilføje flere planlægningsskår. For Tupperware-brugere ser shards og planlægningsproxyer ud som ét kontrolpanel. De behøver ikke at arbejde med en masse skår, der orkestrerer opgaver. Scheduler shards er fundamentalt forskellige fra de klyngeplanlæggere, vi brugte før, da kontrolpanelet blev partitioneret uden statisk at opdele den delte pulje af servere i henhold til netværkstopologien.
Forbedre brugseffektiviteten med Elastic Computing
Jo større vores infrastruktur er, jo vigtigere er det at bruge vores servere effektivt til at optimere infrastrukturomkostningerne og reducere belastningen. Der er to måder at øge effektiviteten af serverbrug på:
- Elastisk computing - nedskaler onlinetjenester i stille timer, og brug frigivne servere til offline arbejdsbelastninger, såsom maskinlæring og MapReduce-job.
- Overbelastning - Placer onlinetjenester og batch-arbejdsbelastninger på de samme servere, så batch-arbejdsbelastninger kører med lav prioritet.
Flaskehalsen i vores datacentre er . Derfor foretrækker vi små, energieffektive servere, der tilsammen giver mere processorkraft. Desværre er overbelastning mindre effektivt på små servere med lidt CPU og hukommelse. Selvfølgelig kan vi placere flere beholdere med små tjenester på en lille energieffektiv server, der bruger få processorressourcer og hukommelse, men store tjenester vil have lav ydeevne i denne situation. Derfor råder vi udviklerne af vores store tjenester til at optimere dem, så de bruger hele serverne.
Grundlæggende forbedrer vi brugseffektiviteten ved hjælp af elastisk databehandling. Mange af vores store tjenester, såsom nyhedsfeed, beskedfunktion og front-end web-tier, varierer afhængigt af tidspunktet på dagen. Vi nedskalerer bevidst onlinetjenester i stille timer og bruger frigivne servere til offline arbejdsbelastninger, såsom maskinlæring og MapReduce-job.
Vi ved af erfaring, at det er bedst at levere hele servere som enheder af elastisk kapacitet, fordi store tjenester både er store donorer og storforbrugere af elastisk kapacitet og er optimeret til at bruge hele servere. Når serveren frigives fra onlinetjenesten i stille timer, leaser ressourcemægleren serveren til planlæggeren for at køre offline arbejdsbelastninger på den. Hvis onlinetjenesten oplever en spidsbelastning, tilbagekalder ressourcemægleren hurtigt den lånte server og returnerer den sammen med skemalæggeren til onlinetjenesten.
Erfaringer og planer for fremtiden
I løbet af de sidste 8 år har vi udviklet Tupperware for at følge med Facebooks hurtige vækst. Vi deler det, vi har lært, og håber, det vil hjælpe andre med at administrere hurtigt voksende infrastrukturer:
- Opret en fleksibel forbindelse mellem kontrolpanelet og de servere, det administrerer. Denne fleksibilitet gør det muligt for kontrolpanelet at administrere servere i forskellige datacentre, hjælper med at automatisere nedlukningen og vedligeholdelsen af klynger og muliggør dynamisk kapacitetsallokering ved hjælp af elastisk databehandling.
- Med et enkelt kontrolpanel i regionen bliver det mere bekvemt at arbejde med opgaver og nemmere at administrere en stor delt serverflåde. Bemærk, at kontrolpanelet opretholder et enkelt indgangspunkt, selvom dets interne struktur er adskilt af hensyn til skala eller fejltolerance.
- Ved hjælp af en plugin-model kan kontrolpanelet underrette eksterne applikationer om kommende containeroperationer. Desuden kan stateful services bruge plugin-grænsefladen til at tilpasse containerstyring. Med denne plugin-model giver kontrolpanelet enkelhed, mens det effektivt betjener mange forskellige stateful tjenester.
- Vi mener, at elastisk computing, hvor vi fjerner hele servere fra donortjenester til batchjobs, maskinlæring og andre ikke-hastende tjenester, er den optimale måde at forbedre effektiviteten af små, energieffektive servere.
Vi er lige begyndt at implementere . I øjeblikket er omkring 20 % af vores servere i en delt pulje. For at opnå 100 % skal mange problemer løses, herunder vedligeholdelse af en delt lagerpulje, automatisering af vedligeholdelse, håndtering af krav på tværs af lejere, forbedring af serverudnyttelsen og forbedring af understøttelse af maskinlærings-arbejdsbelastninger. Vi kan ikke vente med at tage disse udfordringer op og dele vores succeser.
Kilde: www.habr.com