Introductie
Ik werk in een bedrijf waar lopen we een groot aantal batch-taken die worden verwerkt miljoenen records van de gegevens elke dag en ik heb onlangs na te denken over alle machines die zitten elke dag niets doen voor meerdere uren. Zou het niet goed zijn als we zouden kunnen gebruiken die machines voor de verwerking kracht van onze systemen te versterken? In deze reeks artikelen ga ik kijken naar de potentiële voordelen van het gebruik van een kantoor rooster met behulp van gevirtualiseerde omgevingen.
In deel 1 heb ik een overzicht van het systeem en technologieën zal ik gebruik maken besproken, evenals enkele van de mogelijke redenen waarom je zou willen naar een kantoor netwerk te creëren.
Job Control
Als je gaat worden uitgevoerd banen dan zul je een manier om ze te beheren nodig hebben. Jouw taak besturingssysteem (op uw werk server) moet echt goed worden doordacht voordat zelfs maar te proberen om een kantoor netwerk draaien. Dus in de eerste plaats, wat zijn de taken voor een job control systeem:
- Hand out banen op verzoek van werknemers
- Vertel werknemers wat voor soort banen uit te voeren
- Track jobs
- Zorg ervoor dat alleen banen worden eenmaal uitgevoerd
- Bieden job data voor de werknemers, of op zijn minst vertellen waar om het te krijgen
Het systeem moet ook uitbreidbaar, een oplossing die nu werkt in een enkel geval kan worden uitgebreid naar verschillende soorten taken uit te voeren als het bedrijfsleven ziet de waarde in een raster oplossing. Bijvoorbeeld, banen kunnen prioriteiten te winnen, meer dan een soort taak kan bestaan (dat wil zeggen meerdere code bases), uiteindelijk kan je zelfs draaien op verschillende machines werknemer die zijn geoptimaliseerd voor elk type van werk (hoewel dat niet af te stappen van de 'generieke werknemer 'idee). Probeer altijd na te denken over de toekomst bij het ontwikkelen van systemen, kan een korte termijn visie leiden tot een langere termijn frustratie en uitbreiding van de ontwikkelingshulp tijd.
Job Server
We gaan ergens nodig hebben om onze banen controle van, dient dit te worden het enige systeem in uw netwerk, dat een vaste Resource Locator is, zijn dat een IP-adres, hostnaam, URL (met behulp van interne DNS), enz. Dit komt omdat de werknemers moeten weten waar hij moet zoeken naar een baan, werknemers moeten om de klus te controlesysteem (niet de taak besturingssysteem vindt de werknemers) te vinden.
De baan server zelf niet echt een ingewikkelde taak hebben (in een basissysteem ieder geval), moet het een lijst van taken op te slaan, met de hand uit banen, resultaten te ontvangen, en vervolgens op te slaan voor later gebruik. Hoe deze onderdelen (zoals de 'hand out jobs') worden gedefinieerd kunnen erg basic. Later kunnen we het systeem uitbreiden tot een administratie-interface toe te voegen, te bewerken, te verwijderen, te schorsen banen, maar dat wordt niet deze oefening nemen.
Er is geen enkele reden dan dat het je baan server niet kon worden een virtuele machine draaien binnen uw belangrijkste verwerkende server voorwaarde dat het niet te veel middelen afvoer van. De job-server heeft echter nodig een hoge beschikbaarheid, als het gaat neer op een vrijdag avond ga je een heel weekend van de verwerking te verliezen, mogelijk kost je een paar weken ter waarde van de verwerking van de tijd (in vergelijking met uw belangrijkste verwerking server alleen) . Wilt u misschien overwegen om uw werk-server op een load balanced omgeving voor hoge beschikbaarheid.
Basic Setup
De basis set-up voor onze job server zal bestaan uit wat ik bellen naar een van mijn slappe servers (dat is Li nux, m ySql, P HP). De code draait op thea werknemers ook daadwerkelijk uit te werken welke taken het kan draaien door interactie met de job besturingssysteem databases. Later konden we creëren een web service en eigenlijk uitdelen banen in plaats van de arbeiders doen het harde werk zelf, maar voor nu zullen we blijven maken van de KISS-principe (Keep It Simple, Stupid!).
Dus, laat creëren drie mySQL tafels om te gaan met banen. Deze worden `baan`, `jobRecords` en `jobResults`.
Hier ben ik met behulp van SQL Buddy een grote kleine alternatief voor phpMyAdmin , alleen maar omdat het makkelijker te installeren op CentOS (voor anderen te zien: 10 Great alternatieven voor phpMyAdmin )
Deze tabel bestaat uit 5 eenvoudige velden,
- id: een unieke identificatie van de baan
- naam: Kan een klant referentie, of een aantal andere identificatiegegevens worden
- Status: Je moet weten waar de baan is, bv
- 0: Niet gestart
- 1: opgepikt
- 2: Voltooid
- started_by: Wie is er begonnen met het doen van de baan? Dit is niet helemaal nodig, maar is een mooie aanvulling zijn. Ik stel voor het bijhouden van werknemers door hun IP-adres op je netwerk
- started_at: Wanneer heeft de werknemer start van de baan? Door het bijhouden van taken die nog niet zijn afgerond binnen X tijd weten we dat we nodig hebben op te halen de baan opnieuw te beginnen en de verwerking door een andere werknemer. Werknemers zouden stoppen met het verwerken / offline gaan voor een aantal redenen, stroomuitval, crash, netwerk verlies, etc.
Het is gemakkelijk hoe deze tafel zou kunnen worden uitgebreid met een paar extra velden om te zorgen voor de statistieken tracking, een eindtijd kolom om te zien hoe lang de baan nam, een teller om te zien hoeveel werknemers pakte de baan (uiteraard moet dit hebben de neiging om 1), job prioriteit, kan de lijst gaan en op. In meer complexe klus scenario's zou het mogelijk zijn om aan te geven hoeveel geheugen de werknemer zou de toegang tot (en dus gebruik alleen geschikte werknemers), of zelfs wat voor soort werknemer nodig zou zijn nodig.
Laten we nog een paar voorbeeld vacatures:
De volgende tabel weer is vrij eenvoudig te begrijpen, dit zijn onze job records. Ze zijn gekoppeld aan de belangrijkste taken tafel door een kolom `jobs_id`. De make-up van deze tabel is sterk afhankelijk van de gegevens die je nodig hebt om te leveren aan uw medewerkers, laat een zeer simpel voorbeeld, waar we vier kolommen:
- id: ID van het record
- Naam: Persoon naam
- adres: Persoon adres van
- jobs_id: De functie ID dat dit record is gekoppeld aan
De derde en laatste tabel bestaat uit een tabel met resultaten, het heeft ongeveer dezelfde make-up als onze administratie tafel, en met de toevoeging van een aantal kolommen kan deel uitmaken van de records tabel:
- job_record_id: Link het resultaat aan de job tafel
- resultaat: Het resultaat gegevens
... En dat is alles wat je nodig hebt voor het scheppen van controle! (Zij het op een zeer elementair niveau) In mijn geval ben ik wees naar een andere tafel waar mijn gegevens te verwerken was gevestigd, maar dit kan net zo goed een bestand, parameters om simulatie code uit te voeren, noem maar op.
Het selecteren van een job
Zoals eerder vermeld, de arbeiders zullen ons werk het beheer doen voor ons nu, dus alles wat we nodig hebben om echt te doen is het vinden van een baan dat verwerking nodig heeft en krijgt de informatie. Hoe zouden we dit doen? Nou pick onze job selectiecriteria en op zoek naar banen, in SQL ik het volgende gedaan:
- Neem een willekeurige opdrachten die niet zijn gemarkeerd als compleet, maar van onze werknemer en opnieuw instellen (vervang __ME__ met een identifier, gemakkelijkste zou IP-adres):
UPDATE `banen` SET `de status van` = 0 WHERE `de status van` = 1 EN `started_by` = __ME__;
- Met behulp van onze job selectiecriteria, selecteert u een baan en vertellen het controlesysteem dat deze werknemer zich bezig met het:
UPDATE `banen` SET `de status van` = 1, `started_by` = __ME__, `started_at` = NOW () WHERE `de status van` = 0 of
(`De status van` = 1 EN `started_at`> DATE_SUB (NOW (), INTERVAL X HOUR)) ORDER BY `id` ASC;
Door grijpen taken die niet tot resultaten hebben geleid teruggekeerd in X hoeveelheid tijd zorgen we ervoor dat alle opdrachten worden uitgevoerd in het geval van een werknemer crashen of gaan AWOL.
- Naast grijp de banen details, gevolgd door de documenten zelf:
SELECT * FROM `banen` WHERE `started_by` = __ME__ LIMIT 1;
SELECT * FROM `job_records` WHERE `id` = __JOBID__;
Na voltooiing van het werk dat wij voegen ons resultaat records en markeer de taak als voltooid. Herinneren als taken kunnen suspend / resume te allen tijde zorgen voor een aantal robuustheid in uw script. Het kan zijn dat de taak half weg opschort door het updaten van de job control systeem, dus het controleren van het aantal records in een baan en het aantal resultaten opgeslagen in de job control systeem zou een verstandige beslissing is.
Daarnaast, terwijl dit laat zien hoe taken kunnen worden geselecteerd en beheerd vanuit een SQL-query frame dat u moet echt worden abstraheren je baan controle, zodat als je besluit over te stappen naar het gebruik van een web service, een file based systeem, XML , of enige andere aantal systemen zal het geen invloed op de code boven.
Job Configuratie
Het volgende aspect dat aandacht verdient is het werk grootte en de configuratie. Door te spelen met werk configuratie kunnen we slaan een uitstekende balans tussen snelheid, proces-replicatie, en betrouwbaarheid. Neem een paar ofa scenario's:
- Jobs neemt een dag per uit te voeren: dit betekent dat uw werknemers moeten 15 dagen om elke taak te verwerken (denk aan 10% van het vermogen voor 2/3e van de tijd). Dit is niet duidelijk een wijs configuratie, je werk maat is veel te groot! Het zou op zijn minst het dubbele van de tijd verwerkte een baan te krijgen moet de eerste werknemer gaan AWOL (tijd op te halen dat het niet een plus opwerking tijd terug). In een ideale zou je op zijn minst een volledige baan gemakkelijk goedgekeurd door het einde van elke lange periode van inactiviteit, op die manier je de banen draaiende en in het ergste geval een baan te behouden zou twee dagen duren proces moet de eerste gaan ontbreekt.
- Jobs neemt een minuut te lopen: Dit betekent dat uw werknemers ongeveer 15 minuten te nemen om elke taak uit te voeren. Hoewel dit aanvankelijk ideaal lijkt, moet u extra werkzaamheden verwerken krijgen tijdens de lunch, koffiepauzes, vergaderingen, enz. dit scenario zet druk op andere gebieden van uw systeem en introduceert zijn eigen problemen. Bijvoorbeeld eerst je setup / verwerkingstijd verhouding gaat recht naar beneden te gaan, dus het verliezen van het systeem efficiëntie. Uw netwerk zal worden voortdurend streaming taak informatie aan de verschillende werknemers frustrerend medewerkers die dong hun dagelijkse werk. Je bent ook gaan om meer druk op je werk de verwerking van de server als het moet schotel uit heel veel kleine stukjes van het werk op een regelmatige basis. Ten slotte is in deze situatie als de taak server down gaat ga je een enorme achterstand van het onvoltooide werk dat de grotere banen te creëren kon de aanhoudende verwerking zalig niet van bewust dat de klus server problemen ervaren.
In werkelijkheid zal er geen een ideale configuratie voor uw netwerk setup, veel hangt af van de beschikbare middelen, soorten werk, job doorlooptijd vereisten, netwerk mogelijkheden, en zo verder. Maar een aantal richtlijnen zou zijn:
- Grootte opdrachten zo, dat elke werknemer kan krijgen door minimaal 3-4 banen in een periode van 15 uur (de langste waarschijnlijk idle time periode)
- Speel met de opdracht grootte zodat setup-tijd wordt relatief onbelangrijk vergeleken met de verwerkingstijd (rekening houdend met het vorige punt).
- Als een opdracht niet volledig in het dubbele van de hoeveelheid tijd (misschien minder) je verwachten dat het voltooien ervan uitgaan dat haar verdwenen AWOL en begint de verwerking van het met een andere werknemer. Dit betekent dat u moet wachten tot drie keer de normale lengte van een baan voor het in te vullen (eventueel langer indien de latere job mislukt). U kunt deze tijd te verminderen, maar wees voorzichtig niet te verminderen te veel als je kan beginnen dupliceren de verwerking van taken op een regelmatige basis te zijn.
- Jobs moet onafhankelijk zijn van externe eisen zo veel mogelijk. De baan server, bijvoorbeeld, mogen alleen worden gecontacteerd aan het begin en einde van elke baan.
- Niet verzadigen uw netwerk, dit zal twee negatieve gevolgen zal hebben, zal je overdag personeel te vinden met behulp van het netwerk frustrerend en problemen kunnen worden ervaren met aansluitingen time-out een probleem dat alleen maar erger wordt als je schaal van je raster.
- Zorg ervoor dat taken kunnen uitvoeren op uw werknemers. Als taken worden te geheugen intensieve of schijfruimte intensieve taken start afbreken en het enige wat je zal opvallen is een daling in het aantal banen verwerkt met geen echte reden waarom.
Overleggen van de resultaten van een baan
Bij het indienen van de resultaten van een baan is het belangrijk om te controleren of geen resultaten zijn ingediend door een andere werknemer, zeker als de huidige werknemer slapende al enige tijd.
Wanneer de resultaten worden ingediend ervoor te zorgen dat het aantal resultaten van het aantal records wedstrijden binnen de baan.
Zoals gezegd eerder, en kan niet genoeg worden benadrukt, bouwen fout-tolerantie in de printopdrachten en resultaten onderwerping. De werknemers kunnen (en waarschijnlijk zullen) gaan in de stand-bymodus op de meest ongelegen tijden en dit moet worden gehouden. Ook weer weg te abstraheren uw resultaten inzending zal helpen het oog op toekomstige wijzigingen in uw job control systeem veel eenvoudiger te behandelen.
Overzicht
In deze section hebben we gekeken naar wat een baan control server moet doen en hoe je een zeer fundamentele systeem opgezet. We hebben besproken hoe een baan van het besturingssysteem en de beste manier om banen te configureren om het behouden van uw kantoor grid-systeem te krijgen op te halen. Om af te sluiten, was een paragraaf of twee aan overleggen van de resultaten terug naar de job control server gepresenteerd.
- Een job control-server beheert banen en zorgt ervoor dat al het werk units zijn afgerond
- Door te abstraheren van uw taak te selecteren / resultaten indiening kunnen we de technologie van de controle-server zonder veel problemen
- Stel uw taken om ervoor te zorgen dat ze snel en efficiënt te kunnen werken, zonder te veel druk op uw netwerk infrastructuur, en zonder doublures de verwerking van taken op een regelmatige basis.
- Zorg ervoor dat u fout-tolerantie-and-error checking in uw routines op te bouwen, kunnen werknemers onderbreken en hervatten en de meest ongelegen tijden. Vergeet niet om te controleren of de resultaten zijn reeds ingediend door een andere werknemer.
Volgende keer
In deel 3 gaan we creëren onze virtuele machine en het opzetten van onze Windows-machines te worden idle-time werknemers.
Reacties (2) 
Door elk van uw werknemers als een slaaf van de job control server updates voor uw gegevensbronnen zal mooi trickle down om uw werknemers zonder een enorme toename in netwerk-activiteit (dat wil zeggen, tenzij u een enorme data-update en al je medewerkers kick in in een keer). Dit heeft voordelen ten opzichte van rsync in dat u niet een lange pauze voor elke job, gelijk als de database-updates, de mysql daemon op uw werknemer zal voortdurend geactualiseerd zijn gegevens tijdens de verwerking doorgaat. 
