Resolución de problemas complejos en Clusters Linux María

Resolución de problemas complejos en Clusters Linux
María Carolina León Carri1, Luis Alfredo Tognon1
carolina.leon@total.com, luis.tognon@total.com
1
Total Austral S.A. – Moreno 877 Piso 19 (C1091AAQ) Buenos Aires Argentina.
Palabras claves: cluster linux - performance - Eclipse Parallel
Abstract Complex Problems Resolutions on Linux Clusters
High Performance Computing (HPC) clusters were developed for parallel data processing. Nowadays they
are becoming popular in areas of study which need to resolve complex problems. A HPC cluster is a group
of independent computers combined into a unified system through software and networking to provide
greater computational power than a single computer can provide.
The research was made using Schlumberger´s Eclipse Parallel® application implemented for execution on
multiple processors. Two data models were used with different amount of active cells and time intervals and
the application was run with a variable number of processors.
The parallel simulations were executed on machines with the following architectures and operating systems:
Pentium 4 with Windows XP, Sun Blade with Solaris 8, Xeon with Linux Red Hat and AMD Opteron with
Linux Red Hat and Gentoo. The results have shown that the parallel efficiency is proportional to the model
size, the amount of active cells and the kind of fluids involved. The model’s size is limited by the memory
capacity of each node. What is more, the cluster efficiency is related with the communication speed between
processors, the network bandwidth and latency, the processor architecture, the caching mechanics and the
memory access methods.
INTRODUCCIÓN
La necesidad de incrementar las reservas conocidas de hidrocarburos y de optimizar la producción de
petróleo y de gas, entre otras cosas llevó a ampliar el detalle de los modelos geológicos aplicados y de
comportamiento dinámico que los describen. Dicha situación hizo que el tamaño de los modelos, en término
de celdas con datos, creciera mucho y por ello aumentara el tiempo de ejecución y los recursos de hardware
necesarios para ejecutar las aplicaciones dedicadas a resolverlos.
La resolución de estos modelos fue posible por la existencia de los clusters de computadoras de alta
performance (Ridge et al. 1997) que están dedicados al procesamiento de datos en paralelo. Los clusters
adquirieron popularidad en las áreas de estudio que requieren gran capacidad de cálculo para resolver sus
problemas. La ventaja principal de este tipo de computadoras es que están compuestas por un conjunto de
máquinas que interconectadas logran una alta capacidad de procesamiento a menor costo que los
supercomputadores.
Este trabajo tiene como objetivo probar una aplicación utilizada en ingeniería de reservorios Eclipse® en su
versión de Eclipse Parallel® en diversas configuraciones de hardware y sistemas operativos para seleccionar
una configuración accesible en la actualidad.
METODOLOGÍA
Plataformas utilizadas
Para realizar las pruebas de Eclipse® y Eclipse Parallel® se utilizaron máquinas de distinta arquitectura de
hardware y distintos sistemas operativos, ver Fig. 1. Las máquinas SunBlade 2000 e Intel® Pentium 4 poseen
un sólo procesador. La SunBlade 2500 es una máquina SMP (Share Memory Processor) con dos
procesadores. La máquina AMD® Opteron con 4 procesadores (4P) también es SMP con configuración
NUMA (Non Uniform Memory Access). Las Intel® Xeon 1 procesador (1P), Intel® Xeon 2 procesadores (2P)
y AMD® Opteron 2P fueron utilizadas en clusters de alta performance. Los clusters con máquinas Intel®
Xeon poseen 4 nodos cada uno, el cluster AMD® Opteron posee 24 nodos.
Plataforma
SunBlade 2000
SunBlade 2500 Dual
Intel Pentium IV
Xeon (1P)
Xeon Dual
AMD Opteron64 Dual
AMD Opteron64 (4P)
Velocidad del Memoria
Versión de Interconexión
Sistema Operativo
procesador
RAM
Eclipse®
entre procs
1.28 Ghz
4 GB
Solaris 8
2003a_1
1.28 Ghz
8 GB
Solaris 8
2004a_1
2 Ghz
2 GB
Windows 2000
2003a_1
2.8 Ghz
4 GB
Linux RedHat 7.3
2004a
1 Gb Fibra Óptica
2 Ghz
1 GB
Linux RedHat 7.2
2004a
1 Gb Fibra Óptica
1.8 Ghz
2 GB
Linux RedHat AS 3 2004a_1
1 Gb UTP
Coherent Hyper
1.8 Ghz
4 GB
Linux Gentoo
2004a_1
Transport
Fig. 1. Detalle del hardware, sistema operativo y versión de Eclipse® utilizados.
En la Fig. 2 (A) se muestra la arquitectura de los procesadores Intel® Xeon y Xeon Dual (conectando el
segundo CPU por la línea punteada), Intel® Pentium 4 es análoga con un solo procesador, la misma se basa
en la interconexión de los procesadores y la memoria a través del Front Side Bus (FSB). Para acceder a
memoria ambos procesadores deben utilizar el FSB, atravesar el North Bridge del motherboard
encontrándose allí un cuello de botella pues dicho FSB también es utilizado para acceder a los dispositivos
de entrada/salida (E/S) como ser la placa de red.
AMD® Opteron Fig. 2 (B) ha implementado dentro del procesador las funciones necesarias de acceso a
memoria, obteniendo así la posibilidad de acceder a la misma a través de un canal dedicado que utiliza la
tecnología de Hyper Transport (enlace de alta performance, velocidad, ancho de banda y baja latencia
utilizado para conectar punto a punto chips de un sistema) (HyperTransport™ Consortium 2004). Por otra
vía accede a los dispositivos de E/S evitando el cuello de botella en los accesos a memoria. La arquitectura
AMD® Opteron Dual interconecta los procesadores mediante la tecnología Coherent Hyper Transport aún
más veloz que la anterior y propietaria de AMD®. En la Fig. 2 (B) la línea punteada hacia uno de los bancos
de memoria se debe a que no todos los motherboards implementados para AMD® Opteron Dual poseen un
banco de memoria para cada procesador. Dicho caso es el de los nodos del cluster de AMD® Opteron Dual
utilizado, esto degrada un poco la performance total del sistema.
Fig. 2. Arquitectura (A) Intel® Xeon Dual, (B) AMD® Opteron Dual (Brandao 2005).
La Fig. 3 muestra la arquitectura de AMD® Opteron con cuatro procesadores. Los mismos se interconectan
en topología de anillo a través de enlaces Coherent Hyper Transport. Cada procesador posee un banco de
memoria dedicado.
Fig. 3. Arquitectura AMD® Opteron de 4 procesadores (Brandao 2005).
®
Fig. 4. Arquitectura Sun UltraSPARC III (Sun Microsystems 2003).
Finalmente, en la Fig. 4 se muestra la arquitectura de las Sun® UltraSPARC III (Sun Microsystems 2003)
correspondiente a las máquinas SunBlade. Sun Microsystems® optimiza en este modelo el pipeline de
instrucciones, el acceso a memoria y agrega nuevas instrucciones para acelerar tareas específicas de
cómputo. El acceso a memoria se realiza en modo jerárquico de dos niveles que permite incrementar el
ancho de banda en el acceso a los datos en forma más rápida y eficiente.
Se utilizó el sistema de administración de procesos OpenPBS (Veridian Information Solutions 2000) y el
scheduler de procesos MAUI (MAUI 2005) para enviar a ejecutar las corridas de Eclipse Parallel® en
background. Este esquema permite que cada trabajo utilice en forma exclusiva los procesadores que necesita.
OpenPBS registra en sus logs tiempos de CPU, memoria y elapsed utilizado por cada trabajo. Dichos
tiempos coinciden con los que muestra Eclipse Parallel® en sus archivos de salida *.RSM.
Los datos de la simulación se encuentran en un sistema de archivos remoto montado en las máquinas UNIX
a través de NFS y en la máquina Windows a través de CIFS/NTFS.
Descripción de software Eclipse Parallel®
Su implementación en clusters de alta performance ha tenido una rápida evolución, por lo tanto las versiones
fueron cambiando en el transcurso de las pruebas realizadas, las evaluadas fueron: 2003a, 2003a_1, 2004a y
2004a_1. Los cambios realizados entre cada versión con respecto al feature PARALLEL no fueron
significativos, se considera que se pueden comparar los resultados obtenidos con diferentes versiones de
Eclipse® (Schlumberger 2002), aplicación desarrollada por Schlumberger - Geoquest. Eclipse Blackoil® es
un simulador de reservorios de hidrocarburos que permite simular sistemas de 1, 2 y 3 fases y tres
dimensiones, con opciones de gas condensado. Las opciones para 2 fases (oil/water, oil/gas, gas/water) se
resuelven como sistemas de dos componentes, optimizando tiempos de ejecución y requerimientos de
almacenamiento de datos. Además del gas disuelto en el petróleo (variación del punto de burbuja, o de la
relación gas-petróleo con la profundidad) Eclipse Blackoil® puede ser utilizado para modelar el petróleo
vaporizado en el gas (variación del punto de rocío, o de la relación petróleo-gas con la profundidad)
Está programado en Fortran 77 y puede ser ejecutado en computadoras con ANSI standard Fortran 77 con
suficiente cantidad de memoria.
La versión paralela, está basada en una arquitectura de memoria distribuida implementada con las funciones
de pasaje de mensajes MPI - Message Passing Interface (MPI Consortium 1998) que permite la simulación
de un conjunto de datos distribuidos entre múltiples procesadores, con memoria compartida o distribuida y
esto permite resolver simulaciones de mayor tamaño en menor tiempo.
Eclipse® está optimizado para obtener la solución en corto plazo dimensionando el método de resolución
lineal, usando el popular enfoque del método de residuo mínimo generalizado GMRES (Erhel 1995). Pero
teniendo en cuenta que los resultados obtenidos con distinta cantidad de procesadores se ven limitados
debido a que la resolución lineal es menos eficiente a medida que se aumenta el número de procesadores.
Eclipse Parallel® (Schlumberger 2002) divide el modelo a simular en varios dominios (con aproximadamente
la misma cantidad de celdas activas por partición) según la cantidad de procesadores disponibles y cada
dominio es simulado en un procesador utilizando pasaje de mensajes para resolver el modelo. En el caso de
Blackoil (ECLIPSE 100) se particiona el modelo en la dirección X o Y dependiendo de cual es la dirección
de resolución fundamental.
Algunos puntos a tener en cuenta, por que afectan los tiempos de computación son los Local Grid
Refinements (LGR) que pueden ser tratados como dominios separados y procesados en cada procesador,
siendo esta opción eficiente si hay un gran número de LGRs en el modelo, otra alternativa es que los LGRs
se dividan en sub dominios y que los mismos sean distribuidos entre un número de procesadores, pero esta
opción es más costosa computacionalmente. También hay que tener en cuenta el modelo de pozo, ya que se
puede producir un cuello de botella, si tiene muchas conexiones entre dominios que exigen comunicaciones
extras para asegurar la consistencia.
Este software es apropiado para obtener mejores tiempos de ejecución en modelos con millones de celdas,
trabajando con una representación geológica mas realista, logrando en menos tiempo calibrar el modelo
durante el proceso de “history matching” y en definitiva una simulación mas detallada del reservorio.
Definición de Speed-up
El tamaño del problema está directamente relacionado con la cantidad de procesadores óptimo a utilizar. La
medida ideal para definir la performance de un problema es el speed-up definido por:
S=
Ts
Ts
+C
N
donde, C = L +
M
BW
S: speed-up; Ts: Tiempo ejecución serial; N: número de nodos; C: tiempo de comunicación; L: latencia; M:
tamaño de los datos a transmitir y BW: bandwidth (ancho de banda del enlace entre los nodos).
El valor de speed-up es entre 1 y N, es óptimo cuando tiende a ser igual a la cantidad de procesadores en que
se paralelizó el problema. Esto ocurrirá cuando el tiempo de comunicación C es muy pequeño. El tiempo de
comunicación depende de la latencia de la red (tiempo de respuesta, depende de las características físicas del
medio de transmisión) y del tamaño de los datos del problema en función del ancho de banda de la red (en
nuestro caso 1 Gbps). Cuanto mayor sea la cantidad de datos a transmitir mayor será el tiempo de
comunicación.
Configuración del data set utilizado:
ƒ Selección de división de dominios automática, que reparte la misma cantidad de celdas activas por
procesador.
ƒ La posibilidad del usuario de optimizar la división de dominios definiendo en el data set los keywords
SOLVDIRS (permite cambiar la dirección de resolución de XY o YX) y DOMAINS (permite asignar
diferentes tamaños de dominios a cada procesador). Por ejemplo:
SOLVDIRS
YX /
En el caso de una simulación con 4 procesadores se podrían definir los tamaños de datos para cada
procesador en 5, 5, 5 y 9 para el último:
DOMAINS
5559/
ƒ El keyword PARALLEL que define la cantidad de procesadores a utilizarse aplica en ambas situaciones.
PARALLEL
NP /
donde NP es número de procesadores.
ƒ Para obtener el tiempo de CPU y elapsed (tiempo total de ejecución CPU + operaciones de sistema como
ser pasaje de mensajes, acceso a datos, interrupciones del sistema operativo) en el archivo de salida
*.RSM, se deben agregar en la sección SUMMARY, los keywords: TCPU y ELAPSED.
Optimización del entorno paralelo
Existen un conjunto de variables que se deben optimizar para obtener mayor performance en el tiempo total
de resolución de una simulación paralela. Las mismas abarcan distintos aspectos del sistema desde
parámetros que definen el tamaño de paquetes de las bibliotecas MPI hasta parámetros de NFS y TCP/IP.
MPI posee un conjunto de variables de entorno que permiten optimizar las funciones de pasaje de mensajes,
por ejemplo se puede definir el tamaño de buffer del socket establecido entre cada par de nodos al momento
de intercambiar datos, esta variable es P4_SOCKBUFSIZE por default es de tamaño 128 KB, al utilizar
enlaces de Gigabit Ethernet se recomienda aumentar el tamaño a 256 KB.
Por otro lado, no es trivial alcanzar el ancho de banda que ofrece Gigabit Ethernet a nivel de sistema
operativo. Para esto Linux posee un conjunto de variables de configuración de los sockets de TCP/IP que
permiten agrandar el tamaño de ventanas de congestión. Se deben definir los valores deseados dentro del
archivo /etc/sysctl.conf. Las variables son:
• net.core.rmem_default
• net.core.rmem_max
• net.core.wmem_default
• net.core.wmem_max
• net.ipv4.tcp_wmem
• net.ipv4.tcp_rmem
• net.ipv4.tcp_mem
Finalmente, si los datos se encuentran en un servidor remoto y los mismos se acceden mediante NFS es
importante realizar el tunning de dicho protocolo. Para NFS sobre Gigabit Ethernet se recomienda agrandar
el tamaño de los bloques de lectura y escritura a 8 KB, además se logra mayor performance configurando el
protocolo en forma asincrónica.
Modelos de simulación
Se evaluaron dos modelos de datos, con distinta cantidad de celdas e intervalos de tiempo de simulación, ver
Fig. 5, se ejecutó Eclipse Parallel® variando la cantidad de procesadores en los que se dividía el problema.
Las características particulares que tienen los modelos y que influyen en el tiempo de ejecución son la
cantidad de celdas activas, el período de tiempo que se quiere simular y los fluidos entre otros.
Modelo
Cantidad de Celdas
A
Amill
Amill
131859
2.302.118
2.302.118
Cantidad de
Intervalo de tiempo
Celdas Activas
58374
Inicio: 31/12/1965
550.617
Fin: 01/05/2003
513.877
Fluidos
Oil-Water-Gas
Fig. 5. Descripción de los modelos utilizados.
Se intentó ejecutar el modelo de datos Amill en todas las plataformas pero Windows 2000 no pudo brindar al
proceso la cantidad de memoria necesaria. A pesar de que la máquina tenía 2Gb de memoria, sólo le dio a
Eclipse® un máximo de 1,328 Gb. Para poder ejecutarlo se disminuyó la cantidad de celdas activas
eliminando un grupo de celdas que no afectaban a la simulación quedando finalmente 513.877 celdas activas.
DESARROLLO Y RESULTADOS
Se realizaron pruebas con los modelos de simulación presentados con Eclipse® y Eclipse Parallel® en las
distintas plataformas disponibles.
En la Fig. 6 se muestran los resultados de la ejecución del modelo A con Eclipse® serial, se puede observar
que la simulación en la SunBlade 2500 fue mejor que en SunBlade 2000 las versiones de Eclipse Parallel®
utilizadas fueron 2004a_1 y 2003a_1 respectivamente. Hay dos factores que pueden influir en este resultado,
el primero es que la SunBlade 2500 posee dos procesadores por lo tanto se pueden “paralelizar” las tareas de
usuario y sistema, un procesador realiza los cálculos matemáticos de la simulación y el otro las tareas de
sistema mejorando así el tiempo de procesamiento extra al uso de CPU del usuario (ELAPSED-CPU). El
segundo es que al utilizar distintas versiones de Eclipse Parallel® Schlumberger pudo haber mejorado los
flags de compilación obteniendo así un código optimizado.
12000
Elapsed (segundos)
10000
8000
6000
4000
2000
0
Pentium4
Xeon 1P
Xeon 2P
Opteron 2P
Elapsed-TCPU
SunBlade2000 SunBlade2500
1068,43
16,88
682,61
11,62
9,91
30,20
Opteron 4P
2,19
TCPU
9238,41
6718,80
5222,02
5936,07
5157,84
3582,80
4206,01
Fig. 6. Simulación del modelo A con Eclipse® Serial.
Los procesadores Pentium 4 y Xeon 1P fueron más eficientes que la SunBlade 2000 y la SunBlade 2500. Los
AMD® Opteron Dual fueron aun más eficiente que el Xeon Dual, pero aquí debemos tener en cuenta que
Opteron es un procesador con arquitectura de 64 bits lo que lo hace más eficiente en accesos a memoria. La
menor performance de Opteron 4P con respecto al Opteron Dual se debe a que los equipos tenían distintos
sistemas operativos instalados.
6500
Xeon 1P
Xeon 2P
Xeon 2P
Opteron Dual
6000
5500
Elapsed (segundos)
5000
Opteron Dual
Opteron 4P
4500
4000
3500
3000
2500
2000
1500
1000
500
0
1
2
4
8
Cantidad de Procesadores
Fig. 7. Simulación del modelo A con Eclipse Parallel®.
Las líneas punteadas corresponden a pruebas utilizando dos procesadores por máquina.
De las pruebas paralelas realizadas con el modelo A se obtuvieron los resultados de la Fig. 7. donde se
muestra el tiempo de ejecución en función de la cantidad de procesadores utilizados.
El mejor resultado se obtuvo con el cluster AMD® Opteron Dual utilizando sólo un procesador por máquina.
El caso llamativo es el de Xeon Dual utilizando dos procesadores por nodo, en la ejecución paralela es buen
resultado pues prácticamente se resuelve el problema en la mitad del tiempo que el serial, pero luego cuando
se aumenta el número de procesadores a 4, el tiempo total aumenta considerablemente. Esto puede deberse a
la arquitectura interna de los nodos, ver Fig. 2 (A), el FSB se debe utilizar para los accesos a memoria y para
el intercambio de mensajes entre los nodos vecinos como así también para el acceso a los datos desde el
servidor de NFS hallándose en el FSB un cuello de botella afectando a la resolución total del problema.
La ejecución de Xeon Dual con 8 procesadores (dos procesadores por máquina) es mejor que la anterior y
esto se debe a que en este caso al repartir el dominio de datos en 8 procesadores, se reparten menor cantidad
de datos por nodo, requiriendo menor uso de memoria y disminuyendo la cantidad de mensajes a procesar
entre cada par de procesadores ya sean internos a un nodo o entre dos nodos.
También en el cluster de 24 Opteron Duales, la opción de dos procesadores por nodo resultó poco eficiente,
debido a que la arquitectura del motherboard no brinda la posibilidad de asignar un banco de memoria por
procesador y a configurar la opción NUMA del kernel.
La máquina Opteron 4P obtuvo buena performance al utilizar dos procesadores internos, fue aún más veloz
que su caso serial y mucho más al utilizar los 4 procesadores. Aquí se observan los beneficios de tener los
bancos de memoria dedicados para cada procesador.
1500000
1400000
1300000
ELAPSED (segundos)
1200000
1100000
1000000
900000
800000
700000
600000
500000
400000
300000
200000
100000
0
ELAPSED-TCPU
TCPU
1
1
4
4
8
SunBlade2000
Pentium 4
Xeon 2P
Opteron 4P
39411.99
12455.40
53935.10
35459.20
Opteron 2P
51033.70
1355221.40
675337.40
259767.60
201710.50
106722.80
Fig. 8. Simulación del modelo Amill en las distintas plataformas con distinta cantidad de procesadores.
Las simulaciones del modelo Amill se grafican en la Fig. 8, en tiempo en segundos en función de la
plataforma utilizada y la cantidad de procesadores. Se realizaron ejecuciones seriales para SunBlade 2000 y
Pentium 4. Se ejecutó el modelo utilizando cuatro procesadores para Xeon Dual (utilizando un procesador
por nodo) y para Opteron 4P. Finalmente se simuló el modelo con ocho procesadores en el cluster Opteron
Dual de 24 nodos (utilizando un procesador por máquina). La ejecución en la SunBlade 2000 duró 16 días,
luego en Pentium 4 se obtuvo una mejora del 50% finalizando la simulación en 8 días. El cluster de
procesadores Xeon Dual resolvió el problema en 3,6 días. La máquina Opteron 4P mostró una buena
performance con 2,7 días y finalmente utilizando ocho procesadores se alcanzó el resultado en 1,8 días. Este
último caso, no mantiene la relación de mejora de tiempo con respecto a los casos anteriores, esto se debe a
que en computación paralela no se gana performance simplemente por aumentar el número de procesadores.
En la Fig. 9 se muestran el speed-up para Xeon 2P, Opteron 4P y Opteron 2P en ejecuciones paralelas de 4, 4
y 8 procesadores. En los dos primeros casos se alcanzó un speed-up de aproximadamente 3, esto es un valor
aceptable, aún se mantiene una buena relación entre el tiempo de transmisión de los datos y el tiempo de
cálculo en cada uno de los procesadores. Sin embargo, para el caso de Opteron 2P con 8 procesadores el
speed-up dio 4.36 esto quiere decir que se está invirtiendo más tiempo en funciones de comunicación entre
los procesadores que en poder de cálculo de cada uno de ellos. Para que se justifique simular el modelo en 8
procesadores, este debería ser mas grande en términos de celdas activas.
Xeon 2P
Opteron 4P
Opteron 2P
Speed-up
3.06
3.20
4.36
TS
699255.71
569417.61
488880.24
N
4
4
8
C
53935.10
35459.20
51033.70
Fig. 9. Speed-up de la ejecución de Eclipse Parallel®.
Uso de recursos
Se realizó un análisis del uso de recursos de la aplicación Eclipse Parallel® durante la ejecución del modelo
A en el cluster de Xeon duales. Se evaluó el uso de CPU, memoria y red en uno de los nodos participantes de
la simulación del modelo, utilizando cuatro procesadores distribuidos para un caso en cuatro máquinas y para
otro en dos. El perfil de ejecución del resto de las máquinas es similar.
En la Fig. 10 se muestra el porcentaje de uso de CPU en función del tiempo de simulación. El máximo
porcentaje de uso es 200% esto se debe a que se representa en el mismo gráfico la suma del porcentaje de
uso de los dos procesadores. La Fig. 10 (a) muestra que durante la ejecución en cuatro máquinas con cuatro
procesadores (4M4P) los procesos de usuario utilizan aproximadamente un 80% de CPU mientras que el uso
de procesos del sistema (interrupciones del sistema operativo, accesos a memoria, pasaje de mensajes entre
otras) alcanza un máximo de un 4%. El sistema dispone de un procesador exclusivo para la simulación y otro
para las tareas del sistema operativo.
En el caso dos máquinas con cuatro procesadores (2M4P) el uso de CPU de usuario es de 180%. Observar
que el porcentaje de CPU dedicado a operaciones del sistema operativo se mantiene en el transcurso de toda
la simulación en un 5%. En este caso los procesadores deben llevar a cabo tareas de usuario y sistema al
mismo tiempo.
En la Fig. 11 se grafica el uso de memoria en Gigabytes (GB) en función del tiempo de simulación. En el
caso 4M4P el máximo uso de memoria es de 0.1 GB mientras que al utilizar 2M4P se nota un incremento en
el uso de memoria de un 80% (0.18 GB). En este caso la memoria es utilizada por dos procesos involucrados
en la simulación. La cantidad de memoria utilizada se relaciona directamente con el tamaño del modelo
simulado y con la cantidad de procesadores utilizados.
(a)
(b)
Fig. 10. Uso de recurso de CPU de uno de los nodos participantes de la simulación del modelo A
en el cluster de Xeon 2P. (a) Ejecución en 4 máquinas 4 procesadores.
(b) Ejecución en 2 máquinas 4 procesadores.
(a)
(b)
Fig. 11. Uso de recurso de MEMORIA de uno de los nodos participantes de la simulación del modelo A en el
cluster de Xeon 2P. (a) Ejecución en en 4 máquinas 4 procesadores.
(b) Ejecución en 2 máquinas 4 procesadores.
Cuando se utilizan cuatro procesadores, el dominio se divide en cuatro sub dominios con la siguiente
distribución:
Por lo tanto el pasaje de mensajes se realizará entre los pares (a, b), (a, c), (b, d) y (c, d).Esta descomposición
se puede manejar automáticamente o puede ser controlada por el usuario. En la Fig. 12 se muestra
gráficamente cómo sería el pasaje de mensajes entre cuatro procesadores. Teniendo en cuenta esta
distribucion en la Fig. 13 muestra el uso de la red en cantidad de Megabits por segundo (Mbps) que entran y
salen del nodo durante el período simulado. En el caso de 4M4P se observa un mayor uso de la red debido a
que el nodo representado debe intercambiar mensajes con otros dos nodos, alcanzando un máximo de 1.6
Mbps de datos de salida y 1 Mbps de entrada.
En el caso 2M4P el uso de la red disminuye un 50%. Esto se debe a que en este caso un procesador se
conecta con el otro procesador interno a través del Front Side Bus (FSB) y sólo utiliza la red para
intercambiar mensajes con un procesador de la otra máquina.
Fig. 12. Diagrama de conexión de una simulación con cuatro procesadores.
Los enlaces rojos son conexiones de red, los verdes son internos FSB.
(a)
(b)
Fig. 13. Uso de recurso de RED de uno de los nodos participantes de la simulación del modelo A en el cluster de
Xeon 2P. (a) Ejecución en 4 máquinas 4 procesadores. (b) Ejecución en 2 máquinas 4 procesadores.
En la Fig. 14 se grafica el uso de CPU del modelo Amill en un nodo del cluster Opteron dual en dos
simulaciones diferentes. El primer tramo corresponde a la ejecución del modelo en 16 procesadores y el
segundo tramo a una ejecución con 8 procesadores, en ambos casos se utiliza sólo un procesador por nodo.
Es interesante notar que en el primer caso el uso de CPU para procesos de usuario y de sistema es
prácticamente igual, 50% cada uno. Esto indica que el modelo es muy pequeño para ser ejecutado en 16
procesadores. El procesador utiliza más tiempo para resolver el pasaje de mensajes que para la resolución del
problema matemático. Para el segundo caso, sólo se nota un alto grado de procesos de sistema al inicio de la
simulación, momento en el cual se está distribuyendo las tareas entre los procesadores involucrados, luego se
estabiliza el uso exclusivamente para procesos de usuario.
compute -0-19.local
Percent
100
0
17:20
User CPU
System CPU
17:40
Idle CPU
Fig. 14. Uso de CPU para la simulación del modelo Amill con 16 y 8 procesadores.
CONCLUSIONES
ƒ La eficiencia de la simulación en paralelo es proporcional a la cantidad de celdas activas y a los fluidos
involucrados en el modelo. A mayor cantidad de datos a procesar, mayor eficiencia se obtendrá en su
paralelización.
ƒ La eficiencia del cluster también está relacionada con la velocidad de comunicación entre los
procesadores. (a) El ‘bus’ interno de una máquina no es eficiente para el intercambio de mensajes que
genera Eclipse Parallel®. Esto se comprobó al ejecutar el mismo modelo en una sola máquina utilizando
sus dos procesadores y en dos máquinas utilizando un procesador de cada una. En el último caso se
obtuvo mejor tiempo. Además, se debe tener en cuenta que en el primer caso los procesadores deben
compartir la memoria. Por lo tanto se recomienda que las máquinas que componen el cluster posean sólo
un procesador. (b) La capacidad de la red que conecta los nodos del cluster limitará la cantidad de nodos
que pueda tener el mismo. Por ejemplo, en una red dedicada al cluster 100baseT Ethernet se podrán
conectar hasta cuatro nodos. En cambio en una red Gigabit el número de nodos será mucho mayor. En el
modelo A que se utilizó para las pruebas se pudo observar que las interfaces de red de las máquinas sólo
utilizaron un porcentaje constante (máximo 1Mb) de la capacidad de sus interfaces. (c) Según el
proveedor del software, no se pueden armar clusters que requieran un gran número de nodos paralelos
bajo el sistema operativo Windows. (d) Las máquinas AMD Opteron 64 bits poseen una nueva tecnología
llamada ‘Coherent Hyper Transport’ para interconectar los procesadores internos de un nodo. Dicha
tecnología mostró muy buena performance con respecto a la capacidad de cálculo de un nodo con 4
procesadores. (e) Otra característica que favorece a la capacidad de cálculo de los procesadores AMD
Opteron 64 bits es que cada procesador posee bancos de memoria de uso exclusivo de cada procesador
(esto se logra configurando la opción de BIOS ‘Non CPU Interleaving’ y la opción del kernel ‘Non
Uniform Memory Access – NUMA’).
ƒ El tamaño de los modelos a procesar se ve limitado por la capacidad de memoria de las máquinas. Cuanta
más memoria tengan las máquinas, se podrán resolver modelos más grandes en menor tiempo. En el caso
de ser máquinas con múltiples procesadores se debe elegir la cantidad de memoria en relación con la
cantidad de procesadores involucrados en un nodo.
ƒ Se recomienda que el cluster sea homogéneo, esto es, que tenga el mismo hardware y software en cada
uno de sus nodos. Esto garantiza que el balance de carga automático que realiza Eclipse Parallel® sea
adecuado. Además, facilita la administración del cluster.
ƒ Es importante optimizar la configuración del sistema de archivos (p.e. en el caso de NFS) para obtener
mayor performance, debido a que Eclipse Parallel® realiza gran cantidad de funciones de escritura a
disco en el transcurso de la simulación.
ƒ Cuando se utiliza AMD® Opteron 64 es importante la arquitectura del motherboard para poder optimizar
el uso de los procesadores internos de un nodo habilitando la opción NUMA del kernel y la de ‘Non CPU
Interleaving’ del BIOS.
AGRADECIMIENTOS
A Schlumberger por el préstamo de las licencias necesarias para realizar las pruebas en las distintas
plataformas.
Al Instituto de Astronomía y Física del Espacio (IAFE, UBA) por prestarnos el cluster de 24 nodos
Opteron64 Duales.
A AMD, especialmente a Silvia Carusso por prestarnos la máquina Opteron de 4 procesadores.
Al Laboratorio de Sistemas Complejos del Departamento de Computación, de la UBA que nos cedió el lugar
físico de trabajo donde se encontraba dicho servidor.
Y especialmente a Total Austral por permitir presentar este trabajo en las II Jornadas de Geotecnología.
BIBLIOGRAFÍA
D. Ridge, D. Becker, P. Merkey and T.Sterling. Beowulf: Harnessing the power of parallelism in a pile-ofpcs. Proceedings, IEEE Aerospace. 1997.
Sun Microsystems. An overview of UltraSPARC™ III Cu. 2003.
J. Erhel. A parallel GMRES version for general sparse matrices. 1995.
Schlumberger. GSS Software Release Notes 2002A. 2002.
MPI Consortium. MPI Consortium: The Message Passing Interface Standard, Technical Report.
http://www.mcs.anl.gov/mpi. Junio 1998.
Schlumberger. Eclipse Parallel, Reduce simulation processing time. http://www.sis.slb.com. 2002.
R. Brandao. "Evolución del Microprocesador X86". AMD South America. 2005.
HyperTransport™ Consortium. HyperTransport™ I/O Technology Overview - An Optimized, Low-latency
Board-level Architecture. http://hypertransport.org. 2004.
Schlumberger. Oil and gas reservoir and production optimization. 2002.
P. Foster. Eclipse reservoir simulation. The Eclipse Parallel option. 2003.
P. Foster. Configuring Parallel Eclipse on a Network of Windows PCs. http://www.sis.slb.com. 2003.
P. Crumpton, P. Fjerstad, J Berge. Parallel Computing using Eclipse Parallel. 2003.
Schlumberger. Eclipse, Technical Description 2003A. Chapter 38: Parallel Option. 2003.
Veridian Information Solutions. Portable Batch System Administrator Guide. http://www.openpbs.org. 2000.
MAUI. MAUI Scheduler administrator’s guide. http://mauischeduler.sourceforge.net. 2005.