Et maintenant (...) ? Dois-je adopter RocksCluster ?

Vous savez désormais installer un cluster classique RocksCluster. L'intérêt majeur de RocksCluster est sa simplicité, la quantité importante d'utilisateurs et la réactivité de la liste de diffusion. Cependant, de nombreux systèmes permettent également d'installer/exploiter des clusters :

Le principal problème de RocksCluster est son aspect vieillissant et sa fréquence de mises à jour.

En effet, bien qu'étant assez modulaire, il est difficile de sortir de RedHat/CentOS and co. (ScientificLinux). RocksCluster est peu souvent mis à jour:

  • il faut attendre longtemps après une mise à jour de CentOS, or CentOS est déjà en retard par rapport à RedHat. Cela peut poser des problèmes évidents de sécurité (exemples récents de failles OpenSSL ou bien bash) ou si vous souhaitez accéder à des fonctionnalités implémentées dans des versions récentes de CentOS (ex: cgroups noyau / docker, version de python (2.6, 2.7), de yum et de la glibc par défaut...). Tout ceci peut être changé, patché, maintenu manuellement (...) mais nécessite du temps et des compétences.

Par contre, la faible fréquence des mises à jour indique également une certaine stabilité et l'orientation CentOS/RedHat amène comme avantage tout l'écosystème existant sous RedHat, notamment la certification de certains drivers, etc...

Par ailleurs, le côté diskfull n'est pas forcément un avantage. Vous avez un scratch en local, mais pour toute modification apportée à un noeud, vous devez la déployer sur tous les noeuds et modifier la procédure d'installation de vos noeuds ce qui rend cette phase de post-installation de plus en plus longue. En revanche, vous avez également toute la configuration du noeud en local ce qui diminue de facto le trafic réseau.

Dois-je adopter RocksCluster ?

Cette question est donc bien plus complexe qu'il n'y paraît et sort du contexte de ce TP et reste un point de vue subjectif.

Avant d'adopter RocksCluster et de choisir le matériel pour votre cluster, il faut se poser un certain nombre de questions :

  • Quels sont les moyens (humains, infrastructure (*), financiers) affectés au cluster et à sa gestion ?
  • Quel dimensionnement (taille du cluster, nombre d'utilisateurs) ?
  • Quelles displines, quelles applications et quels sont les types de calculs amenés à tourner sur mon cluster ?

(*): ex: en diskless on consommera moins (kW) et ça pèsera moins lourd, mais le coût de l'interconnexion sera sûrement plus élevé...

Comment les systèmes de fichiers parallélisés existaient il y a longtemps dans Rocks au travers de PVFS. Cependant, ce dernier n'est plus utilisé/maintenu et proposé par Rocks. Un "roll" lustre existe pour la version 6.0 de RocksCluster.


Cependant, RocksCluster reste une distribution Linux classique basée sur CentOS. Vous pouvez le modifier comme bon vous semble et tout le code de surcouche maison Rocks est libre et modifiable à souhait. Le fichier extend-compute permet de passer en phase de post-installation n'importe quel script shell.

A l'UMR5554/ISE-M et sur la plate-forme LabEx MBB, nous utilisons un RocksCluster modifié pour nos besoins :

  • pas de service 411 pour synchroniser nos utilisateurs, mais une connexion à un LDAP,
  • un système de déploiement et d'hébergement de packages maison,
  • plusieurs NAS déclarés dans Rocks (mais pas gérés par Rocks) sous debian like avec NFS/ZFS, qui hébergent les homes des utilisateurs et des applications ainsi que des librairies,
  • et de nombreux autres scripts maison.

Nous envisageons toutefois une migration vers une solution maison à base d'un serveur d'image et de distribution debian/*, avec SLURM comme gestionnaire de batch. Cependant, cela demande de rééduquer nos utilisateurs (comment soumettre et gérer ses jobs, etc...).

Dans le domaine de la bioinformatique, les mises à jour des applications sont régulières et il est important d'avoir un système récent pour bénéficier des dernières bibliothèques.

results matching ""

    No results matching ""