Kommentarer (2)

Ved Steven Lloyd Watkin , fredag ​​4 dec 2009 11:59

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 3 har vi skabt vores virtuelle behandling maskine og opsætte Windows-maskiner for at blive ledig tid arbejdstagere.

Kører den seneste kode

Uundgåeligt efter oprettelsen dine medarbejdere forretningslogik vil ændre sig, vil bugs findes, mere effektivt kode vil hurtigere blive produceret overlades dermed dine medarbejdere sad rundt behandling af data ved hjælp gamle ildelugtende kode . Hvordan så sikrer vi, at vi altid bruger de nyeste og bedste version af vores behandling scripts?

Der er et par meget nemme enkle måder, hvorpå vi kunne gøre dette, det trick er dog at reducere behandlingstiden magt og netværkstrafik til at nå dette. Lad os starte med det simpleste af løsninger og forbedre det langsomt over et par iterationer.

Den første metode ville være at blot forbindelse til vores job kontrol server (via samba, FTP eller lignende) og træk ned den seneste version af koden. Ikke meget effektiv, men det vil gøre arbejdet. Lad os forbedre det lidt, hvordan om at skabe en rsync script og bruge, at hver gang i stedet? Alternativt hvad med at sætte vores seneste forarbejdning script til undergravende virksomhed tjekker ud koden i første omgang og så bare opdatere vores kode på hver kørsel ( svn update )?

I sidste ende kunne vi ende med et bash script (kaldet af cron hver 10 minutter), der ser lige så simpelt som dette:

  #! / Bin / sh
 hvis ps ax | grep-v grep | grep php > / dev / null
 Derefter
     echo "Job i øjeblikket behandling, frakørsel"
 andet
     echo "Job er ikke kører, skal du starte nu"
     cd / sti / til / arbejde / kopier
     svn update
     php yourJobProcessingScript.php
 fi 

Nu kan vi være sikre på, at med hvert løb er vi absolut kører den seneste kode. Vi sikrer dette ved at opdatere vores kodebase hver og hver gang vi udfører en løbetur og reducere netværkstrafikken ved kun at overføre filen forskelle på tværs af vores netværk.

I min demonstration setup, gjorde jeg nøjagtig som ovenfor. Subversion blev installeret på mit job forarbejdning server, og jeg simpelthen trak den nyeste kode fra en »arbejdstager« filial bruge 'svn update'. Jeg har også tilføjet en versionsnummer tag til min behandling script, der blev sendt tilbage til databasen som en del af resultaterne tilbage. På den måde kunne jeg se, at min kode var ved at blive opdateret hver gang jeg kopieret min kuffert i arbejdstagerens gren vil sige, at jeg var helt kører den seneste behandling script.

Bruger den nyeste data

Hvis dit job forarbejdning gør brug af datakilder så på et tidspunkt disse vil blive opdateret. Medmindre du ringer til din datakilder på en meget sjælden grundlag du vil oversvømme netværket med trafik, så snart dine medarbejdere begynde at køre bringe alt i stå. For min løsning besluttede jeg, at jeg vil flytte mine data kilder rundt med mine VM'er.

Hold du heste der! Hvad hvis min datakilder er KÆMPE? Nå det er virkelig en sag, hvor meget data vi taler? Det kan være mere omkostningseffektivt at installere en ekstra større harddisk i hver maskine, end at købe en ekstra behandling server. Dette er et spørgsmål om budget og er op til virksomheden at afgøre. Det måske, at dine datakilder er så store, at det bare umuligt at holde, at mængden af data i din arbejdstager maskiner. I så fald hvad ville du gøre? Godt vi kunne se på at kalde en lokal data-server, men dette kan forårsage problemer med netværket. I dette tilfælde et gitter system som dette kan blive urealistisk at medtage i dit kontormiljø. Det kan også være, at du kan se i alternative løb strategier, for eksempel kun at kalde dine medarbejdere fra 08:00 til 06:00 hver aften og / eller kvæle datakilde anmodninger.

Bevæger sig på lad os sige vores datakilder beløbe sig til 100 GB data. Nå ja det er ganske lidt af data til at flytte rundt på nettet på en opdatering. Hvordan vil vi sikre, at vi har den seneste kopi af dataene i denne sag? Rsync er en mulighed, men jeg personligt tror, ​​ved at køre dit seneste datakilde på dit job forarbejdning server og konfigurere dette som en mester i replikation (med en dejlig lang bin log) kan være vejen at gå:

Ved at indstille hver af dine medarbejdere op som en slave til jobbet Control Server opdateringer til dine datakilder vil sive ned pænt til dine medarbejdere uden en enorm stigning i net-aktivitet (det er medmindre du udfører en kæmpe data opdatere og alle dine medarbejdere spark i på én gang). Dette har fordele i forhold til rsync i, ​​at du ikke ville få en lang pause før hvert job, som database opdateringer, MySQL på din arbejdsplads, vil dæmonen løbende opdatere sine data, mens behandlingen fortsætter.

Dette er, hvordan jeg oprettet min demonstration server. At oprette replikation jeg fulgte guiden på mySQL websted ( Opsætning replikation ) og inden for 20 minutter, som jeg havde min inital arbejdstager gentage jobkontrol servere datasæt. For hver yderligere arbejdstager replikation indstillinger og proces arbejdede hver gang, da VM blev kopieret.

Resumé

I dette afsnit af artiklen har vi set på, hvor let og smertefrit det er at holde din behandling koden up to date med using rsync eller subverion (SVN) til at gøre arbejdet og reducere netværkstrafik på samme time. Vi har også diskuteret, hvordan at holde dine oplysninger om datakilden up-to-date, idet den kan sive ned til hver af dine medarbejdere. Således er vi område at sikre, at vi holder op med forretningslogik og information i vores kontor skinnesystem. Der vil naturligvis være utallige alternativer til at udføre disse opgaver, men her var to simple eksempler for at vise, hvor let en løsning er at finde.

Næste gang

I den sidste del af denne serie, som er opkaldt rammende Del 5 , vil vi diskutere implementere dette system til. Jeg vil sammenfatte, hvad der er lært, og hvad jeg formåede at skabe.

Kommentarer (3)

Ved Steven Lloyd Watkin , fredag ​​4 dec 2009 23:37

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 2 har vi kigget på de arbejdspladser, en server vil køre, og hvordan arbejdspladser skal konfigureres for at opnå størst mulig behandling og samtidig sikre, at hver opgave er behandlet uden fejl.

Opsætning af din arbejdstager - eller Limp server

Det næste skridt i processen er at oprette din virtuelle medarbejdere. Det vil jeg tænkt mig at bruge en installation af CentOS bruge VirtualBox. Jeg har tænkt mig at installere mySQL og PHP på serveren, også kendt som en halte (Li nux, m ySQL, P HP) Servera (jeg kan have gjort dette navn op).

• Installer VirtualBox på din Windows-maskine (følg link)
• Hent og installer CentOS (nuværende version 5.3) inden for en skabt virtuel maskine

Der er ingen punkt mig at gå til dette er der nok 1.000 's store tutorials derude (ok, her er en: Oprettelse og Managing CentOS virtuel maskine under VirtualBox ). Det vigtige punkt at bemærke jeg formoder er, at jeg ringede til min virtuelle maskine GridMachine.

For så vidt angår mit valg af virtualisering klient og operativsystem gå der er ingen store tvingende grund for hvert valg. VirtualBox er noget jeg bruger på mit hjem maskine og er støttet af de tre store operativsystemer. Jeg valgte CentOS som er en god stabil OS og jeg bruger det på min egen webserver. Jeg er en stor tilhænger af de rigtige værktøjer til opgaven (selvom jeg anvender brug den hurtigste og nemmeste for dig "-mentalitet her), så hvis styresystemet X kører din kode hurtigere og mere effektivt at bruge det i stedet:)

Vigtigere at sikre, at din VM bruger DHCP, ellers for hver ny virtuel maskine skulle være konfigureret separat, hvilket er noget vi ikke want.By bruger DHCP vi behøver ikke at konfigurere netværksindstillinger individuelt for arbejdstager-maskiner, vil DHCP hånd ud IP'er for dig. Derfor kan du kopiere din virtuelle maskine omkring kontoret uden at bekymre sig om opsætning hver en op (det forbedrer skalerbarhed og reducerer arbejdstager administration).

Den proces, du bør sigte mod at opnå ville være at få en ny fysisk maskine, installere VirtualBox, og derefter stort set installere det virtuelle billede uden meget andet. Det kan være klogt at sætte alle dine medarbejdere på et andet subnet, så du kan i det mindste se, hvor mange maskiner der kører. Du skal også oprette dine maskiner på en lang lejekontrakt eller ubegrænset leje DHCP.

Sådan køres Jobs på arbejdstagerens

Dette er en interessant område, og der er flere gyldige metoder til behandling job på arbejdstager. Her vil jeg blot diskutere de to mest oplagte:

• Bestandigt at køre script: Et script, det være sig et shell script, eller et PHP script der udføres én gang på arbejdstageren og kører som en del af en uendelig løkke. Jeg har tilbagediskonterede denne metode som et brag af manuskriptet og potentielt dine medarbejdere vil ophøre med at køre uden en form for intervention.
• Cron baseret script udførelse: Hvert X minutter cron dæmonen starter et opkald til dit script til at få tingene i gang. Uden nogle at markere dette kan føre til mange mange kopier af din arbejdstager script kører.

Min beslutning var at gå med cron, som skydes i gang en shell script hver 10 minutes. Min shell script udfører følgende opgaver:

1. Få en proces liste og grep dette for 'php'. Hvis ikke fundet derefter fortsætte.
2. Ring til dit job kode, i mit tilfælde ville det være noget PHP baseret
3. Arbejdstager script afslutter sin køre
4. Klar til at gå igen på næste indkaldelsens

Min bash script ser ud som følgende:

  #! / Bin / sh
 hvis ps ax | grep-v grep | grep php> / dev / null
 Derefter
     echo "Job i øjeblikket behandling, frakørsel"
 andet
     echo "Job er ikke kører, skal du starte nu"
     php yourJobProcessingScript.php
 fi 

Bemærk: ekko's er næsten helt meningsløst, men kan hjælpe den næste person, der kommer sammen for at prøve og redigere dem.

, Der konkluderer oprettelsen af ​​arbejdstagerens virtuelle maskine, hurtig, enkel og let at kopiere til hver ny stykke hardware, der er modtaget. Den »Klogskab« af forsyningsnettet er virkelig ikke i visualiseret OS, dens al at gøre med den kode skabt til at behandle job, jobbet konfiguration, og i at sikre, at opgaven skal udføres når det er hensigtsmæssigt (dvs. når værten er ledig ).

Opsætning af Windows til Initialiser Workers

Den første opgave er at arbejde ud kommandoen til at køre den virtuelle maskine fra vinduerne kommandolinjen. Hvis du har installeret VirtualBox på standardplaceringen, og du har navngivet din arbejdstager GridMachine derefter kommandoen kræves for at indlæse dine arbejdstager er:

  "C: \ Programmer \ sun \ VirtualBox \ VBoxManage.exe" startvm GridMachine 

Men at køre scriptet i en »hovedløs 'state vi nødt til at bruge:

  "C: \ Programmer \ sun \ VirtualBox \ VBoxHeadless.exe"-startvm GridMachine - vrdp = off 

Dette vil starte den virtuelle maskine uden GUI og lad det spare staten elegant. Det andet argument slukker RDP, så det ikke er i konflikt med vinduer RDP, eller give dig en besked om at lytte på port 3389. Den virtuelle maskine navn er store og små bogstaver!

Derefter skal vi nødt til at indstille vinduer på op til kick off vores arbejdstager VM, når maskinen er inaktiv. At gøre dette (på Windows XP), du bliver nødt til at gå på Start -> Alle Programmer -> Tilbehør -> Systemværktøjer -> Planlagte Opgaver som nedenfor:

Klik derefter på 'Tilføj Scheduled Task "efterfulgt af gennemse for at tilføje en brugerdefineret program. Naviger til din VBoxManage script og klik ok. Planlæg din opgave for enhver af de muligheder (vi vil ændre dette i et minut) og fortsætter. Efter at have sprunget det næste skærmbillede vinduerne vil spørge dig, hvem du vil køre denne opgave, vil jeg foreslå enten 'Administrator' eller oprette en ny bruger med rettigheder. Husk at vi ikke ønsker at blande med den standard personale konto på maskinen på noget tidspunkt. Klik på Næste og kontrol viser, avancerede indstillinger for denne opgave.

Til slutningen af tiden tekstfeltet tilføje vores "startvm GridMachine 'streng og sikre, at der kun kører, når logget ind er tilbage markering. Besøg tidsplanen opgaven næste og ændre tidsplanen drop ned til muligheden ", når inaktiv ', vælge den mængde tid, du gerne vil have maskinen til at være ledig, før man går videre til den næste fane.

Endelig jasket den mulighed, der hedder stoppe opgave, hvis det har kørt X mængde tid, men sætter kryds mulighed for at stoppe den opgave, hvis maskinen ikke længere er ledig.

Det var det så for Windows host setup!

Resumé

I denne del har vi oprettet en virtuel maskine til at fungere som en arbejdstager, samt den måde, som vi kalder og udføre vores job forarbejdning scripts (for mig selv et PHP script). Herfra kan vi se på, hvordan man opsætter vores kopier af Windows til at starte op den virtuelle maskine i hovedløs tilstand, når computeren bliver ledig, og gemme sin tilstand, når brugeren genoptager brugen af ​​maskinen. Forhåbentlig på dette punkt, du ser, hvor nemt det er at oprette et sådant system og er kløe at få nogle eksperimenter i gang selv!

Næste gang

I Part 4 vil vi kigge på ved hjælp af værktøjer til at sikre, at du kører den seneste version af kode og data kilder, så opnåede resultater er altid up-to-date med de nyeste forretningsoplysninger og logik.

Kommentarer (1)

Ved Steven Lloyd Watkin , fredag ​​4 dec 2009 11:23

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.

Som en PHP udvikler jeg har tænkt mig at bruge værktøjer, som jeg bruger hver dag, nemlig Linux, mySQL , PHP, VirtualBox og undergravende virksomhed (SVN). Men jeg håber, at denne guide vil tilpasse sig andre sprog og teknologier lige så godt.

Den løsning, jeg giver, vil være meget løst baseret på den type behandling vi havde behov for at opnå men dette kan ikke være rigtigt igennem hele artiklen, som jeg vil ændre tingene til enkelthed, eller til at producere mere interessant brugsscenarier.

Disse virtualiserede miljøer vil køre på Windows maskiner, da dette er hvad de fleste kontorer køre. Behandlingen, at kontormaskiner ikke må ikke gribe ind med personale ved hjælp af disse maskiner, bør kræve, ingen vedligeholdelse på maskinen og være let indsættes til nye maskiner, som de bliver tilgængelige. Desuden bør nye virtuelle maskiner, der ikke kræver nogen yderligere konfiguration, da dette i høj grad reducerer skalerbarhed og brugervenlighed, hvor elnettet kan udvides.

Hvorfor Implementer en Office Computing Grid?

Først skal du kan tænke, hvorfor ikke bare bruge en cloud computing ressource såsom Amazons EC2-platform ? Nå årsagerne kan være flere, for eksempel:

• Du vil ikke overdrage visse data til en cloud computing miljø
• Du kan ikke sætte bestemte data i en cloud computing miljø for juridiske årsager (f.eks data forlader landet), som potentielt af juridiske årsager, fx NHS poster.
• Du ønsker at beholde din behandling enheder tæt og har fuld kontrol over den hardware er for
• Du har ikke projektmidlerne til at køre sky forekomster
• Dit kontor ikke har en forbindelse til internettet og dermed dets ikke muligt at bruge en sky ressource
• Du ikke kan lide regn, skyer tyder regn, derfor skal du holde sig langt væk

Jeg er sikker på listen kunne fortsætte, men jeg tror, ​​det er nok for nu.

Fordele ved et kontor Computing Grid

Nå, lad os gøre nogle matematik (og i ægte fysik stil lader foretage nogle gennemgribende antagelser). Forestil dig at du har store velnæret behandling server, der kører 100 arbejdspladser om dagen. I dit kontor, du har 50 maskiner, som er inaktive 16 timer om dagen, hver af disse maskiner er 10% så kraftig som dine velnæret behandling bryde. (Alle resultater her er afrundet til at undervurdere performance stigning).

Så maskine * 10% effekt * 2 / 3 tid = 0,067, dvs 1 desktop forarbejdning i tomgang tid kunne 1 proces 6 fulde opgaver pr.

Hvis du nu skalere dette op, det tager 15 tomgang desktops til at behandle så mange arbejdspladser pr dag, som din vigtigste behandling server gør.

Så i vores lade kontor på 50 maskiner, vi kunne øge vores processorkraft fra 1 server op til 4 full processing servere, eller vi kunne forarbejdning 400 job om dagen i stedet for 100.

Varsel, for ingen investering i ny hardware din virksomhed har netop øget sin batchbehandling kapacitet 4 gange! Potentielt du vil øge din strømforbrug, men fra de fleste kontormiljøer, jeg har været til maskiner er generelt tilbage på natten alligevel, så du kunne se dette som en grøn initiativ.

Andre fordele også betyde, at investeringer i nye (eller opdateret) forarbejdning servere kan blive forsinket, hvis dit kontor maskiner er tilstrækkelige, og at når du forbedrer kraften i din kontormaskiner dit kontor nettet bliver mere kraftfuld automatisk.

Teknologier

Hvad du har brug for? (Eller mere korrekt, hvad har jeg brug):

• Tomgang kontormaskiner (i mit tilfælde en ekstra gamle vinduer XP laptop)
• VirtualBox (eller en anden virtualiserings klient-software)
• En virtuel maskine med PHP, mySQL running kører en skære ned OS, jeg ringer disse mine Limp servere:)
• Arbejdspladser til at køre
• Job server (kan være en anden virtuel maskine eller andet sted)

Typisk Job

De typer af job, at dette system er designet til at køre, er som følger:

• Systemet modtager en liste over data, som vi skal matche og returnere resultater
• Matchende indebærer kontrol / søgning flere (temmelig statisk) datakilder
• Resultater fra datakilder kan kræve yderligere validering, sammenlægning, kontrol af yderligere datakilder som reaktion på resultaterne
• Data returneres med matchende poster, fuldt valideret og forarbejdede
• Hver post i et job er uafhængig af resten

Så dybest set, vi kigger på løb job, som kræver en blanding af database opslag og nogle talknusning, en ret typisk scenario i et erhvervsmiljø.

Grid løsninger er ikke kun fordelagtig for behandling job af denne type. Dybest set kan enhver proces, som kan opdeles i selvstændige enheder, der skal køre sideløbende. Se denne wikipedia for eksempler og mere information: Grid Computing , men et par kendte eksempler er Seti @ Home og BIONC . Der er rammer for at køre computing net, og disse er værd at se på.

Hvad vil vi opnå?

Ved udgangen af ​​disse artikler, jeg håber at vise, at indsætte et kontor gitter ikke behøver at være enormt dyrt eller tidskrævende. Jeg har tænkt mig at diskutere:

• Opsætning af jobbet kontrolsystem, job konfiguration
• Oprettelse af en passende behandling virtuel maskine
• Hvordan til opsætning af systemet på en Windows-maskine
• Sikrer, at du bruger den nyeste kode og data
• Deployment og benchmarking
• At se fremad

Jeg vil være bygning (ok jeg bygget, så skrev dette) et eksempel program for at teste begreber på en lokal maskine ved hjælp af Windows XP og min 'GridMachine' virtuelle maskine. Mit job kontrol server vil være min primære maskine, der kører Fedora 11 .

Dette er på ingen måde betød at demonstrere en fuldt fungerende robust system, dets betød mere af en demonstration og diskutere viser, at disse ting kan opnås i en rimelig kort tid og med små omkostninger. Du er velkommen til at sende mig nogen kommentarer, rettelser eller forbedringer, og jeg vil gøre mit bedste for at holde denne artikel opdateret til at matche.

Næste gang

I del 2 vil jeg starte med at kigge på jobbet styresystem, og se på, hvordan arbejdspladser skal konfigureres for at opnå størst mulig behandling og samtidig sikre, at hver opgave er behandlet uden fejl.

Kommentarer (1)

Ved Steven Lloyd Watkin , fredag ​​4 dec 2009 11:23

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 det 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 det efterfølgende job 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.

Kommentarer (3)

Ved Steven Lloyd Watkin , fredag ​​4 dec 2009 11:03

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 4 så vi på brugen af værktøjer til at sikre, at vi kører den seneste version af kode og data-kilder, således at opnåede resultater er altid up-to-date med de nyeste forretningsoplysninger og logik.

Pre-Deployment

Før implementering dit forsyningsnettet, hvis der er én ting, du gør, og én ting alene er det benchmark dit nuværende system! Ligegyldigt hvad du fortæller kolleger om, hvor meget ekstra arbejde systemet kommer til at gøre, medmindre du har numre til bakke dette op din garantier ingenting. Så

• hvor mange poster kan du behandle i øjeblikket? Pr dag? I timen?
• Hvor lang tid tager det typisk tager at vende rundt et job?
• Hvor meget mere kapacitet har du?

Der er også yderligere spørgsmål:

• Hvis din behandling server (eller en af ​​dine forarbejdning servere) går ned, hvordan vil det påvirke dine muligheder, vil du blive lammet?
• Hvilke fordele håber du / forventer at komme fra et gitter system?
• Er dine kontormaskiner stand til at køre de job?
• Er din (eller kan du job konverteres) til at arbejde i denne stil kører?

Den sidste store punkt er at tage din tid på større ændringer, som dette. Opdater din behandling kode for at arbejde med den nye metode, benchmark igen. Eventuelt oprettelse af din behandling server til at køre en virtuel maskine, efter alle dine behandling server vil bare være en anden arbejdstager (bare en meget kraftig en relativt). Tillad den nye proces at afvikle.

Deployment

Mit forslag ville være at pop ind på kontoret en weekend udføre alle de installationer og opsætning. Gør dette lige før en fjorten dages ferie og orlov, så andre fattige chap at håndtere konsekvenserne ... måske ikke ...

Installation af et system som dette skal være langsom. På trods af at det er relativt enkelt at etablere dette system vil påvirke hele din kontor infrastruktur (godt digital på et). For det første udrulning til et par maskiner på et tidspunkt, overvåge netværkstrafik, hvordan arbejderen værter udfører på en dag-til-dag basis. Du skal muligvis ændre dit job konfiguration som svar på Deres resultater.

Når systemet har afgjort med et par maskiner (lad os sige 10% af alle kontormaskiner, dvs 5) fortsat at overvåge trafikken på nettet og værtsmaskinen performance. Næste benchmark igen, du skulle nu være forarbejdning 33% flere jobs end din første benchmarks. Kontrollere dette er tilfældet, eller at du i det mindste i denne ballpark. Hvis ikke, undersøger, hvad der foregår før man går videre. Gentag denne cyklus, indtil du lykkeligt har alle kontor maskiner, der kører uden at dræbe individuel maskinens ydeevne eller slibning dit netværk i stå.

På alle tidspunkter at holde benchmarking, selv efter at alle implementeringer er foretaget. Kontrollere, hvor nye kode opdateringer påvirke hastigheden på dit system, se alle arbejdstagere rapporterer med og forarbejdning job. Langsomt (meget langsomt) stigning dit job konfiguration for at få det bedste ud af dine medarbejdere og netværk.

Stop!

Hvad nu, hvis du ønsker at stoppe dine medarbejdere i at køre på et tidspunkt? De er alle derude kører regenerere, og forsøger deres bedste for at behandle data som sultne insekter. Svaret kan synes indlysende, men dens værd at tilføje just in case sin overset. Blot redigere din behandling script med en exit (0) or die () eller en anden erklæring for at dræbe din behandling job. En vigtig grund til, at vi altid forsøger at opdatere til den nyeste behandling scriptet før løb!

Demonstration System

For at skrive dette sæt af korte artikler jeg har oprettet en meget lille gitter at demonstrere de teknologier og metoder. Jeg har læst masser af artikler, tutorials, og bruges forskellige værktøjer til opsætning og kontrollere, hvad der foregik. På ingen måde har jeg gået ud og mættede en hel kontor med trafik og jeg har heller ikke haft adgang til en regelmæssig ansatte pc for at se, hvordan vært præstation blev påvirket.

Min demonstration systemet var meget ydmyg faktisk. Jeg brugte min normale desktop oprettet som et job kontrol-server. På dette jeg havde installeret mySQL server installeret oprettet som en mester i replikation, PHP Â og SVN er forbundet via apache (for adgang via arbejdstager VM).

Jeg skabte så en CentOS arbejdstager maskine på VirtualBox på en 6 år gammel Windows XP laptop. Jeg setup planlagte opgaver som angivet efter kopiering af VM på maskinen og lad det gå.

Den virtuelle maskine blev oprettet med PHP, undergravende virksomhed, og mySQL. Jeg tjekkede ud en filial kaldet »arbejdstager« fra mit job kontrol servere repository og gjort sikker på det kunne blive opdateret ved hjælp af 'svn update'. Næste Jeg setup mySQL som en slave og kontrolleret, at data var kopiere fra mySQL på jobbet kontrol serveren ned for arbejdstageren VM. Efter alt dette jeg setup bash script og opgaven.

Min behandling script dybest set gik i retning af dette (meget simple ting):

• Læs i navnefeltet
• Tælles antallet af lignende navne i en tabel fra datakilden afholdt på VM
• Tælles antallet af navne som ovenfor, men en opsplitning af navn af mellemrum (dvs. fornavn, midten, efternavn)
• Gentagne denne proces 1.000 gange

Hvert job tog cirka 20 minutter at køre. På et tidspunkt åbnede jeg flere eksemplarer af arbejdstageren VM på vinduerne bærbare computer, og så de arbejdspladser, der skal kontrolleres ud af hver af arbejdstageren IP-adresser. På dette punkt, jeg også bekræftet, at replikationen automatisk genstartes.

Forlader den bærbare computer i tomgang resulterede i en arbejdstager begynder at behandle job fra jobbet kontrol-serveren. Når genoptage laptop brug var der en forsinkelse på ca 30-60 sekunder, dette er en hel del tid og personale skulle gøres opmærksom på, at deres maskine kan holde pause for en kort stund, når tilbage til maskinen. Nyere maskiner kan ikke have en pause på denne lange. Fordelen ved den mængde behandlingen udføres af disse maskiner i tomgang perioder ville mere end opveje ansatte at skulle vente en kort periode (f.eks 1 minut) ankommer til deres maskiner af en formiddag (jeg ofte vente længere, at dette for en Windows Defender opdatering skal finde sted), hvis de blev gjort opmærksom på dette (nyttigt tid til at snuppe en morgenkaffen!).

Samlet Jeg føler tillid til, at jeg har vist de teknologier, der kan bruges til at oprette et sådant system. Jeg har vist, at et sådant system virker på en (meget) lille målestok og med nogle mere eksperimenterende kan skaleres op at udnytte midlerne under en kontorets maskiner. Hvis jeg ikke kommer til det punkt at gøre dette ville jeg være meget interesseret i at vide / se, når nogen andre gør.

Konklusioner / Evaluering

Det næste oplagte skridt ville være at faktisk få en virkelig verden eksempel og begynde at implementere et system som dette i et kontormiljø og se hvad der sker. Bede en virksomhed at forpligte sig til dette uden en sti brændende virksomhed at bevise den teknologi og effektivitet kan være lidt vanskeligt. Grid / Distribueret computing er meget populær er nogle cirkler og har nogle store applikationer (BIONC, SETI @ Home, Folding @ Home, osv). Jeg har dog ikke finde en mindre målestok og enkelt system som dette i mine søgninger, som kunne rulles ud i et kontormiljø.

Jeg oprettede en dybest set gratis system ved hjælp af primært open source-software og-værktøjer der findes i næsten ethvert kontor. De teknologier, var dybest set demonstreret og vise at udføre og arbejde som forventet. Forhåbentlig har jeg vise, at med ikke meget arbejde og med en meget enkel opsætning, du kan installere et kontor grid computing system, der er stærk, billig, Â og skalerbar alle på samme tid.

Når et system er oppe at køre der er næsten ingen ende på mængden af ​​tilpasning og forbedringer, du kan gøre. For eksempel statistikker / benchmarking kan nemt tilføjes viser værdien af ​​et sådant system hver dag. Nye maskiner kan tilføjes hurtigt og nemt, når de ankommer med opgraderinger af eksisterende hardware styrke din processorkraft.

Jeg håber du har nydt at læse denne serie af artikler, og dens givet dig stof til eftertanke om at køre et kontor skinnesystem. Den løsning præsenteres her, vil ikke nødvendigvis arbejde i alle situationer, men skal kunne tilpasses, så du kan få dine data forarbejdning foretaget ved hjælp af din egen løsning.

Du er velkommen til at sende mig nogen kommentarer, rettelser eller forbedringer, og jeg vil gøre mit bedste for at holde denne artikel opdateret til at matche.

Kommentarer (0)

Ved Steven Lloyd Watkin , søndag 11 OKT 2009 06:09

Hvis du for nylig har opgraderet PHP eller Apache du måske kommer op mod udstedelse af din webserver tilbage blanke sider, og kaster fejlmeddelelser i dine logfiler med ingen idé om, hvorfor, her er en mulig måde at løse det ...

Jeg har haft dette problem et par gange for nylig efter opgradering Apache eller PHP på en virtuel maskine. Første gang jeg bemærkede fejlen jeg simpelthen vendt tilbage til en sikkerhedskopi af min VM, men anden gang jeg indså, at jeg ville have til at se nærmere på problemet.

Første gang jeg bemærkede spørgsmålet nogle af mine websider blev serveret som blanke filer, mens de andre arbejdede helt fint. Efter nogle undersøgelser jeg bemærkede, at Apache var ved at skrive ud til / var / log / http / error_ med følgende besked repeatidly:

[Meddelelse] underprocessens XXXX exit signal Segmentation fejl (11)

Der er ikke tild til at gå af on-line, og de fleste af siderne om det spor ud til ingenting. Når det er sagt, jeg indsnævret problemet til PHP bryder sammen, når de forsøger at unødvendige dynamiske biblioteker.

Ser man på min php.ini (/ etc / php.ini) Jeg kommenterede ud alle de dynamiske biblioteker læsset planer om at kommentere dem tilbage i efter behov. De to jeg var nødt til at tage ud af, hvor pdo.so og MySQL . så.

Når disse blev fjernet alle mine websider blev serveret fint, bare som før PHP / Apache opdatering.

Kommentarer (0)

Ved Steven Lloyd Watkin , lørdag 11 juli, 2009 09:48

Som jeg har brugt endnu et par timer i dag uden adgang til internettet Jeg troede, jeg hellere få denne skrevet ned, så næste gang jeg rod min bærbare op Oplysningerne skal være lette at lave.

Dybest set for at få trådløse drivere, der arbejder for en Acer 5002 WLMi du skal bruge B43-fwcutter. Instruktioner kan findes her: Linux Wireless B43 .

Nemt, når oplysningerne er placeret.