Bigmems

Introduction

Les bigmems désignent à l'ISEM des machines très performantes qui tournent très majoritairement sous GNU/Linux, en Ubuntu LTS (2018.04 ou 2020.04).

Il existe plusieurs types de bigmems :

  1. les machines privées ISEM,
  2. les machines réservables LabEx CeMEB,
  3. les machines réservables ISEM.

Un 4ème type de machines bigmem pourra probablement apparaître au sein du cluster de calcul de l'ISEM, dans une queue dédiée.

En effet, la grande majorité des machines bigmem sont d'anciennes machines privées achetées par des équipes ou des chercheurs de l'ISEM. Il est donc logique que l'ISEM dispose de plus de machines. Par ailleurs le manque de place ne nous permet pas d'accueillir plus de machines.

Pour l'instant les machines disponibles sont réservables sous GRR, après authentification : https://mbb.univ-montp2.fr/grr

Les machines peuvent être réservées au plus tôt 24 heures avant, mais il faut souvent compter un peu plus, car c'est en réalité J-1 avec J qui commence à minuit. Dans les faits, vous pourrez donc commencer au plus mieux à J-2, sauf demande expresse à un administrateur. Pour la durée, au plus, vous pouvez réserver une machine 3 semaines consécutives, durée renouvelable 1 fois, sur une période de 3 mois glissants. Pour les machines réservables ISEM, un peu de flexibilité sur ces durées reste possible.

Principe général

Les réservations de bigmems, lorsqu'elles sont validées par l'administrateur, sont ensuite réinstallées dans la nuit de votre 1er jour de réservation. Il n'y a pas de prise en compte de l'heure de début.

Vous recevez ensuite un mail automatique vous indiquant comment vous connecter à la machine avec un mot de passe.

Votre utilisateur a des droits élevés de sudoer, vous permettant d'installer ce que vous voulez. Ainsi, aucun support particulier n'est assuré; il est assumé que vous êtes autonome sous un shell Linux.

La machine étant réinstallée à la prochaine réservation, vous devez vous assurer avoir récupéré toutes vos données avant que votre réservation soit terminée. Si vous vous rendez compte que vous risquez que la durée risque d'être trop courte, merci de faire un ticket au plus tôt, pour éviter qu'une réservation soit validée après la votre (...), et demander une prolongation.

Ne faites surtout pas vous-même une nouvelle réservation derrière la votre ! En effet, si l'administrateur ne se rend pas compte que l'utilisateur est le même et de la volonté de continuer de travailler sur la même machine, il validera la nouvelle réservation et la machine sera réinstallée ! Les données seront perdues !

Pour plus de détails sur le fonctionnement technique, merci de vous reporter à la section fonctionnement.

Les programmes installés dans /share/apps sur nos clusters de calcul sont également disponibles sur les bigmems, tous comme les modules et guix. Si vous constatez un dysfonctionnement, merci également de faire un ticket.

Machines réservables ISEM

Les machines réservables disponibles pour l'ISEM se font sur demande, après création d'un ticket. Vous verrez alors apparaître dans grr une nouvelle catégorie, avec vos nouvelles machines.

MBBWorkflow

Le service conteneurisé (avec docker swarm + shinyproxy) MBBWorkflow disponible n'ayant guère trouvé son public, il est désormais possible de transformer une bigmem en machine "bioco" compatible, c'est à dire permettant de faire tourner des workflows bioinformatiques de type MBBWorkflow.

Lorsque vous faite votre réservation, indiquez simplement "Oui" pour MBBWorkflow à la fin. Toute les bigmems réservables, à l'exception de la bigmem0 (pas sur le bon réseau) sont compatibles.

Il vous suffira ensuite de suivre les instructions ici pour terminer l'installation lorsque vous aurez accès à cette dernière.

Problèmes habituels

Si vous avez déjà utilisé une bigmem et qu'elle vous est de nouveau attribuée (ou bien vous avez choisi la même), vous aurez un message de clé SSH déjà connues par votre système (ou pour être plus précis de Fingerprint de l'hôte).

C'est tout à fait normal, puisque de nouvelles clés ont été régénérées à la réinstallation de la machine. Vous n'avez donc rien à craindre.

Le message commence ainsi :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

La solution est souvent donnée dans le message lui-même avec la commande à faire.

Si ce n'est pas le cas, vous pouvez éditer votre fichier known_hosts ou effectuer un ou plusieurs sed selon les besoins; par exemple :

ssh remy@<ip.ip.ip.ip hidden>

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:...................................
Please contact your system administrator.
Add correct host key in /home/remy/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/remy/.ssh/known_hosts:296
Host key for <ip.ip.ip.ip hidden> has changed and you have requested strict checking.
Host key verification failed.

# suppression de la clé concernant cet hôte.
# Celle-ci est présente à la ligne 296 
sed -i 296d /home/remy/.ssh/known_hosts

Fonctionnement

Détails technique de fonctionnement interne (cliquez ici pour déplier) Les réservations validées sont reportées dans un caldendrier système au format caldav grâce à un hack de GRR et des scripts maison (voir ici pour plus d'informations). Un Cron sur un master salt vérifie alors ce calendrier. Lorsque le script lancé par cron détecte une nouvelle réservation, il vérifie le contenu de l'évènement.
Selon le type et le contenu de l'évènement, au choix, il redémarrera un conteneur GPU sur des machines GPU, réinstallera une bigmem, et rajoutera éventuellement les spécificités systèmes pour les machines "bioco" compatibles MBBWorkflow.
Le master saltstack contrôle les serveurs FAI /tftp et DHCP. Ainsi, ces derniers sont d'abord mis à jour avec un orchestrateur SaltStack, puis la machine est redémarrée par SaltStack. Lorsque la machine a été réinstallée par FAI et que le paquet SaltStack a été installé, cette dernière contacte le master SaltStack qui la rajoute à nouveau puis déploie les recettes de post-install.

Un espace large est présent dans le répertoire personnel de l'utilisateur. Il s'agit d'un aggrégat de disques sous ZFS. Autrefois situé dans /media/bigvol/<username>, ce dernier se situe désormais dans /home/<username>. /media/bigvol étant désormais un lien symbolique qui pointe uniquement vers /home.

results matching ""

    No results matching ""