Commit afff76a8 authored by remy's avatar remy
Browse files

rajout d'une doc sur les bigmems !

parent 2b2050ac
# 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 bigmem peut 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 tôt à J-2, sauf [demande expresse à un administrateur](https://kimura.univ-montp2.fr/calcul/helpdesk_NewTicket.html).
Au plus, vous pouvez réserver une machine 3 semaines consécutives, 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 est 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](https://kimura.univ-montp2.fr/calcul/helpdesk_NewTicket.html) au plus tôt, pour éviter qu'une réservation soit validée après la votre (...), et demander une prolongation.
>**Warning** Ne faite 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é est 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](#fonctionnement).
## Machines réservables ISEM
Les machines réservables disponibles pour l'ISEM se font sur demande, après création d'un [ticket](https://kimura.univ-montp2.fr/calcul/helpdesk_NewTicket.html).
Vous verrez alors apparaître dans [grr](https://mbb.univ-montp2.fr/grr) une nouvelle catégorie, avec vos nouvelles machines.
## MBBWorkflow
Le service conteneurisé (avec [_docker swarm_](https://docs.docker.com/engine/swarm/) + [_shinyproxy_](https://shinyproxy.io/)) **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](https://gitlab.mbb.univ-montp2.fr/jlopez/subwaw) 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`](https://www.gnu.org/software/sed/manual/) 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:XvkUe6S4fje46qM9bQuzUZMgmrX7JUVpbjAk54WQ8bI.
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
Les réservations validées sont reportées dans un caldendrier système au format [`caldav`](https://fr.wikipedia.org/wiki/CalDAV) grâce à un hack de [GRR](https://github.com/JeromeDevome/GRR) et des scripts maison (voir [ici](https://github.com/JeromeDevome/GRR/issues/60#issuecomment-439018679) 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](https://fai-project.org/)/tftp et DHCP. Ainsi, ces derniers sont d'abord mis à jour avec un [orchestrateur](https://docs.saltproject.io/en/latest/topics/orchestrate/index.html) [SaltStack](https://docs.saltproject.io/en/latest/), 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.
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment