Last update: 08/08/2019
Jusqu'à présent, nous utilisions une distribution HPC linux, nommée Rocks Cluster, basée sur CentOS. L'avantage principal de cette distribution est d'être maintenue très longtemps par les "mainteneurs", permettant d'avoir des correctifs très longtemps. Par ailleurs, CentOS étant un dérivé de RedHat, cela permet de rester compatible avec les drivers de la majorité des fabricants matériel.
Ainsi, de nombreux systèmes HPC fonctionnent sous RedHat ou CentOS, permettant aux centres de calcul d'avoir du matériel garanti par les fabricants, ayant une expertise sous RedHat, avec un système de calcul stable dans le temps.
Cependant :
Infiniband / Mellanox, etc...),Nous avons donc fait le choix de passer sous Ubuntu. Cette distribution bien connue présente l'avantage d'être un dérivé de Debian, et d'avoir accès à un certains nombre de packages supplémentaires, notamment en bioinformatique. Par ailleurs le noyau linux est bien plus récent, tout comme la librairie C utilisée (glibc). Ainsi, nous pouvons bénéficier de programmes plus à jour (nécessitant une version plus récente de la glibc, de gcc...) et utilisant plus de fonctionnalités du noyau linux (car plus récent), comme les nombreuses fonctionnalités utilisées dans les technologies de conteneurs (namespace et cgroups).
A noter que nous avons tout de même besoin de stabilité sur ce système, donc nous partons sur une version déjà éprouvée d'Ubuntu, Bionic LTS (la version 18.04 LTS). Par ailleurs, nous avons déjà une grande expertise sur ce système puisque nous l'utilisons sur les machines bigmems et d'autres serveurs. Pour terminer sur ce choix du système, Ubuntu présente tout de même l'inconvénient majeur, comme beaucoup de nombreux systèmes Linux, d'utiliser Systemd. Si cela s'avère trop contraignant, j'envisagerai de basculer sur Devuan.
Il y a quelques années, nous installions la majorité des logiciels pour tous nos utilisateurs. Ce travail très chronophage (même si une grande partie était automatisée ([*]) nous a décidé à nous orienter sur un système où nous installions tout dans un lieu partagé par NFS, le /share/apps/bin, avec des applications compilées en statique (c'est ce qui se fait dans la majorité des centres HPC), permettant d'embarquer dans le binaire, toutes les dépendances nécessaires (mais faisant grossir énormément la taille du binaire). Ensuite, les applications sont chargées par environment modules.
[*] Un script maison détectait le type de source et définissait une méthode d'installation adéquate. Les sources, binaires et packages étaient maintenus sur un dépôt Web local.
Sur nos nouveaux systèmes, environment modules a été remplacé par lmod (ça ne change rien à l'utilisation), et nous faisons la part belle aux conteneurs, déjà très utilisés dans la précédente version du cluster (mais moins visibles).
La technologie de conteneur choisie est Singularity, avec des modules et un générateur de recette à disposition que nous avons développé (Wicopa). Cette technologie est compatible avec Docker; cependant, le développement des nouvelles versions de Singularity nous semble un peu trop rapide. Il n'est donc pas exclu que nous ne nous tournions pas vers une autre technologie à l'avenir.
Un avantage certain de Singularity est qu'il est utilisé sur de nombreux autres centres de calcul. Ainsi, il est possible de déplacer son conteneur d'un centre à un autre (le conteneur étant un simple fichier (SIF)), ou, à minima, la recette permettant de regénérer le conteneur.
Jusqu'à présent, cette partie était assurée par Rocks Cluster, basée sur Kickstart/Anaconda (rien à voir avec conda/python). Le noeud maître de Rocks contenait ainsi un serveur HTTP et TFTP. Le partitionnement ainsi que l(a) (post-)installation étaient définis par un ensemble de fichiers XML.
Pour remplacer cette partie, nous avons choisi FAI. FAI présente de nombreux avantages :
FAI aurait pu, à lui tout seul, nous permettre de gérer nos noeuds de calcul, mais ce n'est pas le choix que j'ai fait.
Pour finir de remplacer Rocks Cluster, il fallait pouvoir supprimer le noeud maître. Le noeud maître déployait les noeuds de calcul, mais permettait également de :
Et c'est là que SaltStack vient à la rescousse. Je gérais déjà un grand nombre de serveurs par SaltStack. L'idée a donc été d'utiliser cette solution pour gérer le noeud maître sur toutes les fonctions évoquées précédemment (les logiciels derrière sont les mêmes (dhcp, dns, SGE, ganglia...), mais ils sont déployés par SaltStack, selon nos règles de configuration).
Nous utilisons également SaltStack pour gérer la configuration et les applications déployées sur nos noeuds de calcul.
FAI installe le paquet SaltStack, puis, lorsque le noeud est installé, au redémarrage, va s'authentifier sur le serveur SaltStack local qui déploie ensuite toutes les recettes sur le noeud de calcul (client SGE, ganglia, clés SSH des noeuds de calcul, ...). SaltStack est reconnue pour ses performances face à ses concurrents et permet même de remplacer avantageusement certains systèmes permettant de lancer plusieurs commandes simultanément sur tous les noeuds.
Nous déprécions la précédente version d'OpenMPI utilisée dans Rocks Cluster. La version par défaut est donc la 2.1.1, présente en standard sur les systèmes (sans charger de module). Il est possible de charger la version 4.0.1 par module.
Si vous êtes sur le réseau 162.38.181.X, et que vous utilisez cette version d'Ubuntu (18.04 LTS bionic) vous pouvez utiliser notre mirroir Ubuntu local. Les noeuds de calcul sont déployés rapidement, grâce à ce mirroir. Nous pouvons vous autoriser à l'utiliser et le vous donner le paramétrage sur simple demande.
C'est une question de trafic réseau; la charge deviendrait trop importante.
C'est en effet, une question qui nous a fait réfléchir. Beaucoup de clusters ont basculé sur Slurm; parfois pour de bonnes raisons, parfois uniquement pour faire comme les autres. S'il est vrai que de nombreux utilisateurs sont désormais habitués à utiliser d'autres centres de calcul et l'outil Slurm, est-ce une raison suffisante pour changer de système de gestion de jobs ? Non, car par ailleurs, de très nombreux autres utilisateurs n'ont pas accès à d'autres calculateurs et ont déjà des scripts de soumission pour SGE. Il aurait fallu, pour ces derniers, changer tous leurs scripts de soumission.
De plus, la migration de tout le reste était déjà un travail colossal, et rajouter la migration d'une brique essentielle des clusters aurait été délicat. En outre, nos recettes Salt pour SGE sont également déjà particulièrement avancées.
Ceci dit, nous gardons cette idée de côté, car certaines fonctionnalités, telle que celle-ci seraient bien utiles.
La gestion du scratch sur nos clusters a toujours été un peu particulière. En effet, en l'absence de réseau très haut débit à faible latence, il n'est pas possible de maintenir un FS parallélisé avec des performances correctes. Il n'y a donc pas de scratch global sur tout le cluster. C'est d'ailleurs une des raisons qui distingue notre infrastructure du HPC classique; nous faisons en réalité du HTC. Il faut donc penser à copier vos données sur le noeud qui exécutera votre job pour utiliser cet espace, puis penser à récupérer vos données par la suite lorsque le job se termine.
Git nous permet de gérer au fil de l'eau nos développements de modules, de SaltStack et de FAI. En cas de besoin, nous pouvons revenir à la version voulue ou bien faire un développement sur une branche qui ne sera pas la même que la version en production.
Document généré par pandoc