I want to talk to you today about using Deadline along
with the Google Cloud platform.
I'll start off with an overview of Deadline.
It was developed to allow render farm
to be shared between applications, departments,
and of course, between facilities as well.
It's been used by large and small companies
alike around the world.
It does not use a single manager design
it's meant to be distributed.
Instead the slave logic that is built into the line
picks up the work based on the set
of rules, the criteria, and scheduling logic
that you provide.
Right now deadlines supports or 70 applications out of the box,
and can be added via Python and the native applications
scripting languages.
Deadline was meant to be artist driven.
We want it to be really easy, one click to install.
We want it to be able to render, simulate, execute commands, do
software builds.
We actually use internally at Thinkbox.
Do out own software builds.
And of course we have extensive public and private file
support, which I'm here to talk about today.
We want you to have the best of both worlds,
use your existing infrastructure,
your existing Deadline's set up, your local hardware,
plus use on demand.
And the best way to do that of course, Google Cloud Platform.
We have extensive support for Google Cloud Platform.
The way we do that is with the new module in Deadline,
called the virtual machine extension.
It's able to launch and terminate virtual machines.
We can do it through a cloud panel
or we can do in an automated way through a program called
Bouncer, I'll tell you a little bit about that as we go.
And we have a sort of fancy Cloud installer
if you want to get going on the Cloud
very quickly with the Cloud repository,
you can use our Cloud wizard to do that.
These are the sort of common Deadline components.
I'm going to spend a lot of time here,
but the short version is the repository
in the database form the queue.
And the key worker applications is
Slave, that's responsible for controlling
my max nuke whatever, doing the actual rendering on the render
node.
There's various support applications.
Pulse monitors your interface into the queue,
Draft for lightweight compositing,
and of course you licensed server.
Let's talk about the Cloud-related components
of Deadline.
Deadline Balancer is the mechanism
that we have for doing automated launching
and terminating virtual machines.
I'll talk about that in a little bit more detail.
We have an Asset Crawler script essentially
that sits on each Cloud region that you enable and watches
for assets and makes sure that jobs don't try to render
before the assets are ready.
On the Google side, of course you're
going to a Google Cloud account.
That's your own personal account or company account,
depending on how you're using it.
A virtual network within the Cloud,
this is sort of a little bubble within your Cloud account
where you build a network to do the rendering.
Virtual private network forms the bridge
between your local facility and your Cloud account
for secure communications.
Storage on the Cloud.
And then you'll also need the virtual machines themselves
that have the information for the operating
system, the worker application like my Deadline slate
and so forth.
Those are the components and I'll
start to talk a little bit about how it all fits together.
We sort of promote a hybridized approach.
We call it Pop-up Cloud as our sort of buzzword for that.
We combine local compute resources will off
site private or public Cloud resources.
You have a local office and the VPN that connects you up
to your Cloud.
This is enabled through our Cloud provider dialogue
within Deadline.
This is where you can add Cloud regions from your provider
and configure all the credentials
and so forth so that once it's configured
Deadline can talk to the Cloud and get things done.
Let me tell you about some of the ways
that Deadline can be configured.
It's meant to be extremely flexible.
And so sometimes people ask me, how should we set this up?
It really depends on your use case,
there's a lot of different ways you can do it.
The various components of Deadline
can be installed in different locations, it's very tolerant.
As long as the pieces could talk to each other
they can pretty much exist anywhere.
In this particular configuration for direct submission
the database and repository are up in the Cloud.
You've got the balancer application up in the Cloud,
it's starting and stopping virtual machines.
You've got some Cloud storage.
On your local side you probably have an artist,
you might have a couple of slaves running locally as well,
it'd be driven by that Cloud based repository,
and got your local file store.
One possible configuration.
Another possible configuration.
Move the database and repository locally.
Essentially the same, the balancer
might be local in that case as well,
or it could be, again, up in the Cloud.
But still you're talking to a set of cloud slaves
and a set of local slaves, you've
got your local storage, your cloud storage.
And you have that flexibility again of your local system
and your Cloud system.
And then a third configuration could be
that you have two repositories.
Some of the companies that we work with really like to you
might say micromanage their Cloud rendering.
And so what they do is they set up
an entirely separate repository, basically a separate render
farm, in the Cloud, they got their own local render farm.
And a lot of times this happens simply
because they have a local farm that's all working perfectly,
they want to play with this stuff,
they want to do it carefully, so they'll set up
a separate farm in the Cloud.
Once they get their head around it
they'll probably move back to one of the other configurations
where there's only a single repository.
But again, it's quite seamless.
You can use whichever configuration works for you.
The mechanism that we use to decide whether a job can
go to the Cloud or not is called Group Mappings,
this is the interface for it.
Let me talk more conceptually about how it works.
Deadline has a notion of groups.
Whenever you submit a job to Deadline,
you submit it to a group.
The group can be sort of anything you define.
Quite often you'll see a configuration
like 3D simulation, I'm looking at the column sort
of in the middle that says Group Mapping,
you have a 3D group, a simulation group,
a proxy group, a composite.
This could be whatever you want.
On the left side is your queue.
This is sort of a schematic representation of a queue,
there might be a Maya job in there, a draft job
for doing proxy and Bifrost.
Each of these jobs has a group that
is associated with the job when it's submitted.
So what the Group Mapping does, is it says, OK, for this group,
let's look at for example 3D at the top there,
I want to map that group to an N1 standard for instance, four
core instance, and I want to map it into a virtual machine
image that has Deadline Slave installed,
it's got Maya it's got Max.
Basically all the three software, plus Deadlines
control software.
And what will happen then, is that basically tells Deadline
that the 3D group is enabled within this region,
and these settings are on a per region
basis, so if you have multiple regions set up
you can actually control which sort of hardware
and which VM images that you use.
At the bottom you'll notice that, for example
the composite group doesn't have a mapping,
and all this is saying is that for this particular region
we don't want the job going to the Cloud,
we'll just keep those locally.
So you have the-- can have a job go to multiple regions, one
region, it all just depends on the group mapping
so that you have a lot of flexibility and control
of that.
Once your group mappings are defined
and Deadline knows the job is eligible to be processed
on the Cloud, the program that will do that
is called Balancer.
And Balancer basically watches over the queue
and it says OK I see some jobs and I see some mappings,
and so based on the demand and based
on all of your configuration settings and your budget,
I'm going to start up some instances over here
or terminate some instances over there and so forth.
So, launching and terminating virtual machine instances
by hand would be tedious.
You could manually launch them but it's not
going to be efficient, so this is
an automated way of doing that.
Saves costs with regard to starting and stopping
virtual machines.
And it will balance across regions.
And the algorithm that decides which
virtual machines get started and when and all that is pluggable.
So we provide a default algorithm
that we feel pretty efficient, but we
realize that studios may want to hook
into other things you may want to provide sort of deep status
controls.
So the algorithm's pluggable, you can look at the code
that we provide and modify it, copy it, make your own.
Come talk to us if you need help, we're happy to help you.
Deadline, this is the settings for Balancer
for a given region.
One of the key things look at there
is that green box in the middle, that's the budget.
What the budget does is it makes sure
that you don't exceed a certain spend rate within that region.
That could be dollars per hour or whatever units you want,
typically is dollars per hour.
And the reason for that is that because the algorithm is
pluggable, it's sometimes possible to make a mistake,
as what happens with any computer code.
So the Balancer will always make sure
that, no matter what the algorithm says
in terms of starting virtual machines,
it may say start 500 million virtual machines,
the Balancer will say what your budget just doesn't support
that, so we're going to clamp it your actual request
to fit within your budget.
So sort of a safety mechanism.
And it also let's you control your overall spend
for project as well.
Deadline has, in its current form,
something we call asset awareness.
At present we don't do automated asset management,
but we have a lot of controls in there
to make sure that things don't actually render
until your assets are ready.
So, for example, the jobs haven't
required asset property, and when that's populated
it says which assets are required to process a job.
The asset crawler lives on the Cloud,
and it keeps an eye on which assets are up on the Cloud.
And the Balancer then we'll talk to that Asset Crawler
and say, hey, do you have the assets for this job?
And if the Asset Crawler says yes,
then the Balancer will green light that job for the Cloud.
If it doesn't then Balancer will just discount that job.
And then finally the job will be green lit for the Cloud,
but again it won't pick up unless those assets are ready.
So this prevents errors, prevents waste and spend.
So this is all fine and good.
Is great that you can configure deadline in all these ways,
you can do all this stuff with it.
But there's a little bit of learning curve there.
And so we want to help you get started and with this as
quickly as possible so that you can get your head around it.
We do that was something called the Deadline Cloud Wizard.
What it does is it does an automated set up of the pieces
and you need to get a Cloud Based repository render
farm going.
Installs VPN, configures Cloud storage,
installs temporary Deadline and Balancer licensing,
int installs a fully functional repository and database,
it downloads example VM images preconfigured with,
for example Maya and Blender things
like that so you can see it work.
It pre-populates the queue with some example jobs,
you can basically see the whole thing work out
of your own account very quickly.
So I have a video this is a sort of a edited down video
of actually running the Cloud Wizard.
So you download the Cloud Wizard from us,
install it on your machine and fire it up.
We're going to set up a Cloud based farm right in front you.
There's a few prerequisites you need to do.
Obviously you need to set up your Google Cloud account,
you need to create a project, and you enable the Google
Compute Engine.
These things just take a few minutes.
So hear are the project IDs going in.
I'm getting the OAuth credentials, which
allows the Cloud Wizard to talk to your Cloud account,
to talk to Google, and take action to install things,
to do things.
So this is basically setting up the authentication.
And it is good.
So there.
Authentication completed.
The next thing it's going to do is set up some SSH keys.
It can be done automatically for you.
I mentioned that you need a little mini network
inside of your Cloud account, so it's
going to set that up for you.
Retrieving temporary licensing.
It's going to copy the virtual machine
images for infrastructure, that means
the repository, your database, your licensing,
as well as the demo instances.
It's setting up a VPN firewall rules,
it's launching the infrastructural VN
so that your repository and database are coming online.
And It's telling you to shut down
any VPN you might already have going because it's
going to set up it's own.
Go and do that right now.
And once that's up and running then pretty much
you have a secure connection between your local workstation
and your Cloud account.
Finish up in a moment, and license server set up
is done now that it has the Mac address
and has installed the licensing.
It's now doing the last minute configuration
on the repository.
You can imagine doing this by hand would take a while,
so the whole idea of the direction that we're
going with all of this is to make it happen automatically,
quickly for you, basically again pop-up Cloud.
So, here the Balancer application is launched.
This is a brand new repository so it's creating
an account for me on Deadline.
Here is Monitor, with a couple of jobs in the upper left hand
corner.
I'm going to switch into super user mode,
and go back to configure Cloud providers.
Here we can see the Google Cloud region that
was set up automatically by the Cloud Wizard
all the credentials have been entered
based on what you put into the Cloud Wizard
so you don't have to go through all that.
Lots of settings and saves time, Balancer options,
initial budget set to two, just to keep it nice and safe
for testing and play.
These are the group mappings, I talked about earlier.
If we look at, for example, the Blender group
we can see that it's been set to n1-standard-1,
one core instance type, and it's using the image
that has Blender installed.
So when a Blender job is ready to go,
which I'm about to do right here by resuming
both of these jobs, both Maya and Blender,
it will start those up.
Now one of those jobs, I didn't actually-- you can't really
see the priority of the jobs here, but one of them
has a little bit more priority than the other.
Balancer will recognize that and try
to populate virtual machines for that job first.
And we can see it populating the state.
It's running through the algorithm,
the pluggable algorithm, which tells it,
hey, we need a couple of virtual machines fired up
for Maya because that's what our budget said that we could do.
And then it starts firing up virtual machines.
And if I wanted to go back and say well,
two isn't really enough let's bump it up to 10.
Get things done a little bit faster.
And trust me the numbers can get bigger,
I'll talk about that later.
And within a few moments, within the next cycle of the bouncer,
again this is a bit time compressed
because the amount of time that we have for the presentation.
But it will recognize that change
and say oh you've got more budget now,
so let's fire up some additional VMs.
As the Maya job completes, it will then
go down to the job that has next highest priority,
will start shutting down the Maya virtual machines
and spinning up the Blender virtual machines
because that's what's needed.
It will also recognize, if you have two different job
types that are using the exact same virtual machine images,
it will just switch over to those intelligently.
It wont shut things down start them back up again.
So there's a lot of choice of configuration here, we've
tried to keep it as flexible as possible, and yet as
easy as possible.
So now the Maya job's done, firing up Blender,
we're seeing virtual machines fire up for that
through the Balancer.
So that's pretty much it for the Cloud Wizard,
in terms of watching demo of it run,
I think I'm just going to skip forward at this point.
It's going to essentially finish that job
and then terminate those virtual machines.
So, quick recap on the Cloud Wizard.
It only usually takes about 30 minutes
to run in most of our testing.
There's a little bit of prerequisite,
like I said, that stuff shouldn't really take you
more than 15 to 30 minutes.
So I'd say in under an hour you can
be playing with the Cloud render farm that's
running in your own account.
Thinkbox helps you out with a 30 day evaluation,
so there's no cost on the Thinkbox side to try this out.
Google's kind enough to help you out
with a $500 credit for your Cloud compute time.
That means essentially that you can
get started with this at no cost to you,
the only real cost is your time.
So figure couple hours for that and you
can actually play with this, get your head around the concepts,
and think about how you might want to do your implementation.
Does it scale?
You can see the number on the left the middle?
No?
Make a bigger.
5,000 instances we've tested for sure,
we didn't come close to tapping out what system can do.
I'm quite certain that we could reach many, many multiples
of that number.
I seriously doubt most studios will need that many,
but if you do, give us a call or give Google
a call I'm sure we'll very happy to talk to you.
What's coming next?
I'd mentioned the Deadline has asset awareness right now
but it doesn't really manage assets for you.
We are all over that, we have some prototypes
that we showed at NAB.
We're building a comprehensive system for asset management
that's coming very soon, if you want
to get on the beta for that I'll tell you
how to do that real soon.
Simplified connectivity, I mentioned
the virtual private network that you need to set up.
A lot of studios will probably still want
a virtual private network, but we're
going to come up with a proxy server that
will eliminate the need for a VPN and still be secure,
as an alternative if you want to go that way.
Big news, we are right on the brink of a beta
testing on demand licensing.
So the Deadline licensing can match
the kind of licensing that you see with services
like Google Cloud Platform.
Per minute, per hour, monthly billing models.
It works additively so if you already
have permanent licenses you can just extend beyond them
with the on demand licensing.
We're making the system available to third party
vendors so that smaller plug-in developers and so forth
can piggyback on the system and get on demand licensing
as well.
As I said, beta testing is starting pretty much right
away, so give us a shout if you want to try this.
That's pretty much it.
Thinkbox is building progressive and hybridized workflows
targeting end users with no development experience.
But also remaining extremely flexible
and configurable for very large studios.
We have several very big name, very large studios that
are deploying this kind of set up right now,
and you'll be hearing more about that very soon.
It's our belief that on demand extensions
to existing infrastructure is the right way to go.
With that said, there's lots of different ways
we've seen lots of different solutions here, all of them
are valid, all of them provide value.
And so we have our philosophy as well,
and it is to extend your existing system with on demand.
And that's it.
Here's some links for more information.
The easiest way to contact us is just
go to thinkboxsoftware.com.
That's misspelled, I just noticed that the top, sorry.
I There's my email address, some YouTube videos,
a link to the Cloud Wizard, and of course,
the beta testing link, and lots of people Google
who've been absolutely fantastic helping us with our API
integration credits and so forth,
to make Deadline absolutely rock solid on Google.
And we really look forward to hearing from you
and, like I said try it out, there's no cost.
You can do in a very short amount of time play with it
and see how it works.
Thanks.