Effektiv och pålitlig hantering av kluster i alla skala med Tupperware
Idag på vi introducerade Tupperware, vårt klusterhanteringssystem som orkestrerar behållare över miljontals servrar som kör nästan alla våra tjänster. Vi distribuerade Tupperware första gången 2011, och sedan dess har vår infrastruktur vuxit från upp till helhet . Hela denna tid stod inte Tupperware stilla och utvecklades med oss. Vi visar dig hur Tupperware tillhandahåller förstklassig klusterhantering, inklusive bekvämt stöd för stateful tjänster, en enda kontrollpanel för alla datacenter och möjligheten att fördela kapacitet mellan tjänster i realtid. Vi kommer också att dela med oss av de lärdomar vi har lärt oss i takt med att vår infrastruktur utvecklas.
Tupperware utför olika uppgifter. Applikationsutvecklare använder det för att leverera och hantera applikationer. Den paketerar applikationskoden och beroenden till en bild och levererar den till servrar som behållare. Behållare ger isolering mellan applikationer på samma server så att utvecklare hanterar applikationslogiken och inte behöver oroa sig för att hitta servrar eller hantera uppdateringar. Tupperware övervakar även serverns prestanda, och om den upptäcker ett fel överför den behållare från den problematiska servern.
Kapacitetsplaneringsingenjörer använder Tupperware för att allokera serverkapacitet till team baserat på budget och begränsningar. De använder det också för att förbättra serveranvändningen. Datacenteroperatörer vänder sig till Tupperware för att korrekt distribuera behållare över datacenter och stoppa eller flytta behållare under underhåll. Tack vare detta kräver underhåll av servrar, nätverk och utrustning minimal mänsklig inblandning.
Tupperware arkitektur
Tupperware PRN-arkitektur är en av regionerna i våra datacenter. Regionen består av flera datacenterbyggnader (PRN1 och PRN2) belägna i närheten. Vi planerar att göra en kontrollpanel som kommer att hantera alla servrar i en region.
Applikationsutvecklare levererar tjänster i form av Tupperware-jobb. Ett jobb består av flera behållare, och alla kör vanligtvis samma programkod.
Tupperware ansvarar för att tillhandahålla containrar och hantera deras livscykel. Den består av flera komponenter:
- Tupperware-gränssnittet tillhandahåller API:er för användargränssnittet, CLI och andra automationsverktyg genom vilka du kan interagera med Tupperware. De döljer hela den interna strukturen för Tupperware-jobbägare.
- Tupperware Scheduler är en kontrollpanel som ansvarar för att hantera containerns och jobbets livscykel. Den distribueras på regional och global nivå, där den regionala schemaläggaren hanterar servrar i en region och den globala schemaläggaren hanterar servrar från olika regioner. Schemaläggaren är uppdelad i skärvor och varje skärva hanterar en uppsättning jobb.
- Tupperwares Scheduler Proxy döljer den interna skärningen och ger en bekväm enkel ruta för Tupperware-användare.
- Tupperware-allokatorn tilldelar behållare till servrar. Schemaläggaren hanterar stopp, start, uppdatering och failover av behållare. För närvarande kan en allokator hantera hela regionen utan att delas upp i skärvor. (Observera skillnaden i terminologi. Till exempel, schemaläggaren i Tupperware motsvarar kontrollpanelen i , och Tupperware-allokatorn kallas en schemaläggare i Kubernetes.)
- Resursmäklaren lagrar sanningskällan för server- och tjänstehändelser. Vi driver en resursmäklare för varje datacenter och den lagrar all information om servrarna i det datacentret. Resursmäklaren och kapacitetshanteringssystemet, eller resursförsörjningssystemet, bestämmer dynamiskt vilken schemaläggerleverans som styr vilken server. Hälsokontrolltjänsten övervakar servrar och lagrar data om deras hälsa i resursmäklaren. Om en server har problem eller behöver underhåll, säger resursmäklaren till fördelaren och schemaläggaren att stoppa behållarna eller flytta dem till andra servrar.
- Tupperware Agent är en demon som körs på varje server som förbereder och tar bort behållare. Applikationer körs inuti en behållare, vilket ger dem mer isolering och reproducerbarhet. På Vi har redan beskrivit hur enskilda Tupperware-behållare skapas med hjälp av bilder, btrfs, cgroupv2 och systemd.
Utmärkande egenskaper hos Tupperware
Tupperware liknar på många sätt andra klusterhanteringssystem som Kubernetes och , men det finns också skillnader:
- Inbyggt stöd för statliga tjänster.
- En enda kontrollpanel för servrar i olika datacenter för att automatisera leveransen av containrar baserat på avsikt, avveckling av kluster och underhåll.
- Tydlig uppdelning av kontrollpanelen för zoomning.
- Elastisk beräkning gör att du kan fördela kraften mellan tjänster i realtid.
Vi utvecklade dessa coola funktioner för att stödja en mängd olika tillståndslösa och tillståndsfulla applikationer över en enorm global delad serverflotta.
Inbyggt stöd för statliga tjänster.
Tupperware driver en mängd kritiska tillståndstjänster som lagrar beständig produktdata för Facebook, Instagram, Messenger och WhatsApp. Dessa kan vara stora lager av nyckel-värdepar (t.ex. ) och övervakning av dataförråd (till exempel, и ). Att upprätthålla statliga tjänster är inte lätt, eftersom systemet måste säkerställa att försörjningen av containrar tål storskaliga störningar, inklusive nätavbrott eller strömavbrott. Och medan konventionella tekniker, som att distribuera behållare över feldomäner, fungerar bra för tillståndslösa tjänster, behöver tillståndsbaserade tjänster ytterligare stöd.
Till exempel, om ett serverfel gör en databasreplik otillgänglig, bör du aktivera automatiskt underhåll som kommer att uppdatera kärnorna på 50 servrar från en pool på 10 50? Beror på situationen. Om en av dessa 2 servrar har en annan kopia av samma databas, är det bättre att vänta och inte förlora XNUMX repliker på en gång. För att dynamiskt kunna fatta beslut om systemunderhåll och prestanda behöver vi information om intern datareplikering och placeringslogiken för varje stateful tjänst.
TaskControl-gränssnittet tillåter tillståndsfulla tjänster att påverka beslut som påverkar datatillgängligheten. Genom att använda detta gränssnitt meddelar schemaläggaren externa applikationer om containeroperationer (omstart, uppdatering, migrering, underhåll). En stateful tjänst implementerar en styrenhet som talar om för Tupperware när det är säkert att utföra varje operation, och dessa operationer kan bytas ut eller försenas tillfälligt. I exemplet ovan kan databasstyrenheten säga till Tupperware att uppdatera 49 av de 50 servrarna, men lämna en specifik server (X) ifred tills vidare. Som ett resultat, om kärnans uppdateringsperiod passerar och databasen fortfarande inte kan återställa den problematiska repliken, kommer Tupperware fortfarande att uppdatera X-servern.
Många stateful tjänster i Tupperware använder TaskControl inte direkt, utan genom ShardManager, en gemensam plattform för att skapa stateful tjänster på Facebook. Med Tupperware kan utvecklare specificera sin avsikt för exakt hur behållare ska distribueras över datacenter. Med ShardManager specificerar utvecklare sin avsikt för hur dataskärvor ska fördelas över behållare. ShardManager är medveten om dataplacering och replikering av sina applikationer och kommunicerar med Tupperware via TaskControl-gränssnittet för att schemalägga containeroperationer utan direkt applikationsinblandning. Denna integration förenklar avsevärt hanteringen av statliga tjänster, men TaskControl kan mer. Till exempel är vår omfattande webbnivå tillståndslös och använder TaskControl för att dynamiskt justera hastigheten för uppdateringar av behållare. Så småningom per dag utan att kompromissa med tillgängligheten.
Hantera servrar i datacenter
När Tupperware först lanserades 2011, hanterades varje serverkluster av en separat schemaläggare. Då var ett Facebook-kluster en grupp serverrack kopplade till en nätverksswitch, och datacentret inhyste flera kluster. Schemaläggaren kunde bara hantera servrar i ett kluster, vilket innebär att jobbet inte kunde spridas över flera kluster. Vår infrastruktur växte, vi skrev allt mer av kluster. Eftersom Tupperware inte kunde flytta jobbet från det nedlagda klustret till andra kluster utan förändringar krävde det mycket ansträngning och noggrann koordinering mellan applikationsutvecklare och datacenteroperatörer. Denna process resulterade i slöseri med resurser när servrar var inaktiva i månader på grund av avvecklingsprocedurer.
Vi skapade en resursmäklare för att lösa klusteravvecklingsproblemet och samordna andra typer av underhållsuppgifter. Resursmäklaren håller reda på all fysisk information som är associerad med en server och bestämmer dynamiskt vilken schemaläggare som styr varje server. Genom att dynamiskt länka servrar till schemaläggare kan schemaläggaren hantera servrar i olika datacenter. Eftersom ett Tupperware-jobb inte längre är begränsat till ett enda kluster kan Tupperware-användare specificera hur behållare ska fördelas över feldomäner. Till exempel kan en utvecklare deklarera sin avsikt (säg: "kör mitt jobb på 2 feldomäner i PRN-regionen") utan att ange specifika tillgänglighetszoner. Tupperware kommer själv att hitta lämpliga servrar för att implementera denna avsikt, även om klustret eller tjänsten tas ur drift.
Skalbar för att stödja hela det globala systemet
Historiskt sett har vår infrastruktur delats upp i hundratals dedikerade serverpooler för individuella team. På grund av fragmentering och brist på standarder hade vi höga driftskostnader och inaktiva servrar var svårare att använda igen. På förra årets konferens vi presenterade , som borde förena vår infrastruktur till en stor enda serverpark. Men en enda serverpark har sina egna svårigheter. Det måste uppfylla vissa krav:
- Skalbarhet. Vår infrastruktur växte i takt med att vi lade till datacenter i varje region. Servrarna har blivit mindre och mer energieffektiva, så det finns många fler av dem i varje region. Som ett resultat kan en enda schemaläggare per region inte hantera antalet behållare som kan köras på hundratusentals servrar i varje region.
- Tillförlitlighet. Även om schemaläggaren kan skalas upp så mycket, betyder den stora omfattningen av schemaläggaren att det finns en högre risk för fel och en hel region av behållare kan bli ohanterlig.
- Feltolerans. I händelse av ett stort infrastrukturfel (till exempel om servrarna som kör schemaläggaren misslyckas på grund av ett nätverksfel eller strömavbrott), bör de negativa konsekvenserna påverka endast en del av servrarna i regionen.
- Användarvänlighet. Det kan tyckas att du behöver köra flera oberoende schemaläggare för en region. Men ur ett bekvämlighetsperspektiv gör en enda ingång till en regions gemensamma pool det lättare att hantera kapacitet och jobb.
Vi delade upp schemaläggaren i skärvor för att lösa problemen med att upprätthålla en stor delad pool. Varje schemaläggare hanterar sin egen uppsättning jobb i regionen, och detta minskar risken förknippad med schemaläggaren. När den delade poolen växer kan vi lägga till fler schemaläggare. För Tupperware-användare ser shards och schemaläggare ut som en kontrollpanel. De behöver inte arbeta med ett gäng skärvor som orkestrerar uppgifter. Schemaläggarskärvor skiljer sig fundamentalt från de klusterschemaläggare vi använde tidigare, när kontrollpanelen var partitionerad utan att statiskt dela upp den delade poolen av servrar enligt nätverkstopologin.
Förbättra användningseffektiviteten med Elastic Computing
Ju större infrastruktur vi har, desto viktigare är det att använda våra servrar effektivt för att optimera infrastrukturkostnaderna och minska belastningen. Det finns två sätt att öka effektiviteten i serveranvändningen:
- Elastisk datoranvändning – skala ner onlinetjänster under tysta timmar och använd frigjorda servrar för offline-arbetsbelastningar, såsom maskininlärning och MapReduce-jobb.
- Överbelastning - Placera onlinetjänster och batch-arbetsbelastningar på samma servrar så att batch-arbetsbelastningar körs med låg prioritet.
Flaskhalsen i våra datacenter är . Därför föredrar vi små, energieffektiva servrar som tillsammans ger mer processorkraft. Tyvärr är överbelastning mindre effektivt på små servrar med lite CPU och minne. Naturligtvis kan vi placera flera behållare med små tjänster på en liten energieffektiv server som förbrukar lite processorresurser och minne, men stora tjänster kommer att ha låg prestanda i denna situation. Därför råder vi utvecklare av våra stora tjänster att optimera dem så att de använder hela servrar.
I grund och botten förbättrar vi användningseffektiviteten med hjälp av elastisk beräkning. Många av våra stora tjänster, som nyhetsflödet, meddelandefunktionen och front-end webbnivån, varierar beroende på tid på dygnet. Vi skalar avsiktligt ner onlinetjänster under tysta timmar och använder frigjorda servrar för offline-arbetsbelastningar, såsom maskininlärning och MapReduce-jobb.
Vi vet av erfarenhet att det är bäst att tillhandahålla hela servrar som enheter av elastisk kapacitet eftersom stora tjänster är både stora givare och stora konsumenter av elastisk kapacitet, och är optimerade för att använda hela servrar. När servern släpps från onlinetjänsten under tysta timmar, hyr resursmäklaren ut servern till schemaläggaren för att köra offline-arbetsbelastningar på den. Om onlinetjänsten upplever en toppbelastning, återkallar resursmäklaren snabbt den lånade servern och, tillsammans med schemaläggaren, returnerar den till onlinetjänsten.
Lärdomar och planer för framtiden
Under de senaste 8 åren har vi utvecklat Tupperware för att hålla jämna steg med Facebooks snabba tillväxt. Vi delar med oss av vad vi har lärt oss och hoppas att det kommer att hjälpa andra att hantera snabbt växande infrastrukturer:
- Skapa en flexibel anslutning mellan kontrollpanelen och de servrar som den hanterar. Denna flexibilitet gör att kontrollpanelen kan hantera servrar i olika datacenter, hjälper till att automatisera avvecklingen och underhållet av kluster och möjliggör dynamisk kapacitetstilldelning med hjälp av elastisk beräkning.
- Med en enda kontrollpanel i regionen blir det bekvämare att arbeta med uppgifter och lättare att hantera en stor delad serverflotta. Observera att kontrollpanelen har en enda ingångspunkt, även om dess inre struktur är separerad på grund av skala eller feltolerans.
- Med hjälp av en plugin-modell kan kontrollpanelen meddela externa applikationer om kommande containeroperationer. Dessutom kan stateful tjänster använda plugin-gränssnittet för att anpassa containerhantering. Med denna plugin-modell ger kontrollpanelen enkelhet samtidigt som den effektivt betjänar många olika stateful tjänster.
- Vi tror att elastisk datoranvändning, där vi tar bort hela servrar från givartjänster för batchjobb, maskininlärning och andra icke-brådskande tjänster, är det optimala sättet att förbättra effektiviteten hos små, energieffektiva servrar.
Vi har precis börjat genomföra . För närvarande är cirka 20 % av våra servrar i en delad pool. För att uppnå 100 % måste många problem åtgärdas, inklusive underhåll av en delad lagringspool, automatisering av underhåll, hantering av krav för flera hyresgäster, förbättrad serveranvändning och förbättrat stöd för maskininlärningsarbetsbelastningar. Vi kan inte vänta med att ta oss an dessa utmaningar och dela våra framgångar.
Källa: will.com