====== LOLHPC ======
Un supercalculateur au LOLcal xD
[[!toc startlevel=“2” levels=“3”]]
===== Description =====
[[https:%%//%%en.wikipedia.org/wiki/High-performance_computing]]
Construction d’un supercalculateur à partir de matériel récupéré à l’in2p3
===== Participants =====
* mirsal
* olivier
* lordzurp
* martin
* zorun
==== Référent(s) ====
==== Contributeur(s) ====
* mirsal
* olivier
* lordzurp
* martin
* zorun
==== Compétence(s) recherchée(s) ====
HPC, Grid computing, clusters
===== Détails =====
==== Matériel(s) utilisé(s) ====
32 noeuds de calcul scientifique NEC récupérés à l’in2p3 (Institut National de Physique Nucléaire et de Physique des Particules) en chassis 1U montés dans une baie 19"
2x Xeon (21 à 2.8GHz et 11 à 3GHz) génération NetBurst (certainement ça [[https:%%//%%fr.wikipedia.org/wiki/Liste_des_mod%C3%A8les_de_Xeon#Nocona]])
4x512Mo DDR ECC reg (et 2 slot libres)
2x120Go sata, lecteur CD
dual lan, 1 port PCIX full size et 1 port PCIX half-size, module IPMI …
alimentation sur 3 arrivées, 1800W/prise
Conso mesurée : - 56W pour les switch - 240W / serveur sans calculs
Conso totale estimée : 7.7kW
==== Objectif(s) ====
Un supercalculateur fonctionnel dans le LOLcal
==== Milestone(s) ====
Déplacer le tout dans la salle du fond:
les deux portes ne font pas la même hauteur, je n’ai mesuré que la première avant de charger la baie => Fail de 3cm.
-> Une après midi / soirée à 3-4 personnes
Un supercalculateur au milieu du LOLcal, ça fait désordre xD
Tâche effectuée puis annulée pour cause de travaux dans la salle du fond et réaménagement.
Réaliser l’interconnexion des nœuds:
La baie est câblée mais pas switchée. on a des switchs 100Mbit/s à dispo et suffisement de câbles pour réaliser le brassage. Il manque des serre-flex et des écrous et il faudrait idéalement récupérer deux switchs gigabit 24 ports.
Tâche réalisée, mais à vérifier depuis le déménagement.
Connecter la baie au reste du réseau du lol
Il faut faire passer des câbles entre les deux salles, créer du vlan et de l’aggrégat.
Préparer et installer la partie logicielle
On ne va pas utiliser les SL pourries de l’in2p3. Ce qu’on va installer dépendra de ce qu’on va faire avec.
Déplacer la baie pour stockage pendant les travaux de la salle du fond
Mettre en place une solution pour le refroidissement et pour l’alimentation électrique.
Calculeeeeer (ou pas) :)
Mettre en place une politique iptable
VLAN de management + VLAN pour l’interface et Internet
Mettre un lien entre le switch de la box et les switchs du Supercalculateur
Mettre en place NAT IPv4 et radv IPv6 sur le routeur
Routage du range de management via le routeur
===== Ce qui est fait =====
* Renommer les lame dans le KVM
* Installer quelques Debian pour tester
===== Utilisation(s) possible(s) =====
Indiquer ci-dessous les idées d’utilisation, avec une estimation des besoins en CPU, RAM, espace disque, et consommation réseau.
[[!table data=""" Utilisation | CPU | RAM | Espace | Réseau Minage Bitcoin/litecoin |+++|+|+|+ Encodage vidéo (OpenMediaKit) |+++|++|+++|+++ [[http://www.povray.org/|Ray-tracing]], rendu 3D |+++|++|+|+ Calcul scientifique (MPI, etc) |++|++|+|+ Cryptage (?) |++|/|/|/ Relais Tor |++|+|/|+++ Compilation distribué |+++|++|+|++ Noeud Boinc (calcul distribué) |+++|++|+|+ """]]
Ce serait cool de proposer un accès à d’autres hackerspaces via [[https://dn42.net|dn42]]. Par contre, ce serait mieux avec une vraie connexion réseau (pas de l’ADSL).
Autre idée : hacker le protocole du KVM
==== Solution utilisable : ====
* Slurm+MPI
* Openstack
* Hadoop ou Spark
* Razor
* DN42
* ChaosVPN
===== Stockage =====
On aimerait avoir les mêmes données (/home) sur chaque noeud : ainsi, on peut se connecter à n’importe quel noeud allumé pour lancer ses calculs.
Deux familles de solutions :
* **centralisé :** en gros, un serveur NFS dans lequel tous les noeuds vont taper
* **distribué :** système de fichier réparti ou autre solution de synchronisation
La première solution est à éviter : ça oblige à avoir une machine qui tourne tout le temps, il faut s’assurer de la redondance des données, les perfs seront catastrophiques dès que plusieurs noeuds feront des I/O, et ce serait dommage de ne pas utiliser les disques des noeuds du cluster.
On part plutôt sur la seconde solution (parce qu’en plus, c’est rigolo à faire). Il y a cependant un nouveau problème potentiel : le //split brain// ([[https://fr.wikipedia.org/wiki/Split-brain|wikipedia]]).
==== Problème du split brain ====
Typiquement, tous les noeuds du cluster ne seront pas allumées en permanence. On aimerait par exemple pouvoir faire la chose suivante :
* Allumer la moitié des noeuds
* Écrire des choses dans le système de fichier réparti
* Éteindre les noeuds
* Allumer l’autre moitié des noeuds
* Écrire d’autres choses dans le système de fichier réparti
* Rallumer la première moitié des noeuds
* (le système de stockage réparti fait sa cuisine)
* Les mêmes données sont disponibles sur tous les noeuds !
Il faut une solution de stockage réparti qui permette ça.
==== Répartition du stockage ====
* **Solution 1 :** RAID-0 sur chaque noeud, donc 2x 120 GB = 240 GB disponible. Les données sont répliquées à l’identique sur chaque noeud.
* Capacité totale : 240 GB
* Avantages : grande redondance, flexibilité (on peut allumer de 1 à 32 machines)
* Inconvénients : peu de capacité totale, performances en écriture (à tester)
* **Solution 2 :** regroupement des noeuds par paires : RAID-0 sur chaque noeud, puis “RAID-0 réseau” entre deux noeuds d’une même paire. Ensuite, les données sont répliquées à l’identique sur chaque paire.
* Capacité totale : 480 GB
* Avantages : redondance, performances en écriture probablement meilleures
* Inconvénients : plus complexe, beaucoup moins flexible (il faut allumer les machines par paires)
==== Système de fichier réparti ====
Utilisation d’un vrai système de fichier réparti (soit kernelspace, soit userspace)
* [[https://en.wikipedia.org/wiki/Ceph_%28storage%29|Ceph]]
* [[http://www.gluster.org/|Glusterfs]]
* [[http://wiki.lustre.org/index.php/Main_Page|Lustre]]
* [[http://www.drbd.org/|DRDB]]
Ce dernier n’est pas vraiment un système de fichiers : c’est un périphérique bloc distribué, sur lequel on peut mettre n’importe quel système de fichier.
==== Synchronisation ====
On peut aussi faire le contraire : mettre n’importe quel système de fichier “classique” (ext4) sur chaque noeud, et synchroniser les données par-dessus. Ça paraît beaucoup plus hackish, mais ça peut marcher, et c’est surtout plus simple.
* [[http://www.cis.upenn.edu/~bcpierce/unison/|unison]] a un mode qui permet de synchroniser de façon répétée, à intervalle régulier. Par contre, ça fait de la synchro bidirectionnelle entre deux machines seulement. Pour un cluster, il peut imaginer une topologie en étoile (tout les noeuds synchronisent avec une machine donnée), mais ce n’est pas distribué et ça ne doit pas passer très bien à l’échelle.
* [[http://oss.linbit.com/csync2/|Csync2]] : beaucoup plus adapté ! [[http://oss.linbit.com/csync2/paper.pdf|Documentation]]
===== Gestion de la configuration =====
On ne veut pas s’embêter à installer/configurer/gérer les utilisateurs sur chaque noeud.
Plus précisément, on voudrait automatiser :
* **Provisioning des utilisateurs :** création d’utilisateur sur tous les noeuds d’un coup (mot de passe, clé SSH, groupes)
* **Provisioning des paquets :** pouvoir déployer des paquets sur tous les noeuds d’un coup
Il y a plein de solutions pour ça :
* [[http://puppetlabs.com/|Puppet]]
* [[http://www.ansibleworks.com/|Ansible]]
* [[http://www.saltstack.com/community/|Salt]]
* …
===== Référence(s) =====
==== Document(s) ====
==== Lien(s) ====