Running Optional Applications in Deadline (Oct 27, 2016)

Version: Deadline 8.0

INTRODUCTORY OVERVIEW

Deadline ships with a few optional applications that can be used to enhance your render farm, including:

• Pulse
• Balancer
• Web Service
• License Forwarder

If you’ve chosen to run one or more of these applications, it’s probably safe to assume that the benefits they provide are very important to your workflow. Therefore, it’s probably also safe to assume that you want to ensure that these applications are always running. It just so happens that Deadline has a couple ways to achieve this.

KEEP ‘EM RUNNING FUNCTIONALLY

The first thing you can do to ensure these applications are always running on a machine is to ensure these applications are always running on that machine. There are two simple steps to achieve this:

1. Ensure the Deadline Launcher is running on the machine.
2. Add a few entries to the Deadline Client system configuration file.

RUNNING THE DEADLINE LAUNCHER

The Launcher is always installed as part of the Client Installation, and is automatically configured to start up when the machine starts up. So if you’ve used the Client installer to install the optional applications mentioned above (which is the recommended way to do so), then your work is done!

However, if you’d like to learn more about the Launcher, check out the Launcher Documentation.

CONFIGURING THE DEADLINE CLIENT

For each of the optional applications listed above, you can configure the Launcher to do two things:

• Launch the application when the Launcher starts up. This ensures the application is started alongside the Launcher when the machine starts up.
• Keep the application running, in case it is stopped accidentally or it crashes.

This configuration is done in the Deadline System Configuration File, which can be found in the following locations. Note that the [VERSION] in the path will change based on the Deadline version number.

• Windows: %PROGRAMDATA%\Thinkbox\Deadline[VERSION]\deadline.ini
• Linux: /var/lib/Thinkbox/Deadline[VERSION]/deadline.ini
• OS X: /Users/Shared/Thinkbox/Deadline[VERSION]/deadline.ini

Just open up the deadline.ini file in a text editor, and add the following pairs of settings for each application you are running on the machine. Note that each setting needs to be on its own line in the file.

Pulse:

LaunchPulseAtStartup=True
KeepPulseRunning=True

Balancer:

LaunchBalancerAtStartup=True
KeepBalancerRunning=True

Web Service:

LaunchWebServiceAtStartup=True
KeepWebServiceRunning=True

Proxy Server:

LaunchProxyServerAtStartup=True
KeepProxyServerRunning=True

License Forwarder:

LaunchLicenseForwarderAtStartup=True
KeepLicenseForwarderRunning=True

When you are done, you might end up with a deadline.ini file that looks something like this:

[Deadline]
ConnectionType=Repository
NetworkRoot=\\server\DeadlineRepository8
LicenseMode=Standard
LicenseServer=@lic-server
LauncherListeningPort=17080
LauncherServiceStartupDelay=60
AutoConfigurationPort=17081
LaunchPulseAtStartup=True
KeepPulseRunning=True
LaunchWebServiceAtStartup=True
KeepWebServiceRunning=True
LaunchProxyServerAtStartup=True
KeepProxyServerRunning=True

Now simply save the file, and you’re all set!

A CONTINGENCY BACKUP PLAN

But what happens if the machine itself goes down? To prepare for this situation, it’s possible to set up redundant instances of each application. This way, if the primary instance goes down, a redundant instance can take its place.PULSE, BALANCER, AND LICENSE FORWARDER

PULSE, BALANCER, AND LICENSE FORWARDER

These applications have a Primary/Standby system to handle redundancy. The Primary instance will operate normally, and the Standby instance(s) will sit idle. For example, the Primary Pulse will perform Housecleaning, Power Management, and Statistics Gathering, while the Secondary Pulse(s) won’t do any of this. This is important, because these operations shouldn’t be performed by more than one instance at the same time.

By default, the first instance of the application you run will automatically become the Primary. For example, if you plan to run Pulse on two machines, the first machine that you run Pulse on will be set as the Primary. When you run the second Pulse, it will detect that there is already a Primary, and will prompt you with this:

You can choose to run it in Standby mode, or close it. Note that if the timer for the prompt reaches 0, it will also run in Standby mode. Now that all of your instances are running, you can use the application’s panel in the Deadline Monitor to review your Primary and Standby instances. Simple look at the Primary column:

If you ever want to change which instance is the Primary, simply right-click on a non-Primary instance in the panel and select the Auto Configure option. Note that you will need to be in Super User mode in the Deadline Monitor. You can enter Super User mode from the Tools menu.

In this example, the second machine is now the Primary, and the first is now in Standby mode.

Now that you have your Primary and Standby instances configured the way you want, the last thing you need to do is enable Automatic Primary Election in the Repository Options. Enter Super User mode from the Tools menu, then select Tools -> Configure Repository Options. Click on the Housecleaning page on the left, select the Repository Repair tab, and then enable Automatic Election for the appropriate applications.

With this option enabled, Deadline will automatically promote one of the Standby instances to Primary if the Primary is no longer running. This ensures you suffer little downtime if a Primary instance goes down. You can have as many Standby instances as you want, but the system ensures that you only ever have one Primary.

PROXY SERVER AND WEB SERVICE

These applications don’t have a Primary/Standby system like the other applications above. This is because they are simple web servers, and don’t perform any operations on their own that you would want to limit to a single instance. In fact, you can run as many of these applications as you want, and they won’t impact each other.

However, you probably would prefer to have a proper hierarchy with a single Web Server Proxy that distributes the HTTP requests in a round-robin fashion to your instances. If one of the instances goes down, the request is simply directed to an instance that is still running.

Setting up a Web Server Proxy is a pretty in-depth topic, so we won’t be covering that here, but you can check out our NGINX Web Server documentation for an example on how to do this with NGINX.

FINAL CONCLUSION

As mentioned at the beginning, if you’re running any of these optional applications, it’s important that they remain running so that your workflow isn’t interrupted. Now you can rest easy knowing that Deadline can recover if any of these applications go down.