Einführung
Ich arbeite in einer Firma, wo wir laufen viele Batch-Jobs Verarbeitung von Millionen von Datensätzen der Daten jeden Tag und ich habe vor kurzem Nachdenken über all die Maschinen, um jeden zu sitzen und jeden Tag nichts zu tun für mehrere Stunden. Wäre es nicht gut, wenn wir diese Maschinen benutzen konnte, um die Rechenleistung der Systeme zu stärken? In dieser Reihe von Artikeln werde ich auf die potenziellen Vorteile der Verwendung eines Büro-Look Gitter mit virtualisierten Umgebungen.
In Teil 1 habe ich einen Überblick über das System und Technologien I benutzen werden, sowie einige der möglichen Gründe, warum Sie ein Büro Raster zu erstellen würden diskutiert.
Job Control
Wenn Sie vorhaben, werden laufende Aufträge sind dann wirst du einen Weg, sie zu verwalten müssen. Ihr Job-Steuerung (auf der 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:
- Hand von Jobs auf Anfrage von Arbeitern
- Sag Arbeiter, welche Art von Jobs, die
- Ihre Arbeitsplätze
- Stellen Sie sicher, dass die Arbeitsplätze nur einmal ausgeführt
- Geben Sie Job-Daten für die Arbeitnehmer, oder zumindest sagen, wo man es bekommt
Das System muss auch erweiterbar, eine Lösung, die für die nun in einem einzigen Fall kann verlängert werden, verschiedene Arten von Jobs ausgeführt wie das Unternehmen sieht den Wert in einer Grid-Lösung sein. Zum Beispiel, Arbeitsplätze können Prioritäten zu gewinnen, mehr als ein Job-Typ bestehen können (dh mehrere Code-Basen), schließlich kann man sogar laufen verschiedene Arbeiter Maschinen, die für jede Art von Arbeit optimiert werden (auch wenn das bedeutet Abkehr von der "generic Arbeiter 'Idee). Versuchen Sie immer an die Zukunft denken bei der Entwicklung von Systemen kann eine kurzfristige Vision, langfristig Frust und erhöht die Entwicklungszeit führen.
Job Server
Wir werden irgendwo müssen unsere Job-Kontrolle aus, sollte dies das einzige System in Ihrem Netz, die eine feste Resource Locator hat sein werden, dass eine IP-Adresse, Hostname, URL (mit internen DNS), etc. Dies ist, weil die Arbeiter müssen wissen, wo nach Jobs suchen, müssen Arbeitnehmer vor der Job-Steuerung (nicht den Job-Steuerung finden die Arbeiter) zu finden.
Der Job Server selbst hat nicht wirklich eine komplizierte Aufgabe (in ein Basis-System sowieso), muss es eine Liste von Jobs zu speichern, hand out Arbeitsplätze erhalten Ergebnisse und anschließend speichern Sie diese für den späteren Abruf. Wie diese Teile (wie "Hand Job ') definiert werden kann, sehr einfach. Später können wir das System erweitern, um eine Administrationsoberfläche hinzufügen, bearbeiten, löschen, auszusetzen Arbeitsplätze, aber das ist jenseits dieser Übung sind.
Es gibt keinen Grund, dann, dass Ihr Job Server konnte nicht einer virtuellen Maschine läuft innerhalb Ihres Processing Server werden, sofern sie nicht drain zu viele Ressourcen von ihm. Der Job-Server jedoch braucht eine hohe Verfügbarkeit, wenn es runter geht an einem Freitag Abend wirst du ein ganzes Wochenende der Verarbeitung zu verlieren, möglicherweise kostet Sie ein paar Wochen im Wert von Verarbeitungszeit (wann Sie Ihre wichtigsten Processing Server im Vergleich zur alleinigen) . Vielleicht möchten Sie in Erwägung ziehen, Ihren Job Server auf einem load balanced Umfeld für hohe Verfügbarkeit.
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:
The next table again is quite simple to understand, these are our job records. They are linked to the main jobs table by a column `jobs_id`. The make up of this table very much depends on the data that you need to supply to your workers, lets make a very simple example where we have four columns:
- id: ID of the record
- name: Person's name
- address: Person's address
- jobs_id: The job ID that this record is linked to
The third and final table consists of a results table, it has much the same make up as our records table, and with the addition of some columns could be part of the records table:
- job_record_id: Link the result to the job table
- result: The result data
…and that's all you need for job control! (albeit at a very basic level) In my case I'm pointed to another table where my data to process was located, but this could just as easily been a file, parameters to run simulation code, you name it.
Selecting a job
As stated previously, the workers will do our job management for us for now, so all we need to really do is find a job that needs processing and get the information. How would we do this? Well pick our job selection criteria and look for jobs, in SQL I did the following:
- Take any jobs that are not marked as complete but from our worker and reset them (substitute __ME__ with an identifier, easiest would be IP address):
UPDATE `jobs` SET `status` = 0 WHERE `status` = 1 AND `started_by` = __ME__;
- Using our job selection criteria, select a job and tell the control system that this worker is dealing with it:
UPDATE `jobs` SET `status` = 1, `started_by` = __ME__, `started_at` = NOW() WHERE `status` = 0 OR
(`status` = 1 AND `started_at` > DATE_SUB(NOW(), INTERVAL X HOUR)) ORDER BY `id` ASC;
By grabbing jobs that haven't returned results in X amount of time we ensure that all jobs are run in the event of a worker crashing or going AWOL.
- Next grab the jobs details followed by the records themselves:
SELECT * FROM `jobs` WHERE `started_by` = __ME__ LIMIT 1;
SELECT * FROM `job_records` WHERE `id` = __JOBID__;
Upon completion of the job we insert our result records and mark the job as complete. Remember as jobs can suspend/resume at any time allow for some robustness in your script. It might be that the task suspends half way through updating the job control system, so checking the number of records in a job and the number of results saved back to the job control system would be a wise move.
In addition, whilst this demonstrates how jobs can be selected and managed from an SQL-query frame you should really be abstracting your job control so that if you decide to switch to using a web service, a file based system, XML , or any other number of systems it will not affect the code above it.
Job Configuration
The next aspect to consider is job size and configuration. By playing with job configuration we can strike an excellent balance between speed, process replication, and reliability. Take a couple of scenarios:
- Jobs take 1 day each to run: This means that your workers need 15 days to process each job (remember 10% of the power for 2/3rds of the time). This is clearly not a wise configuration, your job size is way too big! It would take at least double the time to get a job processed should the initial worker go AWOL (time to pick up that it hasn't returned a result plus reprocessing time). In an ideal you'd have at least one full job easily cleared by the end of each long idle period, that way you keep the jobs ticking over and at worst case a job would take two days to process should the first go missing.
- Jobs take 1 minute to run: This means that your workers take about 15 minutes to run each job. Whilst this may initially seem ideal, you gain additional work processing during lunch time, coffee breaks, meetings, etc this scenario puts strain on other areas of your system and introduces its own problems. For example, firstly your setup/processing time ratio is going to go right down, therefore losing system efficiency. Your network is going to be constantly streaming job information to the various workers frustrating staff who are dong their day to day work. You're also going to put more strain on your job processing server as it has to dish out lots and lots of small pieces of work on a regular basis. Lastly, in this situation if your job server goes down you're going to create a huge back log of uncompleted work whereas bigger jobs could of continued processing blissfully unaware that the job server was experiencing difficulties.
In der Realität wird es niemand ideale Konfiguration für Ihr Netz eingerichtet werden, hängt stark von der verfügbaren Ressourcen, Arten von Arbeit, Job Bearbeitungszeit Anforderungen, Netzwerkfähigkeit, und so weiter. Doch einige Richtlinien wäre:
- Größe Arbeitsplätze, so dass jeder Arbeitnehmer über mindestens 3-4 Arbeitsplätze in einem Zeitraum von 15 Stunden (die längste wahrscheinlich idle Zeit) bekommen
- Spielen Sie mit dem Job-Größe, so dass Rüstzeiten wird ziemlich unbedeutend im Vergleich zu der Verarbeitungszeit (unter Berücksichtigung der oben genannten Punkt).
- Wenn ein Job nicht in die doppelte Menge an Zeit (vielleicht sogar weniger), die Sie erwarten, dass es komplett abgeschlossen ist anzunehmen, dass es weg ist AWOL und Verarbeitung mit einem anderen Arbeiter zu beginnen. Das heißt, Sie können warten, bis das Dreifache der normalen Länge der einen Job für ihn in Anspruch (möglicherweise mehr, wenn die nachfolgende Auftrag fehlschlägt). Vielleicht möchten Sie diese Zeit zu reduzieren, aber darauf achten, nicht zu viel, wie Sie vielleicht anfangen zu duplizieren Bearbeitungsaufgaben in regelmäßigen Abständen zu reduzieren.
- Jobs sollten unabhängig von außerhalb Anforderungen so weit wie möglich. Der Job-Server, zum Beispiel sollte nur am Anfang und Ende jedes Auftrags kontaktiert werden.
- Nicht zu sättigen Ihr Netzwerk, das wird zwei negative Effekte haben, werden Sie tagsüber Personal zu finden über das Netzwerk frustrierend und Probleme können mit Verbindungen Zeitüberschreitung ein Problem, das nur bekommen schlimmer, wie Sie Ihren Rasterskala erlebt werden.
- Stellen Sie sicher, Arbeitsplätze können auf Ihre Mitarbeiter führen. Wenn Arbeitsplätze zu Erinnerung werden intensive oder Speicherplatz intensive Beschäftigung startet Abbruch und das einzige, was werden Sie feststellen, ist ein Tropfen an der Zahl der Arbeitsplätze mit keinen wirklichen Grund, warum verarbeitet.
Einreichen Ergebnisse einer Job
Bei der Abgabe der Ergebnisse einer Aufgabe es ist wichtig zu überprüfen, dass die Ergebnisse nicht von einem anderen Arbeiter eingereicht worden, vor allem, wenn die aktuelle Arbeitnehmer hat seit einiger Zeit inaktiv.
Wenn die Ergebnisse vorgelegt werden sicherstellen, dass die Anzahl der Ergebnisse die Anzahl der Datensätze entspricht im Job.
Wie bereits erwähnt, und kann nicht genug betont, bauen Fehlertoleranz in Wiederfinden und Ergebnisse Unterwerfung. Die Arbeiter können (und wahrscheinlich wird) in den Suspend-Modus zu den ungünstigsten Zeiten und dies muss Rücksicht genommen werden. Auch noch einmal abstrahiert weg Ihre Ergebnisse Vorlage wird dazu beitragen, sorgen für zukünftige Änderungen an Ihrem Job Control System viel einfacher zu handhaben.
Zusammenfassung
In diesem Schnitt A haben wir, was eine Job-Control-Server muss nicht sah und, wie man ein sehr einfaches System einzurichten. Wir diskutierten, wie man einen Auftrag aus der Steuerung und wie man am besten, um Arbeitsplätze zu konfigurieren, dass die meisten unserer Ihres Büros Grid-System erhalten abzurufen. Zum Abschluss wurde ein oder zwei Absätze zur Einreichung Ergebnisse zurück an die Job-Kontrolle-Server vorgestellt.
- 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 | 
hinzufügen , bootstrap , Container , dynamisch , Navigation , Seiten , PHP , sub-Seite , Ansicht , zend , Zend Framework , Zend_Navigation 
