Introdución
Eu traballo nunha empresa onde realizar traballos de procesamento por lotes moitos millóns de rexistros de datos de cada día e eu teño pensado recentemente sobre todas as máquinas que se senten ao redor de cada día sen facer nada por varias horas. Non sería bo se puidésemos utilizar estas máquinas para reforzar o poder de procesamento dos nosos sistemas? Neste conxunto de artigos que eu vou mirar para os potenciais beneficios da contratación dunha oficina da rede usando ambientes virtualizados.
Na parte 1 eu dei unha visión xeral do sistema e as tecnoloxías que vai utilizar, así como discutidos algúns dos posibles motivos polos que desexa crear unha rede de oficina.
Job Control
Se indo para ser executado emprego, entón vai ter algunha maneira para administra-los. O seu sistema de control do traballo (no seu servidor de traballo) ten que ser moi ben pensada antes de intentar realizar unha rede de oficina. Polo tanto, en primeiro lugar, cales son as tarefas de un sistema de control do traballo:
- Distribúe tarefas, a petición dos traballadores
- Diga traballadores que tipo de traballos para seren executados
- emprego Track
- Asegúrese de que os traballos só son executados unha vez
- Proporcionar datos de emprego aos traballadores, ou, polo menos, dicirlles onde obtelo
O sistema tamén debe ser extensible, unha solución que funciona de momento nun único caso pode ser prorrogado para executar varios tipos de traballos que a empresa ve o valor nunha solución de rede. Por exemplo, os traballos poden gañar prioridades, máis de un tipo de traballo pode haber (ou sexa, varias bases de código), eventualmente pode incluso realizar varias máquinas de traballo diferentes que están optimizados para cada tipo de traballo (aínda que isto non se afastar do "traballador xenérico 'idea). Sempre intento pensar no futuro cando os sistemas en desenvolvemento, unha visión a curto prazo pode levar á frustración a longo prazo e tempo de desenvolvemento aumentou.
Traballo de servidor
Imos ter que un lugar para o noso traballo de control, este debe ser o único sistema na súa rede que ten un localizador de recursos fixos, sexa un enderezo IP, nome do servidor da URL (mediante DNS interno), etc Isto é porque os traballadores teñen que saber onde buscar emprego, os traballadores necesitan atopar o sistema de control de traballo (non o sistema de control do traballo atopar os traballadores).
O servidor de traballo en si non ten realmente unha tarefa complicada (nun sistema básico de calquera maneira), el que almacenar unha lista de postos de traballo, distribuír tarefas, recibir os resultados, e posteriormente gardalas para a súa posterior recuperación. Como estas pezas (como "man de emprego") son definidos pode ser moi básico. Máis tarde, podemos estender o sistema para incluír unha interface de administración para engadir, editar, borrar, suspender os traballos, pero iso está alén deste exercicio.
Non hai ningunha razón, entón, que o teu servidor de emprego non podería ser unha máquina virtual rodando dentro do seu servidor de procesamento principal, sempre que non drena moitos recursos del. O servidor de traballo pero non necesitan de alta dispoñibilidade, se vai para abaixo unha noite de venres vai perder toda unha semana de tratamento, pode custa-lle un par de semanas por valor de tempo de procesamento (en comparación co seu servidor de procesamento principal só) . Pode querer poñer o seu servidor de traballo nun ambiente de balance de carga para alta dispoñibilidade.
Configuración básica
A configuración básica para o noso servidor de traballo estará composto por que eu estou chamando unha de Limp meus servidores (que é Li nux, ySql m, P HP). O código execución traballadores Thea vai realmente traballar para fóra o traballo que pode realizar, interactuar con bases de datos co traballo do sistema de control. Posteriormente, poderiamos crear un web service e realmente a entrega dos traballos en vez de ter os traballadores fan o traballo duro en si, senón por agora imos seguir usando o principio KISS (Keep it Simple, Stupid!).
Entón, imos crear tres MySQL táboas para xestionar os traballos. Estes serán «emprego», «jobRecords`, e `jobResults».
Aquí está a usar o SQL Buddy un pouco grande alternativa ao phpMyAdmin só porque é máis fácil de instalar no Center (para os outros, ver: 10 grandes alternativas ao phpMyAdmin )
Esta táboa está composta de 5 campos simple,
- ID: Identificar o traballo
- Nome: Podería ser unha referencia de cliente, ou calquera número de outros identificadores
- Estado: Debe saber que o traballo está, por exemplo,
- 0: Non iniciado
- 1: Peguei
- 2: Rematada
- started_by: Quen empezou a facer o traballo? Isto non é totalmente necesario, pero é bo ter. Eu suxiro seguimento dos traballadores polo seu enderezo IP na rede
- started_at: Cando o traballador iniciar o traballo? Ao seguir os traballos que non teñan completado no prazo de X cantidade de tempo que sabemos que cómpre tomar o traballo, unha vez máis e comezar a procesar por outro traballador. Traballadores poden deixar o procesamento / go off-line para calquer número de razóns, falta de enerxía, accidente, perda de rede, etc
É doado coma este cadro podería ser estendido con algúns campos adicionais para permitir estatísticas de seguimento, unha columna horario de finalización para ver canto tempo o traballo tomou, un contador para ver cantos traballadores colleu o traballo (obviamente iso precisa tenden a 1), a prioridade dos traballos, a lista pode ir sobre e sobre. En escenarios máis complexa tarefa sería posible especificar a cantidade de memoria que o traballador terá acceso ó (e, polo tanto, utilizar só os traballadores máis axeitados), ou mesmo o tipo de traballo sería necesario.
Permite engadir un exemplo de algúns traballos:
A seguinte táboa de novo é ben sinxela de entender, estes son datos que o noso traballo. Están ligados á mesa de traballo por medio dunha columna `jobs_id». A composición desta táboa depende moito dos datos que cómpre proporcionar aos seus traballadores, imos facer un exemplo moi sinxelo, onde temos catro columnas:
- gravar o id: identificación do
- nome: é o nome da persoa
- enderezo: o enderezo Persoa
- jobs_id: O traballo de identificación de que este rexistro é ligada á
A táboa a terceira e última consiste nunha táboa de resultados, ten case a mesma cousa compoñen a nosa táboa de rexistros, e coa adición de algunhas columnas poderían ser parte da táboa de rexistros:
- mesa de traballo job_record_id: Ligazón ao resultado do
- Resultado: os datos do resultado
... E iso é todo o que precisa para o control de traballo! (Aínda que a un nivel moi básico) No meu caso estou vinculado a outra mesa onde os meus datos para procesar foi localizado, pero isto pode só como facilmente ser un ficheiro, os parámetros para executar o código de simulación, o seu nome.
Seleccionando un emprego
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.
En realidade non haberá unha configuración ideal para a súa configuración de rede, depende moito dos recursos dispoñibles, tipo de traballo, as esixencias da función tempo de resposta, a capacidade de rede, e así por diante. Con todo, algunhas orientacións serían:
- traballos en tamaño de modo que cada traballador pode pasar por polo menos 3-4 postos de traballo nun período de 15 horas (o máis longo período de tempo probable idle)
- Xogar coa dimensión do traballo a fin de que o tempo de configuración tórnase moi insignificante cando se compara co tempo de procesamento (tendo en conta o punto anterior).
- Un traballo non é concluído o dobre a cantidade de tempo (quizais menos), espera que completa ela asumir que AWOL seu pasado e comezar a proceso-lo con outro traballador. Isto significa que pode ter que agardar a tres veces o tamaño normal dun traballo para a conclusión (posiblemente máis, se o traballo subseguinte falla). Pode querer reducir este tempo, pero teña coidado de non reduci-lo moito como podes comezar a duplicación de tarefas de procesamento nunha base regular.
- Traballos deben ser independentes das necesidades de fóra, na medida do posible. O servidor de emprego, por exemplo, só debe ser contacto no inicio e ao final de cada traballo.
- Non saturado súa rede, terá dous efectos negativos, o seu equipo vai atopar durante o día utilizando a rede frustrante e problemas poden ser probados con conexións tempo de espera un problema que só vai peor a medida que a escala do grid.
- Asegúrese de traballos poden ser executados nos seus traballadores. Os traballos de facerse demasiado espazo de memoria traballos intensivos ou intensivos de disco comezará a abortar eo único que vai notar un descenso no número de traballos procesados, sen motivo real.
Entregaren os resultados dun traballo
Ao presentar os resultados dun traballo é importante comprobar que os resultados non foron presentados por outro traballador, especialmente se o traballador actual estivo durminte por algún tempo.
Cando os resultados son presentados garantir que o número de resultados corresponde ao número de rexistros dentro do traballo.
Como dito anteriormente, e non pode ser subestimado, construír tolerancia a fallos en recuperación de traballos e presentación dos resultados. Os traballadores poden (e que seguramente) entrar no modo de suspensión no inconveniente a maioría das veces e iso ten que ser atendidas. Ademais, unha vez abstrair súa submisión resultados axudar a atender a futuras cambios no seu sistema de control de traballo moito máis fácil de manexar.
Resumo
Neste section nós miramos o que é un servidor de control de traballo ten que facer e como obter un sistema moi básico configurado. Discutir como recuperar un traballo dende o sistema de control ea mellor forma de configurar tarefas para obter o máximo do noso sistema de reixa de oficina. Para finalizar, un parágrafo ou dous sobre a presentación dos resultados ao seu servidor de control de traballo era presentado.
- Un servidor de control de traballo xestiona emprego e asegura que todas as unidades de traballo son concluídas
- Ao abstrair o traballo de seleccionar / submisión resultados podemos cambiar a tecnoloxía do control de servidor sen grandes problemas
- Configure o seu traballo para garantir que sexan executados con rapidez e eficiencia, sen poñer demasiada presión sobre a infraestructura de rede, e sen duplicar tarefas de procesamento nunha base regular.
- Asegúrese de construír a tolerancia a fallos e checking erro nas súas rutinas, os traballadores poden suspender e retomar o inconveniente e na maioría das veces. Lembre-se de comprobar que os resultados xa foron presentados por outro traballador.
A próxima vez
Na parte 3 , imos crear o noso procesamento de máquina virtual e configurar o Windows para facer as nosas máquinas de traballadores a tempo ocioso.
Comentarios (2) 
Ao establecer cada un dos seus traballadores como un escravo para o traballo de actualizacións do servidor de control para as fontes de datos vai pingar moi ben no seu traballo sen un gran aumento na actividade da rede (que é menos que realizar unha actualización de datos enorme e todos os seus traballadores patada no ao mesmo tempo). Isto ten vantaxes sobre o rsync en que non ía estar dunha longa pausa antes de cada traballo, como as actualizacións da base de datos, o mysql servizo no seu traballo continuamente actualizar os seus datos, o procesamento continúa. 
Artigos , Informática , computación Grid , Linux , PHP , Programación Web | 
bash , lote , código , datos , rede , Linux , mestre , MySQL , PHP , procesamento , redbean , replicación , rsync , script , escravo , subversion , svn , svn update 
