Kommentarer (2)

Genom att Steven Lloyd Watkin , fredag ​​4 dec 2009 11:59

Införandet

Jag arbetar i ett företag där vi köra många batchjobb behandla miljontals skivor av data varje dag och jag har funderat nyligen om alla de maskiner som sitter runt varje dag gör ingenting i flera timmar. Skulle det inte vara bra om vi kunde använda dessa maskiner för att stärka processorkraften i våra system? I denna uppsättning artiklar jag kommer att titta på de potentiella fördelarna med att anställa ett kontor galler med virtualiserade miljöer.

I del 3 har vi skapat vår virtuella maskin och konfigurera Windows maskiner för att bli idle deltidsarbetande.

Köra den senaste koden

Oundvikligen har skapat dina anställda affärslogik kommer att förändras, kommer buggar hittas kommer snabbare och mer effektiv kod produceras vilket lämnar dina arbetare satt runt bearbeta data med hjälp av gamla illaluktande kod . Hur då ser vi till att vi alltid du använder den senaste och bästa versionen av våra bearbetning skript?

Det finns några mycket enkla enkla sätt vi kunde göra detta, tricket är dock att minska processorkraft och nätverkstrafik för att uppnå detta. Låt oss börja med den enklaste av lösningar och förbättra den långsamt under ett par iterationer.

Den första metoden skulle vara att helt enkelt ansluta till vårt jobb styrning server (via samba, FTP, eller liknande) och dra ner den senaste versionen av koden. Inte mycket effektiv, men det kommer att göra jobbet. Låt oss öka på den något, vad sägs om att skapa en rsync manus och använda det varje gång istället? Alternativt kan det om att sätta vår senaste bearbetning skriptet i subversion kolla koden initialt och sedan bara uppdatera vår kod på varje körning ( svn update )?

Till slut kunde vi sluta med en bash skript (kallas av cron var 10 minuter) som ser så enkelt så här:

  #! / Bin / sh
 om PS AX | grep-v grep | grep php > / dev / null
 därefter
     echo "Job närvarande bearbetar, avfart"
 annars
     echo "Job inte körs, starta nu"
     cd / sökväg / till / arbetar / kopiering
     svn uppdatering
     php yourJobProcessingScript.php
 fi 

Nu kan vi vara säkra på att för varje gång vi definitivt kör den senaste koden. Vi säkerställer detta genom att uppdatera vår kodbas varje gång vi gör en körning och minska nätverkstrafiken genom att endast överföra filer skillnaderna mellan vårt nätverk.

I min demonstration Setup gjorde jag precis som ovan. Subversion installerades på mitt jobb behandling server och jag helt enkelt drog senaste koden från en arbetstagare filial med hjälp av "svn update '. Jag lade också till en tagg versionsnummer till min behandling manus som återvände till databasen som en del av resultaten avkastning. På så sätt kunde jag se att min kod var att uppdateras varje gång jag kopierade min stammen till den anställde grenen, dvs att jag var definitivt kör den senaste bearbetningen skriptet.

Med de senaste uppgifterna

Om ditt jobb bearbetning utnyttjar datakällor därefter vid någon tidpunkt dessa kommer att uppdateras också. Om du ringa dina datakällor på ett mycket ovanligt basis du kommer att översvämma ditt nätverk med trafik så snart som dina anställda börjar köra föra allt till ett stillastående. För min lösning jag bestämde att jag vill flytta mina datakällor runt med mina virtuella maskiner.

Håll du hästar där! Vad händer om jag datakällor är enorma? Ja detta är verkligen ett fall av hur mycket data vi talar? Det kan vara mer kostnadseffektivt att installera en extra större hårddisk i varje maskin än att köpa en ytterligare bearbetning server. Detta är en fråga om budget och är upp till verksamheten att avgöra. Det kanske att dina datakällor är så stora att det bara omöjligt att hålla den mängd data i din arbetsdatorer. I så fall vad skulle du göra? Jo vi kunde se på att ringa en lokal dataserver, men detta kan orsaka problem med nätverket. I detta fall ett rutnät system som detta kan bli orealistiskt att inkludera i din kontorsmiljö. Det kan också vara så att du kan titta på alternativa kör strategier, till exempel endast ringa dina arbetare från 20:00 till 06:00 varje kväll och / eller strypning dataförfrågningar källa.

Flytta på låt säga vår datakällor uppgår till 100 GB data. Jo det är en hel del uppgifter att röra sig nätverket på en uppdatering. Hur skulle vi se till att vi har den senaste versionen av data i detta fall? Rsync är en möjlighet, men personligen tycker jag genom att köra din senaste datakällan på ditt jobb behandling server och ställa upp detta som en mästare i replikering (med en fin lång bin log) kan vara vägen att gå:

Genom att ställa alla dina anställda upp som en slav till servern jobb kontroll uppdateringar till dina datakällor kommer sippra ned fint för de anställda utan en enorm ökning av aktiviteten inom nätverket (dvs om du gör en enorm uppgifter uppdateringen och alla dina anställda sparka in på en gång). Detta har fördelar jämfört med rsync i att du inte skulle få en lång paus före varje jobb, som databasuppdateringar den MySQL kommer demonen på din arbetstagaren kontinuerligt uppdatera sina data medan behandlingen fortsätter.

Detta är hur jag in min demonstration server. För att ställa in replikering jag följde guiden på mySQL platsen ( Upprättande replikering ) och inom 20 minuter hade jag min initial arbetstagaren replikera kontroll över arbetet servrar dataset. För varje ytterligare arbetstagare replikering inställningar och process fungerade varje gång när VM kopierades.

Sammanfattning

I detta avsnitt av artikeln har vi tittat på hur enkelt och smärtfritt det är att hålla din processkod uppdaterad med using rsync eller subverion (SVN) att göra arbetet och minska nätverkstrafiken på samma time. Vi diskuterade också hur att hålla din information om datakällan up-to-date genom att låta den sippra ner till alla dina anställda. Således har vi området se till att vi håller jämna steg med affärslogik och information i vårt kontor bärverk. Det kommer naturligtvis att vara otaliga alternativ till att utföra dessa uppgifter, men här fanns två enkla exempel för att visa hur lätt en lösning är att komma med.

Nästa gång

I den sista delen av denna serie, passande namnet del 5 , kommer vi att diskutera utbyggnaden av detta system. Jag sammanfattar vad som har lärt sig och vad jag lyckats skapa.

Kommentarer (1)

Genom att Steven Lloyd Watkin , fredag ​​4 dec 2009 11:23

Införandet

Jag arbetar i ett företag där vi köra många batchjobb behandla miljontals skivor av data varje dag och jag har funderat nyligen om alla de maskiner som sitter runt varje dag gör ingenting i flera timmar. Skulle det inte vara bra om vi kunde använda dessa maskiner för att stärka processorkraften i våra system? I denna uppsättning artiklar jag kommer att titta på de potentiella fördelarna med att anställa ett kontor galler med virtualiserade miljöer.

Som en PHP utvecklare jag kommer att använda verktyg som jag använder varje dag, nämligen Linux, mySQL , PHP, VirtualBox och Subversion (SVN). Men jag hoppas att denna guide kommer anpassa sig till andra språk och tekniker lika bra.

Lösningen ger jag kommer att vara mycket löst baserad på den typ av behandling vi skulle behöver för att uppnå men detta kanske inte är sant genom hela artikeln som jag kommer att ändra saker och ting för enkelhetens skull, eller för att producera mer intressanta användning scenarier.

Dessa virtualiserade miljöer kommer att köras på Windows-maskiner eftersom det är vad majoriteten av kontor köras. De behandlingar som den kontorsmaskiner inte ska störa personalen att använda dessa maskiner bör kräver inget underhåll på maskinen och vara lätt att sättas på nya maskiner när de blir tillgängliga. Dessutom bör nya virtuella maskiner kräver ingen ytterligare konfiguration eftersom det kraftigt minskar skalbarhet och lätthet med vilken nätet kan förlängas.

Varför Distribuera ett Office Computing Grid?

Först kanske du tänker, varför inte bara använda en resurs cloud computing som Amazons EC2-plattform ? Väl anledningarna kan vara flera, till exempel:

• Du kommer inte överlåta vissa uppgifter till ett moln datormiljö
• Du kan inte ställa vissa data i ett cloud computing miljö för juridiska skäl (t.ex. uppgifter att lämna landet), eventuellt av juridiska skäl, t.ex. NHS poster.
• Du vill behålla dina processenheter stänga och har full kontroll över hårdvaran för
• Du har inte projektmedel för att köra moln instanser
• Ditt kontor har inte en anslutning till Internet och därför det är inte möjligt att använda ett moln resurs
• Du gillar inte regn, moln föreslår regn, därför du håller borta

Jag är säker på listan skulle kunna fortsätta, men jag tror det räcker för nu.

Fördelar med ett Office Computing Grid

Tja, kan göra några matte (och i sann fysik stil kan göra några svepande antaganden). Tänk dig att du har stora biffiga bearbetning server som kör 100 jobb per dag. På kontoret har du 50 maskiner som är tomgång 16 timmar om dagen, är vart och ett av dessa maskiner 10% så kraftfull som din biffiga behandling Sever. (Alla resultat här är rundade underskatta prestandaökning).

Så 1 maskin * 10% effekt * 2/3 tid = 0,067 dvs 1 skrivbordet bearbetning i viloläge tiden kunde bearbeta 6 fulla jobb per dag.

Om du nu skala upp detta tar det 15 lediga skrivbord för att bearbeta så många jobb per dag som din huvudsakliga behandlingen server gör.

Så i vårt låtsas kontor 50 maskiner vi kunde öka vår processorkraft från 1 server upp till 4 fulla bearbetning servrar, eller vi kan behandla 400 jobb per dag istället för 100.

Lägg märke till att inga investeringar i ny hårdvara företaget har just ökat sin batch-bearbetning kapacitet 4 gånger! Potentiellt du kommer att öka din elförbrukning utan från de flesta kontorsmiljöer Jag har varit i maskiner i allmänhet kvar på natten ändå, så du kan se detta som en grön initiativ.

Andra fördelar innebär också att investeringar i nya (eller uppdaterad) bearbetning servrar kan fördröjas om dina kontorsmaskiner är tillräckliga och att när du förbättrar kraften i dina kontorsmaskiner kontoret nätet blir mer kraftfull automatiskt.

Technologies

Vad du behöver? (Eller mer korrekt vad gjorde jag använder):

• Idle kontorsmaskiner (i mitt fall en extra gammalt Windows XP laptop)
• VirtualBox (eller en annan virtualisering klientprogram)
• En virtuell maskin med PHP, MySQL running kör en skära ner OS, jag ringer dessa mina Limp servrar :)
• Jobb för att köra
• Job server (kan vara en annan virtuell maskin någonstans)

Typiska jobb

De typer av jobb som detta system är konstruerat att köras är följande:

• Systemet får en förteckning över uppgifter på vilka vi måste matcha och ger resultat
• Matchande innebär kontroll / söka flera (ganska statisk) datakällor
• Resultat från datakällor kan kräva ytterligare validering, sammanslagning, kontroll av ytterligare datakällor som svar till resultat
• Data tillbaka med matchande poster som är fullt validerade och bearbetas
• Varje post inom ett jobb är oberoende av de övriga

Så i princip vi tittar på kör jobb som kräver en blandning av databas uppslagningar och några siffertuggande, en ganska typiskt scenario i en företagsmiljö.

Grid lösningar är inte bara fördelaktigt för behandling av arbeten av denna typ. I princip kan varje process som kan delas upp i självständiga enheter köras parallellt. Se denna Wikipedia för exempel och mer information: Grid Computing , men ett par kända exempel är Seti @ Home och BIONC . Det finns ramar för att köra datorer galler, och dessa är väl värda att titta närmare på.

Vad ska vi uppnå?

Vid slutet av dessa artiklar hoppas jag att visa att distribuera ett kontor nätet behöver inte vara enormt dyrt eller tidskrävande. Jag kommer att diskutera:

• Koppla in systemet kontroll över arbetet, jobbet konfiguration
• Skapa en lämplig behandling virtuell maskin
• Hur man ställer in systemet på en Windows-dator
• Se till att du använder den senaste koden och data
• Deployment och benchmarking
• Blickar framåt

Jag är huset (ok jag byggde, så skrev) ett exempel för att testa begreppen på en lokal dator med Windows XP och min "GridMachine" virtuell maskin. Mitt jobb kontrollen servern kommer att vara min huvudsakliga dator som kör Fedora 11 .

Detta är inte på något sätt tänkt att visa en fullt fungerande robust system, innebar det mer av en demonstration och diskutera visar att dessa saker kan uppnås på ett relativt kort tid och till låg kostnad. Du får gärna skicka mig kommentarer, korrigeringar eller förbättringar och jag kommer göra mitt bästa för att hålla den här artikeln uppdateras för att matcha.

Nästa gång

I del 2 kommer jag börja med att titta på jobbet styrsystemet, och se i hur arbete ska konfigureras för att uppnå största möjliga behandling och samtidigt säkerställa att varje jobb behandlas utan att misslyckas.

Kommentarer (1)

Genom att Steven Lloyd Watkin , fredag ​​4 dec 2009 11:23

Införandet

Jag arbetar i ett företag där vi köra många batchjobb behandla miljontals skivor av data varje dag och jag har funderat nyligen om alla de maskiner som sitter runt varje dag gör ingenting i flera timmar. Skulle det inte vara bra om vi kunde använda dessa maskiner för att stärka processorkraften i våra system? I denna uppsättning artiklar jag kommer att titta på de potentiella fördelarna med att anställa ett kontor galler med virtualiserade miljöer.

I del 1 gav jag en översikt av systemet och teknik jag kommer att använda, liksom diskuterat några av de potentiella orsakerna till varför du skulle vilja skapa ett kontor nätet.

Job Kontroll

Om du ska vara igång jobb då du kommer att behöva något sätt att hantera dem. Ditt jobb styrsystem (på jobbet server) måste vara riktigt väl genomtänkt innan man ens försöker köra ett Office-nätet. Så det första, vad är uppgifter för ett jobb styrsystem:

• Dela ut jobb på begäran från arbetare
• Berätta arbetare vilken typ av jobb för att köra
• Spår jobb
• Se till att jobb bara körs en gång
• Ge jobbdata för arbetstagare, eller åtminstone berätta för dem var att få det

The system also needs to be extensible, a solution that works for now in a single case may be extended to run several types of jobs as the business sees the worth in a grid solution. For example, jobs may gain priorities, more than one job type may exist (ie several code bases), eventually you may even run several different worker machines that are optimised for each type of job (although that does move away from the 'generic worker' idea). Always try to think about the future when developing systems, a short term vision can lead to longer term frustration and increased development time.

Job Server

We're going to need somewhere to control our jobs from, this should be the only system in your grid that has a fixed resource locator, be that an IP address, host name, URL (using internal DNS), etc. This is because the workers need to know where to look for jobs, workers need to find the job control system (not the job control system find the workers).

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: När började arbetaren starta jobbet? 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

Som nämnts tidigare kommer de anställda att göra vårt jobb ledningen för oss nu, så allt vi behöver för att verkligen göra är att hitta ett jobb som kräver behandling och få information. How would we do this? Well pick our job selection criteria and look for jobs, in SQL I did the following:

1. 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__; 

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 `jobb` WHERE `started_by` = __ ME__ GRÄNS 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. 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.

As stated previously, and can not be over emphasised, build fault tolerance into job retrieval and results submission. The workers can (and most likely will) go into suspend mode at the most inconvenient of times and this needs to be catered for. Also once again abstracting away your results submission will help cater for future changes to your job control system much easier to deal with.

Sammanfattning

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.

Kommentarer (3)

Genom att Steven Lloyd Watkin , fredag ​​4 dec 2009 11:03

Införandet

Jag arbetar i ett företag där vi köra många batchjobb behandla miljontals skivor av data varje dag och jag har funderat nyligen om alla de maskiner som sitter runt varje dag gör ingenting i flera timmar. Skulle det inte vara bra om vi kunde använda dessa maskiner för att stärka processorkraften i våra system? I denna uppsättning artiklar jag kommer att titta på de potentiella fördelarna med att anställa ett kontor galler med virtualiserade miljöer.

I del 4 har vi tittat på att använda verktyg för att säkerställa att vi kör den senaste versionen av kod och data källor så att resultaten alltid up-to-date med den senaste affärsinformation och logik.

Pre-Deployment

Innan du distribuerar ditt nätet om det är en sak du gör och en sak bara det är riktmärken ditt nuvarande system! Oavsett vad du säger dina kolleger om hur mycket extra arbete ditt system kommer att göra om du inte har nummer för att backa upp dina garantier är ingenting. Så,

• hur många poster kan du bearbeta just nu? Per dag? Per timme?
• Hur lång tid tar det normalt att vända ett jobb?
• Hur mycket mer kapacitet har du?

Det finns också ytterligare frågor:

• Om din behandling server (eller en av dina bearbetning servrar) går ner hur kommer detta att påverka dina möjligheter, kommer du att handikappade?
• Vilka fördelar hoppas du / räkna med att få från ett rutnät system?
• Är dina kontorsmaskiner kan köra jobb?
• Är din (eller kan du jobb omvandlas) till wrok i denna stil att köra?

Den sista viktiga punkten är att ta din tid på någon större förändring så här. Uppdatera din processkod att arbeta med den nya metoden, riktmärke igen. Möjligen ställa in din behandling server att köra en virtuell maskin, efter alla dina behandling servern kommer bara att vara en annan arbetare (bara en mycket kraftfull en relativt). Låt den nya processen att lösa.

Deployment

Mitt förslag skulle vara att titta in på kontoret en helg utföra alla installationer och installation. Gör detta precis innan en fjorton dagars semester och lämnar så att andra fattiga kap att ta itu med konsekvenserna ... kanske inte ...

Deployment för ett system som detta måste vara långsam. Trots att det är relativt enkelt att ställa in detta system kommer att påverka hela ditt kontor infrastruktur (såväl den digitala ett). För det första, rulla ut till ett par av maskiner åt gången, bildskärm nätverkstrafik, hur arbetstagare värdarna utföra på en dag till dag. Du kan behöva ändra ditt jobb konfiguration som svar på dina resultat.

När systemet har satt sig med några maskiner (låt säga 10% av alla kontorsmaskiner, dvs 5) Håll trafikövervakning nätverk och värddatorn performance. Nästa riktmärke igen bör du nu behandla 33% fler arbetstillfällen än dina första riktmärken. Kontrollera det är så, eller att du åtminstone i detta Ballpark. Om inte, undersöka vad som händer innan vi går vidare. Upprepa denna cykel tills du gärna har alla kontorsmaskiner igång utan att döda enskilda maskinens prestanda eller slipning ditt nätverk till ett stopp.

Alltid hålla benchmarking, även efter alla installationer görs. Kontrollera hur nya kod uppdateringar påverkar hastigheten på ditt system, kontrollera alla arbetstagare redovisning och bearbetning jobb. Långsamt (långsamt) stega ditt jobb konfiguration för att få ut det bästa av dina arbetare och nätverk.

Stopp!

Vad händer om du vill stoppa dina anställda från att köras någon gång? De är alla där ute som kör, regenerering, och försöker sitt bästa för att bearbeta data som hungriga insekter. Svaret kan tyckas självklart men värt att lägga i fall den förbises. Helt enkelt redigera din behandling manus med en exit (0) eller dör () eller någon annan förklaring till döda din behandling jobb. En viktig orsak till varför vi alltid försöker att uppdatera till den senaste bearbetningen manus innan loppet!

Demonstration System

För att skriva denna rad korta artiklar jag skapat en mycket liten galler att demonstrera teknik och metoder. Jag läste massor av artiklar, tutorials och använt olika verktyg för att ställa in och övervaka vad som pågick. På något sätt har jag gått ut och mättade en hel kontor med trafik och inte heller har jag haft tillgång till en ordinarie personal medlemmar PC för att se hur värden prestanda påverkades.

Min demonstration systemet var mycket ödmjuk faktiskt. Jag använde min vanliga skrivbordet inrättades som en kontroll över arbetet server. På denna hade jag installerat mySQL server installerad inrättades som en mästare i replikering, PHP , A och SVN länkade via apache (för åtkomst via arbetare VM).

Jag skapade sedan en CentOS arbetsdator på VirtualBox på en 6 år gammal Windows XP laptop. Jag ställa schemalagda uppgifter som anges efter att ha kopierat VM på maskinen och låt den gå.

Den virtuella maskinen sattes upp med PHP, subversion, och mySQL. Jag kollade ut en gren som heter "arbetstagare" från mitt jobb styrning servrar arkiv och såg till att det kan uppdateras med hjälp av "svn update '. Nästa Jag installation MySQL som en slav och kontroll av att data replikeras från MySQL på jobbet styrservern ner till arbetstagaren VM. Efter allt detta har jag ställa in bash script och cron-jobb.

Min bearbetning manus gick i stort sett i linje med detta (mycket enkla saker):

• Läs i namnfältet
• Räknade antal likadana namn i en tabell från datakällan hålls på VM
• Räknade antal namn som ovan men att dela upp namnet med mellanslag (dvs förnamn, mitten, efternamn)
• Upprepad denna process 1000 gånger

Varje jobb tog ungefär 20 minuter att köra. Vid ett tillfälle öppnade jag flera kopior av arbetstagaren VM på Windows laptop och såg de arbeten kontrolleras av var och en av adresserna arbetstagare IP. Här vill jag också bekräftat att replikering automatiskt startas om.

Lämna den bärbara datorn på tomgång resulterade i att arbetstagaren börjar bearbeta jobb från jobbet kontrollen servern. När återuppta laptop användning fanns en fördröjning på cirka 30-60 sekunder, är detta en hel del tid och personal skulle behöva vara medvetna om att deras maskin kan stanna en kort stund när de återvänder till maskinen. Nyare maskiner kan inte ha en paus på denna långa. Fördelen med den mängd som utförs av dessa maskiner under lediga perioder skulle mer än uppväga anställda tvungna att vänta en kort period (säg 1 minut) när de anländer till sina maskiner av en morgon (jag väntar ofta längre än detta för en Windows Defender uppdatera ske) förutsatt att de fick kännedom om detta (bra tid för att ta en morgonkaffe!).

Överlag är jag säker på att jag har visat den teknik som skulle kunna användas för att skapa ett sådant system. Jag har visat att ett sådant system fungerar på en (mycket) liten skala och med lite mer experimenterande kan skalas upp utnyttja resurserna i en kontorets maskiner. Om jag inte får till den punkt att göra detta skulle jag vara mycket intresserad av att veta / se när någon annan gör det.

Slutsatser / Utvärdering

Nästa självklara steg skulle vara att faktiskt få ett exempel från verkliga livet och börja distribuera ett system som detta inom en kontorsmiljö och se vad som händer. Att be ett företag att engagera sig i detta utan ett spår flammande företag att visa tekniken och effektivitet kan vara lite svårt. Grid / distributed computing är mycket populärt är vissa kretsar och har några stora program (BIONC, SETI @ Home, Folding @ Home, etc). Jag har dock inte hitta en mindre skala och enkelt system som detta i mina sökningar som kan rullas ut inom ett kontorsmiljö.

Jag skapade en i grunden gratis system använder mest öppen källkod och verktyg som finns i nästan alla kontor. Den teknik var grunden visat och visar att utföra och fungera som förväntat. Förhoppningsvis har jag visar att med inte mycket arbete och med en mycket enkel installation kan du distribuera en Office-systemet grid computing som är kraftfull, billig, A och skalbar alla på samma gång.

När ett system är igång det finns nästan ingen ände på hur mycket anpassning och förbättringar du kan göra. Till exempel statistik / benchmarking kan enkelt läggas visar värdet av ett sådant system varje dag. Nya maskiner kan läggas snabbt och enkelt och när de kommer med uppgraderingar till befintlig hårdvara stärka ditt processorkraft.

Jag hoppas du har haft att läsa denna serie av artiklar och gett dig en tankeställare om att köra en System Office nätet. Den lösning som presenteras här kommer inte nödvändigtvis fungerar i alla situationer men bör kunna anpassas så att du kan få din databehandling sker med din egen lösning.

Du får gärna skicka mig kommentarer, korrigeringar eller förbättringar och jag kommer göra mitt bästa för att hålla den här artikeln uppdateras för att matcha.

Kommentarer (3)

Genom att Steven Lloyd Watkin , lördag 28 november 2009 22:42

Min arbetsgivare har nyligen betalat för en grupp av oss utvecklare att ta Zend Framework: Fundamentals kurs, här ska jag sammanfatta mina tankar och åsikter om kursen för andra. För dem som vill spara tid, här är min sammanfattning:

För utvecklare som inte haft tid att titta på Zend Framework den här kursen (Zend Framework: Fundamentals) erbjuder en bra helhetsbild av regelverket introducera dig till de viktigaste områdena och ge tillräckligt med information för att kunna fortsätta. För dem som har tillbringat tid att titta på ramarna och har följt en eller två tutorials denna kurs inte ger mycket längre.

Bakgrund

Jag har varit en PHP- utvecklare för cirka 5-6 år, och har börjat arbeta med Zend Framework på en komponent bas under de senaste 6 månaderna. Jag har utvecklats och / eller varit en utvecklare på ett par små Zend Framework MVC sites. Jag ska vara ärlig har jag inte haft en enorm exponering för andra ramar från en kodning synvinkel men har tillbringat flera timmar forskar projektet webbplatser och utvärdera them. Ramverket och samhället som omger Zend Framework är det ganska spännande och det tycks finnas stora möjligheter där dess väg.

Om kursen

Kursen levereras över 9 två timmar WebEx sessioner (med en 10-minuters paus i mitten). Tiden ägnas åt att gå igenom ett antal diabilder som tillhandahålls av Zend med diskussion som helst. Du kan använda en mikrofon att prata med instruktören, men för att vara ärlig jag inte se någon använda något mer än chattfönstret. Dessutom en VMWare Ubuntu Maskinen är utrustad som har exempelkod och projekt inrätta en en testversion av Zend Studio. Kursledaren talar till deltagarna antingen över en integrerad VoIP lösning, eller så kan du ringa in med en av de många globala ratten i antal.

Under kursen materialet består av en kort översikt av ramprogrammet och MVC mönstret innan du beger dig in i ett prov gästbok ansökan. Diskussionen visade bootstrapping, Zend_Application, DB Tabeller, databasåtkomst, Forms, filtrering, ACL, värdesätta, etc, etc. I princip täcker alla de ämnen som du skulle behöver för att få en grundläggande webbplats upp en igång hela tiden ger dig verktyg för att gå och få mer avancerade i ramen (även om detta gjorde belopp till "Se webbplatsen" mycket av tiden).

Tid ges för att koda upp några exempel och att utveckla "gästbok" och enkel "Wiki" ansökan. Personligen kände jag att tillhandahållandet koden eller varje app och sedan ber oss att utveckla vad som var i grunden en kopia av sidan inte riktigt ge ett bra lärande. Jag skulle ha föredragit att utveckla ett program som liknar, men inte identiska. till exempel applicering med den fördelen att de har en guide för att hänvisa till. Alternativt kan bygga program från grunden med demonstrator vore kanske ledde till fler frågor om varför och hur, vilket ger en bättre förståelse av ramverket, efter allt du kan slå upp detaljerna efter kursen.

Den sista föreläsningen bestod av att arbeta på wikin ansökan med hjälp / vägledning från instruktören. Efter kursen återkoppling togs, var det betonas flera gånger genom den kurs som Zend tar återkoppling på stort allvar, i själva verket synes vår version av kursen var ganska ny. Några av de andra utvecklare i företaget kommer att ta kursen snart så det ska bli intressant att se om detta har hänt.

Kursen stil var informellt, tillåtet för feedback och samarbete mellan deltagare och instruktör. Kursledaren var vänlig, lättillgänglig (var e-postadresser delas för frågor), och medan hans presentation från bilder var lite skakig verkade fullt behörig i ramen. Han var klart någon som använde ram på en regelbunden basis snarare än någon som lärs ut att undervisa kursen gillade jag den "verkliga världen" erfarenhet i detta avseende.

Övergripande känsla

På sätt och vis hittade jag under ett slöseri med tid, i andra var det mycket praktiskt. Förhoppningsvis får jag mina skäl över tydligt, och kanske ge lite mat för tanke eller användbar feedback (veta mig är detta osannolikt!).

För mig denna kurs var att en alltför låg nivå. Efter att ha gått igenom i snabbstartguiden, läs Rob Allens Zend Framework in Action och arbetade med ramverket en lilla jag inte riktigt få något för mycket. Jag vore gillade naturligtvis att plocka upp från slutet av Snabbstart och utveckla nya färdigheter.

Som sagt, gör kurstiteln tydligt ange "Zend Framework: Fundamentals" och i den aspekten kursen uppnår vad den syftar till att göra. Övriga medlemmar i utvecklingsteamet som inte har tillbringat tid på att leta i ramen färdiga varje session med entusiasm och ställde frågor som verkligen var trevligt att se.

Allt var inte förlorat, det var bra att spendera tid bekräfta grundläggande information om ramarna och få ställa ett par frågor i områden där jag inte var 100%. Det var också dags att jag fick sitta ner varje dag och tycker om kodning med hjälp av ram och framtida projekt, något jag skulle inte kunnat göra på annat sätt (kan du föreställa dig ditt företag gå med på det? :)). Sist men inte minst får du också en fin intyg från Zend att säga att du deltagit i kursen (om än via e-post).

Zend Framework Certifiering

Detta var en fråga som fortsatte att komma att tänka på under kursen skulle förbereda mig för certifiering? Den snabba, lätt är ett rungande nej. Kursledaren var helt klar över att med ytterligare råd att för certifiering du verkligen ska använda ramarna för en daglig basis, och känner mig väldigt bekväm och säker i sin användning och metoder.

Sammanfattning

Med tanke på allt jag har skrivit ovan kommer jag att sammanfatta allt i två enkla punktlistor:

• Ny till Zend Framework: Denna kurs är precis vad du förväntar dig, det ger dig en fin introduktion till ram och en bra grund om grunderna som du kan bygga. 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.

Kommentarer (0)

Genom att Steven Lloyd Watkin , tisdag 14 april, 2009 21:06

Jag har lyckats få en webbplats igång med Zend Framework , allt loggar fint till Firebug / FirePHP så nästa steg var att logga in till DB. Jag ville också att logga ytterligare information med hjälp av ramverket som user agent, datum och tid, få och skicka variabler. Så för att förlänga den manuella lite här vad jag gjorde:

// Set up logging to DB
$db = Zend_Registry ::get('dbAdapters');
$db = $db['general'];

$columnMapping = array( 'priority' => 'priority',
'message' => 'message',
'datetime' => 'timestamp',
'user_agent'=> 'user_agent',
'get_vars' => 'get_vars',
'post_vars' => 'post_vars',
'site' => 'site'
);

$writerDb = new Zend_Log_Writer_Db($db, 'error_logging', $columnMapping);
$logger = new Zend_Log($writerDb);

$logger->setEventItem('datetime',date('Ymd H:i:s'));
$logger->setEventItem('user_agent',$_SERVER['HTTP_USER_AGENT']);
$logger->setEventItem('get_vars',print_r($_GET,true));
$logger->setEventItem('post_vars',print_r($_POST,true));
$logger->setEventItem('site',SITE);

$logger->info('Informational message');

Where the array keys in $columnMapping are my column names. 'Priority' and 'message' are understood by Zend_Log_Writers but the additional fields were added to give me some additional information.

Obviously this assumes that you have logging working using one of the other writers first :)