ver

1. El manual para el
clustering con openMosix
por Miquel Catal´n i Co¨
a ıt ≡ miKeL a.k.a.mc2
inspirado en el HOWTO de Kris Buytaert

2. Este manual est´ dedicado a todos aquellos
a
que han hecho, hacen y har´n que haya algo que
a
documentar. A todos los desarrolladores del proyecto
openMosix, muchas gracias.
Menciones especiales para:
Moshe Bar principal desarrollador, autor del MFS y DFSA
Louis Zechtzer
Martin Høy
Brian Pontz
Bruce Knox
Matthew Brichacek
Matthias Rechenburg
Maurizio Davini
Michael Farnbach
Mark Veltzer
Muli Ben Yehuda (a.k.a. mulix)
David Santo Orcero
openMosix -because they said it couldn’t be done
openMosix, porque dijeron que no pod´ hacerse
ıa

3. Este COMO ha estado posible gracias a las colaboraciones de:
Ana P´rez Arteaga correcciones ortogr´ficas y l´xico-sem´nticas
e a e a
C. W. Strommer traducci´n de las PMF (preguntas m´s frecuentes)
o a
Jaime Perea cap´
ıtulo sobre PCMCIA (openMosix para ordenadores port´tiles)
a
Marcelo Stutz cap´
ıtulo sobre el acceso a openMosixView con ssh
y David Santo Orcero aportaciones desde su inmenso archivo personal
Todos nosotros nos hemos esforzado y lo haremos para que a usuarios como t´ les sea
u
util esta gu´ por ello te animamos a hacernos llegar cualquier ambiguedad, error o consejo
´ ıa,
para poder mejorarla.
Tambi´n a t´ que has sabido ver el poder de la comunidad libre y vas a convertir tus PCs en
e ı
un super-computador, gracias.

4. ´
Indice de figuras
1. openMosixview: Aplicaci´n principal . . . . . . . . . . . . . . . . . . . . . .
o 29
2. openMosixview: Propiedades de los nodos . . . . . . . . . . . . . . . . . . . 30
3. openMosixview: Ejecuci´n avanzada . . . . . . . . . . . . . . . . . . . . . . .
o 31
4. openMosixprocs: Administraci´n de procesos . . . . . . . . . . . . . . . . . .
o 33
5. openMosixprocs: La ventana de migrado de un proceso(1) . . . . . . . . . . . 34
6. openMosixprocs: La ventana de migrado de un proceso(2) . . . . . . . . . . . 35
7. openMosixanalyzer. Historial de actividad de procesamiento del cluster . . . 37
8. openMosixanalyzer. Estad´
ısticas de los nodos . . . . . . . . . . . . . . . . . . 37
9. openMosixanalyzer. Historial de actividad de memoria de nuestro cluster . . 38
10. openMosixhistory. Un historial de los procesos ejecutados . . . . . . . . . . . 39

5. ´
Indice de cuadros
1. Cambiando los parmetros en /proc/hpc . . . . . . . . . . . . . . . . . . . . . 19
2. Binarios en /proc/hpc/admin . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3. Escribiendo un 1 en /proc/hpc/decay . . . . . . . . . . . . . . . . . . . . . . 20
4. Informaci´n adicional sobre los procesos locales . . . . . . . . . . . . . . . .
o 20
5. Informaci´n de los otros nodos . . . . . . . . . . . . . . . . . . . . . . . . . .
o 20
6. Par´metros de mosctl con m´s detalle . . . . . . . . . . . . . . . . . . . . .
a a 21
7. Par´metros adicionales para mosrun . . . . . . . . . . . . . . . . . . . . . . .
a 21
8. Condiciones de inicio avanzadas para procesos . . . . . . . . . . . . . . . . . 32

6. openMosix y el mundo de la programaci´n libre avanzan a pasos agigantados. Es un
o
mundo donde el sol nunca se pone y donde nadie entiende de fronteras, razas ni religiones.
Lo que cuenta es el c´digo. Y llega en gran cantidad, y de gran calidad.
o
Moshe Bar
Puedes encontrar este manual y sus futuras revisiones en internet en la direcci´n http://w3.akamc2.net
o

7. ´
Indice
1. Introducci´n
o 1
1.1. Sobre este documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Limitaci´n de responsabilidad . . . . . . . . . . . . . . . . . . . . . . . . . .
o 2
1.3. Pol´
ıtica de distribuci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 3
1.4. Nuevas versiones de este documento . . . . . . . . . . . . . . . . . . . . . . . 3
1.5. Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ¿Qu´ es realmente openMosix?
e 4
2.1. Una muy breve introducci´n al clustering . . . . . . . . . . . . . . . . . . . .
o 5
2.1.1. HPC, Fail-over y Load-balancing . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Mainframes y supercomputadoras vs. clusters . . . . . . . . . . . . . 5
2.1.3. Modelos de clusters NUMA, PVM y MPI . . . . . . . . . . . . . . . . 6
2.2. Una aproximaci´n hist´rica . . . . . . . . . . . . . . . . . . . . . . . . . . .
o o 6
2.2.1. Desarrollo hist´rico . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 6
2.2.2. openMosix != MOSIX . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. openMosix en acci´n: un ejemplo . . . . . . . . . . . . . . . . . . . . . . . .
o 8
3. Caracter´
ısticas de openMosix 9
3.1. Pros de openMosix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Contras de openMosix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Subsistemas de openMosix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. Mosix File System (MFS) . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2. Migraci´n de procesos . . . . . . . . . . . . . . . . . . . . . . . . . .
o 10
3.3.3. Direct File System Access (DFSA) . . . . . . . . . . . . . . . . . . . 10
3.3.4. Memory ushering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. El algoritmo de migraci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 11
3.4.1. El nodo ra´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ız 11

8. 3.4.2. El mecanismo de migrado . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3. ¿ Cu´ndo podr´ migrar un proceso? . . . . . . . . . . . . . . . . . .
a a 12
3.4.4. La comunicaci´n entre las dos ´reas . . . . . . . . . . . . . . . . . . .
o a 12
4. Requerimientos y planteamientos 14
4.1. Requerimientos hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Lineas b´sicas en la configuraci´n del hardware . . . . . . . . . . . . . . . .
a o 15
4.3. Requerimientos software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Planteamientos de tu cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Instalaci´n de un cluster openMosix
o 16
5.1. Obteniendo fuentes y paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Parcheando el kernel de linux . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Opciones en el nuevo kernel parcheado . . . . . . . . . . . . . . . . . 17
5.1.3. Las herramientas de usuario . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.4. Paquetes RPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.5. Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.6. Fuentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Compilaciones necesarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. Compilaci´n del nuevo kernel . . . . . . . . . . . . . . . . . . . . . .
o 17
5.2.2. Configurando las herramientas de usuario . . . . . . . . . . . . . . . . 17
5.3. Instalaciones del programario . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Administraci´n del cluster
o 18
6.1. Administraci´n b´sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o a 19
6.2. Configuraci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 19
6.3. Las herramientas de ´rea de usuario . . . . . . . . . . . . . . . . . . . . . . .
a 20
6.4. Detecci´n autom´tica de nodos . . . . . . . . . . . . . . . . . . . . . . . . .
o a 22
6.4.1. Compilaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

9. 6.4.2. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Ajustes en el cluster 25
8. openMosixview 26
8.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 27
8.2. Instalaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 27
8.2.1. Instalaci´n de los paquetes RPM . . . . . . . . . . . . . . . . . . . .
o 27
8.2.2. Instalaci´n de las fuentes . . . . . . . . . . . . . . . . . . . . . . . . .
o 28
8.2.3. Script de configuraci´n autom´tico . . . . . . . . . . . . . . . . . . .
o a 28
8.2.4. Compilaci´n manual . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 28
8.3. Utilizando openMosixview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.3.1. Aplicaci´n principal . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 29
8.3.2. La ventana de configuraci´n . . . . . . . . . . . . . . . . . . . . . . .
o 30
8.3.3. Ejecuci´n avanzada . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 31
8.3.4. La l´
ınea de comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.3.5. El host-chooser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.3.6. El host-chooser paralelo . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.4. openMosixprocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.4.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 33
8.4.2. La ventana de migraci´n . . . . . . . . . . . . . . . . . . . . . . . . .
o 34
8.4.3. Administrando procesos remotamente . . . . . . . . . . . . . . . . . . 35
8.5. openMosixcollector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.6. openMosixanalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.6.1. Una visi´n general de la carga del sistema . . . . . . . . . . . . . . .
o 36
8.6.2. Estad´
ısticas sobre los nodos del cluster . . . . . . . . . . . . . . . . . 38
8.6.3. Monitoraje de la memoria . . . . . . . . . . . . . . . . . . . . . . . . 38
8.7. openMosixhistory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.8. openMosixview + SSH2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

10. 8.9. FAQ de openMosixview -preguntas m´s frecuentes . . . . . . . . . . . . . . .
a 41
9. Casos especiales 44
9.1. Laptops y targetas PCMCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.2. Nodos sin disco duro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.Problemas m´s comunes
a 51
10.1. No veo todos los nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.2. FAQ de openMosix -preguntas m´s frecuentes . . . . . . . . . . . . . . . . .
a 52
10.2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.2.2. Obteniendo, compilando, instalando y funcionando con openMosix . . 53
10.2.3. Preguntas del kernel (n´cleo) . . . . . . . . . . . . . . . . . . . . . .
u 54
10.2.4. Sistema de ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.2.5. Programando openMosix . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.2.6. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.2.7. Miscel´nea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
a 56
11.Precauciones 58
11.1. Procesos bloqueados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11.2. Escogiendo tus procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11.3. Java y openMosix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
12.Para m´s informaci´n
a o 60
´
13.APENDICE A: Aplicaciones funcionando 62
13.1. Programas que funcionan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.2. Programas que NO funcionan . . . . . . . . . . . . . . . . . . . . . . . . . . 63
´
14.APENDICE B: Acr´nimos
o 64

11. 1. Introducci´n
o

12. ´
1 INTRODUCCION 2
Primero fue MOSIX, ahora es openMosix, un proyecto mucho m´s interesante no s´lo
a o
desde un punto de vista t´cnico sino porque se han mejorado los t´rminos de la licencia que
e e
manten´ a Mosix bajo c´digo propietario.
ıa o
Este COMO (o manual) est´ dirigido a conocer el proyecto openMosix y no el MOSIX por
a
la simple raz´n que el primero tiene un sector de usuarios mucho m´s amplio y con may-
o a
ores garant´ de crecer en los pr´ximos tiempos (Moshe Bar, el principal desarrollador del
ıas o
proyecto openMosix, estima que el 97 % de los usuarios de la antigua comunidad Mosix ya
han migrado a openMosix). La redacci´n de los principales cap´
o ıtulos es la traducci´n del
o
HOWTO escrito por Kris Buytaert para usuarios de Mosix y openMosix. Esta dualidad
tem´tica aportaba confusi´n y obsoletismo as´ que creo haber mejorado y actualizado bas-
a o ı
tante cap´
ıtulos como el de la Instalaci´n, donde he profundizado para permitir que cualquier
o
usuario novel de Linux pueda arregl´rselas con openMosix. En ´sta, mi propuesta en castel-
a e
lano del HOWTO oficial, dejar´ de lado Mosix por considerarlo una tecnolog´ obsoleta y
e ıa
a´n m´s cuando ya lleva, a d´ de hoy, cerca de un a˜o sin ser actualizada. Nada une ya a
u a ıa n
Mosix y openMosix, e intentar buscarles parecidos resultar´, como los grandes avances en el
a
proyecto demuestran, cada vez ms dif´ ıcil.
Para m´s informaci´n sobre el HOWTO original de Kris Buytaert puedes dirigirte a su sitio
a o
web (referenciado m´s adelante).
a
1.1. Sobre este documento
Este documento te dar´ una breve descripci´n de openMosix, un paquete soft-
a o
ware que posibilita que una red de computadoras basadas en GNU/Linux fun-
cionen como un cluster (adem´s ser´ SSI, S ingle System Image, como se ver´).
a a a
A lo largo de este camino que empezaremos juntos se introducir´n conceptos como la com-
a
putaci´n paralela, super-computaci´n, breves tutoriales para programas que tengan utili-
o o
dades especiales para las posibilidades que openMosix pueda ofrecerte, e incluso un repaso
hist´rico sobre los inicios del clustering como alternativa para la super-computaci´n (ver
o o
Ap´ndice B).
e
Asimismo este manual ampl´ su contenido proporcionando documentaci´n para las distintas
ıa o
distribuciones, b´sicamente considerando las que se basan en Debian (y sus paquetes .deb)
a
y las basadas en los paquetes de RedHat (.rpm). Obviamente la compilaci´n de los fuentes
o
ser´ una alternativa constante durante todo el proceso.
a
Kris Buytaert escribi´ el HOWTO original en febrero de 2002, cuando Scot Stevenson busca-
o
ba a alguien para llevar a cabo este trabajo de documentaci´n. En aquella versi´n original se
o o
hac´ muchas veces a referencia Mosix cuando deb´ leerse openMosix, as´ que me tomar´ la
ıa ıa ı e
libertad de focalizarlo todo hacia el segundo, en pro de una mejor inteligibilidad para el
lector y por las causas anteriormente citadas.

13. ´
1 INTRODUCCION 3
1.2. Limitaci´n de responsabilidad
o
Utilice la informaci´n contenida en este documento siendo responsable del riesgo
o
que puedan correr sus equipos. Yo mismo y el equipo de colaboradores repudiamos cualquier
responsabilidad sobre las consecuencias que el seguimiento de estos contenidos puedan provo-
car.
El uso de los ejemplos y conceptos expuestos corren a cargo del lector.
Es recomendable hacer copias de seguridad (backups) de su sistema antes de iniciar cualquier
instalaci´n, ya que el trabajo desde root (administrador de su equipo linux) puede provocar
o
p´rdidas y/o modificaciones irreversibles de su informaci´n.
e o
Asimismo, para su mayor comodidad en caso de dar un mal paso, es recomendable hacer
backups regularmente.
1.3. Pol´
ıtica de distribuci´n
o
Copyright c 2002 by Kris Buytaert and Scot W.Stevenson, para el documento original.
Para el presente manual no existe licencia alguna, aunque agradecemos de antemano (el
equipo de colaboradores y yo mismo) la notificaci´n de cualquier uso que pueda darsele.
o
1.4. Nuevas versiones de este documento
Las versiones oficiales (tanto las originales en ingl´s como sus diversas traducciones)
e
de este documento ser´n hospedadas en The Linux Documentation Project1 .
a
Los borradores del documento original se encontrar´n en la web de Kris Buytaert2 en el
a
sub-directorio apropiado. Los cambios en este documento normalmente ser´n anunciados en
a
las listas de distribuci´n de openMosix.
o
Los posibles cambios en ´sta, la versi´n en castellano, ser´n igualmente anunciados en la
e o a
citada lista y podr´s obtenerla en mi sitio web3 .
a
1.5. Mantenimiento
Actualmente este manual est´ mantenido por miKeL a.k.a.mc2 (Miquel Catal´n i
a a
Co¨ por favor manda tus dudas o preguntas a la direcci´n de correo electr´nico que en-
ıt), o o
contrar´s en su sitio web.
a
Env´ tambi´n tus comentarios, preguntas, errores que puedas encontrar y por supuesto
ıa e
todos los elogios que creas oportunos, al autor.
1
http://www.tldp.org
2
http://howto.ipng.be/Mosix-HOWTO/index.html
3
http://w3.akamc2.net

14. ´
1 INTRODUCCION 4
Para dudas concretas sobre la tecnolog´ openMosix, por favor dir´
ıa ıgete a las listas de correo
del proyecto (ver cap´
ıtulo Para m´s informaci´n).
a o

15. 2. ¿Qu´ es realmente openMosix?
e

16. 2 ´
¿QUE ES REALMENTE OPENMOSIX? 6
2.1. Una muy breve introducci´n al clustering
o
La mayor parte del tiempo tu computadora permanece ociosa. Si lanzas un programa
de monitorizaci´n del sistema como xload o top, ver´s probablemente que la lectura de la
o a
carga de tu procesador permanece generalmente por debajo del 10 %.
Si tienes al alcance varias computadoras los resultados ser´n los mismos ya que no podr´s
a a
interactuar con m´s de una de ellas al mismo tiempo. Desafortunadamente cuando real-
a
mente necesites potencia computacional (como por ejemplo para comprimir un fichero Ogg
Vorbis, o para una gran compilaci´n) no podr´s disponer de la potencia conjunta que te
o a
proporcionar´ todas ellas como un todo.
ıan
La idea que se esconde en el trasfondo del clustering es precisamente poder contar con todos
los recursos que puedan brindarte el conjunto de computadoras de que puedas disponer para
poder aprovechar aquellos que permanecen sin usar, basicamente en otras computadoras.
La unidad b´sica de un cluster es una computadora simple, tambi´n denominada nodo. Los
a e
clusters pueden crecer en tama˜o (o mejor dicho, pueden escalar) a˜adiendo m´s m´quinas.
n n a a
Un cluster como un todo puede ser m´s potente que la m´s veloz de las m´quinas con las
a a a
que cuenta, factor que estar´ ligado irremediablemente a la velocidad de conexi´n con la que
a o
hemos construido las comunicaciones entre nodos.
Adem´s, el sistema operativo del cluster puede hacer un mejor uso del hardware disponible
a
en respuesta al cambio de condiciones. Esto produce un reto a un cluster heterog´neo (com-
e
puesto por m´quinas de diferente arquitectura) tal como iremos viendo paso a paso.
a
2.1.1. HPC, Fail-over y Load-balancing
B´sicamente existen tres tipos de clusters: Fail-over, Load-balancing y HIGH Perfor-
a
mance Computing.
Los clusters Fail-over consisten en dos o m´s computadoras conectadas en red con una
a
conexi´n heartbeat separada entre ellas. La conexi´n heartbeat entre las computadoras es
o o
usualmente utilizada para monitorear cu´l de todos los servicios est´ en uso, as´ como la
a a ı
sustituci´n de una m´quina por otra cuando uno de sus servicios haya ca´
o a ıdo.
El concepto en los Load-balancing se basa en que cuando haya una petici´n entrante al
o
servidor web, el cluster verifica cu´l de las m´quinas disponibles posee mayores recursos
a a
libres, para luego asignarle el trabajo pertinente.
Actualmente un cluster load-balancing es tambi´n fail-over con el extra del balanceo de la
e
carga y a menudo con mayor n´mero de nodos.
u
La ultima variaci´n en el clustering son los High Performance Computing.
´ o
Estas m´quinas han estado configuradas especialmente para centros de datos que requieren
a
una potencia de computaci´n extrema.
o

17. 2 ´
¿QUE ES REALMENTE OPENMOSIX? 7
Los clusters Beowulf han sido dise˜ados espec´
n ıficamente para estas tareas de tipo masivo,
teniendo en contrapartida otras limitaciones que no lo hacen tan accesible para el usuario
como un openMosix.
2.1.2. Mainframes y supercomputadoras vs. clusters
Tradicionalmente los mainframes y las supercomputadoras han estado construidas
solamente por unos fabricantes muy concretos y para un colectivo elitista que necesitaba
gran potencia de c´lculo, como pueden ser empresas o universidades.
a
Pero muchos colectivos no pueden afrontar el costo econ´mico que supone adquirir una
o
m´quina de estas caracter´
a ısticas, y aqu´ es donde toma la m´xima importancia la idea de
ı a
poder disponer de esa potencia de c´lculo, pero a un precio muy inferior.
a
El concepto de cluster naci´ cuando los pioneros de la supercomputaci´n intentaban difundir
o o
diferentes procesos entre varias computadoras, para luego poder recoger los resultados que
dichos procesos deb´ producir. Con un hardware m´s barato y f´cil de conseguir se pu-
ıan a a
do perfilar que podr´ conseguirse resultados muy parecidos a los obtenidos con aquellas
ıan
m´quinas mucho m´s costosas, como se ha venido probando desde entonces.
a a
2.1.3. Modelos de clusters NUMA, PVM y MPI
Hay diferentes formas de hacer procesamiento paralelo, entre las m´s conocidas y
a
usadas podemos destacar NUMA, PVM y MPI.
Las m´quinas de tipo NUMA (Non-Uniform Memory Access) tienen acceso compartido a
a
la memoria donde pueden ejecutar su c´digo de programa. En el kernel de Linux hay ya
o
implementado NUMA, que hace variar el n´mero de accesos a las diferentes regiones de
u
memoria.
PVM / MPI son herramientas que han estado ampliamente utilizadas y son muy conocidas
por la gente que entiende de supercomputaci´n basada en GNU/Linux.
o
MPI es el est´ndar abierto de bibliotecas de paso de mensajes. MPICH es una de las imple-
a
mentaciones m´s usadas de MPI, tras MPICH se puede encontrar LAM, otra implementaci´n
a o
basada en MPI tambi´n con bibliotecas de c´digo abierto.
e o
PVM (Parallel Virtual Machine) es un primo de MPI que tambi´n es ampliamente usado
e
para funcionar en entornos Beowulf.
PVM habita en el espacio de usuario y tiene la ventaja que no hacen falta modificaciones en
el kernel de Linux, basicamente cada usuario con derechos suficientes puede ejecutar PVM.

18. 2 ´
¿QUE ES REALMENTE OPENMOSIX? 8
2.2. Una aproximaci´n hist´rica
o o
2.2.1. Desarrollo hist´rico
o
Algunos rumores hablaban que MOSIX ven´ de Moshe Unix. Inicialmente Mosix
ıa
empez´ siendo una aplicaci´n para BSD/OS 3.0, como podemos leer en este email:
o o
Announcing MO6 for BSD/OS 3.0
Oren Laadan (orenl@cs.huji.ac.il)
Tue, 9 Sep 1997 19:50:12 +0300 (IDT)
Hi:
We are pleased to announce the availability of MO6 Version 3.0
Release 1.04 (beta-4) - compatible with BSD/OS 3.0, patch level
K300-001 through M300-029.
MO6 is a 6 processor version of the MOSIX multicomputer enhancements
of BSD/OS for a PC Cluster. If you have 2 to 6 PC’s connected by a
LAN, you can experience truly multi-computing environment by using
the MO6 enhancements.
The MO6 Distribution
--------------------
MO6 is available either in "source" or "binary" distribution. It is
installed as a patch to BSD/OS, using an interactive installation
script.
MO6 is available at http://www.cnds.jhu.edu/mirrors/mosix/
or at our site: http://www.cs.huji.ac.il/mosix/
Main highlights of the current release:
--------------------------------------
- Memory ushering (depletion prevention) by process migration.
- Improved installation procedure.
- Enhanced migration control.
- Improved administration tools.
- More user utilities.
- More documentation and new man pages.
- Dynamic configurations.
Please send feedback and comments to mosix@cs.huji.ac.il.
-------------------
La plataforma GNU/Linux para el desarrollo de posteriores versiones fue elegida en la s´pti-
e
ma reencarnaci´n, en 1999.
o

19. 2 ´
¿QUE ES REALMENTE OPENMOSIX? 9
A principios de 1999 Mosix M06 fue lanzado para el kernel de Linux 2.2.1.
Entre finales de 2001 e inicios de 2002 nac´ openMosix, la versi´n de c´digo abierto, de
ıa o o
forma separada.
2.2.2. openMosix != MOSIX
openMosix en principio ten´ que ser una ampliaci´n a lo que a˜os atr´s ya se pod´
ıa o n a ıa
encontrar en www.mosix.org, respetando todo el trabajo llevado a cabo por el Prof. Barak
y su equipo.
Moshe Bar estuvo ligado al proyecto Mosix, en la Universidad Hebrea de Jerusalem, durante
bastantes a˜os. Era el co-administrador del proyecto y el principal administrador de los
n
asuntos comerciales de Mosix company.
Tras algunas diferencias de opini´n sobre el futuro comercial de Mosix, Moshe Bar empez´ un
o o
nuevo proyecto de clustering alzando la empresa Qlusters, Inc. en la que el profesor A. Barak4
decidi´ no participar ya que no quer´ poner Mosix bajo licencia GPL.
o ıa
Como hab´ una significativa base de usuarios clientes de la tecnologia Mosix (unas 1000
ıa
instalaciones a lo ancho del planeta) Moshe Bar decidi´ continuar el desarrollo de Mosix
o
pero bajo otro nombre, openMosix, totalmente bajo licencia GPL2.
openMosix es un parche (patch) para el kernel de linux que proporciona compatibilidad
completa con el estardard de Linux para plataformas IA32. Actualmente se est´ trabajando
a
para portarlo a IA64.
El algoritmo interno de balanceo de carga migra, transparentemente para el usuario, los
procesos entre los nodos del cluster. La principal ventaja es una mejor compartici´n de
o
recursos entre nodos, as´ como un mejor aprovechamiento de los mismos.
ı
El cluster escoge por s´ mismo la utilizaci´n ´ptima de los recursos que son necesarios en
ı o o
cada momento, y de forma autom´tica.
a
Esta caracter´
ıstica de migraci´n transparente hace que el cluster funcione a todos los efectos
o
como un gran sistema SMP (Symmetric Multi Processing) con varios procesadores disponibles.
Su estabilidad ha sido ampliamente probada aunque todav´ se est´ trabajando en diversas
ıa a
l´
ıneas para aumentar su eficiencia.
openMosix est´ respaldado y siendo desarrollado por personas muy competentes y respetadas
a
en el mundo del open source, trabajando juntas en todo el mundo.
El punto fuerte de este proyecto es que intenta crear un est´ndar en el entorno del clustering
a
para todo tipo de aplicaciones HPC.
openMosix tiene una p´gina web5 con un ´rbol CVS6 y un par de listas de correo para los
a a
4
http://www.cs.huji.ac.il/ amnon/
5
http://www.openmosix.org
6
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/openmosix/

20. 2 ´
¿QUE ES REALMENTE OPENMOSIX? 10
desarrolladores y para los usuarios.
2.3. openMosix en acci´n: un ejemplo
o
Los clusters openMosix pueden adoptar varias formas. Para demostrarlo intentad
imaginar que compartes el piso de estudiante con un chico adinerado que estudia ciencias
de la computaci´n. Imaginad tambi´n que ten´is las computadoras conectadas en red para
o e e
formar un cluster openMosix.
Asume tambi´n que te encuentras convirtiendo ficheros de m´sica desde tus CDs de audio a
e u
Ogg Vorbis para tu uso privado, cosa que resulta ser legal en tu pa´
ıs.
Tu compa˜ero de habitaci´n se encuentra trabajando en un proyecto de C++ que seg´n dice
n o u
podr´ traer la paz mundial, pero en este justo momento est´ en el servicio cantando cosas
a a
ininteligibles, y evidentemente su computadora est´ a la espera de ser intervenida de nuevo.
a
Resulta que cuando inicias un programa de compresi´n, como puede ser bladeenc para
o
convertir un preludio de Bach desde el fichero .wav al .ogg, las rutinas de openMosix en tu
m´quina comparan la carga de procesos en tu m´quina y en la de tu compa˜ero y deciden
a a n
que es mejor migrar las tareas de compresi´n ya que el otro nodo es m´s potente debido
o a
a que el chico dispon´ de m´s medios econ´micos para poderse permitir una computadora
ıa a o
m´s potente, a la vez que en ese momento permanece ociosa ya que no se encuentra frente
a
a ella.
As´ pues lo que normalemte en tu pentium233 tardar´ varios minutos te das cuenta que ha
ı ıa
terminado en pocos segundos.
Lo que ha ocurrido es que gran parte de la tarea ha sido ejecutada en el AMD
AthlonXP de tu compa˜ero, de forma transparente a ti.
n
Minutos despu´s te encuentras escribiendo y tu compa˜ero de habitaci´n vuelve del servicio.
e n o
´
Este reanuda sus pruebas de compilaci´n utilizando pmake, una versi´n del make optimizada
o o
para arquitecturas paralelas. Te das cuenta que openMosix est´ migrando hacia tu m´quina
a a
algunos subprocesos con el fin de equilibrar la carga.
Esta configuraci´n se llama single-pool: todas las computadoras est´n dispuestas como un
o a
unico cluster. La ventaja o desventaja de esta disposici´n es que tu computadora es parte
´ o
del pool: tus procesos ser´n ejecutados, al menos en parte, en otras computadoras, pudiendo
a
atentar contra tu privacidad de datos. Evidentemente las tareas de los dem´s tambi´n podr´n
a e a
ser ejecutadas en la tuya.

21. 3. Caracter´
ısticas de openMosix

22. 3 CARACTER´
ISTICAS DE OPENMOSIX 12
3.1. Pros de openMosix
No se requieren paquetes extra
No son necesarias modificaciones en el c´digo
o
3.2. Contras de openMosix
Es dependiente del kernel
No migra todos los procesos siempre, tiene limitaciones de funcionamiento
Problemas con memoria compartida
Adem´s los procesos con m´ltiples threads no ganan demasiada eficiencia
a u
Tampoco se obtendr´ mucha mejora cuando se ejecute un solo proceso, como por ejemplo el
a
navegador.
3.3. Subsistemas de openMosix
Actualmente podemos dividir los parches de openMosix dentro del kernel en cuatro
grandes subsistemas, ve´moslos.
a
3.3.1. Mosix File System (MFS)
El primer y mayor subsistema (en cuanto a l´ ıneas de c´digo) es MFS que te permite
o
un acceso a sistemas de ficheros (FS) remotos (i.e. de cualquier otro nodo) si est´ localmente
a
montado.
El sistema de ficheros de tu nodo y de los dem´s podr´n ser montados en el directorio /mfs
a a
y de esta forma se podr´, por ejemplo, acceder al directorio /home del nodo 3 dentro del
a
directorio /mfs/3/home desde cualquier nodo del cluster.
3.3.2. Migraci´n de procesos
o
Con openMosix se puede lanzar un proceso en una computadora y ver si se ejecuta
en otra, en el seno del cluster.
Cada proceso tiene su unico nodo ra´ (UHN, unique home node) que se corresponde con el
´ ız
que lo ha generado.
El concepto de migraci´n significa que un proceso se divide en dos partes: la parte del usuario
o
y la del sistema.

23. 3 CARACTER´
ISTICAS DE OPENMOSIX 13
La parte, o ´rea, de usuario ser´ movida al nodo remoto mientras el ´rea de sistema espera
a a a
en el ra´
ız.
openMosix se encargar´ de establecer la comunicaci´n entre estos 2 procesos.
a o
3.3.3. Direct File System Access (DFSA)
openMosix proporciona MFS con la opci´n DFSA que permite acceso a todos los
o
sistemas de ficheros, tanto locales como remotos. Para m´s informaci´n dir´
a o ıgase a la secci´n
o
de Sistema de ficheros de las FAQs (preguntas m´s frecuentes) del presente documento.
a
3.3.4. Memory ushering
Este subsistema se encarga de migrar las tareas que superan la memoria disponible en
el nodo en el que se ejecutan. Las tareas que superan dicho l´
ımite se migran forzosamente a un
nodo destino de entre los nodos del cluster que tengan suficiente memoria como para ejecutar
el proceso sin necesidad de hacer swap a disco, ahorrando as´ la gran p´rdida de rendimiento
ı e
que esto supone. El subsistema de memory ushering es un subsistema independiente del
subsistema de equilibrado de carga, y por ello se le considera por separado.
3.4. El algoritmo de migraci´n
o
De entre las propiedades compartidas entre Mosix y openMosix podemos destacar
el mecanismo de migraci´n, en el que puede migrar-se cualquiera proceso a cualquier nodo
o
del cluster de forma completamente transparente al proceso migrado. La migraci´n tambi´n
o e
puede ser autom´tica: el algoritmo que lo implementa tiene una complejidad computacional
a
del orden de O(n), siendo n el n´mero de nodos del cluster.
u
Para implementarlo openMosix utiliza el modelo fork-and-forget7 , desarrollado en un prin-
cipio dentro de Mosix para m´quinas PDP11/45 empleadas en las fuerzas a´reas norteam-
a e
ericanas. La idea de este modelo es que la distribuci´n de tareas en el cluster la determina
o
openMosix de forma din´mica, conforme se van creando tareas. Cuando un nodo est´ de-
a a
masiado cargado, y las tareas que se est´n ejecutando puedan migrar a cualquier otro nodo
a
del cluster. As´ desde que se ejecuta una tarea hasta que ´sta muere, podr´ migrar de un
ı e a
nodo a otro, sin que el proceso sufra mayores cambios.
Podr´
ıamos pensar que el comportamiento de un clsuter openMosix es como una m´quina
a
NUMA, aunque estos clusters son mucho m´s baratos.
a
7
hace fererencia a que el sistema cuando reconoce un subproceso se encarga de ejecutarlo en otro nodo,
en paralelo, sin ningun efecto ni notificaci´n al propietario del mismo
o

24. 3 CARACTER´
ISTICAS DE OPENMOSIX 14
3.4.1. El nodo ra´
ız
Cada proceso ejecutado en el cluster tiene un unico nodo ra´ como se ha visto. El
´ ız,
nodo ra´ es el nodo en el cual se lanza originalmente el proceso y donde ´ste empieza a
ız e
ejecutarse.
Desde el punto de vista del espacio de procesos de las m´quinas del cluster, cada proceso
a
(con su correspondiente PID) parece ejecutarse en su nodo ra´ El nodo de ejecuci´n puede
ız. o
ser el nodo ra´ u otro diferente, hecho que da lugar a que el proceso no use un PID del nodo
ız
de ejecuci´n, sino que el proceso migrado se ejecutar´ en ´ste como una hebra del kernel.
o a e
La interacci´n con un proceso, por ejemplo enviarle se˜ales desde cualquier otro proceso
o n
migrado, se puede realizar exclusivamente desde el nodo ra´ ız.
El usuario que ejecuta un proceso en el cluster ha accedido al cluster desde el nodo ra´ del
ız
proceso (puesto que ha logado en ´l). El propietario del proceso en cuesti´n tendr´ control
e o a
en todo momento del mismo como si se ejecutara localmente.
Por otra parte la migraci´n y el retorno al nodo ra´ de un proceso se puede realizar tanto
o ız
desde el nodo ra´ como desde el nodo d´nde se ejecuta el proceso. Esta tarea la puede llevar
ız o
a t´rmino el administrador de cualquiera de los dos sistemas.
e
3.4.2. El mecanismo de migrado
La migraci´n de procesos en openMosix es completamente transparente.
o
Esto significa que al proceso migrado no se le avisa de que ya no se ejecuta en su nodo
de origen. Es m´s, este proceso migrado seguir´ ejecut´ndose como si siguiera en el nodo
a a a
origen: si escribiera o leyera al disco, lo har´ en el nodo origen, hecho que supone leer o
ıa
grabar remotamente en este nodo.
3.4.3. ¿ Cu´ndo podr´ migrar un proceso?
a a
Desgraciadamente, no todos los procesos pueden migrar en cualquiera circunstancia.
El mecanismo de migraci´n de procesos puede operar sobre cualquier tarea de un nodo sobre
o
´
el que se cumplen algunas condiciones predeterminadas. Estas son:
el proceso no puede ejecutarse en modo de emulaci´n VM86
o
el proceso no puede ejecutar instrucciones en ensamblador propias de la m´quina donde
a
se lanza y que no tiene la m´quina destino (en un cluster heterog´neo)
a e
el proceso no puede mapear memoria de un dispositivo a la RAM, ni acceder directa-
mente a los registros de un dispositivo
el proceso no puede usar segmentos de memoria compartida

25. 3 CARACTER´
ISTICAS DE OPENMOSIX 15
Cumpliendo todas estas condiciones el proceso puede migrar y ejecutarse migrado. No ob-
stante, como podemos sospechar, openMosix no adivina nada. openMosix no sabe a priori
si alguno de los procesos que pueden migrar tendr´n algunos de estos problemas.
a
Por esto en un principio openMosix migra todos los procesos que puedan hacerlo si por el
momento cumplen todas las condiciones, y en caso de que alg´n proceso deje de cumplirlas,
u
lo devuelve de nuevo a su nodo ra´ para que se ejecute en ´l mientras no pueda migrar de
ız e
nuevo.
Todo esto significa que mientras el proceso est´ en modo de emulaci´n VM86, mapee memoria
e o
de un dispositivo RAM, acceda a un registro o tenga reservado/bloqueado un puntero a un
segmento de memoria compartida, el proceso se ejecutar´ en el nodo ra´ y cuando acabe la
a ız,
condici´n que lo bloquea volver´ a migrar.
o a
Con el uso de instrucciones asociadas a procesadores no compatibles entre ellos, openMosix
tiene un comportamiento diferente: solo permitir´ migrar a los procesadores que tengan la
a
misma arquitectura.
3.4.4. La comunicaci´n entre las dos ´reas
o a
Un aspecto importante en el que podemos tener inter´s es en c´mo se realiza la
e o
comunicaci´n entre el ´rea de usuario y el ´rea de kernel.
o a a
En alg´n momento, el proceso migrado puede necesitar hacer alguna llamada al sistema.
u
Esta llamada se captura y se eval´a
u
si puede ser ejecutada al nodo al que la tarea ha migrado, o
si necesita ser lanzada en el nodo ra´ del proceso migrado
ız
Si la llamada puede ser lanzada al nodo d´nde la tarea migrada se ejecuta, los accesos al
o
kernel se hacen de forma local, es decir, que se atiende en el nodo d´nde la tarea se ejecuta
o
sin ninguna carga adicional a la red.
Por desgracia, las llamadas m´s comunes son las que se han de ejecutar forzosamente al
a
nodo ra´ puesto que hablan con el hardware. Es el caso, por ejemplo, de una lectura o una
ız,
escritura a disco. En este caso el subsistema de openMosix del nodo d´nde se ejecuta la tarea
o
contacta con el subsistema de openMosix del nodo ra´ Para enviarle la petici´n, as´ como
ız. o ı
todos los par´metros y los datos del nodo ra´ que necesitar´ procesar.
a ız a
El nodo ra´ procesar´ la llamada y enviar´ de vuelta al nodo d´nde se est´ ejecutando
ız a a o a
realmente el proceso migrado:
el valor del ´xito/fracaso de la llamada
e
aquello que necesite saber para actualizar sus segmentos de datos, de pila y de heap
el estado en el que estar´ si se estuviera ejecutando el proceso al nodo ra´
ıa ız

26. 3 CARACTER´
ISTICAS DE OPENMOSIX 16
Esta comunicaci´n tambi´n puede ser generada por el nodo ra´ Es el caso, por ejemplo, del
o e ız.
env´ de una se˜al. El subsistema de openMosix del nodo ra´ contacta con el subsistema
ıo n ız
de openMosix del nodo d´nde el proceso migrado se ejecuta, y el avisa que ha ocurrido un
o
evento as´
ıncono. El subsistema de openMosix del nodo d´nde el proceso migrado se ejecuta
o
parar´ el proceso migrado y el nodo ra´ podr´ empezar a atender el c´digo del ´rea del
a ız a o a
kernel que corresponder´ a la seal as´
ıa ıncrona.
Finalmente, una vez realizada toda el operativa necesaria de la ´rea del kernel, el
a
subsistema de openMosix del nodo ra´ del proceso env´ al nodo donde est´ ejecut´ndose
ız ıa a a
realmente el proceso migrado el aviso detallado de la llamada, y todo aquello que el proceso
necesita saber (anteriormente enumerado) cuando recibi´ la se˜al, y el proceso migrado
o n
finalmente recuperar´ el control.
a
Por todo esto el proceso migrado es como s´ estuviera al nodo ra´ y hubiera recibido la
ı ız
se˜al de ´ste. Tenemos un escenario muy simple donde el proceso se suspende esperando un
n e
recurso. Recordemos que la suspensi´n esperando un recurso se produce unicamente en ´rea
o ´ a
de kernel. Cuando se pide una p´gina de disco o se espera un paquete de red se resuelto
a
como en el primero caso comentado, es decir, como un llamada al kernel.
Este mecanismo de comunicaci´n entre ´reas es el que nos asegura que
o a
la migraci´n sea completamente transparente tanto para el proceso que migra como
o
para los procesos que cohabiten con el nodo ra´
ız
que el proceso no necesite ser reescrito para poder migrar, ni sea necesario conocer la
topologia del cluster para escribir una aplicaci´n paralela
o
No obstante, en el caso de llamadas al kernel que tengan que ser enviadas forzosamente al
nodo ra´ tendremos una sobrecarga adicional a la red debida a la transmisi´n constante de
ız, o
las llamadas al kernel y la recepci´n de sus valores de vuelta.
o
Destacamos especialmente esta sobrecarga en el acceso a sockets y el acceso a disco duro,
que son las dos operaciones m´s importantes que se habr´n de ejecutar en el nodo ra´ y
a a ız
suponen una sobrecarga al proceso de comunicaci´n entre la ´rea de usuario migrada y la
o a
a
´rea de kernel del proceso migrado.

27. 4. Requerimientos y planteamientos

28. 4 REQUERIMIENTOS Y PLANTEAMIENTOS 18
4.1. Requerimientos hardware
Para la instalaci´n b´sica de un cluster necesitaremos al menos dos computadoras
o a
conectadas en red. Podremos conectarlas mediante un cable cruzado entre las respectivas
tarjetas de red, con un hub o con un switch.
Evidentemente cuanto m´s r´pida sea la conexi´n entre m´quinas, m´s eficaz ser´ nuestro
a a o a a a
sistema global.
Actualmente Fast Ethernet es un est´ndar, permitiendo m´ltiples puertos en una m´quina.
a u a
Gigabit Ethernet es m´s cara y no es recomendable probar con ella sin antes haberse asegu-
a
rado un correcto funcionamiento con Fast Ethernet y comprobar que realmente se necesita
este extra en la velocidad de transferencia de datos entre nodos.
Siempre podremos hacer funcionar varias tarjetas Fast en cada nodo para asignarles luego
la misma direcci´n (IP) y de esta forma poder obtener m´ltiples en la velocidad.
o u
4.2. Lineas b´sicas en la configuraci´n del hardware
a o
Para poder configurar un gran cluster (refiri´ndose al n´mero de nodos) tendremos
e u
que pensar en ciertos aspectos, como por ejemplo d´nde situar las m´quinas, ya que tenerlas
o a
en medio de una oficina puede resultar inc´modo en muchos aspectos. La mejor opci´n ser´
o o ıa
“raquearlas”.
El acondicionamiento de la sala donde deba situarse el cluster tambi´n es importante para
e
evitar sobrecalentamientos y dem´s incomodidades a la hora de trabajar con ´l.
a e
Si el n´mero de computadoras que van a disponerse para el cluster no justifica estas in-
u
versiones, aseg´rate de poder tener siempre un f´cil acceso a los nodos, siempre podemos
u a
encontrarnos con el problema de tener que cambiar un ventilador o un disco averiado.
4.3. Requerimientos software
El sistema planteado requiere un sistema b´sico Linux instalado. Podemos elegir
a
cualquier distribuci´n del mercado que encontremos atractiva, este aspecto no es importante.
o
Lo que s´ es importante es usar almenos la versi´n 2.4 del kernel y que tus tarjetas de red
ı o
est´n bien configuradas.
e
4.4. Planteamientos de tu cluster
Para configurar tu cluster openMosix en un pool de nodos, o conjunto de estaciones
de trabajo, tendremos diferentes opciones, cada una con sus ventajas e inconvenientes.
En una single-pool todos los servidores y estaciones de trabajo son utilizadas como un

29. 4 REQUERIMIENTOS Y PLANTEAMIENTOS 19
cluster unico: cada m´quina forma parte del cluster y puede migrar procesos hacia cada uno
´ a
de los otros nodos existentes.
Esta configuraci´n hace que tu propia m´quina forme parte del pool.
o a
En un entorno llamado server-pool los servidores son parte del cluster mientras que las
estaciones de trabajo no lo son. Si quisi´ramos ejecutar aplicaciones en el cluster necesitare-
e
mos entrar en ´l de forma espec´
e ıfica. De este modo las estaciones de trabajo permanecer´n a
libres de procesos remotos que les pudieran llegar.
Existe una tercera alternativa llamada adaptive-pool, donde los servidores son compartidos
mientras que las estaciones de trabajo podr´n entrar y salir del cluster. Podemos imaginar
a
que las estaciones deban ser usadas durante un cierto intervalo de tiempo diario, y que fuera
de este horario puedan ser aprovechadas para las tareas del cluster.

30. 5. Instalaci´n de un cluster openMosix
o

31. ´
5 INSTALACION DE UN CLUSTER OPENMOSIX 21
5.1. Obteniendo fuentes y paquetes
5.1.1. Parcheando el kernel de linux
5.1.2. Opciones en el nuevo kernel parcheado
5.1.3. Las herramientas de usuario
5.1.4. Paquetes RPM
5.1.5. Debian
5.1.6. Fuentes
5.2. Compilaciones necesarias
5.2.1. Compilaci´n del nuevo kernel
o
5.2.2. Configurando las herramientas de usuario
5.3. Instalaciones del programario

32. 6. Administraci´n del cluster
o

33. ´
6 ADMINISTRACION DEL CLUSTER 23
El mantenimiento de un sistema resulta incluso m´s delicado y costoso (en tiempo)
a
que su correcta instalaci´n. En este cap´
o ıtulo se tomar´ contacto con todas las herramientas
a
con las que cuenta openMosix para poder gestionar tu sistema.
La recomendaci´n que lanzamos desde este manual es que pruebes con ellas para conocer
o
exactamente la respuesta de tu cluster, ya que m´s tarde puede facilitarte la detecci´n de
a o
errores o configuraciones poco adecuadas.
6.1. Administraci´n b´sica
o a
openMosix proporciona como principal ventaja la migraci´n de procesos hacia apli-
o
caciones HPC. El adminsitrador puede configurar el cluster utilizando las herramientas de
´rea de usuario de openMosix (openMosix-user-space-tools8 ) o editando la interf´
a ıcie que
encontraremos en /proc/hpc y que ser´ descrita con m´s detalle seguidamente.
a a
6.2. Configuraci´n
o
Los valores en los ficheros del directorio /proc/hpc/admin presentan la configuraci´n actu-
o
al del cluster. El administrador del mismo puede configurar estos valores para cambiar la
configuraci´n en tiempo de ejecuci´n, tal como se muestra en las tablas.
o o
8
http://www.orcero.org/openmosix

34. ´
6 ADMINISTRACION DEL CLUSTER 24
echo 1 > /proc/hpc/admin/block bloquea la llegada de procesos remotos
echo 1 > /proc/hpc/admin/bring lleva todos los procesos a su nodo ra´
ız
Cuadro 1: Cambiando los parmetros en /proc/hpc
config el fichero de configuraci´n principal (escrito por la utilidad setpe)
o
block permite/proh´ la llegada de procesos remotos
ıbe
bring lleva todos los procesos a su nodo ra´
ız
dfsalinks lista los actuales enlaces DFSA
expel env´ los procesos hu´sped a su nodo ra´
ıa e ız
gateways numero m´ximo de gateways
a
lstay los procesos locales se suspenderan
mospe contiene el ID de nuestro nodo openMosix
nomfs activa/desactiva MFS
overheads para ajustes
quiet detiene la obtenci´n de informaci´n sobre la carga del sistema
o o
decay-interval int´rvalo para recoger informaci´n sobre la carga
e o
slow-decay por defecto 975
fast-decay por defecto 926
speed velocidad relativa a un PIII/1GHz
stay activa/desactiva el proceso de migrado autom´tico
a
Cuadro 2: Binarios en /proc/hpc/admin
Existen utilidades adicionales a la interf´
ıcie de /proc y a las l´
ınias de comandos.
Por ejemplo existen unos parches para ps y para top (llamados mps y mtop) los cuales
muestran adicionalmente el ID de nuestro nodo openMosix en una columna. Esta posibilidad
es interesante para encontrar d´nde ha migrado un cierto proceso.
o
Para clusters peque˜os pueden sernos muy utiles las utilidades de openMosixView, una GUI
n ´
para las tareas de administraci´n m´s comunes y que m´s adelante se detalla en un cap´
o a a ıtulo.
6.4. Detecci´n autom´tica de nodos
o a
El demonio de auto-detecci´n de nodos, omdiscd, proporciona un camino autom´tico
o a
para la configuraci´n de nuestro cluster openMosix. Con ´l podremos eliminar la necesidad
o e
de configuraciones manuales como son la edici´n del fichero /etc/mosix.map .
o
omdiscd genera un env´ de paquetes multicast (a todas las direcciones, en nuestro caso,
ıo
nodos) para notificar a los otros nodos que hemos a˜adido uno nuevo. Esto significa que al
n
a˜adir un nodo s´lo tendremos que iniciar omdiscd en ´l.
n o e
Debemos ocuparnos de algunos requisitos previos como pueden ser una buena configuraci´no
de la red de interconexi´n de los nodos, principalmente para el correcto enrutamiento de
o
paquetes. Sin una ruta por defecto deberemos especificar a omdiscd la interf´ ıcie con la
opci´n -i. De otra forma acabar´ con un error parecido al siguiente:
o a

35. ´
6 ADMINISTRACION DEL CLUSTER 25
clear resetea las estad´
ısticas
cpujob informa a openMosix que el proceso est´ ligado al procesador
a
iojob informa a openMosix que el proceso est´ ligado a la E/S
a
slow informa a openMosix que actualice las estd´
ısticas m´s lentamente
a
fast informa a openMosix que actualice las estd´
ısticas m´s r´pidamente
a a
Cuadro 3: Escribiendo un 1 en /proc/hpc/decay
/proc/[PID]/cantmove raz´n por la cual el proceso ha sido migrado
o
/proc/[PID]/goto a qu´ nodo el proceso podr´ migrar
e a
/proc/[PID]/lock si el proceso se ve bloquead en su nodo ra´
ız
/proc/[PID]/nmigs el numero de veces que el proceso ha migrado
/proc/[PID]/where donde el proceso se encuentra siendo computado actualmente
/proc/[PID]/migrate same as goto remote processes
/proc/hpc/remote/from el nodo ra´ del proceso
ız
/proc/hpc/remote/identity informaci´n adicional del proceso
o
/proc/hpc/remote/statm estad´ ıstica de memoria del proceso
/proc/hpc/remote/stats estad´ ıstica del procesador del proceso
Cuadro 4: Informaci´n adicional sobre los procesos locales
o
/proc/hpc/nodes/[openMosix ID]/CPUs el n´mero de CPUs que posee el nodo
u
/proc/hpc/nodes/[openMosix ID]/load la carga de openMosix en este nodo
/proc/hpc/nodes/[openMosix ID]/mem memoria disponible para openMosix
/proc/hpc/nodes/[openMosix ID]/rmem memoria disponible para Linux
/proc/hpc/nodes/[openMosix ID]/speed velocidad del nodo relativa a un PIII/1GHz
/proc/hpc/nodes/[openMosix ID]/status estado del nodo
/proc/hpc/nodes/[openMosix ID]/tmem memoria disponible
/proc/hpc/nodes/[openMosix ID]/util utilizaci´n del nodo
o
Cuadro 5: Informaci´n de los otros nodos
o
6.3. Las herramientas de ´rea de usuario
a
Estas herramientas permitir´n un f´cil manejo del cluster openMosix. Seguidamente
a a
se enumeran con todos sus par´metros.
a
migrate [PID] [openMosix ID] envia una petici´n de migrado del proceso identificado
o
con el ID, al nodo que indiquemos..
mon es un monitor de los daemons basado en el terminal y da informaci´n relevante sobre el
o
estado actual que puede ser visualizada en diagramas de barras.
mosctl es la principal utilidad para la configuraci´n de openMosix. Su sintaxis es:
o
mosctl [stay|nostay]
[block|noblock]
[quiet|noquiet]
[nomfs|mfs]
[expel|bring]
[gettune|getyard|getdecay]

36. ´
6 ADMINISTRACION DEL CLUSTER 26
mosct whois [openMosix_ID|IP-address|hostname]
mosct [getload|getspeed|status|isup|getmem|getfree|getutil] [openMosix_ID]
mosctl setyard [Processor-Type|openMosix_ID||this]
mosctlsetspeed interger-value
mosctlsetdecay interval [slow fast]
Aug 31 20:41:49 localhost omdiscd[1290]: Unable to determine address of
default interface. This may happen because there is no default route
configured. Without a default route, an interface must be: Network is
unreachable
Aug 31 20:41:49 localhost omdiscd[1290]: Unable to initialize network.
Exiting.
Un ejemplo de buena configuraci´n podr´ ser la siguiente:
o ıa
[root@localhost log]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.0.0.99 0.0.0.0 UG 0 0 0 eth0
La importancia de poder automatizar el reconocimiento de nuevos nodos conectados al sis-
tema ha facilitado que se llegue a la simplicidad con la que contamos actualmente para iniciar
dicha detecci´n, con el comando omdiscd.
o
Ahora echando un vistazo a los logfiles tendr´
ıamos que ver algo parecido a
Sep 2 10:00:49 oscar0 kernel: openMosix configuration changed: This is openMosix
#2780 of 6 configured)
Sep 2 10:00:49 oscar0 kernel: openMosix #2780 is at IP address 192.168.10.220
Sep 2 10:00:49 oscar0 kernel: openMosix #2638 is at IP address 192.168.10.78
Sep 2 10:00:49 oscar0 kernel: openMosix #2646 is at IP address 192.168.10.86
Sep 2 10:00:49 oscar0 kernel: openMosix #2627 is at IP address 192.168.10.67
Sep 2 10:00:49 oscar0 kernel: openMosix #2634 is at IP address 192.168.10.74
Tendremos el cluster listo para ser utilizado.
omdiscd tiene otras opciones entre las que cuentan poder ejecutarse como un demonio
(por defecto) o en background (segundo plano) donde la salida ser´ la pantalla (la salida
a
est´ndar), con el comando omdiscd -n. La interf´
a ıcie, como ya se ha indicado, debe ser
especificada con la opci´n -i.
o
Ahora vamos a ver brevemente la herramienta showmap. Esta utilidad nos mostrar´ el nuevo
a
mapa.

37. ´
6 ADMINISTRACION DEL CLUSTER 27
stay desactiva la migraci´n autom´tica
o a
nostay migraci´n autom´tica (defecto)
o a
lstay local processes should stay
nolstay los procesos locales podran migrar
block bloquea la llegada de otros procesos
noblock permite la llegada de procesos
quiet desactiva la posibildiad de dar informaci´n sobre la carga del nodo
o
noquiet activa la posibildiad de dar informaci´n sobre la carga del nodo
o
nomfs desactiva MFS
mfs activa MFS
expel env´ fuera del nodo los procesos que han llegado previamente
ıa
bring traer´ todos los procesos migrados hacia su nodo ra´
a ız
gettune muestra el par´metro de overhead
a
getyard muestra la utilizaci´n actual de Yardstick
o
getdecay muestra el estado del par´metro decay
a
whois nos muestra el openMosix-ID, la direcci´n IP y los nombres de host del cluster
o
getload muestra la carga (openMosix-)
getspeed muestra la velocidad (openMosix-)
status muestra el estado y la configuraci´n actual
o
isup nos informa de si un nodo est´ funcionando o no (ping openMosix)
a
getmem muestra la memoria l´gica libre
o
getfree muestra la memoria f´ ısica libre
getutil muestra la utilizaci´n del nodo
o
setyard establece un nuevo valor para Yardstick
setspeed establece un nuevo valor para la velocidad (openMosix-)
setdecay establece un nuevo valor para el intervalo del decay
Cuadro 6: Par´metros de mosctl con m´s detalle
a a
Con mosrun ejecutaremos un comando especialemte configurado en un nodo estable-
cido.
Su sintaxis: mosrun [-h|openMosix ID| list of openMosix IDs] command [arguments]
El comando mosrun puede ser ejecutado con diversas opciones. Para evitar complicaciones
innecesarias viene con ciertas pre-configuraciones para ejecutar las tareas con configuraciones
especiales de openMosix.
nomig runs a command which process(es) won’t migrate
runhome ejecuta un comando bloqueado en el nodo ra´ ız
runon ejecutar´ un comando el cu´l ser´ directamente migrado y bloqueado a cierto nodo
a a a
cpujob informa a openMosix que el proceso est´ ligado a la CPU
a
iojob informa a openMosix que el proceso est´ ligado a la E/S
a
nodecay ejecuta un comando e informa al cluster de no refrescar las estadisticas de carga
slowdecay ejecuta un comando con intervalo de decay grande para acumular en las estad´ ısticas
fastdecay ejecuta un comando con intervalo de decay peque˜o para acumular en las estad´
n ısticas
Cuadro 7: Par´metros adicionales para mosrun
a

38. ´
6 ADMINISTRACION DEL CLUSTER 28
setpe es una utilidad de configuraci´n manual del nodo sintaxis:
o
setpe -w -f [hpc_map]
setpe -r [-f [hpc_map]]
setpe -off
-w lee la configuraci´n de openMosix desde un fichero (normalmente /etc/hpc.map).
o
-r escribe la configuraci´n actual de openMosix en un fichero (normalmente /etc/hpc.map).
o
-off desactiva la configuraci´n actual del cluster.
o
tune es una utilidad de calibraci´n y optimizaci´n de openMosix (para m´s informa-
o o a
ci´n recurra a las p´ginas man de tune).
o a
[root@oscar0 root]# showmap
My Node-Id: 0x0adc
Base Node-Id Address Count
------------ ---------------- -----
0x0adc 192.168.10.220 1
0x0a4e 192.168.10.78 1
0x0a56 192.168.10.86 1
0x0a43 192.168.10.67 1
0x0a4a 192.168.10.74 1
Existen otras muchas utilidades que pueden sernos utiles para la detecci´n autom´tica
´ o a
de nodos, como un mecanismo de routing para clusters con m´s de una red de conexi´n.
a o
Toda esta informaci´n es actualizada constantemente y podremos encontrarla en los ficheros
o
README y DESIGN de las herramientas de usuario.
6.4.1. Compilaciones
Si queremos obtener este m´dulo a partir de las fuentes tendremos que hacer una
o
peque˜a modificaci´n en el fichero openmosix.c. Una de las l´
n o ınias, concretamente
#define ALPHA
tendremos que comentarla ya que nosotros estamos trabajando en plataforma x86.
Si quisi´ramos tener un historial m´s detallado podemos editar main.c para escribir
e a
log set debug(DEBUG TRACE ALL); (en la l´
ınia 84 aproximadamente)
ahora podremos ejecutar
make clean
make

39. ´
6 ADMINISTRACION DEL CLUSTER 29
6.4.2. Problemas
Algunas veces la auto-detecci´n no funcionar´ tal como podr´
o a ıamos esperar, per ejem-
plo cuando un nodo deber´ ser detectado y no ve el tr´fico multicast que se lleva a cabo en
ıa a
la red.
Esto ocurre con algunas targetas PCMCIA. Una soluci´n posible ser´ poner la interf´ en
o ıa ıcie
modo prom´scuo, tal como se detalla seguidamente:
ı
Aug 31 20:45:58 localhost kernel: openMosix configuration changed:
This is openMosix #98 (of 1 configured)
Aug 31 20:45:58 localhost kernel: openMosix #98 is at IP address 10.0.0.98
Aug 31 20:45:58 localhost omdiscd[1627]: Notified kernel to activate
openMosix Aug 31 20:45:58 localhost kernel:
Received an unauthorized information request from 10.0.0.99
Algo que podr´
ıamos probar es forzar manualmente nuestro NIC a modo prom´
ıscuo y/o
multicast, as´
ı:
ifconfig ethx promisc
o
ifconfig ethx multicast
Podremos ejecutar igualmente
tcpdump -i eth0 ether multicast
Si se nos muestra simulated es que seguramente hemos olvidado poner el comentario a la
l´
ınia #define ALPHA, ser´
ıa:
Aug 31 22:14:43 inspon omdiscd[1422]: Simulated notification to activate openMosix
[root@inspon root]# showmap
My Node-Id: 0x0063
Base Node-Id Address Count
------------ ---------------- -----
0x0063 10.0.0.99 1
[root@inspon root]# /etc/init.d/openmosix status
OpenMosix is currently disabled
[root@inspon root]#

40. 7. Ajustes en el cluster

41. 8. openMosixview

42. 8 OPENMOSIXVIEW 32
8.1. Introducci´n
o
openMosixview es la siguiente versi´n (y totalmente reescrita) de MosixView.
o
Es una interf´ gr´fica (GUI) libre para la adminstraci´n y mantenimiento de un cluster
ıcie a o
9
openMosix que podemos bajarnos de la web del proyecto .
La suite openMosixview contiene 6 aplicaciones altamente eficaces e utiles tanto para la
´
administraci´n como para el monitoraje de nuestro cluster.
o
openMosixview la principal aplicaci´n de monitoraje y administraci´n
o o
openMosixprocs una aplicaci´n para la administraci´n de procesos
o o
openMosixcollector acumula la informaci´n del cluster proporcionada por los dae-
o
mons
openMosixanalyzer para el an´lisis de la informaci´n colectada por openMosixcol-
a o
lector
openMosixhistory un historial de procesos del cluster
3dmosmon un visor para monitoraje de datos en 3D
Todos los componentes son accesibles desde la ventana de la aplicaci´n principal. Los co-
o
mandos openMosix m´s comunes podr´n ser ejecutados con unos pocos clicks de rat´n.
a a o
Podremos encontrar tambi´n sliders para la asignaci´n de prioridad para cada nodo, con el fin
e o
de simplificar el balanceo de carga (manual o autom´tico). penMosixview ha sido adaptado
a
al openMosix-auto-discovery y puede obtener toda la informaci´n desde /proc-interface.
o
8.2. Instalaci´n
o
Requerimientos:
tener instaladas las librer´ QT >= 2.3.0
ıas
derechos de root!
rlogin y rsh (o ssh) en todos los nodos del cluster y sin constrase˜as
n
las herramientas de usuario de openMosix (mosctl, migrate, runon, iojob, cpujob...)
Los paquetes RPM tienen como directorio de instalaci´n la ruta /usr/local/openMosixview.
o
9
http://www.openMosixview.com

43. 8 OPENMOSIXVIEW 33
8.2.1. Instalaci´n de los paquetes RPM
o
Tendremos que bajarnos la ultima versi´n de los paquetes RPM de openMosixview.
´ o
Luego ejecutaremos el comando (suponiendo la versi´n 1.2)
o
rpm -i openMosixview-1.2.rpm
Esto nos instalar´ los ficheros binarios en el directorio /usr/bin.
a
Para desinstalarlo ejecutaremos
rpm -e openMosixview
8.2.2. Instalaci´n de las fuentes
o
Bajaremos la ultima versi´n de openMosixview y descomprimiremos y desempaque-
´ o
taremos el paquete (suponiendo la versi´n 1.2):
o
gunzip openMosixview-1.2.tar.gz
tar -xvf openMosixview-1.2.tar
8.2.3. Script de configuraci´n autom´tico
o a
S´lo ser´ necesario entrar al directorio openMosixview y ejecutar:
o a
./setup [directorio de instalaci´n qt 2.3.x]
o
8.2.4. Compilaci´n manual
o
Ser´ necesario situar la variable QTDIR hacia el directorio de la distribuci´n QT, por ejem-
a o
plo:
export QTDIR=/usr/lib/qt-2.3.0 (para bash)
o
setenv QTDIR /usr/lib/qt-2.3.0 (para csh)
Tras lo anterior tendr´
ıamos que ejecutar con ´xito la configuraci´n
e o
./configure

44. 8 OPENMOSIXVIEW 34
make
Luego tendremos que hacer lo mismo en los subdirectorios de openMosixcollector, open-
Mosixanalyzer, openMosixhistory and openMosixviewprocs.
Copiaremos todos los binarios a /usr/bin
cp openMosixview/openMosixview /usr/bin
cp openMosixviewproc/openMosixviewprocs/mosixviewprocs /usr/bin
cp openMosixcollector/openMosixcollector/openMosixcollector /usr/bin
cp openMosixanalyzer/openMosixanalyzer/openMosixanalyzer /usr/bin
cp openMosixhistory/openMosixhistory/openMosixhistory /usr/bin
Y el script de iniciaci´n de openMosixcollector en tu directorio de iniciaci´n, por ejemplo:
o o
cp openMosixcollector/openMosixcollector.init /etc/init.d/openMosixcollector
o
cp openMosixcollector/openMosixcollector.init /etc/rc.d/init.d/openMosixcollector
Ahora tendremos que copiar los binarios de openMosixprocs de cada nodo del cluster
al directorio
/usr/bin/openMosixprocs
rcp openMosixprocs/openMosixprocs tu nodo:/usr/bin/openMosixprocs
Y ahora ya podremos ejecutar openMosixview con el comando openMosixview .

45. 8 OPENMOSIXVIEW 35
8.3. Utilizando openMosixview
8.3.1. Aplicaci´n principal
o
La Figura 1 nos muestra la ventana de la aplicaci´n.
o
Figura 1: openMosixview: Aplicaci´n principal
o
openMosixview nos muestra, para cada nodo del cluster (cada fila): una luz, un bot´n,
o
un slider, un n´mero lcd, dos barras de progreso y un par de etiquetas.
u
Las luces de la izquierda nos muestran el ID del nodo y su estado. En color rojo significa
que el nodo no se encuentra operativo, y verde lo contrario.
Si hacemos clic en el bot´n que muestra la direcci´n IP de un nodo habremos invocado al
o o
di´logo de configuraci´n que nos mostrar´ los botones para ejecutar los comandos de mosctl
a o a
m´s comunes (explicados en pr´ximos subcap´
a o ıtulos).
Con los sliders de velocidad podemos establecer la velocidad que considerar´ el cluster para
a
cada nodo. Este par´metro se muestra en el display lcd.
a
Podemos intervenir tambi´n en el balanceo de carga de cada nodo cambiando sus
e
valores. Los procesos en un cluster openMosix migran m´s f´cilmente hacia un nodo cuya
a a
velocidad sea m´s elevada. Recordemos que este concepto de velocidad no tiene que ser el que
a
realmente posea la computadora, es simplemente el par´metro que queremos que openMosix
a
considere para cada m´quina.
a
Las barras de progreso, que conforman el par de columnas en la mitad de la ventana,
dan una idea general de la carga de cada nodo del cluster. La primera se refiere a la carga
del procesador y muestra un porcentaje que ser´ una aproximaci´n del valor escrito por
a o
openMosix en el fichero /proc/hpc/nodes/x/load. La segunda barra nos muestra la memoria
utilizada en cada nodo. El box de la izquierda nos muestra el total de memoria disponible.
Finalmente el box de m´s a la derecha nos muestra el n´mero de procesadores de cada nodo.
a u
En la esquina superior-izquierda podemos ver el box load-balancing efficiency, ´ste es un
e

46. 8 OPENMOSIXVIEW 36
indicador de la eficiencia del algoritmo de balanceo de carga. Un valor pr´ximo al 100 %
o
indica que la carga computacional ha podido dividirse equitativamente entre los nodos.
Podemos utilizar los men´s de collector- y analyzer- para administrar openMosixcol-
u
lector y openMosixanalyzer, respectivamente. Estas dos partes de las aplicaciones open-
Mosixview son muy adecuadas para construir un historial del trabajo hecho y la manera en
como se ha hecho en el cluster.
8.3.2. La ventana de configuraci´n
o
Esta ventana emergente de la Figura 2 aparecer´ si clicamos en el bot´n de la ip de
a o
cualquier nodo.
Figura 2: openMosixview: Propiedades de los nodos
La configuraci´n de openMosix de cada nodo puede ser cambiada f´cilmente. Todos los
o a
comandos podr´n ser ejecutados con rsh o ssh en los nodos remotos (y tambi´n en el nodo
a e
local, evidentemente) como root sin necesidad de contrase˜as.
n
Si tenemos instalado openMosixprocs en los nodos remotos del cluster podremos clicar en
el bot´n remote proc-box para invocar openMosixprocs desdel remoto. Se nos mostrar´ en
o a
pantalla los par´metros [xhost+hostname] y ser´n configurados para apuntar a nuestro nodo
a a
local. Adem´s el cliente es ejecutado en el remoto con rsh o ssh (recordemos que tendr´
a ıamos
que tener copiados los binarios de openmsoxiprocs en el directorio /usr/bin de cada nodo).

47. 8 OPENMOSIXVIEW 37
openMosixprocs nos permitir´ una administraci´n de nuestros programas.
a o
Si hemos entrado a nuestro cluster desde una estaci´n de trabajo remota podremos introducir
o
nuestro nombre de nodo local en la edit-box, debajo de la remote proc-box. Luego openMosix-
procs se nos mostrar´ en nuestra estaci´n de trabajo y no en el nodo del cluster donde hemos
a o
entrado (podemos configurar [xhost+clusternode] en nuestra estaci´n de trabajo). Podemos
o
encontrar un historial en el combo-box as´ como el nombre de nodo que hayamos escrito.
ı
8.3.3. Ejecuci´n avanzada
o
Si queremos iniciar trabajos en nuestro cluster el di´logo de advanced execution
a
mostrado en la Figura 3 podr´ ayudarnos para convertirlo a modo gr´fico.
a a
Figura 3: openMosixview: Ejecuci´n avanzada
o
Elegiremos el programa a iniciar con el bot´n run-prog (en File-Open-Icon) y especificaremos
o
cu´l y donde se encuentra el trabajo que queremos iniciar en este di´logo de ejecuci´n. Hay
a a o
diferentes opciones que se describen en la pr´xima tabla.
o
8.3.4. La l´
ınea de comandos
Podremos especificar los argumentos a los que antes pod´ ıamos acceder gr´ficamente
a
a trav´s de comandos en el lineedit-widget en la parte superior de la ventana, tal como se
e