BEOWULF vs MOSIX

1. Ivan Rodero e6701137@est.fib.upc.es Maig 2001 BEOWULF vs MOSIX

2. - ÍNDEX - • Introducció • Arquitectures paral·leles • Beowulf • PVM i MPI • Mosix • Beowulf vs Mosix • Conclusions • Bibliografia • URL’s relacionades

3. Introducció • Actualment estan “de moda” les arquitectures paral·leles • Raó de ser del processament en paral·lel és accelerar la resolució d’un problema, és a dir, incrementar l’ speed up • És vital realitzar una bona paral·lelització de l’aplicació (Més informació als apunts de CASO) • Camps d’acció de la supercomputació: • Meteorologia • Física de la matèria condensada (dinàmica molecular,...) • Estudis de proteïnes • Generació d’imatges per ordinador de models realístics • Enginyeria, etc...

4. Taxonomia de les arquitectures de computadors SISD SIMD Memòria Compartida MMP MIMD Memòria Distribuida COW Cluster Beowulf

5. Taxonomia de les arquitectures paral·leles • SIMD (Single Instruction, Multiple Data) Un sol flux d’instruccions i varis fluxes de dades. • Són ordinadors poc potents però en grans quantitats (ordre de milers) • Hipercub, cal una estació de treball que actui com a controlador (host) • Arquitectura força inflexible • Utilitzat bàsicament en entorns de recerca • Podríem fer un símil entre aquest tipus d’arquitectures amb un programa de TV de gimnàstica on la monitora dóna instruccions i milers o milions de persones van repetint des de casa seva

6. Taxonomia de les arquitectures paral·leles • MIMD (Multiple Instruction, Multiple Data) Varis fluxos d’instruccions i varis fluxes de dades. • Els processadors d’arquitectures MIMD acostumen a ser més potents • Cada processador actua de forma esencialment diferent, això s’anomena “descomposició de control”. • SPMD (Single Program, Multiple Data) Programa únic, dades múltiples • Similar a SIMD però el codi pot fluir a través de branques de codi diferents • És més flexible

7. Memòria Compartida • Varis processadors accedeixen al mateix espai d’adreces • Baixa latància • Gran ample de banda • El número de processadors acostuma a ser menor o igual a 16 normalment • A la combinació de MIMD i de memòria compartida s’anomena SMP (Symmetric Multiprocessing, multiprocés simètric).

8. Memòria Distribuida • Basat en el model de pas de missatges !! • Latència elevada • Ús de l’ample de banda amb un acurat repartiment de les dades sobre els processadors • Si comparteixen el mateix bus se’ls anomena processadors enormement pral·lels (MPP, Massively Parallel Processors) • Exemples: Fujitsu VPP, IBM SP2 • Són molt costoses i potents • En el cas de disposar de múltiples ordinadors, enllaçats per una xarxa més o menys ràpida, parlarem d’un CLUSTER

9. Clusters • Bàsicament podem parlar de dos models diferents, els classe Beowulf i els COW (Cluster Of Workstations) • Aquest tipus d’arquitectures s’estan utilitzant cada vegada més i cada cop agafen més importància • El model basat en clusters ens dóna força avantatges: • Escalabilitat (fins a sistemes molt grans) • Preu (es tracta de hardware de baix-mig cost) • Reaprofitament de màquines antigues (relacionat amb el preu) • Cada màquina es pot utilitzar per altres propòsits • Facilitat per substituir un ordinador defectuós • Existeix força suport software per a la seva programació

10. I Linux ? • Linux és idoni per diferents raons: • Elseu caràcter obert • El seu disseny modular • L’existència de controladors per a tot tipus de dispositius de xarxa • Els seu extraordinari rendiment • La disponibilitat per a diverses arquitectures • Inmillorable suport tècnic (enorme comunitat d’usuaris) • Sobretot és barat i disposem del codi font (és versàtil) • Així doncs, a partir d’ara ens centrarem bàsicament en els Clusters en Linux, encara que es poden fer amb altres SO

11. Beowulf • Etern problema del pressupost • No tots els laboratoris es poden permetre comprar un supercomputador prefabricat • Tenim bàsicament 2 opcions: • Utilitzar varis computadors de baixa potència i instal·lar-hi Linux. A sobre de Linux utilitzar PVM (software de pas de missatges), es tracta d’un COW, i aconseguim un supercomputador de baix pressupost. • Més rendiment amb el mateix cost: supercomputadors classe Beowulf.

12. Què és un Beowulf ? • Un Beowulf és un conjunt de nodes minimalistes (cadascun té el mínim per poder funcionar), lligats per un mitjà de comunicació barat, en el que la topologia de la xarxa s’ha dissenyat per a resoldre un tipus de problema específic. • La programació és fortament dependent de l’arquitectura, es poden utilitzar com a llibreries l’interfície de sockets, la PVM o la MPI. • No utilitzen mecanismes de memòria compartida entre nodes, la comunicació es fa mitjançant pas de missatges. • Un programa desenvolupat tenint en compte la topologia de Beowulf és més ràpid que l’equivalent en un COW amb PVM, per l’absència de colisions i el hardware resulta molt més barat.

13. Software per a Beowulf • La major part és de domini públic (SO, compiladors, llibreries, etc...) • Aprofitable per a Linux i Unix • En el cas de que estigui paral·lelitzat utilitzant PVM, MPI o sockets, l’adaptació al Beowulf és trivial. • En el cas de que no estigui paral·lelitzat, té el mateix grau de complexitat una paral·lelització higiènica del problema que una paral·lelització orientada a executar en un Beowulf. • Hi ha un important falta de llenguatges. Hi ha l’opció de programar directament amb sockets però és una possible font d’errors i té un cert grau de complexitat. Relacionat amb aquest problema Mosix té molt a dir.

14. Linux Extreme • Independentment al projecte Beowulf, encara que de forma paral·lela, ha surgit un grup de treball que persegueix els mateixos objectius amb el seu software • És el denominat Linux Extreme • Organitzen events i desenvolupen software lliure, en els que l’objectiu és fer supercomputació amb màquines Linux • De fet, es tracta d’una distribució de Linux realitzada entre Red Hat i la NASA orientada a clusters

15. PVM o MPI • PVM (Paralel Virtual Machine) i MPI (Message-Passing Interface) són les llibreries de programació paral·lela per excel·lència. • Les principals característiques: • Estàndar: PVM és l’estàndar de fet però MPI és l’estandar formal (desenvolupat per al 1993 per un comité de 60 experts) • Tolerancia a fallades: a PVM si cau un node, els altres poden seguir endavant amb l’execució del programa. MPI no té aquest mecanisme de recuperació. • Heterogeneitat: la màquina virtual fa que PVM funcioni molt bé en clusters heterogenis. MPI espera que el hardware sigui homogeni, una màquina MPP o els ordinadors idèntics.

16. PVM o MPI • Rendiment: Cal esperar que MPI tingui millor rendiment que PVM, especialment en màquines MPP. • Base instal·lada: Al ser força posterior, el número de programes que fan ús de MPI és significativament inferior als que utilitzen PVM. • Control d’execució i gestió de recursos: PVM especifica com executar els programes independentment del hardware i del SO. També inclou un mecanisme per la gestió de recursos. MPI cap dels dos. • Topologia: Amb MPI és possible especificar la topologia de connexió entre elements per optimitzar les comunicacions. PVM no disposa d’aquesta capacitat. • API: Al ser posterior a PVM, MPI va apendre dels seus errors i ofereix un API més senzill i eficient.

17. PVM o MPI • Interoperabilitat: Diferents implantacions de MPI poden no cooperar correctament entre sí. Fins i tot pot passar que un programa en C no pugui comunicar-se amb un altre en Fortran. PVM no té aquests problemes. • Complexitat: PVM mostra un propòsit definit en tot el seu disseny. MPI és una llibreria més complexa. • Flexibilitat en les comunicacions: El conjunt de funcions de comunicació de MPI és més ric que el de PVM. • PVM guanya 6 a 5. Un millor comportament en entorns heterogenis i tolerància a fallades pot ser que fagin de PVM la millor alternativa per a la programació de clusters. • Però dependrà de factors com el hardware, l’aplicació concreta,...

18. Mosix • Programar un codi capaç d’adaptar-se a un Beowulf complica el desenvolupament del codi • Si no tenim el codi font d’una aplicació i volem adaptar-la a un cluster paral·lel, utilitzar una arquitectura clase Beowulf porta a un codi poc eficient en molt casos • Taló d’Aquiles dels Beowulf : Repartiment de la càrrega • En Mosix, el model hardware és exactament el mateix que en la arquitectura Beowulf, és a dir, la quantitat elevada de nodes de potència computacional baixa o mitja, o sigui hardware amb la millor relació FLOPS/$ possible

19. Mosix - Característiques • Podem definir un supercomputador classe Mosix com un conjunt de “patches” (afegits) que s’apliquen al Kernel tals que: • Doten a un conjunt de màquines, minimalistes o no, la facilitat d’un espai de processos comú • Els processos migren d’un node cap a un altre segons la càrrega de la màquina i la memòria lliure • Utilitzen per això un algoritme de planificació adaptatiu. • La columna vertebral d’aquest procés és la denominada migració. • La migració consisteix en el fet que un procés passa d’un node a un altre de forma transparent a l’usuari.

20. Mosix - Característiques • A diferència del Beowulf, el programador que desenvolupa una aplicació per a Mosix i l’usuari que l’executa, no veu el cluster com a tal. Es comporta com un multiprocessador on la CPU de cada node es tradueixen en la CPU de l’hipotètic multiprocessador virtual SMP. • Es produeix un increment en la càrrega del sistema pel procés de migració. • Totes les decisions són preses de forma descentralitzada, local als processadors involucrats. Gràcies a això tenim alguns benificis addicionals: • Facilitat addicional per afegir i el·liminar nodes en calent !! • El fet de que les dades sobre els estats de la màquina no s’hagin d’enviar i rebre constantment, evita el coll d’ampolla i disminueix les col·lisions, augmentant el rendiment.

21. Mosix - Característiques • Però tot no és perfecte. • Tots els nodes han de ser de la mateixa arquitectura • Han de tenir processadors amb jocs d’instruccions compatibles • El mateix sabor de Unix • És necessari coprocessador matemàtic. • No existeix Mosix per a Linux Digital i això és un handicap molt fort.

22. Mosix - Programació • Els Mosix es poden programar utilitzant tots els mecanismes tradicionals dels Beowulf encara que això suposa una pèrdua de temps per al programador. • Els Mosix ens dónen tota la seva potència mitjançant el model de programació “ fork and forget” (segons la definició de l’equip del professor Amnon Barak): • Si desitgem utilitzar el paral·lelisme de Mosix amb tota la seva potència, només cal programar fent crides a fork. Ens podem despreocupar completament de la paral·lelització i el repartiment de processadors, perquè l’arquitectura Mosix fa la resta.

23. Beowulf vs Mosix • És millor un Beowulf si: • Disposem ja del codi font de l’aplicació per adaptar el model de paral·lelisme al número de nodes de la xarxa, topologia y tecnologia de la xarxa, etc... • Si no disposem del codi font l’aplicació ha d’estar paral·lelitzada d’una forma que ens permeti l’aprofitament màxim de la xarxa mitjançant fitxers de configuració. • A més, un Beowulf acostuma a donar millor aprofitament del hardware si: • Els diferents processos de l’aplicació tenen un temps d’execució equivalent. L’objectiu és que els nodes no es desaprofitin mai, en cas d’aplicacions concurrents de càrrega fortament asimètrica.

24. Beowulf vs Mosix • En la pràctica el mecanisme de migració de processos de Mosix afegeix una sobrecàrrega al sistema. • Els supercomputadors classe Beowulf també són millors en els cassos en els que no es pugui utilitzar un classe Mosix, com es: • Amb ordinadors 800486 SX i i80386, sense coprocessador. • Amb ordinadors amb arquitectures no i80x86 • La migració entre dues màquines amb arquitectures diferents no es possible i, sense migració, Mosix no té sentit. • Existeixen Kernels no suportats per Mosix.

25. Beowulf vs Mosix • És millor Mosix en cassos de: • Càrrega heterogènia, és a dir, uns nodes molt més carregats que altres. • Variació freqüent de les aplicacions, és a dir, estem canviant l’aplicació que executem en el cluster amb una freüència que no justificaria l’esforç d’adaptar-la en a una arquitectura Beowulf per a obtenir el màxim rendiment. • Varies aplicacions diferents en el mateix cluster. • Varies aplicacions concurrents no paral·lelitzades. Aquest és, sense lloc a dubtes, el punt més fort de Mosix.

26. Beowulf vs Mosix • És a dir, Mosix serà millor quan l’increment de càrrega causat pel mecanisme de migració justifica l’avantatge que dóna no tenir nodes desocupats. • En un cluster dedicat que estigui pensat per calcular poc més d’un procés a la vegada, habitualment controlem més paràmetres com administradors i la major part de les vegades som capaços d’aprofitar millor el sistema i amb més facilitat. Per tant seran preferibles els Beowulf. • Per una altra banda, en clusters no dedicats, o que es vegin subjectes a la incorporació i eliminació de nodes, o en clusters que tinguin que córrer varies aplicacions simultàniament, siguin distribuides o no, acostumen a tenir millor rendiment els classe Mosix.

27. Beowulf vs Mosix • Finalment cal recordar que en aplicacions en les quals: • el temps d’execució depèn fonamentalment de: • de la velocitat d’accés a disc • de la velocitat de xarxa • utilitzen models de memòria compartida • Tenen un rendiment pobre tant en els classe Beowulf com en els classe Mosix (seria més adequada una arquitectura tipus SMP per exemple)

28. Conclusions • Com a conclusions podem veure els avantatges i desavantatges de Mosix i per tant enllaçar-ho amb els seus usos: • Utilitzar un supercomputador classe Mosix pot ser útil per a algunes tasques, però també pot ser un complet error per a d’altres. • Els millors usos d’aquesta arquitectura són: • Aplicacions, previament paral·lelitzades, que fan un ús intensiu de la CPU. Independentment que tinguem el codi font o no. Qualsevol aplicació ja paral·lelitzada serà capaç d’utilitzar un cluster classe Mosix de forma quasi òptima. • Com a subcas de l’anterior. El millor escenari per a Mosix és quan tenim l’aplicació ja paral·lelitzada, però no disposem del seu codi font. En aquest cas, l’arquitectura Mosix és la millor forma de que l’aplicació pugui córrer en un cluster de forma més ràpidament possible.

29. Conclusions • Moltes aplicacions que, sense tenir relació entre sí, haurien de córrer concurrentment en el cluster. El mecanisme d’equilibrat de la càrrega de Mosix ens permet que, independentment de que la major part dels requeriments de treball es fagin a un node o a pocs nodes del cluster, la càrrega entre els nodes s’equilibrarà. • Com a subcas de l’anterior. El millor escenari per a Mosix és quan tenim requeriments de treballs que la seva càrrega computacional no està repartida uniformement entre els nodes, o amb processos repartits uniformement pels nodes amb requeriments de memòria heterogenis. • Exemple: En el cas dels laboratoris que es fan simulacions (ex. Spice) aquest fenòmen pot ser més destacat, perquè un mateix usuari pot executar més d’una simulació concurrentment per a verificar diferents cassos i els processos, de forma transparent, migraran a on tinguin menys càrrega.

30. Conclusions • Per una altra banda Mosix presenta alguns inconvenients que el fan poc útil per a determinades tasques, entre elles: • Compartides amb els Beowulf: • Encara que planificat per a versions futures de Mosix, encara no existeix un suport a sockets portable. Això significa que les aplicacions que fagin un ús intensiu de la xarxa no obtinguin cap benefici per l’ús d’un classe Mosix. Si l’aplicació ja està paral·lelitzada utilitzant un model de memòria distribuida, Mosix només empitjorarà les coses. La migració de processos no produirà més que sobrecàrrega en la xarxa, sense cap benefici pràctic. • Les aplicacions lentes per realitzar un ús intensiu de les lectures i escriptures de disc tampoc obtenen cap millora per utilitzar Mosix. Existeix un sistema de fitxers de Mosix, però està en fase beta i tampoc guanya res.

31. Conclusions • Desavantatges no compartides amb Beowulf: • La xarxa té que ser homogènia. Si tenim una xarxa amb diferent arquitectures, Mosix no funcionarà. Són problemes en els que un dels fluxes o dels processos de la nostra aplicació ha d’estar lligat a determinat node. Si no podem realitzar migracions entre nodes, Mosix no té cap avantatge respecte als Beowulf i és sensiblement més lent. • L’elecció d’una màquina més potent, un Beowulf o un Mosix, dependrà bàsicament del nostre problema. • Hem vist com aconseguir que Linux ens doni el millor rendiment possible sense gastar més de l’imprescindible en hardware.

32. Bibliografia • Apunts de CASO en format transparència • William Stalling. “Organización y arquitectura de Computadores” Ed. Prentice Hall, 4a Edició • Diversos articles de la revista “Linux Actual”. Ed. Prensa Técnica • Varis articles sobre Beowulf (en alguns FTP’s) • Ex: “ How to build a Beowulf ” (objectius, configuració, administració, ...) • Articles sobre Mosix (a la web del projecte) • FAQ’s de Beowulf i Mosix • Alguns HOWTO’s sobre Beowulf (webs de Beowulf)

33. URL’s relacionades • http://www.beowulf.org • http://www.extremelinux.org • http://www.redhat.com/extreme • http://www.beowulf-underground.org/ • http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html • http://www.uk.linux.org/SMP/title.html • http://www.epm.orml.gov/pvm/pvm_home.html • http://www.mcs.anl.gov:80/mpi/ • http://www.mosix.org • http://www.mosix.cs.huji.ac.il/ • http://agamenon.uniandes.edu.co/~c21437/ma-bedoy/