====== 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 Photo de la baie ===== 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) ==== ===== 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) ====