Innledning

Jeg jobber i et selskap hvor vi kjører mange batch jobber behandling millioner registreringer av data hver dag og jeg har tenkt nylig om alle maskiner som sitter rundt hver eneste dag gjør ingenting i flere timer. Ville ikke det være bra om vi kunne bruke disse maskinene til å styrke behandlingskapasiteten til våre systemer? I dette settet av artiklene jeg skal se på de potensielle fordelene av å benytte et kontor rutenett med virtualiserte miljøer.

I del 1 ga jeg en oversikt over systemet og teknologiene jeg skal bruke samt drøftet noen av de mulige årsaker til hvorfor du ønsker å opprette et kontor rutenett.

Job Control

Hvis du skal kjøre jobber så du kommer til å trenge noen måte å håndtere dem. Din jobb kontrollsystemet (på jobben din server) må være veldig godt gjennomtenkt før selv prøver å kjøre et kontor rutenett. Så det første, hva er oppgaver for en jobb-kontroll system:

• Del ut jobber på forespørsel fra arbeiderne
• Fortell arbeidere hva slags jobber for å kjøre
• Spor jobber
• Sørg for at arbeidsplasser kun kjøres en gang
• Gi jobben data for arbeidstakere, eller i det minste fortelle dem hvor de skal få det

Systemet må også være utvidbart, en løsning som fungerer for nå i en enkelt sak kan utvides til å kjøre flere typer jobber som bedriften ser verdien i et rutenett løsning. For eksempel kan få jobber prioriteringer, kan mer enn én jobb type eksisterer (dvs. flere code baser), eventuelt kan du selv kjøre flere forskjellige arbeidstaker maskiner som er optimalisert for hver type jobb (selv om det beveger seg bort fra den "generiske arbeideren 'idé). Prøver alltid å tenke på fremtiden ved utvikling av systemer, kan en kortsiktig syn føre til lengre sikt frustrasjon og økt utvikling tid.

Job Server

Vi kommer til å trenge et sted å kontrollere vår jobber fra, dette bør være det eneste systemet i rutenett ditt som har en fast ressurs locator, være at en IP-adresse, vertsnavn URL (bruk av interne DNS), osv. Dette er fordi må arbeiderne å vite hvor du skal lete etter jobber, arbeidstakere trenger å finne den jobben kontrollsystemet (ikke den jobben kontrollsystemet finne arbeiderne).

Jobben serveren selv ikke har egentlig en komplisert oppgave (i et grunnleggende system hvertfall), trenger den til å lagre en liste over jobber, dele ut jobber, får resultater, og deretter lagre dem for senere henting. Hvordan disse delene (for eksempel "dele ut jobber") er definert kan være svært enkel. Senere kan vi utvide systemet til å inkludere et administrasjonsgrensesnitt for å legge til, redigere, slette, suspendere jobber, men dette er utenfor denne øvelsen.

Det er ingen grunn overhodet da at jobben serveren ikke kunne være en virtuell maskin som kjører innenfor ditt viktigste behandlingen server så lenge det ikke tapper ikke for mye ressurser fra det. Jobben Serveren men trenger høy tilgjengelighet, om den går ned på en fredag ​​kveld du kommer til å miste en hel helg med behandling, potensielt koster deg et par uker igjen av behandlingstid (i forhold til hoved behandling server alene) . Du vil kanskje vurdere å sette jobben din server på et lass balansert miljø for høy tilgjengelighet.

Grunnleggende konfigurering

Den grunnleggende oppsett for jobben vår server vil bestå av det jeg kaller en av mine halte servere (som er Li Nux, m ySql, P HP). Koden kjører på Thea arbeiderne faktisk vil finne ut hva jobber den kan kjøres ved å samhandle med med jobb-kontroll system databaser. Senere kunne vi lage en web-tjeneste og faktisk deler ut arbeidsplasser i stedet for at arbeiderne gjøre jobben selv, men for nå vil vi fortsette å bruke KISS-prinsippet (Keep It Simple, Stupid!).

Så, kan opprette tre mySQL tabeller å forholde seg til jobber. Disse vil bli `jobb`, `jobRecords`, og `jobResults`.

Her Jeg bruker SQL Buddy en stor liten alternativ til phpMyAdmin bare fordi det lettere å installere på CentOS (for andre se: 10 Great alternativer til phpMyAdmin )

Denne tabellen består av 5 enkle felt,

• id: Unikt identifisere jobben
• Navn: Kan være en klient referanse, eller en rekke andre identifikatorer
• Status: Du må vite hvor jobben er på, f.eks
  • 0: Ikke startet
  • 1: Plukket opp
  • 2: Fullført
• started_by: Hvem er begynt å gjøre jobben? Dette er ikke helt nødvendig, men er en fin å ha. Jeg vil foreslå sporing arbeiderne ved deres IP-adressen på nettverket
• started_at: Når begynte arbeideren starter jobben? Ved å spore jobber som ikke har fullført innen X mye tid vi vet vi trenger for å plukke opp jobben igjen og starte behandling av en annen arbeidstaker. Arbeidere kunne stoppe behandlingen / gå offline for en rekke årsaker, strømbrudd, krasj, nettverk tap etc.

Det er lett hvordan denne tabellen kan utvides med et par ekstra felt for å muliggjøre sporing statistikk, en sluttid kolonne for å se hvor lang tid jobben tok, en teller for å se hvor mange arbeidere plukket opp jobben (selvsagt dette må en tendens til å 1), jobb prioritet, kan listen fortsette og fortsette. I mer kompliserte jobben scenarier vil det være mulig å angi hvor mye minne de arbeideren trenger tilgang til (og dermed kun bruke egnet arbeidere), eller til og med hvilken type arbeidstaker skulle være nødvendig.

Lar legge til et par eksempel jobber:

Den neste tabellen igjen er ganske enkel å forstå, dette er vår jobb poster. De er knyttet til de viktigste jobbene tabellen ved en kolonne `jobs_id`. Den utgjør i denne tabellen svært mye avhenger av data som du må oppgi for arbeiderne, kan gjøre en veldig enkelt eksempel der vi har fire kolonner:

• id: ID i posten
• Navn: Person navn
• adresse: Person adresse
• jobs_id: Jobben ID at denne posten er knyttet til

Den tredje og siste tabell består av en resultatside bord, har det mye det samme gjør opp som våre rapporter bord, og med tillegg av noen kolonner kan være en del av postene tabellen:

• job_record_id: Link resultatet til jobben tabellen
• Resultatet: Resultatet data

... Og det er alt du trenger for jobb-kontroll! (Om enn på et veldig grunnleggende nivå) I mitt tilfelle er jeg pekte til et annet bord hvor min data til prosessen var plassert, men dette kunne like gjerne vært en fil, parametre for å kjøre simulering kode, alt mulig.

Velge en jobb

Som tidligere nevnt, vil arbeiderne gjøre jobben vår management for oss for nå, så alt vi trenger for å virkelig gjøre er å finne en jobb som trenger behandling og få informasjon. Hvordan ville vi gjøre dette? Vel plukke vår jobb utvalgskriterier og ser etter jobber, i SQL gjorde jeg følgende:

1. Ta noen jobber som ikke er merket som fullført, men fra arbeidstaker vår og nullstille dem (erstatte __ME__ med en identifikator, ville enkleste være IP-adresse):

     UPDATE `jobb` SET `status` = 0 WHERE `status` = 1 AND `started_by` = __ME__; 

2. Ved hjelp av vår jobb utvelgelseskriterier, velger en jobb og fortelle det kontrollsystemet som denne arbeideren arbeider med det:

     UPDATE `jobb` SET `status` = 1, `started_by` = __ME__, `started_at` = NÅ () WHERE `status` = 0 eller
    (`Status` = 1 AND `started_at`> DATE_SUB (NÅ (), INTERVAL X HOUR)) ORDER BY `id` ASC; 

   Ved å ta tak i jobber som ikke har returnert resultater i X tid vi sikre at alle jobber er kjørt i tilfelle en arbeidstaker å krasje eller gå AWOL.

3. Neste ta jobbene detaljene fulgt av postene selv:

     SELECT * FROM `jobb` WHERE `started_by` = __ME__ LIMIT 1;
    SELECT * FROM `job_records` WHERE `id` = __JOBID__; 

Ved ferdigstillelse av den jobben vi setter inn våre resultat poster og merke jobben som fullført. Husker som jobber kan suspendere / gjenoppta når som helst kan for noen robusthet i skriptet. Det kan være at oppgaven utsetter halvveis gjennom oppdatering av jobb-kontroll systemet, slik at kontrollen antall poster i en jobb, og antall resultater lagret tilbake til jobb-kontroll systemet vil være et klokt trekk.

I tillegg, mens dette viser hvordan arbeidsplasser kan velges og styres fra en SQL-spørring rammen du burde virkelig være abstrahere jobben din kontroll, slik at hvis du velger å bytte til ved hjelp av en web service, en fil basert system, XML , eller andre rekke systemer vil det ikke påvirke koden over det.

Job Konfigurasjon

Den neste aspekt å vurdere er jobben størrelse og konfigurasjon. Ved å spille med jobben konfigurasjon kan vi stryke en god balanse mellom fart, prosess replikering, og pålitelighet. Ta et par of scenarier:

1. Jobber ta en dag hver for å kjøre: Dette betyr at de ansatte trenger 15 dager på å behandle hver jobb (husk 10% av kraften for 2/3rds av tiden). Dette er helt klart ikke en klok konfigurasjon, er din jobb størrelse altfor stort! Det ville ta minst dobbelt tid til å få en jobb behandles bør den første arbeideren gå AWOL (tid for å plukke opp at den ikke har returnert følge pluss reprosessering tid). I en ideell vil du ha minst en full jobb enkelt ryddet innen utgangen av hvert lang inaktiv periode, at måten du holder jobbene tikker over og i verste fall en jobb ville ta to dager å behandle burde det første gå glipp av.
2. Jobber tar 1 minutt å kjøre: Dette betyr at de ansatte tar ca 15 minutter å kjøre hver jobb. Mens dette kan i utgangspunktet virke perfekt, får du ytterligere arbeid prosessering til lunsj, kaffepauser, møter, osv. dette scenariet setter press på andre deler av systemet og innfører sine egne problemer. For eksempel er det første oppsettet / behandlingstid forholdet kommer til å gå rett ned, derfor miste effektivitet. Nettverket kommer til å være konstant streaming jobben informasjon til de forskjellige arbeiderne frustrerende ansatte som er dong deres daglige arbeid. Du er også tenkt å legge mer press på jobben din behandling server som det har å dele ut masse små biter av arbeidet på en jevnlig basis. Endelig, i denne situasjonen hvis jobben din server går ned du kommer til å lage en stor back log av gjenstående arbeid mens større arbeidsplasser kan til fortsatt behandling uvitende om at jobben serveren opplevde vanskeligheter.

I realiteten blir det ingen ideell konfigurasjon for grid oppsett, mye avhenger av de tilgjengelige ressursene, typer jobb, jobb behandlingstid krav, nettverksmulighet, og så videre. Men noen retningslinjer vil være:

• Størrelse jobbene slik at hver arbeidstaker kan komme gjennom minst 3-4 arbeidsplasser i en periode på 15 timer (den lengste trolig tomgang tidsperiode)
• Spill med jobben størrelse, slik at oppsett tid blir ganske ubetydelig i forhold til behandlingstiden (med tanke på punktet over).
• Hvis en jobb ikke fullfører i det doble av tiden (kanskje mindre) du forventer det å fullføre det anta at dens borte AWOL og begynner å behandle den med en annen arbeidstaker. Dette betyr at du kanskje må vente opp til tre ganger den normale lengden på en jobb for det å fullføre (kanskje lenger hvis den påfølgende jobben mislykkes). Det kan være lurt å redusere denne tiden, men vær forsiktig med å redusere det altfor mye du kan begynne å duplisere utføre oppgaver på en jevnlig basis.
• Jobber bør være uavhengig av eksterne krav så mye som mulig. Jobben server, for eksempel, skal kun kontaktes i starten og slutten av hver jobb.
• Ikke mette nettverket ditt, vil dette ha to negative effekter, vil dagtid personalet bruker nettverket frustrerende og problemer kan oppleves med forbindelser timing ut et problem som bare vil bli verre når du skalere rutenettet.
• Sikre arbeidsplasser kan kjøre på arbeiderne. Dersom arbeidsplasser blir for minnekrevende eller diskplass intensiv arbeidsplasser vil starte avbryter og det eneste du vil merke er en nedgang i antall arbeidsplasser behandles med ingen reell grunn.

Sende Resultater av en jobb

Når sende inn resultatet av en jobb det er viktig å kontrollere at resultatene ikke har blitt sendt inn av en annen arbeidstaker, særlig hvis den aktuelle arbeidstaker har vært sovende i noen tid.

Når resultatene er presentert sikrer at antall resultatene samsvarer med antall poster i jobben.

Som tidligere nevnt, og kan ikke være over understreket, bygge feiltoleranse i jobb henting og resultater underkastelse. Arbeiderne kan (og mest sannsynlig vil) gå i dvalemodus på det mest ubekvemme ganger, og dette må tas hensyn til. Også en gang abstrahere bort resultatene innlevering vil hjelpe ta seg av fremtidige endringer i jobb-kontroll systemet mye enklere å håndtere.

Sammendrag

I denne section har vi sett på hva en jobb kontroll server må gjøre og hvordan du får et helt grunnleggende system satt opp. Vi diskuterte hvordan du kan hente en jobb fra kontrollsystemet og hvordan best å konfigurere jobber for å få mest vårt på kontoret rutenett. Til slutt, et avsnitt eller to om å sende inn resultater tilbake til jobb-kontroll serveren ble presentert.

• En jobb kontroll server administrerer jobber og sørger for at alle arbeidsenheter er fullført
• Ved å abstrahere jobben velger / resultater innlevering vi kan endre teknologien på kontrollen serveren uten mye problemer
• Konfigurer jobber for å sikre at de kjøres raskt og effektivt uten å sette for mye press på nettverkets infrastruktur, og uten å duplisere prosessering oppgaver på en jevnlig basis.
• Pass på at du bygger feiltoleranse og feil checking inn i rutiner, kan arbeidstakere oppheve og gjenoppta og den mest upraktisk ganger. Husk å sjekke om resultater har allerede blitt sendt inn av en annen arbeidstaker.

Neste gang

I del 3 vil vi lage vår virtuelle behandling maskin og sette opp vinduene våre maskiner for å bli inaktiv-tid arbeidere.

One Response til "Office Grid Computing bruke Virtual miljøer - Del 2"

1. Hydrolyserer sier:

   Torsdag 18. februar 2010 kl 19:11

   Heya! Bra konsept, men kan dette virkelig gjøre jobben?

   Svar