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
Den grundlæggende opsætning til vores job-server vil bestå af hvad jeg kalder en af mine slatne servere (dvs. Li nux, m ySql, P HP). Den kode, der kører på thea arbejdere rent faktisk vil finde ud af hvilke job det kan køre ved at interagere med med job-styresystem databaser. Senere kunne vi skabe en web service og faktisk uddele job frem for at lade arbejderne udføre det hårde arbejde selv, men for nu vil vi fortsætte med at anvende KISS princippet (Keep It Simple, Stupid!).
Så kan oprette tre mySQL tabeller til at beskæftige sig med job. Disse vil blive `jobs`, `jobRecords` og `jobResults`.
Her Jeg bruger SQL Buddy en stor lille alternativ til phpMyAdmin bare fordi det er nemmere 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 en række af andre identifikatorer
- Status: Du skal vide, hvor opgaven er, fx
- 0: Ikke startet
- 1: samlet op
- 2: Afsluttet
- started_by: Hvem er begyndt at gøre jobbet? Dette er ikke helt påkrævet, men er et rart at have. Jeg vil foreslå, sporing af arbejdstagere ved deres IP-adresse på dit netværk
- started_at: Hvornår arbejdstageren starte jobbet? Ved at spore job, der ikke har gennemført inden for X tid, vi ved vi nødt til at afhente jobbet igen og starte behandling af en anden arbejdstager. Arbejdstagere 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 statistik sporing, et sluttidspunkt kolonne for at se, hvor lang tid jobbet tog, en tæller til at se, hvor mange arbejdere tog jobbet (selvfølgelig det skal en tendens til at 1), job prioritet, kan listen blive ved og ved. I mere komplekse job scenarier vil det være muligt at angive, hvor meget hukommelse arbejdstageren ville have adgang til (og derfor kun er anvendt passende arbejdstagere), eller sågar hvilken type arbejdstager krævede ville være.
Lad os tilføje et par eksempel job:
Den næste bordet igen er ganske simpelt at forstå, det er vores job optegnelser. De er knyttet til de vigtigste job bordet ved en kolonne `jobs_id`. Den gør op med denne tabel afhænger meget af de data, du har brug for til at levere til dine medarbejdere, kan 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 rekord er knyttet til
Den tredje og sidste tabel består af et resultat tabellen, har stort set samme gør op som vore optegnelser bordet, og med tilføjelse af nogle kolonner kunne være en del af posterne tabel:
- job_record_id: Link resultatet til jobbet bordet
- Resultat: Resultatet af data
... Og det er alt du har brug for job kontrol! (Omend på et meget grundlæggende niveau) I mit tilfælde er jeg pegede på et andet bord, hvor mine data til processen var placeret, men det kunne lige så let være blevet en fil, parametre til at køre simulering kode, you name it.
Valg af et 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). 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 forarbejdet job bør den initiale arbejdstager gå væk fra mig (tid til at samle op, at det ikke har returneret et resultat plus oparbejdning tid). I en ideel du gerne have mindst en hel jobbet let slettes ved udgangen af hver langside inaktiv periode, den måde du holder jobs tikker over og i værste fald et job, ville tage to dage at processen bør de første forsvinder.
- Jobs tage 1 minut til at køre: Det betyder, at dine medarbejdere tager cirka 15 minutter at køre hvert job. Mens dette kan i starten synes ideelt, 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 introducerer sine egne problemer. For eksempel dit setup / sagsbehandlingstiden forholdet først og fremmest kommer til at gå helt ned, således at miste systemets effektivitet. Dit netværk vil være konstant streaming job information til de forskellige arbejdere frustrerende medarbejdere, som DONG deres daglige arbejde. Du er også kommer til at lægge mere pres på dit job forarbejdning serveren, som det er at uddele masser og masser af små stykker arbejde på regelmæssig basis. Endelig, i denne situation, hvis dit job server går ned du kommer til at skabe en enorm tilbage log over uafsluttet arbejde, mens større arbejdspladser kan for fortsat behandling lykkeligt uvidende om, at jobbet serveren havde vanskeligheder.
I virkeligheden vil der ikke være en ideel konfiguration til dit net setup, meget afhænger af de tilgængelige ressourcer, typer af job, job ekspeditionstid krav, netværks-kapacitet, og så videre. Men nogle retningslinjer vil være:
- Størrelse job, så at hver arbejdstager kan komme igennem mindst 3-4 arbejdspladser i en periode på 15 timer (den længste sandsynlige inaktiv periode)
- Spil med jobbet størrelse, så setup tid bliver temmelig ubetydelige i forhold til behandlingstiden (under hensyntagen til ovenstående punkt).
- Hvis et job ikke komplet i dobbelt så lang tid (måske mindre), du forventer at færdiggøre det antage, at det er væk væk fra mig og begynde at behandle det med en anden arbejdstager. Dette betyder, at du måske nødt til at vente i op til tre gange den normale længde af et job til den er færdig (muligvis længere, hvis den efterfølgende jobbet mislykkes). Du ønsker måske at reducere denne tid, men vær forsigtig med ikke at reducere det alt for meget som du kan begynde at overlappe behandlings opgaver på regelmæssig basis.
- Jobs 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 effekter, vil din dagtimerne personalet finde ved hjælp af netværket frustrerende og problemer, kan opleves med tilslutninger timing et problem, som kun vil blive værre, når du skalere din net.
- Sikre jobs kan køre på dine medarbejdere. Hvis arbejdspladser bliver for hukommelsen intensiv eller diskplads intensivt job vil begynde at opgive, og det eneste du vil bemærke er et fald i antal arbejdspladser behandles uden reel grund til hvorfor.
Indsendelse Resultater af et job
Ved fremlæggelsen 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 arbejdstageren har været i dvale i et stykke tid.
Når resultaterne er fremlagt sikre, at antallet af resultater svarer til det antal 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 standby-tilstanden på det mest ubelejlige gange, og det skal være taget højde for. Også igen 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 har vi 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 henter et job fra kontrolsystemet og hvordan man bedst kan konfigurere job for at få mest vores af dit kontor skinnesystem. Til slut, var et afsnit eller to på sende resultaterne tilbage til jobbet Control Server præsenteret.
- Et job kontrol server styrer job og sikrer, at alle arbejder enheder er afsluttet
- Ved at abstrahere dit job vælge / resultater indsendelse vi kan ændre teknologien i kontrol-serveren uden de store problemer
- Konfigurer dit 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 behandlings opgaver på regelmæssig basis.
- Sørg for, at du bygger fejltolerance og fejl checking ind i dine rutiner, kan arbejderne afbryde og genoptage og de mest ubelejlige af gange. Husk at kontrollere, om resultater, der allerede er blevet indsendt af en anden arbejdstager.
Næste gang
I del 3 vil vi skabe vores virtuelle behandling maskine og oprettet vores Windows-maskiner for at blive ledig-deltidsansatte.
Kommentarer (4) 
Artikler , PHP , web-programmering , Zend Framework | 
rammer , ini , PHP , Router , Routes , Zend , Zend Framework , Zend_Navigation , Zend_Router 
