DrQueue - Теоретическая часть.

Итак, без теории - никуда. Поэтому, разберемся с доками на источнике.
Далее по тексту:
Master - мастер-машина,управляющая.
Slave - ведомая машина, вычислительный узел.
По диаграмме видно, что система состоит из следующих элементов:
Master - хранит список Slave и список работ, несколько Slave-узлов, Clients - машины клиентов и общее сетевое хранилище, которое используют участники процесса.
Общее хранилище само по себе не является частью DrQueue, это обычный сетевой ресурс, управляемый операционной системой и "раздаваемый" машинам с помощью протоколов nfs, cifs/samba или других.
Хранилище вообще может быть распределено на нескольких машинах, для DrQueue это не имеет значение.
Разберемся с составляющими.
Master.
Master опрашивается Slave-машинами и Client-ами. Узлы Slave также обновляют информацию о своем состоянии (какие работы запущены, средняя загрузка, доступные процессоры и т.д). Мастер (Master) содержит всю информацию о работах и вычислительных узлах и поэтому должен работать непрерывно и бесперебойно.
К Мастер-машине может быть сделано множество типов различных запросов. Например, клиентские машины могут запросить список работ, список вычислительных узлов (slaves), подробности о работе, выполняемой одним из них и так далее.
Master непрерывно прослушивает TCP порт и ожидает запросы. Все запросы (также те, что посылаются узлам) не аутентифицируются и поэтому порт следует защитить от недоверенных узлов сети.
Общее сетевое хранилище используется Master-машиной для хранения собственных лог-файлов, поэтому их можно "прочитать" и проанализировать с любой машины ,которая имеет доступ к хранилищу.
Slaves.
Каждый slave хранит и периодически обновляет на Master-машине собственную информацию, статус, лимиты, задачи и т.д.
В состоянии ожидания (idle) и доступности для рендер-задач он запрашивает у Мастера задачи, которые подходят для работы, совпадающей с профилем slave-а (пул, операционная система, ограничения памяти и т.д).
Как только Мастер "отдает" задачу Slav-у, он (slave) начинает принимать всю информацию, относящуюся к работе и задаче (расположение скрипта работы, тип работы, номер кадра\задачи, всю информацию связанную с этим типом работы как например директория проекта Maya, сцена ... и т.д.
Располагая этой информацией, slave создаст новый процесс с соответствующими переменными окружения и начнет выполнять скрипт работы связанный с ней.
Этот скрипт работы необходимо разместить в любом месте общего хранилища, чтобы все вычислительные узлы (slaves) могли получить его по одинаковому адресу (пути).
"Новосозданный" процесс запустится на выполнение и сохранение лог-файла задачи в директории лог-файлов DrQueue (внутри его собственной директории работ).
Пока процесс не завершит работу, slave-узел будет периодически проверять его работу и существование на предмет некорректного его завершения.
Когда процесс завершится, родительский процесс slave-машины примет статус выхода потомка и отошлет всю эту информацию Master-у. Тот в свою очередь примет выполенную задачу и статус завершения. Взависимости от этих значений эта задача может быть перенаправлена автоматически с пометкой "Finished" (Завершена) или "Error"(Ошибка). Эта информация будет доступна для всех client-машин.
Slave-узлы также открывают другой TCP порт для приема специфичных для них запросов. Причина этого в том, что slave монопольно может изменять собственные параметры. Мастер лишь принимает их и даже если их поменять на Мастер-машине, они будут перезаписаны slave-узлов при очередном периодическом обновлении. Изменения внесенные на Мастер-машины будут перезаписаны и утеряны (стерты).
Таким образом slave-узлы ограничивают набор запросов на изменение различных аспектов их работы, например установка новых лимитов или включение/отключение узла.
Когда исполняется один из этих запросов, мастер сможет принять результаты действия запроса при следующем обновлении.
(Даже в случае если изменяются некоторые параметы slave при различных частях выполнения программы когда необходимо корректно выполнять следующие команды. Пример этого - когда задачи раздаются slave-узлам и необходимо проверить некоторые лимиты. Но даже эта информация будет перезаписана позже. Это просто быстрый путь для исправления несогласованности и коллизий. В случае отказов при этих действиях будет поступать уведомление и узлы поступят соответствующе).

Рендер процесс.
Когда вычислительный узел создает дочерний процесс, который будет выполнять скрипт работы вы должны понимать, что скрипт будет исполняться локально на этом узле и все составляющие элементы работы должны быть ему доступны.
Эти элементы включают в себя правильные пути, бинарные файлы программ, которые булет запускать скрипт (как например программа для рендеринга), плагины, текстуры, сцены, директории вывода и т.д.
Все, что может потребоваться для успешного рендеринга должно быть доступно каждому узлу по одинаковому для всех пути.
Вот основная причина для Общего сетевого хранилища. С его помощью вся информация сохраняемая там будет доступна вычислительным узлам и они смогут работать со скриптами работы без проблем.
В кросплатформенной рендеринг-среде скрипт работы будет отвечать за преобразование или трансляцию значений им получаемых в соответсвующие и необходимые операционной среде параметры.
Особенно важен этап трансляции пути, когда наряду с windiws системами вы используете другие не windows системы.
На Unix-подобных системах вы можете легко создать символические ссылки чтобы сделать все пути корректными даже если эти пути отличаются на разных машинах.
Clients
Клиенты (Clients) - это любые программы которые могут запросить информацию об очереди у мастера или послать иные запросы на выполнение различных действий как например переорганизация очередей, включение slave-машин в работу, удаление работы и т.д.
drqman один из таких клиентов но есть множество других как например инструменты для работы из командной строки (sendjob,jobinfo,ctask и так далее) и любая другая программа, которая может использовать библиотеку DrQueue (libdrqueue), как например python скрипты, использующие модуль drqueue (как например DrKeewee).
Эти клиенты могут выполнять все типы действий с очередью, которые доступны в библиотеке. Нет ограничений на тип запроса, который может быть выполнен клиентом, но неверные запросы могут привести к непредсказуемым результатам как например упоминавшаяся ранее ситуация об обновлении информации о slave на master-машине.
Вы будете ожидать, что изменяя информацию об узле на мастер-машине вы поменяете настройки slave-машины, но это надо будет делать на самой slave - машине. (Однако некоторые запросы мастера к узлам могут заставить узел изменить параметры)
DrKeewee
Случай DrKeewee особенный (просто потому, что он единственный сам по себе) потому что это клиент, который мог бы принимать инструкции с удаленного хоста и выполнять их локально.
Так как он предоставляет вэб-интерфейс для отображения статуса очереди, он может выполнять в одно время различные запросы типа drqueue (с помощью python модуля) как от мастера так и от slave.
Это отличный путь для предоставления например доступа только на чтение статуса очереди. Вы можете также использовать другие методы http аутентификации для предоставления различного уровня доступа.
Всегда есть возможность адоптировать его функциональность к своим потребностям.