beowulf vs mosix

CONCEPTES AVANÇATS DE SISTEMES OPERATIUS Departament d’Arquitectura de Computadors

(apunts de l’assignatura en format transparència)

BEOWULF vs MOSIXBEOWULF vs MOSIX

Ivan Rodero

[email protected]

Maig 2001

CONCEPTES AVANÇATS DE SISTEMES OPERATIUS

Departament. d’Arquitectura de Computadors - UPC

2

- ÍNDEX -- ÍNDEX -

Introducció Arquitectures paral·leles

Beowulf PVM i MPI

Mosix Beowulf vs Mosix Conclusions Bibliografia URL’s relacionades



3

Introducció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ó:

MeteorologiaFísica de la matèria condensada (dinàmica molecular,...)Estudis de proteïnesGeneració d’imatges per ordinador de models realísticsEnginyeria, etc...



4

Taxonomia de les arquitectures de computadorsTaxonomia de les arquitectures de computadors

SISDSISD

SIMDSIMD

MIMDMIMD

MemòriaCompartidaMemòria

Compartida

MemòriaDistribuidaMemòria

Distribuida

MMPMMP

ClusterClusterCOWCOW

BeowulfBeowulf



5

Taxonomia de les arquitectures paral·lelesTaxonomia 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·lelesTaxonomia 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 CompartidaMemò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 DistribuidaMemò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

ClustersClusters 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òsitsFacilitat per substituir un ordinador defectuósExisteix força suport software per a la seva programació



10

I Linux ?I Linux ?

Linux és idoni per diferents raons: El seu 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

BeowulfBeowulf

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 ?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 BeowulfSoftware 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 ExtremeLinux 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 MPIPVM 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 MPIPVM 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 MPIPVM 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

MosixMosix

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ístiquesMosix - 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 lliureUtilitzen 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ístiquesMosix - 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ístiquesMosix - 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ó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 MosixBeowulf 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 MosixBeowulf 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


É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


É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


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

ConclusionsConclusions 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

ConclusionsConclusions

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


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


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 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 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/

beowulf vs mosix

Documents

multiple data programa

codi font s verst

aix sanomena descomposici

resoluci dun problema

laplicaci ms informaci

spmd single program

parallel s accelerar