Effektiv og pålitelig styring av klynger i alle skalaer med Tupperware
I dag vi introduserte Tupperware, vårt klyngeadministrasjonssystem som orkestrerer containere på tvers av millioner av servere som kjører nesten alle tjenestene våre. Vi implementerte Tupperware første gang i 2011, og siden den gang har infrastrukturen vår vokst fra opp til hele . Hele denne tiden sto ikke Tupperware stille og utviklet seg sammen med oss. Vi viser deg hvordan Tupperware gir førsteklasses klyngeadministrasjon, inkludert praktisk støtte for stateful tjenester, ett enkelt kontrollpanel for alle datasentre, og muligheten til å distribuere kapasitet mellom tjenester i sanntid. Vi vil også dele leksjonene vi har lært etter hvert som infrastrukturen vår utvikler seg.
Tupperware utfører forskjellige oppgaver. Applikasjonsutviklere bruker den til å levere og administrere applikasjoner. Den pakker applikasjonskoden og avhengighetene inn i et bilde og leverer det til servere som containere. Containere gir isolasjon mellom applikasjoner på samme server, slik at utviklere håndtere applikasjonslogikken og ikke trenger å bekymre seg for å finne servere eller administrere oppdateringer. Tupperware overvåker også ytelsen til serveren, og hvis den finner en feil, overfører den containere fra den problematiske serveren.
Kapasitetsplanleggingsingeniører bruker Tupperware til å tildele serverkapasitet til team basert på budsjett og begrensninger. De bruker det også til å forbedre serverutnyttelsen. Datasenteroperatører henvender seg til Tupperware for å distribuere containere riktig på tvers av datasentre og stoppe eller flytte containere under vedlikehold. Takket være dette krever vedlikehold av servere, nettverk og utstyr minimal menneskelig innblanding.
Tupperware-arkitektur
Tupperware PRN-arkitektur er en av regionene i datasentrene våre. Regionen består av flere datasenterbygg (PRN1 og PRN2) som ligger i nærheten. Vi planlegger å lage ett kontrollpanel som skal administrere alle servere i én region.
Applikasjonsutviklere leverer tjenester i form av Tupperware-jobber. En jobb består av flere beholdere, og de kjører vanligvis den samme applikasjonskoden.
Tupperware er ansvarlig for å klargjøre containere og administrere deres livssyklus. Den består av flere komponenter:
- Tupperware-grensesnittet gir APIer for brukergrensesnittet, CLI og andre automatiseringsverktøy som du kan samhandle med Tupperware gjennom. De skjuler hele den interne strukturen for Tupperware-jobbeiere.
- Tupperware Scheduler er et kontrollpanel som er ansvarlig for å administrere beholderens og jobbens livssyklus. Den er distribuert på regionalt og globalt nivå, der den regionale planleggeren administrerer servere i én region og den globale planleggeren administrerer servere fra forskjellige regioner. Planleggeren er delt inn i shards, og hvert shard administrerer et sett med jobber.
- Tupperwares Scheduler Proxy skjuler den interne skjæringen og gir en praktisk enkelt glassrute for Tupperware-brukere.
- Tupperware-allokatoren tildeler beholdere til servere. Planleggeren håndterer stopp, start, oppdatering og failover av containere. Foreløpig kan én tildeler administrere hele regionen uten å dele seg i skjær. (Merk forskjellen i terminologi. For eksempel tilsvarer planleggeren i Tupperware kontrollpanelet i , og Tupperware-allokatoren kalles en planlegger i Kubernetes.)
- Ressursmegleren lagrer sannhetskilden for server- og tjenestehendelser. Vi driver én ressursmegler for hvert datasenter, og den lagrer all informasjon om serverne i det datasenteret. Ressursmegleren og kapasitetsstyringssystemet, eller ressursforsyningssystemet, bestemmer dynamisk hvilken planleggingslevering som kontrollerer hvilken server. Helsesjekktjenesten overvåker servere og lagrer data om deres helse i ressursmegleren. Hvis en server har problemer eller trenger vedlikehold, ber ressursmegleren allokatoren og planleggeren om å stoppe beholderne eller flytte dem til andre servere.
- Tupperware Agent er en demon som kjører på hver server som håndterer klargjøring og fjerning av containere. Applikasjoner kjører inne i en beholder, noe som gir dem mer isolasjon og reproduserbarhet. På Vi har allerede beskrevet hvordan individuelle Tupperware-beholdere lages ved hjelp av bilder, btrfs, cgroupv2 og systemd.
Karakteristiske trekk ved Tupperware
Tupperware ligner på mange måter andre klyngestyringssystemer som Kubernetes og , men det er også forskjeller:
- Innebygd støtte for statlige tjenester.
- Et enkelt kontrollpanel for servere i forskjellige datasentre for å automatisere levering av containere basert på intensjoner, dekommisjonering av klynger og vedlikehold.
- Tydelig inndeling av kontrollpanelet for zooming.
- Elastisk databehandling lar deg fordele kraft mellom tjenester i sanntid.
Vi utviklet disse kule funksjonene for å støtte en rekke statsløse og stateful applikasjoner på tvers av en enorm global delt serverflåte.
Innebygd støtte for statlige tjenester.
Tupperware driver en rekke kritiske stateful-tjenester som lagrer vedvarende produktdata for Facebook, Instagram, Messenger og WhatsApp. Dette kan være store lagre med nøkkelverdi-par (f.eks. ) og overvåking av datalager (f.eks. и ). Å opprettholde stateful tjenester er ikke lett, fordi systemet skal sikre at forsyningen av containere tåler store forstyrrelser, inkludert nettbrudd eller strømbrudd. Og mens konvensjonelle teknikker, som å distribuere containere på tvers av feildomener, fungerer godt for statsløse tjenester, trenger stateful tjenester ekstra støtte.
For eksempel, hvis en serverfeil gjør én databasereplika utilgjengelig, bør du aktivere automatisk vedlikehold som vil oppdatere kjernene på 50 servere fra en pool på 10 50? Avhenger av situasjonen. Hvis en av disse 2 serverne har en annen kopi av den samme databasen, er det bedre å vente og ikke miste XNUMX replikaer samtidig. For dynamisk å ta beslutninger om systemvedlikehold og ytelse, trenger vi informasjon om intern datareplikering og plasseringslogikken til hver stateful tjeneste.
TaskControl-grensesnittet lar stateful tjenester påvirke beslutninger som påvirker datatilgjengelighet. Ved hjelp av dette grensesnittet varsler planleggeren eksterne applikasjoner om beholderoperasjoner (omstart, oppdatering, migrering, vedlikehold). En stateful tjeneste implementerer en kontroller som forteller Tupperware når det er trygt å utføre hver operasjon, og disse operasjonene kan byttes eller forsinkes midlertidig. I eksemplet ovenfor kan databasekontrolleren fortelle Tupperware å oppdatere 49 av de 50 serverne, men la en spesifikk server (X) være i fred for nå. Som et resultat, hvis kjerneoppdateringsperioden går og databasen fortsatt ikke er i stand til å gjenopprette den problematiske replikaen, vil Tupperware fortsatt oppdatere X-serveren.
Mange stateful tjenester i Tupperware bruker TaskControl ikke direkte, men gjennom ShardManager, en felles plattform for å lage stateful tjenester på Facebook. Med Tupperware kan utviklere spesifisere intensjonen sin for nøyaktig hvordan containere skal distribueres på tvers av datasentre. Med ShardManager spesifiserer utviklere sin intensjon for hvordan datashards skal distribueres på tvers av containere. ShardManager er klar over dataplassering og replikering av sine applikasjoner og kommuniserer med Tupperware gjennom TaskControl-grensesnittet for å planlegge containeroperasjoner uten direkte applikasjonsinvolvering. Denne integrasjonen forenkler administrasjonen av stateful tjenester, men TaskControl er i stand til mer. For eksempel er vårt omfattende nettnivå statsløst og bruker TaskControl til å dynamisk justere oppdateringshastigheten til containere. Etter hvert per dag uten at det går på bekostning av tilgjengeligheten.
Administrere servere i datasentre
Da Tupperware først ble lansert i 2011, ble hver serverklynge administrert av en egen planlegger. Den gang var en Facebook-klynge en gruppe serverrack koblet til én nettverkssvitsj, og datasenteret huset flere klynger. Planleggeren kunne bare administrere servere i én klynge, noe som betyr at jobben ikke kunne spres over flere klynger. Infrastrukturen vår vokste, vi avskrev i økende grad klynger. Siden Tupperware ikke kunne flytte jobben fra den utrangerte klyngen til andre klynger uten endringer, krevde det mye innsats og nøye koordinering mellom applikasjonsutviklere og datasenteroperatører. Denne prosessen resulterte i bortkastede ressurser når servere var inaktive i flere måneder på grunn av avviklingsprosedyrer.
Vi opprettet en ressursmegler for å løse klyngeavviklingsproblemet og koordinere andre typer vedlikeholdsoppgaver. Ressursmegleren holder styr på all fysisk informasjon knyttet til en server og bestemmer dynamisk hvilken planlegger som kontrollerer hver server. Dynamisk kobling av servere til planleggere gjør at planleggeren kan administrere servere i forskjellige datasentre. Siden en Tupperware-jobb ikke lenger er begrenset til en enkelt klynge, kan Tupperware-brukere spesifisere hvordan containere skal distribueres på tvers av feildomener. For eksempel kan en utvikler erklære sin intensjon (si: "kjør jobben min på 2 feildomener i PRN-regionen") uten å spesifisere spesifikke tilgjengelighetssoner. Tupperware vil selv finne passende servere for å implementere denne intensjonen, selv om klyngen eller tjenesten er tatt ut av drift.
Skalerbar for å støtte hele det globale systemet
Historisk har infrastrukturen vår blitt delt inn i hundrevis av dedikerte serverpooler for individuelle team. På grunn av fragmentering og mangel på standarder hadde vi høye driftskostnader, og inaktive servere var vanskeligere å bruke igjen. På fjorårets konferanse vi presenterte , som skal forene infrastrukturen vår til en stor enkelt serverpark. Men en enkelt serverpark har sine egne vanskeligheter. Den må oppfylle visse krav:
- Skalerbarhet. Infrastrukturen vår vokste etter hvert som vi la til datasentre i hver region. Servere har blitt mindre og mer energieffektive, så det er mange flere av dem i hver region. Som et resultat kan ikke en enkelt planlegger per region håndtere antallet beholdere som kan kjøres på hundretusenvis av servere i hver region.
- Pålitelighet. Selv om planleggeren kan skaleres opp så mye, betyr det store omfanget av planleggeren at det er en høyere risiko for feil og en hel region med containere kan bli uhåndterlig.
- Feiltoleranse. I tilfelle en stor infrastrukturfeil (for eksempel at serverne som kjører planleggeren svikter på grunn av nettverksfeil eller strømbrudd), bør de negative konsekvensene påvirke bare en del av serverne i regionen.
- Brukervennligheten. Det kan virke som du må kjøre flere uavhengige planleggere for én region. Men fra et bekvemmelighetsperspektiv gjør et enkelt inngangspunkt til en regions felles pool det enklere å administrere kapasitet og arbeidsplasser.
Vi delte opp planleggeren i skjær for å løse problemene med å opprettholde et stort felles basseng. Hvert planlegger-shard administrerer sitt eget sett med jobber i regionen, og dette reduserer risikoen knyttet til planleggeren. Etter hvert som det delte bassenget vokser, kan vi legge til flere planleggingsskår. For Tupperware-brukere ser shards og planleggerproxyer ut som ett kontrollpanel. De trenger ikke å jobbe med en haug med skår som orkestrerer oppgaver. Planlegger-shards er fundamentalt forskjellige fra klyngeplanleggerne vi brukte før, da kontrollpanelet ble partisjonert uten statisk å dele det delte utvalget av servere i henhold til nettverkstopologien.
Forbedre brukseffektiviteten med Elastic Computing
Jo større infrastrukturen vår er, desto viktigere er det å bruke serverne våre effektivt for å optimalisere infrastrukturkostnadene og redusere belastningen. Det er to måter å øke effektiviteten av serverbruk på:
- Elastisk databehandling – skaler ned nettbaserte tjenester i stille timer og bruk frigjorte servere for offline arbeidsbelastninger, for eksempel maskinlæring og MapReduce-jobber.
- Overbelastning – Plasser nettjenester og batcharbeidsbelastninger på de samme serverne slik at batcharbeidsbelastninger kjøres med lav prioritet.
Flaskehalsen i våre datasentre er . Derfor foretrekker vi små, energieffektive servere som til sammen gir mer prosessorkraft. Dessverre, på små servere med lite CPU og minne, er overbelastning mindre effektivt. Selvfølgelig kan vi plassere flere beholdere med små tjenester på en liten energieffektiv server som bruker lite prosessorressurser og minne, men store tjenester vil ha lav ytelse i denne situasjonen. Derfor råder vi utviklere av våre store tjenester til å optimalisere dem slik at de bruker hele servere.
I utgangspunktet forbedrer vi brukseffektiviteten ved å bruke elastisk databehandling. Mange av de viktigste tjenestene våre, for eksempel nyhetsfeed, meldingsfunksjon og front-end web-nivå, varierer avhengig av tidspunktet på dagen. Vi skalerer ned onlinetjenester med hensikt i stille timer og bruker frigjorte servere for offline arbeidsbelastninger, som maskinlæring og MapReduce-jobber.
Vi vet av erfaring at det er best å levere hele servere som enheter av elastisk kapasitet fordi store tjenester er både store givere og store forbrukere av elastisk kapasitet, og er optimalisert for å bruke hele servere. Når serveren frigjøres fra onlinetjenesten i stille timer, leier ressursmegleren serveren til planleggeren for å kjøre offline arbeidsbelastninger på den. Hvis netttjenesten opplever en toppbelastning, tilbakekaller ressursmegleren raskt den lånte serveren og returnerer den til netttjenesten sammen med planleggeren.
Lærdom og planer for fremtiden
I løpet av de siste 8 årene har vi utviklet Tupperware for å holde tritt med den raske veksten til Facebook. Vi deler det vi har lært og håper det vil hjelpe andre med å administrere raskt voksende infrastrukturer:
- Sett opp en fleksibel forbindelse mellom kontrollpanelet og serverne det administrerer. Denne fleksibiliteten gjør at kontrollpanelet kan administrere servere i forskjellige datasentre, hjelper til med å automatisere dekommisjonering og vedlikehold av klynger, og muliggjør dynamisk kapasitetstildeling ved hjelp av elastisk databehandling.
- Med ett enkelt kontrollpanel i regionen blir det mer praktisk å jobbe med oppgaver og enklere å administrere en stor delt serverflåte. Vær oppmerksom på at sentralen har ett enkelt inngangspunkt, selv om dens interne struktur er atskilt på grunn av skala eller feiltoleranse.
- Ved å bruke en plugin-modell kan kontrollpanelet varsle eksterne applikasjoner om kommende containeroperasjoner. I tillegg kan stateful tjenester bruke plugin-grensesnittet for å tilpasse containeradministrasjon. Med denne plugin-modellen gir kontrollpanelet enkelhet samtidig som det betjener mange forskjellige stateful tjenester effektivt.
- Vi tror at elastisk databehandling, der vi tar bort hele servere fra givertjenester for batchjobber, maskinlæring og andre ikke-hastende tjenester, er den optimale måten å forbedre effektiviteten til små, energieffektive servere.
Vi begynner så vidt å implementere . For tiden er omtrent 20 % av serverne våre i en delt pool. For å oppnå 100 % må mange problemer løses, inkludert vedlikehold av en delt lagringspool, automatisering av vedlikehold, administrering av krav på tvers av leietakere, forbedret serverutnyttelse og forbedret støtte for maskinlæringsarbeid. Vi kan ikke vente med å ta på oss disse utfordringene og dele suksessene våre.
Kilde: www.habr.com