Wiki du LOL

Construire ensemble

Outils pour utilisateurs

Outils du site


vintage:lolhpc

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
vintage:lolhpc [2014/01/20 20:34] – 4 Exemples d'utilisation du lolhpcvintage:lolhpc [2024/10/29 20:01] (Version actuelle) – modification externe 127.0.0.1
Ligne 76: Ligne 76:
 <HTML><li></HTML><HTML><p></HTML>Déplacer la baie pour stockage pendant les travaux de la salle du fond<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Déplacer la baie pour stockage pendant les travaux de la salle du fond<HTML></p></HTML><HTML></li></HTML>
 <HTML><li></HTML><HTML><p></HTML>Mettre en place une solution pour le refroidissement et pour l’alimentation électrique.<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Mettre en place une solution pour le refroidissement et pour l’alimentation électrique.<HTML></p></HTML><HTML></li></HTML>
-<HTML><li></HTML><HTML><p></HTML>Calculeeeeer (ou pas) :)<HTML></p></HTML><HTML></li></HTML><HTML></ul></HTML>+<HTML><li></HTML><HTML><p></HTML>Calculeeeeer (ou pas) :)<HTML></p></HTML><HTML></li></HTML> 
 +<HTML><li></HTML><HTML><p></HTML>Mettre en place une politique iptable<HTML></p></HTML><HTML></li></HTML> 
 +<HTML><li></HTML><HTML><p></HTML>VLAN de management + VLAN pour l’interface et Internet<HTML></p></HTML><HTML></li></HTML> 
 +<HTML><li></HTML><HTML><p></HTML>Mettre un lien entre le switch de la box et les switchs du Supercalculateur<HTML></p></HTML><HTML></li></HTML> 
 +<HTML><li></HTML><HTML><p></HTML>Mettre en place NAT IPv4 et radv IPv6 sur le routeur<HTML></p></HTML><HTML></li></HTML> 
 +<HTML><li></HTML><HTML><p></HTML>Routage du range de management via le routeur<HTML></p></HTML><HTML></li></HTML><HTML></ul></HTML> 
 + 
 +===== Ce qui est fait ===== 
 + 
 +  * Renommer les lame dans le KVM 
 +  * Installer quelques Debian pour tester
  
 ===== Utilisation(s) possible(s) ===== ===== Utilisation(s) possible(s) =====
Ligne 82: Ligne 92:
 Indiquer ci-dessous les idées d’utilisation, avec une estimation des besoins en CPU, RAM, espace disque, et consommation réseau. 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 | +++ | + | | Encodage vidéo | +++ | ++ | +++ | +++ [[http://www.povray.org/|Ray-tracing]], rendu 3D | +++ | ++ | + | + Calcul scientifique (MPI, etc) | ++ | ++ | + | + """]]+[[!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) ===== ===== Référence(s) =====
vintage/lolhpc.1390250083.txt.gz · Dernière modification : 2024/10/29 20:01 (modification externe)