Resolución de problemas complejos en Clusters Linux. María Carolina León Carri 1, Luis Alfredo Tognon 1 carolina.leon@total.com, luis.tognon@total.

Resolución de problemas complejos en Clusters Linux María Carolina León Carri 1, Luis Alfredo Tognon 1 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 Velocidad del Memoria Versión de Interconexión Sistema Operativo procesador RAM Eclipse entre procs SunBlade 2000 1.28 Ghz 4 GB Solaris 8 2003a_1 - SunBlade 2500 Dual 1.28 Ghz 8 GB Solaris 8 2004a_1 - Intel Pentium IV 2 Ghz 2 GB Windows 2000 2003a_1 - Xeon (1P) 2.8 Ghz 4 GB Linux RedHat 7.3 2004a 1 Gb Fibra Óptica Xeon Dual 2 Ghz 1 GB Linux RedHat 7.2 2004a 1 Gb Fibra Óptica AMD Opteron64 Dual 1.8 Ghz 2 GB Linux RedHat AS 3 2004a_1 1 Gb UTP AMD Opteron64 (4P) 1.8 Ghz 4 GB Linux Gentoo 2004a_1 Coherent Hyper 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:

Ts S = donde, Ts + C N 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 5 5 5 9 / 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 Cantidad de Celdas Activas A 131859 58374 Amill 2.302.118 550.617 Amill 2.302.118 513.877 Intervalo de tiempo Inicio: 31/12/1965 Fin: 01/05/2003 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 10000 Elapsed (segundos) 8000 6000 4000 2000 0 SunBlade2000 SunBlade2500 Pentium4 Xeon 1P Xeon 2P Opteron 2P Opteron 4P Elapsed-TCPU 1068,43 16,88 682,61 11,62 9,91 30,20 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. Elapsed (segundos) 6500 6000 5500 5000 4500 4000 3500 3000 2500 2000 1500 1000 500 0 1 2 4 8 Cantidad de Procesadores Xeon 1P Xeon 2P Xeon 2P Opteron Dual Opteron Dual Opteron 4P 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. ELAPSED (segundos) 1500000 1400000 1300000 1200000 1100000 1000000 900000 800000 700000 600000 500000 400000 300000 200000 100000 0 1 1 4 4 8 SunBlade2000 Pentium 4 Xeon 2P Opteron 4P Opteron 2P ELAPSED-TCPU 39411.99 12455.40 53935.10 35459.20 51033.70 TCPU 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. Speed-up TS N C Xeon 2P 3.06 699255.71 4 53935.10 Opteron 4P 3.20 569417.61 4 35459.20 Opteron 2P 4.36 488880.24 8 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. Percent 100 compute -0-19.local 0 17:20 17:40 User CPU System CPU 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.