Sponsors
Sponsor Products
Cloud Rendering - open sourcing our technology - Looking for interested studios for open source effort
posted by Rob Aitchison  on Feb. 12, 2016, noon (4 years, 5 months, 22 days ago)
4 Responses     0 Plus One's     1 Comments  
Hi,
As one of those customers who used it, I will vouch for it. Regardless of the subjective quality of the film, we were able to render the majority of it using this technology. We were able to work through the issues and have a good, reliable solution in place If you have any questions, feel free to hit me up.
Thanks Francois; looking forward to seeing what you do next.
Cheers!
On Fri, Feb 12, 2016 at 11:31 AM, Francois Ruty <content@studiosysadmins.com> wrote:

Hello, I write here since I represent a startup who used to work on a cloud rendering technology. Basically we have a SMB proxy that enables studios to perform runtime asset syncing (your render nodes import assets on the fly, as the renderer tries to access them).

The implication of that is that you can use any render nodes in any facility in the world, and have them act as if they were located in your local pipeline. With the SMB proxy, you can show to your remote render node your local file structure, and as the remote render nodes tries to open the files it needs, those files are transparently imported with a high speed file transfer system.

For analogy, our software enables you to set up "Avere-like" cache, on top of ubuntu machines or VMs.

We are now shifting ou focus to applications (we are working on a 3D application prototype) and we are still sitting on our SMB proxy technology, which performed successfully on several projects so far. The reason we shift our focus is that we initially planned to provide turnkey render nodes but this proved to be not scalable enough for us. So we decided to stop providing render nodes. But our technology works well and we are considering building a community around it.

We are considering making it open source, we would stay the owners of the code, but studios who signal themselves as interested could use the software, access the source code, and possibly collectively improve it where necessary. I'd like to emphasize that the software is production-proven, we're not talking about a prototype here.

Those who are interested or just have questions can email me at fruty@seekscale.comor write here

thanks

Franois


To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


Thread Tags:
  discuss-at-studiosysadmins 

Response from Andy Jones @ March 9, 2016, 5:10 p.m.
From the seekscale web site:
You install 1 Seekscale software appliance at each of your facilities, and each of them will automatically detect in real-time which asset to import from where, to match your artists needs.

Sounds really interesting to me. Definitely curious to hear more. Particularly if there is any kind of API for pre-syncing or managing which kinds of files get synced. I'd also love to know more about how well the transfer speeds compare to (or integrate with) Aspera or similar tech.
Thanks!Andy

0 Plus One's     1 Comments  
   

Response from Francois Ruty @ Feb. 13, 2016, 6:03 a.m.

Hello,

@Rob: thanks =)

 

@Saker: I'm not sure I understand your schema, but I can reformulate a little bit how the SMB proxy can be used in production.

The classic setup is that you have in your studio a central asset server, most likely a NFS or SMB shared drive, where all your render nodes fetch what they need.

Now, let's say you want to use remote render nodes outside of your facility. It can be Amazon nodes, or it can be render nodes in other datacenters. Why would you want to do that? Usually it's because you can find cheap render nodes in some remote data center, or you simply need to many node and need to spread the load among multiple providers.

OK now let's say you have a high-bandwidth low-latency link to those remote datacenters. In this case you can just set up a VPN, and mount your central asset server on the remote render nodes. If the network link is good, it should work OK.

However in practice, you don't necessarily have a perfect network link between your main facility, where your asset server is located, and the remote dataceter with your extra render nodes. So if you simply set up a VPN and mount your local asset server on the remote render nodes, performance will be extremely low for file transfer and render nodes will be unusable (SMB and NFS are made for local networks, they are not designed for latency links).

So at this point you start thinking, can I just replicate my asset server to the remote datacenter so that the remote render nodes can have a local copy of the files? Usually that's not possible because you have TBs of assets, and artists edit them all the time. So, your next option is: "OK for each frame let's send the render nodes only the assets needed for the frame". That is the ideal option. The problem is, most of the time, you don't know which assets a given job is going to require.

The SMB proxy is the solution to your problem. In this remote datacenter where you have your extra render node, you add a ubuntu machine where you install the SMB proxy. You mount the resulting share on the render nodes. Then the SMB proxy shows all assets from your central assets server, as if they were there locally. The SMB proxy just connects to your central assets server, fetches the folder and files list, and present them to the remote render nodes. Of course, in the remote datacenter, the SMB proxy has no files locally, but the render nodes don't know that.

Then when you send a job to the render node, the render node starts opening files on the SMB share from the SMB proxy. What the SMB proxy does is that it detects which files the render node is trying to open, freeze the call, import the files from the central assets server with a high-speed file transfer protocol, and then releases the call. The render node opens the file, and was never aware that the file has been imported live.

So, to sum it up, you have a runtime assets-syncing system, which enables you to present your render nodes a unified name space for your assets, without having to deal with actual sync issues. All your render nodes, whatever their location, think all assets are local, and when they actually need them the SMB proxy actually import them locally.


0 Plus One's     0 Comments  
   

Response from Francois Ruty @ Feb. 13, 2016, 6:03 a.m.

Hello,

@Rob: thanks =)

 

@Saker: I'm not sure I understand your schema, but I can reformulate a little bit how the SMB proxy can be used in production.

The classic setup is that you have in your studio a central asset server, most likely a NFS or SMB shared drive, where all your render nodes fetch what they need.

Now, let's say you want to use remote render nodes outside of your facility. It can be Amazon nodes, or it can be render nodes in other datacenters. Why would you want to do that? Usually it's because you can find cheap render nodes in some remote data center, or you simply need to many node and need to spread the load among multiple providers.

OK now let's say you have a high-bandwidth low-latency link to those remote datacenters. In this case you can just set up a VPN, and mount your central asset server on the remote render nodes. If the network link is good, it should work OK.

However in practice, you don't necessarily have a perfect network link between your main facility, where your asset server is located, and the remote dataceter with your extra render nodes. So if you simply set up a VPN and mount your local asset server on the remote render nodes, performance will be extremely low for file transfer and render nodes will be unusable (SMB and NFS are made for local networks, they are not designed for latency links).

So at this point you start thinking, can I just replicate my asset server to the remote datacenter so that the remote render nodes can have a local copy of the files? Usually that's not possible because you have TBs of assets, and artists edit them all the time. So, your next option is: "OK for each frame let's send the render nodes only the assets needed for the frame". That is the ideal option. The problem is, most of the time, you don't know which assets a given job is going to require.

The SMB proxy is the solution to your problem. In this remote datacenter where you have your extra render node, you add a ubuntu machine where you install the SMB proxy. You mount the resulting share on the render nodes. Then the SMB proxy shows all assets from your central assets server, as if they were there locally. The SMB proxy just connects to your central assets server, fetches the folder and files list, and present them to the remote render nodes. Of course, in the remote datacenter, the SMB proxy has no files locally, but the render nodes don't know that.

Then when you send a job to the render node, the render node starts opening files on the SMB share from the SMB proxy. What the SMB proxy does is that it detects which files the render node is trying to open, freeze the call, import the files from the central assets server with a high-speed file transfer protocol, and then releases the call. The render node opens the file, and was never aware that the file has been imported live.

So, to sum it up, you have a runtime assets-syncing system, which enables you to present your render nodes a unified name space for your assets, without having to deal with actual sync issues. All your render nodes, whatever their location, think all assets are local, and when they actually need them the SMB proxy actually import them locally.


0 Plus One's     0 Comments  
   

Response from Saker Klippsten @ Feb. 12, 2016, 1:10 p.m.
Interested and I would like to understand how this works. - Since every second counts and every bit transferred counts towards the bottom line. Note we also just finished integrating GCP for seamless rendering into our pipeline..
Sounds like a wan accelerator appliance (riverbed) type deal except software..that can live in the cloud?
Simplified below question based on what your described..

Render Node 1 in Cloud ----->SMB Proxy "Avere Like Cache" Hosted in Cloud-----> Wan-----> My on prem serverRender Node 2 in Cloud ----->SMB Proxy ( hits the cache only )Render Node 3 in Cloud ----->SMB Proxy ( hits the cache only )


Or is it
Render Node 1 in Cloud running SMB Proxy Software -----> Wan------> My On Prem ServerRender Node 2 in Cloud running SMB Proxy Software -----> Wan------> My On Prem Server
Render Node 3 in Cloud running SMB Proxy Software -----> Wan------> My On Prem Server

or is it neither?


If its the latter that seems to be inefficient. As each node will have to pull the same set of data from my on prem server over the wan. This can be costly fast and tie up my connection to the cloud .
If its option 1. How well does that scale when you have hundreds or in our case thousands of nodes hitting the cache assuming this depends on the type of machine its hosted on?




-S



On Fri, Feb 12, 2016 at 8:31 AM, Francois Ruty <content@studiosysadmins.com> wrote:

Hello, I write here since I represent a startup who used to work on a cloud rendering technology. Basically we have a SMB proxy that enables studios to perform runtime asset syncing (your render nodes import assets on the fly, as the renderer tries to access them).

The implication of that is that you can use any render nodes in any facility in the world, and have them act as if they were located in your local pipeline. With the SMB proxy, you can show to your remote render node your local file structure, and as the remote render nodes tries to open the files it needs, those files are transparently imported with a high speed file transfer system.

For analogy, our software enables you to set up "Avere-like" cache, on top of ubuntu machines or VMs.

We are now shifting ou focus to applications (we are working on a 3D application prototype) and we are still sitting on our SMB proxy technology, which performed successfully on several projects so far. The reason we shift our focus is that we initially planned to provide turnkey render nodes but this proved to be not scalable enough for us. So we decided to stop providing render nodes. But our technology works well and we are considering building a community around it.

We are considering making it open source, we would stay the owners of the code, but studios who signal themselves as interested could use the software, access the source code, and possibly collectively improve it where necessary. I'd like to emphasize that the software is production-proven, we're not talking about a prototype here.

Those who are interested or just have questions can email me at fruty@seekscale.comor write here

thanks

Franois


To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


0 Plus One's     0 Comments