streamalism.org

1. Oversikt

Vi distribuerer vanligvis forskjellige applikasjoner på den samme klyngen av maskiner. For eksempel er det vanlig i våre dager å ha en distribuert behandlingsmotor som Apache Spark eller Apache Flink med distribuerte databaser som Apache Cassandra i samme klynge.

Apache Mesos er en plattform som tillater effektiv ressursdeling mellom slike applikasjoner.

I denne artikkelen vil vi først diskutere noen få problemer med ressurstildeling i applikasjoner distribuert på samme klynge. Senere får vi se hvordan Apache Mesos gir bedre ressursutnyttelse mellom applikasjoner.

2. Deling av klyngen

Mange applikasjoner trenger å dele en klynge. I det store og hele er det to vanlige tilnærminger:

• Del klyngen statisk og kjør et program på hver partisjon
• Tildel et sett med maskiner til et program

Selv om disse tilnærmingene tillater applikasjoner å kjøre uavhengig av hverandre, oppnår det ikke høy ressursutnyttelse.

Tenk for eksempel på et program som kjører bare i en kort periode etterfulgt av en periode med inaktivitet. Nå, siden vi har tildelt statiske maskiner eller partisjoner til dette programmet, har vi gjort det ubrukte ressurser i den inaktive perioden.

Vi kan optimalisere ressursutnyttelsen ved å omdisponere gratis ressurser i den inaktive perioden til andre applikasjoner.

Apache Mesos hjelper med dynamisk ressurstildeling mellom applikasjoner.

3. Apache Mesos

Med begge gruppedelingstilnærminger som vi diskuterte ovenfor, er applikasjoner bare klar over ressursene til en bestemt partisjon eller maskin de kjører. Apache Mesos gir imidlertid en abstrakt oversikt over alle ressursene i klyngen til applikasjoner.

Som vi snart vil se, fungerer Mesos som et grensesnitt mellom maskiner og applikasjoner. Det gir applikasjoner med tilgjengelige ressurser på alle maskiner i klyngen. Den oppdaterer ofte denne informasjonen slik at den inkluderer ressurser som frigjøres av applikasjoner som har nådd fullføringsstatus. Dette gjør at applikasjoner kan ta den beste avgjørelsen om hvilken oppgave som skal utføres på hvilken maskin.

For å forstå hvordan Mesos fungerer, la oss ta en titt på arkitekturen:

Dette bildet er en del av den offisielle dokumentasjonen for Mesos (kilde). Her, Hadoop og MPI er to applikasjoner som deler klyngen.

Vi vil snakke om hver komponent som vises her i de neste par seksjonene.

3.1. Mesos Mester

Master er kjernekomponenten i dette oppsettet og lagrer den nåværende tilstanden til ressurser i klyngen. I tillegg fungerer det som en orkestrator mellom agentene og applikasjonene ved å formidle informasjon om ting som ressurser og oppgaver.

Siden enhver feil i master resulterer i tap av tilstand om ressurser og oppgaver, distribuerer vi den i konfigurasjon med høy tilgjengelighet. Som det kan sees i diagrammet ovenfor, distribuerer Mesos standby-masterdemoner sammen med en leder. Disse demonene er avhengige av Zookeeper for å gjenopprette tilstand i tilfelle en feil.

3.2. Mesos Agenter

En Mesos-klynge må kjøre en agent på hver maskin. Disse agentene rapportere ressursene sine til mesteren med jevne mellomrom og i sin tur, motta oppgaver som et program har planlagt å kjøre. Denne syklusen gjentas etter at den planlagte oppgaven enten er fullført eller tapt.

Vi får se hvordan applikasjoner planlegger og utfører oppgaver på disse agentene i de følgende avsnittene.

3.3. Mesos Frameworks

Mesos tillater applikasjoner å implementere en abstrakt komponent som samhandler med mesteren til motta tilgjengelige ressurser i klyngen og dessuten ta planleggingsbeslutninger basert på dem. Disse komponentene er kjent som rammeverk.

Et Mesos-rammeverk består av to underkomponenter:

• Planlegger - Gjør at applikasjoner kan planlegge oppgaver basert på tilgjengelige ressurser på alle agentene
• Leder - Kjører på alle agenter og inneholder all informasjon som er nødvendig for å utføre en planlagt oppgave på den agenten

Hele denne prosessen er avbildet med denne strømmen:

For det første rapporterer agentene sine ressurser til mesteren. For øyeblikket tilbyr master disse ressursene til alle registrerte planleggere. Denne prosessen er kjent som et ressurstilbud, og vi vil diskutere det i detalj i neste avsnitt.

Planleggeren velger deretter den beste agenten og utfører forskjellige oppgaver på den gjennom mesteren. Så snart utføreren fullfører den tildelte oppgaven, publiserer agenter ressursene sine til mesteren. Master gjentar denne prosessen med ressursdeling for alle rammer i klyngen.

Mesos tillater applikasjoner å implementere sin egendefinerte planlegger og utfører på forskjellige programmeringsspråk. En Java-implementering av planleggeren må implementerede Planlegger grensesnitt:

offentlig klasse HelloWorldScheduler implementerer Scheduler {@Override public void registered (SchedulerDriver schedulerDriver, Protos.FrameworkID frameworkID, Protos.MasterInfo masterInfo) {} @Override public void reregistered (SchedulerDriver schedulerDriver, Protos.MasterInfoid master info schedulerDriver, List list) {} @ Override public void offerRescinded (SchedulerDriver schedulerDriver, OfferID offerID) {} @ Override public void statusUpdate (SchedulerDriver schedulerDriver, Protos.TaskStatus taskStatus) {} @Overridriverriverriverriverriver , Protos.SlaveID slaveID, byte [] bytes) {} @Override public void disconnected (SchedulerDriver schedulerDriver) {} @Override public void slaveLost (SchedulerDriver schedulerDriver, Protos.SlaveID slaveID) {} @Override public voidulor .ExecutorID executorID, Protos.SlaveID slaveID, i nt i) {} @Override public void error (SchedulerDriver schedulerDriver, String s) {}}

Som man kan se, består det stort sett av ulike tilbakekallingsmetoder for kommunikasjon med mesteren spesielt.

Tilsvarende må implementeringen av en eksekutor implementere Leder grensesnitt:

offentlig klasse HelloWorldExecutor implementerer Executor {@Override offentlig ugyldig registrert (ExecutorDriver driver, Protos.ExecutorInfo executorInfo, Protos.FrameworkInfo frameworkInfo, Protos.SlaveInfo slaveInfo) {} @Override public ugyldig omregistrert (ExecutorDriver driver, Protos.SlaveInfo) offentlig tomrom frakoblet (ExecutorDriver driver) {} @Override public void launchTask (ExecutorDriver driver, Protos.TaskInfo task) {} @Override public void killTask ​​(ExecutorDriver driver, Protos.TaskID taskId) {} ​​@Override public void frameworkMessage driver (ExecutorDr byte [] data) {} @Override offentlig ugyldig nedleggelse (ExecutorDriver-driver) {}}

Vi ser en operativ versjon av planleggeren og utføreren i en senere del.

4. Ressursledelse

4.1. Ressurstilbud

Som vi diskuterte tidligere, publiserer agenter ressursinformasjonen sin til mesteren. I sin tur tilbyr mesteren disse ressursene til rammene som kjører i klyngen. Denne prosessen er kjent som en ressurstilbud.

Et ressurstilbud består av to deler - ressurser og attributter.

Ressurser er vant til publisere maskinvareinformasjon for agentmaskinen som minne, CPU og disk.

Det er fem forhåndsdefinerte ressurser for hver agent:

• prosessor
• gpus
• mem
• disk
• porter

Verdiene for disse ressursene kan defineres i en av de tre typene:

• Skalar - Brukes til å representere numerisk informasjon ved hjelp av flytende tall for å tillate brøkverdier som 1,5G minne
• Område - Brukes til å representere en rekke skalarverdier - for eksempel et portområde
• Sett - Brukes til å representere flere tekstverdier

Som standard prøver Mesos-agenten å oppdage disse ressursene fra maskinen.

I noen situasjoner kan vi imidlertid konfigurere egendefinerte ressurser på en agent. Verdiene for slike tilpassede ressurser skal igjen være i en av typene som er diskutert ovenfor.

For eksempel kan vi starte agenten vår med disse ressursene:

--resources = 'cpus: 24; gpus: 2; mem: 24576; disk: 409600; porter: [21000-24000,30000-34000]; bugs (debug_role): {a, b, c}'

Som vi kan se, har vi konfigurert agenten med få av de forhåndsdefinerte ressursene og en tilpasset ressurs som heter bugs som er av sett type.

I tillegg til ressurser, kan agenter publisere nøkkelverdier for master. Disse attributtene fungerer som ekstra metadata for agenten og hjelper rammene i planleggingsbeslutninger.

Et nyttig eksempel kan være å legg til agenter i forskjellige stativer eller soner og så planlegge forskjellige oppgaver på samme stativ eller sone for å oppnå datalokalitet:

--attributter = 'rack: abc; sone: vest; os: centos5; nivå: 10; nøkler: [1000-1500]'

I likhet med ressurser kan verdier for attributter være enten en skalar, et område eller en teksttype.

4.2. Ressursroller

Mange moderne operativsystemer støtter flere brukere. Tilsvarende støtter Mesos også flere brukere i samme klynge. Disse brukerne er kjent som roller. Vi kan vurdere hver rolle som en ressursforbruker i en klynge.

På grunn av dette kan Mesos-agenter fordele ressursene under forskjellige roller basert på forskjellige tildelingsstrategier. Videre kan rammeverk abonnere på disse rollene i klyngen og ha finkornet kontroll over ressurser under forskjellige roller.

Tenk for eksempel på a klyngevertsapplikasjoner som betjener forskjellige brukere i en organisasjon. Så av dele ressursene i roller, kan hver applikasjon fungere isolert fra hverandre.

I tillegg kan rammeverk bruke disse rollene for å oppnå datalokalitet.

Anta for eksempel at vi har to applikasjoner i klyngen som heter produsent og forbruker. Her, produsent skriver data til et vedvarende volum som forbruker kan lese etterpå. Vi kan optimalisere forbruker applikasjonen ved å dele volumet med produsent.

Siden Mesos lar flere applikasjoner abonnere på samme rolle, kan vi knytte det vedvarende volumet til en ressursrolle. Videre rammene for begge produsent og forbruker vil begge abonnere på den samme ressursrollen. derfor forbruker applikasjonen kan nå starte datalesingsoppgaven på samme volum som produsent applikasjon.

4.3. Ressursreservasjon

Nå kan spørsmålet oppstå om hvordan Mesos fordeler klyngeressurser i forskjellige roller. Mesos tildeler ressursene gjennom reservasjoner.

Det er to typer reservasjoner:

• Statisk reservasjon
• Dynamisk reservasjon

Statisk reservasjon er lik ressurstildelingen ved agentoppstart vi diskuterte i de tidligere avsnittene:

 --ressurser = "cpus: 4; mem: 2048; cpus (baeldung): 8; mem (baeldung): 4096"

Den eneste forskjellen her er at nå Mesos-agenten reserverer åtte CPUer og 4096m minne for rollen som heter baeldung.

Dynamisk reservasjon tillater oss å omorganisere ressursene i roller, i motsetning til den statiske reservasjonen. Mesos lar rammeverk og klyngeoperatører dynamisk endre tildelingen av ressurser via rammemeldinger som et svar på ressurstilbud eller via HTTP-sluttpunkter.

Mesos tildeler alle ressurser uten rolle til en standardrolle med navnet (*). Master tilbyr slike ressurser til alle rammer, uansett om de abonnerer på det eller ikke.

4.4. Ressursvekt og kvoter

Generelt tilbyr Mesos-mesteren ressurser ved hjelp av en rettferdighetsstrategi. Den bruker vektet Dominant Resource Fairness (wDRF) for å identifisere rollene som mangler ressurser. Mesteren tilbyr deretter flere ressurser til rammene som har abonnert på disse rollene.

Hendelse, selv om rettferdig deling av ressurser mellom applikasjoner er en viktig egenskap ved Mesos, er det ikke alltid nødvendig. Anta at en klynge er vert for applikasjoner som har et lavt ressursavtrykk sammen med de som har et høyt ressursbehov. I slike distribusjoner vil vi tildele ressurser basert på applikasjonens art.

Mesos tillater rammer å kreve flere ressurser ved å abonnere på roller og legge til en høyere vektverdi for den rollen. Derfor, hvis det er to roller, en med vekt 1 og en annen med vekt 2, vil Mesos tildele to ganger den rettferdige andelen ressurser til den andre rollen.

I likhet med ressurser kan vi konfigurere vekter via HTTP-sluttpunkter.

Foruten å sikre en god andel ressurser til en rolle med vekter, sørger Mesos også for det minimumsressursene for en rolle tildeles.

Mesos tillater oss å legge til kvoter i ressursrollene. En kvote spesifiserer minimumsmengde ressurser som en rolle garantert vil motta.

5. Implementing Framework

Som vi diskuterte i en tidligere del, tillater Mesos applikasjoner å gi rammeverk implementeringer på et språk de ønsker. I Java implementeres et rammeverk ved hjelp av hovedklassen - som fungerer som inngangspunkt for rammeprosessen - og implementeringen av Planlegger og Leder diskutert tidligere.

5.1. Rammeverk Hovedklasse

Før vi implementerer en planlegger og en utfører, implementerer vi først inngangspunktet for vårt rammeverk som:

• Registrerer seg hos mesteren
• Tilbyr agentens kjøretidsinformasjon
• Starter planleggeren

Vi legger først til en Maven-avhengighet for Mesos:

 org.apache.mesos mesos 0.28.3 

Deretter implementerer vi HelloWorldMain for vårt rammeverk. En av de første tingene vi vil gjøre er å starte utførelsesprosessen på Mesos-agenten:

public static void main (String [] args) {String path = System.getProperty ("user.dir") + "/target/libraries2-1.0.0-SNAPSHOT.jar"; CommandInfo.URI uri = CommandInfo.URI.newBuilder (). SetValue (bane) .setExtract (false) .build (); String helloWorldCommand = "java -cp biblioteker2-1.0.0-SNAPSHOT.jar com.baeldung.mesos.executors.HelloWorldExecutor"; CommandInfo commandInfoHelloWorld = CommandInfo.newBuilder () .setValue (helloWorldCommand) .addUris (uri) .build (); ExecutorInfo executorHelloWorld = ExecutorInfo.newBuilder () .setExecutorId (Protos.ExecutorID.newBuilder () .setValue ("HelloWorldExecutor")) .setCommand (commandInfoHelloWorld) .setName ("Hello World (Java)") .setSource ("java"). bygge(); }

Her konfigurerte vi først eksekutørens binære plassering. Mesos-agent ville laste ned denne binæren ved rammeverkregistrering. Deretter vil agenten kjøre den gitte kommandoen for å starte eksekutørprosessen.

Deretter initialiserer vi rammeverket vårt og starter planleggeren:

FrameworkInfo.Builder frameworkBuilder = FrameworkInfo.newBuilder () .setFailoverTimeout (120000) .setUser ("") .setName ("Hello World Framework (Java)"); frameworkBuilder.setPrincipal ("test-framework-java"); MesosSchedulerDriver driver = new MesosSchedulerDriver (new HelloWorldScheduler (), frameworkBuilder.build (), args [0]);

Endelig, vi starter MesosSchedulerDriver som registrerer seg hos mesteren. For å få en vellykket registrering må vi passere IP-adressen til Master som et programargument argumenter [0] til denne hovedklassen:

int status = driver.run () == Protos.Status.DRIVER_STOPPED? 0: 1; driver.stop (); System.exit (status);

I klassen vist ovenfor, CommandInfo, ExecutorInfo, og FrameworkInfo er alle Java-representasjoner av protobuf-meldinger mellom master og rammer.

5.2. Implementering Scheduler

Siden Mesos 1.0, Vi kan påkalle HTTP-endepunktet fra ethvert Java-program for å sende og motta meldinger til Mesos-mesteren. Noen av disse meldingene inkluderer for eksempel rammeverkregistrering, ressurstilbud og avslag på tilbud.

Til Mesos 0.28 eller tidligere, må vi implementere Planlegger grensesnitt:

For det meste vil vi bare fokusere på resourceOffers metoden for Planlegger. La oss se hvordan en planlegger mottar ressurser og initialiserer oppgaver basert på dem.

Først får vi se hvordan planleggeren tildeler ressurser til en oppgave:

@Override public void resourceOffers (SchedulerDriver schedulerDriver, List list) {for (Tilbudstilbud: liste) {Listeoppgaver = ny ArrayList (); Protos.TaskID taskId = Protos.TaskID.newBuilder () .setValue (Integer.toString (LaunchTasks ++)). Build (); System.out.println ("Starter printHelloWorld" + taskId.getValue () + "Hello World Java"); Protos.Resource.Builder cpus = Protos.Resource.newBuilder () .setName ("cpus") .setType (Protos.Value.Type.SCALAR) .setScalar (Protos.Value.Scalar.newBuilder () .setValue (1)) ; Protos.Resource.Builder mem = Protos.Resource.newBuilder () .setName ("mem") .setType (Protos.Value.Type.SCALAR) .setScalar (Protos.Value.Scalar.newBuilder () .setValue (128)) ;

Her tildelte vi 1 CPU og 128M minne til oppgaven vår. Deretter bruker vi Planlegger Driver å starte oppgaven på en agent:

 TaskInfo printHelloWorld = TaskInfo.newBuilder () .setName ("printHelloWorld" + taskId.getValue ()) .setTaskId (taskId) .setSlaveId (offer.getSlaveId ()) .addResources (cpus) .addResources (mem) .setExecutor. newBuilder (helloWorldExecutor)) .build (); List offerIDS = ny ArrayList (); offerIDS.add (offer.getId ()); task.add (printHelloWorld); schedulerDriver.launchTasks (offerIDS, oppgaver); }}

Alternativt Planlegger finner ofte behovet for å avvise ressurstilbud. For eksempel hvis Planlegger ikke kan starte en oppgave på en agent på grunn av mangel på ressurser, må den umiddelbart avslå tilbudet:

schedulerDriver.declineOffer (offer.getId ());

5.3. Implementering Leder

Som vi diskuterte tidligere, er eksekutorkomponenten i rammeverket ansvarlig for å utføre applikasjonsoppgaver på Mesos-agenten.

Vi brukte HTTP-endepunktene for implementering Planlegger i Mesos 1.0. På samme måte kan vi bruke HTTP-endepunktet for utføreren.

I en tidligere seksjon diskuterte vi hvordan et rammeverk konfigurerer en agent til å starte eksekutørprosessen:

java -cp biblioteker2-1.0.0-SNAPSHOT.jar com.baeldung.mesos.executors.HelloWorldExecutor

Spesielt denne kommandoen vurderer HelloWorldExecutor som hovedklasse. Vi implementerer dette hoved- metode til initialisere MesosExecutorDriver som kobler seg til Mesos-agenter for å motta oppgaver og dele annen informasjon som oppgavestatus:

offentlig klasse HelloWorldExecutor implementerer Executor {public static void main (String [] args) {MesosExecutorDriver driver = new MesosExecutorDriver (new HelloWorldExecutor ()); System.exit (driver.run () == Protos.Status.DRIVER_STOPPED? 0: 1); }}

Den siste tingen å gjøre nå er å akseptere oppgaver fra rammeverket og starte dem på agenten. Informasjonen for å starte en hvilken som helst oppgave er selvstendig i HelloWorldExecutor:

public void launchTask (ExecutorDriver driver, TaskInfo task) {Protos.TaskStatus status = Protos.TaskStatus.newBuilder () .setTaskId (task.getTaskId ()) .setState (Protos.TaskState.TASK_RUNNING) .build (); driver.sendStatusUpdate (status); System.out.println ("Utfør oppgave !!!"); status = Protos.TaskStatus.newBuilder () .setTaskId (task.getTaskId ()) .setState (Protos.TaskState.TASK_FINISHED) .build (); driver.sendStatusUpdate (status); }

Selvfølgelig er dette bare en enkel implementering, men det forklarer hvordan en utfører deler oppgavestatus med mesteren på hvert trinn og deretter utfører oppgaven før du sender en fullføringsstatus.

I noen tilfeller kan eksekutører også sende data tilbake til planleggeren:

String myStatus = "Hello Framework"; driver.sendFrameworkMessage (myStatus.getBytes ());

6. Konklusjon

I denne artikkelen diskuterte vi kort ressursdeling mellom applikasjoner som kjører i samme klynge. Vi diskuterte også hvordan Apache Mesos hjelper applikasjoner med å oppnå maksimal utnyttelse med et abstrakt syn på klyngeressursene som CPU og minne.

Senere diskuterte vi dynamisk fordeling av ressurser mellom applikasjoner basert på ulike rettferdighetspolitikker og roller. Mesos tillater applikasjoner å lage planlegge beslutninger basert på ressurstilbud fra Mesos-agenter i klyngen.

Til slutt så vi en implementering av Mesos-rammeverket i Java.

Som vanlig er alle eksempler tilgjengelig på GitHub.