Einführung
Ich arbeite in einer Firma, wo wir viele Batch-Jobs Verarbeitung von Millionen von Datensätzen von Daten jeden Tag und ich habe in letzter Zeit über alle Maschinen, die sich um jeden und jeden Tag sitzen Nichtstun für mehrere Stunden laufen. Wäre es nicht gut, wenn wir diese Maschinen benutzen könnte, um die Rechenleistung unserer Systeme zu stärken? In dieser Reihe von Artikeln werde ich auf die potenziellen Vorteile der Beschäftigung ein Büro aussehen Gitter mit virtualisierte Umgebungen.
In Teil 1 Ich gab einen Überblick über das System und Technologien I verwenden werden sowie einige der möglichen Gründe diskutiert, warum Sie wollen würde, ein Büro Raster zu erstellen.
Job Control
Wenn Sie vorhaben, werden laufende Aufträge sind dann wirst du einen Weg, sie zu verwalten müssen. Ihre Job-Control-System (auf dem Job-Server) muss wirklich gut durchdacht sein, bevor auch nur zu versuchen, ein Büro Grid laufen. Also erstens, was sind die Aufgaben für eine Job-Control-System:
- Auszuteilen Arbeitsplätze auf Anfrage von Arbeitern
- Sag Arbeiter Welche Arten von Job zu laufen
- Track-Arbeitsplätze
- Sicherstellen, dass die Aufträge erst dann zu laufen, wenn
- Provide job data to workers, or at least tell them where to get it
The system also needs to be extensible, a solution that works for now in a single case may be extended to run several types of jobs as the business sees the worth in a grid solution. For example, jobs may gain priorities, more than one job type may exist (ie several code bases), eventually you may even run several different worker machines that are optimised for each type of job (although that does move away from the 'generic worker' idea). Always try to think about the future when developing systems, a short term vision can lead to longer term frustration and increased development time.
Job Server
We're going to need somewhere to control our jobs from, this should be the only system in your grid that has a fixed resource locator, be that an IP address, host name, URL (using internal DNS), etc. This is because the workers need to know where to look for jobs, workers need to find the job control system (not the job control system find the workers).
The job server itself doesn't really have a complicated task (in a basic system anyhow), it needs to store a list of jobs, hand out jobs, receive results, and subsequently store them for later retrieval. How these parts (such as 'hand out jobs') are defined can be very basic. Later on we can extend the system to include an administration interface to add, edit, delete, suspend jobs but this is beyond this exercise.
There is no reason whatsoever then that your job server could not be a virtual machine running within your main processing server provided it doesn't drain too many resources from it. The job server however does need high availability, if it goes down on a Friday evening you're going to lose a whole weekend of processing, potentially costing you a couple of weeks worth of processing time (when compared to your main processing server alone). You may want to consider putting your job server on a load balanced environment for high availability.
Basic Setup
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:
Die nächste Tabelle wieder ist recht einfach zu verstehen, das sind unsere Job Datensätze. Sie werden dem Haupt-Arbeitsplätze Tabelle nach einer Spalte `jobs_id` verknüpft. Das Make up von dieser Tabelle hängt sehr stark von den Daten, die Sie benötigen, um Ihre Mitarbeiter zu versorgen, lets make ein sehr einfaches Beispiel, wo wir vier Säulen:
- ID: ID des Datensatzes
- Name: Name der Person
- Adresse: Person die Adresse
- jobs_id: Die Job-ID, dass dieser Datensatz verknüpft ist
Die dritte und letzte Tabelle besteht aus einer Ergebnistabelle, hat es viel anders machen als unsere Aufzeichnungen Tisch, und mit der Zugabe von einigen Spalten könnte ein Teil der Aufzeichnungen Tisch sein:
- job_record_id: Verknüpfen Sie das Ergebnis in den Job-Tabelle
- Ergebnis: Die Ergebnisdaten
... Und das ist alles, was Sie für Job-Kontrolle! (Wenn auch auf einer sehr grundlegenden Ebene) In meinem Fall bin ich an einen anderen Tisch, wo meine Daten zu verarbeiten befinden sollte, aber das könnte genauso gut eine Datei, Parameter zur Simulation Code ausführen, you name it.
Die Auswahl einer Job
Wie bereits erwähnt, werden die Arbeiter unserer Job-Management für uns tun im Moment, so dass alles was wir brauchen, um wirklich zu tun ist, einen Job zu finden, die Verarbeitung benötigt und die Informationen bekommen. Wie würden wir das tun? Nun nehmen unseren Job Auswahlkriterien und suchen nach Jobs, die in SQL Ich habe die folgenden:
- Nehmen Sie alle Jobs, die nicht so vollständig, aber aus unserer Arbeiter sind markiert und zurückgesetzt werden sie (ersetzen __ ME__ mit einer Kennung, am einfachsten wäre IP-Adresse sein):
UPDATE `Arbeitsplätze` SET `Status` = 0 WHERE `Status` = 1 AND `started_by` = __ ME__;
- Mit unserem Job Auswahlkriterien, wählen Sie einen Job und sagen, die Steuerung, dass diese Arbeiter der es beschäftigt:
UPDATE `Arbeitsplätze` SET `Status` = 1, `` = __ started_by ME__, `started_at` = NOW () WHERE `Status` = 0 ODER
(`Status` = 1 AND `started_at`> DATE_SUB (NOW (), INTERVAL x Stunde)) ORDER BY `id` ASC;
Durch Greifen Jobs, die nicht Ergebnisse wurden in X Höhe der Zeit stellen wir sicher, dass alle Arbeitsplätze im Fall eines Arbeitnehmers, Abstürzen oder er unerlaubt geführt werden zurückgegeben.
- Als nächstes hol dir die Jobs Details von den Platten selbst befolgt:
SELECT * FROM `Arbeitsplätze` WHERE `started_by` = __ ME__ LIMIT 1;
SELECT * FROM `job_records` WHERE `id` = __ JOBID__;
Nach Abschluss der Arbeit setzen wir unser Ergebnis Aufzeichnungen und markieren Sie die Aufgabe als abgeschlossen. Denken Sie daran, wie Arbeitsplätze können Suspend / jederzeit wieder aufnehmen können seit einiger Robustheit in Ihrem Skript. Es könnte sein, dass die Aufgabe, auf halbem Weg unterbricht durch die Aktualisierung der Job-Control-System, so dass die Überprüfung der Anzahl der Datensätze in einem Job und die Anzahl der Ergebnisse zurück an den Job-Control-System gespeichert wäre eine weise Entscheidung.
Darüber hinaus, während dies zeigt, wie Arbeitsplätze ausgewählt und können aus einer SQL-Abfrage-Rahmen wirklich werden sollte verwaltet werden abstrahiert Ihren Job-Kontrolle, so dass, wenn Sie sich entschließen, die Verwendung eines Web-Service, eine Datei-basierte System, schalten XML , oder jede andere Anzahl von Systemen wird es keine Auswirkungen auf die obigen Code es.
Job-Konfiguration
Der nächste Aspekt ist Job Größe und Konfiguration. Durch das Spiel mit Job-Konfiguration können wir schlagen eine exzellente Balance zwischen Geschwindigkeit, Prozess-Replikation, und Zuverlässigkeit. Nehmen Sie sich ein paar ofa Szenarien:
- Jobs dauern jeweils 1 Tag zu laufen: Das bedeutet, dass Ihre Arbeiter 15 Tage brauchen, um jeden Auftrag zu bearbeiten (Sie erinnern sich 10% der Energie für 2/3rds der Zeit). Dies ist eindeutig nicht eine kluge Konfiguration ist es Ihre Aufgabe Größe viel zu groß! Es würde mindestens die doppelte Zeit, um ein Job verarbeitet die ersten Arbeiter gehen sollte AWOL (Zeit zu holen, dass es nicht ein Ergebnis zuzüglich Wiederaufarbeitung rechtzeitig zurückgegeben). In einer idealen man müsste mindestens eine volle Stelle leicht mit dem Ende eines jeden langen Ruhezeit geräumt, so erhalten Sie die Jobs über Ticken halten und im schlimmsten Fall ein Job würde zwei Tage dauern, bis der erste Prozess gehen sollte fehlen.
- Jobs nehmen 1 Minute zu laufen: Das bedeutet, dass Ihre Mitarbeiter etwa 15 Minuten dauern, jeden Auftrag ausführen. Dies mag zunächst scheinen ideal, gewinnen Sie zusätzliche Arbeit Verarbeitung während der Mittagspause, Kaffeepausen, Sitzungen usw. Dieses Szenario belastet die andere Bereiche Ihres Systems und stellt seine eigenen Probleme. Zum Beispiel, zunächst das Setup / Bearbeitungszeit Verhältnis wird sich bis hinunter zu gehen, daher verlieren Effizienz des Systems. Ihr Netzwerk wird ständig Streaming Job-Informationen zu den verschiedenen Arbeitern frustrierend Mitarbeiter, dong sind ihrer täglichen Arbeit sein. Sie werden auch mehr Belastung für das Job-Verarbeitung-Server setzen, wie sie austeilen viele, viele kleine Stücke von der Arbeit auf einer regelmäßigen Basis hat. Schließlich ist in dieser Situation, wenn Ihr Job Server ausfällt wirst du eine riesige zurück Protokoll nicht abgeschlossener Arbeiten während größere Aufträge von der Verarbeitung fortgesetzt könnte völlig ahnungslos, dass der Job Server war mit Schwierigkeiten zu schaffen.
In der Realität wird es niemand ideale Konfiguration für Ihren Netz-Setup sein, viel hängt von den verfügbaren Ressourcen, Arten von Job, Job-Turnaround-Zeit Anforderungen, Netzwerkfähigkeit, und so weiter. Doch einige Richtlinien wäre:
- Größe Arbeitsplätze, so dass jeder Arbeiter kann durch mindestens 3-4 Arbeitsplätze in einem Zeitraum von 15 Stunden (wahrscheinlich die längste Zeit im Leerlauf) bekommen
- Spielen Sie mit der Größe des Auftrags, so dass Setup-Zeit wird ziemlich unbedeutend im Vergleich zu der Verarbeitungszeit (unter Berücksichtigung der obigen Punkt).
- Wenn ein Job nicht in doppelter Höhe der Zeit (vielleicht auch weniger), die Sie erwarten, dass es komplett abgeschlossen ist anzunehmen, dass seine gegangen AWOL und Verarbeiten es mit einem anderen Arbeiter zu beginnen. Das heißt, Sie können warten müssen, bis zu drei Mal die normale Länge von einem Job für ihn zu vollenden (möglicherweise länger, wenn die nachfolgende Auftrag fehlschlägt). Vielleicht möchten Sie diese Zeit zu reduzieren, aber darauf achten, nicht zu viel, wie Sie vielleicht beginnen Duplizieren Bearbeitungsaufgaben auf einer regelmäßigen Basis zu reduzieren.
- 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.
Zusammenfassung
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.
Nächstes Mal
In part 3 we'll create our virtual processing machine and set up our windows machines to become idle-time workers.
Kommentare (6) 
PHP , Web-Programmierung , Zend Framework | 
hinzuzufügen , Bootstrap , Container , dynamisch , Navigation , Seiten , PHP- , Unter-Seite , Ansicht , Zend , Zend Framework , Zend_Navigation 
