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 traine (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 :(
https://zupimages.net/up/21/05/fsjv.png

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 : https://zupimages.net/up/21/05/tuvn.png
(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...