Webinar NNCR Cluster n°2 (6 juin 2019)

Bonjour à tous,

Suite au webinar de ce jour, 2ème du nom, vous trouverez ci-joint les diapositives utilisées pour la présentation.
2019-06-06_Webinar_NNCR_Cluster_2.pdf (1,3 Mo)

Vous pouvez également visionner l'enregistrement vidéo du webinar.

45

Nous vous proposons de continuer la discussion ici-même pour répondre à vos questions ou prendre vos remarques.

A très bientôt

2 « J'aime »

Questions/Réponses issues d'autres canaux:

y-a-t'il un "lien" (API/image modèle spécifique...) permettant d'envoyer des calculs sur le cluster depuis le cloud ifb ?

Pas pour l'instant. L'accès au cluster se fait uniquement via SSH et le login node (core.cluster.france-bioinformatique.fr).

Pour des features request y-a-t'il un lien (automatique) entre le board gitlab et Discourse

Pas de lien automatique. Nous avons un lien entre le Slack et GitLab mais pas avec Discourse (i.e. community.cluster.france-bioinformatique.fr).

quelle technologie de stockage avez-vous retenu (même si j'ai compris que vous aviez des idées pour le futur et l'AO en cours) ? quelles sont les performances attendues, en débit, en accès aléatoire, en nombre de fichiers...

Actuellement nous utilisons MooseFS. Nous avons utilisé dans un premier temps GlusterFS, mais pour des raisons de performances nous avons basculé rapidement sur MooseFS (solution maîtrisé notamment par l'IGBMC). GlusterFS sur l'infrastructure matérielle existante (i.e. pas préconisé par RedHat, ce qui change beaucoup de chose) s'est révélé insuffisamment performant pour l'accès aux métadonnées ("ls" lent).
Pour l'augmentation du stockage, nous discutons de plusieurs solutions (BeeGFS, IBM Spectrum Scale, etc.).
La performance (débit, accès, etc) est évidemment un point clef. Nous visons des performances au-delà de 200.000 IO/s et une bande passante au-delà de 10 Go/s (en écriture). Nous n'avons pas spécifié plus (accès aléatoire/séquentiel, nombre/taille des fichiers, profondeur, etc) mais nous demandons d'évaluer la performance (benchmark public et maison) pour nous permettre de comparer les solutions.
Il y a aussi d'autre critères à prendre en compte. Nous avons en effet besoin de fonctionnalités comme les quotas, les ACL, les hard-links (pour conda), des snapshots, d'une solution extensible (scale-out), etc. Cela peut faire la différence.

dans la configuration Slurm, quelles sont les limites de durée des jobs ? comment allez-vous adresser les demandes d'exécution de jobs dont la durée excède cette limite ?

Dans slurm, nous avons actuellement 2 partitions

  • fast: MaxTime=1-00:00:00
  • long: MaxTime=10-00:00:00

Nous n'avons pas pour l'instant de demande excédant 10 jours. Il faut que l'on en discute.

@julien a entamé un travail pour développer la partie QoS (Quality of Service) de Slurm. Ce sera sûrement une partie de la réponse.