Inledning

Jag arbetar i ett företag där vi driver många batchjobb bearbetning miljontals skivor av data varje dag och jag har funderat nyligen om alla maskiner som sitter runt 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 virtualiserade miljöer.

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

Kontroll över arbetet

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

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

Systemet måste också vara utbyggbar, en lösning som fungerar för nu i ett enskilt fall får förlängas för att köra flera olika typer av arbeten som företaget ser värt i ett rutnät lösning. Till exempel kan arbetstillfällen vinna prioriteringar kan mer än ett jobb typ finns (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 arbetstagaren "idé). Försök alltid att tänka på framtiden när de utvecklar system kan ett kortsiktigt vision leda till mer långsiktiga frustration och ökad utvecklingstid.

Job Server

Vi kommer att behöva någonstans att kontrollera våra jobb från, detta bör vara det enda systemet i din tabell 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 att söka jobb, arbetare behöver hitta systemet kontroll över arbetet (inte jobbet styrsystemet hitta arbetare).

Jobbet servern själv egentligen inte har en komplicerad uppgift (i en grundläggande system ändå), behöver den för att 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 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 som helst 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 dränera alltför mycket resurser från det. Jobbet Servern dock behöva hög tillgänglighet, om det går ner på en fredag ​​kväll du kommer att förlora en hel helg av bearbetning, kan kosta dig ett par veckor värde av handläggningstiden (jämfört med dina viktigaste bearbetning server ensam) . Du kanske vill överväga att sätta ditt jobb server på en belastning balanserad miljö för hög tillgänglighet.

Basic Setup

Den grundläggande inställningen för vårt jobb-servern kommer att bestå av det jag kallar en av mina LIMP-servrar (som är Li Nux, m ySql, P HP). Koden körs på Thea arbetstagare kommer faktiskt räkna ut vilka jobb det kan köras genom att interagera med med jobb styrsystem 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 för nu ska vi fortsätta att använda KISS principen (Keep it simple, Stupid!).

Så låter skapa tre mySQL tabeller för att hantera jobb. Dessa kommer att "jobb", "jobRecords" och "jobResults".

Här använder jag 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: unik identitet för jobbet
• namn: Kan vara ett kundreferens, eller valfritt antal andra identifierare
• Status: Du måste veta var jobbet är på, t.ex.
  • 0: inte startat
  • 1: Plockade upp
  • 2: Avslutade
• started_by: Vem började göra jobbet? Detta är inte helt krävs men är ett trevligt att ha. Jag skulle föreslå spårning arbetstagare genom deras IP-adress på ditt nätverk
• started_at: När började arbetstagaren 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 arbetstagare. Arbetstagare kan sluta bearbetning / gå offline för någon av flera skäl, strömavbrott, krasch, nätverk förlust, etc.

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

Låter tillsätt några exempel arbetstillfällen:

I nästa tabell 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". Make Up av denna tabell beror mycket på de data som du behöver för att leverera till dina anställda, låter 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 kopplat till

Den tredje och sista tabellen består av en resultat tabellen har det mycket samma märke upp 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 jobbtabellen
• Resultat: Resultatet data

... 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å en annan tabell där min data för att processen var belägen, men detta kunde lika gärna varit en fil, parametrar för att köra simuleringen kod, you name it.

Välja ett jobb

Som nämnts tidigare, kommer arbetarna att göra vårt jobb förvaltningen 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:

1. Ta några jobb som inte är markerade som färdiga men från vår arbetstagaren och återställa dem (substitut __ME__ ett identifieringsnummer, skulle enklast IP-adress):

     UPDATE `jobb` SET `status` = 0 där `status` = 1 och `started_by` = __ME__; 

2. Använda våra kriterier jobb urval, välj ett jobb och tala om för styrsystemet att arbetstagaren har att göra med det:

     UPDATE `jobb` SET `status` = 1, "started_by` = __ME__, "started_at` = NOW () 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 arbetstagare kraschar eller går AWOL.

3. Nästa greppa jobb detaljer följt av posterna själva:

     SELECT * FROM `jobb` där `started_by` = __ME__ GRÄNS 1;
    SELECT * FROM `job_records` där `id` = __JOBID__; 

Efter avslutad jobb vi sätter vårt resultat register och markera jobbet som fullständig. Kom ihåg eftersom arbetstillfällen kan suspend / resume helst utrymme för en viss robusthet i skriptet. Det kan vara att uppgiften avbryter halvvägs genom en uppdatering av systemet kontroll över arbetet, så kontrollera antalet poster i ett jobb och antalet resultat sparas tillbaka till jobbet övervakningssystem skulle vara ett klokt drag.

Dessutom, samtidigt som detta visar hur jobben kan väljas och hanteras från en SQL-query ram du verkligen borde abstrahera ditt jobb kontrollera 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 jobb konfiguration vi kan slå till en utmärkt balans mellan fart, process replikering och tillförlitlighet. Ta ett par Ofa scenarier:

1. Jobb ta en dag varje köra: Detta innebär att din arbetstagare 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 storlek alldeles för stort! 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 till följd plus upparbetning tid). I en idealisk du skulle ha minst en hel jobb enkelt bort i slutet av varje långa driftsstopp, som så håller du jobb tickande över 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 medarbetare tar ca 15 minuter att köra varje jobb. Även om detta kan förefalla idealiskt, får du extra arbete bearbetning vid lunchtid, kafferaster, möten osv detta scenario sätter stam på andra områden i ditt system och introducerar sina egna problem. Till exempel är det första din setup / handläggningstiden förhållande kommer att gå rätt ner, därför att förlora systemets 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 lägga mer belastning på ditt jobb bearbetning servern som den 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 rygg logg över oavslutat arbete medan större arbeten kan fortsatt behandling lyckligt ovetande att jobbet servern hade några svårigheter.

I verkligheten blir det ingen idealisk konfiguration för din tabell inställning, mycket beror på de tillgängliga resurserna, typer av jobb, jobb handläggningstid 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 jobbets storlek så att ställtiderna blir ganska obetydlig i jämförelse 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 denna tid, men var noga med att inte minska det alltför mycket som du kan börja dubblera bearbetning uppgifter på 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 tidsgränsen går ut ett problem som bara kommer att bli värre när du skala din tabell.
• Se till jobb kan köras på dina medarbetare. Om jobb blir för minneskrävande eller diskutrymme intensiva arbeten kommer att starta avbryter och det enda du märker är en droppe i antal arbetstillfällen som bearbetats med någon verklig anledning.

Skicka in Resultat av en Job

När de lämnar in resultatet av ett arbete ä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 har skickats in se till att antalet resultat motsvarar det antal poster inom jobb.

Som nämnts tidigare, och kan inte nog betonas, bygga feltolerans i jobb hämtning och resultat underkastelse. Arbetarna kan (och förmodligen kommer) att gå i vänteläge på de mest obekväma tider och detta måste tillgodoses. Också återigen abstrahera bort dina resultat inlämning kommer att bidra tillgodose framtida förändringar av ditt jobb styrsystem mycket lättare att hantera.

Sammanfattning

I detta section har vi 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år på ditt kontor bärverk. För att avsluta, ett stycke eller två på att lämna in resultat tillbaka till jobbet Control Server presenterades.

• Ett jobb Control Server hanterar jobb och ser till att alla arbetsenheter är klara
• Genom att abstrahera jobbet välja / resultat inlämnande vi kan förändra tekniken för kontroll servern utan mycket problem
• Konfigurera jobb att se till att de sköts snabbt och effektivt utan att lägga alltför stor press på din nätverksinfrastruktur, och utan att dubbelarbete bearbetning uppgifter på regelbunden basis.
• Se till att du bygger feltolerans och checking fel 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 kommer vi skapar våra virtuella maskin och sätta ihop våra Windows-maskiner att bli idle-tid arbetstagare.

En Svaren till "Office Grid Computing hjälp Virtuella miljöer - Del 2"

1. Hydrolyserar säger:

   Torsdag 18 februari 2010 kl 19:11

   Heya! Bra koncept, men kan detta verkligen jobbet?

   Svara