dietAgent - En ligne dans le Cloud

PROGRAMME:

Nom

dietAgent - Agent middleware de grille DIET

Nom

dietAgent - Binaire principal de l'architecture DIET pour l'exécution des agents DIET (maître et local
agents)

SYNOPSIS

dietAgent [fichier de configuration] ...

DESCRIPTION

Le DietAgent est le principal binaire de la distribution DIET. Il est utilisé à la fois pour le maître et
agents locaux d'une hiérarchie DIET.

DIET PLATEFORME

Une plate-forme DIET est construite sur Server Daemons (SeD). Les demandes sont réparties entre un
hiérarchie des agents. L'ordonnanceur peut s'appuyer sur les informations de disponibilité des ressources
collectées à partir de trois outils différents : des capteurs NWS qui sont placés sur chaque nœud du
hiérarchie, à partir de l'outil de prédiction des performances centré sur l'application FAST qui s'appuie sur
Informations NWS ou de CoRI Easy un module basé sur des appels système simples et
des tests de performance.

Les différents composants d'une architecture DIET sont les suivants :

Témoignage Un client est une application qui utilise DIET pour résoudre des problèmes de calcul.
Les clients peuvent être des pages Web, des scripts PSE comme Matlab ou Scilab ou un programme natif.

Master Agent (MA)
Une MA gère les demandes de calcul des clients. Il choisit le meilleur serveur
disponible pour traiter la demande sur la base des informations de performance recueillies auprès de
les serveurs. Ensuite, la référence du serveur choisi est retournée au client.

Demandeur d’emploi local (national) Agent (LA)
Une LA transmet les requêtes entre les MA et les serveurs. Les LA stockent une liste de services
disponible dans leur sous-arborescence. Pour chaque service, les LA stockent une liste d'enfants (soit
agents ou serveurs) fournissant les premiers. Selon le réseau sous-jacent
topologie, une hiérarchie de LA peut exister entre le MA et les serveurs appropriés,
l'une des tâches de LA est de faire un ordonnancement partiel sur son sous-arbre, réduisant efficacement
sa charge de travail MA.

Server démon (SED)
Un SeD encapsule une ressource de calcul. Par exemple, il peut être localisé sur le
point d'entrée d'un ordinateur parallèle. SeD stocke une liste de données disponibles localement,
solveurs informatiques disponibles et informations relatives aux performances (disponibles
quantité de mémoire ou nombre ou ressources). Lors de l'inscription, SeD déclare à son
agent parent (LA ou MA) chaque problème de calcul qu'il peut résoudre. SeD peut envoyer
performances et informations matérielles en utilisant le module CoRI ou performance
prédictions pour certains types de problèmes en utilisant le module FAST.

Master Agent JOUR (MA GAD)
Le Master Agent DAG (MADAG) fournit la planification du workflow DAG. Cet agent sert de
le point d'entrée de la hiérarchie de régime pour un client qui souhaite soumettre un flux de travail.
Le langage supporté par le MADAG est basé sur XML.

CORBA UTILISATION POUR DIET

DIET s'appuie sur le service de nommage CORBA pour la découverte de services permettant à chaque entité de
interconnecter. La référence au service de nommage omniORB est inscrite dans un CORBA
fichier de configuration dont le chemin est donné à omniORB via la variable d'environnement
OMNIORB_CONFIG.

Les lignes concernant le serveur de noms dans le fichier de configuration omniORB sont construites comme
suit:

InitRef = NameService=corbaname :: :

Le port du serveur de noms est le port donné en argument à l'option -start de omniNames.
Vous devez également mettre à jour votre LD LIBRARY PATH pour qu'il pointe vers /lib. Donc votre LD
La variable d'environnement LIBRARY PATH devrait maintenant être :
LD CHEMIN DE LA BIBLIOTHÈQUE=/ lib: /lib.

NB1: Afin d'éviter les collisions de noms, chaque agent doit se voir attribuer un nom différent
dans le serveur de noms ; puisqu'ils n'ont pas d'enfants, les SED n'ont pas besoin de noms attribués
à eux et ils ne s'enregistrent pas auprès du serveur de noms.

NB2: Chaque hiérarchie de régime peut utiliser un serveur de noms différent ou plusieurs hiérarchies
peut partager un serveur de noms (en supposant que tous les agents reçoivent des noms uniques). Dans un
environnement multi-MA, pour que plusieurs hiérarchies puissent coopérer, il est
nécessaire qu'ils partagent tous le même serveur de noms.

OPTIONS

fichier_config
Fichier de configuration utilisé par l'agent pour lancer l'entité DIET

DIET CONFIGURATION DOSSIER

Chaque entité DIET nécessite un fichier de configuration.

S'il vous plaît noter que:

· les commentaires commencent par '#' et se terminent à la fin de la ligne courante,

· les lignes significatives ont le format : mot-clé = valeur, suivant le format de configuration
fichiers pour omniORB 4,

· pour les options qui acceptent 0 ou 1, 0 signifie non et 1 signifie oui, et

· les mots-clés sont sensibles à la casse.

Selon le type d'élément DIET, différents types de mots-clés peuvent être trouvés. Ici
est une liste des mots-clés possibles pour un fichier de configuration d'Agent DIET :

niveautrace
Valeur entière correspondant au traceLevel pour l'agent DIET :

· 0 : DIET n'imprime rien.

· 1 : DIET n'imprime que les avertissements et les erreurs sur la sortie d'erreur standard.

· 2 : [par défaut] DIET imprime des informations sur les principales étapes d'un appel.

· 5 : DIET imprime également des informations sur toutes les étapes internes.

· 10 : DIET imprime également toutes les structures de communication.

· >10 : (traceLevel - 10) est donné à l'ORB pour imprimer également les messages CORBA.

0 Diet n'imprime rien, – 1 Diet n'imprime que les avertissements et les erreurs sur le
sortie d'erreur standard, – 2 [par défaut] Diet imprime des informations sur les principales étapes d'un
appel, – 5 Diet imprime également des informations sur toutes les étapes internes, – 10 Diet imprime toutes
les structures de communication aussi, – > 10 (traceLevel - 10) est donné à l'ORB pour
imprimez également les messages CORBA.

Type d'agent
trois valeurs possibles

· DIET MASTER AGENT (ou MA) pour un Master Agent

· AGENT LOCAL DIET (ou LA) pour un Agent Local

· DIET_MA_DAG pour un Agent MA DAG

régimePort
Entier définissant le port d'écoute de l'agent. S'il est laissé vide, l'ORB obtiendra un
ouvrir le port du système (si la valeur par défaut 2809 est occupée).

régimeNomHôte
Chaîne définissant l'interface d'écoute de l'agent. S'il est laissé vide, l'ORB
utiliser le nom d'hôte du système (le premier si plusieurs sont disponibles).

prénom Chaîne identifiant l'élément. Les clients et les nœuds enfants (LA et SeD) doivent
pointez vers le même service de nommage CORBA hébergeant la MA.

nom du parent
Chaîne identifiant l'agent parent.

[Remarque : Seuls les agents locaux DIET pouvaient utiliser le mot-clé parentName]

utilisation rapide
Booléen activation/désactivation du module FAST. S'il est défini sur 0, tous les paramètres LDAP et NWS
sont ignorées et toutes les requêtes à FAST sont désactivées (lorsque Diet est compilé avec
VITE). Ceci est utile lors du test d'une plate-forme DIET sans avoir à déployer un
Base LDAP ni plate-forme NWS.

[Remarque : DIET doit être compilé avec FAST]

ldapUtiliser
Booléen activer/désactiver la prise en charge LDAP.

[Remarque : DIET doit être compilé avec FAST]

ldapBaseComment
Chaîne représentant la base LDAP stockant l'adresse des services connus FAST sous la forme
port hôte .

[Remarque : DIET doit être compilé avec FAST]

ldapMasque
Chaîne spécifiant le masque enregistré dans la base LDAP.

[Remarque : DIET doit être compilé avec FAST]

nwsUtiliser Booléen activation/désactivation de la prise en charge NWS.

[Remarque : DIET doit être compilé avec FAST]

nwsNameserver
Chaîne représentant l'adresse du service de nommage NWS sous la forme host:port .

[Remarque : DIET doit être compilé avec FAST]

nwsForecaster
Chaîne représentant le module de prévision NWS utilisé par FAST.

[Remarque : DIET doit être compilé avec FAST]

utiliserLogService
Booléen activant/désactivant le LogService à des fins de surveillance.

lsOutbuffersize
Entier définissant la taille du tampon des messages sortants.

lsFlushinterval
Entier définissant l'intervalle de vidage du tampon des messages sortants.

voisins
Chaîne de liste MA qui doit être contacté pour créer une fédération. Il est formaté comme
une liste d'adresses séparées par des espaces blancs sous la forme hôte:port.

[Remarque : DIET doit être compilé avec l'option Multi-MA]

minimumVoisins
Entier définissant le minimum de voisins connectés. Si l'agent est moins connecté
voisins, il essaiera d'établir de nouvelles connexions.

[Remarque : DIET doit être compilé avec l'option Multi-MA]

maximumvoisins
Entier définissant le maximum de voisins connectés. De plus, l'agent refusera
des connexions plus récentes.

[Remarque : DIET doit être compilé avec l'option Multi-MA]

mise à jourLienPériode
Entier définissant la période (en secondes) à laquelle l'agent vérifiera son
le statut des voisins et essaiera d'établir de nouvelles connexions si leur nombre est
moins que minimumNeighbours.

[Remarque : DIET doit être compilé avec l'option Multi-MA]

bindServicePortbindServicePort
Entier définissant le port utilisé par la MA pour partager son IOR.

[Remarque : Option utilisée uniquement par les AG]

useConcJobLimituseConcJobLimit
Booléen activant/désactivant la restriction SeD concernant les résolutions simultanées. Cette
doit être utilisé avec maxConcJobs.

[Remarque : Option utilisée uniquement par les SeD]

maxConcJobs
Entier définissant le nombre maximal de travaux exécutés simultanément. Cela devrait être utilisé dans
en conjonction avec maxConcJobs.

[Remarque : Option utilisée uniquement par les SeD]

ID de l'emplacement
Chaîne utilisée pour la prédiction des coûts de transfert alternatifs dans Dagda.

[Remarque : Option utilisée uniquement par les SeD]

MADAGUE
Chaîne correspondant au nom de l'agent MADAG.

[Remarque : DIET doit être compilé avec l'option workflow]

[Remarque : Option utilisée uniquement par les clients]

module de planification
Chemin d'accès au module de bibliothèque de planificateur contenant l'implémentation du planificateur.

[Remarque : DIET doit être compilé avec l'option User Scheduling]

[Remarque : Option utilisée uniquement par les agents]

moduleFichierConfig
Chaîne correspondant à un fichier de configuration facultatif du module.

[Remarque : DIET doit être compilé avec l'option User Scheduling]

[Remarque : Option utilisée uniquement par les agents]

nom de lot
Chaîne correspondant au nom de la file d'attente où le travail sera soumis.

[Remarque : DIET doit être compilé avec l'option Batch]

[Remarque : Option utilisée uniquement par les SeD]

cheminVersNFS
Chemin d'accès au répertoire NFS où vous disposez des autorisations de lecture/écriture.

[Remarque : DIET doit être compilé avec l'option Batch]

[Remarque : Option utilisée uniquement par les SeD]

cheminVersTmp
Chemin d'accès au répertoire temporaire où vous disposez des autorisations de lecture/écriture.

[Remarque : DIET doit être compilé avec l'option Batch]

[Remarque : Option utilisée uniquement par les SeD]

interneOARbatchQueueName
Chaîne utile uniquement lors de l'utilisation des fonctionnalités de traitement par lots CORI avec OAR 1.6

[Remarque : DIET doit être compilé avec l'option Batch]

[Remarque : Option utilisée uniquement par les SeD]

initIDRequête
Entier définissant la valeur de départ de l'ID de demande MA.

[Remarque : Option utilisée uniquement par les AG]

ackFichier
Chemin d'accès à un fichier qui sera créé lorsque l'élément sera prêt à être exécuté.

[Remarque : DIET doit être compilé avec l'option Acknowledge File]

[Remarque : Option utilisée uniquement par les agents et les SeD]

maxMsgSize
Entier définissant la taille maximale des messages CORBA envoyés par Dagda. Par défaut, c'est
la même que la taille omniORB giopMaxMsgSize.

espace disque max
Entier définissant l'espace disque maximal disponible pour Dagda pour le stockage des données. Lorsqu'il est défini
à 0, Dagda ignorera tout quota de disque. Par défaut, c'est la même valeur que
l'espace disque disponible sur la partition définie par storageDirectory.

maxMemSpace
Entier définissant la mémoire maximale disponible pour Dagda. Lorsqu'il est réglé sur 0, Dagda
ignorer toute limitation d'utilisation de la mémoire. Par défaut, aucune limitation.

cacheAlgorithme
Chaîne définissant l'algorithme de remplacement du cache utilisé lorsque Dagda a besoin de plus de mémoire
pour stocker une donnée. Les valeurs possibles sont : LRU, LFU, FIFO. Par défaut, non
algorithme de remplacement de cache, Dagda n'écrase jamais les données.

Partager des fichiers
Booléen activant/désactivant le partage de fichiers Dagda avec ses enfants. Nécessite que le
chemin est accessible par les enfants (c'est-à-dire: partition NFS partagée par le parent et
enfants). Par défaut, pas de partage de fichiers.

fichier de sauvegarde de données
Chemin d'accès au fichier de sauvegarde utilisé par Dagda à la demande de l'utilisateur (checkpointing). Par défaut,
aucun point de contrôle n'est désactivé.

[Remarque : Option utilisée par les agents et ServerDaemon]

restauration au démarrage
Booléen définissant si Dagda doit charger le fichier défini par dataBackupFile au démarrage
et restaurer toutes les données enregistrées lors du dernier événement de point de contrôle. Désactivé par
défaut.

[Remarque : Option utilisée par les agents et les SeD]

répertoire de stockage
Chaîne définissant le répertoire où Dagda stockera les fichiers de données. Par défaut / Tmp
est utilisé.

UTILISATION SPÉCIFIQUE PLANIFICATION

Options spécifiques définissant la politique du planificateur utilisée par le client chaque fois qu'il soumet un
demande:

· ÉCLATER DEMANDE: round robin sur le SeD disponible

· ÉCLATER LIMIT: n'autoriser qu'un certain nombre de requêtes par SeD en parallèle la limite peut
être défini avec "void setAllowedReqPerSeD(unsigned ix)"

[Remarque : DIET doit être compilé avec l'option Custom Client Scheduling (CCS)]

[Remarque : Option utilisée par les clients]

clientMaxNbSeD :
Valeur entière représentant le nombre maximum de SeD que le client doit recevoir.

[Remarque : Option utilisée par les clients]

ENVIRONNEMENT

DIET a besoin de définir certaines variables pour que l'agent puisse trouver toutes les
bibliothèque obligatoire et le service de nommage CORBA.

LD_LIBRARY_PATH
Cette variable d'environnement doit contenir le chemin d'accès aux bibliothèques omniORB

OMNIORB CONFIG
Chemin d'accès au fichier de configuration CORBA où la référence au nommage omniORB
le service est écrit.

EXEMPLES

Voici des exemples de fichier de configuration pour l'agent maître ou les agents locaux.

· Fichier de configuration de l'Agent Maître :

# fichier MA example.cfg, fichier de configuration pour une MA
agentType = DIET_MASTER_AGENT
nom = MA
#traceLevel = 2 # par défaut
#dietPort = # pas besoin
#dietHostname =
useLogService = 0 # par défaut
lsOutbuffersize = 0 # par défaut
lsFlushinterval = 10000 # par défaut

· Fichier de configuration pour l'agent local

# fichier LA example.cfg, fichier de configuration pour un LA
type d'agent = DIET_LOCAL_AGENT
nom = LA
useLogService = 0 # par défaut
lsOutbuffersize = 0 # par défaut
lsFlushinterval = 10000 # par défaut

DE LA LIGNE BOGUES

Si vous trouvez ce logiciel intéressant, ou si vous trouvez un bug, merci de nous envoyer un mail : <‐
[email protected]> avec la description du problème, la version du programme
et/ou toute information qui pourrait nous aider à le corriger.

Utilisez dietAgent en ligne en utilisant les services onworks.net