Download Boris Daix

conditionné en archive, la copie et recopie de fichiers, et le partage de mémoires de masse sont
des exemples de cette complexité. Telles que les cas de déploiement présentés les ont illustré, les
abstractions de ces cas complexes sont cependant difficiles à expliciter dans leur totalité car elles
ne sont pas prévues pour être parcourues par des humains mais bien par les acteurs du modèle
ODD.
Le modèle ODD d’automatisation du déploiement d’applications propose un découpage des
rôles qui permet à chaque acteur d’avoir un fonctionnement simple, quelle que soit la complexité
des cas de déploiement traités. Ce fonctionnement simple pourrait cependant être enrichi. Tel
est par exemple le cas des gestionnaires Conseiller et Exécuteur.
Le gestionnaire Conseiller pourrait par exemple ajouter des requêtes afin de tester la présence
d’éléments de contenu, ce qui pourrait éviter la mise en attente d’éléments de contenu produisant
les premiers. Par exemple, un fichier de résultats peut avoir été associé avec un répertoire et
mis en attente alors qu’il est déjà présent dans ce répertoire. Il n’aurait pas encore été abstrait,
produit par exemple par une entité active de l’environnement de déploiement. Une fois exécutée
par le gestionnaire Exécuteur, ces requêtes de test ont un résultat : l’état TERMINÉ ou CORROMPU.
Dans le premier cas, Conseiller peut changer directement l’état du fichier pour l’état TERMINÉ
afin de signifier sa présence. En revanche, si ces requêtes sont en échec, il doit décider quels
éléments de contenu en amont mettre en attente.
Le gestionnaire Exécuteur pourrait fournir un mécanisme de tolérance aux défaillances. Puisqu’il analyse les éléments d’instance à la portée des requêtes qu’il exécute avant d’exécuter les
requêtes suivantes, Exécuteur peut exécuter de nouveau des requêtes en échec. Par exemple,
si l’élément Blob de copie d’un répertoire quitte son état d’attente pour être en échec après
que Exécuteur ait exécuté la requête de copie correspondante, alors Exécuteur peut exécuter à
nouveau cette requête avant d’exécuter les requêtes suivantes dans le flot des requêtes que la
tâche agrège. Si le problème persistait, alors il mettrait la tâche elle-même en échec.
6.7
Conclusion
Les trois cas de déploiement traités ci-dessus ont permis de valider l’architecture de déploiement dynamique ODD/SAMURAAIE. Dans les trois cas, cette architecture a en effet traité
l’allocation de ressources, l’installation de l’application sur les ressources allouées, et l’exécution
de l’application installée sur ces ressources. De plus, ces trois cas ont introduit les propriétés de
parallélisme, d’hétérogénéité, et de dynamicité des systèmes informatiques à haute performance,
propriétés que l’architecture ODD/SAMURAAIE sait prendre en charge.
La station, la grappe de stations, et la grille de stations sont toutes parallèles. Les interconnexions de la grappe et les grappes de la grille sont hétérogènes. La grappe et la grille sont
également dynamiques. De même, les applications parallèles, paramétriques, et en flot de travail
sont toutes parallèles ou réparties. L’application en flot de travail est hétérogène. Les applications
paramétriques et en flot de travail sont dynamiques.
130