Evilprofessor.co.uk »Grid Computing

Kategori: Grid Computing

Office Grid Computing använda Virtuella miljöer - Del 4

Genom Steven Lloyd Watkin , fredag 4 dec 2009 11:59

Inledning

Jag arbetar i ett företag där vi bedriver många batchjobb bearbetning miljontals poster av data varje dag och jag har tänkt nyligen om alla de maskiner som sitter runt varje och varje dag gör ingenting i flera timmar. Vore det inte bra om vi kunde använda dessa maskiner att stärka processorkraften i våra system? I denna uppsättning av artiklar jag kommer att titta på de potentiella fördelarna med att anställa ett kontor rutnät med hjälp av virtualiserade miljöer.

I del 3 har vi skapat vår virtuella bearbetning dator och konfigurera Windows-maskiner för att bli sysslolös deltidsarbetande.

Köra den senaste koden

Oundvikligen När du har skapat dina arbetare affärslogik kommer att förändras, kommer buggar hittas, kommer snabbare och mer effektiv kod produceras vilket lämnar dina arbetare satt runt bearbeta data med hjälp av gamla illaluktande kod . Hur då ser vi till att vi alltid använder den senaste och bästa versionen av vår bearbetning av manus?

Det finns några mycket enkla enkla sätt vi kunde göra detta, tricket är dock att minska processorkraft och nätverkstrafik för att uppnå detta. Låt oss börja med den enklaste av lösningar och förbättra den långsamt under ett par iterationer.

Den första metoden skulle vara att helt enkelt ansluta till vårt jobb Control Server (via samba, ftp, eller liknande) och dra ner den senaste versionen av koden. Inte särskilt effektivt, men det kommer att göra jobbet. Låt oss förbättra det lite, vad sägs om att skapa en rsync manus och använda det varje gång istället? Alternativt vad om att sätta våra senaste bearbetning manus till subversion kolla in koden från början och sedan bara uppdatera vår kod på varje körning ( svn update )?

Till slut kunde vi sluta med ett bash skript (kallas av cron varje 10 minuter) som ser ut så här enkel:

  #! / Bin / sh
 om PS AX | grep-v grep | grep php > / dev / null
 sedan
     echo "Job bearbetar för närvarande, avfart"
 annat
     echo "Job inte är igång, börja nu"
     cd / sökväg / till / arbeta / kopiera
     svn update
     php yourJobProcessingScript.php
 fi

Nu kan vi vara säkra på att för varje gång vi definitivt kör den senaste koden. Vi säkerställer detta genom att uppdatera vår kodbas varje gång vi gör en körning och minska nätverkstrafiken genom att bara överföra filen skillnaderna mellan vårt nätverk.

I min demonstration inställning, jag gjorde exakt som ovan. Subversion installerades på mitt jobb bearbetning server och jag helt enkelt drog den senaste koden från en arbetstagare gren med hjälp av "svn update". Jag har också lagt till en tagg versionsnumret till min bearbetning manus som var tillbaka till den databas som en del av resultaten tillbaka. På så sätt kunde jag se att min kod var att uppdateras varje gång jag kopierat mina stammen till arbetstagaren grenen säga att jag definitivt var kör den senaste bearbetningen manus.

Med den senaste uppgifterna

Om ditt jobb bearbetning använder datakällor sedan någon gång dessa kommer att uppdateras också. Om du inte ringa din datakällor på ett mycket ovanligt grund du kommer att översvämma ditt nätverk med trafik så snart som dina arbetare börja springa föra allt till ett stillastående. För min lösning jag bestämde mig för att jag vill flytta mina datakällor runt med mina virtuella maskiner.

Håll du är hästar där! Vad händer om min datakällor är enorma? Ja detta är verkligen ett fall av hur mycket data talar vi? Det kan vara mer kostnadseffektivt att installera ytterligare en större hårddisk i varje maskin än att köpa en ytterligare bearbetning server. Detta är en fråga om budget och är upp till företaget att avgöra. Det kanske att dina datakällor är så stora att det bara omöjligt att hålla den mängd data i din arbetsdatorer. I så fall vad skulle du göra? Väl vi kan titta på kalla en lokal data-server, men detta kan orsaka problem med nätverket. I detta fall ett rutsystem som detta kan bli orealistiskt att inkludera i din kontorsmiljö. Det kan också vara så att du kan titta i alternativ drift strategier, till exempel bara att ringa dina arbetare från 20:00 till 06:00 varje kväll och / eller strypning dataförfrågningar källa.

Flytta på låt säga våra datakällor uppgår till 100 GB data. Jo det är ganska lite data för att flytta runt på nätet på en uppdatering. Hur skulle vi se till att vi har de senaste kopia av informationen i detta fall? Rsync är en möjlighet, men personligen tror jag genom att köra ditt senaste datakälla på ditt jobb bearbetning server och sätta upp detta som en mästare i replikering (med en fin lång bin log) kan vara vägen att gå:

Genom att ställa alla dina arbetstagare upp som slav till servern kontroll över arbetet uppdateringar av dina datakällor kommer att sippra ner fint till dina arbetare utan en enorm ökning av nätverksaktivitet (dvs om du inte gör en enorm uppgifter uppdateringen och alla dina medarbetare spark i på en gång). Detta har fördelar jämfört med rsync i att du inte skulle få en lång paus innan varje jobb, som databas uppdateringar, MySQL kommer demonen på din arbetstagaren kontinuerligt uppdatera sina uppgifter, medan behandlingen pågår.

Detta är hur jag in min demonstration server. För att ställa in replikering Jag följde guiden på mySQL plats ( Konfigurera replikering ) och inom 20 minuter hade jag min inital arbetare replikera kontroll över arbetet servrar dataset. För varje ytterligare anställd replikering inställningar och processen fungerat varje gång när VM kopierades.

Sammanfattning

I detta avsnitt av artikeln har vi tittat på hur enkelt och smärtfritt det är att hålla din processkod aktuell genom usingÂ rsync eller subverion (SVN) att göra jobbet och minska nätverkstrafiken på samma time.Â Vi diskuterade också hur att hålla din information om datakällan up-to-date genom att låta den sippra ner till alla dina anställda. Således har vi område se till att vi hänger med affärslogik och information i vårt kontor nätet. Det kommer givetvis att otaliga alternativ till att utföra dessa uppgifter, men här var två enkla exempel visa hur lätt en lösning är att komma med.

Nästa gång

I den sista delen av denna serie, det passande namnet Del 5 kommer vi att diskutera utbyggnaden av detta system. Jag ska sammanfatta vad som har lärt sig och vad jag lyckats skapa.

Artiklar , Datorer , Grid Computing , Linux , PHP , Webbprogrammering | uppdatering

Office Grid Computing använda Virtuella miljöer - Del 1

Kommentarer (1)

Genom Steven Lloyd Watkin , fredag 4 dec 2009 11:23

Inledning

Som en PHP- utvecklare jag ska använda verktyg som jag använder varje dag nämligen, Linux, MySQL , PHP, VirtualBox och Subversion (SVN). Men jag hoppas att denna guide kommer att anpassa sig till andra språk och teknik lika bra.

Lösningen ger jag kommer att vara mycket löst baserad på den typ av behandling skulle vi behöver för att uppnå detta kan emellertid inte vara sant genom hela artikeln som jag kommer att ändra saker för enkelhet, eller att producera mer intressant användning scenarier.

Dessa virtualiserade miljöer kommer att köras på Windows-maskiner eftersom det är vad majoriteten av kontor springa. De behandlingar som den kontorsmaskiner inte ska störa personalen använder dessa maskiner bör inte kräver något underhåll på maskinen och vara lätt att sättas till nya maskiner när de blir tillgängliga. Dessutom bör nya virtuella maskiner kräver ingen ytterligare konfiguration eftersom det kraftigt reducerar skalbarhet och lätthet med vilken nätet kan förlängas.

Varför Distribuera ett rutnät Office Computing?

Först du kanske tänker, varför inte bara använda en resurs cloud computing som Amazons EC2 plattform ? Jo anledningarna kan vara flera, till exempel:

Du får inte överlåta vissa uppgifter till ett moln datormiljö
Du kan inte sätta vissa data i en cloud computing miljö för juridiska skäl (t.ex. uppgifter att lämna landet), vilket kan av juridiska skäl, t.ex. NHS poster.
Du vill behålla din behandling enheter nära och har full kontroll över hårdvaran för
Du behöver inte projektmedel för att köra molnet instanser
Ditt kontor har inte en anslutning till Internet och därför inte möjligt att använda ett moln resurs
Du tycker inte om regn, moln föreslår regn, därför du håller borta

Jag är säker på listan skulle kunna fortsätta, men jag tror det räcker för nu.

Fördelar med ett Office Computing Grid

Tja, kan göra lite matematik (och i sann fysik stil kan göra några svepande antaganden). Tänk dig att du har stora biffiga bearbetning server som kör 100 jobb per dag. På kontoret har du 50 maskiner som står stilla 16 timmar om dygnet, alla dessa maskiner är 10% lika kraftfull som en biffiga bearbetning bryta. (Alla resultat här är avrundade till underskattar prestandaökning).

Så kan en maskin * 10% ström * 2 / 3 gång = 0,067 dvs en stationär bearbetning i dödtid process 6 fulla jobb per dag.

Om du nu skala upp detta tar det 15 tomgång stationära datorer för att behandla lika många jobb per dag som din huvudsakliga bearbetningen servern.

Så i vårt låtsas kontor på 50 maskiner vi kunde öka vår bearbetning av ström från en server upp till 4 hela bearbetning-servrar, eller vi kan vara bearbetning 400 jobb per dag istället för 100.

Lägg märke till några investeringar i ny hårdvara ditt företag har bara ökat sin kapacitet gruppbearbetning 4 gånger! Potentiellt du kommer att öka din elförbrukning utan från de flesta kontorsmiljöer Jag har varit i maskiner är i allmänhet kvar på natten ändå, så kunde man se detta som ett grönt initiativ.

Andra fördelar innebär också att investeringar i nya (eller uppdaterad) bearbetning servrar kan bli fördröjd om dina kontorsmaskiner är tillräckliga och att när du förbättrar styrkan i din kontorsmaskiner kontoret nätet blir mer kraftfull automatiskt.

Technologies

Vad du behöver? (Eller mer korrekt vad gjorde jag använder):

Idle kontorsmaskiner (i mitt fall en extra gamla Windows XP laptop)
VirtualBox (eller annan virtualisering klientprogram)
En virtuell maskin med PHP, mySQL runningÂ kör en skära ner OS, jag kallar dessa mina HALTA servrar:)
Jobb att köra
Job server (kan vara en annan virtuell maskin någonstans)

Typiska jobb

De typer av jobb som detta system är utformat för att köras är följande:

Systemet får en lista med data som vi behöver för att matcha och returnera resultat
Matchande innefattar kontroll / söker flera (ganska statisk) datakällor
Resultat från datakällor kan kräva ytterligare validering, sammanslagning, kontroll av ytterligare datakällor som svar på resultat
Data är tillbaka med matchande poster som är fullt validerade och bearbetas
Varje post i ett jobb är oberoende av resten

Så i princip vi tittar på att köra jobb som kräver en blandning av databas uppslagningar och några siffertuggande, ett ganska typiskt scenario i en företagsmiljö.

Grid lösningar är inte bara fördelaktigt för bearbetning jobb av denna typ. I princip kan varje process som kan delas upp i självständiga enheter köras parallellt. Se denna wikipedia för exempel och mer information: Grid Computing , men ett par kända exempel är Seti @ Home och BIONC . Det finns ramar för att köra data nät, och dessa är väl värda att titta närmare på.

Vad ska vi uppnå?

Vid slutet av dessa artiklar hoppas jag att visa att driftsätta ett kontor nätet behöver inte vara enormt dyrt eller tidskrävande. Jag kommer att diskutera:

Ställa in systemets kontroll över arbetet, jobb konfiguration
Skapa en lämplig behandling virtuell maskin
Hur man ställer in systemet på en Windows-maskin
Se till att du använder den senaste kod och data
Deployment och benchmarking
Framöver

Jag kommer att bygga (ok jag byggde, sedan skrev detta) ett exempel för att testa begreppen på en lokal dator med Windows XP och min "GridMachine" virtuell maskin. Mitt jobb Control Server kommer att bli min huvudsakliga dator som kör Fedora 11 .

Detta är på intet sätt tänkt att visa en fullt fungerande robust system, innebar att mer av en demonstration och diskussion som visar att dessa saker kan uppnås på ett relativt kort tid och till låg kostnad. Du är välkommen att skicka mig kommentarer, korrigeringar eller förbättringar och jag ska göra mitt bästa för att hålla den här artikeln uppdateras för att matcha.

Nästa gång

I del 2 kommer jag att börja med att titta på jobbet styrsystemet, och titta på hur jobben ska konfigureras för att uppnå största möjliga behandling och samtidigt se till att varje jobb är bearbetad utan att misslyckas.

Artiklar , Datorer , Grid Computing , Linux , PHP | parti , cron , databas , db , grid computing , tomgång , Linux , PHP , bearbetning , subversion , svn , virtuell , VirtualBox , fönster

Office Grid Computing använda Virtuella miljöer - Del 2

Kommentarer (1)

Genom Steven Lloyd Watkin , fredag 4 dec 2009 11:23

Inledning

I del 1 gav jag en översikt över systemet och teknik jag kommer att använda samt diskuterat några av de potentiella anledningar till varför du skulle vilja skapa ett kontor rutnät.

Kontroll över arbetet

Om du kommer att vara igång jobb då du kommer att behöva något sätt att hantera dem. Ditt jobb styrsystem (på ditt jobb server) måste vara väldigt väl genomtänkt innan du ens försöker att driva ett kontor rutnät. Så det första, vad är de uppgifter för ett jobb styrsystem:

Dela ut jobben på begäran från arbetare
Berätta för arbetare vilken typ av jobb att köra
Spår jobb
Se till att jobb bara köras en gång
Ge jobbdata för arbetstagare, eller åtminstone tala om för dem var att få det

Systemet behöver också utbyggbar, en lösning som fungerar för nu i ett enda fall kan utvidgas till att köra flera typer av jobb som branschen ser ett värde i ett rutnät lösning. Till exempel kan jobb vinna prioriteringar, mer än ett jobb typ kan finnas (dvs. flera kod baser), så småningom kan du även köra flera olika arbetsdatorer som är optimerade för varje typ av jobb (även om det rör sig bort från de "generiska arbetaren "idé). Försök alltid att tänka på framtiden vid utveckling av system kan ett kortsiktigt visionen att leda till längre sikt frustration och ökad utvecklingstid.

Job Server

Vi kommer att behöva någonstans att kontrollera våra jobb från bör detta vara det enda systemet i ditt nät som har en fast Resource Locator, vara så att en IP-adress, värdnamn, URL (med interna DNS), etc. Detta beror på arbetarna måste veta var man ska söka jobb, arbetare måste hitta systemet kontroll över arbetet (inte jobbet styrsystemet hitta arbetarna).

Jobbet servern själv inte riktigt har en komplicerad uppgift (i en grundläggande systemet i alla fall), behöver den för att lagra en lista med jobb, dela ut jobb, få resultat, och sedan lagra dem för senare hämtning. Hur dessa delar (till exempel "dela ut jobb") definieras kan vara väldigt grundläggande. Senare kan vi utvidga systemet till att omfatta ett administrationsgränssnitt för att lägga till, redigera, radera, avbryta jobb men detta är bortom denna övning.

Det finns ingen anledning då att ditt jobb servern inte kunde vara en virtuell maskin som körs i din huvudsakliga behandlingen servern förutsatt att det inte rinna för mycket resurser från det. Jobbet servern däremot behöver hög tillgänglighet, om det går ner på en fredag kväll du kommer att förlora en hel helg av behandling, eventuellt kostar dig ett par veckor till ett värde av handläggningstiden (jämfört med din huvudsakliga behandlingen servern ensam) . Du kanske vill överväga att sätta ditt jobb server på en lastbalanserade miljö för hög tillgänglighet.

Basic Setup

Den grundläggande inställningen för vårt jobb-servern kommer att bestå av vad jag kallar en av mina HALTA servrar (det vill säga Li Nux, m ySql, P hk). Koden körs på thea arbetstagarna faktiskt kommer att räkna ut vilka jobb det kan köras genom att interagera med med system jobbkontroll databaser. Senare kunde vi skapa en webbtjänst och faktiskt dela ut jobb snarare än att arbetarna gör det hårda arbetet själva, men nu ska vi fortsätta att använda KISS principen (Keep it Simple, Stupid!).

Så, kan skapa tre mySQL bord att ta itu med jobb. Dessa kommer att vara `jobb`, `jobRecords` och `jobResults`.

Här Jag använder SQL Buddy en stor liten alternativ till phpMyAdmin bara för att det är lättare att installera på CentOS (för andra ser: 10 bra alternativ till phpMyAdmin )

Denna tabell består av 5 enkla fält,

id: identifiera jobbet
namn: Kan vara en kundreferens, eller valfritt antal av andra identifieringsuppgifter
Status: Du måste veta var jobbet är på, t.ex.
- 0: Ej startat
- 1: Plockade upp
- 2: Genomförd
started_by: Vem började göra jobbet? Detta är inte helt nödvändigt men är ett trevligt att ha. Jag skulle föreslå att spåra arbetstagarna genom deras IP-adress på ditt nätverk
started_at: När började arbetaren börjar jobbet? Genom att spåra jobb som inte har avslutats inom X tid vi vet att vi behöver plocka upp jobbet igen och börja behandlas av en annan arbetare. Arbetare kunde stoppa bearbetning / gå offline för någon av flera skäl, strömavbrott, krasch, nätverk förlust, etc.

Det är lätt hur detta bord kan förlängas med några ytterligare fält för att möjliggöra statistik spårning, en sluttid kolumnen för att se hur lång tid jobbet tog, en räknare för att se hur många arbetare plockade upp jobbet (uppenbarligen detta måste tenderar att 1), jobb prioriteras, listan kan fortsätta och fortsätta. I mer komplexa jobb scenarion det skulle vara möjligt att ange hur mycket minne arbetstagaren skulle behöva tillgång till (och därför bara använda lämpliga arbetstagare), eller ens vilken typ av arbetstagare skulle krävas.

Låt oss lägga till några exempel på arbeten:

Nästa bordet igen är ganska enkel att förstå, det är vårt jobb register. De är kopplade till de viktigaste jobben tabellen genom en kolumn `jobs_id`. Den utgör i denna tabell beror mycket på de data som du behöver för att leverera till dina anställda, kan göra ett mycket enkelt exempel där vi har fyra kolumner:

ID: ID för den post
namn: personens namn
adress: Person adress
jobs_id: Jobbet ID som denna post är kopplad till

Den tredje och sista tabell består av ett resultat bord, har den ungefär samma utgör som våra register bord, och med tillägg av vissa kolumner kan vara en del av posterna tabellen:

job_record_id: Länk resultatet till jobbet bordet
Resultat: Resultatet uppgifter

... Och det är allt du behöver för jobbet kontroll! (Om än på en mycket grundläggande nivå) I mitt fall jag pekade på ett annat bord där min data för att processen var beläget, men det kan lika gärna varit en fil, parametrar att köra simulering kod, you name it.

Välja ett jobb

Som nämnts tidigare, kommer arbetarna att göra vårt jobb ledningen för oss för nu, så allt vi behöver verkligen göra är att hitta ett jobb som behöver behandling och få information. Hur skulle vi göra detta? Tja plocka våra kriterier jobb urval och söka jobb, i SQL gjorde jag följande:

Ta inga jobb som inte är märkta som kompletta men från våra arbetare och återställa dem (substitut __ME__ med en identifierare, skulle enklast kunna IP-adress):
```
  UPDATE `jobb` SET `status` = 0 där `status` = 1 och `started_by` = __ME__; 
```
Använda våra kriterier jobb, markerar du ett jobb och talar om för styrsystemet att arbetstagaren har att göra med det:
```
  UPDATE `jobb` SET `status` = 1, `started_by` = __ME__, `started_at` = NU () där `status` = 0 eller
 (`Status` = 1 och `started_at`> DATE_SUB (NU (), INTERVALL X HOUR)) ORDER BY `id` ASC; 
```
Genom att ta tag jobb som inte gav resultat i X tid vi se till att alla jobb körs i händelse av en arbetare krascha eller gå AWOL.

Nästa tag i jobb detaljer följt av journaler själva:

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

Efter avslutad jobb vi sätter vårt resultat register och markera det jobb som fullständig. Tänk så jobb kan avbryta / återuppta som helst utrymme för en viss robusthet i skriptet. Det kan vara att uppgiften avbryter halvvägs uppdatera systemet kontroll över arbetet, så kontrollera antalet poster i ett jobb och antalet resultat sparas tillbaka till jobbet styrsystemet skulle vara ett klokt drag.

Dessutom, samtidigt som detta visar hur jobben kan väljas och hanteras från en SQL-query ram du egentligen borde abstrahera ditt jobb kontroll så att om du väljer att byta till att använda en webbtjänst, en fil baserat system, XML , eller någon annan antalet system de inte kommer att påverka koden ovanför.

Job konfiguration

Nästa aspekt att beakta är jobbets storlek och konfiguration. Genom att spela med jobbet konfiguration kan vi hitta en bra balans mellan fart-, process-replikering och tillförlitlighet. Ta en scenarier par OFA:

Jobb tar en dag varje köra: Det innebär att dina anställda behöver 15 dagar för att behandla varje jobb (kom ihåg 10% av kraften för 2/3rds av tiden). Detta är uppenbarligen inte en klok konfiguration, är ditt jobb storleken alldeles för stor! Det skulle ta minst dubbelt så lång tid att få ett jobb bearbetas bör den initiala arbetstagaren gå AWOL (tid att plocka upp att det inte har återvänt ett resultat plus upparbetning tid). I en idealisk du skulle ha minst en fullt jobb lätt bort i slutet av varje lång inaktiv tid, så du behåller jobben tickar över och i värsta fall ett jobb skulle ta två dagar att processen bör den första go saknas.
Jobb tar 1 minut att köra: Det innebär att dina anställda tar ca 15 minuter att köra varje jobb. Även om detta initialt kan verka perfekt, du får extra arbete bearbetning vid lunchtid, kaffepauser, möten osv detta scenario sätter påfrestningar på andra områden i ditt system och introducerar sina egna problem. Till exempel, för det första din setup / handläggningstiden förhållandet kommer att gå rätt ner, därför förlorar systemet effektivitet. Ditt nätverk kommer att vara ständigt strömmande jobbinformation till de olika arbetarna frustrerande personal som dong deras dagliga arbete. Du kommer också att sätta större påfrestning på ditt jobb behandling servern som det har att dela ut massor av små bitar av arbete på en regelbunden basis. Slutligen, i denna situation om ditt jobb servern går ner du kommer att skapa en enorm baksida logg över slutfört arbete medan större arbeten kan en fortsatt bearbetning lyckligt ovetande att jobbet servern hade några svårigheter.

I verkligheten finns det ingen perfekt konfigurationen för din grid inställning, mycket beror på tillgängliga resurser, typer av jobb, extrajobb turnaround krav, nätverkskapacitet, och så vidare. Men några riktlinjer skulle vara:

Storlek jobb så att varje arbetstagare kan ta sig igenom minst 3-4 jobb i en period av 15 timmar (den längsta sannolikt inaktiv tidsperiod)
Spela med jobbet storlek så att ställtiderna blir ganska obetydlig jämfört med handläggningstiden (med tanke på ovanstående punkt).
Om en arbetssökande inte komplett i dubbla mängden tid (kanske mindre) du förväntar att slutföra det anta att dess gått AWOL och börja bearbeta den med en annan arbetare. Detta innebär att du kan få vänta upp till tre gånger den normala längden på ett jobb för att slutföra (möjligen längre om det efterföljande arbetet misslyckas). Du kanske vill minska den här gången, men var noga med att inte minska det alltför mycket som du kan börja dubblera bearbetning uppgifter på en regelbunden basis.
Jobb bör vara oberoende av externa krav så mycket som möjligt. Jobbet server, till exempel, bör endast kontaktas i början och slutet av varje jobb.
Inte mätta ditt nätverk, kommer detta att ha två negativa effekter så kommer ditt dagtid personal hittar med hjälp av nätverket frustrerande och problem kan upplevas med anslutningar timing ut ett problem som bara kommer bli värre när du skala ditt rutnät.
Se till att jobb kan köras på dina arbetare. Om jobben blir för minneskrävande eller diskutrymme intensivt jobb börjar avbryta och det enda du märker är en nedgång i antalet arbetstillfällen bearbetas med någon egentlig anledning.

Inlämning Resultat av ett jobb

När du skickar resultatet av ett arbete är det viktigt att kontrollera att resultaten inte har lämnats in av en annan arbetare, särskilt om den aktuella arbetstagaren har varit vilande under en tid.

När resultaten lämnas säkerställa att antalet resultat motsvarar det antal poster inom jobb.

Som nämnts tidigare, och kan inte nog understrykas, bygga feltolerans i jobb hämtning och resultat underkastelse. Arbetarna kan (och förmodligen kommer) att gå in i viloläge på den mest obekväma tider och detta måste tillgodoses. Också en gång abstrahera bort dina resultat ansökan kommer att hjälpa tillgodose framtida förändringar av ditt jobb styrsystemet mycket lättare att hantera.

Sammanfattning

I denna sectionÂ vi har tittat på vad ett jobb Control Server behöver göra och hur man får en mycket grundläggande system som inrättats. Vi diskuterade hur man hämtar ett jobb från styrsystemet och hur du bäst konfigurerar jobb för att få ut det mesta vårt för ditt kontor bärverk. För att avsluta, var ett stycke eller två om framläggning av tillbaka till jobbet styra servern presenteras.

Ett jobb Control Server hanterar jobb och ser till att alla arbetsenheter är klara
Genom att abstrahera jobbet välja / resultat underkastelse vi kan ändra tekniken för kontroll servern utan större problem
Konfigurera jobb att se till att de kör snabbt och effektivt utan att för mycket press på ditt nätverk infrastruktur, och utan dubblering bearbetning uppgifter på en regelbunden basis.
Se till att du bygger feltolerans och fel checkingÂ i dina rutiner, kan arbetstagare avbryta och återuppta och den mest obekväma gånger. Kom ihåg att kontrollera om resultaten har redan lämnats in av en annan arbetare.

Nästa gång

I del 3 ska vi skapa vår virtuella bearbetning maskin och sätta ihop våra Windows-maskiner för att bli sysslolös deltidsarbetande.

Artiklar , Datorer , Grid Computing , Linux , PHP , Webbprogrammering | ansökan , batch , databas , db , galler , kontroll över arbetet , jobb , Linux , MySQL , PHP , bearbetning , virtuell , VirtualBox , fönster

Office Grid Computing använda Virtuella miljöer - Del 5

Kommentarer (3)

Genom Steven Lloyd Watkin , fredag 4 dec 2009 11:03

Inledning

I del 4 har vi tittat på att använda verktyg för att säkerställa att vi kör den senaste versionen av koden och datakällor så att erhållna resultaten är alltid up-to-date med den senaste affärsinformation och logik.

Pre-Deployment

Innan du distribuerar din nätet om det finns en sak du gör och en sak bara det riktmärke ditt nuvarande system! Oavsett vad du talar om dina kolleger om hur mycket extra arbete ditt system kommer att göra om du inte har siffror att backa upp detta dina garantier är ingenting. Så,

hur många poster kan du bearbeta just nu? Per dag? Per timme?
Hur lång tid tar det normalt att vända ett jobb?
Hur mycket mer kapacitet har du?

Det finns också ytterligare frågor:

Om din behandling server (eller någon av dina bearbetning servrar) går ner hur kommer detta påverka din förmåga, kommer du handikappad?
Vilka fördelar hoppas du / räkna med att få från ett rutnät?
Är dina kontorsmaskiner som kan köra de jobb?
Är dina (eller kan du jobb omvandlas) att arbeta i denna typ av kör?

Den sista viktig punkt är att ta din tid på någon större förändring som denna. Uppdatera din processkod att arbeta med den nya metoden, riktmärke igen. Möjligen konfigurera din behandling server att köra en virtuell maskin, efter alla dina bearbetning servern kommer bara vara en annan arbetare (bara en mycket kraftfull en relativt). Låt den nya processen att lösa.

Deployment

Mitt förslag skulle vara att titta in på kontoret en helg utföra alla installationer och inställningar. Gör detta precis innan en fjorton dagars semester och lämnar så andra fattiga killen för att hantera konsekvenserna ... kanske inte ...

Deployment för ett system som detta måste vara långsam. Trots att det är relativt enkelt att inrätta detta system kommer att påverka hela ditt kontor infrastruktur (såväl det digitala en). För det första, rulla ut till ett par maskiner åt gången, övervaka nätverkstrafik, hur arbetaren är värd utföra på en dag till dag. Du kan behöva ändra ditt jobb konfiguration som svar på dina fynd.

När systemet har fast med ett par maskiner (låt säga 10% av alla kontorsmaskiner, dvs 5) fortsätta att övervaka nätverkstrafiken och värddatorn performance.Â Nästa riktmärke igen, bör du nu bearbetning 33% fler arbetstillfällen än din första riktmärken. Kontrollera detta är så, eller att du åtminstone i denna division. Om inte, undersöka vad som händer innan vi går vidare. Upprepa denna cykel tills du gärna ha alla kontorsmaskiner igång utan att döda enskilda maskinens prestanda eller slipning ditt nätverk till ett stillastående.

I alla tider att hålla benchmarking, även efter att alla installationer är gjorda. Kontrollera hur ny kod uppdateringar påverka hastigheten på ditt system, kontrollera alla arbetstagare redovisning och bearbetning av jobb. Långsamt (långsamt) påslag ditt jobb konfiguration för att få det bästa från dina arbetare och nätverk.

Stopp!

Vad händer om du vill avbryta dina anställda från att köra någon gång? De är alla där ute som kör, regenerering, och försöker sitt bästa för att bearbeta data som hungriga insekter. Svaret kan tyckas självklart men värt att lägga till i fall att det förbises. Enkelt redigera dina bearbetning manus med en exit (0) or die () eller något annat uttalande att döda dina bearbetning jobb. Ett viktigt skäl till att vi alltid försöker att uppdatera till den senaste behandlingen manus innan någon kör!

Demonstration System

För att kunna skriva denna rad korta artiklar jag skapat en mycket liten rutnät för att demonstrera tekniker och metoder. Jag läste massor av artiklar, självstudiekurser och använt olika verktyg för att ställa in och övervaka vad som pågick. På något sätt har jag gått ut och mättade en hel kontor med trafik och inte heller har jag haft tillgång till en ordinarie personal dator för att se hur värd resultatet påverkades.

Min demonstration systemet var mycket ödmjuk faktiskt. Jag använde min vanliga stationära inrättas som en kontroll över arbetet server. På denna hade jag installerat MySQL server installerad inrättas som en mästare i replikering, PHP , A och SVN länkas samman genom apache (för åtkomst via arbetare VM).

Jag skapade sedan en CentOS arbetsdator på VirtualBox på en 6 år gammal Windows XP-laptop. Jag installation schemalagda aktiviteter som anges efter att ha kopierat VM på maskinen och låt den gå.

Den virtuella maskinen bildades med PHP, omstörtande verksamhet, och mySQL. Jag kollade en gren som heter "arbetstagare" från mitt jobb styra servrar förvaret och såg till att det kan uppdateras med hjälp av "svn update". Nästa jag ställa MySQL som en slav och kontroll av att data replikerar från MySQL på jobbet kontroll servern ner till arbetstagaren VM. Efter allt detta jag ställa in bash script och cron-jobb.

Min bearbetning av manuset gick i stort sett i linje med detta (mycket enkla saker):

Läs i namnfältet
Räknade antalet liknande namn i en tabell från datakällan som hölls på VM
Räknade antal namn som ovan, men dela upp namn med mellanslag (t.ex. förnamn, mitten, efternamn)
Upprepade här processen 1000 gånger

Varje jobb tog ungefär 20 minuter att köra. Vid ett tillfälle öppnade jag flera kopior av arbetstagaren VM på fönstren laptop och såg de jobb kontrolleras av av var och en av adresserna arbetstagaren undersökningsperioden. Här vill jag också bekräftat att replikering automatiskt startas om.

Att lämna den bärbara datorn på tomgång resulterade i att en arbetstagare börjar bearbeta jobb från kontroll över arbetet servern. När återuppta laptop användning var det en fördröjning på cirka 30-60 sekunder, detta är en hel del tid och personal skulle behöva göras medvetna om att deras maskin kan pausa för en kort stund när de återvänder till maskinen. Nyare maskiner kan inte ha en paus på detta länge. Fördelen med hur mycket bearbetning som utförs av dessa maskiner under tomgång perioder skulle mer än uppväga anställda att behöva vänta en kort tid (säg 1 minut) vid ankomsten till deras maskiner om morgonen (jag väntar ofta längre än detta för en Windows Defender uppdatering ska ske), förutsatt att de var medvetna om detta (bra tid att ta en morgonkaffe!).

Sammantaget är jag övertygad om att jag har visat den teknik som skulle kunna användas för att skapa ett sådant system. Jag har visat att ett sådant system fungerar på ett (mycket) liten skala och med lite mer experimenterande kan skalas upp utnyttja resurserna i en kontors-maskiner. Om jag inte kommer till den punkt att göra detta skulle jag vara mycket intresserad av att veta / se när någon annan gör det.

Slutsatser / Utvärdering

Nästa självklara steg skulle vara att faktiskt få ett exempel från verkliga livet och börja distribuera ett system som detta i en kontorsmiljö och se vad som händer. Att be ett företag att engagera sig i detta utan ett spår flammande företaget att bevisa att tekniken och effektiviteten kan vara lite svårt. Grid / distribuerad databehandling är mycket populärt är vissa kretsar och har några stora program (BIONC, SETI @ Home, Folding @ Home, etc). Jag har dock inte hitta en mindre skala och enkelt system ut så här i mina sökningar som kan rullas ut i en kontorsmiljö.

Jag skapade en i princip gratis system med mestadels öppen källkod och verktyg som finns i nästan alla kontor. De tekniker som var i grunden visat och visar att uppträda och fungera som förväntat. Förhoppningsvis har jag visat att med inte mycket arbete och med en mycket enkel installation kan du distribuera en Office-systemet grid computing som är kraftfull, billig, A och skalbar alla på samma gång.

När ett system är igång det finns nästan ingen ände på hur mycket anpassning och förbättringar du kan göra. Till exempel statistik / benchmarking kan enkelt läggas visar värdet av ett sådant system varje dag. Nya maskiner kan läggas snabbt och enkelt och när de kommer med uppgraderingar av befintlig maskinvara stärka din processorkraft.

Jag hoppas du har njutit av att läsa denna serie av artiklar och gett dig en tankeställare om att köra ett system för kontor rutnät. Lösningen som presenteras här kommer inte nödvändigtvis fungerar i alla lägen men bör kunna anpassas så att du kan få dina databehandling sker med din egen lösning.

Du är välkommen att skicka mig kommentarer, korrigeringar eller förbättringar och jag ska göra mitt bästa för att hålla den här artikeln uppdateras för att matcha.

Artiklar , Datorer , Grid Computing , Linux , PHP , Webbprogrammering | apache , bash , batch , riktmärke , databas , driftsättning , galler , förbättra , Linux , MySQL , öppen källkod , PHP , replikering , subversion , virtuell , arbetare , Zend Framework , zned