Retrouvez cet article dans : Linux Magazine 102
Un informaticien moyen a souvent plusieurs ordinateurs chez lui, au moins une tour et un portable.
Souvent coûteux, nos ordinateurs deviennent assez vite obsolètes. Pourtant, si l’on fait la somme des processeurs, serveurs compris, que l’on a chez soi, on s’aperçoit que l’on a une puissance de calcul inexploitée.
Dans cet article, nous allons voir comment mettre en place une ferme de rendu (render farm) pour Blender et utiliser tous nos petits processeurs pour calculer nos scènes pleines de raytracing.

Ici, tous les ordinateurs sont sous Ubuntu 7.10 (Gutsy) ce qui n’empêche pas DrQueue de piloter d’autres systèmes d’exploitation (Mac OSX, Windows, BSD, Irix...). N’utilisant pas les autres OS chez moi, je n’ai pas testé leur intégration dans la ferme, mais il est tout à fait possible d’avoir des esclaves hétérogènes.
De même, DrQueue ne se limite pas aux calculs de scènes Blender. Il peut calculer des scènes Maya, Lightwave, Mental Ray, Softimage XSI, Mantra/Houdini, Turtule, BMRT, 3Delight, Pixie, Aqsis, After Effects, Shake, Nuke, Terragen et, d’après la dernière news du site, l’interface web de DrQueue permettrait de calculer des scènes 3DSMax.
Mais, restons dans le sujet avec le logiciel libre Blender, car c’est le but de cet article...
Comment ça marche DrQueue ?
Master & Slaves
Pour fonctionner, ce système se base sur un maître et des esclaves. Le maître peut être un ordinateur sans réelle puissance de calcul et les autres ordinateurs sont lancés en esclaves et pilotés par le master.
Toutefois, on peut lancer, en plus, un processus esclave sur le maître pour ne pas perdre inutilement sa puissance de calcul.
Le premier réflexe serait de faire un sudo apt-get install drqueue sur toutes les machines. Que nenni !
Contrairement à ce que l’on pourrait penser, on n’installe pas DrQueue sur toutes les machines, mais seulement sur la machine maître. Ensuite, on configure les esclaves pour qu’ils puissent lancer les scripts de DrQueue, à travers le réseau NFS, directement sur le maître.
Une fois que l’on a compris ce principe, les choses deviennent beaucoup plus claires.
Les trois scripts principaux sont master.linux.i686, slave.linux.i686 et drqman.linux.i686. Le dernier est une interface GTK qui nous permettra d’administrer graphiquement le cluster.
Sur cette figure, nous avons des ordinateurs de puissances différentes qui vont pouvoir calculer une scène de 250 images par exemple. Une fois une image finie, DrQueue va redonner une nouvelle image à un ordinateur libre et, chose intéressante, si un nouvel esclave arrive, en cours de calcul, dans le parc, il est automatiquement sollicité par le master et mis au boulot.
Bien sûr, certains processeurs iront plus vite que d’autres, mais l’intérêt est de faire travailler tout le monde pour gagner un temps précieux.
On peut donc estimer le temps de calcul avec les facteurs suivants :
Si l’ordinateur A calcule une image de notre scène en 60 secondes, ça nous donnera environ 4 heures de calcul pour nos 250 images.
Si le B calcule une image en 120 secondes, il devrait finir les 250 images en 8 heures.
Si les deux ordinateurs travaillent ensemble, on a un rapport approximatif d’1/3 pour le temps de calcul, soit 3h de calcul au lieu de 4h si l’ordinateur A avait calculé ça tout seul.
Une heure de gagné, c’est toujours ça !!.

Dans un parc de 10 machines de puissances équivalentes, en reprenant les caractéristiques de l’ordinateur A pour tous les ordinateurs, vous calculerez votre scène théoriquement en 25 minutes. Théoriquement, car certaines images sont plus complexes et donc plus longues à calculer, mais bon même 30 ou 40 minutes au lieu de 4 heures, ça c’est Palace !!
Maintenant, scrutez l’horizon et imaginez les possibilités offertes par les 70 machines d’une université qui restent souvent allumées la nuit sans être utilisées.
Un petit cron bien placé et hop : à 0h00 tous les travaux en attente sont calculés par une armée de processeurs.
Pour ceux qui cherchaient un argument pour investir dans autre chose que des licences 3DS (oups !).
Assez de théorie, on installe
Avant toute chose, il faut avoir le même utilisateur sur toutes les machines et éviter de lancer les scripts en ROOT pour des raisons évidentes de sécurisé souvent citées dans ce magazine.
On commence par la machine maître, vu que c’est là qu’il y a le plus de boulot.
Nous allons installer quelques paquets nécessaires au fonctionnement et, bien sûr, Blender qu’il ne faut pas oublier.
sudo aptitude install scons blender nfs-user-server nfs-common tcsh
Pour avoir la dernière version de DrQueue, téléchargez les sources .tgz sur le site http://www.drqueue.org, décompressez-les dans votre répertoire personnel et rendez-vous dans ce nouveau répertoire.
cd /home/utilisateur/drqueue
À noter que l’on utilisera scons, car il n’y a pas de make dans les dernières versions.
Pour installer DrQueue dans /usr/local/drqueue, nous lancerons la commande suivante :
scons PREFIX=/usr/local install
Ce même emplacement sera le point de montage NFS qui permettra aux autres ordinateurs de lancer les scripts. Il doit donc appartenir, avec ses sous-dossiers (-R), à votre utilisateur.
sudo chown -R utilisateur.utilisateur /usr/local/drqueue
Configuration de NFS
Nous créons un répertoire render dans le répertoire de votre utilisateur.
mkdir /home/utilisateur/render
Ce répertoire sera le point central de rendu pour tous les ordinateurs de la ferme : c’est là que les images calculées seront déposées.
Pour les fanas des fluides et autres particules, pensez à stocker les calculs de simulation physique dans un sous-répertoire de render de façon à ce qu’ils soient accessibles en chemin absolu par les autres machines (ex : /home/utilisateur/render/fluides/).
Nous verrons plus loin comment adapter vos scènes Blender.
On configure maintenant le serveur NFS pour donner accès à drqueue et render aux ordinateurs esclaves.
Nous partons du principe que le maître a l’adresse IP 192.168.1.1 et que deux esclaves ont les IP 192.168.1.2 et 192.168.1.3. À vous d’adapter suivant votre réseau.
Si l’on a beaucoup de machines, on peux déclarer un réseau local 192.168.1.*(rw,async). Attention cependant à la sécurité.
vi /etc/exports
On ajoute les lignes :
/home/utilisateur/render 192.168.1.2 192.168.1.3(rw,async) /usr/local/drqueue 192.168.1.2 192.168.1.3(rw,async)
Configuration des variables d’environnement
Pour que tous les ordinateurs aient les mêmes références au niveau des chemins vers les scripts, il faut stocker ces informations dans des variables qui seront initialisées au démarrage des machines. Nous configurons ici le maître pour qu’il puisse lancer un processus esclave sur lui-même et nous verrons plus loin que les esclaves auront aussi ces lignes dans leur .bashrc.
vi /home/utilisateur/.bashrc
Ajoutez à la fin du fichier :
#DRQUEUE export DRQUEUE_ROOT=/usr/local/drqueue export DRQUEUE_TMP=/usr/local/drqueue/tmp export DRQUEUE_MASTER=192.168.1.1 Les fichiers de configuration de DrQueue :
Là encore, il faut indiquer aux trois logiciels de DrQueue où se trouvent les exécutables, les logs et les références dont ils ont besoin. On va donc simplement modifier ces fichiers.
vi /usr/loca/drqueue/etc/master.conf logs=/usr/local/drqueue/logs tmp=/usr/local/drqueue/tmp db=/usr/local/drqueue/db bin=/usr/local/drqueue/bin etc=/usr/local/drqueue/etc vi /usr/local/drqueue/etc/slave.conf logs=/usr/local/drqueue/logs tmp=/usr/local/drqueue/tmp vi /usr/loca/drqueue/etc/drqman.conf logs=/usr/local/drqueue/logs tmp=/usr/local/drqueue/tmp db=/usr/local/drqueue/db
Configuration des machines esclaves
Les esclaves ont besoin des paquets suivants pour dialoguer avec le maître :
sudo aptitude install blender nfs-user-server nfs-common tcsh libgtk2.0-dev
Sur chaque machine, nous devons reproduire les mêmes chemins vers drqueue et render avec les mêmes permissions.
mkdir /home/utilisateur/render sudo mkdir /usr/local/drqueue sudo chown -R utilisateur.utilisateur /usr/local/drqueue
Comme pour le maître, on ajoute les variables d’environnement à la fin du fichier .bashrc
vi /home/utilisateur/.bashrc #DRQUEUE export DRQUEUE_ROOT=/usr/local/drqueue export DRQUEUE_TMP=/usr/local/drqueue/tmp export DRQUEUE_MASTER=192.168.1.1
et pour finir, les montages NFS dans les fstab.
sudo vi /etc/fstab 192.168.1.1:/home/utilisateur/render /home/utilisateur/render nfs user,noauto 0 0 192.168.1.1:/usr/local/drqueue /usr/local/drqueue nfs user,noauto 0 0
Pour être sûr que tous les services ont bien été relancés et que les variables sont prises en compte, on va redémarrer toutes les machines (dans le doute reboot :p )
Voilà , la ferme est prête à l’emploi.
Utilisation du cluster
Avant toute chose, il faut monter les répertoires NFS de tous les esclaves, car, dans cet exemple, ils sont en noauto.
Adapter la scène
Nous allons calculer la scène image par image et, si l’on souhaite faire une vidéo, il suffira d’utiliser le séquenceur de Blender ou un programme comme Mencoder pour convertir ces images en une vidéo.
Après avoir indiqué à votre scène .blend de faire un export d’images .tga (ou autre) dans /home/utilisateur/render, enregistrez-la dans ce même répertoire.
Il n’est pas nécessaire de mettre Threads à 2 si vous avez des dual core, car DrQueue donne une image à calculer à chaque " core ", comme s’il s’agissait d’un processeur à part entière.

Pour ceux qui veulent utiliser des fluides, modifiez le paramètre d’export avant d’appuyer sur le bouton " BAKE " de façon à ce que les calculs de simulation soient accessibles aux autres machines.

Si vous avez des textures, les autres ordinateurs ne les trouveront pas si elles ne sont pas dans le répertoire render. Le plus simple est de packager votre scène pour qu’elles soient intégrées à votre fichier .blend.
Allez dans Fichier/pack data et enregistrez de nouveau la scène.
Lancement des processus
Sur la machine maître, on lance un premier terminal qui fera tourner le processus maître :
/usr/local/drqueue/bin/master.Linux.i686
Si l‘on veut que la machine maître calcule, elle aussi, on ouvre un autre terminal et on lance :
/usr/local/drqueue/bin/slave.Linux.i686
Sur les esclaves, on lance le même script :
/usr/local/drqueue/bin/slave.Linux.i686
Sur une machine avec un bureau Gnome ou autre et avec la libgtk2.0-dev installée, on lancera DrQman :
/usr/local/drqueue/bin/drqman.Linux.i686
Note :
Il est possible de faire un lien entre /usr/local/drqueue/bin et /usr/bin si l’on veut pouvoir lancer les commandes sans taper le chemin complet.
On doit voir nos ordinateurs dans l’onglet " computer ". Ici, il y a un dual core qui vaut 2 processeurs.

Pour créer un JOB (travail), une fois dans l’onglet " jobs ", faites un clic droit dans la zone blanche " NEW  JOB".

Pour paramétrer votre Job, suivez ces étapes :
- sélectionnez " Blender " dans le panneau déroulant ;
- donnez un nom au job ;
- indiquez le nombre d’images à calculer ;
- ensuite, sélectionnez le fichier
.blendque l’on a mis au préalable dans/home/utilisateur/render ; - décochez les OS qui ne sont pas utilisés (esclaves) ;
- cliquez sur générer le script ;
- cliquez sur le bouton " submit ".

En rafraîchissant la page, on voit que notre JOB est lancé et que les ventilateurs des machines s’emballent : le calcul est bien parti.
On peut avoir des détails en faisant un clic droit sur le job, voir les images finies et celles en cours de calcul.
Si tout se passe bien, les images sont exportées dans /home/utilisateur/render et vous devriez les voir apparaître au bout de quelques minutes.
Si, dans les détails du Job, les images sont surlignées en rouge, vérifiez les droits en écriture dans render.

Conclusion
Vous avez maintenant le droit de vous tromper dans une animation sans perdre 5 heures de calcul et vous faire des cheveux blancs avant l’âge ;)
Cet article est loin de lister toutes les possibilités de ce logiciel. Entre autres, le fait d’avoir une liaison (binding) Python permet de créer ou d’adapter des scripts et, par exemple, de faire calculer une seule image par tous les ordinateurs.
Une interface web est aussi disponible, ce qui peut être intéressant pour des accès internet au cluster et, avec les débits actuels, on pourrait envisager de faire du calcul avec OpenVPN.
Pour la petite info, DrQueue a été utilisé par des sociétés de production audiovisuelle dont Orange Open Movie Project pour le film d’animation Elephants Dream que l’on peut télécharger légalement (Licence Créative Commons) sur le site http://elephantsdream.org.
Voilà , j’espère que cet article vous a plu et qu’il vous sera utile...
Merci à l’équipe de Gnu/Linux Mag.
Références
- Sources, http://mediatux.com
- Forums, adaptations de différentes docs, http://drqueue.org
 Retrouvez cet article dans : Linux Magazine 102


