Page 1 sur 1

Clustering /Linux à des fins de calcul distribué.

Publié : ven. 5 févr. 2021 10:08
par Ryu_wm
Petit test de clustering sous Linux.
Par clustering j'entends distribution de la charge, pas du failover. On trouve aussi le terme de grille (grid) de calcul.

C'est un projet autour duquel je tourne depuis le début des années 2000 mais j'ai fait une grosse parenthèse entre 2008 et 2021.

J'avais déjà testé (de mémoire) Hadoop, OpenMosix, Oscar.
Certains sont des MPI (message processing interfaces) ce qui ne sied pas à ce que je cherche à faire : faire tourner 1 application sur les ressources de plusieurs noeuds. le MPI ce n'est pas tant pour de l'applicatif mais plutôt du script.

Le clustering tel que je l'entend ici est un peu l'inverse de la virtualisation. la V permet avec des ressources d'1 machine de créer n bulles qui se partagent les ressources. la grille c'est n ressources mises en commun (cpu,ram,disque) pour faire simuler 1 machine unique.

Aujourd'hui je teste Mosix, un vieuuuuuux projet http://www.mosix.org/ mais lui donne encore ses librairies et est assez bien documenté contrairement à d'autres, même à l'échelle de projets communs européens où les sites web ne sont même plus maintenus.

Donc hop, un iso Linux 64 bits (ici je préfère un Ubuntu 16.04LTS que je "maîtrise" plus que d'autres, et les librairies MOSIX 4.4.4.
Pour le hardware je me sers dans une pile de HP Prodesk 400 DM 1 qui trainent (https://www.google.com/search?q=HP+Prod ... FR922FR922)

Installation d'Ubuntu en 30 minutes sur 3 stations.
on copie colle détarzip les lib Mosix
on suit la doc pour créer les répertoires qui vont bien et coller les fichiers aux bons endroit (j'ai scripté ça car à faire sur plusieurs noeuds)
http://www.mosix.org/pub/Guide.pdf

ensuite quand tout est bon on configure les noeuds. Perso je trouve plus pratique de paramétrer les noeuds esclaves en premier, pour leur adresse IP et je fichier secret qui permet la communication inter noeuds. Ensuite sur le noeud principal on lui fait scanner l'étendue réseau afin qu'il trouve les noeuds et les mappe dans un fichier (1 ip = 1 noeud), simple tant qu'on reste au sein du même LAN moins quand on doit faire communiquer plusieurs grappes sur des plans IP/sites différents.

une fois la configuration de tous les noeuds effectuée, on teste si la communication se passe bien et on va donner une tâche au cluster et voir si elle se répartie bien.
j'ai choisi de faire tourner un script "while;do a=1;do" et je le soumets en tâche
./mosrun script

via l'outil de monitoring mosmon je vois la charge se répartir sur les noeuds (normalement !)
->OK

Maintenant que je sais que ça fonctionne, j'en arrive à mon but réel :
faire tourner un applicatif de calcul distribué sur le cluster.
Pour ce faire j'utilise mon vieil ami Distributed.net https://www.distributed.net/Download_clients
je rapatrie un client et un peu de charge de travail suffisant pour 3*4 vCPU.

je lance Dnet sur Mosix ./mosix/mosrun -b ../dnet/dnetc et ... c'est le drame :
olivier@Mosix-Node0:~/mosix$ su
Mot de passe :
root@Mosix-Node0:/home/olivier/mosix# mosrun -b -m1200 -e ../dnet/dnetc

distributed.net client for Linux Copyright 1997-2016, distributed.net
Please visit http://www.distributed.net/ for up-to-date contest information.
Start the client with '-help' for a list of valid command line options.


dnetc v2.9112-521-CFR-16021317 for Linux (Linux 4.8.0-36-generic+MOSIX).
Please provide the *entire* version descriptor when submitting bug reports.
The distributed.net bug report pages are at http://bugs.distributed.net/
Using email address (distributed.net ID) '___@hotmail.com'

[Feb 04 08:51:13 UTC] Automatic processor detection found 4 processors.
Erreur de segmentation (core dumped)
MOSRUN: system-call 'shmat' not supported under mosix
le problème ici c'est shmat, un souci de mémoire partagée, c'est implémenté dans l'applicatif et Mosix prévient qu'il ne gère pas, voici ce que dit la doc de Mosix
LIMITATIONS
Some system-calls are not supported by migratable programs, including system-calls that are tightly connected to resources of the local node or intended for system-administration. These are:
acct, add_key, adjtimex, afs_syscall, bdflush, capget, capset, chroot, clock_getres, clock_nanosleep,
clock_settime, create_module, delete_module, epoll_create, epoll_create1, epoll_ctl, epoll_pwait, epoll_wait,
ev entfd, eventfd2, fanotify_init, fanotify_mark, futex, get_kernel_syms, get_mempolicy, get_robust_list,
getcpu, getpmsg, init_module, inotify_add_watch, inotify_init, inotify_init1, inotify_rm_watch, io_cancel,
io_destroy, io_getevents, io_setup, io_submit, ioperm, iopl, ioprio_get, ioprio_set, kexec_load, keyctl,
lookup_dcookie, madvise, mbind, migrate_pages, mlock, mlockall, move_pages, mq_getsetattr, mq_notify,
mq_open, mq_timedreceive, mq_timedsend, mq_unlink, munlock, munlockall, nfsservctl, perf_event_open,
personality, piv ot_root, prlimit64, prof_counter_open, ptrace, quotactl, reboot, recvmmsg, remap_file_pages,
request_key, rt_sigqueueinfo, rt_sigtimedwait, rt_tgsigqueueinfo, sched_get_priority_max, sched_get_priority_min, sched_getaffinity, sched_getparam, sched_getscheduler, sched_rr_get_interval, sched_setaffinity,
sched_setparam, sched_setscheduler, security, set_mempolicy, setdomainname, sethostname, set_robust_list,
settimeofday, shmat, signalfd, signalfd4, swapoff, swapon, syslog, timer_create, timer_delete, timer_getoverrun, timer_gettime, timer_settime, timerfd, timerfd_gettime, timerfd_settime, tuxcall, unshare, uselib,
vmsplice, waitid.
Mosix offre des possibilités d'isolement et de contournement (notamment les commutateurs e et w) mais au mieux je n'arrive à faire tourner le client que sur 1 noeud : celui qui soumet la tâche :(
Image

je me rends donc sur le site Distributed.net, je sais qu'ils ne donnent pas les sources de leur code (problème de triche) mais peut être y a t'il une piste ou une version du client qui ne partage pas sa mémoire ? Et là, magique, les FAQ parlent du clustering :
http://faq.distributed.net/cache/58.html
Client versions prior to v2.8014.468 were capable of being used on a MOSIX cluster. Subsequent client versions use shared memory which prevents migration on a MOSIX cluster. A separate client for Linux-x86/ELF using pthreads was made available as v2.9001.478 which inherently disabled the need for shared memory. Starting with client v2.9003-480, the generic client disables the use of shared memory when specifying the '-numcpu 0' setting on the command line.
et effectivement ça fonctionne :
Image
(ici le noeud 0 est occupé par mes soins interface graphique et capture écran + découpage, etc.)

Donc Mosix 4 fonctionne facilement.
Les scripts se répartissent sans problème, les applicatifs doivent être compatibles c'est plus compliqué.
Dans le cas spécifique du client de calcul distribué Dnet il faut l'affecter manuellement à chaque processeur du cluster ce qui abolie un peu la philosophie d'un cluster (autant faire tourner le client en local sur chaque PC) mais ça a le mérite de permettre de vérifier la distribution de tâche et sa répartition dans le cluster.

Re: Clustering /Linux à des fins de calcul distribué.

Publié : ven. 5 févr. 2021 11:37
par Ryu_wm
Hop, je vais faire tourner les 12 cpu pendant approximativement 96h et comparer si j'obtiens la même chose que de faire tourner Dnet sur 3 stations.

Ensuite, si résultat positif et si mardi j'ai un peu de temps, j'agrandirai la plateforme.

Re: Clustering /Linux à des fins de calcul distribué.

Publié : mar. 9 févr. 2021 10:35
par Ryu_wm
Essai concluant. La "perte" de temps de calcul n'est que minime.
En revanche, trop de taf je ne peux pas me permettre de tester à plus grande échelle.

Image

Re: Clustering /Linux à des fins de calcul distribué.

Publié : ven. 12 févr. 2021 09:24
par Ryu_wm
Voilà, un peu de temps libre, agrandissement du cluster.

Alors pour info, on perd du temps à cloner les disques et reconfigurer Mosix sur les noeuds supplémentaires.
Etrangement moi ça ne fonctionnait pas (changement nom de machine/IP/conf Mosix), les daemons associés à Mosix refusaient de se lancer.
Donc, install fraiche Ubuntu+Mosix+conf et en route.

Image

Image

Vais laisser tourner 96h.

Re: Clustering /Linux à des fins de calcul distribué.

Publié : ven. 12 févr. 2021 11:06
par Zedoune
Tu t’étonneras pas de ta consommation électrique j'espère :D

Re: Clustering /Linux à des fins de calcul distribué.

Publié : sam. 13 févr. 2021 09:29
par Ryu_wm
7*4*3.2 GHz pour ~7*55 W, on est pas mal.

De toute façon cette expérience est menée sur mon lieu de travail ;)

Re: Clustering /Linux à des fins de calcul distribué.

Publié : sam. 13 févr. 2021 21:17
par augur1
Respect !!

Re: Clustering /Linux à des fins de calcul distribué.

Publié : mer. 17 févr. 2021 12:00
par Ryu_wm
bon ben vraiment sympa, en tout cas pour ce qui est de la puissance de traitement.
Couplé à un bon DFS ça doit être super.

En terme de puissance j'obtiens ceci sur 7 core i3-4160T * 4vCPU @3.1GHz
Image

à mettre en relation avec un mono Xeon E3-1220V2 * 4vCPU @3.3Ghz
Image

le ratio de calcul pour l'appli donne le cluster à 4.8* la puissance de traitement du Xeon.
Je sais que le client Dnet est tributaire de la mémoire cache L1 et L2, j'ai la flemme de chercher les specs de chaque CPU mis en balance, mais le ratio calcul du cluster me parait très satisfaisant.

Je regrette de ne pas avoir mené cette expérience il y a 20 ans quand la puissance de traitement valait cher...

Re: Clustering /Linux à des fins de calcul distribué.

Publié : ven. 21 mai 2021 14:43
par jsonline_bis
Bravo Ryu.
En 2002, j'habitais dans le centre Paris et je m'étais interressé à ce que faisais la société Alinka sur ce sujet.
J'avais même été les voir (leur agence du 75003) et pris une plaquette mais j'ai dû accepter que tester un truc comme ca dépassait très largement mes ressources matérielles et connaissances de l'époque. J'ai encore cette plaquette en souvenir. Alinka faisait partie du groupe prologue software ( https://www.01net.com/actualites/prolog ... 11150.html) .
Diverses solutions de clustering Linux, dont Alinka, de cette époque sont évoqués ici :
http://www-igm.univ-mlv.fr/~dr/XPOSE200 ... 0linux.htm

Re: Clustering /Linux à des fins de calcul distribué.

Publié : ven. 21 mai 2021 15:33
par jsonline_bis
En s'éloigant un peu du sujet (mais pas trop) on trouve aussi les bases de données Teradata : voir par exemple : https://pageperso.lis-lab.fr/bernard.es ... ata-4p.pdf

Re: Clustering /Linux à des fins de calcul distribué.

Publié : jeu. 2 juin 2022 08:41
par Ryu_wm
Hier j'ai eu l'opportunité de faire un noeud de calcul de 92 stations.
Mais trop la flemme et trop peu de temps dispo.

Image

Re: Clustering /Linux à des fins de calcul distribué.

Publié : jeu. 2 juin 2022 09:23
par gizmo78
ça fait des supers noeuds de virtu pour du homelab ça!

Re: Clustering /Linux à des fins de calcul distribué.

Publié : jeu. 2 juin 2022 10:07
par dsebire
c'est quoi comme machines ?

Re: Clustering /Linux à des fins de calcul distribué.

Publié : jeu. 2 juin 2022 13:05
par gizmo78
thinkcenter lenovo, y a facilement du i5 4C/8T dedans et tu peux y coller 32Go et au mini ssd sata voir nvme

Re: Clustering /Linux à des fins de calcul distribué.

Publié : ven. 3 juin 2022 10:15
par Ryu_wm
hop hop hop
c'est du matériel acquis en marché global pour les ministères.
la plupart de ces stations sont en céléron G3900T ou AMD Pro 200/4Go/hdd méca. 1/3 embarque des ssd nvme mais pas plus.
perso même pour de la bureautique je les déconseille, on ne peut rien faire avec (en tout cas pas de la navigation internet).
Les stations les plus abouties sont de très vieilles HP G400 en core i3-34xx c'est pour dire.

mais en fait ce qui est lamentable c'est qu'un coup de canif a été mis dans le contrat, normalement ces stations sont revendues (50 balles max hein ... ) mais a priori la société avec qui on a un contrat est débordée ou ne veut plus (je ne sais pas) du coup celles de la photo partent en D3E :o

Comme c'est du matériel de l'état on ne peut rien en faire, on peut même pas les donner à un autre ministère (éducation par exemple !) car bien trop compliqué.