Введение
Я работаю в компании, где мы запускаем много рабочих мест, пакетную обработку миллионов записей данных каждый день, и я думал в последнее время о всех машинах, которые сидят каждый день ничего не делать в течение нескольких часов. Не было бы хорошо, если мы могли бы использовать эти машины для укрепления вычислительной мощности наших систем? В этой серии статей я буду смотреть на потенциальные выгоды от использования офиса сетки использованием виртуализованных средах.
В части 1 я дал обзор системы и технологии, я буду использовать, а также обсудили некоторые из возможных причин, почему вы хотите создать офис сети.
Управление заданиями
Если вы собираетесь быть запущена работа, то вы будете нуждаться в какой-то мере управлять ими. Ваша задача системы управления (на работу сервера) должен быть очень хорошо продумана еще до попытки запуска офиса сетки. Итак, во-первых, какие задачи для системы управления заданиями:
- Раздайте работу по просьбе рабочих
- Скажите рабочим, какой тип запуска заданий
- Трек рабочих мест
- Убедитесь, что задания выполняются только один раз
- Обеспечить работу данных работников, или по крайней мере, сказать им, где его получить
Кроме того, система должна быть расширяемой, решение, которое работает сейчас в одном случае может быть продлен до запуска нескольких видов работ, как бизнес видит себя в сетке решение. Например, работа может получить приоритеты, более чем одного типа задания может существовать (то есть несколько баз кода), в конце концов вы даже можете запускать несколько разных машин работника, которые оптимизированы для каждого вида работы (хотя это никак отойти от "общего работника "Идея). Всегда стараюсь думать о будущем, при разработке системы, короткое видение термина может привести к долгосрочной фрустрации и увеличение времени разработки.
Работа сервера
Мы собираемся где-то нужно контролировать нашу работу с, это должна быть единственная система в вашей сети, которая имеет фиксированный локатор ресурса, будь то IP-адрес, имя хоста, адрес (с использованием внутреннего DNS) и т.д. Это происходит потому, что рабочие должны знать, где искать работу, работникам необходимо найти систему управления заданиями (не система управления заданиями найти работников).
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:
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.
- Вакансии занять от 1 минуты до запуска: Это означает, что ваши работники займет около 15 минут для выполнения каждого задания. Хотя это может поначалу показаться идеальной, вы получаете дополнительную обработку работе во время обеда, кофе-брейки, встречи и т.д. этот сценарий ставит нагрузку на другие области системы и вводит свои собственные проблемы. Например, в первую очередь ваши настройки / время обработки соотношение будет идти прямо, поэтому потери эффективности системы. Ваша сеть будет постоянно потокового работы информации различных рабочих расстраивает сотрудников, которые дон их повседневной работе. Вы также собирается уделять больше нагрузка на сервера обработки заданий, как он должен блюдо из много-много маленьких кусочков работу на регулярной основе. Наконец, в этой ситуации, если ваша работа сервер выходит из строя, вы собираетесь создать огромное бревно обратно незавершенного работы в то время как больше рабочих мест могли бы, продолжали обработку в блаженном неведении о том, что работа сервера, испытывающих трудности.
На самом деле там будет некому идеальной конфигурации для настройки сети, многое зависит от имеющихся ресурсов, видов работы, должностных требований затрат времени, возможность работы в сети, и так далее. Тем не менее некоторые рекомендации будут:
- Размер работу так, чтобы каждый работник может пройти как минимум 3-4 рабочих мест в течение 15 часов (вероятно, самый длинный период простоя времени)
- Играть с работой размер так, чтобы настройка времени становится незначительным по сравнению с обработкой времени (с учетом выше точки).
- Если работа не была завершена в два раза больше времени (может быть меньше), Вы ожидаете, чтобы завершить его предполагается, что его ушли в самоволку и начать ее обработку с другим работником. Это означает, что вы, возможно, придется ждать до трех раз нормальная продолжительность работы его завершения (возможно, и дольше, если последующая работа не удается). Вы можете сократить это время, но будьте осторожны, чтобы не уменьшить его слишком много, как вы можете начать дублирование задач обработки на регулярной основе.
- Вакансии должны быть независимы от внешних требований, насколько это возможно. Работа сервера, например, должны быть контакты в начале и в конце каждой работы.
- Не насытить вашей сети, это будет иметь два отрицательных эффекта, ваш дневной персонал найти с помощью сети разочарование и проблемы могут возникнуть с подключением время ожидания, что проблема будет только хуже, как вы масштабирования сети.
- Обеспечить рабочие места могут работать на ваших работников. Если работа стала слишком большой объем памяти или дискового пространства интенсивная работа начнется прерывание и единственное, что вы заметите это капля в число рабочих мест, обрабатываются никакой реальной причины, почему.
Представление результатов работы
При подаче результатов работы важно, чтобы убедиться, что результаты не были представлены на другого работника, особенно если текущий рабочий был заморожен на некоторое время.
Когда результаты представлены убедиться, что ряд результатов, совпадает с количеством записей в работу.
Как отмечалось ранее, и не может быть переоценить, построить отказоустойчивости в поиск работы и результаты представления. Работники могут (и, скорее всего, будет) переходят в режим ожидания в самый неподходящий раз, и это должно быть обслужены. Также еще раз абстрагируясь от ваших результатов представление поможет удовлетворить будущие изменения в работу системы управления гораздо проще иметь дело.
Резюме
В этом section мы смотрели на то, что сервер управления заданиями нужно сделать и как получить очень простой системой настройки. Мы обсуждали, как получить работу в системе управления, и как лучше настроить рабочие места, чтобы получить большинство наших вашей системы сетки офиса. Чтобы закончить, один-два абзаца о представлении результатов на сервер управления заданиями была представлена.
- Сервер управления работой управляет заданиями и гарантирует, что все работы будут завершены единиц
- Абстрагируясь работу выбрать / результаты представления, мы можем изменить технологию управления сервером без особых проблемы
- Настройка рабочих мест, чтобы они работают быстро и эффективно, не подвергая слишком много давления на сетевую инфраструктуру, и без дублирования задач обработки на регулярной основе.
- 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.
Next time
In part 3 we'll create our virtual processing machine and set up our windows machines to become idle-time workers.
Комментарии (6) 
PHP , веб-программирование , Zend Framework | 
добавить , загрузки , контейнер , динамично , навигации , страницы , PHP , суб-страницы , зрения , Zend , Zend Framework , Zend_Navigation 
Themocracy