Rendering farm?

[dsr-mzpnVDyJpH4k7aNtvndDlA at public.gmane.org (Dan Ritter)]

On Fri, Oct 09, 2009 at 07:37:25PM -0400, Richard Pieri wrote:
> On Oct 9, 2009, at 6:39 PM, Scott Ehrlich wrote:
> > I received at least one email suggesting a Windows-based rendering
> > farm - likely to consist of a few rack systems all running 64-bit
> > Windows.  I read an article on Tomshardware which gave some decent
> > insight.   What can list participants offer on this concept?
> 
> Virtualization is a nifty thing, and like every nifty thing it gets  
> misused :).  Don't use it for your render farm.  Render farms are a  
> lot like Beowulf clusters (and are sometimes set up *as* Beowulfs).   
> They take big tasks and break them down into smaller pieces.  More  
> nodes = more pieces = faster render times.  Virtualization is not a  
> win in this environment because your host limits the number of  
> concurrent VMs.  Virtualization is not a win because you want to be  
> able to swap out a failed node as quickly as possible -- and that is  
> neither easy nor fast if you have a hardware fault on the physical host.

Yup. The key to a render farm is the old-fashioned notion of
batch computing. Set up your job management system, and let
people submit jobs to it. Finished jobs are delivered; if a
machine in the farm breaks for whatever reason, that part of the
job is allocated to a working machine. If a job fails for its
own reason, the whole job is kicked out and returned to the
submitter along with the error messages.

http://www.linux-mag.com/id/1184 is old but useful.

-dsr-