Innledning
Jeg jobber i et selskap hvor vi kjøre mange satsvise jobber behandling millioner av poster av data hver dag, og jeg har tenkt nylig om alle maskinene som sitter rundt hver eneste dag gjør ingenting for flere timer. Ville det ikke være bra hvis vi kunne bruke disse maskinene til å styrke behandlingskapasiteten til våre systemer? I dette settet av artikler jeg skal se på de potensielle fordelene ved å ansette et kontor rutenett med virtualiserte miljøer.
I del 1 ga jeg en oversikt over systemet og teknologiene jeg skal bruke så vel som diskutert noen av de mulige årsakene til at du ønsker å opprette et kontor rutenett.
Job Kontroll
Hvis du skal kjøre jobber så du kommer til å trenge noen måte å håndtere dem. Din jobb kontroll system (på jobben din server) må være veldig godt gjennomtenkt før du selv forsøker å kjøre et kontor rutenett. Så det første, hva er oppgaver for en jobb kontroll system:
- Del ut jobbene på forespørsel fra arbeiderne
- Fortell arbeidere hvilken type jobber å kjøre
- Spor jobber
- Sørg for at jobbene er kun kjørt en gang
- Gi jobbdata til arbeiderne, 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 et enkelt tilfelle kan utvides til å kjøre flere typer jobber som bedriften ser verdien i et rutenett løsning. For eksempel kan jobber gain prioriteringer, mer enn én type jobb kan foreligge (dvs. flere code baser), til slutt kan du også kjøre flere forskjellige arbeider 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 når utvikle systemer, kan et 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, bør dette være den eneste systemet i nettet ditt som har en fast resource locator, være at en IP-adresse, vertsnavn, URL (bruk av interne DNS), osv. Dette er fordi behov for arbeiderne å vite hvor du skal lete etter jobber, arbeidere trenger å finne den jobben kontrollsystemet (ikke jobben kontrollsystemet finne arbeiderne).
Jobben serveren selv egentlig ikke har en komplisert oppgave (i et grunnleggende system hvertfall), det er behov for å lagre en liste over jobber, dele ut jobber, får resultater, og deretter lagre dem for senere henting. Hvordan disse delene (som "hand out jobber") er definert kan være svært grunnleggende. Senere kan vi utvide systemet til å inkludere et administrasjonsgrensesnitt for å legge til, redigere, slette, suspendere jobber, men dette er hinsides denne øvelsen.
Det er ingen grunn overhodet da at jobben din server ikke kunne være en virtuell maskin som kjører innenfor ditt viktigste behandlingen serveren forutsatt at det ikke tappe for mye ressurser fra det. Jobben server imidlertid ikke trenger høy tilgjengelighet, hvis det går ned på en fredag kveld du kommer til å miste en hel helg med behandling, potensielt koste deg et par uker igjen av behandlingstid (i forhold til dine viktigste behandlingen server alene) . Det kan være lurt å vurdere å sette jobben din server på et lass balansert miljø for høy tilgjengelighet.
Basic Setup
Den grunnleggende oppsett for jobben vår server vil bestå av det jeg kaller en av mine halting servere (som er Li Nux, m ySql, P HP). Koden som kjører på thea arbeiderne faktisk vil finne ut hvilke jobber det kan kjøres ved å samhandle med med jobb styresystem databaser. Senere kunne vi lage en web-tjeneste og faktisk dele ut jobbene i stedet for at arbeiderne gjøre jobben selv, men for nå vil vi fortsette å bruke KISS prinsippet (Keep it Simple, Stupid!).
Så lar opprette tre mySQL tabeller å forholde seg til jobber. Disse vil bli `arbeidsplasser`, `jobRecords` og `jobResults`.
Her Jeg bruker SQL Buddy en flott liten alternativ til phpMyAdmin bare fordi det enklere å installere på CentOS (for andre ser: 10 Great alternativer til phpMyAdmin )
Denne tabellen består av 5 enkle felt,
- id: Entydig identifikasjon 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 begynte å gjøre jobben? Dette er ikke helt nødvendig, men er en fin å ha. Jeg vil foreslå sporing arbeiderne ved deres IP-adresse på nettverket ditt
- started_at: Når begynte arbeideren starte jobben? Ved å spore jobber som ikke har fullført innen X tid vi vet at vi trenger å plukke opp jobben igjen og starte behandling av en annen arbeidstaker. Arbeiderne kunne stoppe behandlingen / go offline for en rekke årsaker, strømbrudd, crash, nettverk tap, etc.
Det er lett hvordan denne tabellen kan utvides med noen ekstra felter for å tillate statistikk sporing, 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 gå av og på. I mer kompliserte jobben scenarier vil det være mulig å angi hvor mye minne arbeidstakeren ville ha tilgang til (og derfor bare bruke egnet arbeidere), eller hva slags arbeideren skulle være nødvendig.
Lar legge til noen få eksempel jobber:
Den neste bordet igjen er ganske enkel å forstå, dette er vår jobb poster. De er knyttet til de viktigste jobbene tabellen etter en kolonne `jobs_id`. Den utgjør i denne tabellen svært mye avhenger av dataene du trenger for å levere til arbeiderne, kan lage et veldig enkelt eksempel der vi har fire kolonner:
- id: ID av 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 tabellen, har det mye den samme sminke som våre poster bord, og med tillegg av noen kolonner kan være en del av postene tabellen:
- job_record_id: Link resultatet til jobben bordet
- Resultatet: Resultatet data
... Og det er alt du trenger for jobb kontroll! (Riktignok på et veldig grunnleggende nivå) I mitt tilfelle er jeg pekte til et annet bord hvor mine data til prosessen var plassert, men dette kunne like gjerne vært en fil, parametere å kjøre simulering kode, you name it.
Velge en jobb
Som nevnt tidligere, vil arbeiderne gjøre jobben vår ledelse 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 jobben vår utvalgskriterier og lete etter jobber, i SQL gjorde jeg følgende:
- Ta noen jobber som ikke er merket som komplett, men fra arbeideren vår og nullstille dem (innbytter __ME__ med en identifikator, ville enkleste være IP-adresse):
UPDATE `jobb` SET `status` = 0 HVOR `status` = 1 AND `started_by` = __ME__;
- Ved hjelp av vår jobb seleksjonskriterier, velger du en jobb og fortelle kontrollsystem som denne arbeideren har å gjøre med det:
UPDATE `jobb` SET `status` = 1, `started_by` = __ME__, `started_at` = NÅ () HVOR `status` = 0 eller
(`Status` = 1 AND `started_at`> DATE_SUB (NÅ (), INTERVALL X HOUR)) ORDER BY `id` ASC;
Ved å ta tak i jobber som ikke har returnert resultater i X tid vi sikre at alle jobber kjøres i tilfelle en arbeidstaker å krasje eller gå AWOL.
- Neste tak i jobbene detaljer etterfulgt av postene selv:
SELECT * FROM `jobb` HVOR `started_by` = __ME__ LIMIT 1;
SELECT * FROM `job_records` HVOR `id` = __JOBID__;
Ved ferdigstillelse av jobben vi sette inn våre resultat poster og mark jobben som fullført. Husk som jobber kan suspendere / gjenoppta når som helst la for noen robusthet i skriptet. Det kan være at oppgaven suspenderer halvveis gjennom oppdatering jobben kontrollsystem, så sjekker antall poster i en jobb og antall resultater lagres tilbake til jobben styresystem ville være et klokt trekk.
I tillegg, mens dette viser hvordan arbeidsplasser kan velges og styres fra en SQL-spørring ramme du bør 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 antall systemer det ikke vil påvirke koden over den.
Job Configuration
Den neste aspekt å vurdere er jobb størrelse og konfigurasjon. Ved å spille med jobben konfigurasjon kan vi slå en utmerket balanse mellom fart, prosess replikering, og pålitelighet. Ta et par Ofa scenarier:
- Jobber ta en dag hver for å kjøre: Dette betyr at arbeidstakere trenger 15 dager på å behandle hver jobb (husk 10% av kraften for 2/3rds av tiden). Dette er klart ikke en klok konfigurasjon, er jobben din størrelse altfor stort! Det ville ta minst dobbelt tid til å få en jobb behandlet bør den første arbeideren gå AWOL (tid for å plukke opp at det ikke har returnert et resultat pluss reprosessering tid). I en ideell ville du ha minst en hel jobb lett ryddet innen utgangen av hvert lang inaktiv periode, på den måten du beholde jobbene tikker over og i verste fall en jobb ville ta to dager å behandle bør først gå mangler.
- Jobs tar 1 minutt å kjøre: Dette betyr at arbeiderne tar ca 15 minutter å kjøre hver jobb. Mens dette kan i utgangspunktet virke perfekt, får du ytterligere arbeid behandling i løpet av lunsj, kaffepauser, møter, etc dette scenariet setter press på andre deler av systemet og innfører sine egne problemer. For eksempel det første oppsettet / behandlingstid forholdet kommer til å gå rett ned, derfor mister system effektivitet. Nettverket kommer til å være konstant streaming jobb informasjon til ulike arbeiderne frustrerende ansatte som er dong deres daglige arbeid. Du er også kommer til å legge mer press på jobben din behandling server som det har å dele ut masse små biter av arbeidet på en jevnlig basis. Til slutt, i denne situasjonen hvis jobben din server går ned du kommer til å skape et enormt tilbake logg over gjenstående arbeid mens større jobber kan for fortsatt behandling uvitende at jobben serveren opplevde vanskeligheter.
I realiteten vil det ikke være en ideell konfigurasjon for grid oppsett, avhenger mye 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 sannsynligvis inaktiv periode)
- Spill med jobben størrelse, slik at oppsett tid blir relativt ubetydelig i forhold til saksbehandlingstiden (med tanke på ovennevnte punkt).
- Hvis en jobb ikke fullføre i det doble av tiden (kanskje mindre) du forventer det å fullføre den anta at dets gått AWOL og begynne å behandle den med en annen arbeidstaker. Dette betyr at du kanskje må vente opp til tre ganger normal lengde av en jobb for det å fullføre (muligens lengre hvis den påfølgende jobben feiler). Du ønsker kanskje å redusere denne tiden, men vær forsiktig med å redusere det altfor mye du kan begynne å duplisere behandling oppgaver på en jevnlig basis.
- Jobs skal være uavhengig av eksterne krav så mye som mulig. Jobben server, for eksempel, skal kun bli kontaktet ved starten og slutten av hver eneste jobb.
- Ikke mette nettverket ditt, vil dette ha to negative effekter, vil dagtid personalet finne bruker nettverket frustrerende og problemer kan oppleves med forbindelser timing ut et problem som bare vil bli verre etter hvert som du skalere rutenett.
- Sikre arbeidsplasser kan kjøre på de ansatte. Dersom arbeidsplasser blir for minneintensive eller diskplass intensive arbeidsplasser vil starte avbryte og det eneste du vil merke en nedgang i antall arbeidsplasser behandlet med noen reell grunn til hvorfor.
Sende Resultater av en jobb
Når du sender resultatene av en jobb det er viktig å sjekke at resultatene ikke har blitt sendt inn av en annen arbeidstaker, særlig hvis den aktuelle arbeidstakeren har vært sovende i noen tid.
Når resultatene er sendt inn at antall resultater samsvarer med antall poster i jobben.
Som nevnt tidligere, og kan ikke være over understreket, bygge feiltoleranse inn jobbgjenfinning og resultater underkastelse. Arbeiderne kan (og mest sannsynlig vil) gå inn i hvilemodus på det mest ubeleilig ganger, og dette må tas hensyn til. Også en gang abstrahere bort resultatene innsending vil hjelpe dekke fremtidige endringer i jobben din kontrollsystem mye lettere å håndtere.
Oppsummering
I denne section har vi sett på hva en jobb kontroll server trenger å gjøre og hvordan du får en veldig grunnleggende system satt opp. Vi diskuterte hvordan man skal hente en jobb fra kontrollsystemet og hvordan de best kan konfigurere jobber for å få mest mulig vår på kontoret bæresystem. Til slutt, var et avsnitt eller to på sender resultater tilbake til jobben kontrollere serveren presenterte.
- En jobb kontroll server administrerer jobber og sørger for at alt arbeid enheter er fullført
- Ved å abstrahere din jobb å velge / resultater innsending kan vi endre teknologi for kontroll serveren uten mye problemer
- Konfigurer jobber for å sikre at de kjøres raskt og effektivt uten å legge for mye press på nettverket infrastruktur, og uten å duplisere behandling oppgaver på en jevnlig basis.
- Sørg for at du bygger feiltoleranse og feiling checking inn i rutiner, kan arbeiderne avbryte og fortsette og de 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 vår windows maskiner for å bli inaktiv tid arbeidere.
Kommentarer (4) 
Artikler , PHP , Web Programming , Zend Framework | 
rammeverk , ini , PHP , Ruter , ruter , Zend , Zend Framework , Zend_Navigation , Zend_Router 
