Kommentarer (0)

Ved Steven Lloyd Watkin , søndag 27 mars 2011 24:57

Dette innlegget vil raskt vise deg hvordan du setter opp proxying med grunnleggende godkjenning ved hjelp av Apache .

I mitt tilfelle ønsket jeg å ha girkasse bit torrent-klienten tilgjengelig over internett, så jeg kunne sjekke om staten og adminster torrent nedlastinger (for eksempel de nyeste fedora release) etter behov. Transmission selv driver sin web-klient på port 9091 som standard. Snarere enn å bry åpne opp for flere porter på brannmuren min og legge til nessecary port forwarding regler Jeg bestemte jeg ville bare proxy samtalene gjennom til overføring via apache bruker mod_proxy .

Fortsett å lese 'Apache proxy med fordøye godkjenning' »

Kommentarer (0)

Ved Steven Lloyd Watkin , søndag 12 desember 2010 16:19

Sammendrag

Dette er en kjapp post for å diskutere ganske enkel visning hjelper jeg laget for å gjengi en Zend Framework stil vise filen hvis den finnes. Vanligvis ber koden til å gjengi en fil som ikke eksisterer vil kaste et unntak. Derfor har jeg laget en wrapper for Zend_View:: render ()-metoden som fastsettes om filen finnes, og hvis så gjengir, ellers bare returnerer en tom streng.
Fortsett å lese 'Zend Framework: Render Hvis eksisterer' »

Kommentarer (7)

Ved Steven Lloyd Watkin , torsdag 30 september 2010 21:00

Med den offisielle utgivelsen av Zend Certified Engineer (ZCE) program for 5,3 tenkte jeg jeg skulle gi min raske inntrykk av hva jeg tenkte på eksamen.

Litt bakgrunnsinformasjon om meg selv: Jeg ble først introdusert til PHP ca 7 år siden og har jobbet profesjonelt i PHP siden 2006. Jeg arbeider i dag for en spennende start-up kalt Brightpearl basert i Bristol, UK , produserer integrerte CRM, regnskap, og e-handel programvare. Jeg har ikke tidligere fått noen av de tidligere ZCE kvalifikasjoner. I øyeblikket utvikler i 5.2.X serien, og har egentlig ikke brukt noen av de spesifikke 5.3 funksjoner (jeg venter på Zend Framework 2 og Lære 2) i min utviklingsprosjekter.
Fortsett å lese 'Zend Certified Engineer (ZCE) 5,3' »

Kommentarer (2)

Ved Steven Lloyd Watkin , tirsdag 16 februar 2010 20:48

Som en oppfølging til mitt tidligere innlegg om per modul basert layout innstillingene for Zend Framework , har jeg oppdatert koden til å kreve mindre konfigurasjonen enn før (ikke at det kreves mer at noen få linjer i din søknad konfigurasjonen!).
Fortsett å lese 'Zend Framework Per Module Layout Innstillinger - Følg opp' »

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

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. Jobs take 1 minute to run: This means that your workers take about 15 minutes to run each job. 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. You're also going to put more strain on your job processing server as it has to dish out lots and lots of small pieces of work on a regular 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. 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.

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.

In Part 4 we looked at using tools to ensure that we're running the latest version of the code and data sources so that obtained results are always up-to-date with the latest business information and logic.

Pre-Deployment

Before deploying your grid system if there's one thing you do and one thing alone it's benchmark your current system ! No matter what you tell colleagues about how much extra work your system is going to do unless you have numbers to back this up your guarantees are nothing. So,

• how many records can you process currently? Per Day? Per Hour?
• How long does it typically take to turn around a job?
• How much more capacity do you have?

There's also additional questions:

• If your processing server (or one of your processing servers) goes down how will this affect your capabilities, will you be crippled?
• What advantages do you hope/expect to get from a grid system?
• Are your office machines capable of running the jobs?
• Are your (or can you jobs be converted) to wrok in this style of running?

The last major point is to take your time on any major change like this. Update your processing code to work using the new methodology, benchmark again. Possibly set up your processing server to run a virtual machine, after all your processing server will just be another worker (just a very powerful one relatively). Allow the new process to settle.

Distribusjon

My suggestion would be to pop into the office one weekend perform all the installations and setup. Do this just before a fortnight's holiday and leave so other poor chap to deal with the consequences… maybe not…

Deployment for a system like this needs to be slow. Despite it being relatively simple to set up this system will affect your entire office infrastructure (well the digital one). Firstly, roll out to a couple of machines at a time, monitor network traffic, how the worker hosts perform on a day-to-day basis. You may need to alter your job configuration in response to your findings.

Once the system has settled with a few machines (lets say 10% of all office machines, ie 5) keep monitoring network traffic and host machine performance. Next benchmark again, you should now be processing 33% more jobs than your first benchmarks. Check this is so, or that you're at least in this ballpark. If not, investigate what is going on before moving on. Repeat this cycle until you happily have all office machines running without killing individual machine performance or grinding your network to a standstill.

At all times keep benchmarking, even after all deployments are made. Check how new code updates affect speed of your system, check all workers are reporting in and processing jobs. Slowly (very slowly) increment your job configuration to get the best from your workers and network.

Stop!

What if you want to stop your workers from running at some time? They are all out there running, regenerating, and trying their best to process data like hungry insects. 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.

Kommentarer (3)

By Steven Lloyd Watkin , Saturday 28th November 2009 10:42 pm

My employer recently paid for a group of us developers to take the Zend Framework: Fundamentals course, here I'll summarise my thoughts and opinions on the course for others. For those looking to save time, here's my summary:

For developers who haven't had time to look at the Zend Framework this course (Zend Framework: Fundamentals) offers a good overall picture of the framework introducing you to the key areas and giving enough information in order to continue. For those who have spent time looking at the framework and have followed one or two tutorials this course does not offer much beyond.

Bakgrunn

I've been a PHP developer for around 5-6 years, and have started working with the Zend Framework on a component basis over the last 6 months. I've developed and/or been a developer on a couple of small Zend Framework MVC sites. I'll be honest, I haven't had a huge amount of exposure to other frameworks from a coding point of view but have spent several hours researching the project websites and evaluating them. The framework and the community surrounding Zend Framework it is quite exciting and there seem to be huge possibilities in where its going.

About the Course

The course is delivered over 9 two hour webex sessions (with a 10-minute break in the middle). The time is spent going through a set of slides provided by Zend with discussion at any time. You can use a microphone to talk to the instructor, but to be honest I didn't see anyone use anything more than the chat window. In addition a VMWare Ubuntu machine is provided that has example code and projects set up an a trial version of Zend Studio. The course leader talks to attendees either over an integrated VoIP solution, or you can dial in using one of the many worldwide dial in numbers.

During the course the material consists of a brief overview of the Framework and the MVC pattern before heading into a sample guestbook application. The discussion demonstrated bootstrapping, Zend_Application, Db Tables, Database access, Forms, Filtering, ACL, Validating, etc, etc. Basically covering all the topics you'd require to get a basic site up an running all the time giving you the tools to go and get more advanced in the framework (although this did amount to 'See the website' much of the time).

Time is given to code up some examples, and to develop the 'guestbook' and simple 'wiki' application. Personally I felt that providing the code or each app and then asking us to develop what was essentially a copy alongside didn't really provide a good learning experience. I would have preferred to develop an application similar, but not identical. to the example application with the benefit of having a guide to refer to. Alternatively building the applications from scratch with the demonstrator would of possibly led to more questions about why and how , thus giving a better understanding of the framework, after all you can look up specifics after the course.

The last lecture consisted of working on the wiki application with help/guidance from the instructor. After the course feedback was taken, it was emphasised several times through the course that Zend takes feedback very seriously, in fact apparently our version of the course was quite new. Some of the other developers in the company will be taking the course soon so it will be interesting to see if this has happened.

The course style was informal, allowed for feedback and collaboration between attendees and the instructor. The course leader was friendly, approachable (email addresses were shared for questions), and whilst his presentation from the slides was a bit shaky seemed fully competent in the framework. He was clearly someone who used the framework on a regular basis rather than someone who is taught to teach the course, I liked the 'real world' experience in that respect.

Overall Feeling

In some ways I found the course a waste of time, in others it was very handy. Hopefully I'll get my reasons across clearly, and maybe provide some food for thought or useful feedback (knowing me this is unlikely!).

For myself this course was aimed at too low a level. Having gone through the quickstart guide, read Rob Allen's Zend Framework in Action, and worked with the framework a little I didn't really get anything too much. I would of liked the course to pick up from the end of the quickstart and develop additional skills.

That said, the course title does clearly state “Zend Framework: Fundamentals ” and in that aspect the course achieves what it sets out to do. Other members of the development team that haven't spent the time looking into the framework finished each session with enthusiasm and asked questions which was really nice to see.

All was not lost, it was good to spend time confirming the basic details of the framework and get to ask a couple of questions in areas where I wasn't 100%. It was also time that I got to sit down each day and think about coding using the framework and future projects, something I wouldn't of been able to do otherwise (can you imagine your company agreeing to that? :) ). Last but not least you also get a nice certificate from Zend to say that you attended the course (albeit by email).

Zend Framework Certification

This was one question that kept coming to mind during the course, would it prepare me for the certification? The quick, easy is a resounding No . The course instructor was quite clear on that with the additional advice that for the certification you should really be using the framework on a day to day basis and feel very comfortable and confident in its usage and methodologies.

Sammendrag

Given everything I've written above, I'll summarise everything in two easy bullet points:

• New to Zend Framework: This course does exactly what you'd expect, it gives you a nice introduction to the framework and a good grounding on the basics from which you can build. The course seems to generate interest and enthusiasm for the framework amongst developers.
• Used the Zend Framework: While it was nice to shore up some of the very basics I felt the time, effort, and funds to take the course could of been better spent elsewhere. It will be nice to see Zend create a new higher level course to take developers to the next level – at least to the standard of certification and beyond. For that I would sign up immediately.