From: Marco Recuay <marco@(email surpressed)>
Subject: Rush and Amazon EC2
   Date: Fri, 08 Jun 2012 17:03:28 -0400

On 06/08/12 14:03, Marco Recuay wrote:
> We're starting experiments with moving some rendering workload to 
> Amazon's EC2 cloud computing platform.
> 
> Has anyone here had any experience with this type of pipeline before? 
> Would Rush pull licenses via a VPN connection to the offsite render 
> nodes?

	Yes -- that, or PPPoE, or similar would be the way to do it.
	This way you can not only serve licenses, but manage the remote farm
	from your office network (via irush/www-rush/rush command line)
	while keeping both networks private from the internet, yet able
	to see each other.

	Folks do run Rush over WANs using either private connectivity
	or the internet to interconnect them, and often configure tunnels
	over the internet, so their data isn't in the clear on public
	wires. (PPPoE, VPN, etc all provide for this)

	I know storage is usually the biggest issue with remote rendering,
	ie. the file server. This may have changed since the info I last
	received.

	So far folks have reported that the file servers Amazon provides
	can't handle the load of film/video production (ie. maya pulling
	large scenes from an EC2 file server, or a comp pulling plates),
	so they have to resort to localizing the data, which complicates
	the pipeline.

	One route to go is to localize the data to each node,
	as I don't think Amazon allows you to colo your own file server
	at their site.

	I think folks have done experiments with Amazon's network,
	but have mixed results depending on data size.

	There's a good thread here on this subject:
	http://studiosysadmins.com/board/viewpost/11158/

	Also: here are some articles on "cloud rendering" in the media,
	though I'd take much of it with a grain of salt, and I'd
	defer to actual results:
http://www.awn.com/articles/article/elastic-cloud-computing-dreamworks-cerelink
http://www.datacenterknowledge.com/archives/2011/02/28/hollywoods-render-farms-move-to-the-cloud/
http://www.google.com/search?q=dreamworks+cloud+rendering&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

	I think for the most part people have had troublesome
	results, and in the end, find it cheaper and easier to
	manage internally.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

On 2012-06-08 15:26:40 -0700, Greg Ercolano <erco@(email surpressed)> said:

On 06/08/12 14:03, Marco Recuay wrote:

We're starting experiments with moving some rendering workload to
Amazon's EC2 cloud computing platform.

Has anyone here had any experience with this type of pipeline before?
Would Rush pull licenses via a VPN connection to the offsite render
nodes?

	Yes -- that, or PPPoE, or similar would be the way to do it.
	This way you can not only serve licenses, but manage the remote farm
	from your office network (via irush/www-rush/rush command line)
	while keeping both networks private from the internet, yet able
	to see each other.

	Folks do run Rush over WANs using either private connectivity
	or the internet to interconnect them, and often configure tunnels
	over the internet, so their data isn't in the clear on public
	wires. (PPPoE, VPN, etc all provide for this)

	I know storage is usually the biggest issue with remote rendering,
	ie. the file server. This may have changed since the info I last
	received.

	So far folks have reported that the file servers Amazon provides
	can't handle the load of film/video production (ie. maya pulling
	large scenes from an EC2 file server, or a comp pulling plates),
	so they have to resort to localizing the data, which complicates
	the pipeline.

	One route to go is to localize the data to each node,
	as I don't think Amazon allows you to colo your own file server
	at their site.

	I think folks have done experiments with Amazon's network,
	but have mixed results depending on data size.

	There's a good thread here on this subject:
	http://studiosysadmins.com/board/viewpost/11158/

	Also: here are some articles on "cloud rendering" in the media,
	though I'd take much of it with a grain of salt, and I'd
	defer to actual results:
http://www.awn.com/articles/article/elastic-cloud-computing-dreamworks-cerelink
http://www.datacenterknowledge.com/archives/2011/02/28/hollywoods-render-farms-move-to-the-cloud/

http://www.google.com/search?q=dreamworks+cloud+rendering&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

think for the most part people have had troublesome
	results, and in the end, find it cheaper and easier to
	manage internally.

On 06/13/12 13:25, Marco Recuay wrote:
> Thanks Greg. We'll give it a shot and see what works or doesn't. I 
> doubt it would be viable as a full-time render solution for us at this 
> point, but due to the small size of our facility it would be nice to be 
> prepared for those situations when the work starts getting beyond our 
> internal capacity.

	You should look into remote rendering facilities that not only
	provide the cpu power, but the software and licenses as well.

	I know of RenderRocket because they use Rush as a back end.

	They provide Maya/Mray, 3dsmax, Vray, and Cinema4D rendering,
	and use	a web interface to submit and monitor scenes, and you
	can give them external firewire drives to deliver/retrieve
	large amounts of data:

		http://www.renderrocket.com/

	There are others too which I don't know as much about,
	but have seen folks mention as well:

		http://www.respower.com/
		http://www.rebusfarm.com/
		http://www.powua.com/
		http://www.rendercore.com/
		http://www.rendernation.com/

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)