Indledning

Jeg arbejder i en virksomhed, hvor vi kører mange batch jobs behandling millioner af optegnelser af 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 denne række artikler, jeg har tænkt mig at kigge på de potentielle fordele ved at ansætte en kontor nettet ved hjælp af virtualiserede miljøer.

I del 1 jeg gav en oversigt over systemet og teknologier jeg vil bruge samt drøftet nogle af de mulige årsager hvorfor du ønsker at skabe et kontor gitter.

Job Control

Hvis du vil køre job, du vil få brug for en måde at håndtere dem. Dit job kontrol system (på dit job server) skal være meget velgennemtænkte før selv forsøger at køre et kontor gitter. Så det første, hvad er de opgaver et job kontrolsystem:

• Uddel opgaver efter anmodning fra arbejdstagerne
• Fortæl arbejdstagere, hvilken type job til at køre
• Spor job
• Sørg for, at arbejdspladser kun køres én gang
• Levere jobdata til arbejdstagere, eller i det mindste fortælle dem hvor du kan få det

Systemet også skal udvides, en løsning, som virker for nu i et enkelt tilfælde kan udvides til at køre flere typer af arbejdspladser, fordi virksomheden ser værd i et gitter løsning. For eksempel kan arbejdspladser få prioriteringer, kan mere end én jobtype findes (dvs. flere kode 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øger altid at tænke på fremtiden, når at udvikle systemer, kan en kortsigtet vision føre til længere sigt frustration og øget udviklingsbistand tid.

Job Server

Vi vil få brug for et sted at kontrollere vores job fra, dette bør være det eneste system i din net, der har en fast ressource locator, være, at en IP-adresse, host navn, URL (ved hjælp 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 arbejdstagere).

Jobbet selve serveren ikke rigtig har en kompliceret opgave (i en grundlæggende system alligevel), er det nødvendigt at gemme en liste over job, uddele opgaver, 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 en administration interface til at tilføje, redigere, slette, suspendere job, men det er efter 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 server imidlertid ikke brug for høj tilgængelighed, hvis det går ned på en fredag ​​aften, du kommer til at miste en hel weekend for behandling, potentielt koster dig et par uger til en værdi af sagsbehandlingstiden (sammenlignet med dine vigtigste behandling server alene) . Du ønsker måske at overveje at sætte dit job server på en belastning afbalanceret miljø for høj tilgængelighed.

Grundlæggende opsætning

Den grundlæggende opsætning til vores job-server vil bestå af hvad jeg kalder en af mine halte servere (dvs. Li nux, m ySql, P HP). Koden kører på the arbejdstagere faktisk vil arbejde ud af, hvad job det kan køre ved at interagere med med job styresystem databaser. Senere kunne vi skabe en webservice og faktisk uddele job snarere end at have arbejderne gør det hårde arbejde selv, men for nu vil vi fortsætte med at bruge KISS princippet (Keep it Simple, Stupid!).

Så lader oprette tre MySQL tabeller til at behandle job. Disse vil blive `job`, `jobRecords`, og `jobResults«.

Her Jeg bruger SQL Buddy en stor lille alternativ til phpMyAdmin bare fordi dens lettere at installere på CentOS (for andre se: 10 Great alternativer til phpMyAdmin )

Denne tabel består af 5 enkle felter,

• id: entydigt identificerer jobbet
• navn: Kunne være en klient reference, eller hvilket som helst antal af andre identifikatorer
• Status: Du skal vide, hvor jobbet er på, f.eks
  • 0: Ikke startet
  • 1: Afhentet
  • 2: Afsluttet
• started_by: Hvem er begyndt at gøre jobbet? Det er ikke helt påkrævet, men er en dejlig at have. Jeg vil foreslå tracking arbejdere af deres IP-adresse på dit netværk
• started_at: Hvornår arbejdstageren starte jobbet? Ved at spore arbejdspladser, der ikke er afsluttet inden for X beløb på tide, at vi ved, at vi har brug for at hente jobbet igen og starte behandlingen af ​​en anden arbejdstager. Arbejdere kunne stoppe behandlingen / gå offline for en række årsager, strømsvigt, nedbrud, netværk tab, osv.

Det er nemt, hvordan denne tabel kunne udvides med et par ekstra felter for at muliggøre statistiksystem, en sluttidspunkt kolonne for at se, hvor lang tid jobbet tog, en tæller til at se, hvor mange arbejdere tog jobbet (naturligvis må dette har tendens til at 1), job prioritet, kan listen blive ved og ved. I mere kompleks opgave scenarier vil det være muligt at angive, hvor meget hukommelse arbejdstageren ville have adgang til (og derfor kun er anvendt passende arbejdstagere), eller endog hvilken type arbejdstageren ville være påkrævet.

Lad os tilføje et par eksempel job:

Den næste bordet igen er ganske simpelt at forstå, disse er vores job optegnelser. De er knyttet til de vigtigste job bordet ved en kolonne `jobs_id«. De fyldes op af denne tabel afhænger meget af de data, du skal bruge til at levere dine medarbejdere, lader gøre et meget simpelt eksempel, hvor vi har fire kolonner:

• id: ID af posten
• navn: Person navn
• adresse: Person adresse
• jobs_id: Jobbet ID, at denne post er knyttet til

Den tredje og sidste tabel består af en resultatside bord, det har stort set samme gør op med vores registreringer bord, og med tilføjelse af nogle kolonner kunne være en del af posterne tabel:

• job_record_id: Link resultatet til jobbet bordet
• Resultatet: Resultatet data

... Og det er alt hvad du behøver for job kontrol! (Dog på et meget grundlæggende niveau) I mit tilfælde er jeg henvist til en anden tabel, hvor mine data til processen var placeret, men det kunne lige så let er blevet en fil, parametre for at køre simulering kode, you name it.

Valg af en job

Som tidligere nævnt, vil arbejderne gøre vores jobstyring for os nu, så vi alle nødt til virkelig at gøre, er at finde et job, der kræver behandling og få oplysningerne. Hvordan ville vi gøre det? Nå vælge vores job udvælgelseskriterier og kigge efter job i SQL jeg gjorde følgende:

1. Træffe alle job, der ikke er markeret som komplet, men fra vores arbejdstager-og nulstille dem (erstatte __ME__ med en identifikator, ville nemmeste være IP-adresse):

     UPDATE `jobs` SET `status` = 0 WHERE `status` = 1 og `started_by` = __ME__; 

2. 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 TIME)) ORDER BY `id` ASC; 

   Ved at snuppe arbejdspladser, der ikke returnerede resultater i X tid vi sikrer, at alle job er at køre i tilfælde af en arbejdstager bryder eller gå AWOL.

3. Næste fat i job detaljer efterfulgt af journaler selv:

     SELECT * FROM `job` WHERE `started_by` = __ME__ LIMIT 1;
    SELECT * FROM `job_records` WHERE `id` = __JOBID__; 

Ved afslutningen af ​​job, vi indsætter vores resultat optegnelser og markere jobbet som komplet. Husk som arbejdspladser kan suspendere / genoptage til enhver tid giver mulighed for nogle 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 at skifte til en webservice, en fil baseret system, XML , eller enhver anden Antallet af systemer vil det ikke påvirke koden ovenover.

Job Configuration

Det næste aspekt at overveje, er opgavens omfang og konfiguration. Ved at spille med job konfiguration, vi kan finde en god balance mellem hastighed, proces replikering, og pålidelighed. Tag et par of scenarier:

1. Jobs tage 1 dag hver til at køre: Det betyder, at dine medarbejdere skal bruge 15 dage til at behandle hvert job (husk 10% af den strøm til 2/3rds af tiden). Dette er tydeligvis ikke en klog konfiguration, dit job størrelse er alt for stor! Det ville tage mindst dobbelt så lang tid at få et job forarbejdet bør den initiale arbejdstageren gå AWOL (tid til at samle op, at det ikke har returneret et resultat plus oparbejdning tid). I en ideel du gerne have mindst en hel job nemt ryddet inden udgangen af hver langside inaktiv periode, den måde du holder jobs tikkende over og i værste fald et job ville tage to dage at behandle, bør den første forsvinder.
2. Jobs tage 1 minut til at køre: Det betyder, at dine medarbejdere tager cirka 15 minutter at køre hvert job. Selv om dette kan i første omgang synes ideel, får du ekstra arbejde forarbejdning under frokost tid, kaffepauser, møder, osv. dette scenario lægger pres på andre områder af dit system og indfører sine egne problemer. For eksempel er det første din opsætning / behandlingstid forholdet kommer til at gå helt ned, derfor mister systemets effektivitet. Dit netværk bliver hele tiden streaming jobinformation til de forskellige arbejdstagere frustrerende medarbejdere, der er dong deres daglige arbejde. Du vil også lægge mere pres på jobbet behandling server, som det har til at uddele masser og masser af små stykker arbejde på en regelmæssig basis. Endelig i denne situation, hvis dit job server går ned, du vil oprette en kæmpe tilbage log af uafsluttet arbejde, mens større arbejdspladser kan for fortsat behandling lykkeligt uvidende om, at jobbet server var i vanskeligheder.

I virkeligheden vil der ikke være en ideel konfiguration til din net opsætning, meget afhænger af de tilgængelige ressourcer, typer af job, job ekspeditionstid krav, netværk kapacitet, og så videre. Men nogle retningslinjer ville være:

• Størrelse job, således at hver arbejdstager kan komme igennem mindst 3-4 arbejdspladser i en periode på 15 timer (den længste sandsynlige tomgang tidsrum)
• Spil med jobbet størrelse, så opsætningen bliver tid ret ubetydelig i forhold til sagsbehandlingstiden (i betragtning af ovenstående punkt).
• Hvis et job ikke komplet i dobbelt tid (måske mindre), du forventer at færdiggøre det antages, at dets gået AWOL og begynde at behandle den med en anden arbejdstager. Dette betyder, at du måske nødt til at vente op til tre gange den normale længde af et job til den er færdig (eventuelt længere, hvis de efterfølgende jobbet mislykkes). Du ønsker måske at reducere denne tid, men pas på ikke at reducere det alt for meget, da du kan starte gentage behandlingen opgaver på en regelmæssig basis.
• Arbejdspladser bør være uafhængige af eksterne krav så meget som muligt. Jobbet server, for eksempel, bør kun kontaktes ved starten og slutningen af ​​hver opgave.
• Må ikke mætte dit netværk, vil dette få to negative virkninger, vil din dagtimerne medarbejdere finde ved hjælp af nettet frustrerende og problemer kan opleves med tilslutninger timing et problem, som kun vil blive værre, når du skalere din net.
• Sikre arbejdspladser kan køre på dine medarbejdere. Hvis arbejdspladser bliver for hukommelse intensiv eller diskplads intensiv job vil starte abortere, og det eneste du vil bemærke er et fald i antallet af arbejdspladser er forarbejdet med nogen reel grund til.

Indsendelse Resultater af en Job

Ved indsendelse af resultaterne af et job er det vigtigt at kontrollere, at resultaterne ikke er blevet indsendt af en anden arbejdstager, især hvis den nuværende arbejdstager har været i dvale i et stykke tid.

Når resultaterne er fremlagt sikre, at antallet af resultater svarer til det antal af poster i jobbet.

Som nævnt tidligere, og kan ikke være over understreges, at bygge fejltolerance i job hentning og resultater underkastelse. Arbejderne kan (og højst sandsynligt vil) gå i pausetilstand på de mest ubelejlige af gange, og dette skal tilgodeses. Også endnu en gang abstrahere væk dine resultater indsendelse vil hjælpe tage højde for fremtidige ændringer i dit job styresystem meget nemmere at håndtere.

Resumé

I denne section vi har kigget på, hvad et job kontrol server har brug for at gøre, og hvordan man får et meget grundlæggende system oprettet. Vi diskuterede hvordan man kan hente et job fra kontrolsystemet og hvordan man bedst kan konfigureres job for at få mest vores af dit kontor skinnesystem. Til slut, et afsnit eller to om fremlæggelsen tilbage til jobbet styre serveren blev præsenteret.

• Et job kontrol-server styrer job og sikrer, at alle arbejder enheder er afsluttet
• Ved at abstrahere dit job at vælge / resultater indsendelse vi kan ændre teknologien i kontrol-serveren uden megen problemer
• Konfigurer din job at sikre, at de kører hurtigt og effektivt uden at lægge for meget pres på dit netværk infrastruktur, og uden at overlappe forarbejdning opgaver på en regelmæssig basis.
• Sørg for, at du bygger fejltolerance og fejl checking i din rutiner, kan arbejdstagerne suspendere og genoptage og de mest ubelejlige tidspunkter. Husk at kontrollere, om resultater, der allerede er indsendt af en anden arbejdstager.

Næste gang

I del 3 vil vi skabe vores virtuelle behandling maskine og opsætte vores vinduer maskiner for at blive ledig tid arbejdstagere.

Et svar til "Office Grid Computing bruger virtuelle miljøer - Del 2"

1. Hydrolysere siger:

   Torsdag d. 18. februar 2010 kl 19:11

   Heya! Godt koncept, men kan det virkelig gøre arbejdet?

   Svar