Kommentarer (3)

Genom att Steven Lloyd Watkin , fredag ​​4 dec 2009 23:37

Införandet

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

I del 2 tittade vi på de jobb en server kommer att köra, och hur jobben ska konfigureras för att uppnå största möjliga behandling och samtidigt säkerställa att varje jobb behandlas utan att misslyckas.

Ställa in arbetare - eller halta server

Nästa steg i processen är att ställa in dina virtuella anställda. För detta jag kommer att använda en installation av CentOS med VirtualBox. Jag ska installera mySQL och PHP på servern, även känd som börjar halta (Li Nux, m ySQL, P HP) Servera (jag kan ha gjort det namnet upp).

• Installera VirtualBox på din Windows-maskin (följ länk)
• Ladda ner och installera CentOS (nuvarande version 5,3) i en skapad virtuell maskin

Det är ingen idé jag gå till denna finns det nog 1.000-tals stora tutorials där ute (ok, här är ett: Skapa och Managing CentOS virtuella maskinen under VirtualBox ). Det viktiga att notera antar jag är att jag ringde min virtuell maskin GridMachine.

När det gäller mina val av virtualisering klient och operativsystem åka dit är ingen stor övertygande skäl för att varje val. VirtualBox är något jag använder på mitt hem maskinen och stöds av de tre stora operativsystemen. Jag valde CentOS som det är en bra stabil OS och jag använder det på min egen webbserver. Jag är en stor anhängare av rätt verktyg för jobbet (även om jag ansöker "använda den snabbaste och enklaste för dig" mentalitet här), så om operativsystem X körs din kod snabbare och mer effektivt utnyttja den istället :)

Viktigt att din VM använder DHCP, annars för varje ny virtuell maskin skulle behöva konfigureras separat vilket är något vi inte want.By använder DHCP vi inte behöver konfigurera nätverksinställningar individuellt för arbetsdatorer kommer DHCP lämna ut IP-adresser för dig. Därför kan du kopiera din virtuella maskin om Office utan att oroa om hur var och en upp (detta förbättrar skalbarheten och minskar arbetare administration).

Processen bör du sträva efter att uppnå skulle vara att få en ny fysisk maskin, installera VirtualBox och sedan ganska mycket distribuera den virtuella bild utan mycket annat. Det kan vara klokt att ställa alla dina anställda på ett annat subnät så att du åtminstone kan se hur många maskiner igång. Du måste också ställa in dina maskiner på ett långt hyreskontrakt eller obegränsad leasing DHCP.

Hur man kör jobb på arbetstagaren

Detta är ett intressant område och det finns flera giltiga metoder för bearbetning jobb på arbetstagaren. Här ska jag bara diskutera de två mest uppenbara:

• Ständigt köra skript: Ett skript, antingen det är en skalskript eller ett PHP-skript körs en gång på arbetstagaren och körs som en del av en oändlig slinga. Jag har diskonterat denna metod som ett kraschen manuset och potentiellt dina anställda kommer att upphöra att köras utan någon form av intervention.
• Cron-baserade skript utförande: Var X minuter cron-demonen startar ett samtal till ditt manus för att få saker och ting. Utan någon kontroll kan detta leda till många, många kopior av arbetstagarens skript som körs.

Mitt beslut var att gå med cron som drar igång ett script var 10 minutes. mitt skal skript utför följande uppgifter:

1. Få en process lista och grep detta för "php". Om den inte hittas sedan fortsätta.
2. Ring ditt jobb koden, i mitt fall skulle detta vara något PHP baserade
3. Arbetare script slutför loppet
4. Redo att gå igen på nästa lämpliga samtal

Min bash script ser ut ungefär så här:

  #! / Bin / sh
 om PS AX | grep-v grep | grep php> / dev / null
 därefter
     echo "Job närvarande bearbetar, avfart"
 annars
     echo "Job inte körs, starta nu"
     php yourJobProcessingScript.php
 fi 

OBS: ECHO: s är nästan helt meningslöst, men kan hjälpa nästa person som kommer med till försöka redigera dem.

Som avslutar uppsättningen av arbetstagaren virtuella maskinen, snabbt, enkelt och lätt att kopiera till varje ny maskinvara som tas emot. Den "skicklighet" av nätet är egentligen inte i visualiseras OS, dess alla att göra med koden skapades för att processen jobb, jobb konfiguration, och i att se till att jobbet körs när så är lämpligt (dvs när värden är inaktiv ).

Ställa in Windows för att initiera arbetare

Den första uppgiften är att träna kommandot krävs för att köra den virtuella maskinen från fönstren kommandoraden. Om du har installerat VirtualBox på standardplatsen och du har döpt din arbetstagarens GridMachine sedan kommandot som krävs för att ladda upp din arbetstagare:

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

Men för att köra skriptet i en "huvudlös" stat måste vi använda:

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

Detta kommer att starta den virtuella maskinen utan GUI och låt den för att spara tillståndet graciöst. Det andra argumentet stängs RDP så det inte strider mot fönster RDP, eller ge dig ett meddelande om att lyssna på port 3389. Den virtuella maskinen Namnet är skiftlägeskänsligt!

Därefter behöver vi ställa fönster upp till avspark vårt arbetstagaren VM när maskinen har varit inaktiv. För att göra detta (i Windows XP) du behöver för att gå Start -> Alla program -> Tillbehör -> Systemverktyg -> Schemalagda aktiviteter enligt nedan:

Klicka sedan på "Lägg till schemalagd aktivitet" följt av några för att lägga till ett anpassat program. Navigera till din VBoxManage manus och klicka på ok. Schemalägg din uppgift för någon av alternativen (vi kommer att ändra detta i en minut) och fortsätta. Efter att hoppa över nästa skärm fönstren kommer att fråga dig vem du vill köra den här uppgiften, skulle jag föreslå antingen "Administratör" eller skapa en ny privilegierad användare. Kom ihåg att vi inte vill störa standard personalen konto på maskinen när som helst. Klicka på Nästa och kontrollera visar avancerade alternativ för denna uppgift.

Till slutet av körningen textrutan lägga till vår "startvm GridMachine 'string och se till att löpa först när Inloggad omarkerad kvar. Besök schemat uppgiften nästa och ändra schemat falla ner till alternativet "när inaktiv", välj den tid du vill att maskinen ska vara inaktiv innan man går vidare till nästa flik.

Slutligen avmarkera det alternativ som anger stoppa aktiviteten om den har varit igång X tid, men välj alternativet för att stoppa uppgiften om maskinen inte längre ledig.

Det är det då för Windows Host setup!

Sammanfattning

I denna del har vi satt upp en virtuell maskin för att fungera som arbetstagare, liksom det sätt på vilket vi kallar och exekvera våra skript lönbearbetning (för mig själv ett PHP-skript). Härifrån vi tittar på hur man ställer upp våra exemplar av Windows att starta upp den virtuella maskinen i huvudlösa läge när datorn blir ledig, och spara dess tillstånd när användaren återupptar användning av maskinen. Förhoppningsvis på denna punkt du ser hur enkelt det är att inrätta ett sådant system och längtar efter att få några försök att gå själv!

Nästa gång

I del 4 kommer vi att titta på med verktyg för att se till att du kör den senaste versionen av kod och data källor så att resultaten alltid up-to-date med den senaste affärsinformation och logik.

Kommentarer (1)

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

Införandet

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

Som en PHP utvecklare jag kommer att 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 anpassa sig till andra språk och tekniker lika bra.

Lösningen ger jag kommer att vara mycket löst baserad på den typ av behandling vi skulle behöver för att uppnå men detta kanske inte är sant genom hela artikeln som jag kommer att ändra saker och ting för enkelhetens skull, eller för att producera mer intressanta användning scenarier.

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

Varför Distribuera ett Office Computing Grid?

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

• Du kommer inte överlåta vissa uppgifter till ett moln datormiljö
• Du kan inte ställa vissa data i ett cloud computing miljö för juridiska skäl (t.ex. uppgifter att lämna landet), eventuellt av juridiska skäl, t.ex. NHS poster.
• Du vill behålla dina processenheter stänga och har full kontroll över hårdvaran för
• Du har inte projektmedel för att köra moln instanser
• Ditt kontor har inte en anslutning till Internet och därför det är inte möjligt att använda ett moln resurs
• Du gillar inte 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 några matte (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 är tomgång 16 timmar om dagen, är vart och ett av dessa maskiner 10% så kraftfull som din biffiga behandling Sever. (Alla resultat här är rundade underskatta prestandaökning).

Så 1 maskin * 10% effekt * 2/3 tid = 0,067 dvs 1 skrivbordet bearbetning i viloläge tiden kunde bearbeta 6 fulla jobb per dag.

Om du nu skala upp detta tar det 15 lediga skrivbord för att bearbeta så många jobb per dag som din huvudsakliga behandlingen server gör.

Så i vårt låtsas kontor 50 maskiner vi kunde öka vår processorkraft från 1 server upp till 4 fulla bearbetning servrar, eller vi kan behandla 400 jobb per dag istället för 100.

Lägg märke till att inga investeringar i ny hårdvara företaget har just ökat sin batch-bearbetning kapacitet 4 gånger! Potentiellt du kommer att öka din elförbrukning utan från de flesta kontorsmiljöer Jag har varit i maskiner i allmänhet kvar på natten ändå, så du kan se detta som en grön initiativ.

Andra fördelar innebär också att investeringar i nya (eller uppdaterad) bearbetning servrar kan fördröjas om dina kontorsmaskiner är tillräckliga och att när du förbättrar kraften i dina 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 gammalt Windows XP laptop)
• VirtualBox (eller en annan virtualisering klientprogram)
• En virtuell maskin med PHP, MySQL running kör en skära ner OS, jag ringer dessa mina Limp servrar :)
• Jobb för att köra
• Job server (kan vara en annan virtuell maskin någonstans)

Typiska jobb

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

• Systemet får en förteckning över uppgifter på vilka vi måste matcha och ger resultat
• Matchande innebär kontroll / söka flera (ganska statisk) datakällor
• Resultat från datakällor kan kräva ytterligare validering, sammanslagning, kontroll av ytterligare datakällor som svar till resultat
• Data tillbaka med matchande poster som är fullt validerade och bearbetas
• Varje post inom ett jobb är oberoende av de övriga

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

Grid lösningar är inte bara fördelaktigt för behandling av arbeten 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 datorer galler, 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 distribuera ett kontor nätet behöver inte vara enormt dyrt eller tidskrävande. Jag kommer att diskutera:

• Koppla in systemet kontroll över arbetet, jobbet konfiguration
• Skapa en lämplig behandling virtuell maskin
• Hur man ställer in systemet på en Windows-dator
• Se till att du använder den senaste koden och data
• Deployment och benchmarking
• Blickar framåt

Jag är huset (ok jag byggde, så skrev) ett exempel för att testa begreppen på en lokal dator med Windows XP och min "GridMachine" virtuell maskin. Mitt jobb kontrollen servern kommer att vara min huvudsakliga dator som kör Fedora 11 .

Detta är inte på något sätt tänkt att visa en fullt fungerande robust system, innebar det mer av en demonstration och diskutera visar att dessa saker kan uppnås på ett relativt kort tid och till låg kostnad. Du får gärna skicka mig kommentarer, korrigeringar eller förbättringar och jag kommer 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 börja med att titta på jobbet styrsystemet, och se i hur arbete ska konfigureras för att uppnå största möjliga behandling och samtidigt säkerställa att varje jobb behandlas utan att misslyckas.

Kommentarer (1)

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

Införandet

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

I del 1 gav jag en översikt av systemet och teknik jag kommer att använda, liksom diskuterat några av de potentiella orsakerna till varför du skulle vilja skapa ett kontor nätet.

Job Kontroll

Om du ska vara igång jobb då du kommer att behöva något sätt att hantera dem. Ditt jobb styrsystem (på jobbet server) måste vara riktigt väl genomtänkt innan man ens försöker köra ett Office-nätet. Så det första, vad är uppgifter för ett jobb styrsystem:

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

Systemet måste också vara töjbar, en lösning som fungerar för nu i ett enda fall får förlängas för att köra flera olika typer av jobb som verksamheten ser värdet i ett rutnät lösning. Till exempel kan jobb få 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.

Jobb server

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

Jobbet själva servern inte riktigt har en komplicerad uppgift (i ett bassystem ändå), måste den lagra en lista med jobb, dela ut jobb, få resultat, och därefter lagra dem för senare hämtning. Hur dessa delar (till exempel "dela ut jobb") definieras kan vara mycket minimalt. Senare kan vi utvidga systemet till att omfatta ett administrationsgränssnitt för att lägga till, redigera, radera, avbryta jobb men det är bortom denna övning.

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

Basic Setup

Den grundläggande inställning för vårt jobb servern kommer att bestå av vad jag kallar en av mina Limp servrar (det vill säga Li Nux, m ySql, P HP). Koden körs på Thea arbetstagarna faktiskt kommer att räkna ut vilka jobb man kan köra genom att interagera med med jobb kontrollsystem databaser. Senare kunde vi skapa en webbtjänst och faktiskt dela ut jobb snarare än att de anställda 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 tabeller för att ta itu med jobb. Dessa kommer att vara `jobb`, `jobRecords` och `jobResults kallade.

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 se: 10 Great 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, t.ex.
  • 0: Inte startat
  • 1: Hämtade
  • 2: Genomförd
• started_by: Vem började göra jobbet? Detta är inte helt nödvändigt men är en trevlig att ha. Jag skulle föreslå spårning arbetare genom deras IP-adress på ditt nätverk
• started_at: När började arbetaren starta jobbet? Genom att spåra jobb som inte har slutföras inom X tid vi vet att vi behöver plocka upp jobbet igen och starta behandling av en annan arbetstagare. Arbetare kunde stoppa behandlingen / go offline för ett antal skäl, strömavbrott, krasch, nätverk förlust, etc.

Det är lätt hur denna tabell kan utökas med ytterligare några områden för att möjliggöra för 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 tog upp jobbet (naturligtvis detta behöver tenderar att 1), jobb prioritet, listan kan fortsätta och fortsätta. I mer komplexa jobb scenarier skulle det 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åter lägga till några exempel jobb:

Nästa bordet igen är ganska enkel att förstå, dessa är våra jobb register. De är kopplade till den främsta arbeten tabellen genom en kolonn '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 posten
• Namn: Person namn
• adress: Person adress
• jobs_id: Jobbet ID som denna post är kopplad till

Den tredje och sista tabell består av en resultattavla, har det mycket samma märke upp som våra register bord, och med tillägg av vissa kolumner kan vara en del av journaler 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 mina data till processen ligger, men det kan lika gärna varit en fil, parametrar för att köra simulering kod, you name it.

Välja ett jobb

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

1. Vidta de jobb som inte är märkta som fullständig, men från vår arbetstagaren och återställa dem (ersätt __ ME__ med en identifierare skulle enklast IP-adress):

    UPPDATERING kallade jobb `SET` status `= 0 där` status `= 1 OCH` started_by `= __ ME__; 

2. Med våra kriterier jobb, markerar du ett jobb och tala om för styrsystemet att arbetstagaren handlägger:

     UPPDATERING kallade 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 har återvänt resultat i X tid vi se till att alla jobb körs i händelse av en arbetstagares krascha eller gå AWOL.

3. Nästa ta de arbetstillfällen detaljerna följt av posterna själva:

     SELECT * FROM `jobb` WHERE `started_by` = __ ME__ GRÄNS 1;
    SELECT * FROM `job_records` WHERE `id` = __ JOBID__; 

Efter avslutad jobbet vi in ​​våra resultat register och markera jobbet som fullständig. Minns jobb kan avbryta / återuppta som helst utrymme för en viss robusthet i skriptet. Det kan vara att uppgiften skjuter halvvägs genom att uppdatera systemet kontroll över arbetet, så kontrollera antalet poster i ett jobb och antalet resultat sparade tillbaka till jobbet styrsystemet skulle vara ett klokt drag.

Dessutom, medan det visar hur jobb kan väljas och hanteras från en SQL-query ram du borde verkligen vara abstrahera jobbet kontroll så att om du väljer att byta till en webbtjänst, en fil system, XML , eller någon annan antal system kommer det inte att påverka den kod ovanför den.

Job konfiguration

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

1. Jobb tar 1 dag i båda för att köra: Detta innebär att dina anställda behöver 15 dagar för att behandla varje jobb (kom ihåg 10% av strömmen till 2/3rds av tiden). Detta är uppenbarligen inte en klok konfiguration är ditt jobb storlek alldeles för stor! Det skulle ta minst dubbelt så lång tid att få ett jobb bearbetas bör den initiala arbetstagaren går AWOL (tid att plocka upp att det inte har återvänt ett resultat plus upparbetning tid). I en idealisk du skulle ha minst en hel jobb lätt bort i slutet av varje lång viloperiod, så du håller jobben tomgång och i värsta fall ett jobb skulle ta två dagar att processen bör den första go saknas.
2. Jobb tar 1 minut att köra: Detta innebär att dina anställda tar ungefär 15 minuter att köra varje jobb. Även om detta från början kan verka perfekt får du ytterligare arbete bearbetning under lunchtid, kaffe raster, möten, etc. Detta scenario sätter belastning på andra delar av ditt system och introducerar sina egna problem. Till exempel, för det första din setup / handläggningstiden förhållandet kommer att gå rakt ner, alltså att förlora systemets effektivitet. Nätverket kommer att vara ständigt streaming jobbinformation till de olika arbetarna frustrerande personal som är dong sin dag till dag arbetet. Du kommer också att lägga mer belastning på ditt jobb behandling servern som den har att dela ut massor av små bitar av arbete på regelbunden basis. Slutligen, i denna situation, om ditt jobb servern går ner du kommer att skapa en enorm baksida logg över oavslutat arbete, medan större arbeten kan av fortsatt behandling lyckligt ovetande om att jobbet servern svårigheter.

I verkligheten blir det ingen perfekt konfigurationen för din grid inställning, beror mycket på de tillgängliga resurserna, typ av jobb, jobb handläggningstider krav tid, nätverkskapacitet och så vidare. Men vissa riktlinjer skulle vara:

• Storlek jobb så att varje arbetstagare kan ta sig igenom åtminstone 3-4 jobb i en period av 15 timmar (den längsta sannolikt inaktiv tid)
• Spela med jobbet storlek så att ställtiderna blir ganska obetydlig jämfört med behandlingstiden (med tanke på ovanstående punkt).
• Om en arbetssökande inte komplett i dubbelt så lång tid (kanske mindre) du förväntar att slutföra det anta att gått AWOL och börja bearbeta den med en annan arbetstagare. Det innebär att du kan få vänta upp till tre gånger den normala längden av ett arbete för att slutföra (möjligen längre om den efterföljande arbetet misslyckas). Du kanske vill minska den här gången, men var noga med att inte minska den alltför mycket eftersom du kan börja dubblera bearbetning uppgifter på en regelbunden basis.
• Jobb ska vara oberoende av utomstående krav på 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 få två negativa effekter, kommer din dagtid medarbetare hittar med hjälp av nätet frustrerande och problem kan upplevas med anslutningar tajma ut ett problem som bara kommer bli värre när du skala ditt rutnät.
• Se till jobb kan köras på dina arbetare. Om jobb blir för minneskrävande eller diskutrymme intensiva jobb börjar avbryta och det enda du kommer att märka är en droppe i antal arbetstillfällen som bearbetats med någon riktig anledning.

Lämnar Resultat av ett jobb

När du skickar resultaten från ett jobb är det viktigt att kontrollera att resultaten inte har lämnats in av en annan arbetstagare, särskilt om den aktuella arbetstagaren har varit vilande under en tid.

När resultaten lämnas se till att antalet resultat motsvarar det antal poster i jobbet.

Som nämnts tidigare och kan inte nog betonas, bygga feltolerans i jobbet hämtning och resultat underkastelse. Arbetarna kan (och sannolikt kommer) gå in vänteläge på den mest obekväma gånger och detta måste tillgodoses. Även en gång abstrahera bort din resultaten ansökan kommer att hjälpa tillgodose framtida ändringar ditt jobb styrsystemet mycket lättare att hantera.

Sammanfattning

I denna section har vi tittat på vad ett jobb styrserver 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 att få ut mesta vår i ditt kontor bärverk. Till slut blev ett stycke eller två på skicka resultatet tillbaka till jobbet styrservern presenteras.

• Ett jobb styrserver hanterar jobb och ser till att alla arbetsenheter är klara
• Genom att abstrahera ditt jobb väljer / resultat lämnas vi kan ändra tekniken för kontroll servern utan mycket problem
• Konfigurera dina jobb så att de drivs snabbt och effektivt utan att alltför mycket press på din nätverksinfrastruktur, och utan att duplicera bearbetning uppgifter på en regelbunden basis.
• Se till att du bygger feltolerans och fel checking i dina rutiner, kan de anställda avbryta och återuppta och den mest obekväma gånger. Kom ihåg att kontrollera om resultat har redan lämnats in av en annan arbetstagare.

Nästa gång

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

Kommentarer (3)

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

Införandet

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

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 kod och data källor så att resultaten alltid up-to-date med den senaste affärsinformation och logik.

Pre-Deployment

Innan du distribuerar ditt nätet om det är en sak du gör och en sak bara det är riktmärken ditt nuvarande system! Oavsett vad du säger dina kolleger om hur mycket extra arbete ditt system kommer att göra om du inte har nummer för att backa upp 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 en av dina bearbetning servrar) går ner hur kommer detta att påverka dina möjligheter, kommer du att handikappade?
• Vilka fördelar hoppas du / räkna med att få från ett rutnät system?
• Är dina kontorsmaskiner kan köra jobb?
• Är din (eller kan du jobb omvandlas) till wrok i denna stil att köra?

Den sista viktiga punkten är att ta din tid på någon större förändring så här. Uppdatera din processkod att arbeta med den nya metoden, riktmärke igen. Möjligen ställa in din behandling server att köra en virtuell maskin, efter alla dina behandling servern kommer bara att 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 installation. Gör detta precis innan en fjorton dagars semester och lämnar så att andra fattiga kap att ta itu med konsekvenserna ... kanske inte ...

Deployment för ett system som detta måste vara långsam. Trots att det är relativt enkelt att ställa in detta system kommer att påverka hela ditt kontor infrastruktur (såväl den digitala ett). För det första, rulla ut till ett par av maskiner åt gången, bildskärm nätverkstrafik, hur arbetstagare värdarna utföra på en dag till dag. Du kan behöva ändra ditt jobb konfiguration som svar på dina resultat.

När systemet har satt sig med några maskiner (låt säga 10% av alla kontorsmaskiner, dvs 5) Håll trafikövervakning nätverk och värddatorn performance. Nästa riktmärke igen bör du nu behandla 33% fler arbetstillfällen än dina första riktmärken. Kontrollera det är så, eller att du åtminstone i detta Ballpark. Om inte, undersöka vad som händer innan vi går vidare. Upprepa denna cykel tills du gärna har alla kontorsmaskiner igång utan att döda enskilda maskinens prestanda eller slipning ditt nätverk till ett stopp.

Alltid hålla benchmarking, även efter alla installationer görs. Kontrollera hur nya kod uppdateringar påverkar hastigheten på ditt system, kontrollera alla arbetstagare redovisning och bearbetning jobb. Långsamt (långsamt) stega ditt jobb konfiguration för att få ut det bästa av dina arbetare och nätverk.

Stopp!

Vad händer om du vill stoppa dina anställda från att köras 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 i fall den förbises. Helt enkelt redigera din behandling manus med en exit (0) eller dör () eller någon annan förklaring till döda din behandling jobb. En viktig orsak till varför vi alltid försöker att uppdatera till den senaste bearbetningen manus innan loppet!

Demonstration System

För att skriva denna rad korta artiklar jag skapat en mycket liten galler att demonstrera teknik och metoder. Jag läste massor av artiklar, tutorials 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 medlemmar PC för att se hur värden prestanda påverkades.

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

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

Den virtuella maskinen sattes upp med PHP, subversion, och mySQL. Jag kollade ut en gren som heter "arbetstagare" från mitt jobb styrning servrar arkiv och såg till att det kan uppdateras med hjälp av "svn update '. Nästa Jag installation MySQL som en slav och kontroll av att data replikeras från MySQL på jobbet styrservern ner till arbetstagaren VM. Efter allt detta har jag ställa in bash script och cron-jobb.

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

• Läs i namnfältet
• Räknade antal likadana namn i en tabell från datakällan hålls på VM
• Räknade antal namn som ovan men att dela upp namnet med mellanslag (dvs förnamn, mitten, efternamn)
• Upprepad denna process 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å Windows laptop och såg de arbeten kontrolleras av var och en av adresserna arbetstagare IP. Här vill jag också bekräftat att replikering automatiskt startas om.

Lämna den bärbara datorn på tomgång resulterade i att arbetstagaren börjar bearbeta jobb från jobbet kontrollen servern. När återuppta laptop användning fanns en fördröjning på cirka 30-60 sekunder, är detta en hel del tid och personal skulle behöva vara medvetna om att deras maskin kan stanna en kort stund när de återvänder till maskinen. Nyare maskiner kan inte ha en paus på denna långa. Fördelen med den mängd som utförs av dessa maskiner under lediga perioder skulle mer än uppväga anställda tvungna att vänta en kort period (säg 1 minut) när de anländer till sina maskiner av en morgon (jag väntar ofta längre än detta för en Windows Defender uppdatera ske) förutsatt att de fick kännedom om detta (bra tid för att ta en morgonkaffe!).

Överlag är jag säker på 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å en (mycket) liten skala och med lite mer experimenterande kan skalas upp utnyttja resurserna i en kontorets maskiner. Om jag inte får 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 inom en kontorsmiljö och se vad som händer. Att be ett företag att engagera sig i detta utan ett spår flammande företag att visa tekniken och effektivitet kan vara lite svårt. Grid / distributed computing ä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 som detta i mina sökningar som kan rullas ut inom ett kontorsmiljö.

Jag skapade en i grunden gratis system använder mest öppen källkod och verktyg som finns i nästan alla kontor. Den teknik var grunden visat och visar att utföra och fungera som förväntat. Förhoppningsvis har jag visar 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 till befintlig hårdvara stärka ditt processorkraft.

Jag hoppas du har haft att läsa denna serie av artiklar och gett dig en tankeställare om att köra en System Office nätet. Den lösning som presenteras här kommer inte nödvändigtvis fungerar i alla situationer men bör kunna anpassas så att du kan få din databehandling sker med din egen lösning.

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