DQS (
Distributed Queueing System) a été développé au SCRI (Supercomputer
Computations Research Institute, Florida State University,
Tallahassee). DQS permet de répartir l'exécution de travaux ("job")
en traitement par lots ("batch") ou de "shells" interactifs en
fonction des ressources réclamées et de la charge. DQS comme son
nom l'indique gère un ensemble de machines Unix connectées en
réseau. Chaque machine possède une ou plusieurs files d'attente
("queue"). Les attributs de la file d'attente déterminent les
ressources qu'elle est susceptible de fournir. Ce peut être la
taille mémoire, le temps maximum, la disponibilité d'un logiciel,
une architecture de machine. Lorsque l'utilisateur soumet une
requête au système DQS il précise dans celle-ci les ressources
nécessaires à son exécution. On peut ainsi demander une machine qui
a TeX, ou bien un IBM RS6000. DQS analyse les ressources demandées
et envoie la requête à une file d'attente possédant les
caractéristiques voulues, le choix se fait en fonction de la charge
des différents machines.
NQS
a été originellement
développé pour la NASA en 1985. Le code source a été vendu à de
nombreuses compagnies dont Silicon Graphics, Cray Research et
Monsanto Company. SG a développé sa propre variante pour l'utiliser
sous IRIX 4 bien qu'il en ait été retiré avant IRIX 5. Cray a
bénéficié d'un bon succès commercial avec son produit NQE qui
contenait de nombreuses améliorations sur le NQS originel. Monsanto
a décidé de placer "Monsanto NQS" sous licence GPL GNU et a
distribué des améliorations pour IRIX et des portages vers quelques
versions d'UNIX dont SunOS et DEC OSF/UNIX en culminant avec NQS
v3.36 en 1994. En 1994, l'Université de Sheffield a commencé un
programme de deux ans pour fournir à toutes les académies du
Royaume-Uni un système de traitement par lots pour UNIX robuste et
portable. L'Université s'est basée sur l'excellent travail de John
Roman de chez Monsanto, livrant "Generic NQS" avec de nouvelles
fonctionnalités, des corrections de bogues et le support de plus
d'une vingtaine de versions d'UNIX, dont Linux. De nos jours,
Generic NQS continue à être supportée par Stuart Herbert sur son
temps libre en utilisant des machines sous Linux et FreeBSD.
NQE
(Network Queuin
Environment) Outilsdestinées à la soumission de travaux, soit des
programmes non interactifs qui seront gérées dans des files
d’attente plus ou moins prioritaire. NQE permet la soumission
de travaux en mode batch, tout en choisissant la machine la moins
chargée qui possède les ressources demandées. Les particularités de
NQE sont de choisir sa file d’attente, et de ne pas suspendre
les jobs pour cause de surcharge. Notons que NQE est basé sur NQS
(Cray Network Queuing System), NLB (Network Load Balancer) et FTA
(File Transfer Agent). Quand aux remarques a propos de NQE :
il mélange les notions de process et de processeurs, il gère sa
file des job ne attente en mode fair-share, si un job dépasse les
temps CPU demandé il sera tué, si la machine est rebooté le job
sera relancé.
NQE permet de :
•
Soumettre les demandes
batch à NQS
•
Router automatiquement des
demandes batch sans savoir les noms des files
•
Surveiller l'état des
demandes batch
•
Supprimer une demande
batch
•
Restaurer et recommencer
vos demandes batch
L'utilitaire NQE gère le déroulement
de tous les travaux en fonction des ressources demandées par
travail et le nombre de travaux soumis par les utilisateurs.
PBS pro
(Portable Batch System)
fut développé au centre de recherche de la NASA Ames pour répondre
aux besoins des nouveaux centres de calcul, et des nouvelles
problématiques de répartition de calcul sur des environnements
hétérogènes. PBS pro intègre les notions de grid-computing car
possède une interface bidirectionnelle vers Globus, une réservation
de plage horaire ainsi que des possibilités de peer
scheduling.
OpenPBS
version OpenSource de PBS.
De nombreuses limitations subsistent au niveau de la version
OpenPBS. Tout d’abord seule la version Linux/Unix existe, de
plus pas de version SMP pour Cluster, ni de gestion dynamique de
ressource, ni de régulation de charges, pas d’algorithme de
backfilling, pas d’ouverture aux grilles (OpenMP, GridFTP,
Globus etc …), pas d
GnuQueue
(load balancing system and
batch processing) programme GPL pour lancer des jobs en
les répartissant sur les machines les moins chargées, un remplaçant
pour rsh/ssh.
GRAM
(Globus Ressource
Allocation Manager) composant en charge de la gestion des requêtes
de travail. Il est principalement matérialisé par un démon tournant
sur chaque ressource disponible : le gatekeeper en écoute sur le
port 2119. Le gatekeeper se charge entre autres de vérifier la
validité des requêtes qu'il reçoit et gère leur
exécution.
CONDOR en plus
d’être un outils permettant de monitorer, et de scheduler est
également muni d’un système de traitement par lots qui permet
de répartir des tâches sur un ensemble de ressources de
calcul.
MMJFS
Composant GRAM en version
Web Services dans Globus 3.
LSF
(Load Sharing Facility)
est un logiciel de Platform Computing Corp. permettant de contrôler
et coordonner un ensemble d'ordinateurs formant un cluster ou ferme
de machines. Ce logiciel a deux principales fonctions
:
1. Donner
une vision unique d'un ensemble d'ordinateurs
2. Permettre la répartition des travaux (interactifs et batchs,
séquentiels ou parallèles...) sur ces différents ordinateurs, afin
d'équilibrer au mieux la charge en fonction d'une politique
d'utilisation.
Sun Grid
Engine est la
solution proposée par Sun Microsystems en matière de
grid-computing. SGE est avant tout un système de gestion de charge,
de distribution transparente et automatique des taches,
d’ordonnancement optimal des taches sur les ressources de
calcul. SGE est conçu pour un grand nombre de taches et de
ressources (scalabilité horizontale)
Duroc (Dynamically-Updated Request Online Coallocator) Le rôle de DUROC est de dialoguer avec les Ressources Managers (RM ou GRAM) des différentes machines. Le GRAM est le service capable de faire déclencher l'exécution d'un programme en invoquant la méthode adéquate sur la machine concernée : il s'agit soit d'une exécution directe (fork) ou d'une soumission au système de file d'attente (NQE, LSF, condor,....). L'objectif du dialogue est de synchroniser l'exécution globale d'une application parallèle représentée par l'ensemble des processus à exécuter sur les différentes machines (les processus sont appelés subjobs).