Xgrid est la technologie d'Apple permettant la création de grilles de calculs. Une grille permet de distribuer une ou plusieurs tâches de calculs à différents ordinateurs dédiés ou non. L'avantage d'une grille est de pouvoir distribuer à plusieurs ordinateurs des portions de calculs longs et/ou complexes plutôt que d'effectuer la totalité sur un seul ordinateur.
Toutes les tâches informatiques ne pourront pas forcement tirer avantage d'une grille. En effet, pour pouvoir passer dans la moulinette, il faut que la ou les tâches soient divisibles et que les résultats puissent être ré-assemblés.
Exemple :
Un rendu 3D par PovRay peut être effectué par une grille.
Une scene 3D de 800 pixels de hauteur est divisée en 4 tâches :
1ere tâche - calcul du rendu de H1 à H200
2ème tâche - calcul du rendu de H201 à H400
3ème tâche - calcul du rendu de H401 à H600
4ème tâche - calcul du rendu de H601 à H800
Lorsque tout a été calculé, les résultats sont récupérés puis ré-assemblés.
Une grille est composée obligatoirement par 3 types d'acteurs différents : un contrôleur, des agents, un client. Ces 3 acteurs ne sont pas forcément dédiés, c'est à dire qu'une même machine peut être à la fois contrôleur, agent et client. Le contrôleur est l'élément de gestion de la grille. C'est lui qui va collecter les travaux, les redistribuer par ordre de priorité vers les machines aux puissances de calculs disponibles. Il s'occupe de tout, de manière parfaitement transparente. L'agent est tout simplement une machine qui participe au calcul de la grille. Le client est celui qui va soumettre des travaux à la grille et généralement récupérer le résultat.

Le contrôleur est présent dans Mac OS X Server et dans Mac OS X client. Dans OS X Server, un GUI permet de le configurer. Dans OS X client, pour le mettre en fonction, soit on passe par la ligne de commande, soit on utilise l'utilitaire XgridLite qui rajoute un panneau de contrôle dans les préférences systèmes. * Pour la ligne de commande, le fichier de conf du contrôleur se trouve dans
/etc/xgrid/controller/com.apple.xgrid.controller.plist.default
Pour lancer le contrôleur on tape :
sudo xgridctl controller start
Pour définir que le contrôleur doit être lancé au démarrage de la machine on tape :
sudo xgridctl controller on
* Pour XgridLite (recommandé) Le panneau de configuration est explicite :

Disponibles dans OS X Server et client, ils s'activent dans les préférences systèmes - Partage On défini pour quel contrôleur les agents vont travailler ainsi que les méthodes d'authentification.


Le client doit être une machine OS X. Pour envoyer les travaux dans la grille, il utilisera soit des applications spécifiques (appelées également plugin Xgrid) soit la ligne de commande avec le CLI xgrid.
Lorsque le contrôleur et les agents sont configurés, vous pouvez avoir un oeil sur l'état de la grille grâce à l'utilitaire Xgrid Admin qui fait parti du Bundle "Server Admin Tools" librement téléchargeable sur le site d'Apple.

xgrid -h addr_controleur -p motdepasse_controleur -job submit -in /tmp/working_dir macommande_a_executer
addr_controleur est l'adresse IP ou DNS du contrôleur de grille
motdepasse_controleur est le mot de passe du contrôleur de grille
/tmp/working_dir est le répertoire contenant les fichiers à traiter. Le contenu de ce répertoire sera automatiquement envoyé de votre machine client vers tous les agents engagés dans le calcul par le contrôleur.
nota important sur macommande_a_executer :
Lorsque macommande_a_executer est un chemin absolu, les agents exécuteront le chemin absolu de la commande. C'est à dire que la commande doit exister sur tous les agents engagés. Dans ce cas, les agents doivent tous posséder le même environnement et mêmes PATH.
Lorsque macommande_a_executer est une commande simple, cette commande sera copiée automatiquement du client vers les agents (par le contrôleur). Cela peut poser des problèmes lorsqu'il y a des agents PPC et Intel et que la commande du client n'est pas en binaire universel, ou encore en cas de dépendance de la commande. Les dépendances ne sont pas envoyées vers les agents.
Pour reprendre l'exemple de rendu 3D avec Povray, tous les agents doivent posséder le même Povray. On part du principe que l'on va découper le rendu en 4 tâches.
La scène 3D à rendre est fournie dans les exemples Povray et s'appelle abyss.pov. On désire rendre cette scène sur 1024 pixels de large et 768 de haut.
On découpe le rendu en 4 tâches et donc 4 fichiers .ini (768/4 = 192).
le fichier 0.ini contient :
+Iabyss.pov +Linclude/ +FP +Q9 +a0.3 +H768 +W1024 -D +SR1 +ER192 +Oabyss_0000.ppm
le fichier 1.ini contient :
+Iabyss.pov +Linclude/ +FP +Q9 +a0.3 +H768 +W1024 -D +SR193 +ER384 +Oabyss_0001.ppm
le fichier 2.ini contient :
+Iabyss.pov +Linclude/ +FP +Q9 +a0.3 +H768 +W1024 -D +SR385 +ER576 +Oabyss_0002.ppm
le fichier 3.ini contient :
+Iabyss.pov +Linclude/ +FP +Q9 +a0.3 +H768 +W1024 -D +SR577 +ER768 +Oabyss_0003.ppm
on crée le répertoire contenant les fichiers de travail qui seront envoyés aux agents (on l'appellera [WORKINGDIR], désigné par son chemin absolu ). Ici, il n'y a que les fichiers *.ini à envoyer ainsi que le fichier abyss.pov On place abyss.pov et les 4 fichiers .ini dans [WORKINGDIR]. Les agents travailleront à la racine de ce [WORKINGDIR]. Il faut en tenir compte suivant les commandes et fichiers divers qui seront traités sur les agents.
Nous sommes maintenant prêts à soumettre les 4 travaux à la grille :
xgrid -h addr_controleur -p motdepasse_controleur -job submit -in [WORKINGDIR] /opt/local/bin/povray 0.ini

xgrid -h addr_controleur -p motdepasse_controleur -job submit -in [WORKINGDIR] /opt/local/bin/povray 1.ini

xgrid -h addr_controleur -p motdepasse_controleur -job submit -in [WORKINGDIR] /opt/local/bin/povray 2.ini

xgrid -h addr_controleur -p motdepasse_controleur -job submit -in [WORKINGDIR] /opt/local/bin/povray 3.ini

Chaque envoi de travail vous donnera un identifiant unique de travail ( {jobIdentifier = X; } ). Il est nécessaire de le connaître pour rapatrier le résultat du travail. Vous pouvez toujours vérifier l'état d'avancement des travaux grâce à Xgrid Admin, ou en utilisant le CLI xgrid :
xgrid -h addr_controleur -p motdepasse_controleur -job attributes -id X
Lorsqu'un travail est fini (status = finished), il faut récupérer le résultat. Pour le récupérer, on utilise encore le CLI xgrid :
xgrid -h addr_controleur -p motdepasse_controleur -job results -id X -se fichier_de_sortie_erreur -so fichier_de_sortie\
-out repertoire_de_récupération_du_fichier
X correspond à l'identifiant du travail ( jobIdentifier ). Dans repertoire_de_récupération_du_fichier, vous y trouverez à l'issue les fichiers qui ont été calculés soit : abyss_0000.ppm, abyss_0001.ppm, abyss_0002.ppm et abyss_0003.ppm Sous OSX, les fichiers .ppm peuvent être ouverts avec GraphicConverter. Pour obtenir l'image complète, on utilise l'utilitaire combineppm :
combineppm abyss > abyss.ppm

Une grille peut posséder des agents locaux ou distants (LAN et WAN). Il faut, en plus des temps de calculs, prendre en compte la bande passante et le temps de transfert des fichiers à traiter, ainsi que les fichiers résultats entre client -> contrôleur -> agents -> contrôleur -> client Il faut également bien juger de l'opportunité du nombre de tâches à effectuer pour un travail. Découper l'image d'exemple en 4 parties sera probablement plus performant que de la découper en 150 (pour notre exemple). Si par contre l'image est très grande (plusieurs milliers de pixels de hauteur) et que le nombre d'agents puissants est important, il sera plus intéressant d'augmenter raisonnablement le nombre de tâches. Ces infos ne sont pas exhaustives...
A partir du CLI xgrid, on peut batcher les travaux (voir man xgrid batch xml ) ou créer des plugins avec un GUI pour que l'utilisateur ne se prennent pas trop la tête avec la ligne de commande