Utviklingen av cluster planlegging system

Kubernetes har blitt de facto standard i området container orkestrering. Alle applikasjoner vil bli utviklet Og kjørt På Kubernetes i fremtiden. Formålet med denne artikkelserien er å introdusere de underliggende implementeringsprinsippene Til Kubernetes på en dyp og enkel måte.

Kubernetes er et klyngeplanleggingssystem. Denne artikkelen introduserer i hovedsak noen tidligere cluster planlegging system arkitektur Av Kubernetes. Ved å analysere deres designideer og arkitekturegenskapene, kan vi studere utviklingsprosessen av klyngeplanleggingssystemarkitektur, og hovedproblemet som må vurderes i arkitekturdesignet. Det vil være svært nyttig for å forstå Kubernetes arkitektur.

Vi må forstå noen av de grunnleggende konseptene for klyngeplanleggingssystem, for å gjøre det klart, vil jeg forklare konseptet gjennom et eksempel, la oss anta at vi vil implementere en distribuert Cron. Systemet styrer Et sett Med Linux-verter. Brukeren definerer jobben gjennom API levert av systemet. systemet vil periodisk utføre den tilsvarende oppgaven basert på oppgavedefinisjonen.:

• Klynge: Linux-vertene som administreres av dette systemet, danner et ressursutvalg for å kjøre oppgaver. Dette ressursutvalget kalles Klynge.
• Jobb: den definerer hvordan klyngen utfører sine oppgaver. I dette eksemplet Er Crontab akkurat en enkel Jobb som tydelig viser hva som må gjøres (utførelsesskript) på hvilket tidspunkt (tidsintervall).Definisjonen av noen jobber er mer komplisert, for eksempel definisjonen av en jobb som skal fullføres i flere aktiviteter, og avhengighetene mellom aktiviteter, samt ressursbehovene for hver aktivitet.
• Oppgave: en jobb må planlegges i bestemte ytelsesoppgaver. Hvis vi definerer en jobb for å utføre et skript på 1 am hver kveld, så skriptet prosessen utføres på 1 am hver dag er En Oppgave.

ved utforming av klyngeplanleggingssystemet er kjerneoppgavene til systemet to:

• Oppgaveplanlegging: Når jobbene er sendt til klyngeplanleggingssystemet, må de innsendte jobbene deles inn i bestemte kjøringsoppgaver, og kjøringsresultatene for aktivitetene må spores og overvåkes. I eksemplet på distribuert Cron må planleggingssystemet i tide starte prosessen i samsvar med kravene i operasjonen. Hvis prosessen ikke klarer å utføre, er det nødvendig å prøve på nytt osv. Noen komplekse scenarier, for Eksempel Hadoop Kart Redusere, planlegging systemet må dele Kartet Redusere oppgaven i tilsvarende flere Kart Og Redusere oppgaver, og til slutt få oppgaven kjøring resultatdata.
• Ressursplanlegging: brukes i hovedsak til å samsvare med aktiviteter og ressurser, og passende ressurser tildeles for å kjøre aktiviteter i henhold til ressursbruk av verter i klyngen. Hovedmålet med ressursplanlegging er å forbedre ressursutnyttelsen så langt som mulig og redusere ventetiden for oppgaver under betingelse av fast ressursforsyning, og redusere forsinkelsen av oppgaven eller responstiden (hvis det er batchoppgave, refererer det til tiden fra start til slutt av oppgaveoperasjoner, hvis det er online responstypeoppgaver, For Eksempel Webapplikasjoner, som refererer til hver responstid til forespørselen), Må Oppgaveprioriteten tas i betraktning mens Den er så rettferdig som mulig. mulig (ressurser er ganske allokert til alle oppgaver). Noen av disse målene er motstridende og må balanseres, for eksempel ressursutnyttelse, responstid, rettferdighet og prioriteringer.

Hadoop MRv1

Kartreduksjon er en slags parallell databehandlingsmodell. Hadoop kan kjøre denne typen cluster management plattform for parallell databehandling. MRv1 er den første generasjons versjonen Av Kart Redusere task scheduling engine Av Hadoop plattform. Kort Sagt, MRv1 er ansvarlig for planlegging og utførelse av jobben på klyngen, og gå tilbake til beregningsresultatene når en bruker definerer Et Kart Redusere beregning og sende Den Til Hadoop. Her er hva arkitekturen Til MRv1 ser ut:

arkitekturen er relativt enkel, standard Master / Slave arkitektur har to kjernekomponenter:

• Job Tracker Er hovedadministrasjonskomponenten i klyngen, som er ansvarlig for både ressursplanlegging og aktivitetsplanlegging.
• Tasktracker kjører på hver maskin i klyngen, som er ansvarlig for å kjøre bestemte oppgaver på verts-og rapporteringsstatusen.

med populariteten Til Hadoop og økningen av ulike krav, Har MRv1 Følgende problemer som skal forbedres:

• ytelsen har en viss flaskehals: maksimalt antall noder som støtter ledelsen er 5000, og maksimalt antall oppgaver for å støtte operasjonen er 40.000. Det er fortsatt noe rom for forbedring.
• det er ikke fleksibelt nok til å utvide eller støtte andre oppgavetyper. I Tillegg Til Å Tilordne reduksjonsoppgaver, er det mange andre oppgavetyper I Hadoop-økosystemet som må planlegges, for Eksempel Spark, Hive, HBase, Storm, Oozie, etc. Derfor er det nødvendig med et mer generelt planleggingssystem, som kan støtte og utvide flere aktivitetstyper
• Lav ressursutnyttelse: MRv1 konfigurerer statisk et fast antall spor for hver node, og hvert spor kan bare brukes til den spesifikke oppgavetypen (Kart eller Reduser), noe som fører til problemet med ressursutnyttelse. For eksempel er et stort antall Kartoppgaver kø for tomgangsressurser, men faktisk er et stort antall Reduksjonsspor tomgang for maskiner.
• problemer Med flere leieforhold og flere versjoner. Ulike avdelinger kjører for eksempel oppgaver i samme klynge, men de er logisk isolert fra hverandre, eller de kjører forskjellige versjoner Av Hadoop i samme klynge.

GARN

GARN(Enda En Ressurs Forhandler) ER en andre generasjon Av Hadoop, hovedformålet er å løse alle slags problemer I MRv1. GARNARKITEKTUR ser slik ut:

DEN enkle forståelsen AV GARN er at den viktigste forbedringen Over MRv1 er å dele ansvaret for den opprinnelige JobTrack i to forskjellige komponenter: Resource Manager Og Application Master

• Resource Manager: Det er ansvarlig For Ressursplanlegging, styrer alle ressurser, tildeler ressurser til ulike typer oppgaver, og enkelt utvider Ressursplanleggingsalgoritmen gjennom en pluggbar arkitektur.
• Application Master: Det er ansvarlig for oppgaveplanlegging. Hver jobb (Kalt Application IN YARN) starter en tilsvarende Application Master, som er ansvarlig for å dele jobben i bestemte oppgaver, og søker om ressurser Fra Resource Manager, starter oppgaven, sporer statusen til oppgaven og rapporterer resultatene.

La oss ta en titt på hvordan denne arkitekturendringen løste Mrv1s ulike problemer:

• Del den opprinnelige oppgaven planlegging ansvar Job Tracker, og resulterer i betydelige ytelsesforbedringer. Oppgaveplanleggingsansvaret for den opprinnelige Jobbsporeren ble delt ut for Å bli utført Av Application Master,og Application Master ble distribuert, hver forekomst håndterte bare forespørselen fra en Jobb, og dermed fremmet det maksimale antall klyngenoder fra 5000 til 10 000.
• komponentene i aktivitetsplanlegging, Programmester og ressursplanlegging kobles fra og opprettes dynamisk basert på jobbforespørsler. En Application Master-forekomst er ansvarlig for bare en jobb med planlegging, noe som gjør det lettere å støtte ulike typer jobber.
• containerisolasjonsteknologien er introdusert, hver oppgave kjøres i en isolert beholder, noe som i stor grad forbedrer ressursutnyttelsen i henhold til oppgavens etterspørsel etter ressurser som kan tildeles dynamisk. Ulempen med DETTE ER YARN ‘ s ressursforvaltning og allokering har bare en dimensjon av minne.

Mesos arkitektur

designmålet TIL YARN er fortsatt å tjene planleggingen Av Hadoop økosystem. Mesos mål kommer nærmere, det er designet for å være et generelt planleggingssystem, som kan styre driften av hele datasenteret. Som vi ser, brukte den arkitektoniske utformingen Av Mesos mye GARN for referanse, jobbplanlegging og Ressursplanlegging bæres av de forskjellige modulene separat. Men Den største forskjellen Mellom Mesos OG GARN er måten å planlegge for ressurser, en unik mekanisme kalt Ressurstilbud er utformet. Trykket av ressurser planlegging er ytterligere frigitt, og jobben planlegging skalerbarhet økes også.

hovedkomponentene I Mesos er:

• Mesos Master: Det er en komponent som er ansvarlig For Ressursallokering og komponenter i ledelsen, som Er Ressursforvalteren som svarer til innsiden AV GARNET. Men modusen er litt annerledes hvis det blir diskutert senere.
• Rammeverk: er ansvarlig for jobbplanlegging, ulike jobbtyper vil ha et Tilsvarende Rammeverk, for Eksempel Spark-Rammeverket som er ansvarlig For Spark-jobber.

Ressurstilbud På Mesos

Det kan virke Som Mesos og GARNARKITEKTURER er ganske like,men Faktisk har Mesteren Av Mesos en veldig unik (og noe bisarre) Ressurstilbudsmekanisme:

• GARN Er Trekk: Ressursene Som Tilbys Av Resource Manager I GARN er passiv, når forbrukerne av ressurs (Application Master) trenger ressurser, kan det ringe Grensesnittet Til Resource Manager for å skaffe ressurser, og Resource Manager reagerer bare passivt på Behovene Til Application Master.
• Mesos Er Push: ressursene Som Tilbys Av Master Of Mesos er proaktiv. Master Of Mesos vil regelmessig ta initiativ til å presse alle tilgjengelige ressurser (De såkalte Ressurstilbudene, jeg vil kalle Det Tilbud fra nå av) Til Rammen. Hvis det er oppgaver Som Rammeverket skal utføre, kan Det ikke aktivt søke om ressurser, med mindre tilbudene er mottatt. Framework velger en kvalifisert ressurs fra Tilbudet om å godta (denne bevegelsen kalles Godta I Mesos) og avvise de resterende tilbudene (denne bevegelsen kalles Avvise). Hvis det ikke er nok kvalifiserte ressurser i Denne runden Av Tilbudet, må vi vente på neste Runde Av Master for Å gi Tilbud.

jeg tror at når du ser denne aktive Tilbudsmekanismen, vil du ha den samme følelsen med meg. Det vil si at effektiviteten er relativt lav, og følgende problemer vil oppstå:

• beslutningseffektiviteten til Ethvert Rammeverk påvirker den generelle effektiviteten. For konsistens Kan Master bare gi Tilbud til ett Rammeverk om gangen, og vente På Rammen for å velge Tilbudet før du gir resten til neste Rammeverk. På denne måten vil beslutningseffektiviteten til Ethvert Rammeverk påvirke den totale effektiviteten.
• “kaste bort” mye tid på rammer som ikke krever ressurser. Mesos vet egentlig ikke hvilket Rammeverk som trenger ressurser. Så Det vil Være Rammeverk med ressurskrav står i kø For Tilbud, men Rammeverket uten ressurskrav får Tilbud ofte.

Som svar på de ovennevnte problemene har Mesos gitt noen mekanismer for å redusere problemene, for eksempel å sette En timeout For Rammeverket for å ta beslutninger, eller la Rammeverket avvise tilbud ved å sette Det Til Å Undertrykke tilstand. Siden det ikke er fokus for denne diskusjonen, detaljene er neglisjert her.

Faktisk er Det noen åpenbare fordeler For Mesos ved hjelp av denne mekanismen for aktivt Tilbud:

• ytelsen er tydeligvis forbedret. En klynge kan støtte opptil 100.000 noder ifølge simuleringstesten, For Twitters produksjonsmiljø, kan den største klyngen støtte 80.000 noder. hovedårsaken er at det aktive Tilbudet Av Mesos Master mechanism ytterligere forenkler Mesos ansvar. prosessen med ressursplanlegging, ressurs til aktivitet matching, I Mesos er delt inn i to faser: ressurser Å Tilby, og Tilbud til aktivitet. Mesos Master er bare ansvarlig for å fullføre den første fasen, og matchingen av den andre fasen er igjen Til Rammen.
• mer fleksibel og i stand til å møte mer ansvarlige retningslinjer for oppgaveplanlegging. For eksempel, ressursbruk strategi For Alle eller Nothings.

Planleggingsalgoritme For Mesos DRF (Dominant Resource Fairness)

SOM FOR DRF-algoritmen har det faktisk ingenting å gjøre med vår forståelse Av Mesos arkitektur, men det er veldig kjerne og viktig I Mesos, så jeg vil forklare litt mer her.

Som nevnt ovenfor gir Mesos Tilbud Til Rammeverket i sin tur,så hvilket Rammeverk bør velges for Å gi Tilbud hver Gang? Dette er kjerneproblemet som skal løses AV drf-algoritmen. Det grunnleggende prinsippet er å ta hensyn til både rettferdighet og effektivitet. Samtidig som det tilfredsstiller alle ressursbehov I Rammeverket, bør Det være så rettferdig som mulig å unngå at Et Rammeverk forbruker for mange ressurser og sulter andre rammer til døden.

DRF ER en variant av min-max rettferdighetsalgoritmen. Enkelt sagt er det å velge Rammen med lavest Dominerende Ressursbruk for å gi Tilbudet hver gang. Hvordan beregne Den Dominerende Ressursbruken Av Rammen? Fra alle ressurstypene som er opptatt Av Rammeverket, velges ressurstypen med lavest ressursbeslutning som Den Dominerende Ressursen. Dens Ressurs yrke rate er akkurat Den Dominerende Ressursbruk Av Rammeverket. FOR eksempel opptar EN CPU Av Rammeverk 20% av den totale Ressursen, 30% av minnet og 10% av disken. Så den dominerende ressursbruken av Rammen vil være 10%, den offisielle termen kaller en disk som dominerende ressurs, og denne 10% kalles Dominerende Ressursbruk.

DET endelige målet MED DRF er å distribuere ressurser likt mellom alle rammene. Hvis Et Rammeverk x aksepterer for mange ressurser i Denne runden Av Tilbudet, vil det ta mye lengre tid å få muligheten til neste runde Av Tilbudet. Imidlertid vil forsiktige lesere finne at det er en antagelse i denne algoritmen, det vil si Etter At Rammen aksepterer ressurser, vil det frigjøre dem raskt, ellers vil det være to konsekvenser:

• andre rammer sulter til døden. Ett Rammeverk a godtar de fleste ressursene i klyngen på en gang, og aktiviteten fortsetter å kjøre uten å avslutte, slik at de fleste ressursene er opptatt Av Rammeverk A hele tiden, og andre rammer vil ikke lenger få ressursene.
• Sulte deg selv i hjel. Fordi den dominerende ressursbruken av Dette Rammeverket alltid er veldig høy, så det er ingen sjanse Til å Få Tilbud i lang Tid, så flere oppgaver kan ikke kjøres.

Så Mesos er bare egnet for planlegging av korte oppgaver, Og Mesos ble opprinnelig designet for korte oppgaver av datasentre.

Oppsummering

fra den store arkitekturen er all planleggingssystemarkitektur Master / Slave-arkitektur, Slaveenden er installert på hver maskin med krav til ledelse, som brukes til å samle vertsinformasjon og utføre oppgaver på verten. Master er hovedsakelig ansvarlig for ressursplanlegging og oppgaveplanlegging. Ressursplanlegging har høyere krav til ytelse og aktivitetsplanlegging har høyere krav til skalerbarhet. Den generelle trenden er å diskutere de to typer plikt avkoble og fullføre dem av ulike komponenter.