La conception du simulateur

Les SEs sont conçus pour traiter deux types de requêtes de transfert: download et upload (avec ou sans délai d’expiration). Pour refléter le fait que lesSEspeuvent recevoir et traiter plusieurs requêtes simultanées, chaque SE simulé est implémenté avec un paramètre définissant le nombre maximum de requêtes simultanées qu’il peut recevoir. Cette valeur est actuellement définie à 500, ce qui correspond au nombre maximal de tâches dans un workflow GATE. Nous pouvons améliorer encore la réalisme des SEs simulés en étudiant les configurations de différents SEs pour connaître le nombre de requêtes parallèles acceptées par chaque SE sur EGI. LesSEssimulés sont supposés avoir un grand nombre de cœurs (par exemple, 48) pour que plusieurs requêtes simultanées puissent être traitées simultanément et à la même vitesse.

LeLFCsimulé permet aux tâches d’enregistrer des fichiers, de les répertorier, d’inscrire des fichiers et de répertorier toutes les réplicats pour un fichier donné. Il permet également aux utilisateurs de définir les emplacements des réplicats pour les fichiers enregistrés dans

LFC avant la simulation. Ces informations sont stockées dans un fichier qui est joint en tant qu’argument pour le service LFC simulé, dans le format: nom du fichier, taille, <se_1:se_2:....se_n>.

Au début de la simulation, le LFC simulé analysera ce catalogue prédéfini de fichiers pour récupérer les emplacements des répliques pour chaque fichier. Les informations du fichier (par exemple, le nom du fichier, la taille) seront également stockées sur les SEsqui hébergent un réplicat pour le fichier. Lorsque les SEs reçoivent une requête de télécharge- ment pour un fichier à partir des tâches, ils vont générer une "tâche SimGrid" avec la quantité d’octets correspondant à la taille du fichier demandé.

Le service de sélection de réplicat est implémenté selon l’algorithme exact du sys- tème réel. Le SURL de chaque SE est représenté par le nom du SE. Puisque nous ne simulons pas les échecs de transfert, le premier réplicat dans la tête de la liste triée est toujours disponible et elle est toujours sélectionnée comme la source pour télécharger le fichier correspondant. Cependant, si un délai d’expiration (timeout) est imposé et si le transfert simulé n’est pas accompli avant la valeur de ce délai d’expiration, il sera systé- matiquement tué et le prochaine réplicat dans la liste triée sera testé.

Coût de communication pour les transferts de fichiers. Nous avons constaté que

8.4. MODÈLES DE PLATES-FORMES RÉALISTES POUR REJOUER DES EXÉCUTIONS RÉELLES DE WORKFLOW

transfert réelles. Nous décidons de refléter cette durée minimum dans notre simulateur en la décomposant en 900 millisecondes pour le coût de communication et 100 millisecondes pour la latence du réseau.

La durée d’un transfert de fichier simulé dans notre simulateur comprend: (i) les coûts de communication simulés, (ii) la latence sur les routes du réseau et (iii) le temps de traitement de la "tâche SimGrid" généré par leSE. Si un délai d’expiration est utilisé, la durée totale est la temps cumulé de toutes les tentatives de transfert.

Injection de paramètres. Compte tenu de la complexité de l’ensemble du système

réel, il est difficile de simuler tous les paramètres car il faut établir des modèles précis pour chaque paramètre et également les valider, ce qui peut être plus difficile. Pour mieux estimer le point de départ de chaque phase du cycle de vie d’une tâche, nous distinguons deux stratégies pour décider des valeurs de paramètres dans notre simulateur: injecter ou estimer.

L’injection d’un paramètre pour simuler l’exécution d’un workflow signifie que la valeur de ce paramètre est directement extraite de la trace d’exécution, tandis que l’estimation d’un paramètre signifie que la valeur est calculée par un modèle prédéfini pendant l’exécution de la simulation. Cette distinction nous donne plus de flexibilité pour concevoir des scénarios de simulation en nous concentrant sur les paramètres sur lesquels nous voulons enquêter sans perdre de réalisme pour les autres paramètres.

Les stratégies de simulation pour les différents paramètres liés aux transferts de fichiers sont résumés dans le Tableau 8.2.

Paramètre Stratégie

temps d’attente • toujours injecté

le durée de calcul • toujours injecté

la taille d’upload • toujours injecté

durées de transfert de

fichiers

• toujours estimé par les modèles de réseau dans SimGrid

réplique de fichier pour chaque transfert

• le même que dans le transfert réel • ou choisi par la service de sélection de

réplique simulée

Table 8.2: Stratégie pour différents paramètres dans notre simulateur.

8.4

Modèles de plates-formes réalistes pour rejouer des exé-

cutions réelles de workflow

Le but de cette section est de construire des modèles de plate-forme pour rejouer l’exécution de chaque workflow GATE. Nous proposons une topologie de réseau réaliste et deux méthodes d’instanciation de la bande passante pour modéliser notre plate-forme

cible (c’est-à-dire la VO Biomed de EGI). A partir de l’information dans chaque trace d’exécution individuelle, nous générons des modèles de plate-forme ad-hoc pour chaque workflow. Le réalisme de nos modèles sera évalué en confrontant les résultats de la sim- ulation aux résultats des exécutions réelles enregistrés dans les traces. Pour assurer que les transferts de fichiers simulés se produisent entre les mêmes hôtes que dans l’exécution réelle, nous injectons le réplicat de fichier impliquée dans les transferts réels en tant que paramètre pour les tâches dans notre simulateur lors de la simulation de transferts de fichiers.