Qube

Render Farm Management for Digital Media Pipelines

 

 

Try It FREE 30 Days

 

EDU Site Subscription

Microsoft Azure

 

 

AWS Google Oracle

 

 

“We’ve rendered over 5 million jobs and still counting…” - ReelFX
AWS Google Oracle

Rendering in the Cloud with Qube!

Qube! typically works quickly and easily with any public or private cloud provider. The most challenging part is usually setting up the secure network connection (most commonly through a software VPN) from your facility to the cloud environment. Once you have established your secure network connection to the cloud, the Qube! Supervisor will see any newly added cloud hosts as an extension of your existing on premise render farm.

Which Cloud Provider?

You can use any kind of cloud provider such as a private cloud environment like Scalr or Liquid Web or a public cloud provider. Almost all of our customers use public cloud providers - Google, Microsoft, or Amazon. We have customers using Qube! in production on all three, and we have successfully completed our own test renders on all three. We have partnership agreements with Google and Microsoft, so not only would we recommend you using one of those, we can also work together with Google or Microsoft to get you started.

Once you have an account set up with your chosen cloud provider and the secure connection is in place, that's when Qube! takes over and can manage jobs seamlessly between your on premise farm and your cloud farm.

How Does PipelineFX Help?
  • Our experience - not only do we run all of our development and full testing environment in the cloud, but we have a multitude of experience from helping customers solve their cloud challenges.
  • Our partnerships - as mentioned above, we have partnership agreements with both Microsoft and Google. We can get you in contact with Media and Entertainment specialists at each company where they both offer cloud credits for the set up and testing of your cloud farm.
  • Qube! credit - either through trial licensing or through our Metered Licensing, we can give you credits for Qube! licenses while you are setting up and testing your cloud environment. Distribution of these credits is done on a case by case basis, of course, after we have a conversation about your goals.
  • Qube! licensing flexibility - we can help you determine what the best Qube! licensing option will be for your rendering needs. You can use your existing paid Qube! licenses (subscription or perpetual) for your cloud nodes, you can enable Metered Licensing and overflow from your facility to the cloud, or you might be able to rent Qube! licenses from the cloud provider, depending on which provider it is.

If you are researching what it might take to render in the cloud and how Qube! may help, please do reach out to us with any questions - sales@pipelinefx.com.

If you are further down the road and more serious about getting started in the cloud, also send us an email at sales@pipelinefx.com and we can discuss what your goals may be. We may recommend a follow up call with the cloud provider to introduce all of the teams to each other, if you are working with Google or Microsoft.

How Does It All Work Together?

In writing this, we are assuming you are currently rendering on premise. If you are brand new to rendering altogether, then we should talk! There is so much we can teach you and so much Qube! can do for you!

Let's say you now have your account set up with the cloud provider and you have just finished getting your secure software VPN in place to connect your facility to the cloud. What next?

1. Start up cloud machines for compute.
Compute is the cloud term used for machines that complete processing tasks, like rendering. These cloud machines will need an image to be selected - an image is a combination of the operating system and the hardware specs needed to complete your renders. Your render nodes on your cloud compute machines should usually mimic whatever you are using on premise. If that set up is not available, a typical render node image for today's software packages would look like:

  • Linux OS - CentOS 7
  • Windows OS - Windows 10 Professional
  • Machine Spec - 8 core, 30 or 32 GB

2. Add the necessary software packages to your cloud compute nodes.
The model is bring your own license, for the most part. As time goes on, we are seeing more cloud providers resell Qube! licenses and licenses of the other necessary software packages, so as you get started, please do check to see which packages can be purchased directly from the cloud provider. As you read above, you have a few options for provisioning Qube! licenses. You'll need to independently add or direct your licenses for the other necessary software packages. Examples of those other packages could include V-Ray, Arnold, Renderman, Clarisse, Houdini, etc.

3. Decide where you would like your pre-processed and post-processed asset files to live.
The typical set up is to have the files you send for rendering (pre-processed) to remain on premise and have them sent to the cloud as you need them. After the job is done, it's common to transfer the output to cloud hosted storage (which are additional cloud machines you'll need to start up) and then transfer those files back to your facility at some regular cadence. Some clients distribute their completed files to other geographic areas supported by the their cloud provider. It's important to understand the cost of doing that prior to starting that kind of process as you'll pay for the initial storage, transfer by size of the data, and additionally the storage on the receiving end. One of the easiest ways to make sure your files get transferred back and forth to the cloud from your facility (so that you don't have to maintain r-sync scripts or something similar) is to use a software based Avere cache. It mounts along your file path, so it will automatically pull files as you need them without you having to change any of the file pathing in your scene files. Since it's a cache, it will also cache those commonly used files so that you don't have to transfer the same files over and over. Aspera offers something similar with Aspera Sync, but that functions a little more like an r-sync attached to their FASP transfer utility. Both technologies are worth a look.

4. Write your pipeline additions to integrate the usage of cloud render nodes.
Scripts or utilities commonly written include, but are not limited to: starting up and shutting down cloud compute nodes, transferring files to the cloud for rendering (if not using a solution like the Avere cache), transferring the files back to your facility once they are complete, and making sure all associated plugins you need are added to your compute instances before rendering (this can involve writing scene traversal to see which plugins are called before a render is initiated or if your plugin set is relatively manageable, you can just put all of the necessary plugins on your compute nodes ahead of time). You can easily automate the usage of the pipeline tools you write with pre-flight and post-flight operations in Qube!. These are configurable tasks that will automatically run prior to a job starting or at job completion. Also be sure to ask us what cloud integrations may already be built into Qube! when you get started as we are furthering our cloud integration into the application all the time.

5. Test your pipeline!

How Much Does It Cost?

The first thing to understand is how many different aspects of cloud usage you'll need to pay for. They include:

  1. Data transfer to the cloud (volume based pricing by the GB)
  2. Compute rendering time (time based pricing by the minute or hour for machine uptime)
  3. Software licensing for each software package (mostly time based pricing by the minute, like Qube, but some require a daily or monthly subscription)
  4. Storage of files on provisioned storage machines (time based pricing by the minute or hour for machine uptime)
  5. Data transfer back from the cloud (volume based pricing by the GB)

Every cloud provider has different prices, so you need to check their websites independently. You can Google search terms like Google Cloud Compute Pricing or Microsoft Azure Storage Pricing. The terms for data transfer are known as ingress and egress.

Yes, what you are thinking is correct. The total can add up if you want to render out a scene or project file.

But in a pinch, there is really no resource pool that can match what's available at a cloud provider. You can scale up as wide or as high as you would like and do so very quickly. For the cost, you can make sure you hit that deadline regardless of the amount of work.

There are some tricks you can use. Try to look for the cost of 'interruptible' or 'preemptible' instances (they go by different names at each provider). They are essentially instances that are cheaper because they can be stopped or interrupted at any time by other work the cloud provider may have - whether that be their own computing needs or the needs of one of their other cloud customers. Up until now, they are rarely interrupted, but obviously, you do sign on for the risk of the work possibly being stopped, and if you cannot have check-pointing in your renders, you will have to start over for those particular jobs. Some providers will also offer the ingress or egress for free. That's worth looking into. Last but not least, it's important to configure your cloud alerts in the control panel they provide. You can set up your alerts to tell you if instances have been running for 'x' number of hours or to tell you if you've spent more than 'y' number of dollars.