Увод
Радим у фирми где смо покренули многе серија Послови обраде милионе записа података сваког дана и ја сам недавно размишљао о свим машинама које седе око сваки дан не радећи ништа за неколико сати. Зар не би било добро ако бисмо могли да користимо ове машине да ојача моћ обраде наших система? У овом сету чланака ћу да се осврнемо на потенцијалне користи од запошљавања канцеларију мрежу користећи виртуелизованим окружењима.
У Парт 1 сам дао преглед система и технологија ћу бити користећи као и разговарали су неки од могућих разлога због којих бисте желели да креирате мрежу канцеларије.
Контрола посао
Ако идете да се ради посао онда ћете морати да на неки начин да управљате њима. Ваш систем контроле посао (на радном серверу) треба да буде заиста добро промишљена, чак пре него што покушате да покренете мрежу канцеларије. Дакле, прво, шта су задаци за посао система контроле:
- Предати послове на захтев радника
- Реците радника који тип Послови за покретање
- Трацк Послови
- Уверите се да су послови изводити само једанпут
- Обезбедите податке посао радника, или бар реците им где да га добијете
Систем такође треба да буде проширив, решење које за сада ради у једном случају може се продужити да ради неколико типова радних места, као на послу види вредност у грид решење. На пример, послови могу добити приоритете, више од једног посла типа може постојати (тј. неколико код базе), на крају мозда цак покренете више различитих машина радилице које су оптимизоване за сваку врсту посла (мада да се удаљавају из 'генерички радника 'идеја). Увек покушајте да размишљају о будућности када се развијају системе, краткорочни визија може довести до дугорочније фрустрације и повећаног развоја времена.
Посао сервер
Идемо негде да треба да контролише свој посао из, ово би требало да буде једини систем у координатној мрежи која има фиксну Ресоурце Лоцатор, бити да ИП адреса, име домаћина, УРЛ адреса (користећи интерни ДНС), итд То је зато што радници треба да знају где да потраже посао, радници треба да пронађу посао контролни систем (није посао систем контроле наћи радника).
Посао сервера се заиста не имати компликован задатак (у основном систему свакако), потребно је да сачувате листу радних места, од руке посла, добијају резултате, а потом их сачувате за касније прегледавање. Како су дефинисани ови делови (као што су "из руке посла ') може бити врло основни. Касније можемо да прошири систем да обухвати интерфејс управе да додајете, мењате, бришете, суспендује посао али то је ван ове вежбе.
Нема разлога онда да ваш сервер посао не може бити виртуелна машина ради у оквиру свог главног сервера за обраду под условом да не празни превише средстава из њега. Посао сервера међутим не треба високу доступност, ако иде доле на петак увече када имате да изгубите цео викенд обраде, потенцијално вам кошта неколико недеља у вредности од времена обраде (у односу на свог главног сервера за обраду алоне) . Можда ћете желети да размотрите свој посао стављањем сервер на оптерећења уравнотеженом окружењу за високу доступност.
Основна подешавања
Основна поставка за наш посао сервера ће се састојати од онога што ја зовем један од мојих Лимп сервера (који је Ли нук, иСкл м, п кс). Код ради на Тхеа радника ће заправо радити шта Послови може покренути по интеракцији са посла са базама података контролних система. Касније смо могли креирати веб сервис и заправо руку радних места уместо да радници раде напоран рад се, али за сада ћемо наставити користећи принцип КИСС (Кееп ит симпле, ступид!).
Дакле, омогућава креирање три МиСКЛ табеле да се баве пословима. То ће бити `Послови`, `јобРецордс`, `и` јобРесултс.
Ево ја користим СКЛ Будди велики мало алтернативу пхпМиАдмин само зато што њено лакше инсталирати на ЦентОС (за други виде: 10 Греат алтернатива пхпМиАдмин )
Ова табела се састоји од 5 једноставних поља,
- ИД: јединствено идентификују посао
- Назив: Могао би бити клијент референца, или било који број од осталих идентификатора
- Статус: Ви треба да знате где је посао на, нпр
- 0: није почео
- 1: покупили
- 2: Завршено
- стартед_би: Ко је поцео да ради тај посао? Ово није у потпуности обавезно, али је лепо имати. Хтео предлажемо праћење радника од њихове ИП адресе на мрежи
- стартед_ат: Када је радник започнете посао? Праћењем послове које нису попуњене у износу од Кс времена знамо да треба да покупи посао поново почети обраду и од стране другог радника. Радници могао зауставити обраду / го ту за било који број разлога, нестанка струје, пада система, губитка мреже, итд
Лако је како би ова табела може проширити са неколико додатних поља да би се омогућило праћење статистике и финиш време колоне да бисте видели колико је посао, бројач да бисте видели колико радници покупили посао (наравно ово треба да имају тенденцију да 1), приоритет посао, листа може да иде на и на. У сложенијим сценаријима за посао било би могуће да одредите колико меморије радник ће морати приступ (и зато користите само одговарајуце раднике), или чак и оно што тип радника бити потребно.
Хајде да додате неколико послове примере:
Наредна табела поново је прилично једноставан за разумевање, ово је наш посао записа. Они су повезане на главној табели радних места колони `јобс_ид`. Чине ове табеле веома много зависи од података који су вам потребни за снабдевање вашим радницима, омогућава да веома једноставан пример где имамо четири колоне:
- ИД: ИД записа
- Име: име особе
- 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 reality there will be no one ideal configuration for your grid setup, much depends on the available resources, types of job, job turnaround time requirements, network capability, and so on. However some guidelines would be:
- Size jobs so that each worker can get through at least 3-4 jobs in a period of 15 hours (the longest likely idle time period)
- Play with the job size so that setup time becomes fairly insignificant compared to the processing time (bearing in mind the above point).
- If a job doesn't complete in double the amount of time (maybe less) you expect it to complete it assume that its gone AWOL and start processing it with another worker. This means you may have to wait up to three times the normal length of a job for it to complete (possibly longer if the subsequent job fails). You may want to reduce this time, but be careful not to reduce it too much as you may start duplicating processing tasks on a regular basis.
- 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.
Као што је речено раније, и не може бити више нагласио, изгради толеранцију грешке у проналажењу посла и достављање резултата. Радници могу (и највероватније ће) ићи у суспенд режиму у већини незгодно пута и то треба да буде за цатеред. Такође, још једном апстрахујући своје резултате у гостима поднесак ће помоћи задовољава будуће промене у вашем систему контроле посао много лакше да се баве.
Резиме
У овом сецтионА смо посматрали шта посао контроле сервера треба да уради и како да се врло основни систем поставили. Разговарали смо о томе како да преузме посао од управљачког система и како најбоље да подесите да добијете посао највише наших вашег система канцеларијског мреже. Да завршим, став или две о достављању резултата натраг на серверу посао контроле је представљен.
- Посао контроле сервера управља радних места и осигурава да су завршене све радне јединице
- По свој посао апстраховања изаберите / Резултати подношење можемо да променимо технологију контролног сервера без много проблема
- Конфигуришите своје послове како би се осигурало да су покренути брзо и ефикасно без стављања превише притисак на вашем мрежне инфраструктуре, и без умножавање обраду задатке на редовној основи.
- Уверите се да изгради толеранцију грешке и грешке у цхецкингА ваше рутине, радници могу обуставити и наставити и већина незгодно пута. Не заборавите да проверите да ли су резултати већ поднет од стране другог радника.
Следећи пут
У делу 3 ми ћемо креирати нашу виртуелну машину за прераду и поставили наши прозори машине да постане неактиван-тиме радници.
Коментари (6) 
ПХП , Веб програмирање , Зенд оквир | 
додај , дизања и контејнер и динамично и навигација и странице и ПХП и Суб-паге и поглед и Зенд и Зенд Оквир и Зенд_Навигатион 
