Pools and Groups

What are Pools and Groups?

Groups can be used to organize your farm based on machine configurations (e.g., specs, installed software, etc). For example, if you have several 64-bit machines with 3ds Max installed, you could assign them to groups like 3dsmax, or 3dsmax_64bit, or simply 3D. Groups have no impact on the order in which Jobs are rendered, they just help to ensure that Jobs render on machines with proper an appropriate hardware/software setup. If you don’t care about grouping your machines, you can simply use the default ‘none’ Group.

Pools are similar to Groups, except that they do affect the order in which Jobs are rendered. Because of this, it is encouraged to use Pools for prioritizing different shows, shots, types of Jobs, etc. If you don’t want to set up Pools on your farm, you can simply use the default ‘none’ Pool. Note that the ‘none’ Pool always has the lowest priority of all the Pools.

Jobs can be added to an optional Secondary Pool. When searching for a Job, a Slave does a first pass using the Primary Pool of the available Jobs. If the Slave doesn’t find any Jobs using the Primary Pool, it then makes a second pass using the Secondary Pool. This system can allow a Job to spread to a Secondary Pool as necessary, and it can also ease the configuration of Pools in the farm if there are lots of Pools and Slaves. An example of this is shown below.

Note that the Secondary Pool feature was designed for Job Scheduling Orders that have Pool listed first, and might not work as expected otherwise. For example, if Priority is listed first, a job with lower priority that’s found during the initial Primary Pool scan will be preferred over a job with higher priority that’s found during the Secondary Pool scan. This is because the Secondary Pool scan is only performed if no jobs are found during the initial Primary Pool scan.

Managing Pools and Groups

Pools and Groups can be managed from the Monitor while in Super User mode (or as a User with the proper User Group privileges). Just select ‘Manage Pools’ (or ‘Manage Groups’) from the ‘Tools’ menu, or from the Slave panel’s right-click menu.

The dialogs are very similar to each other, but the nuances between the two are described below in detail. Note that if you used the Slave panel’s right-click menu to open these dialogs, they will be pre-filtered to just show the slaves that you right-clicked on. They will also show the same columns that are currently being shown in the slave list.

Group Management Dialog

From here, you can manage individual Groups, and assign them to various Slaves. It is a bit simpler than the Pool Management Dialog, which will be covered below in more detail, since it does not have to worry about the order of Groups for a given Slave.

../_images/manage_groups.png

The functions you can perform here are as follows:

  • Groups: This section displays existing Groups and allows you to manipulate them, or create new ones. Your selection here will determine which Groups will be affected by the Group Operations.

    • New: This will create a new Group in the Repository, and allow you to assign the Group to different Slaves. You will be prompted for a name for the new Group. Group names cannot be changed once the Group has been created. Adding a Group with the name of previously Deleted Group will effectively ‘re-instate’ that Group if it hasn’t been Purged yet (see below).
    • Delete: This will Delete all of the selected Groups from the Repository, and enable the option to Purge them (described below).
    • Purge Obsolete Groups on Close: This will purge any obsolete (deleted) Groups from existing Jobs and remove from any Slaves that are currently assigned to it. They will be replaced with the Group selected in the drop down. Note that if you choose not to Purge the obsolete Groups right now, you can always return to this dialog and do it later.
  • Slaves: This section displays a list of all known Slaves that have connected to your Repository. Your selection here will determine which Slaves will be affected by the Groups Operations.

    • Only Show Slaves Assigned to a Selected Group: This option will filter the displayed Slaves to only include the ones that are currently assigned to at least one of the selected Groups.
  • Group Operations: These operations are used to manipulate which Groups are assigned to which Slaves. They typically require a selection of one or more Groups and one or more Slaves to be active.

    • Add: This will add all of the selected Groups to all of the selected Slaves, if it wasn’t already there.
    • Remove: This will remove all of the selected Groups from all of the selected Slaves, if applicable.
    • Copy: This will copy the groups from the selected slave to the clipboard.
    • Paste: This will paste the groups that were copied using the Copy button to the selected slaves.
    • Clear: This will clear all the groups from all of the selected Slaves. This option does not require a Group to be selected.

Pool Management Dialog

The Pool Management dialog functions similarly to the Group Management dialog described above, but with a few added options to deal with managing Pool Ordering for individual Slaves.

../_images/manage_pools.png

The functions you can perform here are as follows. Note that a lot of these overlap with the described Group Management functionality described in the previous section.

  • Pools: This section displays existing Pools and allows you to manipulate them, or create new ones. Your selection here will determine which Pools will be affected by the Pool Operations described below.

    • New: This will create a new Pool in the Repository, and allow you to assign it to Slaves. You will be prompted for a name for the new Pool; not that Pool names cannot be changed once the Pool has been created. Adding a Pool with the name of previously Deleted Pool will effectively ‘re-instate’ that Pool if it hasn’t been Purged yet (see below).
    • Delete: This will Delete all of the selected Pools from the Repository, and enable the option to Purge them (described below).
    • Purge Obsolete Pools on Close: This will purge any obsolete (deleted) Pools from existing Jobs and remove them from any Slaves that may have them in their list. They will be replaced with the Pool selected in the drop down. Note that if you choose not to Purge the obsolete Pools right now, you can always return to this dialog and do it later.
    • Priority Distribution: This graph visualizes how many Slaves have one of the selected Pools as #1 priority, #2 priority, etc. It also displays how many Slaves are not currently assigned to the selected Pools.
  • Slaves: This section displays a list of all known Slaves that have connected to your Repository. Your selection here will determine which Slaves will be affected by the Pool Operations described below.

    • Only Show Slaves Assigned to a Selected Pool: This option will filter the displayed Slaves to only include the ones that are currently assigned to at least one of the selected Pools.
  • Pool Operations: These operations are used to manipulate which Pools are assigned to which Slaves. They typically require a selection of one or more Pools and one or more Slaves to be active.

    • Add: This will add all of the selected Pools to all of the selected Slaves, if it wasn’t already there.
    • Remove: This will remove all of the selected Pools from all of the selected Slaves, if applicable.
    • Promote: This will bump up the selected Pools by one position in all of the selected Slaves’ Pool lists. Any selected Slaves that are not assigned to the selected Pool(s) are unaffected.
    • Demote: This will bump down the selected Pools by one position in all of the selected Slaves’ Pool lists. Any selected Slaves that are not assigned to the selected Pool(s) are unaffected. Note that a Pool cannot be demoted to be lower than the ‘none’ pool – the ‘none’ Pool is always assigned the lowest priority by Slaves.
    • Copy: This will copy the pools from the selected slave to the clipboard.
    • Paste: This will paste the pools that were copied using the Copy button to the selected slaves.
    • Clear: This will clear all the Pools from all of the selected Slaves. This option does not require a Pool to be selected.

Preventing Slaves from Rendering Jobs in the ‘none’ Pool or Group

In some cases, it may be useful to prevent on or more Slaves from rendering Jobs that are assigned to the ‘none’ Pool or Group. For example, you may have a single machine that you want to only render Quicktime Jobs. Normally, you could add this machine to a ‘quicktime’ Group, but if there are noe Quicktime Jobs, the Slave could move on to Jobs that are in the ‘none’ Group. If you want this machine to only be available for Quicktime Jobs, you can configure it to exclue Jobs in the ‘none’ Group.

The option to exclude Jobs in the ‘none’ Pool or Group can be found in the Slave Settings in the Monitor.

Pools and Job Scheduling

How pools affect the Job selection process is best explained through an example. Note that this example relies on a Scheduling Order where Pools are the primary determining factor of scheduling (such as the default Pool -> Priority -> Submit Date scheme).

Say we need to render Jobs for two different shows, and we’ve already created corresponding pools for each show in Deadline:

  • show_a
  • show_b

Now say we have 10 machine in our render farm, and we want to give each show top priority on half of it. To do this, we’d just assign the pools to our Slaves like this:

  • Slaves 1-5:
    1. show_a
  • Slaves 6-10:
    1. show_b

With this setup, if Jobs from both shows are in the queue, then Slaves 1-5 will pick up the Jobs from show_a, while Slaves 6-10 will work on Jobs from show_b. This effectively splits our farm in half, like we desired, but with this configuration Slaves 1-5 would sit idle once show_a finishes production, even if there are plenty of show_b Jobs in the queue. The reverse would also be true if show_b production slows down while show_a is still ramping up.

To accomplish this second goal of maximizing our resources, we’ll assign the Pools to our Slaves as follows:

  • Slaves 1-5:
    1. show_a
    2. show_b
  • Slaves 6-10:
    1. show_b
    2. show_a

Now, Slaves 1-5 will still give top priority to show_a Jobs, and Slaves 6-10 will similarly give top priority to show_b Jobs. However, if there are no show_a Jobs currently in the queue, Slaves 1-5 will start working on show_b Jobs until another show_a Job comes along. Similarly, Slaves 6-10 would start working on show_a if no show_b Jobs were available.

This concept is also extensible to any number of shows/pools, you just have to make sure to have an even Priority Distribution across your farm (the Priority Distribution graph should help with that). Here’s an example of what the Priority Distribution for a 3-show farm with 15 Slaves could look like:

  • Slaves 1-5:
    1. show_a
    2. show_b
    3. show_c
  • Slaves 6-10:
    1. show_b
    2. show_c
    3. show_a
  • Slaves 11-15:
    1. show_c
    2. show_a
    3. show_b

Secondary Pools and Job Scheduling

How secondary pools affect the Job selection process is best explained through an example. Note that this example relies on a Scheduling Order where Pools are the primary determining factor of scheduling (such as the default Pool -> Priority -> First-in First-out option). The Secondary Pool feature was designed for job scheduling orders that have Pool listed first, and might not work as expected otherwise.

Let’s say you have 5 pools and 10 slaves. You want each pool to have top priority on 2 machines, but then be able to spread to the rest of them if they are idle. Without using the secondary pool system, you might have something like this:

  • Slaves 0-1: pool_1, pool_2, pool_3, pool_4, pool_5
  • Slaves 2-3: pool_2, pool_3, pool_4, pool_5, pool_1
  • Slaves 4-5: pool_3, pool_4, pool_5, pool_1, pool_2
  • Slaves 6-7: pool_4, pool_5, pool_1, pool_2, pool_3
  • Slaves 8-9: pool_5, pool_1, pool_2, pool_3, pool_4

This can be tricky to maintain if you have to reorganize pools or new slaves are added to the farm. The new secondary pool system can make this easier:

  • Slaves 0-1: pool_1, pool_all
  • Slaves 2-3: pool_2, pool_all
  • Slaves 4-5: pool_3, pool_all
  • Slaves 6-7: pool_4, pool_all
  • Slaves 8-9: pool_5, pool_all

In this case, all jobs could have pool_all as their secondary pool, and will spread to the rest of the farm if machines become available.