Kommentarer (2)

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

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

Kjører den nyeste koden

Uunngåelig etter at du opprettet arbeiderne forretningslogikk vil forandre, vil feil bli funnet, mer effektiv kode vil raskere bli produsert dermed forlater 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 finnes noen veldig enkle enkle måter vi kunne gjøre dette, kunsten, derimot, er å redusere prosessorkraft og nettverkstrafikk i å oppnå dette. Lar starte med de enkleste løsningene og forbedre den sakte over et par gjentakelser.

Den første metoden ville være å bare koble til vår jobb-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 en rsync skript og bruker den hver gang i stedet? Alternativt hva med å sette våre siste behandling skriptet til Subversion sjekke ut koden først, og så bare oppdatere våre 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
 da
     echo "Job er under gjennomgåelse, exit"
 annet
     echo "Job ikke kjører, starter nå"
     cd / sti / til / arbeid / kopi
     svn update
     php yourJobProcessingScript.php
 fi 

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

I min demonstrasjon oppsett, gjorde jeg akkurat som ovenfor. Subversion ble installert på min jobb behandling server og jeg bare trakk den nyeste koden fra en "arbeidstaker" gren med 'svn update'. Jeg har også lagt et versjonsnummer tag til min behandling script som ble returnert til databasen som en del av resultatene avkastning. På denne måten kunne jeg se at koden min ble oppdatert hver gang jeg kopierte min trunk inn arbeideren grenen vil si at jeg var definitivt kjører den nyeste behandlingen skriptet.

Bruker den nyeste dataene

Hvis jobben din behandling gjør bruk av datakilder og på et tidspunkt disse kommer til å bli oppdatert også. Med mindre du ringer datakilder på en veldig sjelden grunnlag du kommer til å oversvømme nettet med trafikk så snart arbeiderne begynne å bringe alt i stå. For løsningen min bestemte jeg meg for at jeg vil flytte dataene mine kilder rundt med min VMs.

Hold du er hester der! Hva om mine datakildene er HUGE? 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 dine datakilder er så store at det bare unfeasible å holde at mengden data i arbeidstaker maskiner. I så fall hva ville du gjøre? Vel vi kunne se på å ringe en lokal data-server, men dette kan føre til problemer med nettverket. I dette tilfellet et rutenett som dette kan bli urealistisk å inkludere i kontormiljøet. Det kan 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 kvele 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 på nettet 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 datakilden på jobben behandling server og sette dette opp som en mester i replikering (med en fin lang bin loggen) kan være veien å gå:

Ved å sette hver av de ansatte opp som en slave av jobb-kontroll serveren din oppdateres datakilder vil sildre ned pent til arbeidstakere uten en stor økning i nettverket aktivitet (som er mindre du utfører et stort data oppdatere og alle arbeidere kick i på en gang). Dette har fordeler over rsync i at du ikke ville få en lang pause før hver jobb, som database oppdateringer, på mysql på, vil arbeidstaker daemon kontinuerlig oppdatere data mens behandlingen fortsetter.

Dette er hvordan jeg setter opp min demonstrasjon server. For å sette opp replikering jeg fulgte guiden på MySQL stedet ( Sette opp replikering ) og innen 20 minutter hadde jeg min inital arbeidstaker kopiere jobben kontroll servere datasettet. For hvert ekstra arbeidstaker replikering innstillingene og prosessen jobbet hver gang da VM ble kopiert.

Sammendrag

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

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 å lage.

Kommentarer (3)

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

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 2 så vi på de jobbene en server vil kjøre, og hvordan arbeidsplasser bør være konfigurert for å oppnå mest mulig behandling samtidig sikre at hver jobb blir behandlet uten mislykkes.

Sette opp arbeidstaker - eller halte server

Det neste trinnet i prosessen er å sette opp virtuelle arbeidere. For dette skal jeg bruke en installasjon av CentOS med VirtualBox. Jeg kommer til å installere MySQL og PHP på serveren, også kjent som en slapp (Li Nux, m ySQL, P HP) Servera (jeg kan ha gjort at navnet opp).

• Installer VirtualBox på din Windows-maskin (følg link)
• Last ned og installer CentOS (gjeldende versjon 5.3) i løpet av et opprettet virtuell maskin

Det er ingen vits meg å gå til dette er det sannsynligvis 1000 er av stor tutorials der ute (ok, her er en: Lage og Managing CentOS virtuell maskin under VirtualBox ). Det viktige å merke jeg antar er at jeg kalte min virtuelle maskin GridMachine.

Så langt som mitt valg av virtualisering klient og operativsystem går er det ingen stor overbevisende grunn for hvert valg. VirtualBox er noe jeg bruker på min hjemme maskin og er støttet av de tre store operativsystemene. Jeg valgte CentOS som sin en god stabilt OS og jeg bruker det på min egen web server. Jeg er en stor tro på de riktige verktøyene for jobben (selv om jeg søker 'bruk den raskeste og enkleste for deg' mentalitet her), så hvis operativsystemet X kjører koden din raskere og mer effektivt å bruke dette i stedet:)

Viktigere sørge for at VM bruker DHCP, ellers for hver nye virtuelle maskinen må være konfigurert separat som er noe vi ikke want.By bruker DHCP, trenger vi ikke å konfigurere nettverksinnstillinger individuelt for arbeideren maskiner, vil DHCP hånd ut IP-adresser for deg. Derfor kan du kopiere den virtuelle maskinen rundt i kontoret uten å bekymre deg om å sette hver og en opp (det øker skalerbarhet og reduserer arbeidstaker administrasjon).

Prosessen du bør sikte på å oppnå ville være å få en ny fysisk maskin, installerer VirtualBox, og deretter ganske mye distribuere virtuelle bildet uten mye annet. Det kan være lurt å sette opp alle dine arbeidere på et annet subnett, slik at du kan i det minste se hvor mange maskiner kjører. Du må også sette opp maskiner på en lang lease eller ubegrenset lease DHCP.

Hvordan kjøre jobber på arbeideren

Dette er et interessant område, og det er mange metoder for prosessering jobber på arbeideren. Her skal jeg bare diskuterer de to mest åpenbare:

• Stadig kjører script: Et skript, enten det er en shell script, eller et PHP script kjøres en gang på arbeideren og løper som en del av en uendelig loop. Jeg har nedsatte denne metoden som en krasj på manuset og potensielt de ansatte vil slutte å kjøre uten noen form for intervensjon.
• Cron basert script gjennomføring: Hver X minutter cron daemon starter en samtale til skriptet for å få ting i gang. Uten noen sjekker dette kunne føre til mange mange kopier av arbeidstaker skript.

Min beslutning var å gå med cron som starter et shell script hver 10 minutes. Min shell script utfører følgende oppgaver:

1. Få en prosess liste og grep dette for 'php'. Hvis ikke funnet så videre.
2. Ring jobben din kode, i mitt tilfelle dette skulle være noe PHP basert
3. Worker script fullfører sin kjøre
4. Klar til å gå igjen på neste aktuelle samtalen

Min bash script ser omtrent slik ut:

  #! / Bin / sh
 Hvis ps ax | grep-v grep | grep php> / dev / null
 da
     echo "Job er under gjennomgåelse, exit"
 annet
     echo "Job ikke kjører, starter nå"
     php yourJobProcessingScript.php
 fi 

Merk: ekkoet's er nesten helt meningsløst, men kan bidra til den neste personen som kommer til å prøve og redigere dem.

Som konkluderer med oppsettet av arbeideren virtuelle maskinen, raskt, enkelt, og lett å kopiere til hver ny maskinvare som er mottatt. The 'klokskap' av rutenettet systemet egentlig ikke er i visualisert OS, det å gjøre med koden opprettet for å behandle jobber, jobben konfigurasjon, og i å sørge for at jobben går når det er hensiktsmessig (dvs. når verten er inaktiv ).

Sette opp Windows til å initiere Workers

Den første oppgaven er å trene kommandoen kreves for å kjøre den virtuelle maskinen fra vinduene kommandolinjen. Hvis du har installert VirtualBox i standard posisjon, og du har navngitt arbeidstaker GridMachine deretter kommandoen som kreves for å laste opp din arbeidstaker er:

  "C: \ Program Files \ sø \ VirtualBox \ VBoxManage.exe" startvm GridMachine 

Men å kjøre skriptet i en "hodeløs" state vi må bruke:

  "C: \ Program Files \ sø \ VirtualBox \ VBoxHeadless.exe"-startvm GridMachine - vrdp = off 

Dette starter den virtuelle maskinen uten GUI og la den for å spare staten grasiøst. Det andre argumentet slår seg av RDP så det ikke kommer i konflikt med vinduer RDP, eller gi deg en beskjed om å lytte på port 3389. Den virtuelle maskinen navn er store og små bokstaver!

Deretter må vi sette vinduer opp til kick off våre arbeidstaker VM når maskinen har vært inaktiv. For å gjøre dette (på Windows XP) du må gå Start -> Alle programmer -> Tilbehør -> Systemverktøy -> Planlagte oppgaver som følger:

Neste klikk på "Legg til planlagt oppgave" etterfulgt av bla å legge til et egendefinert program. Naviger til VBoxManage script og klikk ok. Planlegg din oppgave for noen av alternativene (vi kommer til å endre dette i ett minutt) og fortsette. Etter å hoppe over neste skjermbildet windows vil spørre deg hvem du vil kjøre denne oppgaven, vil jeg foreslå enten "Administrator" eller opprette en ny privilegert bruker. Husk at vi ikke ønsker å forstyrre den vanlige personalet konto på maskinen på noe punkt. Klikk Neste og sjekk vise avanserte alternativer for denne oppgaven.

Til slutten av kjøringen tekstboksen legge vår "startvm GridMachine 'streng og sikre at bare kjøre når du er innlogget er igjen unticked. Besøk planlegge oppgaven siden og endre planen falle ned til alternativet «når inaktiv", velge hvor mye tid du vil at maskinen skal være inaktiv før du går videre til neste kategori.

Endelig rotete alternativet som sier stopp aktiviteten hvis den har kjørt X tid, men kryss muligheten til å stoppe aktiviteten dersom maskinen er ikke lenger ledig.

Det er det da for windows host setup!

Sammendrag

I denne delen har vi satt opp en virtuell maskin til å fungere som en arbeidstaker, så vel som måten vi kaller og utføre jobben vår behandling skript (for meg et PHP script). Herfra ser vi på hvordan du setter opp vår kopier av vinduer for å starte opp den virtuelle maskinen i hodeløse modus når datamaskinen blir ledig, og lagre tilstanden når brukeren gjenopptar bruken av maskinen. Forhåpentligvis på dette punktet er du ser hvor enkelt det er å sette opp et slikt system, og er spent på å få noen eksperimenter gang selv!

Neste gang

I Del 4 vil vi se på bruk av verktøy for å sikre at du 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.

Kommentarer (1)

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

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.

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.

Den løsningen jeg gir vil bli 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 kommer til å endre ting for enkelhet, eller for å produsere mer interessant bruk scenarier.

Disse virtualiserte miljøer som vil kjøre på Windows maskiner siden dette er hva de fleste kontorer kjøre. Behandlingen at kontormaskiner gjør skal ikke forstyrre personalet bruker disse maskinene, ikke kreve vedlikehold på maskinen, og være lett deployerbare til nye maskiner som de blir tilgjengelige. I tillegg bør nye virtuelle maskiner ikke kreve nye konfigurasjonen som dette i stor grad reduserer skalerbarhet og enkelhet hvor rutenettet systemet kan utvides.

Hvorfor Deploy en 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 et cloud computing miljø
• Du kan ikke legge visse data i en cloud computing miljø for juridiske årsaker (f.eks data forlater landet), potensielt av juridiske grunner, f.eks NHS poster.
• Du ønsker å holde processing units tett og har full kontroll over maskinvaren også
• Du har ikke prosjektet midler til å kjøre sky forekomster
• Kontoret ditt har ikke en tilkobling til internett og derfor ikke mulig å bruke en sky ressurs
• Du trenger ikke liker regn, skyer foreslår regn, derfor kan du holde godt unna

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

Fordeler med en Office Computing Grid

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

Så, maskin * 10% power * 2 / 3 gang = 0.067 dvs. 1 desktop behandling i idle tid, kan en prosess 6 full jobb 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årt 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 jobber per dag i stedet for 100.

Legg merke, for ingen investering i ny maskinvare din bedrift har nettopp økt sin gruppebehandling kapasitet 4 ganger! Potensielt du kommer til å øke strømforbruket, men fra de fleste kontormiljøer Jeg har vært på maskinene er som regel igjen på natten uansett, så du kunne se dette som en grønn initiativ.

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

Technologies

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

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

Typiske Jobber

De typer jobber som dette systemet er utformet for å kjøre er som følger:

• System mottar en liste med data på som vi trenger for å matche og returnere resultater
• Matchende innebærer kontroll / 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 matchende 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, en ganske typisk scenario i et forretningsmiljø.

Grid-løsninger er ikke bare en fordel for behandling oppdrag 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 nett, og disse er vel verdt å se nærmere.

Hva vil vi oppnå?

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

• Sette opp jobben kontrollsystemet, jobb konfigurasjon
• Opprette en forsvarlig behandling virtuell maskin
• Hvordan sette opp systemet på en Windows-maskin
• Sikre du bruker den nyeste koden og data
• Distribusjon og benchmarking
• Ser fremover

Jeg skal bygge (ok jeg bygget, så 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 bli min største maskin som kjører Fedora 11 .

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

Neste gang

I del 2 vil jeg starte med å se på jobb-kontroll systemet, og se på hvordan jobbene skal være konfigurert for å oppnå mest mulig behandling samtidig sikre at hver jobb blir behandlet uten mislykkes.

Kommentarer (1)

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

Innledning

I work in a company where we run many batch jobs processing millions of records of data each day and I've been thinking recently about all the machines that sit around each and every day doing nothing for several hours. Wouldn't it be good if we could use those machines to bolster the processing power of our systems? In this set of articles I'm going to look at the potential benefits of employing an office grid using virtualised environments.

In Part 1 I gave an overview of the system and technologies I will be using as well as discussed some of the potential reasons why you would want to create an office grid.

Job Control

If you're going to be running jobs then you're going to need some way to manage them. Din jobb kontrollsystemet (på jobben din server) må være veldig godt gjennomtenkt før selv prøver å kjøre et kontor rutenett. So firstly, what are the tasks for a job control system:

• Hand out jobs upon request from workers
• Fortell arbeidere hva slags jobber for å kjøre
• Track jobs
• Ensure that jobs are only run once
• 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 example, jobs may gain priorities, more than one job type may exist (ie several code bases), eventually you may even run several different worker machines that are optimised for each type of job (although that does move away from the 'generic worker' idea). Always try to think about the future when developing systems, a short term vision can lead to longer term frustration and increased development time.

Job Server

We're going to need somewhere to control our jobs from, this should be the only system in your grid that has a fixed resource locator, be that an IP address, host name, URL (using internal DNS), etc. This is because the workers need to know where to look for jobs, workers need to find the job control system (not the job control system find the workers).

The job server itself doesn't really have a complicated task (in a basic system anyhow), it needs to store a list of jobs, hand out jobs, receive results, and subsequently store them for later retrieval. How these parts (such as 'hand out jobs') are defined can be very basic. Later on we can extend the system to include an administration interface to add, edit, delete, suspend jobs but this is beyond this exercise.

There is no reason whatsoever then that your job server could not be a virtual machine running within your main processing server provided it doesn't drain too many resources from it. 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.

Basic Setup

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.

It is easy how this table could be extended with a few additional fields to allow for statistics tracking, a finish time column to see how long the job took, a counter to see how many workers picked up the job (obviously this needs to tend to 1), job priority, the list can go on and on. 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; 

   By grabbing jobs that haven't returned results in X amount of time we ensure that all jobs are run in the event of a worker crashing or going 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__; 

Upon completion of the job we insert our result records and mark the job as complete. Remember as jobs can suspend/resume at any time allow for some robustness in your script. 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.

In addition, whilst this demonstrates how jobs can be selected and managed from an SQL-query frame you should really be abstracting your job control so that if you decide to switch to using a web service, a file based system, XML , or any other number of systems it will not affect the code above it.

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. Jobs take 1 day each to run: This means that your workers need 15 days to process each job (remember 10% of the power for 2/3rds of the time). This is clearly not a wise configuration, your job size is way too big! It would take at least double the time to get a job processed should the initial worker go AWOL (time to pick up that it hasn't returned a result plus reprocessing time). In an ideal you'd have at least one full job easily cleared by the end of each long idle period, that way you keep the jobs ticking over and at worst case a job would take two days to process should the first go missing.
2. Jobber tar 1 minutt å kjøre: Dette betyr at de ansatte tar ca 15 minutter å kjøre hver jobb. Whilst this may initially seem ideal, you gain additional work processing during lunch time, coffee breaks, meetings, etc this scenario puts strain on other areas of your system and introduces its own problems. For example, firstly your setup/processing time ratio is going to go right down, therefore losing system efficiency. Your network is going to be constantly streaming job information to the various workers frustrating staff who are dong their day to day work. 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. Lastly, in this situation if your job server goes down you're going to create a huge back log of uncompleted work whereas bigger jobs could of continued processing blissfully unaware that the job server was experiencing difficulties.

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. This means you may have to wait up to three times the normal length of a job for it to complete (possibly longer if the subsequent job fails). You may want to reduce this time, but be careful not to reduce it too much as you may start duplicating processing tasks on a regular basis.
• Jobs should be independent of outside requirements as much as possible. Jobben server, for eksempel, skal kun kontaktes i starten og slutten av hver jobb.
• Don't saturate your network, this will have two negative effects, your daytime staff will find using the network frustrating and problems may be experienced with connections timing out a problem that will only get worse as you scale your grid.
• Sikre arbeidsplasser kan kjøre på arbeiderne. If jobs become too memory intensive or disk space intensive jobs will start aborting and the only thing you'll notice is a drop in number of jobs processed with no real reason why.

Sende Resultater av en jobb

When submitting the results of a job it is important to check that results have not been submitted by another worker, especially if the current worker has been dormant for some time.

When results are submitted ensure that the number of results matches the number of records within the job.

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. Remember to check if results have already been submitted by another worker.

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.

Kommentarer (3)

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

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 4 ser 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 distribusjon din bæresystem hvis det er en ting du gjør og en ting alene, det er avkastningen fra nåværende system! Uansett hva du fortelle kollegaer om hvor mye ekstra arbeid systemet kommer til å gjøre med mindre du har tall å sikkerhetskopiere dette opp garantier er ingenting. Så,

• hvor mange poster kan du prosessen nå? Per dag? 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 forkrøplet?
• Hvilke fordeler håper du forventer / å komme fra et rutenett?
• Er kontormaskiner kan kjøre jobbene?
• Er dine (eller kan du jobber konverteres) til å arbeide i denne stilen med å kjøre?

Det siste store poenget er å ta tiden på noen stor endring som dette. Oppdater behandling koden til å fungere med den nye metodikken, benchmark igjen. Muligens sette opp behandlingen 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 nye prosessen for å avgjøre.

Distribusjon

Mitt forslag ville være å stikke innom kontoret en helg utfører alle installasjoner og oppsett. Gjør dette like før to uker ferie og forlater så andre stakkars fyren til å håndtere konsekvensene ... kanskje ikke ...

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

Når systemet har gjort opp med et par maskiner (kan si 10% av alle kontormaskiner, dvs. 5) holde overvåking nettverkstrafikk og vertsmaskinen performance. Neste benchmark igjen, bør du nå skal behandle 33% flere arbeidsplasser enn den første benchmarks. Sjekk dette er slik, eller at du er i alle fall i denne ballpark. Hvis ikke, undersøke hva som skjer før du går videre. Gjenta denne syklusen til du lykkelig alle kontormaskiner som kjører uten å drepe enkelte maskinens ytelse eller sliping nettverket ditt til en stillstand.

Til enhver tid holde benchmarking, selv etter all distribusjon er gjort. Sjekk hvor ny kode oppdateringer påvirker hastigheten på systemet ditt, sjekke alle arbeidstakere rapporterer i og bearbeiding jobber. Sakte (svært sakte) tilvekst jobben konfigurasjonen for å få det beste fra arbeidere og nettverket.

Stopp!

Hva om du ønsker å stoppe arbeidere fra å kjøre på en gang? De er alle der ute som kjører, regenererende, og prøver sitt beste for å behandle data som sultne insekter. Svaret kan synes opplagt, men det er verdt å legge i tilfelle den oversett. Bare redigere behandling script med en utgang (0) or die () eller noen andre utsagn å drepe behandling jobben. En viktig grunn til at vi alltid prøver å oppdatere til den nyeste behandlingen skriptet før noen kjører!

Demonstrasjon System

For å skrive dette settet med korte artikler jeg laget et veldig lite rutenett å demonstrere teknologi og metoder. Jeg leste masse artikler, veiledninger, og brukt ulike verktøy for å sette opp og overvåke hva som foregikk. På ingen måte har jeg gått ut og mettet en hel kontor med trafikk og heller har jeg hatt tilgang til en fast stab medlemmene PC for å se hvordan verten resultatene ble påvirket.

Min demonstrasjon systemet var svært ydmyk faktisk. Jeg brukte min vanlige desktop satt opp som en jobb-kontroll server. På denne hadde jeg installert mySQL server installert satt opp som en mester i replikering, PHP Â og SVN knyttet sammen, gjennom Apache (for tilgang via arbeidstaker VM).

Jeg så laget en CentOS arbeidstaker maskin på VirtualBox på en 6 år gamle vinduer XP laptop. Jeg setup planlagte oppgaver som spesifisert etter kopiering av VM på maskinen og la det gå.

Den virtuelle maskinen ble satt opp med PHP, Subversion, og mySQL. Jeg sjekket ut en gren som heter "arbeidstaker" fra jobben min kontroll servere depot og gjorde at det kunne bli oppdatert ved hjelp av 'svn update'. Neste Jeg setup mySQL som en slave og sjekket at data ble replikere fra mySQL på jobben kontrollen serveren ned til arbeideren VM. Etter alt dette jeg oppsett av bash script og cron jobben.

Min behandling script utgangspunktet gikk i retning av denne (veldig enkle ting):

• Les i navnefeltet
• Telles antall lignende navn i en tabell fra datakilden holdt på VM
• Telte antall navn som over, men å splitte navn med mellomrom (dvs. fornavn, mellomnavn, etternavn)
• Gjentatte denne prosessen 1000 ganger

Hver jobben tok ca 20 minutter å kjøre. På et tidspunkt åpnet jeg flere eksemplarer av arbeideren VM på vinduene bærbar PC og så på arbeidsplasser kontrolleres av ved hver av arbeidstaker IP-adresser. På dette punktet jeg også bekreftet at replikering automatisk startet på nytt.

Forlater laptop på tomgang resulterte i en arbeidstaker begynner å behandle jobber fra jobben kontrollen serveren. Når du gjenopptar laptop-bruk var det en forsinkelse på ca 30-60 sekunder, er dette en god del tid og ansatte trenger å bli gjort oppmerksom på at maskinen kan pause for en kort stund når tilbake til maskinen. Nyere maskiner kan ikke ha en pause på denne lange. Fordelen med mengden av behandlingen utføres av disse maskinene i idle perioder ville mer som oppveier ansatte å måtte vente en kort periode (si 1 minutt) på å komme fram til maskinene sine av en morgen (jeg ofte vente lenger på at dette for en Windows Defender Oppdateringen skal finne sted) forutsatt at de ble gjort oppmerksom på dette (nyttig tid til å ta en morgenkaffe!).

Samlet Jeg føler meg trygg på at jeg har vist de teknologiene som kan brukes til å lage et slikt system. Jeg har vist at et slikt system fungerer på en (veldig) liten skala, og med litt mer eksperimentering kunne skaleres opp utnytte ressursene i en kontorets maskiner. Hvis jeg ikke får til poenget med å gjøre dette ville jeg være veldig interessert i å vite / se når noen andre gjør.

Konklusjoner / Evaluering

Den neste opplagte steget ville være å faktisk få en reell verden eksempel og begynne å distribuere et system som dette i et kontorlandskap og se hva som skjer. Å be en virksomhet å forplikte seg til dette uten en sti flammende selskap å bevise teknologi og effektiviteten kan være litt vanskelig. Grid / Distribuert databehandling er svært populært er enkelte kretser og har noen store programmer (BIONC, SETI @ Home, Folding @ Home, etc). Jeg gjorde imidlertid ikke finne en mindre skala og enkelt system som dette i søkene mine som kunne rulles ut i et kontormiljø.

Jeg opprettet en i utgangspunktet fritt system hovedsakelig ved hjelp av åpen kildekode programvare og verktøy tilgjengelig i nesten alle kontor. Teknologiene var i utgangspunktet vist og viser til å utføre og arbeide som forventet. Forhåpentligvis har jeg vise at med ikke mye arbeid og med en veldig enkel oppsett kan du distribuere et kontor grid computing system som er kraftig, billig, Â og skalerbar alle på samme tid.

Når et system er oppe og går er det nesten ingen ende på hvor mye tilpassing og forbedringer du kan gjøre. For eksempel statistikk / benchmarking kan enkelt legges viser verdien av et slikt system hver dag. Nye maskiner kan legges raskt og enkelt som, og når de kommer med oppgraderinger til eksisterende maskinvare styrke din prosessorkraft.

Jeg håper du har likt å lese denne serien med artikler og gitt deg mat for tanken på å drive et kontor rutenett. Løsningen som presenteres her vil ikke nødvendigvis fungere i alle situasjoner, men bør kunne tilpasses slik at du kan få databehandling gjort ved hjelp av din egen løsning.

Kan du gjerne sende meg noen kommentarer, rettelser, eller forbedringer og jeg skal gjøre mitt beste for å holde denne artikkelen oppdatert for å matche.

Kommentarer (0)

Ved Steven Lloyd Watkin , søndag 11 oktober 2009 06:09

Hvis du nylig har oppgradert PHP eller Apache du kanskje komme opp mot spørsmålet om din webserver returnere tomme sider, og kaster feilmeldinger i loggene dine med ingen anelse hvorfor, her er en mulig måte å fikse det ...

Jeg har hatt dette problemet et par ganger nylig etter oppgradering Apache eller PHP på en virtuell maskin. Første gang jeg la merke til feilen jeg bare tilbake til en sikkerhetskopi av VM min, men den andre gangen jeg skjønte jeg måtte se nærmere på problemet.

Første gang jeg la merke til problemet noen av mine web-sider ble servert som tomme filer mens den andre fungerte helt fint. Etter noen undersøkelser jeg registrerer at apache skrev ut til / var / log / http / error_log med følgende melding repeatidly:

[Advarsel] barnets pid XXXX exit signal Segmentering feil (11)

Det er ikke allot å gå av på nettet, og de fleste av sidene om det sti av til ingenting. Som sagt, jeg snevret ned problemet til PHP krasjer når du prøver å unødvendige dynamiske biblioteker.

Ser på php.ini min (/ etc / php.ini) jeg kommentert ut all den dynamiske biblioteker lastet planlegger å kommentere dem tilbake på etter behov. De to jeg måtte ta ut hvor pdo.so og mysql . så.

Når disse var fjernet alle mine web-sider ble servert fine, akkurat som før PHP / Apache oppdatering.

Kommentarer (0)

Ved Steven Lloyd Watkin , lørdag 11 juli 2009 09:48

Som jeg har tilbrakt enda noen timer i dag uten tilgang til internett Jeg tenkte jeg skulle bedre få dette skrevet ned slik at neste gang jeg rotet meg bærbar PC opp informasjonen er lett å fikse.

Utgangspunktet for å få trådløse drivere jobber for en Acer 5002 WLMi må du bruke b43-fwcutter. Instruksjoner finner du her: Linux Wireless B43 .

Lett når informasjonen er plassert.