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 :
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 Mosixolivier@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
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âcheLIMITATIONS
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.
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
et effectivement ça fonctionne :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.
(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.
