Kommentarer (2)

Ved Steven Lloyd Watkin , fredag ​​4 desember 2009 11:59

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 3 skapte vi vår virtuelle behandling maskin og sette opp windows maskiner for å bli inaktiv tid arbeidere.

Kjører den nyeste kode

Uunngåelig etter at du opprettet arbeiderne forretningslogikk vil forandre, vil bugs bli funnet, vil raskere mer effektiv kode bli produsert dermed forlate dine arbeidere satt rundt behandling av data ved hjelp av gamle stinkende kode . Hvordan så sikrer vi at vi alltid bruker den nyeste og beste versjonen av vår behandling skript?

Det er noen veldig enkle enkle måter vi kunne gjøre dette, triks, derimot, er å redusere prosessorkraft og nettverkstrafikk i å oppnå dette. Lar starte med de enkleste løsningene og forbedre den sakte over et par iterasjoner.

Den første metoden ville være å bare koble til jobben vår kontroll server (via samba, FTP eller lignende) og trekk ned den nyeste versjonen av koden. Ikke veldig effektivt, men det vil gjøre jobben. Lar forbedre på at noe, hva med å skape et rsync skript og bruker den hver gang i stedet? Eventuelt hva med å sette våre siste behandling manuset til Subversion sjekke ut koden først, og så bare oppdaterer vår kode på hver kjøring ( svn update )?

Til slutt kan vi ende opp med et bash script (kalt av cron hvert 10. minutt), som ser så enkelt som dette:

  #! / Bin / sh
 hvis ps ax | grep-v grep | grep php > / dev / null
 deretter
     echo "Job er for tiden behandling, exit"
 ellers
     echo "Job ikke kjører, starter nå"
     cd / sti / til / jobbe / kopi
     svn update
     php yourJobProcessingScript.php
 fi 

Nå kan vi være sikker på at med hvert løp er vi definitivt kjører den nyeste koden. Vi er sikre dette ved å oppdatere våre kodebasen hver gang vi utfører en løpetur og redusere nettverkstrafikken ved bare å overføre filen forskjeller på tvers av nettverket vårt.

I min demonstrasjon setup, gjorde jeg akkurat som ovenfor. Subversion ble installert på min jobb behandling server og jeg bare trakk siste koden fra en "arbeidstaker" gren bruker 'svn update'. Jeg har også laget en versjon nummer tag til min prosessering manus som ble returnert til databasen som en del av resultatene retur. På denne måten kunne jeg se at min kode ble oppdatert hver gang jeg kopierte min trunk inn arbeideren grenen dvs at jeg var definitivt kjører den nyeste prosessering script.

Bruke nyeste dataene

Hvis jobben din prosessering gjør bruk av datakilder så på et tidspunkt disse kommer til å bli oppdatert også. Med mindre du ringe datakilder på en svært sjeldne basis du kommer til å oversvømme nettverket med trafikken så snart arbeiderne begynne å bringe alt til en stillstand. For løsning mitt bestemte jeg at jeg vil flytte dataene mine kilder rundt med mine VMer.

Hold du hester dit! Hva om mine datakilder er enorme? Vel, dette er virkelig et tilfelle av hvor mye data snakker vi? Det kan være mer kostnadseffektivt å installere en ekstra større harddisk til hver maskin enn å kjøpe en ekstra behandling server. Dette er et spørsmål om budsjett og er opp til virksomheten å bestemme. Det kanskje at datakildene er så store at det bare unfeasible å holde dette beløpet av data i arbeideren maskiner. I så fall hva ville du gjøre? Vel vi kunne se på ringer en lokal data server, men dette kan føre til problemer med nettverket. I dette tilfellet et rutenett system som dette kan bli urealistisk å inkludere i kontormiljøet. Kan det også være at du kan se på alternative kjører strategier, for eksempel bare å ringe dine arbeidere mellom 20:00 og 6am hver natt og / eller struping datakilde forespørsler.

Flytte på kan si våre datakilder beløpe seg til 100 GB med data. Vel ja det er ganske mye data å flytte rundt nettverket på en oppdatering. Hvordan ville vi sikre at vi har den siste kopien av dataene i dette tilfellet? Rsync er en mulighet, men personlig tror jeg ved å kjøre de nyeste dataene kilden på jobben din behandling server og sette dette opp som en mester i replikering (med en fin lang bin log) kan være veien å gå:

Ved å sette hver av dine ansatte opp som en slave til jobbkontroll server oppdateringer til datakilder vil sildre nedover pent til arbeidere uten en enorm økning i nettverk aktivitet (som er mindre du utfører en stor data oppdatere og alle arbeidere sparke i samtidig). Dette har fordeler framfor rsync på at du ikke ville få en lang pause før hver jobb, som database oppdateringer, mysql vil daemonen på arbeideren din kontinuerlig oppdatere sin data mens behandlingen fortsetter.

Dette er hvordan jeg setter opp min demonstrasjon server. For å sette opp replikering Jeg fulgte guiden på mySQL hotellet ( Sette opp replikering ) og innen 20 minutter hadde jeg min inital arbeideren kopiere jobben kontroll serverne datasett. For hvert ekstra arbeidstaker replikering innstillinger og behandle jobbet hver gang da VM ble kopiert.

Oppsummering

I denne delen av artikkelen har vi sett på hvor enkelt og smertefritt det er å holde prosessering kode oppdatert ved using rsync eller subverion (SVN) for å gjøre arbeidet og redusere nettverkstrafikken på samme time. Vi diskuterte også hvordan å holde datakilden informasjon up-to-date ved at det sildre ned til hver av arbeiderne. Dermed kan vi området som sikrer at vi holder tritt med forretningslogikk og informasjon på vårt kontor bæresystem. Det vil åpenbart være utallige alternativer til å utføre disse oppgavene, men her ble to enkle eksempler for å vise hvor enkelt en løsning er å komme forbi.

Neste gang

I den siste delen av denne serien, treffende navn Del 5 vil vi diskutere distribusjon av dette systemet for. Jeg skal oppsummere hva som har blitt lært og hva jeg klarte å skape.

Kommentarer (1)

Ved Steven Lloyd Watkin , fredag ​​4 desember 2009 11:23

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.

Som en PHP utvikler jeg kommer til å bruke verktøy som jeg bruker hver dag nemlig, Linux, MySQL , PHP, VirtualBox og Subversion (SVN). Men jeg håper denne guiden vil tilpasse seg andre språk og teknologier like bra.

Løsningen jeg gir blir svært løst basert på den type behandling vi hadde behov for å oppnå men dette kan ikke være sant gjennom hele artikkelen som jeg skal forandre ting for enkelhet, eller for å produsere mer interessant bruksscenarioer.

Disse virtualiserte miljøer som vil kjøre på windows maskiner siden dette er hva de fleste av kontorer løpe. Behandlingen at kontormaskiner ikke skulle forstyrre personalet bruker disse maskinene, bør kreve noe vedlikehold på maskinen, og være lett deployerbare til nye maskiner som de blir tilgjengelige. I tillegg bør nye virtuelle maskiner ikke krever noen ekstra konfigurasjonen som dette i stor grad reduserer skalerbarhet og lette der bæresystemet kan forlenges.

Hvorfor Distribuere et Office Computing Grid?

For det første du tenker kanskje, hvorfor ikke bare bruke en cloud computing ressurs som Amazons EC2-plattform ? Vel grunnene kan være flere, for eksempel:

• Du vil ikke overlate visse data til en cloud computing miljø
• Du kan ikke sette visse data i en cloud computing miljø for juridiske årsaker (f.eks data forlater landet), potensielt for juridiske årsaker, f.eks NHS poster.
• Du ønsker å holde processing units nært og har full kontroll over maskinvaren også
• Du har ikke prosjektmidlene til å kjøre sky tilfeller
• Kontoret ikke har en tilknytning til internett og derfor det ikke mulig å bruke en sky ressurs
• Du liker ikke regn, skyer foreslår regn, derfor holde god avstand

Jeg er sikker på at listen kunne fortsette, men jeg tror det er nok for nå.

Fordeler med en Office Computing Grid

Vel, lar gjøre litt matte (og i ekte fysikk stil lar gjøre noen feiende forutsetninger). Tenk deg at du har store beefy prosessering server som kjører 100 arbeidsplasser per dag. På kontoret har du 50 maskiner som er idle 16 timer i døgnet, hver av disse maskinene er 10% like kraftig som beefy prosessering sever. (Alle resultatene her er avrundet for å undervurdere ytelse økning).

Så kan en maskin * 10% strøm * 2 / 3 gang = 0,067 dvs 1 desktop behandling i idle tid prosessen seks fulle jobber per dag.

Hvis du nå skalere dette opp det tar 15 idle stasjonære å behandle så mange arbeidsplasser per dag som din viktigste behandlingen server gjør.

Så i vår late kontoret til 50 maskiner kunne vi øke vår prosesseringskraft fra en server opp til 4 full prosessering servere, eller vi kan behandle 400 arbeidsplasser per dag i stedet for 100.

Legg merke, for ingen investering i ny maskinvare firmaet har nettopp økt sin batch prosesseringskapasitet 4 ganger! Potensielt du kommer til å øke strømforbruket, men fra de fleste kontormiljøer jeg har vært i maskiner er generelt igjen på natten uansett, så du kan se dette som et grønt initiativ.

Andre fordeler også bety at investeringer i ny (eller oppdatert) behandling servere kan bli forsinket hvis kontormaskiner er tilstrekkelige og at når du forbedre ytelsen i kontormaskiner kontoret grid blir kraftigere automatisk.

Technologies

Hva du trenger? (Eller mer korrekt hva gjorde jeg bruker):

• Idle kontormaskiner (i mitt tilfelle en reserve gamle windows XP laptop)
• VirtualBox (eller et annet virtualisering klientprogramvaren)
• En virtuell maskin med PHP, mySQL running kjører et kutt ned OS, jeg ringer disse mine Limp servere:)
• Jobs til å kjøre
• Job server (kan være en annen virtuell maskin sted)

Typiske Jobs

Hvilke typer jobber som dette systemet er designet for å kjøre er som følger:

• System mottar en liste med data hvorpå vi trenger for å matche og returnere resultater
• Matching innebærer å sjekke / søker flere (ganske statisk) datakilder
• Resultater fra datakilder kan kreve ytterligere validering, sammenslåing, kontroll av flere datakilder i respons til resultater
• Data er tilbake med samsvarende poster, fullt validert og bearbeidet
• Hver post i en jobb er uavhengig av resten

Så i utgangspunktet vi ser på kjører jobber som krever en blanding av database oppslag og noen tallknusing, et ganske typisk scenario i et bedriftsmiljø.

Grid-løsninger er ikke bare en fordel for behandling jobber av denne typen. I utgangspunktet kan enhver prosess som kan deles inn i selvstendige enheter kjøres parallelt. Se denne Wikipedia for eksempler og mer informasjon: Grid Computing , men et par kjente eksempler er Seti @ Home og BIONC . Det er rammeverk for å kjøre databehandling rutenett, og disse er vel verdt å se inn.

Hva vil vi oppnå?

Ved slutten av disse artiklene håper jeg å vise at distribusjon av et kontor grid trenger ikke være veldig dyrt eller tidkrevende. Jeg kommer til å diskutere:

• Sette opp jobben styresystem, jobb konfigurasjon
• Opprette en passende behandling virtuell maskin
• Hvordan sette opp systemet på en windows maskin
• Sikre du bruker den nyeste kode og data
• Distribusjon og benchmarking
• Ser framover

Jeg vil bli bygget (ok jeg bygget, da skrev dette) et eksempel program for å teste konsepter på en lokal maskin med Windows XP og min "GridMachine" virtuell maskin. Min jobb kontroll serveren vil være min viktigste maskin som kjører Fedora 11 .

Dette er på ingen måte ment å demonstrere en fullt fungerende robust system, betydde det mer av en demonstrasjon og diskutere viser at disse tingene kan oppnås i en rimelig kort tid, og ved liten kostnad. Kan du gjerne sende meg noen kommentarer, rettelser eller forbedringer og jeg skal gjøre mitt beste for å holde denne artikkelen oppdatert å matche.

Neste gang

I del 2 vil jeg starte med å se på jobben kontrollsystemet, og se på hvordan jobbene skal være konfigurert for å oppnå størst mengde behandling samtidig sikre at hver jobb blir behandlet uten å lykkes.

Kommentarer (1)

Ved Steven Lloyd Watkin , fredag ​​4 desember 2009 11:23

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:

1. 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__; 

2. 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.

3. 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:

1. 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.
2. 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 (3)

Ved Steven Lloyd Watkin , fredag ​​4 desember 2009 11:03

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 4 så vi på bruk av verktøy for å sikre at vi kjører den nyeste versjonen av koden og datakilder, slik at oppnådde resultater er alltid up-to-date med de nyeste forretningsinformasjon og logikk.

Pre-distribusjon

Før du distribuerer din grid-systemet hvis det er én ting du og en ting alene, det er benchmark din nåværende system! Uansett hva du fortelle kolleger om hvor mye ekstra arbeid systemet kommer til å gjøre med mindre du har tall å sikkerhetskopiere dette opp din garantier er ingenting. Så,

• hvor mange poster kan du behandler for tiden? Per Day? Per Hour?
• Hvor lang tid det vanligvis tar å snu en jobb?
• Hvor mye mer kapasitet har du?

Det er også flere spørsmål:

• Hvis din behandling server (eller en av dine behandling servere) går ned hvordan vil dette påvirke dine evner, vil du bli lammet?
• Hvilke fordeler håper du / forventer å få fra et rutenett system?
• Er dine kontormaskiner kan kjøre jobbene?
• Er dine (eller du kan jobber bli konvertert) å arbeide i denne stilen av å kjøre?

Den siste store poenget er å ta deg tid på noen stor endring som dette. Oppdater prosessering kode for å arbeide med nye metoder, benchmark igjen. Muligens sette opp prosessering server for å kjøre en virtuell maskin, etter alle dine behandling serveren vil bare være en annen arbeidstaker (bare en veldig kraftig en relativt). La den nye prosessen å bosette seg.

Distribusjon

Mitt forslag ville være å stikke innom kontoret en helg utføre alle installasjoner og oppsett. Gjør dette rett før en fjorten dagers ferie og permisjon slik at andre stakkaren å håndtere konsekvensene ... kanskje ikke ...

Distribusjon for et system som dette trenger å være treg. Til tross for at det er relativt enkelt å sette opp dette systemet vil påvirke hele kontoret infrastruktur (godt digital en). For det første, rull ut til et par maskiner på en gang, overvåke nettverkstrafikk, hvordan arbeideren vertene utføre på en dag-til-dag basis. Du må kanskje endre jobben din konfigurasjon i svar på dine funn.

Når systemet har lagt seg med noen få maskiner (la oss si 10% av alle kontormaskiner, 5 dvs.) holde overvåking nettverkstrafikk og vertsmaskinen performance. Neste benchmark igjen, bør du nå være å behandle 33% flere arbeidsplasser enn din første benchmarks. Sjekk dette er slik, eller at du i alle fall i denne omtrentlig. Hvis ikke, undersøke hva som skjer før du går videre. Gjenta denne syklusen til du gjerne ha alle kontormaskiner kjører uten å drepe individuelle maskinens ytelse eller sliping nettverket ditt til en stillstand.

Til enhver tid holde benchmarking, selv etter at alle distribusjoner er gjort. Sjekk hvordan nye koden oppdateringer påvirke hastigheten på systemet ditt, sjekk alle arbeidere er rapportering og bearbeiding arbeidsplasser. Sakte (svært sakte) økning jobben din konfigurasjon for å få det beste ut av dine medarbeidere og nettverk.

Stopp!

Hva hvis du ønsker å stoppe arbeiderne fra å kjøre på noen gang? De er alle ute å kjøre, regenererende, og prøver sitt beste for å behandle data som sultne insekter. The answer may seem obvious but its worth adding just in case its overlooked. Simply edit your processing script with an exit(0) or die() or some other statement to kill your processing job. An important reason why we always try to update to the latest processing script before any run!

Demonstration System

In order to write this set of short articles I created a very small grid to demonstrate the technologies and methodologies. I read lots of articles, tutorials, and used various tools to setup and monitor what was going on. By no means have I gone out and saturated a whole office with traffic and nor have I had access to a regular staff members PC to see how host performance was affected.

My demonstration system was very humble indeed. I used my regular desktop set up as a job control server. On this I had installed mySQL server installed set up as a master in replication, PHP , and SVN linked through apache (for access via worker VM).

I then created a centOS worker machine on VirtualBox on a 6 year old windows XP laptop. I setup scheduled tasks as specified after copying the VM onto the machine and let it go.

The virtual machine was set up with PHP, subversion, and mySQL. I checked out a branch named 'worker' from my job control servers repository and made sure it could be updated using 'svn update'. Next I setup mySQL as a slave and checked that data was replicating from mySQL on the job control server down to the worker VM. After all this I setup the bash script and the cron job.

My processing script basically went along the lines of this (very simple stuff):

• Read in the name field
• Counted the number of similar names in a table from the data source held on the VM
• Counted the number of names as above but splitting the name by spaces (ie forename, middle, surname)
• Repeated this process 1,000 times

Each job took approximately 20 minutes to run. At one point I opened several copies of the worker VM on the windows laptop and watched the jobs be checked off by each of the worker IP addresses. At this point I also confirmed that replication automatically restarted.

Leaving the laptop to idle resulted in a worker starting to process jobs from the job control server. When resuming laptop usage there was a delay of about 30-60 seconds, this is a fair amount of time and staff would need to be made aware that their machine may pause for a short while when returning to the machine. Newer machines may not have a pause of this long. The benefit of the amount of processing performed by these machines during idle periods would more that outweigh staff members having to wait a short period (say 1 minute) on arriving at their machines of a morning (I frequently wait longer that this for a Windows Defender update to take place) provided they were made aware of this (useful time to grab a morning coffee!).

Overall I feel confident that I have demonstrated the technologies that could be used to create such a system. I have shown that such a system does work on a (very) small scale and with some more experimenting could be scaled up utilise the resources of an office's machines. If I don't get to the point of doing this I would be very interested to know/see when someone else does.

Conclusions / Evaluation

The next obvious step would be to actually get a real world example and start to deploy a system such as this within an office environment and see what happens. Asking a business to commit to this without a trail blazing company to prove the technology and effectiveness may be a little difficult. Grid/Distributed computing is very popular is some circles and has some large applications (BIONC, SETI@Home, Folding@Home, etc). I did not, however, find a smaller scale and simple system like this in my searches that could be rolled out within an office environment.

I created a basically free system using mostly open source software and tools available in almost any office. The technologies were basically demonstrated and show to perform and work as expected. Hopefully I have show that with not much work and with a very simple setup you can deploy an office grid computing system that is powerful, cheap, and scalable all at the same time.

Once a system is up and running there is almost no end to the amount of customisation and improvements you can make. For example statistics / benchmarking can easily be added showing the worth of such a system every day. New machines can be added quickly and easily as and when they arrive with upgrades to existing hardware bolstering your processing power.

I hope you've enjoyed reading this series of articles and its given you food for thought on running an office grid system. The solution presented here won't necessarily work in all situations but should be adaptable to allow you to get your data processing done using your own solution.

Please feel free to send me any comments, corrections, or improvements and I'll do my best to keep this article updated to match.