The Backburner Monitor allows pausing, restarting, and reassigning jobs and tasks to different render nodes as well as creating and managing render node groups and verification that the servers are up and running. With the Windows version, it can be helpful to install the Backburner Monitor on the same workstation so you can start the manager and monitor and work out any connection configuration. Then each server can be observed from one central location.
The Backburner network can be monitored via a Windows-based or browser-based monitor.
The Web Monitor allows users to manage jobs and render nodes using a browser. Its advantage over the Windows Monitor is that it can run on any workstation with a web browser, and it has little impact on the Backburner Manager. Data from the Manager is served by a web server on the same machine.
By default, end-users have complete control over the jobs that they submit to Backburner. To control all jobs on the Backburner network, you must log on to the server with administrator privileges. Generally, the name used to log in to the workstation is associated with all jobs submitted to Backburner from that workstation. However, some applications pass on the account name used to start the application instead. In Smoke, for example, if the artist starts the application as user smoke, smoke owns the jobs. It is therefore necessary to create accounts on the web server with the same names. By matching the log in or application user names with the web server user names, you ensure the artist has control over the jobs he or she submits. To launch the Backburner Web Monitor:
Before users can access the Web Monitor, you must install the following software on the workstation running the Backburner Manager:
Users without administrator privileges can fully manage their own jobs, but can only monitor the status of other jobs in the Web Monitor. Those with administrator privileges can manage all jobs and render nodes. To assign administrator privileges to a Web Monitor user account: Edit the Wiretap server configuration file, wiretap.cfg, located in the backburner directory of the application data directory. In the [SECURITY] section use the BackburnerAdministrators keyword to add users to the admin group. It can be a comma-separated list.
To configure the Web Server to connect to the Backburner Manager:
To set up access to the Web Monitor:
Configure IIS and set the security for the Web Server:
Test the setup:
Setting up access to the Backburner Web Monitor requires that you create Backburner Web Monitor user accounts. The Backburner web server requires all users to provide a login name and password to access the Backburner Web Monitor. The default user account backburner is created during the installation of the Backburner Manager. The password associated with this account is backburner.
Create a Backburner Web Monitor user account:
Users without administrator privileges can only monitor the status of Backburner jobs in the Backburner Web Monitor. Users with administrator privileges can actively manage all jobs and render nodes. The default user account backburner created during the installation of the Backburner Manager has administrator privileges by default. If you are creating new user accounts, you may wish to remove administrator privileges from the default account, for security. Alternately, change the password.
Give administrator privileges to a Backburner Web Monitor user account:
The Jobs tab presents high-level information relating to all jobs associated with the selected Backburner Manager. Use it to view and control the jobs you submit to Backburner, as well as to view jobs submitted to Backburner by other Autodesk applications. Double-click any job in the list to view its details and settings.
All users can activate, suspend, and restart all jobs. Users can archive/restore, modify settings and delete their own jobs, while admin users can perform all actions on all users' jobs.
To find jobs and view their status:
Suspend a rendering job:
Restart a job:
To delete a job:
To set email notifications for a job:
The Servers tab provides an overview of the general health of each render node, the adapters installed on it, and so on. It also provides access to server details, where you can set an availability schedule, for example.
| Server Task | Admin User |
|---|---|
| Shift jobs between servers/server groups | • |
| Delete absent server | • |
| Set server availability schedule | • |
| Create server groups | • |
| Manage server group settings | • |
View render node status:
Shift a render node:
Delete a render node:
To help with network traffic, you can schedule the availability of a render node:
A server group is a named collection of render nodes that is treated like a single node. By default, jobs are submitted by creative applications to the Backburner network as a whole. The Backburner Manager determines to which render nodes they are sent. Some Autodesk applications can be configured to submit jobs to a server group. Server groups can be used to implement a job-processing strategy. For example with a render farm consisting of eight Burn nodes, four GPU-enabled, it would be useful to have two server groups, one each for the non-GPU and GPU-enabled Burn nodes.
Server groups do not restrict the ability to assign render nodes to particular jobs. When a creative application is configured to submit its jobs to a server group, additional nodes can be assigned to it, automatically, or manually, once the job is on the network. Conversely, you can always remove individual nodes from a job, regardless of their relationship to a server group.
To create a server group
To assign a server group to a job:
To delete a server group: On the Server Groups tab, select the server group of interest and click Delete.
Use the Manager tab to set options related to the Backburner network, such as logs, server assignments criteria, job retries, and the tasks performed when a job finishes, such as archiving.
| Area | Field | Description |
|---|---|---|
| Logging and Notification | Logging Level |
|
| Default Mail Server | The smtp mail server through which all email notifications for this manager are sent. This can be overridden for individual jobs. | |
| Server Assignment | Max Concurrent Jobs | The maximum number of jobs Backburner will send out for processing on the render farm at the same time. |
| Task Failures | Retry Count | The number of times the Backburner Manager attempts to restart a job on a server that has failed to complete its processing. A failed job may be returned by Backburner to the job processing queue. Set to zero (0) to have job processing halted on the server after its first failure. Default is 3. |
| Time Between Retries | The time before the Backburner Manager attempts to re-start a job on a server that has failed. Works in conjunction with Retry Count. Default is 30 seconds. | |
| Job Handling | On Job Completion | Specifies what happens to a job once it has successfully completed:
|
The Archive tab presents information pertaining to all archived jobs. From here, you can delete and re-activate old jobs. Archiving removes completed jobs from the job queue. It reduces clutter. Its advantage over deleting completed jobs is in preserving all the information needed to re-submit the jobs at a later date. You can also restore an archived job to examine job details, such as the render nodes that processed it. This can assist in troubleshooting. Archiving can also be part of a facility backup strategy. The job archive contains metadata (job details) only—it does not contain source material or rendered frames. Archiving a job has no effect upon the associated media. Jobs can be archived automatically, when the manager has been configured to do so.
Archive a job:
The Backburner Manager maintains a database, which it updates with every change of state of the render nodes. It then broadcasts the changes to every workstation running a Backburner Windows Monitor, whether the end-user is actively viewing it or not.
The Windows Monitor can be launched from any Windows workstation on the network where it has been installed.
The first Windows Monitor making the connection has full control over the job queue and Backburner network—that is, “queue control”. Subsequent connections by other Windows Monitors have more limited functionality. It is recommended to run Windows Monitor on not more than one or two workstations.
Run the Backburner Windows Monitor:
The first monitor establishing a connection to the manager is automatically granted queue control, and can perform all job-related activities, including stopping, restarting, or deleting jobs. Subsequently, other monitors connect in read-only mode, allowing them to observe the activity on the Backburner network only.
Suspend and reactivate a job, select it, then do one of:
Modify job settings:
For example, enabling for frame-based render jobs results in each render node receiving a block of several frames to render at once. Disabling results in frames being sent one at a time.
For this setting to have an effect, you must also enable Override Task Blocks Setting.
Only servers in the specified server group will work on the given job, unless the group is set to use idle non-group servers.
Restarting a job halts all processing for the job, clears the server of all job-related temporary files (including completed tasks), and restarts the job from its first task. It is identical to resubmitting the job from the creative application, without the need for that application to be running.
Cloning a job creates a 100% duplicate job that is independent of the original, but inherits all of its qualities, including its status and settings. Cloning is a convenient means for experimenting with changes to job settings or testing render nodes, since changes made to the clone do not affect the original. Cloning is allowed, but not generally recommended. For efficiency, the Visual Effects and Finishing applications pre-allocate space on the destination storage device for the frames resulting from all Burn and background I/O jobs. Since the clone is a duplicate of the original job, its results overwrite those of the original job.
Archiving conveniently removes completed jobs from the job queue. It is a practical means for keeping the job queue organized by reducing clutter. Its advantage over deleting completed jobs is in preserving all the information needed to re-submit the jobs at a later date. You can also restore an archived job simply to examine job details, such as the render nodes that processed it. This can assist in identifying problems—if unexpected or unsatisfactory results occurred, for example. Archiving can also be part of a facility backup strategy, since the archive represents a job history, in compact form. Note, however, that the job archive contains metadata (job details) only—it does not contain source material or rendered frames. Note that archiving a job has no effect upon the associated media. The job archive contains job metadata only; that is, it contains the information needed to restart a job, but not the source media.
By default, archived jobs are saved to the Network\Archive folder where the Backburner Manager is installed.
Archive a selected job:
Delete a selected job:
To view render node status:
Customize the render node list:
To shift a render node:
Use the following procedure to delete offline render nodes from the system. Deleting a render node removes its entry from the database maintained by the Backburner Manager. It does not delete any software from the node itself.
To delete a render node:
To help manage network traffic, schedule the availability of a render node:
A server group is a named collection of render nodes that is treated, for the most part, as if it were a single node. By default, jobs are submitted by creative applications to the Backburner network as a whole. It is the Backburner Manager that determines the specific render nodes to which they are sent, based on job type and node availability. However, certain Autodesk applications can be configured to submit jobs to a specific server group.
Server groups can be used to implement a job-processing strategy. For example, consider a facility with two Visual Effects and Finishing applications, and a render farm consisting of eight Burn nodes, four of which are GPU-enabled. In such a situation, you might create two server groups, one each for the non-GPU and GPU-enabled Burn nodes. By assigning each Visual Effects and Finishing workstation to a different server group, you can reserve the GPU-enabled Burn nodes for the workstation with higher priority or more demanding jobs.
Server groups do not restrict the ability to assign render nodes to particular jobs as you see fit. When a creative application is configured to submit its jobs to a server group, additional nodes can be assigned to it, automatically, or manually, once the job is on the network. Conversely, you can always remove individual nodes from a job, regardless of their relationship to a server group.
Two kinds of server groups can be created, local groups and global groups. In almost all cases, you will want to create global server groups only. Local groups serve a particular purpose for 3ds Max, under a specific Backburner configuration.
For information on configuring a creative application to submit jobs to a server group, see the User Guide for the application of choice.
Create a server group:
Assign a server group to a job:
Shift a server group between two jobs:
To delete a server group:
Use the following procedures to create or delete a named collection of render nodes, called a server group, and to assign a server group to a job. Two kinds of server groups can be created, local and global. Apart from some special cases with 3dsMax, global server groups are used. To configure a Visual Effects and Finishing application to submit its jobs to a server group, set the BackburnerManagerGroup keyword in the application's init.cfg.
By default the nodes in a server group are available to all jobs submitted to the Backburner network. A server group can be configured to make use of idle non-group render nodes. A server group can be configured to give priority to the jobs submitted to it specifically. Once configured, when the Backburner Manager receives a job for a server group, non-group jobs are immediately suspended, freeing up the nodes for the server group job.
To create a server group:
To assign a server group to a job:
Shift a server group between two jobs:
To delete a server group, in the Global Groups list, right-click the render node group of interest and choose Delete Group. The render nodes themselves remain untouched, and can be assigned to other groups, as needed.