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.
There is no reason whatsoever then that your job server could not be a virtual machine running within your main processing server provided it doesn't drain too many resources from it. The job server however does need high availability, if it goes down on a Friday evening you're going to lose a whole weekend of processing, potentially costing you a couple of weeks worth of processing time (when compared to your main processing server alone). You may want to consider putting your job server on a load balanced environment for high availability.
Basic Setup
The basic setup for our job server will consist of what I'm calling one of my LiMP servers (that is Li nux, m ySql, P HP). The code running on the workers will actually work out what jobs it can run by interacting with with job control system databases. Later on we could create a web service and actually hand out jobs rather than having the workers do the hard work themselves, but for now we'll continue using the KISS principle (Keep it Simple, Stupid!).
So, lets create three mySQL tables to deal with jobs. These will be `jobs`, `jobRecords`, and `jobResults`.
Here I'm using SQL Buddy a great little alternative to phpMyAdmin just because its easier to install on centOS (for others see: 10 Great alternatives to phpMyAdmin )
Denna tabell består av 5 enkla fält,
- id: Uniquely identify the job
- name: Could be a client reference, or any number of other identifiers
- Status: You need to know where the job is at, eg
- 0: Not started
- 1: Picked up
- 2: Completed
- started_by: Who's started doing the job? This isn't entirely required but is a nice to have. Jag skulle föreslå spårning arbetstagare genom deras IP-adress på ditt nätverk
- started_at: When did the worker start the job? 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. Workers could stop processing/go offline for any number of reasons, power failure, crash, network loss, etc.
It is easy how this table could be extended with a few additional fields to allow for statistics tracking, a finish time column to see how long the job took, a counter to see how many workers picked up the job (obviously this needs to tend to 1), job priority, the list can go on and on. In more complex job scenarios it would be possible to specify how much memory the worker would need access to (and therefore only use suitable workers), or even what type of worker would be required.
Lets add a few example jobs:
The next table again is quite simple to understand, these are our job records. They are linked to the main jobs table by a column `jobs_id`. The make up of this table very much depends on the data that you need to supply to your workers, lets make a very simple example where we have four columns:
- id: ID of the record
- name: Person's name
- address: Person's address
- jobs_id: The job ID that this record is linked to
The third and final table consists of a results table, it has much the same make up as our records table, and with the addition of some columns could be part of the records table:
- job_record_id: Link the result to the job table
- Resultat: Resultatet data
…and that's all you need for job control! (albeit at a very basic level) In my case I'm pointed to another table where my data to process was located, but this could just as easily been a file, parameters to run simulation code, you name it.
Selecting a job
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:
- 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__;
- 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.
- 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 frame ni 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:
- 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.
- 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 den dubbla summan av 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 ändra den teknik 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.
Kommentarer (2) 
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 anställda utan en enorm ökning av nätverksaktivitet (som om inte du gör en enorm data uppdateringen och alla dina anställda 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 uppdateringar av databasen, den MySQL på din arbetaren kommer demonen kontinuerligt uppdatera sina data medan behandlingen fortsätter. 
Artiklarna , Computing , Grid Computing , Linux , PHP , Webbprogrammering | 
bash , parti , kod , databas , rutnät , Linux , master , mySQL , PHP , bearbetning , redbean , replikering , rsync , manus , slav , subversion , svn , svn update 
