Indledning
Jeg arbejder i en virksomhed, hvor vi køre mange batchjob forarbejdning af millioner af optegnelser over data hver dag, og jeg har tænkt for nylig om alle de maskiner, der sidder rundt om hver eneste dag at gøre noget i flere timer. Ville det ikke være godt, hvis vi kunne bruge disse maskiner til at styrke den regnekraft af vores systemer? I dette sæt af artikler jeg har tænkt mig at se på de potentielle fordele ved at ansætte et kontor gitter ved hjælp af virtualiserede miljøer.
I del 1 jeg gav et overblik over systemet og teknologier jeg vil bruge samt drøftet nogle af de potentielle grunde til, at du ønsker at oprette et kontor gitter.
Job Kontrol
Hvis du vil køre jobs så du vil få brug for nogle måde at styre dem. Dit job kontrolsystem (på dit job server) skal være virkelig velgennemtænkt, før selv forsøger at køre et kontor gitter. Så det første, hvad er opgaver for et job kontrolsystem:
- Uddel opgaver efter anmodning fra arbejdstagerne
- Fortæl arbejdere hvilken type af job til at køre
- Spor job
- Sørg for, at arbejdspladser er kun køre én gang
- Giv jobdata til arbejdstagere, eller i hvert fald fortælle dem, hvor du kan få det
Systemet skal også udvides, en løsning der virker for nu i et enkelt tilfælde kan udvides til at køre flere typer af arbejdspladser, fordi virksomheden ser en værdi i et gitter løsning. For eksempel kan arbejdspladser få prioriteter, mere end én jobtype kan eksistere (dvs. flere code baser), i sidste ende kan du endda køre flere forskellige arbejdstager maskiner, der er optimeret for hver type af arbejde (selv om det bevæger sig væk fra det »generiske arbejdstager 'idé). Forsøg altid at tænke på fremtiden, når udvikle systemer, kan en kortsigtet vision føre til på længere sigt frustration og øget udviklingsbistand tid.
Job Server
Vi vil få brug for et sted at styre vores job fra, bør dette være det eneste system i dit net, der har en fast ressource locator, være, at en IP-adresse, værtsnavn, URL (ved hjælp af intern DNS), osv. Dette skyldes arbejderne har brug for at vide hvor de skal lede efter job, arbejdstagere har behov for at finde det job kontrolsystem (ikke jobbet kontrolsystem finde arbejderne).
Jobbet selve serveren ikke rigtig har en kompliceret opgave (i et grundlæggende system alligevel), er det nødvendigt at gemme en liste over job, uddele job, modtage resultaterne, og efterfølgende gemme dem til senere afhentning. Hvordan disse dele (såsom 'hånd ud arbejdspladser «) er defineret kan være meget basale. Senere kan vi udvide systemet til også at omfatte et administrations-interface til at tilføje, redigere, slette, suspendere job, men det er hinsides denne øvelse.
Der er ingen som helst grund så er dit job server ikke kunne være en virtuel maskine, der kører inden for dit primære behandling server, forudsat at det ikke dræne alt for mange ressourcer fra det. Jobbet serveren dog ikke brug for høj tilgængelighed, hvis det går ned på en fredag aften, du kommer til at miste en hel weekend med behandling, potentielt koste dig et par uger til en værdi af sagsbehandlingstiden (i forhold til din primære behandling server alene) . Du vil måske overveje at sætte dit job server på en load balanceret miljø for høj tilgængelighed.
Grundlæggende opsætning
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 )
This table consists of 5 simple fields,
- 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. I'd suggest tracking workers by their IP address on your network
- started_at: When did the worker start the job? By tracking jobs that have not completed within X amount of time we know we need to pick up the job once again and start processing by another worker. 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
- result: The result 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 tidligere nævnt, vil arbejderne gøre vores jobstyring for os for nu, så vi alle har brug for virkelig at gøre er at finde et job, der kræver behandling og få oplysningerne. Hvordan ville vi gøre det? Godt pick vores job udvælgelseskriterier og søge job, i SQL gjorde jeg følgende:
- Tag nogle job, der ikke er markeret som komplet, men fra vores arbejdstager og nulstille dem (stedfortræder __ME__ med et id, ville nemmeste være IP-adresse):
UPDATE `jobs` SET `status` = 0 WHERE `status` = 1 og `started_by` = __ME__;
- Brug vores job udvælgelseskriterier, skal du vælge et job og fortælle kontrolsystem, at denne arbejdstager beskæftiger sig med det:
UPDATE `jobs` SET `status` = 1, `started_by` = __ME__, `started_at` = NOW () WHERE `status` = 0 eller
(`Status` = 1 og `started_at`> DATE_SUB (NOW (), interval X HOUR)) ORDER BY `id` ASC;
Ved at snuppe job, der ikke returnerede resultater i X tid, vi sikrer, at alle job er at køre i tilfælde af en arbejdstager bryder sammen eller gå væk fra mig.
- Næste fat i job detaljer efterfulgt af journaler selv:
SELECT * FROM `jobs` WHERE `started_by` = __ME__ LIMIT 1;
SELECT * FROM `job_records` WHERE `id` = __JOBID__;
Ved afslutningen af jobbet, vi indsætter vores resultat optegnelser og markere opgaven som fuldført. Husk som arbejdspladser kan suspendere / genoptages på ethvert tidspunkt give mulighed for en vis robusthed i dit script. Det kan være, at opgaven suspenderer halvvejs gennem opdatering jobbet kontrolsystem, så kontrol af antallet af poster i et job, og antallet af resultater gemt tilbage til jobbet kontrolsystem ville være et klogt træk.
Hertil kommer, samtidig med at dette viser, hvordan arbejdspladser kan vælges og styres fra en SQL-forespørgsel ramme, du skal virkelig være abstrahere dit job kontrol, så hvis du beslutter dig for at skifte til at bruge en webtjeneste, en fil baseret system, XML , eller enhver anden Antallet af systemer, vil det ikke påvirke den ovenstående kode det.
Job Configuration
Det næste aspekt at overveje, er opgavens omfang og konfiguration. Ved at spille med job konfiguration, vi kan skabe en god balance mellem hastighed, proces-replikation, og pålidelighed. Tag et par OFA scenarier:
- Jobs tage 1 dag hver til at køre: Det betyder, at dine medarbejdere har brug for 15 dage til at behandle hvert job (husk 10% af den strøm til 2/3rds af tiden). This is clearly not a wise configuration, your job size is way too big! It would take at least double the time to get a job processed should the initial worker go AWOL (time to pick up that it hasn't returned a result plus reprocessing time). In an ideal you'd have at least one full job easily cleared by the end of each long idle period, that way you keep the jobs ticking over and at worst case a job would take two days to process should the first go missing.
- Jobs take 1 minute to run: This means that your workers take about 15 minutes to run each job. Whilst this may initially seem ideal, you gain additional work processing during lunch time, coffee breaks, meetings, etc this scenario puts strain on other areas of your system and introduces its own problems. For example, firstly your setup/processing time ratio is going to go right down, therefore losing system efficiency. Your network is going to be constantly streaming job information to the various workers frustrating staff who are dong their day to day work. You're also going to put more strain on your job processing server as it has to dish out lots and lots of small pieces of work on a regular basis. Lastly, in this situation if your job server goes down you're going to create a huge back log of uncompleted work whereas bigger jobs could of continued processing blissfully unaware that the job server was experiencing difficulties.
In reality there will be no one ideal configuration for your grid setup, much depends on the available resources, types of job, job turnaround time requirements, network capability, and so on. However some guidelines would be:
- Size jobs so that each worker can get through at least 3-4 jobs in a period of 15 hours (the longest likely idle time period)
- Play with the job size so that setup time becomes fairly insignificant compared to the processing time (bearing in mind the above point).
- If a job doesn't complete in double the amount of time (maybe less) you expect it to complete it assume that its gone AWOL and start processing it with another worker. This means you may have to wait up to three times the normal length of a job for it to complete (possibly longer if the subsequent job fails). You may want to reduce this time, but be careful not to reduce it too much as you may start duplicating processing tasks on a regular basis.
- Jobs should be independent of outside requirements as much as possible. The job server, for example, should only be contacted at the start and end of every job.
- Don't saturate your network, this will have two negative effects, your daytime staff will find using the network frustrating and problems may be experienced with connections timing out a problem that will only get worse as you scale your grid.
- Ensure jobs can run on your workers. If jobs become too memory intensive or disk space intensive jobs will start aborting and the only thing you'll notice is a drop in number of jobs processed with no real reason why.
Submitting Results of a Job
When submitting the results of a job it is important to check that results have not been submitted by another worker, especially if the current worker has been dormant for some time.
When results are submitted ensure that the number of results matches the number of records within the job.
As stated previously, and can not be over emphasised, build fault tolerance into job retrieval and results submission. The workers can (and most likely will) go into suspend mode at the most inconvenient of times and this needs to be catered for. Also once again abstracting away your results submission will help cater for future changes to your job control system much easier to deal with.
Resumé
In this section we have looked at what a job control server needs to do and how to get a very basic system set up. We discussed how to retrieve a job from the control system and how best to configure jobs to get the most our of your office grid system. To finish, a paragraph or two on submitting results back to the job control server was presented.
- A job control server manages jobs and ensures that all work units are completed
- By abstracting your job select/results submission we can change the technology of the control server without much problems
- Configure your jobs to ensure that they are run quickly and efficiently without putting too much pressure on your network infrastructure, and without duplicating processing tasks on a regular basis.
- Ensure that you build fault tolerance and error checking into your routines, workers can suspend and resume and the most inconvenient of times. Remember to check if results have already been submitted by another worker.
Next time
In part 3 we'll create our virtual processing machine and set up our windows machines to become idle-time workers.
Kommentarer (4) 
Artikler , PHP , web-programmering , Zend Framework | 
rammer , ini , PHP , Router , Routes , Zend , Zend Framework , Zend_Navigation , Zend_Router 
