Oficina de Grid Computing utilitzant entorns virtuals - Part 4
Comentaris (2) Introducció
Jo treballo en una empresa on ens trobem molts llocs de treball de processament per lots de milions de registres de dades cada dia i he estat pensant recentment sobre totes les màquines que se sentin al voltant de cada dia sense fer res durant diverses hores. No seria bo si poguéssim utilitzar aquestes màquines per reforçar la capacitat de processament dels nostres sistemes? En aquest conjunt d'articles que vaig a veure els beneficis potencials de l'ocupació d'una oficina de la xarxa utilitzant entorns virtualitzats.
A la part 3 que hem creat la nostra màquina de processament virtual i configurar màquines de les finestres per esdevenir treballadors a temps d'inactivitat.
Executar l'últim codi
Inevitablement, després de crear la lògica empresarial els treballadors canviarà, els insectes es troba, el codi més ràpid i eficient es produeix el que deixa als seus treballadors es van asseure al voltant de processament de dades mitjançant codi de olorós vell . Llavors, com ens assegurem que sempre estem usant la versió més recent i més gran dels nostres scripts de processament?
Hi ha unes quantes formes senzilles molt fàcil que podríem fer això, el truc, però, és reduir la potència de processament i tràfic de la xarxa per aconseguir això. Anem a començar amb el més simple de les solucions i millorar a poc a poc durant un parell d'iteracions.
El primer mètode seria simplement connectar al nostre servidor de control de treball (a través de samba, FTP, o similar) i baixar l'última versió del codi. No és molt eficient, però farà el treball. Millorarem en això una mica, què hi ha de la creació d'un script de rsync i l'ús que cada vegada que en el seu lloc? D'altra banda què hi ha de posar la nostra última seqüència de comandaments de transformació en la subversió revisant el codi al principi i després només l'actualització del nostre codi en cada cursa ( svn update )?
Al final, podria acabar amb un script bash (anomenat per cron cada 10 minuts), que sembla tan simple com això:
#! / Bin / sh si ps ax | grep-v grep | grep php > / dev / null llavors echo "El treball s'està processant, la sortida" més echo "El treball no s'executa, comença ara" cd / camí / a / treball / còpia svn update php yourJobProcessingScript.php fil
Ara podem estar segurs que amb cada carrera que definitivament estem executant el codi més recent. Estem garantint la present mitjançant l'actualització de la nostra base de codi de temps tots i cadascun portem a terme una carrera i la reducció de trànsit de la xarxa transferint únicament les diferències d'arxius a través de la nostra xarxa.
En la meva configuració de demostració, ho vaig fer exactament com abans. Subversion s'ha instal · lat en el meu servidor de processament de la tasca i simplement va treure l'última versió del codi d'un "treballador" Poder utilitzar 'svn update'. També he afegit una etiqueta de nombre de versió del meu script de transformació que va ser retornat a la base de dades com a part de la devolució de resultats. D'aquesta manera vaig poder veure que el meu codi s'actualitza cada vegada que he copiat el meu tronc en la branca dels treballadors, és a dir que jo estava definitivament d'executar la seqüència de processament més avançada.
Utilitzant les últimes dades
Si el processament de la tasca fa ús de les fonts de dades a continuació, en algun moment aquests seran actualitzat també. A menys que vostè truqui a les seves fonts de dades sobre una base molt poc freqüent que va a inundar la xarxa amb el trànsit tan aviat com els treballadors començaran a portar tot a un punt mort. Per a mi solució, vaig decidir que m'agradaria moure les meves fonts de dades amb els meus màquines virtuals.
Mantingui ets cavalls allà, què passa si les meves fonts d'informació són enormes? Bé, això realment és un cas de quantitat de dades que estem parlant? Pot ser més rendible instal · lar una addicional en el disc dur de major capacitat en cada màquina de comprar un servidor de processament addicional. Es tracta d'una qüestió de pressupost i correspon a l'empresa per decidir. És potser que les seves fonts de dades són tan grans que és només factible per mantenir aquesta quantitat de dades en les màquines dels seus treballadors. En aquest cas, què faries? Bé podríem considerar trucar a un servidor de dades local, però això podria causar problemes a la xarxa. En aquest cas un sistema de reixeta tal com això pot arribar a ser poc realista per incloure en el seu entorn d'oficina. També pot ser que vostè pot mirar en altres estratègies d'execució, per exemple, només trucar als seus treballadors 8 p.m.-06 a.m. cada nit i / o de limitació de les sol · licituds d'origen de dades.
Passant diguem que les nostres dades la quantitat de fonts de 100 Gb de dades. Bé, sí que és una mica de les dades per moure per la xarxa en una actualització. Com ens assegurem que tenim l'última còpia de les dades en aquest cas? Rsync és una possibilitat, però personalment crec que mitjançant l'execució de la seva última font de dades al servidor de processament de la tasca i configurar-lo com un mestre en la replicació (amb un registre de bin ben llarga) podria ser el camí a seguir:
En establir cadascun dels seus treballadors com un esclau de les actualitzacions del servidor de control de treball a les seves fonts de dades tinguin un efecte positiu molt bé als seus treballadors sense un gran augment en l'activitat de xarxa (és a dir, a menys que realitzi una actualització de dades enormes i tots els treballadors entren en joc alhora). Això té avantatges respecte a rsync en què no s'obtindria d'una llarga pausa abans de cada treball, com les actualitzacions de base de dades, el mysql dimoni en el seu treball contínuament actualitzar les seves dades, mentre que el procés continua.
Així és com puc configurar el meu servidor de demostració. Per configurar la replicació He seguit la guia en el lloc de MySQL ( Configuració de la replicació ) i en 20 minuts vaig tenir al meu treballador inital replicar el treball de control de servidors de conjunt de dades. Per cada treballador addicional dels paràmetres de replicació i el procés de treball cada vegada que la màquina virtual s'ha copiat.
Resum
En aquesta secció de l'article, hem vist el fàcil i indolor que és mantenir el codi de processament fins avui per rsync using o subverion (SVN) per fer la feina i reduir el tràfic de xarxa en la mateixa time. També parlem sobre la forma per mantenir la seva informació de la font de dades posada al dia pel que li arribin a cadascun dels seus treballadors. Així, la zona assegurant que complim amb la lògica de negoci i la informació al nostre sistema de xarxa de l'oficina. Hi haurà, òbviament, hi ha diverses alternatives per realitzar aquestes tasques, però aquí són dos exemples simples per demostrar com és fàcil és una solució d'aconseguir.
La propera vegada
A la part final d'aquesta sèrie, ben anomenada la part 5 , anem a parlar de la implementació d'aquest sistema. Vaig a resumir el que s'ha après i el que he aconseguit crear.
Articles , Informàtica , Computació Grid , Linux , PHP , Programació Web | 
actualitzar
