AWS Thinkbox Discussion Forums

Map a asset/library drive in windows with EC2 when scaleout?

Hi all,

For Deadline 6 EC2 integration and easy management is definitely something that I am excited about.

However I do run into some problem with EC2 setup before. And even after I talk to my amazon solution consultant, they were suggesting GlusterFS to map S3 bucket as online shared storage for easy management. EBS volume maybe kind of small for texture/library server setup.
We are using windows server 2008 r2 AMI at the moment.

Other choices of commercial software will run into licensing issue during scale out for the farm if we were to clone the instances in Deadline, e.g. TNTdrive.
So what’s other options we could try?

The reason why we would like to retain the mapping of a drive is to maintain the similarity of the setting in a scene file.
Thanks!

Teirz,

Indeed there are some tricky issues around having nodes on the cloud. At Thinkbox we have been looking at exactly these kinds of issues, and we are still investigating. Depending on the approach, it is possible to build virtual networks on the clould and have virtual nodes read from a mapping this is a mirror of the local assets. There are tradeoffs with this, not the least of which is complexity and cost. Some remapping of asset paths in the scene or comp file may be required in any case.

Cloud rendering may be best for cases where the estimated ratio of IO to rendertime is below some critical threshold. We are very interested in any thoughts our customers may have in this regard.

Hi Coulter,

Thanks for you reply! At least I know I am not the only one having similar problem handling this.
Currently my approach is to setup a VLAN to include any cloud nodes e.g. EC2 nodes to be able to pull any data, ranged from textures to scripts/plugins, from our local server which actually have a network interface in that VLAN. It also solved one problem with sharing limited floating license for any render nodes, e.g. vue, fumefx etc.

However I haven’t manage to get a good thought on how effective is this in terms of spending the cost on IO traffic compare to having a permanent sync server on S3.

Privacy | Site terms | Cookie preferences