FLASH INFORMATIQUE FI



ERIDAN - PBS (Portable Batch System)

le point après près d’un an d’exploitation




Jean-Michel CHENAIS


Introduction

Depuis environ 2 mois, sur le serveur parallèle Eridan, doté de 128 processeurs et 64 Gbytes de mémoire RAM, le sous-système batch PBS tourne en exploitation avec les cpusets actifs, et ceci sans problème particulier. Cet article a pour but de présenter quelques caractéristiques de cette nouvelle configuration de PBS, et d’en préciser les conséquences pour les usagers. Par la même occasion, seront mentionnées quelques autres possibilités de développement en cours de tests sur Eridan, et projets futurs envisageables impliquant ce serveur. En particulier seront examinées les possibilités techniques d’intégrer un environnement Grid à l’Ecole.

Les cpusets

L’architecture originale des serveurs SMP de la firme Silicon Graphics est de façon générique le résultat de l’assemblage d’un grand nombre d’éléments modulaires ou briques, dont chaque type a une fonction bien particulière.

Les principaux types de briques et leur fonction sont les suivants :
• C-brick : éléments de base de calcul comprenant un nombre variable de processeurs selon le modèle et une mémoire locale ;
• IO-brick et P-brick : série élément de base assurant les fonctions d’entrée/sortie, doté d’interfaces PCI spécifiques du genre d’équipement à raccorder ;
• R-brick : élément de base assurant l’interconnexion entre les modules participant à la configuration de la machine.

Dans les séries les plus récentes, ces éléments de base peuvent conduire à des configurations comprenant, pour une machine unique, 512 processeurs et 1 TB de mémoire partagée adressable, résultat de l’assemblage de modules de base pouvant contenir jusqu’à 16 processeurs et 32 Gbytes de mémoire, toujours selon le principe spécifique de l’architecture NUMAflex de Silicon Graphics.

Dans le cas d’Eridan, la machine est beaucoup plus modestement construite sur la base de 32 modules de 4 processeurs et 500MB chacun (C-brick), tous interconnectés à un réseau comprenant 8 routeurs (R-brick), le tout étant rassemblé dans 4 racks contigus. A noter la présence d’un rack supplémentaire prévu pour les IO-bricks et les P-bricks, et dédié aux différents équipements de stockage (ensemble de disques RAID d’environ 2 TBytes de capacité, silo STK avec cartouches STK9940B) et d’interfaces réseau de l’Ecole.

Le sous-système PBS (pour Portable Batch System) a la possibilité de tenir compte de la structure spécifique et générique des serveurs SGI, et par là même dans le cas d’Eridan de tirer profit de cette architecture pour en exploiter au mieux sa puissance de calcul.

Les utilisateurs ont pu constater, du temps où NQS était encore utilisé, que leurs travaux présentaient des variations importantes dans les temps d’exécution. Un même programme avec les mêmes données pouvait avoir un elapsed time variant d’un facteur de 1 à 3, voire plus, dans le pire des cas. Cela était dû principalement à la répartition plus ou moins aléatoire des tâches sur les processeurs de la machine, et des interférences négatives sur la latence entre les opérations d’entrée/sortie et les références des processeurs sur des mémoires distantes.

Premières expériences

Il convenait donc d’organiser un système favorisant pour chaque ensemble de process la localisation de ces process sur un espace réduit de la machine. L’idée de base consiste à forcer l’allocation des process sur un ensemble contigu de processeurs afin que les références mémoire de chaque processeur s’effectuent sur leur mémoire locale. Les processeurs étant rassemblés par 4 sur chaque noeud de la machine, ceci est réalisé en allouant un ensemble de C-bricks tous voisins les uns des autres et en faisant se dérouler les process de façon à ce que, de préférence, chaque processeur fasse référence à sa mémoire locale.

Une première tentative a été entreprise au printemps 2002 avec NQS. Cette expérience a consisté en l’utilisation des fonctions natives de l’OS/IRIX de SGI permettant de désigner nommément les régions, en termes de numéros de processeurs, où devaient se dérouler les process liés à chaque application. Cette famille de fonctions, toutes invoquées par la commande cpuset, permettent, au niveau du shell Unix, de créer, de déplacer, d’associer à un exécutable et de détruire tout un ensemble de process spécifiques d’une application parallèle et regroupés dans des régions présélectionnées (cf. man cpuset).

Cette expérience a consisté en la mise en place d’un wrappeur de la commande <mpirun> . Pour chaque job batch soumis à NQS qui en faisait usage, le nouveau <mpirun> assumait les fonctions suivantes :
• au moment de l’invocation de la commande mpirun, préparation et création d’un cpuset comprenant le nombre juste suffisant de processeurs demandés (déterminé par la valeur du paramètre -np de la commande mpirun),
• pendant l’exécution du job, assignation et contrôle des process liés au cpuset,
• à la fin du job, désallocation des process et destruction du cpuset.

Les tests, effectués sur des jobs individuels, mais pendant la production, ont montré que les performances individuelles des applications étaient améliorées statistiquement d’un facteur de 10 à 20%, avec une distribution mieux centrée sur la valeur moyenne.

Si la preuve de l’incidence favorable des cpusets sur les performances des applications individuelles était prouvée, la mise en public de ce wrappeur n’a pas apporté les gains escomptés, en raison de la complexité de la gestion globale de l’ensemble des cpusets au niveau de la machine. En particulier, aucun mécanisme ne pouvait être mis en place de façon simple pour éviter les phénomènes de fragmentation. De surcroît, rien n’était prévu à ce stade pour les applications type OpenMP. Il fallait donc attendre la disponibilité d’un système batch capable d’assumer la gestion complète des cpusets pour tous les jobs et tous les modèles de programmation.

Intégration des cpusets avec PBS

Silicon Graphics ayant décidé de ne plus supporter NQS, il convenait de s’orienter vers un autre produit intégrant la gestion des cpusets : il s’est révélé, dès novembre 2002, que PBS, dans sa version Pro pour les systèmes Unix offrait cette possibilité, et ce produit était d’autant plus attractif qu’il était quasi gratuit pour l’Ecole, en tant que site académique reconnu par son fournisseur Veridian Systems.

A noter que le système des cpusets n’est pas intégré dans le système PBS lui-même, mais bien dans l’OS IRIX de Silicon Graphics. PBS ne fait qu’exploiter les primitives de l’OS mises à disposition, qui sont activées très facilement par des options de configuration spécifiques à ce produit conçu de façon très modulaire. Ce n’était donc qu’avec la version 6.5.18 d’IRIX, installée en septembre 2002, que l’exploitation des cpusets a été rendue possible.

Dans une première phase, dès novembre 2002 (après des tests internes de fonctionnalité de PBS de quelques mois sur Eridan sans que cela ait gêné son exploitation normale par NQS), PBS a été configuré et utilisé de façon aussi proche que possible de NQS : même structure et organisation de classes, afin de faciliter les opérations de migration des utilisateurs vers le nouveau système batch. Ceci a été favorisé par le fait que PBS est en fait conceptuellement de la même veine que NQS : commandes de base et méthodes de soumission et de récupération des jobs pratiquement identiques, etc. Pendant cette phase, des mesures de performances répétées ont été effectuées.

Dans une deuxième phase, qui a débuté en février 2003, PBS a été configuré pour tenir compte des cpusets, et les mesures ont été effectuées avec les mêmes programmes, mais avec des résultats nettement améliorés, même s’ils ne sont pas encore aussi bons qu’espérés.

Conséquences pour les usagers

La mise en place des cpusets peut impliquer quelques modifications pour les travaux soumis. Le système batch PBS convertit toujours toutes les demandes de ressources des utilisateurs (nombre de processeurs, mémoire) à un nombre juste suffisant de system nodes (ensemble de 4 processeurs et 2 Mbytes de mémoire) nécessaire à l’exécution des travaux. PBS demandera donc le nombre de ssinodes le plus petit qui satisfera à la fois soit le nombre de processeurs, soit la mémoire. Le nombre de processeurs demandé sera donc toujours un multiple de 4, et la mémoire totale demandée ne devrait jamais dépasser 512Mbytes multiplié par ce nombre de processeurs (chaque C-brick ne dispose pour le moment que de 512 Mbytes par processeur).

Conditions des mesures de performances : Les jobs ont été soumis sur Eridan, à des heures aléatoires, pendant plusieurs semaines. Les mesures ont donc été effectuées sur une machine en pleine production, avec des conditions de charge variables mais bien réelles. Toutes les mesures et graphiques ont été réalisés et aimablement mis à disposition par mon estimé collègue Trach Minh Tran).
Sans les cpusets : les performances se répartissent entre 550 et 3700 Mflops, avec une valeur centrée sur 1200 environ. Les meilleures valeurs sont obtenues lorque aucun autre job ne tourne en machine, et ne sont donc pas représentaives des conditions usuelles d’exploitation.
Avec les cpusets : les performances sont beaucoup moins étalées, et se concentrent autour de 2800Mflops. Les quelques basses valeurs ont été obtenues suite à des problèmes système, et ne sont donc pas representatives de l’expérience.

L’ensemble des classes eridan-4 à eridan-64 d’Eridan répond à cette configuration

Pour les jobs batch sur Eridan, il en résulte que les utilisateurs tournant habituellement dans les classes lowmem n’ont rien à craindre : pour ces classes PBS convertit toutes les demandes en celles correspondant aux classes du groupe eridan comportant le même nombre de processeurs : ces mêmes applications ont devant elles de larges possibilités de grandir, donc de traiter des cas 2 fois plus gros. Par contre, pour les travaux demandant de grands espaces mémoire (comme pour les classes bigmem), les utilisateurs devront soit réduire la demande de mémoire, soit augmenter le nombre de processeurs pour obtenir la mémoire nécessaire, et adapter leur code afin d’éviter d’avoir à réserver des processeurs qui ne seraient pas utilisés, ce qui peut parfois se révéler délicat en raison des problèmes de scalabilité. Dans les cas favorables, les usagers par exemple des classes bigmem-16 et bigmem-32 peuvent sans autre tourner leurs jobs respectivement dans les classes eridan-32 et eridan-64. Raison pour laquelle actuellement, pour les autres cas défavorables, la mise en place des cpusets risque d’être contre-productive si la mémoire locale sur Eridan n’est pas rapidement doublée, car en fait, toutes les classes bigmem sont en voie d’être fermées.

Pour le pur interactif, les conséquences sont réduites, mais pas nulles. La mise en place des cpusets exige qu’une partie de la machine soit dévolue à toutes les tâches système non prises en compte par PBS. Cela implique que tous les process fils autres que ceux issus des daemons de PBS tournent dans un cpuset particulier, traditionnellement dénommé boot_cpuset, normalement constittué d’une à deux C-bricks. Dans cette partition particulière, constituée pour l’heure de 2 C-bricks (dont la fonction est similaire à celle d’une machine front-end) se retrouvent concentrés tous les daemons correspondant à tous les nombreux et indispensables services traditionnels, assumant les fonctions telles que connexion (telnet, rlogin, ssh), serveur de temps et de noms (xntpd, named), securité, entrée/sortie (gestion des buffers), surveillance du système (génération des logs système), ainsi que tous les process interactifs habituellement déployés par les utilisateurs (compilations interactives, exécution pour tests de programmes parallèles, etc.). Les demandes en mémoire induites par toutes ces fonctions actuellement sur Eridan requièrent pour le moins deux C-bricks (soit 4 Gbytes), donc immobilisent 8 processeurs retirés à la pure exploitation de PBS. Ces demandes de mémoire sont encore majorées par l’espace requis pour l’allocation des buffers nécessaires à toutes les opérations d’entrée/sortie.

Les utilisateurs dont les applications parallèles sont par nature exclusivement interactives sont donc invités expressement à passer par l’option interactive de PBS. Avec l’option -I de la commande <qsub> , il est possible de soumettre un job, pour un nombre quelconque de processeurs : si les ressources demandées sont disponibles, une session PBS interactive est immédiatement ouverte, et l’utilisateur peut travailler depuis son terminal au travers d’une authentique session interactive, à la seule différence près que tous les process sont normalement sous le contrôle de PBS, plutôt que des daemons tournant dans le boot_cpuset, réduisant, mais sans le supprimer, l’impact du manque de mémoire sur ce dernier. Le pur interactif ne pourrait encore être utilisé que pour des commandes simples strictement mono-processeur (compilation, édition).

Gestion des cpusets

Chaque cpuset créé et attribué par PBS à chaque job a un nom : il contient en général le numéro du job, et l’utilisateur peut en prendre connaissance en consultant les dernières lignes de l’affichage de la commande qstat -f <sequence_number>. A chaque cpuset correspond une liste de processeurs, identifiés par leur numéro d’ordre (de 0 a 127). Ces numéros sont affichés sous la rubrique resource.nodemask du même display sous leur forme hexadécimale ou binaire d’une chaîne de caractères. Cette chaîne est interprétée et est visible en clair dans la dernière colonne de la commande locale js -a (job status). Chacun pourra vérifier que dans la toute grande majorité des cas, les numéros sont consécutifs, preuve d’une bonne sélection des processeurs pour les jobs. Ils peuvent parfois varier de cas en cas, mais finalement se stabilisent : les jobs en quelque sorte finissent par faire leur nid dans la machine et tournent au meilleur de leurs possibilités.

PBS réussit donc là ce qu’avec NQS il s’était révélé impossible de faire avec le wrapper de la commande mpirun : garantir la gestion globale et efficace de tous les cpusets.

En principe, à chaque job correspond un seul cpuset (comprenant en général plusieurs briques). Mais plusieurs petits jobs monoprocesseurs, voire bi-processeurs, peuvent se partager une même brique (nodeboard). Ainsi 4 jobs mono-processeurs, ou 2 jobs bi-processeurs ne demandant au total pas plus de 512MB, peuvent co-exister sur le même ssinode. PBS permet donc l’assignation efficace de cpuset pour les petits jobs : c’est notamment le cas pour certains travaux tournant dans la classe expres-4.

Scheluling des jobs

L’une des qualités requises par tout système batch est de comporter un scheduler efficace, permettant de sélectionner adroitement les jobs à traiter, selon des règles claires et justes pour les usagers, tout en garantissant un rendement efficace de la machine, et pourvu de moyens suffisamment souples donnant à l’administrateur la possibilité de répondre aux demandes ponctuelles des usagers.

En ce sens, PBS dispose d’une grande variété de possibilités, maintenant considérées comme indispensables pour la gestion traditionnelle des grands serveurs. Parmi celles-ci, mentionnons les suivantes, pour la plupart activées sur Eridan :
• Notion des starving jobs : au-delà d’une certaine période de temps, sont considérés comme starving les jobs candidats qui n’ont pas pu rentrer en machine, trop chargée. Cette période est fixée à 24 heures sur Eridan. Donc, tout job starving (par exemple pour manque de ressources) provoque une opération automatique de drainage (vidage) de la machine afin de libérer suffisamment de ressources pour laisser ce job rentrer.
• Notion de backfill : cette opération de drainage implique normalement le blocage de tous les jobs en attente, donc la non-utilisation de ressources pendant un certain temps : PBS permet toutefois la prise en charge des jobs suffisamment courts et requérant peu de processeurs qui auront juste le temps de s’exécuter pendant le drainage. C’est par exemple le cas actuellement pour les jobs de la classe expres-4.
• Notion de classe à haute priorité : les jobs de ces classes ont le pouvoir de préemption sur les jobs des autres classes. De tels jobs peuvent inciter la machine à checkpointer d’autres jobs, donc provoquer la mise sur disque de leur image complète en mémoire RAM, libérant ainsi, selon une méthode ôte-toi de là que je m’y mette, suffisamment de ressources pour pouvoir rentrer en exécution. A noter que le checkpointing n’est entrepris par PBS que si l’OS sous-jacent de la machine dispose de cette faculté.
• Notion de préemption : cette fonction, complémentaire de la précédente, peut être activée par exemple pour quasi immédiatement laisser rentrer les starving jobs : au lieu d’attendre que le drainage libère les ressources nécessaires, un ou plusieurs jobs sont sélectionnés pour être interrompus et checkpointés, et le job candidat entre quasiment immédiatement en exécution. Selon les cas, parmi les jobs sélectionnés, le système peut avantageusement préférer de faire rerun ces jobs s’ils n’ont utilisé qu’une faible partie des ressources demandées (par exemple seulement 10 % de leur temps total CPU) : le checkpoint est en effet une opération relativement coûteuse en ressources et longue à exécuter (parfois plusieurs minutes).
• Notion de classes à ressources dédiées : ces jobs démarrent à des heures fixes, et ces classes peuvent être configurés pour des tâches particulières. En principe, ces jobs sont protégés contre le checkpointing, et elles sont envisageables pour les tâches en real time.

Des tests sont actuellement en cours pour finaliser complètement la mise en place de la préemption sur Eridan. Cela devrait être accompli au moment de la parution de cet article.

En route pour le GRID ?

Il est possible de faire se causer plusieurs ordinateurs configurés avec PBS : c’est le peer to peer scheduling. Les serveurs se consultent mutuellement de façon permanente, et peuvent décider de se s’échanger des jobs, selon leur état de charge et leurs disponibilités en ressources, et des critères déterminés par les managers respectifs. Cette possibilité est certes intéressante et pourrait être ponctuellement appliquée à l’Ecole, mais reste limitée aux machines de configuration similaire. Plus attractif serait la possibilité d’interconnecter des machines différentes.

Dans sa conception, PBS est prévu pour s’intégrer dans un système GRID, regroupant un nombre indéterminé d’ordinateurs hétérogènes. En effet, PBS peut être installé (recompilé) avec les options permettant de générer les modules d’interface pour le produit GLOBUS, développépar les plus grandes universités américaines.

Globus permet de mettre en place le metacomputing. En bref, de tels systèmes sont prévus pour supporter des accès simultanés et concurrents à des ressources de calcul localisées sur des ordinateurs géographiquement dispersés et gérés par des institutions indépendantes et autonomes (Virtual Organisations). Dans cette optique, il serait donc possible par exemple de considérer comme une seule entité (VO) de ressource informatique tous les ordinateurs de l’EPFL.

Globus est un produit OpenSource : il est mis a bien plaire à disposition par leurs créateurs (globus.org) et peut être installé sur tout les systèmes Unix traditionnels ou équivalents. Pour autant que les gestionnaires batch disposent d’interface avec Globus (ce qui est le cas notamment pour PBS et LSF), une plate-forme commune regroupant tout un ensemble de machines et de systèmes variés peut être constituée.

Actuellement Globus est installé sur Eridan. Des tests de fonctionnalités sont en cours : il s’agit dans une première phase de reconnaître le comportement de Globus lui-même. Des commandes utilisateurs peuvent être adressées à Globus (globusrun) qui fonctionne donc, dans ce contexte, à la fois comme serveur et client. Ces mêmes commandes peuvent être envoyées depuis une station cliente pour exécution sur Eridan. Un point important concerne la définition d’une Autorité de Certification (certificate authority : CA) qui authentifie les process clients et leur attribue des certificats (proxy) : il est clair qu’un tel système d’authentification et de contrôle des accès est important dans un contexte Metacomputing pouvant impliquer des fonctions ne s’adressant pas qu’à l’ordinateur local. Dans une 2ème phase, il s’agira de vérifier l’intégration de PBS dans l’environnement Globus. Dans ce but, PBS a été recompilé avec les options globus prévues. Dans une phase ultérieure, l’interopérabilité avec d’autres machines pourra être testée. A cette occasion, un appel aux personnes/institutions de l’Ecole intéressés est lancé. Dans un contexte HPC, l’évolution vers un environnement Grid peut se révéler crucial pour une exploitation optimale des ressources existantes à l’Ecole.

Références :
• le projet Globus : http://www.globus.org



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.