Comentarios (2)

Por Steven Lloyd Watkin , venres 04 de decembro de 2009 11:59

Introdución

Eu traballo nunha empresa na que corremos moitos traballos en lote procesar millóns de rexistros de datos de cada día e eu estiven a pensar recentemente sobre as máquinas que se sentan ao redor de cada día sen facer nada durante varias horas. Non sería bo se puidésemos utilizar esas máquinas para reforzar o poder de procesamento dos nosos sistemas? Neste conxunto de artigos que eu vou ollar para os potenciais beneficios da contratación dunha oficina de reixa utilización de ambientes virtualizados.

Na parte 3 , creamos a nosa máquina de procesamento virtual e configurar o Windows para converterse en máquinas de tempo ocioso dos traballadores.

Executando o código máis recente

Inevitablemente, despois de crear a súa lóxica de negocio traballadores vai cambiar, erros serán atopados, código máis rápido máis eficiente será producido deixando os seus traballadores estiveron sentados arredor de procesamento de datos usando código smelly vello . Como entón asegurar que estamos sempre a través da versión máis recente e maior dos nosos scripts de procesamento?

Hai algúns moi fáciles formas simples que poderiamos facelo, o truco, con todo, é reducir o poder de procesamento e tráfico de rede para alcanzar isto. Imos comezar a máis simple das solucións e melloralas lo lentamente ao longo dun par de iterações.

O primeiro método sería simplemente conectar co noso servidor de control de traballo (vía samba, FTP, ou similar) e tire abaixo a versión de código. Non é moi eficiente, pero vai facer o traballo. Permite mellorar iso un pouco, como sobre a creación dun guión rsync e utilizar ese tempo cada vez? Alternativamente o que sobre a colocación do noso script última transformación en subversión comprobar o código inicialmente e despois é só actualizar o noso código en cada run ( svn update )?

Ao final, pode acabar cun guión bash (chamado polo cron cada 10 minutos), que parece tan sinxelo coma isto:

  #! / Bin / sh
 se ps ax | grep-v grep | grep php > / dev / null
 entón
     echo "Job está a procesar, de saída"
 outro
     echo "O traballo non está en execución, comezar agora"
     cd / ruta / a / traballo / copia
     svn update
     php yourJobProcessingScript.php
 fi 

Agora podemos estar seguro de que cada rolda estamos sempre en execución o código máis recente. Estamos garantindo que a actualizar a nosa base de código cada vez que facemos unha carreira e reducindo o tráfico da rede por trasladar só as diferenzas de arquivo en toda a nosa rede.

Na miña configuración de demostración, eu fixen exactamente como descrito anteriormente. Subversion foi instalado no meu servidor de procesamento de traballo e eu simplemente tirou o último código dun "traballador" filial usando 'svn update'. Eu tamén engade unha etiqueta número de versión para o meu programa de procesamento que foi devolto á base de datos como parte do retorno de resultados. Desta forma, puiden ver que o meu código estaba sendo actualizado cada vez que eu copiei o meu tronco no ie sector de traballo que eu estaba sempre executar o script máis recente de procesamento.

Empregando os datos máis recentes

O procesamento do traballo fai uso de fontes de datos, a continuación, nalgún momento estes van ser actualizados. A menos que chamar as súas fontes de datos en unha base moi frecuente vai inundar a rede con tráfico así que os traballadores comezan a correr levando todo a un impasse. Para a miña solución, decidín que me gustaría pasar miñas fontes de datos de todo coas miñas VMS.

Manteña vostede cabalos alí! E se as miñas fontes de datos son enormes? Ben este é realmente un caso de que a cantidade de datos que estamos a falar? Pode ser máis rendible para instalar un maior disco duro adicional en cada máquina que mercar un servidor de procesamento adicional. Esta é unha cuestión de orzamento e ata a empresa para decidir. Poida que sexa a que as súas fontes de datos son tan grandes que non é máis inviábel para manter esa cantidade de datos nas súas máquinas de traballo. Nese caso o que faría? Así, poderiamos mirar para chamar a un servidor de datos local, pero iso pode causar problemas coa rede. Neste caso, un sistema de reixa, como este pode chegar a ser irrealista para incluír no seu ambiente de escritorio. Pode ser tamén que podes ollar para estratexias alternativas de execución, por exemplo, só chamar seus traballadores oito horas - seis horas cada noite e / ou optimización de solicitudes de datos de orixe.

Seguindo adiante, imos dicir os nosos datos cantidade de fontes de 100GB de datos. Ben, si que é un pouco de datos para se desprazar na rede nunha actualización. Como é seguro que temos a copia máis recente dos datos neste caso? Rsync é unha posibilidade, pero persoalmente creo que, executando o seu último fonte de datos no servidor de procesamento de traballo e como facer esa configuración como un mestre na replicación (cun ​​rexistro bin bo tempo) pode ser o camiño a seguir:

Ao definir cada un dos seus traballadores como un escravo para o traballo actualizacións do servidor de control das súas fontes de datos pode escorrer ben aos seus traballadores, sen un gran aumento na actividade da rede (que é a menos que executar unha actualización de datos enorme e os seus traballadores entran en acción dunha vez). Isto ten vantaxes sobre rsync en que non ía estar unha 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.

Isto é como eu configurar o meu servidor de demostración. Para configurar a replicação seguín a guía no sitio web de MySQL ( Configurar replicación ) e en 20 minutos eu tiña o meu traballo inital replicar o traballo de control conxunto de datos servidores. Para cada traballador adicional a configuración de replicación e proceso de traballo cada vez que a máquina virtual foi copiado.

Resumo

Nesta sección do artigo vimos como é doado e indolor e para manter o seu código de procesamento ata a data por using rsync ou subverion (SVN) para facer o traballo e reducir o tráfico de rede no mesmo time. Tamén discutir como para manter as súas informacións de fonte de datos up-to-date, permitíndolles a escorrer para cada un dos seus traballadores. Así, área que garanta a manter-se coa lóxica de negocio e información no noso sistema de rede da oficina. Non será, obviamente, moitas alternativas para a execución destas tarefas, pero aquí foron dous exemplos sinxelos para mostrar como é fácil solución está por vir.

Próxima vez

Na parte final desta serie, apropiadamente chamado Parte 5 , imos discutir a implantación deste sistema para. Vou resumir o que foi aprendido eo que eu puiden crear.

Comentarios (3)

Por Steven Lloyd Watkin , venres 04 de decembro de 2009 23:37

Introdución

Eu traballo nunha empresa na que corremos moitos traballos en lote procesar millóns de rexistros de datos de cada día e eu estiven a pensar recentemente sobre as máquinas que se sentan ao redor de cada día sen facer nada durante varias horas. Non sería bo se puidésemos utilizar esas máquinas para reforzar o poder de procesamento dos nosos sistemas? Neste conxunto de artigos que eu vou ollar para os potenciais beneficios da contratación dunha oficina de reixa utilización de ambientes virtualizados.

Na parte 2 nós miramos os traballos serán executados nun servidor, e como os traballos deben ser configurados para acadar maior cantidade de procesamento, garantindo que cada traballo é procesado, sen fallar.

Configurar o traballador - ou servidor Limp

O seguinte paso no proceso é a creación dos seus traballadores virtuais. Por iso eu vou usar unha instalación de CentOS usando VirtualBox. Vou instalar MySQL e PHP no servidor, tamén coñecido como Bizkit (Li nux, m ySQL, P HP) Servera (eu poida facer ese nome).

• Instalar VirtualBox na súa máquina Windows (continuación enlace)
• Baixo e instala o CentOS (versión actual 5.3) dentro dunha máquina virtual creada

Non adianta ir a este probablemente hai 1.000 's de tutoriais aí fóra (ok, aquí vai un: Creando e Managing CentOS máquina virtual no VirtualBox ). O punto importante a destacar é que supoño que eu chamei miña máquina virtual GridMachine.

Tanto como as miñas opcións do cliente de virtualización de sistema operativo e alí non é gran motivo convincente para cada elección. VirtualBox é algo que eu uso na miña máquina na casa e é apoiado polos tres principais sistemas operativos. Eu escollín o CentOS como o seu sistema operativo unha boa estable e eu uso no meu propio servidor web. Son un gran crente nas ferramentas certas para o traballo (aínda que eu estou aplicando "usar o máis rápido e máis doado para ti" mentalidade aquí), entón o sistema operativo X executa o código máis rápido e máis eficiente usar isto en vez :)

É importante asegurarse de que a súa VM emprega DHCP, se non, para cada nova máquina virtual que debe ser configurado por separado que é algo que non want.By utilizando DHCP non precisa configurar as opcións de rede individualmente para máquinas de traballo, DHCP pode entregar fóra IPs para ti. Así, pode copiar a máquina virtual no escritorio sen se preocupar sobre como configurar cada un para arriba (é dicir mellora a módulos e reduce a administración traballador).

O proceso que ten que ter como obxectivo sería conseguir unha nova máquina física, instala o VirtualBox, e, a continuación, practicamente implantar a imaxe virtual sen máis. Pode ser sabio para configurar os seus traballadores en unha sub-rede diferente para que poida, polo menos, ver cantas máquinas están funcionando. Tamén cómpre configurar as súas máquinas nun contrato a longo ou de concesión ilimitada DHCP.

Como facer Jobs sobre o traballador

Esta é unha área interesante e existen varios métodos válidos para procesar os traballos sobre o traballador. Aquí eu só vou discutir os dous máis obvios:

• Perpetuamente executar o script: Un guión, sexa un shell script, ou un script PHP é executado unha vez sobre o traballador e é executado como parte dun loop infinito. Eu xa descontado a rede como un accidente do guión e, potencialmente, os traballadores deixarán de funcionar sen ningún tipo de intervención.
• Cron a execución de scripts baseada en: cada X minutos o servizo cron inicia unha chamada ó arquivo para facer as cousas ocorrer. Sen algunhas probas este podería levar a moitas moitas copias da súa carreira guión traballador.

A miña decisión era ir co cron que comeza un shell script cada minutes. 10 O meu guión shell executa as seguintes tarefas:

1. Faga unha lista de procesos e grep para este 'php'. Se non está, a continuación continuar.
2. Chame ao seu código de traballo, no meu caso iso sería algo baseado PHP
3. Guión traballador completa a súa execución
4. Preparado para ir de novo a próxima chamada axeitada

O meu script bash parece algo como o seguinte:

  #! / Bin / sh
 se ps ax | grep-v grep | grep php> / dev / null
 entón
     echo "Job está a procesar, de saída"
 outro
     echo "O traballo non está en execución, comezar agora"
     php yourJobProcessingScript.php
 fi 

Nota: o de eco son case completamente inútil, pero pode axudar a seguinte persoa que vén para intentar editalos.

Isto conclúe a configuración da máquina de traballo virtual, rápido, sinxelo e fácil de copiar a cada nova peza de hardware que é recibido. A "intelixencia" do sistema de rede realmente non é visualizado no sistema operativo, é todo que ver co código creado para traballos do proceso, a configuración do traballo, e para garantir que o traballo é executado no seu caso (ou sexa, cando o anfitrión é ocioso ).

Configurando o Windows para arrincar Traballadores

A primeira tarefa é descubrir o comando necesario para realizar a máquina virtual dende a liña de comandos de Windows. Se instalar o VirtualBox na localización predefinida e nomeou o seu traballador GridMachine entón o mando necesario para cargar o seu traballador é:

  "C: \ Arquivos de programas \ Sun \ VirtualBox \ VBoxManage.exe" startvm GridMachine 

Con todo, para executar o script nun estado 'sen cabeza', cómpre usar:

  "C: \ Arquivos de programas \ Sun \ VirtualBox \ VBoxHeadless.exe"-startvm GridMachine - VRDP = off 

Isto iniciar a máquina virtual sen a GUI e permitir que salva o estado graciosamente. O segundo argumento desactiva RDP polo que non entra en conflito con fiestras RDP, ou dar-lle unha mensaxe sobre escoita na porta 3389. O nome da máquina virtual é sensible a maiúsculas!

A continuación, imos ter definir fiestras ata comezar a nosa VM traballador unha vez que a máquina está ociosa. Para iso (en Windows XP) ten que ir en Inicio -> Programas -> Accesorios -> Ferramentas do Sistema -> Tarefas programadas conforme a continuación:

A continuación preme en "engadir tarefa programada 'seguido de navegar para engadir un programa personalizado. Desprácese ata o guión VBoxManage e prema en Aceptar. Agende súa tarefa para calquera das opcións (imos cambiar isto nun minuto) e seguir. Despois de saltar a seguinte pantalla de Windows ha pedir que quere levar a cabo esta tarefa, eu sugiro que sexa "administrador" ou crear un novo usuario privilexiado. Lembre que non queremos interferir na conta persoal estándar na máquina en calquera momento. Preme aquí ao lado e confía concerto advanced options para esta tarefa.

Para o fin da caixa de texto longo engadir noso cadea 'startvm GridMachine "e garantir que execución só cando conectado queda DESestablecido. Visita a tarefa seguinte programa e cambiar o programa de caer para a opción "cando ocioso", escolla a cantidade de tempo que lle gustaría que o ordenador estea ausente antes de pasar á seguinte guía.

Finalmente Desmarque a opción que afirma deixar a tarefa se foi correndo X cantidade de tempo, pero non sinalar a opción de deixar a tarefa a máquina non está ociosa.

É iso entón, para a configuración de servidor de Windows!

Resumo

Nesta parte temos un conxunto de unha máquina virtual para actuar como un traballador, así como a forma na que chamamos e realizar os nosos scripts de procesamento de traballo (para min un script PHP). A partir de aquí, veremos como configurar nosas copias de Windows para iniciar a máquina virtual no modo headless cando o computador pasa a ser ocioso, e gardar o seu estado cando o usuario retomar a utilización da máquina. Esperemos que neste momento está a ver como é simple para configurar un sistema deste tipo e está ansioso para comezar algunhas experiencias vai vostede mesmo!

Próxima vez

Na Parte 4 , imos estar a ollar para o uso de ferramentas para garantir que está a empregar a última versión das fontes de código e datos, para que os resultados obtidos son sempre up-to-date coas últimas información da empresa e da lóxica.

Comentarios (1)

Por Steven Lloyd Watkin , venres 04 de decembro de 2009 11:23

Introdución

Eu traballo nunha empresa na que corremos moitos traballos en lote procesar millóns de rexistros de datos de cada día e eu estiven a pensar recentemente sobre as máquinas que se sentan ao redor de cada día sen facer nada durante varias horas. Non sería bo se puidésemos utilizar esas máquinas para reforzar o poder de procesamento dos nosos sistemas? Neste conxunto de artigos que eu vou ollar para os potenciais beneficios da contratación dunha oficina de reixa utilización de ambientes virtualizados.

Como PHP desenvolvedor vou usar as ferramentas que eu uso todos os días, ou sexa, Linux, MySQL , PHP, VirtualBox e Subversion (SVN). Con todo, eu espero que esta guía pode adaptarse a outras linguaxes e tecnoloxías tamén.

A solución que fornecer serán moi vagamente baseado no tipo de procesamento que sería necesario para conseguir, pode non ser verdade a través de todo o artigo como eu vou cambiar as cousas para a simplicidade, ou para producir escenarios de uso máis interesantes.

Estes ambientes virtualizados serán executados en máquinas Windows porque é o que a maioría das oficinas executado. O tratamento que as máquinas de oficina non debe interferir co persoal utilizando esas máquinas, deben non necesitan de mantemento na máquina, e ser facilmente salientable para novas máquinas que estean dispoñibles. Ademais, novas máquinas virtuais non debe esixir calquera configuración adicional, xa que reduce a módulos ea facilidade con que o sistema de rede pode ser prorrogado.

Por que implantar un Grid Computing Office?

En primeiro lugar, pode estar a pensar, por que non usar un recurso de computación en nube como plataforma EC2 de Amazon ? Ben, as razóns poden ser varias, por exemplo:

• Non vai confiar certos datos para un ambiente de computación en nube
• Non podes poñer algúns datos nun entorno de cloud computing, por motivos legais (por exemplo, datos de deixar o país), potencialmente, por razóns legais, por exemplo, os rexistros do SNS.
• Vostede quere manter as súas unidades de procesamento de pechar e ten control total sobre o hardware tamén
• Non ten os fondos do proxecto de execución de instancias de nubes
• Súa oficina non ten unha conexión a internet e, por tanto, que non é posible utilizar un recurso de nube
• Non gusta de choiva, nubes de chuvia suxiren, polo tanto, a manter moi lonxe

Estou seguro que a lista podería continuar, pero eu creo que é suficiente polo de agora.

Vantaxes dun Grid Computing Oficina

Ben, imos facer algunha matemática (e ao grande física realidade imos facer algunhas suposicións ampla). Imaxina que ten de procesamento do servidor gran executando beefy 100 postos de traballo ao día. Na súa oficina, ten 50 máquinas que están ociosos 16 horas ao día, cada unha destas máquinas é do 10% tan poderoso como o seu Sever procesamento robusto. (Todos os resultados aquí son redondeados a subestimar aumento de rendemento).

Así, unha máquina de poder do * 10% * 2/3 do tempo = 0,067 é dicir, procesamento escritorio 1 o tempo ocioso pode procesar 6 prazas de emprego completas por día.

Se agora escalar isto leva 15 escritorios ociosos para procesar traballos como moitos por día como o seu servidor de procesamento principal fai.

Así, na nosa oficina finxir de 50 máquinas, poderiamos aumentar o noso poder de procesamento a partir do 1 servidor ata 4 servidores de procesamento pleno, ou poderiamos estar procesar 400 empregos ao día en vez de 100.

Aviso previo, por ningún investimento en hardware novo a súa empresa acaba de ampliar a súa capacidade de procesamento en lote 4 veces! Potencialmente vai aumentar o seu consumo de enerxía, senón da maioría dos ambientes de escritorio que estiveron en máquinas son xeralmente deixadas pola noite de calquera xeito, así que podería ver isto como unha iniciativa verde.

Outras vantaxes tamén significa que o investimento en novas (ou actualizado) servidores de procesamento pode ser adiada se as máquinas da súa oficina son suficientes e que, como mellorar o poder das súas máquinas de oficina a súa reixa oficina faise máis poderosa automaticamente.

Tecnoloxías

O que precisa? (Ou máis correctamente o que eu uso):

• Ociosos de máquinas de oficina (no meu caso un libre de idade fiestras portátil XP)
• VirtualBox (ou outro software de virtualización de cliente)
• Unha máquina virtual con PHP, MySQL running executando un corte OS, eu estou chamando eses servidores meus Limp :)
• Traballos para seren executados
• Servidor Job (pode ser outra máquina virtual nalgún lugar)

Empregos típicos

Tipo de emprego que este sistema está deseñado para executar é o seguinte:

• Sistema recibe unha lista de datos sobre a que necesitamos para responder e devolver resultados
• Correspondencia implica comprobar / buscar varias fontes (bastante fixa) de datos
• Resultados das fontes de datos poden requirir unha validación adicional, fusión, comprobación de fontes de datos adicionais en resposta aos resultados
• Os datos son devoltos con rexistros correspondentes debidamente validados e procesados
• Cada rexistro dentro dun traballo é independente do resto

Entón, basicamente, estamos mirando para realizar traballos que requiren unha mestura de investigacións da base de datos e algún procesamento de números, un escenario bastante común en un ambiente de negocios.

Solucións de redes non só son vantaxosos para procesar os traballos deste tipo. Basicamente, calquera proceso que pode ser dividida en unidades independentes poden ser executados en paralelo. Vexa esta wikipedia exemplos e máis información: Grid Computing , pero un par de exemplos famosos son Seti @ Home e BIONC . Hai cadros para a execución de redes de computación, e estes valen a pena ollar en.

O que imos conseguir?

Ao final destes artigos, espero mostrar que a implantación dunha reixa de oficina non debe ser caro ou lento enorme tempo. Estou indo para discutir:

• Configurar o sistema de control de traballo, configuración de traballo
• Creando unha máquina de procesamento virtual axeitada
• Como configurar o sistema nunha máquina Windows
• Garantir que está a usar o código máis recente e os datos
• Implantación e avaliación do desempeño
• Mirando cara o futuro

Eu estarei de construción (ok eu constrúe, entón escribín iso) unha aplicación de exemplo para probar os conceptos nunha máquina local usando o Windows XP e miña máquina GridMachine 'virtual. O meu servidor de control de traballo será a miña máquina principal, que corre o Fedora 11 .

Isto é así sentido para demostrar un sistema totalmente funcional robusto, o seu significado máis dunha demostración e discusión mostrando que estas cousas pode ser conseguida nun período de tempo razoablemente curto e con custos relativamente reducidos. Sinto-se libre para me enviar os comentarios, correccións ou melloras e eu vou facer o meu mellor para manter este artigo actualizado para corresponden.

Próxima vez

Na parte 2 vou comezar por ollar para o sistema de control de traballo, e ollar en como os traballos deben ser configurados para acadar maior cantidade de procesamento, garantindo que cada traballo é procesado, sen fallar.

Comentarios (1)

Por Steven Lloyd Watkin , venres 04 de decembro de 2009 11:23

Introdución

Eu traballo nunha empresa na que corremos moitos traballos en lote procesar millóns de rexistros de datos de cada día e eu estiven a pensar recentemente sobre as máquinas que se sentan ao redor de cada día sen facer nada durante varias horas. Non sería bo se puidésemos utilizar esas máquinas para reforzar o poder de procesamento dos nosos sistemas? Neste conxunto de artigos que eu vou ollar para os potenciais beneficios da contratación dunha oficina de reixa utilización de ambientes virtualizados.

Na parte 1 eu dei unha visión xeral do sistema e as tecnoloxías que están empregando, así como discutir algunhas das posibles razóns polo que desexa crear unha rede de oficina.

Job Control

Se indo para ser executado emprego, entón vai ter algunha forma de xestiona-los. O seu sistema de control do traballo (no seu servidor de emprego) ten que ser moi ben pensada antes de intentar realizar unha rede de oficina. Entón, en primeiro lugar, cales son as tarefas dun sistema de control de traballo:

• Distribuír os traballos, a petición dos traballadores
• Diga traballadores que tipo de postos de traballo para realizar
• Traballos Pista
• Asegúrese de que os traballos son executado só 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 estendido para realizar varios tipos de traballos como a empresa ve o valor nunha solución de rede. Por exemplo, os traballos poden gañar prioridades, máis dun tipo de traballo pode existir (ou sexa, varias bases de código), finalmente pode incluso realizar varias máquinas de traballo diferentes que son optimizados para cada tipo de traballo (a pesar de que non se afasta do traballador xenérico 'idea). Sempre intento pensar no futuro no desenvolvemento de sistemas, unha visión a curto prazo pode levar á frustración a longo prazo e tempo de desenvolvemento máis grande.

Servidor de traballo

Nós imos ter un lugar para controlar o noso traballo de, este debe ser o único sistema na súa rede que ten un fixo Resource locator, sexa un enderezo IP, o nome do host URL (usando DNS interno), etc Isto é porque os traballadores teñen que saber onde buscar emprego, os traballadores teñen que atopar o sistema de control de traballo (non o sistema de control de traballo atopar os traballadores).

O servidor de traballo en si non ten realmente unha tarefa complicada (nun sistema básico de todos os xeitos), el que almacenar unha lista de empregos, man de postos de traballo, recibir os resultados, e, posteriormente, almacena-los para a súa posterior recuperación. Como estas pezas (como "man de empregos") son definidos pode ser moi básico. Máis tarde, pode estender o sistema para incluír unha interface de administración para engadir, editar, borrar, suspender os traballos, pero iso está fóra deste exercicio.

Non hai ningunha razón que sexa, entón, que o teu servidor de traballo non podería ser unha máquina virtual executando dentro do seu servidor de procesamento principal, sempre que non drena moitos recursos del. O servidor de traballo con todo é necesario alta dispoñibilidade, se vai para abaixo nunha noite de venres vai perder un fin de semana enteiro de procesamento, potencialmente custando-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 balanceo de carga para alta dispoñibilidade.

Configuración básica

A configuración básica para o noso servidor de traballo consistirá en que eu estou chamando un dos meus servidores Bizkit (que é Li nux, m ySql, P HP). O código a executar en traballadores Thea vai realmente descubrir o que pode facer traballos, interactuar con bases de datos con emprego de sistemas de control. Posteriormente, poderiamos crear un servizo web e realmente mão empregos en vez de ter os traballadores fan o traballo duro en si, pero por agora imos seguir usando o principio KISS (Keep it Simple, Stupid!).

Entón, imos crear tres MySQL táboas para manexar os traballos. Estes serán os `emprego`, `jobRecords` e `jobResults`.

Aquí está a usar SQL camarada unha boa alternativa pouco para phpMyAdmin só porque é máis fácil de instalar no CentOS (para outros o ven: 10 óptimas alternativas para phpMyAdmin )

Esta táboa está composta por 5 campos simple,

• ID: Identificar o traballo
• nome: Podería ser unha referencia de cliente, ou calquera número de outros identificadores
• Estado: Ten que saber onde o traballo está, por exemplo,
  • 0: Non iniciado
  • 1: Colleu
  • 2: Feito
• started_by: Quen comezou a facer o traballo? Iso non é totalmente necesario, pero é un bo ter. Eu suxiro que os traballadores de seguimento polo seu enderezo IP na súa rede
• started_at: Cando o traballador iniciar o traballo? Ao seguir os traballos que non teñan completado dentro X cantidade de tempo que sabemos que necesitamos para incorporarse o traballo unha vez máis e comezar a procesar por outro traballador. Os traballadores poderían deixar o procesamento / go off-line para calquera número de razóns, falta de enerxía, accidente, perda de rede, etc

É doado como esta táboa pode ser estendido con algúns campos adicionais para permitir estatísticas de seguimento, unha columna de tempo de chegada para ver canto tempo o traballo levou, un contador para ver cantos traballadores colleu o traballo (obviamente iso necesita tenden a 1), a prioridade dos traballos, a lista pode ir sobre e sobre. En escenarios de traballo máis complexos sería posíbel especificar a cantidade de memoria que o traballador precisaría para enlazar (e, polo tanto, utilizar só os traballadores máis axeitados), ou mesmo o tipo de traballador sería necesario.

Permite engadir un exemplo poucos empregos:

A seguinte táboa de novo é moi sinxelo de entender, son datos que o noso traballo. Eles están conectados á táboa de traballos principal por unha columna `jobs_id`. A composición desta táboa depende moito dos datos que precisa ofrecer aos seus traballadores, imos facer un exemplo moi sinxelo, onde temos catro columnas:

• id: identificación do rexistro
• nome: o nome da persoa
• Enderezo: Enderezo da Persoa
• jobs_id: A ID de traballo que este rexistro está ligado á

A táboa terceiro e último está formado por unha táboa de resultados, que ten o mesmo facer se como a nosa táboa rexistros, e coa adición de algunhas columnas podería ser parte da táboa de rexistros:

• job_record_id: vincular o resultado para a mesa de traballo
• Resultado: Os datos do resultado

... E iso é todo que precisa para o control de traballo! (Aínda que a un nivel moi básico) No meu caso eu estou vinculado a outra táboa onde os meus datos para proceso foi localizado, pero isto pode só como facilmente ser un arquivo, os parámetros para executar código de simulación, o seu nome.

Seleccionando un emprego

Como mencionado anteriormente, os traballadores van facer o noso traballo de xestión para nós agora, para todo o que necesitamos realmente facer é atopar un traballo que precisa de procesamento e obter a información. Como faríamos isto? Ben escoller os nosos criterios de selección de emprego e buscar emprego, en SQL eu fixen o seguinte:

1. Tome todos os traballos que non están marcadas como concluídas, mais do noso traballador e redefini-las (substitúa ME__ __ cun identificador máis doado, sería a dirección IP):

   UPDATE `jobs` SET `status` = 0 WHERE `status` = 1 AND `started_by` = __ME__; 

2. 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.

3. 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:

1. 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.
2. Traballos levar 1 minuto para executar: Isto significa que os traballadores levar uns 15 minutos para realizar cada traballo. Aínda que isto poida parecer inicialmente ideal, gañou procesamento traballo adicional durante a hora do xantar, coffee breaks, reunións, etc este escenario pon presión sobre outras áreas do seu sistema e presenta os seus propios problemas. Por exemplo, en primeiro lugar a súa razón de tempo de configuración / procesamento está a ir dereito para abaixo, perdendo así a eficiencia do sistema. Súa rede vai ser constantemente información sobre o traballo de streaming para o equipo varios traballadores frustrante que son dong seu traballo do día a día. Tamén vai poñer máis presión sobre o seu traballo como servidor de procesamento que ten que repartir lotes e lotes de pequenas pezas de traballo nunha base regular. Por fin, nesta situación, o seu servidor de emprego descende vai crear un rexistro de volta enorme de traballo incompleto mentres traballos maiores podería de procesamento continuou alegremente inconscientes de que o servidor estaba pasando por dificultades de emprego.

En realidade, non haberá unha configuración ideal para a súa instalación da reixa, moi depende dos recursos dispoñibles, tipo de traballo, requisitos do traballo tempo de produción, capacidade de rede, e así por diante. Con todo, algunhas directrices sería:

• Traballos en tamaño de xeito que cada traballador pode pasar por polo menos 3-4 emprego nun período de 15 horas (o máis longo período de tempo probable idle)
• Xoga co tamaño do traballo de xeito que o tempo de configuración tórnase bastante insignificante comparado co tempo de procesamento (tendo en conta o punto anterior).
• Se un traballo non é concluído en dobrar a cantidade de tempo (quizais menos) se espera para completa-lo asumir que a súa AWOL ir e comezar a proceso-lo con outro traballador. Isto significa que pode ter que esperar ata tres veces a lonxitude normal de un traballo para a conclusión (posiblemente máis o traballo posterior falla). Pode querer reducir este tempo, pero Tomé coidado para non reduci-lo moito como podes comezar a duplicación de tarefas de procesamento nunha base regular.
• Jobs debe ser independente das esixencias externas, na medida do posible. O servidor de emprego, por exemplo, só debe atoparse no inicio e final de cada traballo.
• Non saturar a súa rede, este terá dous efectos negativos, o seu equipo vai atopar durante o día a través da rede frustrante e os problemas poden ser probados con conexións tempo de espera dun problema que só vai peor cando escalar a reixa.
• Garantir os postos de traballo poden ser executados nos seus traballadores. Os traballos fanse moito espazo de memoria traballos intensivos ou intensivos disco comeza a abortar eo único que notará é unha gota 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 dormente por algún tempo.

Cando os resultados son presentados asegurar que o número de resultados coincide co número de rexistros dentro do traballo.

Como mencionado anteriormente, e non pode ser máis enfatizado, construír tolerancia a fallos na recuperación de traballos e presentación de resultados. Os traballadores poden (e seguramente) entrar no modo de suspensión no máis inconveniente de veces e iso debe ser servidos. Also once again abstracting away your results submission will help cater for future changes to your job control system much easier to deal with.

Resumo

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.

Next time

In part 3 we'll create our virtual processing machine and set up our windows machines to become idle-time workers.

Comentarios (3)

By Steven Lloyd Watkin , Friday 4th December 2009 11:03 pm

Introduction

I work in a company where we run many batch jobs processing millions of records of data each day and I've been thinking recently about all the machines that sit around each and every day doing nothing for several hours. Wouldn't it be good if we could use those machines to bolster the processing power of our systems? In this set of articles I'm going to look at the potential benefits of employing an office grid using virtualised environments.

In Part 4 we looked at using tools to ensure that we're running the latest version of the code and data sources so that obtained results are always up-to-date with the latest business information and logic.

Pre-Deployment

Before deploying your grid system if there's one thing you do and one thing alone it's benchmark your current system ! No matter what you tell colleagues about how much extra work your system is going to do unless you have numbers to back this up your guarantees are nothing. So,

• how many records can you process currently? Per Day? Per Hour?
• How long does it typically take to turn around a job?
• How much more capacity do you have?

There's also additional questions:

• If your processing server (or one of your processing servers) goes down how will this affect your capabilities, will you be crippled?
• What advantages do you hope/expect to get from a grid system?
• Are your office machines capable of running the jobs?
• Are your (or can you jobs be converted) to wrok in this style of running?

The last major point is to take your time on any major change like this. Update your processing code to work using the new methodology, benchmark again. Possibly set up your processing server to run a virtual machine, after all your processing server will just be another worker (just a very powerful one relatively). Allow the new process to settle.

Deployment

My suggestion would be to pop into the office one weekend perform all the installations and setup. Do this just before a fortnight's holiday and leave so other poor chap to deal with the consequences… maybe not…

Deployment for a system like this needs to be slow. Despite it being relatively simple to set up this system will affect your entire office infrastructure (well the digital one). Firstly, roll out to a couple of machines at a time, monitor network traffic, how the worker hosts perform on a day-to-day basis. You may need to alter your job configuration in response to your findings.

Once the system has settled with a few machines (lets say 10% of all office machines, ie 5) keep monitoring network traffic and host machine performance. Next benchmark again, you should now be processing 33% more jobs than your first benchmarks. Check this is so, or that you're at least in this ballpark. If not, investigate what is going on before moving on. Repeat this cycle until you happily have all office machines running without killing individual machine performance or grinding your network to a standstill.

At all times keep benchmarking, even after all deployments are made. Check how new code updates affect speed of your system, check all workers are reporting in and processing jobs. Slowly (very slowly) increment your job configuration to get the best from your workers and network.

Stop!

What if you want to stop your workers from running at some time? They are all out there running, regenerating, and trying their best to process data like hungry insects. The answer may seem obvious but its worth adding just in case its overlooked. Simply edit your processing script with an exit(0) or die() or some other statement to kill your processing job. An important reason why we always try to update to the latest processing script before any run!

Demonstration System

In order to write this set of short articles I created a very small grid to demonstrate the technologies and methodologies. I read lots of articles, tutorials, and used various tools to setup and monitor what was going on. By no means have I gone out and saturated a whole office with traffic and nor have I had access to a regular staff members PC to see how host performance was affected.

My demonstration system was very humble indeed. I used my regular desktop set up as a job control server. On this I had installed mySQL server installed set up as a master in replication, PHP , and SVN linked through apache (for access via worker VM).

I then created a centOS worker machine on VirtualBox on a 6 year old windows XP laptop. I setup scheduled tasks as specified after copying the VM onto the machine and let it go.

The virtual machine was set up with PHP, subversion, and mySQL. I checked out a branch named 'worker' from my job control servers repository and made sure it could be updated using 'svn update'. Next I setup mySQL as a slave and checked that data was replicating from mySQL on the job control server down to the worker VM. After all this I setup the bash script and the cron job.

My processing script basically went along the lines of this (very simple stuff):

• Read in the name field
• Counted the number of similar names in a table from the data source held on the VM
• Counted the number of names as above but splitting the name by spaces (ie forename, middle, surname)
• Repeated this process 1,000 times

Each job took approximately 20 minutes to run. At one point I opened several copies of the worker VM on the windows laptop and watched the jobs be checked off by each of the worker IP addresses. At this point I also confirmed that replication automatically restarted.

Leaving the laptop to idle resulted in a worker starting to process jobs from the job control server. When resuming laptop usage there was a delay of about 30-60 seconds, this is a fair amount of time and staff would need to be made aware that their machine may pause for a short while when returning to the machine. Newer machines may not have a pause of this long. The benefit of the amount of processing performed by these machines during idle periods would more that outweigh staff members having to wait a short period (say 1 minute) on arriving at their machines of a morning (I frequently wait longer that this for a Windows Defender update to take place) provided they were made aware of this (useful time to grab a morning coffee!).

Overall I feel confident that I have demonstrated the technologies that could be used to create such a system. I have shown that such a system does work on a (very) small scale and with some more experimenting could be scaled up utilise the resources of an office's machines. If I don't get to the point of doing this I would be very interested to know/see when someone else does.

Conclusions / Evaluation

The next obvious step would be to actually get a real world example and start to deploy a system such as this within an office environment and see what happens. Asking a business to commit to this without a trail blazing company to prove the technology and effectiveness may be a little difficult. Grid/Distributed computing is very popular is some circles and has some large applications (BIONC, SETI@Home, Folding@Home, etc). I did not, however, find a smaller scale and simple system like this in my searches that could be rolled out within an office environment.

I created a basically free system using mostly open source software and tools available in almost any office. The technologies were basically demonstrated and show to perform and work as expected. Hopefully I have show that with not much work and with a very simple setup you can deploy an office grid computing system that is powerful, cheap, and scalable all at the same time.

Once a system is up and running there is almost no end to the amount of customisation and improvements you can make. For example statistics / benchmarking can easily be added showing the worth of such a system every day. New machines can be added quickly and easily as and when they arrive with upgrades to existing hardware bolstering your processing power.

I hope you've enjoyed reading this series of articles and its given you food for thought on running an office grid system. The solution presented here won't necessarily work in all situations but should be adaptable to allow you to get your data processing done using your own solution.

Please feel free to send me any comments, corrections, or improvements and I'll do my best to keep this article updated to match.

Comentarios (3)

By Steven Lloyd Watkin , Saturday 28th November 2009 10:42 pm

My employer recently paid for a group of us developers to take the Zend Framework: Fundamentals course, here I'll summarise my thoughts and opinions on the course for others. For those looking to save time, here's my summary:

For developers who haven't had time to look at the Zend Framework this course (Zend Framework: Fundamentals) offers a good overall picture of the framework introducing you to the key areas and giving enough information in order to continue. For those who have spent time looking at the framework and have followed one or two tutorials this course does not offer much beyond.

Fondo

I've been a PHP developer for around 5-6 years, and have started working with the Zend Framework on a component basis over the last 6 months. I've developed and/or been a developer on a couple of small Zend Framework MVC sites. I'll be honest, I haven't had a huge amount of exposure to other frameworks from a coding point of view but have spent several hours researching the project websites and evaluating them. The framework and the community surrounding Zend Framework it is quite exciting and there seem to be huge possibilities in where its going.

About the Course

The course is delivered over 9 two hour webex sessions (with a 10-minute break in the middle). The time is spent going through a set of slides provided by Zend with discussion at any time. You can use a microphone to talk to the instructor, but to be honest I didn't see anyone use anything more than the chat window. In addition a VMWare Ubuntu machine is provided that has example code and projects set up an a trial version of Zend Studio. The course leader talks to attendees either over an integrated VoIP solution, or you can dial in using one of the many worldwide dial in numbers.

During the course the material consists of a brief overview of the Framework and the MVC pattern before heading into a sample guestbook application. The discussion demonstrated bootstrapping, Zend_Application, Db Tables, Database access, Forms, Filtering, ACL, Validating, etc, etc. Basically covering all the topics you'd require to get a basic site up an running all the time giving you the tools to go and get more advanced in the framework (although this did amount to 'See the website' much of the time).

Time is given to code up some examples, and to develop the 'guestbook' and simple 'wiki' application. Personally I felt that providing the code or each app and then asking us to develop what was essentially a copy alongside didn't really provide a good learning experience. I would have preferred to develop an application similar, but not identical. to the example application with the benefit of having a guide to refer to. Alternatively building the applications from scratch with the demonstrator would of possibly led to more questions about why and how , thus giving a better understanding of the framework, after all you can look up specifics after the course.

The last lecture consisted of working on the wiki application with help/guidance from the instructor. After the course feedback was taken, it was emphasised several times through the course that Zend takes feedback very seriously, in fact apparently our version of the course was quite new. Some of the other developers in the company will be taking the course soon so it will be interesting to see if this has happened.

The course style was informal, allowed for feedback and collaboration between attendees and the instructor. The course leader was friendly, approachable (email addresses were shared for questions), and whilst his presentation from the slides was a bit shaky seemed fully competent in the framework. He was clearly someone who used the framework on a regular basis rather than someone who is taught to teach the course, I liked the 'real world' experience in that respect.

Overall Feeling

In some ways I found the course a waste of time, in others it was very handy. Hopefully I'll get my reasons across clearly, and maybe provide some food for thought or useful feedback (knowing me this is unlikely!).

For myself this course was aimed at too low a level. Having gone through the quickstart guide, read Rob Allen's Zend Framework in Action, and worked with the framework a little I didn't really get anything too much. I would of liked the course to pick up from the end of the quickstart and develop additional skills.

That said, the course title does clearly state “Zend Framework: Fundamentals ” and in that aspect the course achieves what it sets out to do. Other members of the development team that haven't spent the time looking into the framework finished each session with enthusiasm and asked questions which was really nice to see.

All was not lost, it was good to spend time confirming the basic details of the framework and get to ask a couple of questions in areas where I wasn't 100%. It was also time that I got to sit down each day and think about coding using the framework and future projects, something I wouldn't of been able to do otherwise (can you imagine your company agreeing to that? :) ). Last but not least you also get a nice certificate from Zend to say that you attended the course (albeit by email).

Zend Framework Certification

This was one question that kept coming to mind during the course, would it prepare me for the certification? The quick, easy is a resounding No . The course instructor was quite clear on that with the additional advice that for the certification you should really be using the framework on a day to day basis and feel very comfortable and confident in its usage and methodologies.

Resumo

Given everything I've written above, I'll summarise everything in two easy bullet points:

• New to Zend Framework: This course does exactly what you'd expect, it gives you a nice introduction to the framework and a good grounding on the basics from which you can build. The course seems to generate interest and enthusiasm for the framework amongst developers.
• Used the Zend Framework: While it was nice to shore up some of the very basics I felt the time, effort, and funds to take the course could of been better spent elsewhere. It will be nice to see Zend create a new higher level course to take developers to the next level – at least to the standard of certification and beyond. For that I would sign up immediately.

Comentarios (0)

By Steven Lloyd Watkin , Sunday 11th October 2009 6:09 pm

If you've recently upgraded PHP or Apache you maybe coming up against the issue of your webserver returning blank pages, and throwing error messages into your logs with no idea why, here's one possible way to fix it…

I've had this problem a couple of times recently after upgrading Apache or PHP on a virtual machine. The first time I noticed the error I simply reverted to a backup of my VM but the second time I realised I'd have to look into the issue.

The first time I noticed the issue some of my web pages were being served as blank files while the others worked absolutely fine. After some investigation I noted that apache was writing out to /var/log/http/error_log with the following message repeatidly:

[notice] child pid XXXX exit signal Segmentation fault (11)

There's not allot to go by on-line, and most of the pages about it trail off to nothing. That said, I narrowed down the issue to PHP crashing when trying to unneeded dynamic libraries.

Looking at my php.ini (/etc/php.ini) I commented out all of the dynamic libraries loaded planning on commenting them back in as required. The two I had to take out where pdo.so and mysql .so .

Once these were removed all my web pages were being served fine, just as before the PHP/Apache update.